[Freeswitch-dev] thesis on live sip calls migration

Thu Jan 21 01:45:14 PST 2010

Hi,
after a deeper investigation on cseq I can can state that:

- there are 2 cseq for each channel: in in my tests I substituted the
variable name sip_cseq with sip_incoming_cseq when it's read from nua_i_*
events and sip_outgoing_cseq when it's read from nua_r_*

- in order to resurrect a call I need only the sip_outgoing_cseq, in the
most part of cases this field remain unset for inbound channels ( so I can
use a random one during migration) and it is equal to the invite one for
outbound channel.

- things go in different way when FS sends in-session requests to endpoints.
In these cases I think it can be resolved by reading the sip_outgoing_cseq
on nua_r_info, nua_r_prack and nua_r_update. Obviously the sip_incoming_cseq
is increased on nua_i_info, nua_i_prack and nua_i_update but this field it's
not useful for migrating a call. Maybe it will be necessary to fire some new
switch custom events to give access to these updated field from
event_socket.

I'm here for any further explanations

bye

On Tue, Jan 19, 2010 at 3:04 PM, stefano bossi <ste.bossi at gmail.com> wrote:

> 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",
> sip->sip_cseq->cs_seq);
>  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
> INVITE.
>
> bye
>
> 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
>>
>>
>
> _______________________________________________
> 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/20100121/2c657237/attachment.html 