<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>