[Freeswitch-dev] thesis on live sip calls migration

Anthony Minessale anthony.minessale at gmail.com
Mon Jan 4 08:16:08 PST 2010

When would you like to continue this conversation?

On Fri, Dec 18, 2009 at 4:38 AM, stefano bossi <ste.bossi at 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 at 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_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20100104/f570110d/attachment.html 

More information about the FreeSWITCH-dev mailing list