Hi,<div>after a deeper investigation on cseq I can can state that:</div><div><br></div><div>- 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_*<br>
<br></div><div>- 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.</div>
<div><br></div><div>- 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.</div>
<div><br></div><div>I'm here for any further explanations</div><div><br></div><div>bye</div><div><br></div><div><div class="gmail_quote">On Tue, Jan 19, 2010 at 3:04 PM, stefano bossi <span dir="ltr"><<a href="mailto:ste.bossi@gmail.com">ste.bossi@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">Hi Anthony,<div><br></div><div>your last commit on sofia.c adds a very helpful function to extract sip_to_tag and sip_from_tag..</div>
<div>I was working on something similar but I also read the Cseq.. you can do this with these 3 lines of code</div>
<div><br></div><div><div>if (sip->sip_cseq && sip->sip_cseq->cs_seq) {</div><div><span style="white-space:pre"> </span>const char *sip_cseq = switch_core_session_sprintf(session,"%d", sip->sip_cseq->cs_seq);</div>
<div><span style="white-space:pre"> </span>switch_channel_set_variable(channel, "sip_cseq", sip_cseq);</div><div>}</div></div><div><br></div><div>(It compiles, I hope it is correct too :)</div>
<div><br></div><div>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.</div><div><br></div><div>bye</div></div><div>
<br><div class="gmail_quote"><div class="im">
On Mon, Jan 4, 2010 at 5:16 PM, Anthony Minessale <span dir="ltr"><<a href="mailto:anthony.minessale@gmail.com" target="_blank">anthony.minessale@gmail.com</a>></span> wrote:<br></div><div><div></div><div class="h5">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>When would you like to continue this conversation?<br><br><br><div class="gmail_quote"><div><div></div><div>On Fri, Dec 18, 2009 at 4:38 AM, stefano bossi <span dir="ltr"><<a href="mailto:ste.bossi@gmail.com" target="_blank">ste.bossi@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex"><div><div></div><div><div class="gmail_quote">Hi all,<br><div class="gmail_quote">
<br>as promised in #freeswitch-dev I'll try to explain better what I've done and I would like to achieve for my thesis.<br>
<br><br>At the moment I successfully patched sofsip_cli and now it can do something near active call migration :)<div>
Thanks to the versatility of nua api I could achieve my objective with little effort.</div>
<div>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.</div>
<div>In this case I write call data in a file and when I launch the reinvite I read directly from this file.<br>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.<br>
<br>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. <br>This is possible with these actions:<br><ul><li>registrations are shared with odbc<br></li></ul><ul><li>on the start of the module(present only on the backup machine):</li>
</ul><ol><li>I set an arp rule blocking the arp response for the virtual IP (set on the primary machine)<br>
</li><li>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)<br></li><li>I prepare and run the sip profile (on the backup)... loading here the profile permits to save a lot of time during reaction<br>
</li></ol><ul><li>on the reaction</li>
</ul><ol><li>I remove the arp rule</li><li>I send a gratuitous arp request</li></ol>As I said in about 50ms sip clients can call again. Maybe this time can decrease using NETLINK socket for the arp table.<br><br>The union of these 2 works
will give us a very fast "live profile migration" :D<br>
</div><br>There some points to discuss:<br>
<ul><li>switch_core_session_resurrect_channel: I didn't know this function, I need to understand what it offers, maybe tomorrow ;)<br></li><li>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) <br>
</li><li>I thought only to sofia aspects.. </li></ul>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.<br>This is my first work on something real like FS.. I'm opened to any kind of suggestions!<i><br><br></i>please contact me for further clarifications<br><br>Thanks<br>
<br>Stefano Bossi<br></div><br>
</div><br>
<br></div></div>_______________________________________________<br>
FreeSWITCH-dev mailing list<br>
<a href="mailto:FreeSWITCH-dev@lists.freeswitch.org" target="_blank">FreeSWITCH-dev@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Anthony Minessale II<br><br>FreeSWITCH <a href="http://www.freeswitch.org/" target="_blank">http://www.freeswitch.org/</a><br>ClueCon <a href="http://www.cluecon.com/" target="_blank">http://www.cluecon.com/</a><br>
Twitter: <a href="http://twitter.com/FreeSWITCH_wire" target="_blank">http://twitter.com/FreeSWITCH_wire</a><br><br>AIM: anthm<br><a href="mailto:MSN%3Aanthony_minessale@hotmail.com" target="_blank">MSN:anthony_minessale@hotmail.com</a><br>
GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com" target="_blank">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a href="http://irc.freenode.net" target="_blank">irc.freenode.net</a> #freeswitch<br><br>FreeSWITCH Developer Conference<br><a href="mailto:sip%3A888@conference.freeswitch.org" target="_blank">sip:888@conference.freeswitch.org</a><br>
<a href="http://iax:guest@conference.freeswitch.org/888" target="_blank">iax:guest@conference.freeswitch.org/888</a><br>
<a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org" target="_blank">googletalk:conf+888@conference.freeswitch.org</a><br>pstn:+19193869900<br>
<br>_______________________________________________<br>
FreeSWITCH-dev mailing list<br>
<a href="mailto:FreeSWITCH-dev@lists.freeswitch.org" target="_blank">FreeSWITCH-dev@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div></div></div><br></div>
<br>_______________________________________________<br>
FreeSWITCH-dev mailing list<br>
<a href="mailto:FreeSWITCH-dev@lists.freeswitch.org">FreeSWITCH-dev@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div><br></div>