[Freeswitch-dev] thesis on live sip calls migration

stefano bossi ste.bossi at gmail.com
Tue Jan 19 06:04:36 PST 2010

Hi Anthony,

your last commit on sofia.c adds a very helpful function to extract
sip_to_tag and sip_from_tag..
I was working on something similar but I also read the Cseq.. you can do
this with these 3 lines of code

if (sip->sip_cseq && sip->sip_cseq->cs_seq) {
const char *sip_cseq = switch_core_session_sprintf(session,"%d",
switch_channel_set_variable(channel, "sip_cseq", sip_cseq);

(It compiles, I hope it is correct too :)

This cseq can be used for calls failover in the most part of cases, I only
wonder if  this is still true after any other request during dialog than


On Mon, Jan 4, 2010 at 5:16 PM, Anthony Minessale <
anthony.minessale at gmail.com> wrote:

> Hi,
> 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>
> pstn:+19193869900
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20100119/cc7faf1a/attachment.html 

More information about the FreeSWITCH-dev mailing list