Subject: RE: [Ietf-behave] TURN Issue #7: Forking interactions

From: "Francois Audet" <[email-masked]>
Date: Mon, 5 Dec 2005 13:53:47 -0800 (PST)

Don't we have the same problem with multiple 183s with SDP for 
early media?

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Jonathan Rosenberg
> Sent: Monday, December 05, 2005 12:42
> To: Behave
> Subject: [Ietf-behave] TURN Issue #7: Forking interactions
> 
> 
> The way TURN works right now, you can only have a single 
> correspondent 
> for media streams if you want to avoid the TURN 
> encapsulations. This is 
> because there can only be one active destination.
> 
> This has interesting interactions with forking. If a SIP 
> INVITE forks, 
> and you get back multiple 200 OK, each with a single media 
> stream, the 
> caller has to handle that. To avoid encapsulation, it would 
> have to do 
> an additional TURN allocation for each forked branch after the first, 
> and issue a re-invite to modify the media destination to use that new 
> allocated address. Also, after the first 200 OK, it cannot 
> immediately 
> issue a set active destination; it needs to wait a little bit 
> to see if 
> there are any more 200 OK coming.
> 
> There are a few options here:
> 
> 1. change nothing; just document this use case in a section 
> that talks 
> specifically about SIP interactions
> 
> 2. allow for multiple active destinations. This would be a sizeable 
> change in the protocol, requiring that encapsulation always 
> be used, and 
> probably requiring a different encapsulation technique
> 
> 
> Given how common multiple 200 OK is in practice right now (not much), 
> this strikes me as a corner case for which a non-optimal 
> solution is OK. 
> As such, I would propose #1.
> 
> Thanks,
> Jonathan R.
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Cisco Fellow                                   Parsippany, NJ 
> 07054-2711
> Cisco Systems
> jdrosen@xxxxxxxxx                              FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> 
>

---

From: "Derek MacDonald" <[email-masked]>
Date: Mon, 5 Dec 2005 14:15:42 -0800 (PST)

I wasn't under impressions that setting an active destination restricted
traffic to that destination only.

If we make Send Request unreliable, it seems that we could use turn
encapsulation for one of the targets with minimal overhead.  The client
needs to keep track of which of the multiple targets is active, and possibly
optimize the current active destination when some call legs are removed but
it shouldn't be too hard.

Given the above assumptions I vote for #1.

--Derek

> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-
> bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Francois Audet
> Sent: Monday, December 05, 2005 1:54 PM
> To: Jonathan Rosenberg; Behave
> Subject: RE: [Ietf-behave] TURN Issue #7: Forking interactions
> 
> _______________________________________________
> Ietf-behave mailing list

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 20 Dec 2005 11:09:16 -0800 (PST)

Yes, same problem.

-Jonathan R.

Francois Audet wrote:

-----Original Message-----

Thanks,
Jonathan R.

--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@xxxxxxxxx                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 20 Dec 2005 11:29:11 -0800 (PST)

Derek MacDonald wrote:

I wasn't under impressions that setting an active destination restricted
traffic to that destination only.
No, it doesn't at the moment. Nor does it prohibit incoming packets from 
destinations that are not active.

However, while pondering this topic, it has occurred to me that there is 
a bug in this area in the -08 spec. The TCP behavior works under the 
assumption that you never end up muxing TURN encapsulated and 
non-encapsulated data over the same connection. So, the idea was, the 
client would issue a Set Active Destination over TCP, and after that, 
there would never need to be TURN messages from client to server. This 
is true. However, it is still possible to have a mix of TURN and 
non-TURN traffic from server to client. In particular, if multiple TCP 
connections had been established from the turn server to remote 
destinations, data can arrive on either. Data from the active 
destination would be forwarded without encapsulation, but data from the 
inactive one would need to be encapsulated. Thats a problem.

One way to fix this is to make it so that, once an active destination is 
set, you can ONLY receive incoming packets from that destination; others 
are discarded.

If we make Send Request unreliable, it seems that we could use turn
encapsulation for one of the targets with minimal overhead.  The client
needs to keep track of which of the multiple targets is active, and possibly
optimize the current active destination when some call legs are removed but
it shouldn't be too hard.
Well, per above, if one makes it so that you only get packets from the 
active destination, this wouldn't quite work. It would work if you never 
set the active destination. Basically, if you reduce the send overhead 
by making it unreliable, you would not set the active destination at 
all, and encapsulate every packet.

Indeed (thinking aloud here), a more radical approach is to simply drop 
the whole notion of active destination - always encapsulate in both 
directions. I'm not proposing this, as it would add a fair bit of packet 
overhead for the common case of no forking, but it would simplify things.

-Jonathan R.