Hi Paul, You are absolutely right but make-before-break is only possible, as you said, if you can get some advance warning.
I think the most suitable case is cellular-to-WiFi. In this case both networks will be available, we can make, verify and only after that handoff. However, WiFi-to-Mobile might neither give warning nor be available simultaneously especially when it is a user action like turn-off wifi or simply losing the coverage. Cellular radio-access-type changes are even more challenging: 3G to 4G (vice versa) in theory should be nearly seamless. But in reality IP connectivity will be lost for seconds before it is recovered. What is worse, IP address might not even be preserved. 2G to 3G (vice versa) is even more difficult as in many cases the radio access will be totally lost causing even longer down time. In fact, these were the cases where I doubted the reasoning behind "no retransmission over TCP/TLS" for INVITE etc when you absolutely need it. Best, -volkan 2016-07-07 20:20 GMT+03:00 Paul Kyzivat <pkyzi...@alum.mit.edu>: > ISTM that there is dubious likelihood of success of this is attempted > after the previous connection has already failed. Make-before-break is > safer if you can get some advanced warning. But make-before-break has its > own implications on how you do this so that it doesn't become > break-while-trying-to-make. > > Thanks, > Paul > > > On 7/7/16 12:37 PM, Volkan Hatem wrote: > >> 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 >> >> > _______________________________________________ > 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
