Hi Dale, Indeed, INVITE-with-Replaces was the first alternative I could think of as well.
However, in the case where I implemented the hand-off we could deterministically bring the SIP-UA to register with its "home" proxy which holds the current call-leg (dialog). A simple re-INVITE to update the target address was enough to restore signalling connectivity. This was a simpler approach in our case due to some other limitations I will not digress. I am sure you are aware of RFC 6141 which brings more clarification to target address update requests. Of course, there are other issues to tackle as well such as - NAT traversal, whether ICE or a simpler (always insert a proxy when NAT detected) mechanisms can be preferred. - The time it takes to get an IP connectivity, resolve proxy addresses might complicate it if it takes too long - Whether it conflicts with other operations requiring re-INVITEs as well (updating session description to add/remove/modify media) - Decision to drop or recover unstable calls (before establishing a dialog) Etc. Best, -volkan 2016-07-07 18:49 GMT+03:00 Dale R. Worley <wor...@ariadne.com>: > Is there any generalized technique for "handoff", for moving a SIP > dialog from one interface/medium to another? > > My impression is that this problem is most commonly seen switching > between a mobile connection and a WiFi connection, but it can happen in > pure-SIP situations as well. > > So far, it seems that a UA could use INVITE-with-Replaces (sent from the > new interface to the other party) to transfer the dialog from its old > interface to its new interface. Has anyone implemented such a > technique? > > Dale > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
