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.miness...@gmail.com> wrote:
> 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
>
>
_______________________________________________
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
