Sorry, I haven't seen this one. Observations made in the following slides
overlap with my experiences:
http://web.cs.ucla.edu/~ghtu/Mobicom13-tu-slide.pdf
2016-07-12 19:06 GMT+03:00 Dale R. Worley :
> Volkan Hatem writes:
> > Cellular radio-access-type changes are even more challenging: 3G to 4
> On 13 Jul 2016, at 17:21, Dale R. Worley wrote:
>
> "Olle E. Johansson" writes:
>>> Requests forwarded between different types of transports where the
>>> proxy's TU must take an active role in ensuring reliable delivery on
>>> one of the transports MUST be forwarded transaction statefully
"Olle E. Johansson" writes:
>> Requests forwarded between different types of transports where the
>> proxy's TU must take an active role in ensuring reliable delivery on
>> one of the transports MUST be forwarded transaction statefully.
>>
>> That is, a stateless proxy is not allowed to sen
> On 12 Jul 2016, at 17:48, Dale R. Worley wrote:
>
> Roman Shpount writes:
>> We actually always use UDP like re-transmits even when sending SIP messages
>> over TCP or TLS. There are enough implementations that connect TCP or TLS
>> interface with UDP using a stateless proxy which make it nec
> On 12 Jul 2016, at 18:08, Dale R. Worley wrote:
>
> "Olle E. Johansson" writes:
>> THis sounds like a cool test-case for SIPit. [...]
>
>> We do have multiple wifi networks with different properties - bad
>> hotel network, IPv6 only, dual stack, "normal" wifi (whatever that is)
>> - that wil
mo.zun...@cwpanama.com
-Mensaje original-
De: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] En nombre de Roman
Shpount
Enviado el: Tuesday, July 12, 2016 12:19 PM
Para: Dale R. Worley
CC: Sip-implementors@lists.cs.columbia.edu
Asunto:
On Tue, Jul 12, 2016 at 11:58 AM, Dale R. Worley wrote:
> Paul Kyzivat 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-brea
On Tue, Jul 12, 2016 at 11:48 AM, Dale R. Worley wrote:
> Roman Shpount writes:
> > We actually always use UDP like re-transmits even when sending SIP
> messages
> > over TCP or TLS. There are enough implementations that connect TCP or TLS
> > interface with UDP using a stateless proxy which mak
"Olle E. Johansson" writes:
> THis sounds like a cool test-case for SIPit. [...]
> 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.
If there are any significant nu
Volkan Hatem writes:
> Cellular radio-access-type changes are even more challenging: 3G to 4G
> (vice versa) in theory should be nearly seamless. [...]
> 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.
Is that b
Brett Tate writes:
> If it matters, solutions using things like Replaces and REFER raise the
> typical concerns with authorization, security, billing, et cetera. For
> instance, see security section of RFC 3891.
Security is "interesting" because there is no guarantee that the new
dialog is handl
Paul Kyzivat 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 does
Volkan Hatem writes:
> Indeed, INVITE-with-Replaces was the first alternative I could think of as
> well.
> 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
Roman Shpount writes:
> We actually always use UDP like re-transmits even when sending SIP messages
> over TCP or TLS. There are enough implementations that connect TCP or TLS
> interface with UDP using a stateless proxy which make it necessary.
Just last night, I found this requirement, which I
> On 07 Jul 2016, at 20:28, Volkan Hatem wrote:
>
> 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 e
> On 07 Jul 2016, at 20:31, Brett Tate wrote:
>
>> 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 B2BU
> On 07 Jul 2016, at 19:20, Paul Kyzivat 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
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
25 matches
Mail list logo
