On Mon, May 12, 2014 at 4:53 PM, ThunderZ <thunderz2008@gmail.com> wrote:
HI, Govanni
Thank you for your reply.
Hi ThunderZ (what a name! :) )
1) the logic underlying is: you expect to have 16 lines at your disposal, you planned your business on this, so if you don't have it I don't work, so you repair the error, or change your assumptions. I find this logic sound
I would disagree.
Let's say you have a VOIP gateway with 4xE1s. One E1 is playing up, an there are 60 calls going on the other E1s. In order to fix that E1, I don't think anyone would want to force the whole system down, and cut all those existing calls.
The problem we're talking about here is if in a system with two E1 cards, one (or both) is broken at system startup. If you can gather enough support in mailing list for a different behavior (eg: starting the module also if not all - and possibly none - skype interfaces are working) I can modify it. At this moment, seems to me the current behavior is sound.
2) I don't understand this. Can you elaborate, and tell me the steps to reproduce the problem?
Basically, I just add a new interface to skypopen.conf.xml, then run "sk reload" via fs_cli. I see all the configs of the existing interfaces show up, but nothing on the new interface.
Sorry I continue to not understand. Let's say you have 10 interfaces, skype001 to skype010 in your config file. You add a skype011 interface to the file and that interface is ignored by "sk_reload", while is working with a "reload mod_skypopen" ?
3) the skype client must be connected to the skype network (eg: authenticated) before the start of mod_skypopen. Because of this there is a delay in the start_skype_clients script between the launch of the skype clients and the launch of mod_skypopen. The first time a skype client starts with a specific skype_username, after being connected to the skype network it builds files into its config_directory that will greatly expedite future connections of that skype_client with that skypename to the skype network.
Please note that the error I mentioned isn't related to mod_skyopen module itself. It's the starting of a skype instance in a Xvfb server. From my experiences, it could take up to 3 minutes for a skype user to login to the skype network on linux via Xvfb, and this not only applies to the first time login either. When this error happens, the skype user cannot login to the network even after such a long delay, and just returns "P2P connect failed" at the end (Tried this 5 times with a skype user with the same result). The funny thing is, it only happens with the Xvfb server. When I used a real Xserver, with GUI to log in to skype, it would work fine. Thereafter, it works ok with Xvfb server too, as probably the "good" settings are stored in the skype configuration directory by now.
Yes, what you just wrote is what I was trying to convey, "probably the "good" settings are stored in the skype configuration directory by now" -giovanni
Thanks.
Sincerely,
Giovanni Maruzzelli Cell : +39-347-2665618
On Sat, May 10, 2014 at 5:36 PM, ThunderZ <thunderz2008@gmail.com> wrote:
Hi, there
I have a few questions regarding this mod_skypopen module.
1. While loading the module, if one skype interface fails to load for whatever reason, i.e. the skype user didn't login for that interface or Xvfb server had a issue, why all the other working interfaces are removed automatically, and the module itself is unloaded with an error? I don't think a single dead interface should affect other working ones.
2. According to the Wiki, "sk reload => this re-reads Skypopen configuration file skypopen.conf.xml and adds ONLY new interfaces it found in conf." However, when I do a "sk reload", I found all the new interfaces are ignored too. Did I miss something? I'm using the latest git version.
3. With the default skype configuration template, I found that some skype accounts always return this "/P2P connect failed" error using the standard startup script. However, if I use the same command to login such accounts from a real X server, it will work ok (abeit after some considerable delay). After that, it also works ok with the Xvfb display via the standard script.
/ Any advice will be greatly appreciated./
Thanks. /
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services:consulting@freeswitch.orghttp://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Serverhttp://www.cudatel.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://wiki.freeswitch.orghttp://www.cluecon.com
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org