> On 07 Jul 2016, at 19:20, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote: > > 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.
THis sounds like a cool test-case for SIPit. Switching from a wifi net to fixed network during a call - or just changing wifi networks. If you have ice you need to restart ice, if you are using Turn you can use the cookie to retrieve your part of the media stream and for SIP you need to reinvite. We do have multiple wifi networks with different properties - bad hotel network, IPv6 only, dual stack, “normal” wifi (whatever that is) - that will stress test implementations. /O > > 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
