You're suggesting running two instances of FS on same machine, have them communicate first over TCP then UDP via SIP over socket (Skype --> Skypiax --> FS1 --> FS2) on a production system? Hmmm... nah... :-)
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Giovanni Maruzzelli Sent: Friday, April 17, 2009 4:40 PM To: [email protected] Subject: Re: [Freeswitch-users] Skypiax as a windows service On Fri, Apr 17, 2009 at 12:30 AM, Anthony Minessale <[email protected]> wrote: > are you planning on just signaling on TCP or both audio and signalling > cos realtime audio over TCP kinda stinks. > > you may find that just running FS as the farm and calling to it with sip is > more or less the same idea with no work ;) > Hi Anthony, yes, TCP is not the best for audio. But it's the only way to route audio from/to the Skype client instance. I mean, it's the only way the Skype client allows you to access its audio streams. This is the current situation: 1) mod_skypiax use native signaling (Windows messages, or X events) to interact with the Skype client through the Skype API. 2) one of the Skype API commands allows for telling to the Skype client: "please, use this TCP port for audio in, and that TCP port for audio out, instead of the soundcard". 3) the TCP ports must be on the local IP interface (127.0.0.1) 4) mod_skypiax and the Skype client(s) exchange audio samples through TCP on the local machine, while signaling is platform native I would like to have the Skype client instances on another machine, for security and stability purposes (I'm not trusting consumer grade Skype client to run on production main FS server). That's why I was writing the "farming client", for rerouting both the signaling commands and the audio streams back and forth between two separate machines. Now I understand what you wrote: I can use FS itself (with mod_skypiax) as a "farming client", and connect with the "main" FS via SIP. So I can achieve the original aim of having a separate machine(s) with the Skype instances. Obviously, if that's a requirements, I can optimize the footprint of the "farming client FS" loading only the modules needed for SIP-Skype interaction. Thanks a lot Anthony, this cuts the Gordian knot and spare me lots of pathetic efforts :-) UV, is this solution practical for you? Sincerely, Giovanni Maruzzelli ========================================= www.celliax.org via Pierlombardo 9, 20135 Milano Italy gmaruzz at celliax dot org Cell : +39-347-2665618 Fax : +39-02-87390039 > > On Thu, Apr 16, 2009 at 10:09 AM, Giovanni Maruzzelli <[email protected]> > wrote: >> >> EG: in the "farm out" scenario there will be FS talking via TCP to a >> "farm client" (on local machine or remote). The "farm client" talks >> with Skype client instances running on the same machine the "farm >> client" is running on. >> >> On Thu, Apr 16, 2009 at 1:47 PM, UV <[email protected]> wrote: >> > Decoupling the Skyiax from FS will solve the problem as I assume it'll >> > use >> > TCP/IP (winsock) to interface with FS - therefore, I can run it still on >> > the >> > same machine but two separate sessions. >> >> yes, it uses TCP for this. So you would end up with FS (with Skypiax >> module) running on RDP while the Skype client instances are running as >> services, on the same machine (or in different machines). FS will talk >> to Skype client instances via TCP. >> Is this acceptable to you? >> >> Other question: why not running FS as a service too? If you run FS as >> a service and Skype clients as services, all things would works? Why >> you want to use RDP for? (sorry for the silly questions, I just want >> to understand better). >> >> > However, I think getting the Skypiax >> > to work as a service will be more beneficial regardless if it's >> > decoupled or >> > not. >> >> What do you mean? I believe that Skypiax (as an FS module) works when >> FS is run as service. Your problem seems to me that you cannot run >> Skype instances under RDP because they cannot access the sound device. >> Is this correct? >> >> gm >> >> _______________________________________________ >> Freeswitch-users mailing list >> [email protected] >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users >> http://www.freeswitch.org > > > > -- > Anthony Minessale II > > FreeSWITCH http://www.freeswitch.org/ > ClueCon http://www.cluecon.com/ > > AIM: anthm > MSN:[email protected] > GTALK/JABBER/PAYPAL:[email protected] > IRC: irc.freenode.net #freeswitch > > FreeSWITCH Developer Conference > sip:[email protected] > iax:[email protected]/888 > googletalk:[email protected] > pstn:213-799-1400 > > _______________________________________________ > Freeswitch-users mailing list > [email protected] > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > http://www.freeswitch.org > > _______________________________________________ Freeswitch-users mailing list [email protected] http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org _______________________________________________ Freeswitch-users mailing list [email protected] http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
