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.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.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