Subject: Re: [BEHAVE] TURN Issue #4: Port Adjacency

From: Magnus Westerlund <[email-masked]>
Date: Fri, 18 Jan 2008 16:40:44 +0100

Jonathan Rosenberg skrev:
> The use case is communicating between an ICE agent and a non-ICE 
> traditional Voip client, like a PSTN gateway. Those endpoints frequently 
> implement the old original 1889 and do RTP and RTCP on adjacent ports. 
> Since ICE recommends TURN as the default candidate, when communicating 
> with these peers, we'd be able to get RTCP. WIthout this feature, RTCP 
> will not work.
> 
> There are still a LOT of endpoints in real deployment that assume 
> RTP/RTCP port adjacency.
> 

Yes, port adjacency must work.

Cheers

Magnus Westerlund (with individual hat)

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://www1.ietf.org/mailman/listinfo/behave

---

From: Philip Matthews <[email-masked]>
Date: Mon, 21 Jan 2008 08:27:58 -0500

The discussion on this point has been fairly quiet recently, so let  
me try to summarize where we are at and make a proposal for how to  
resolve this issue.

I am definitely not an RTP expert, but here is what I understand to  
be the use-case for this feature. Please correct me if I am wrong.

Say X and Y are SIP UAs that want to communicate. Y is an old  
endpoint that does RFC 1889 and expects RTCP on the next-higher port  
and does not signal this fact. If X is behind a NAT (any type of  
NAT!) and Y has a public IP address, then X and Y can communicate and  
use both RTP and RTCP only if X allocates two adjacent ports on a  
TURN server with a public IP address.

As far as I can see, if Y is behind a NAT, then there is no easy way  
to get this to work, because Y's NAT will most likely map Y's ports  
to non-adjacent ports and there is no easy way to determine what Y's  
RTCP port was mapped to.

Given the above use-case and the fact that some people want to  
support it, then here is my proposal to resolve this issue:
     In an Allocate Request, a client can request that the server  
reserve the next-higher port number. The server may or may not be  
able to do this; for example, the server may not support this  
feature, or the server may support it but be unable to find two  
adjacent ports. When the server is not able to reserve the next- 
higher port, the server returns an error code and thus the allocation  
attempt fails. At this point, the client may give up and try a  
different server, or it may decided to retry without the request to  
reserve the next-higher port.
If the server IS able to reserve the next-higher port, then it keeps  
this reservation until (a) a client request that exact port number,  
or (b) the lower-numbered allocation expires. In case (a), this is  
hopefully the client that reserved the lower-numbered port.

