Subject: Re: [BEHAVE] TURN 07: Channel ID collisions with usage

From: Rohan Mahy <[email-masked]>
Date: Sat, 1 Mar 2008 07:31:46 -0800

Hi Magnus,

I feel your headache more clearly now.  If Alice waits to do a  
channel binding until after a candidate is selected, everything will  
work fine, but I agree that it would work better if Alice didn't have  
to do this.

thanks,
-rohan

On Feb 29, 2008, at 7:45 AM, Magnus Westerlund wrote:

> Rohan Mahy skrev:
>> Hi Magnus,
>> With this feature, there is no multiplexing of TURN and another  
>> protocol.
>> A softphone application on Alice's PC goes sends a TURN Allocate  
>> Request through her home NAT to turn.example.net.  She takes the  
>> RELAYED-ADDRESS and the XOR-MAPPED-ADDRESS and puts these in ICE  
>> candidates in an offer that she sends to Bob's UA.  She could have  
>> also sent a STUN Binding Request to stun.example.net instead to  
>> get the XOR-MAPPED-ADDRESS, but that would require an additional  
>> transaction for Alice's UA.
>> This convenience feature has nothing to do with ICE connectivity  
>> checks which are different STUN requests sent either directly to  
>> Alice's UA or forwarded through a relayed address used by Alice on  
>> the TURN server.  ICE does not suggest in any way that Alice or  
>> Bob will accept *TURN* requests on the same port used for RTP.
>> Does this make sense?
>
> Okay, take 3 to explain my headache. Alice's PC sends a TURN  
> allocate request from port P on interface X to turn.example.net. It  
> gets back two addresses: R:rp and S:sp, i.e. a relayed and a server  
> reflexive address that both has X:P as base for them.
>
> This have the implications that when BOB sends his STUN checks to  
> R:rp they will arrive at X:P in either a DATA indication or with a  
> channelbinding header. BOB can also send his STUN check to S:sp  
> that arrives at X:P without a TURN header. So far no major  
> problems. The X:P can demultiplex directly arriving STUN requests  
> and the ones that first goes to the TURN client. But we also have  
> the capability to handle data on this socket. In fact one could  
> illustrate the multiplexing like this:
>
>                         /-- Data receiver
>                        /
>        /- TURN Client ---- STUN Server
>       /
> X:P ----- STUN server
>       \
>        \- Data receiver
>
> The issue is that a RTP data receiver both would like to have data  
> with payloads starting with 10 in the first octet. Thus you are  
> unable to decide what the correct demultiplexing in this case is,  
> at least as long as you are using channelID in the 8000-8FFF range  
> with RTP.
>
> Do you now see the issue?
>
> Cheers
>
> Magnus Westerlund
>
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: [email-masked]
> ----------------------------------------------------------------------

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 3 Mar 2008 09:33:34 +0200

Le Friday 29 February 2008 17:48:53 ext Philip Matthews, vous avez écrit :
> This is not quite true. If the client tries to use the same transport
> address for both direct connections and indirect connections via the
> TURN server, then the client will receive 4 different types of
> packets on the same transport address:
> 1) STUN-formatted TURN packets
> 2) STUN connectivity packets from the peer
> 3) RTP packets
> 4) ChannelData messages
>
> The client can demux these by looking at the first two bits in the
> packets:
> 00 - Packet is either case (1) or (2), and must be further demuxed by
> looking at the source transport address
> 01 - Packet is a ChannelData message
> 10 - Packet is an RTP packet
> 11 - Packet is a ChannelData message
> This only works if the client refrains from using channel numbers
> that start with 10.

Now that would seem to be a total non-starter. What if the payload is _not_ 
RTP? I don't expect the "STUN/TURN" library to know about the payload format, 
and I don't expect the software using the library to know much about channel 
allocation. Hence I strongly disagree with the idea that TURN clients should 
know what channel number to use or not to use.

-- 
Rémi Denis-Courmont

---

From: Philip Matthews <[email-masked]>
Date: Mon, 3 Mar 2008 14:52:14 -0500

