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.bo...@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.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
>
>
_______________________________________________
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