The only drawback I can see with this is that clients will need code  
to retry the request if they are willing to proceed without the  
reserved next-higher port. Thus this will cause some delay in  
gathering ICE candidates. If this is seen as a big problem, then the  
alternative would be for the server to do the allocation and return a  
flag saying that it was not able to reserve the next-higher port.  
However, I don't really like this since REQUESTED-PORT-PROPS can be  
used to request other properties and it is not very clear how to  
generalize this (e.g., if you request an odd port, can the server  
allocate an even one and say "sorry but I could only find an even one  
to allocate"?).

Comments on the use-case or the proposal?

- Philip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 23 Jan 2008 11:49:54 -0500

A couple of comments:

Philip Matthews wrote:
> The discussion on this point has been fairly quiet recently, so let me 
> try to summarize where we are at and make a proposal for how to resolve 
> this issue.
> 
> I am definitely not an RTP expert, but here is what I understand to be 
> the use-case for this feature. Please correct me if I am wrong.
> 
> Say X and Y are SIP UAs that want to communicate. Y is an old endpoint 
> that does RFC 1889 and expects RTCP on the next-higher port and does not 
> signal this fact. If X is behind a NAT (any type of NAT!) and Y has a 
> public IP address, then X and Y can communicate and use both RTP and 
> RTCP only if X allocates two adjacent ports on a TURN server with a 
> public IP address.
> 
> As far as I can see, if Y is behind a NAT, then there is no easy way to 
> get this to work, because Y's NAT will most likely map Y's ports to 
> non-adjacent ports and there is no easy way to determine what Y's RTCP 
> port was mapped to.
> 
> 
> 
> Given the above use-case and the fact that some people want to support 
> it, then here is my proposal to resolve this issue:
>     In an Allocate Request, a client can request that the server reserve 
> the next-higher port number. The server may or may not be able to do 
> this; for example, the server may not support this feature, 

no - this is not an optional feature. I don't want to negotiate this 
capability.

or the
> server may support it but be unable to find two adjacent ports. When the 
> server is not able to reserve the next-higher port, the server returns 
> an error code and thus the allocation attempt fails. At this point, the 
> client may give up and try a different server, or it may decided to 
> retry without the request to reserve the next-higher port.
> this reservation until (a) a client request that exact port number, or 

Minor correction - the SAME CLIENT requests that exact port number. Same 
means, uses the same credentials (username, pass, realm).

> (b) the lower-numbered allocation expires. In case (a), this is 

I'm agnostic on whether (b) should be as you describe, or a short 
timeout (say 30s).

> 
> 
> The only drawback I can see with this is that clients will need code to 
> retry the request if they are willing to proceed without the reserved 
> next-higher port.

Assuming that the server cannot allocate it. THis would only happen if 
the server is running low on resources, presumably. In that case, any 
allocation might fail, for adjacent ports or not.

> Thus this will cause some delay in gathering ICE 
> candidates. If this is seen as a big problem, then the alternative would 
> be for the server to do the allocation and return a flag saying that it 
> was not able to reserve the next-higher port. However, I don't really 
> like this since REQUESTED-PORT-PROPS can be used to request other 
> properties and it is not very clear how to generalize this (e.g., if you 
> request an odd port, can the server allocate an even one and say "sorry 
> but I could only find an even one to allocate"?).

I don't want to do this. The request is for two ports. It should fail 
completely, or succeed completley. I hate dealing with partial success 
cases.

-Jonathan R.

-- 
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

---

From: Philip Matthews <[email-masked]>
Date: Wed, 23 Jan 2008 16:41:22 -0500

On 23-Jan-08, at 11:49 , Jonathan Rosenberg wrote:

> A couple of comments:
>
> Philip Matthews wrote:
>> The discussion on this point has been fairly quiet recently, so  
>> let me try to summarize where we are at and make a proposal for  
>> how to resolve this issue.
>> I am definitely not an RTP expert, but here is what I understand  
>> to be the use-case for this feature. Please correct me if I am wrong.
>> endpoint that does RFC 1889 and expects RTCP on the next-higher  
>> port and does not signal this fact. If X is behind a NAT (any type  
>> of NAT!) and Y has a public IP address, then X and Y can  
>> communicate and use both RTP and RTCP only if X allocates two  
>> adjacent ports on a TURN server with a public IP address.
>> As far as I can see, if Y is behind a NAT, then there is no easy  
>> way to get this to work, because Y's NAT will most likely map Y's  
>> ports to non-adjacent ports and there is no easy way to determine  
>> what Y's RTCP port was mapped to.
>> feature,
> no - this is not an optional feature. I don't want to negotiate  
> this capability.

Two comments on this:
1) I don't see any negotiation here. The client asks for this feature  
and is told "Sorry". The client doesn't know whether the "Sorry" is  
because the server can never do this, or just cannot do this right now.
2) In practice, I don't see the server not implementing features as a  
big deal. The client is not trying random TURN servers, rather the  
administrator as arranged for the client to be able to use certain  
servers. So the administrator knows the capabilities of the servers.  
If the administrator feels that support for this service is  
important, he/she will only sign contracts with TURN server providers  
that support this feature.

BTW, both of these comments apply to the ChannelBind failure case as  
well.

>
> or the
>> server may support it but be unable to find two adjacent ports.  
>> When the server is not able to reserve the next-higher port, the  
>> server returns an error code and thus the allocation attempt  
>> fails. At this point, the client may give up and try a different  
>> server, or it may decided to retry without the request to reserve  
>> the next-higher port.
>> If the server IS able to reserve the next-higher port, then it  
>> keeps this reservation until (a) a client request that exact port  
>> number, or
>
> Minor correction - the SAME CLIENT requests that exact port number.  
> Same means, uses the same credentials (username, pass, realm).

It may be that there is a unique username per client. But personally  
I suspect that, at least in some cases, there will be a large number  
of clients all provisioned with the same set of credentials. This is  
probably what I will suggest Avaya does, because it is easier.

> I'm agnostic on whether (b) should be as you describe, or a short  

Yup. This is your original option 2b.

>
>> The only drawback I can see with this is that clients will need  
>> code to retry the request if they are willing to proceed without  
>> the reserved next-higher port.
>
> Assuming that the server cannot allocate it. THis would only happen  
> if the server is running low on resources, presumably. In that  
> case, any allocation might fail, for adjacent ports or not.

Sure.

>
>
>> Thus this will cause some delay in gathering ICE candidates. If  
>> this is seen as a big problem, then the alternative would be for  
>> the server to do the allocation and return a flag saying that it  
>> was not able to reserve the next-higher port. However, I don't  
>> really like this since REQUESTED-PORT-PROPS can be used to request  
>> other properties and it is not very clear how to generalize this  
>> (e.g., if you request an odd port, can the server allocate an even  
>> one and say "sorry but I could only find an even one to allocate"?).
>
> I don't want to do this. The request is for two ports. It should  
> fail completely, or succeed completley. I hate dealing with partial  
> success cases.

