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