Hi, When would you like to continue this conversation?
On Fri, Dec 18, 2009 at 4:38 AM, stefano bossi <ste.bo...@gmail.com> wrote: > Hi all, > > as promised in #freeswitch-dev I'll try to explain better what I've done > and I would like to achieve for my thesis. > > > At the moment I successfully patched sofsip_cli and now it can do something > near active call migration :) > Thanks to the versatility of nua api I could achieve my objective with > little effort. > Basically I call someone, then I kill sofsip_cli and I restart it. I launch > my "reinvite" command and the call can continue normally. The called client > doesn't realize what happened. > In this case I write call data in a file and when I launch the reinvite I > read directly from this file. > Sofsip_cli sends an INVITE message with some TAG appended to the > nua_handle. So the called phone thinks to receive an in-session invite and > simply refreshes the call, but Sofsip_cli instead allocates all the stuff > for a new call. In this way I can avoid to modify directly the RTP part. It > seems to be all simpler. > > I even wrote a little module for FS able to monitor(using the SIP OPTION > message) the life of a specific sofia profile.. It's just a proof of concept > but it can do failover(without live call migration) between 2 machines in > about 50ms. > This is possible with these actions: > > - registrations are shared with odbc > > > - on the start of the module(present only on the backup machine): > > > 1. I set an arp rule blocking the arp response for the virtual IP (set > on the primary machine) > 2. I set the virtual IP on the backup machine( but no one knows thanks > to the arp rule and so I can bind to vIP) > 3. I prepare and run the sip profile (on the backup)... loading here > the profile permits to save a lot of time during reaction > > > - on the reaction > > > 1. I remove the arp rule > 2. I send a gratuitous arp request > > As I said in about 50ms sip clients can call again. Maybe this time can > decrease using NETLINK socket for the arp table. > > The union of these 2 works will give us a very fast "live profile > migration" :D > > There some points to discuss: > > - switch_core_session_resurrect_channel: I didn't know this function, I > need to understand what it offers, maybe tomorrow ;) > - the propagation of call state variables: my first idea was to use the > multicast events adding some headers to send all the necessary data (but > anthm proposed XML) > - I thought only to sofia aspects.. > > In next days I'll try to understand where to hook in FS to try these ideas. > When I'll have something ready (and without very very big errors:) I'll be > happy to send you the patch. > This is my first work on something real like FS.. I'm opened to any kind of > suggestions!* > > *please contact me for further clarifications > > Thanks > > Stefano Bossi > > > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev@lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > > -- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_miness...@hotmail.com <msn%3aanthony_miness...@hotmail.com> GTALK/JABBER/PAYPAL:anthony.miness...@gmail.com<paypal%3aanthony.miness...@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:8...@conference.freeswitch.org <sip%3a...@conference.freeswitch.org> iax:gu...@conference.freeswitch.org/888 googletalk:conf+...@conference.freeswitch.org<googletalk%3aconf%2b...@conference.freeswitch.org> pstn:+19193869900
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