I don't like this either.

- Philip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 23 Jan 2008 22:32:03 -0500

inline:

Philip Matthews wrote:
>>> able to do this; for example, the server may not support this feature,
>>

Its 'negotiation' in that, now the client has to be prepared for the 
case where the server doesn't support the thing. I want to make it so 
that failure of these requests is rare - corner cases like capacity 
failures under overload. I DONT want it to become a common case, because 
the server decided to reject due to lack of support for the feature.

Protocol options complicate things. THis is a protocol option I don't 
want. All servers MUST implement this capability, and MUST either fully 
accept the request, or fully reject it.

Do, or do not. There is no try.
    -Jedi Master Yoda

> servers. So the administrator knows the capabilities of the servers. If 
> the administrator feels that support for this service is important, 
> he/she will only sign contracts with TURN server providers that support 
> this feature.

It still means client software has to be prepared for all of these 
cases. Please, there is NO REASON for this optionality.

> 
> BTW, both of these comments apply to the ChannelBind failure case as well.

No. That request should fail almost never. I just commented on this in 
another thread. ANd that means clients don't need to implement failure 
cases like, 'my server doesn't support it'. ChannelBind is a MUST 
implement and support on the server, full stop.

-Jonathan R.

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 24 Jan 2008 10:14:55 -0800

I agree with JDR (and Master Yoda) on this one.

thanks,
-rohan

On Jan 23, 2008, at 7:32 PM, Jonathan Rosenberg wrote:
>>>> port and does not signal this fact. If X is behind a NAT (any  
>>>> type of NAT!) and Y has a public IP address, then X and Y can  
>>>> way to get this to work, because Y's NAT will most likely map  
>>>> Y's ports to non-adjacent ports and there is no easy way to  
>>>> determine what Y's RTCP port was mapped to.
>>>> reserve the next-higher port number. The server may or may not  
>>>> be able to do this; for example, the server may not support this  
>>>> feature,
>>>
>> 1) I don't see any negotiation here. The client asks for this  
>> feature and is told "Sorry". The client doesn't know whether the  
>> "Sorry" is because the server can never do this, or just cannot do  
>> this right now.
>
> Its 'negotiation' in that, now the client has to be prepared for  
> the case where the server doesn't support the thing. I want to make  
> it so that failure of these requests is rare - corner cases like  
> capacity failures under overload. I DONT want it to become a common  
> case, because the server decided to reject due to lack of support  
> for the feature.
>
> Protocol options complicate things. THis is a protocol option I  
> don't want. All servers MUST implement this capability, and MUST  
> either fully accept the request, or fully reject it.
>
>> 2) In practice, I don't see the server not implementing features  
>> as a big deal. The client is not trying random TURN servers,  
>> rather the administrator as arranged for the client to be able to  
>> use certain servers. So the administrator knows the capabilities  
>> of the servers. If the administrator feels that support for this  
>> service is important, he/she will only sign contracts with TURN  
>> server providers that support this feature.
>
> No. That request should fail almost never. I just commented on this  
> in another thread. ANd that means clients don't need to implement  
> failure cases like, 'my server doesn't support it'. ChannelBind is  
> a MUST implement and support on the server, full stop.
>
> -Jonathan R.
>
> --

---

From: "Alfred E. Heggestad" <[email-masked]>
Date: Sat, 26 Jan 2008 12:35:50 +0100

Magnus Westerlund wrote:
>> traditional Voip client, like a PSTN gateway. Those endpoints 
>> frequently implement the old original 1889 and do RTP and RTCP on 
>> adjacent ports. Since ICE recommends TURN as the default candidate, 
>> when communicating with these peers, we'd be able to get RTCP. WIthout 
>> this feature, RTCP will not work.
>>

I also this that this operation should be 100% atomic.

a simpler way of solving this using atomic allocations:

- The client sends an AllocateRequest asking for two subsequent ports.

- The server returns AllocateResponse with two RELAY-ADDRESS attributes,
  one for each mapping.

This can also be extended to "I want to allocate N subsequent ports".

What is missing here is a way for the client to map the two ports.

/alfred

> ------------------------------------------------------------------------
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 28 Jan 2008 11:23:06 -0500

inline:

Alfred E. Heggestad wrote:
>>> when communicating with these peers, we'd be able to get RTCP. 
>>> WIthout this feature, RTCP will not work.
>>>

THe problem is that the client needs to send a separate request to the 
server for each port, so that the server can learn the mapping from the 
allocated ports to the server reflexive port towards the client. So you 
are needing multiple requests anyway even if you consider the first one 
to actually reserve both ports.

-Jonathan R.