BTW, Everything I wrote assumes UA perspective. IMS like tighter integrations have the luxury of the advance warning and support of the network.
-volkan 2016-07-07 21:28 GMT+03:00 Volkan Hatem <vol...@hatem.net>: > 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
