On Tue, Jul 12, 2016 at 11:58 AM, Dale R. Worley <wor...@ariadne.com> wrote:
> Paul Kyzivat <pkyzi...@alum.mit.edu> writes: > > 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. > > At least in theory, you can make-after-break, since INVITE-Replaces can > snatch a call from an endpoint that is no longer reachable. (The remote > endpoint resends BYE many times, and then drops the dialog, but the > user interface is moved to the new dialog immediately.) > > As someone else noted, the important thing is to detect the break > quickly enough that the call can be reestablished before session timers > expire. > > You actually need to recover the connection before the transaction times out in order to make sure that SIP Session timer does not close the dialog. Session timer connectivity check and connection failure can occur at any time relative to each other. Because of this, connection can fail at the time of session timer connection check, no matter how often you check the connectivity. The only way to preserve the dialog is to reestablish the network connection while connectivity check is still running. This is, by the way, one more reason why we use UDP timers for TCP based messages -- it gives the client time to detect the connection failure and recover the connection. _____________ Roman Shpount _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
