Hi,
When would you like to continue this conversation?
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):
- I set an arp rule blocking the arp response for the virtual IP (set on the primary machine)
- 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)
- 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
As I said in about 50ms sip clients can call again. Maybe this time can decrease using NETLINK socket for the arp table.
- I remove the arp rule
- I send a gratuitous arp request
The union of these 2 works will give us a very fast "live profile migration" :D
There some points to discuss:
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.
- 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..
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