I think Jonathan has an good point.
Using his approach, there is no need to restrict the channel number  
range.

My inclination right now is to describe both approaches in the  
specification, and let an implementation choose the approach it wishes.

- Philip

On Fri, 29-Feb-08, at 16:56 , Jonathan Rosenberg wrote:

> I had thought that the client would FIRST demux packets from the TURN
> server, vs. those not from the TURN server. For stuff coming from the
> TURN server, it is always TURN or channeldata, and we know how to  
> demux
> that. For stuff not coming from the TURN server, its never  
> channeldata,
> and never TURN; it can be RTP or STUN. ANd those are easy to demux.
>
> So I think this needs to be explained but I see no need to constrain
> channel numbers or any other such thing.
>
> Think of what would happen in the case of tcp from client to turn
> server; everything over that connection is clearly TURN and treated as
> such. Just do the same for UDP.
>
> Thanks,
> Jonathan R.
>
> Philip Matthews wrote:
>> Magnus:
>>
>> Thanks for point out this issue, which I had not previously  
>> considered.
>> As I see it, there are a number of ways that a client can solve this
>> problem:
>>
>> 1) Since the choice of channel numbers is totally under the  
>> control of
>> the client, the client can avoid channel numbers that make demuxing a
>> problem. In the case of RTP, this would mean that the client should
>> avoid channel numbers that have the first two bits as either 00 or 10
>> (the first is used by STUN and the second is used by RTP). This still
>> leaves 2^31 possible channel numbers. For application protocols other
>> than RTP, the client may have to avoid other channel numbers.
>>
>> 2) If the client knows that, for a given call, its peers will  
>> either all
>> use the direct path or all use the TURN server, then it can simply  
>> wait
>> to allocate channel numbers until it knows which case it is dealing
>> with. If all peers are going via the TURN server, then there can  
>> be no
>> conflict with the application protocol (e.g. RTP) since all  
>> application
>> protocol packets arrive at the client encapsulated inside either a  
>> Data
>> indication or a ChannelData message, so all channel numbers except  
>> those
>> starting with 00 can be used.
>>
>> 3) If the client is dealing with an application protocol where the  
>> demux
>> problem is harder (for example, a protocol which allows arbitrary  
>> values
>> in the first 32 bits), then the client must use a different client
>> transport address to talk to the TURN server. In this case, the
>> XOR-MAPPED-ADDRESS in the Allocate response is not useful.
>>
>> On a separate thread, we are discussing whether ESP falls into  
>> case (3).
>>
>> In terms of the document, I suggest adding text that basically  
>> says the
>> above. I would make it general (i.e., not specific to RTP), but we  
>> could
>> add an appendix that discusses the issue for certain specific
>> application protocols.
>>
>> - Philip
>>
>>
>> On Fri, 29-Feb-08, at 08:32 , Magnus Westerlund wrote:
>>
>>> Hi,
>>>
>>> In the review of TURN 07 I found that the draft doesn't at all take
>>> care of a case I asked about previous.
>>>
>>> The allocation response include the server reflexive address to the
>>> TURN client. The only reason for doing this is to enable a client to
>>> co-locate both a TURN client and a direct STUN+UDP based  
>>> protocol, for
>>> example RTP, on the same port.
>>>
>>> However, the TURN channel header has overlap with RTP thus causing a
>>> demultiplexing collision when channel numbers in the 8000-8FFF range
>>> is used.
>>>
>>> This seriously need to be taken care of. I think the simplest  
>>> thing is
>>> to stop co-locating the TURN client with anything else. And thus  
>>> also
>>> the XOR-MAPPED-ADDRESS should not be returned in the allocate  
>>> response
>>> either.
>>>
>>> Cheers
>>>
>>> Magnus Westerlund
>>>
> Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
> Cisco Fellow                                   Edison, NJ 08837
> Cisco, Voice Technology Group
> [email-masked]
> http://www.jdrosen.net                         PHONE: (408) 902-3084
> http://www.cisco.com