On Thu, Jul 7, 2016 at 2:28 PM, Volkan Hatem wrote:
> 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.
>
We actually always use UDP like re-transmits even when sending SIP messages
over TCP or TLS. T
On Thu, Jul 7, 2016 at 11:49 AM, Dale R. Worley wrote:
> 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
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 mi
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 :
> Hi Paul,
>
> You are absolutely right but make-before-break is only possible, as you
> said, if yo
> 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?
Yes; with B2BUA acting upon Replaces.
If it matters, solutions using thi
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
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
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
