Yes, agree ... as we have recently implemented VoWiFi (iOS / Apple based) which used SIP Protocol (INVITE/REGISTER etc.) and handover from WiFi to LTE/4G is working OK. Also handover from LTE/4G to 3G is working as well which is called eSRVCC (but this require telecommunication CORE signaling to be involved).
Adnan UL Haque Access Solution Architect Mobile: +966592442474 | Direct: +966592412474 -----Original Message----- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Volkan Hatem Sent: Thursday, July 07, 2016 9:43 PM To: Volkan Hatem Cc: sip-implementors@lists.cs.columbia.edu Subject: SUSPECT: Re: [Sip-implementors] Handoff 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 ________________________________ Disclaimer This communication is intended for the above named person and is confidential and / or legally privileged. Any opinion(s) expressed in this communication are not necessarily those of Zain. If it has come to you in error you must take no action based upon it, nor must you print it, copy it, forward it, or show it to anyone. Please delete and destroy the e-mail and any attachments and inform the sender immediately. Thank you. Zain is not responsible for the political, religious, racial or partisan opinion in any correspondence conducted by its domain users. Therefore, any such opinion expressed, whether explicitly or implicitly, in any said correspondence is not to be interpreted as that of Zain. Zain may monitor all incoming and outgoing e-mails in line with Zain business practice. Although Zain has taken steps to ensure that e-mails and attachments are free from any virus, we advise that, in keeping with best business practice, the recipient must ensure they are actually virus free. _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
