[Freeswitch-dev] thesis on live sip calls migration

stefano bossi ste.bossi at gmail.com
Fri Dec 18 02:38:33 PST 2009

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"

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

*please contact me for further clarifications


Stefano Bossi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20091218/b22c0cde/attachment.html 

More information about the FreeSWITCH-dev mailing list