Subject: RE: [Ietf-behave] draft-ietf-behave-nat-00: RTP behavior descript ion

From: "Francois Audet" <[email-masked]>
Date: Fri, 29 Oct 2004 09:51:28 -0700 (PDT)

Ok, it seems to me that we are all completely in agreement. 

How about adding the following text right after the paragraph on port 
parity in section 3.2 (this is a slighly modified version of what
I proposed earlier this week):

        Some NATs attempt to preserve the port contiguity rule of RTCP=RTP+1. These NATs
        do things like sequential assignment, port reservation and so forth. Sequential
        port assignment assumes that the application will open a binding for RTP first and
        then open a binding for RTCP. It is not practical to enforce this requirement
        on all applications. Furthermore, there is a glare problem if many 
        applications (or endpoints) are trying to open binding 
        simultaneously. Port reservation is also problematic since it is wasteful, 
        especially considering that a NAT can not reliably distinguish between RTP over 
        UDP and other UDP packets where there is no contiguity rule. For those 
        reasons, it would be too complex to attempt
        to preserve the contiguity rule by suggesting specific NAT behavior, and it would
        certainly break the deterministic behavior rule.

        In order to support both RTP and RTCP, it will therefore be necessary
        that applications follows rules to negotiate both RTP and RTCP separately,
        and account for the very real possibility that the RTCP=RTP+1 rule will be
        broken. As this is an application requirement, it is outside of the scope 
        of this document to discuss it further.

Is this good? Any suggested improvements?

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Magnus Westerlund
> Sent: Friday, October 29, 2004 08:19
> To: ml-behave@xxxxxxxxxx
> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Ietf-behave] draft-ietf-behave-nat-00: RTP 
> behavior descript ion
> 
> 
> Hi Jon,
> 
> Jon Ringle wrote:
> 
> > By specifying that a BEHAVE-compliant NAT has a means to 
> provide port
> > parity
> > and +1 reservation, then BEHAVE does NOT encourage a change 
> by applications
> > requiring such behaviour.
> 
> I will clarify that I don't think it will be good, even to 
> try, to put a 
> requirement that RTP and RTCP is kept together. That is to 
> complex and 
> to brittle to work. However to avoid any clients from failing 
> into the 
> pitfall of renumbering their RTP port number to an even 
> number, I think 
> that preserving port parity makes sense. However, port parity is NOT 
> enough to make RTP work over a BEHAVE-compliant NAT. An 
> application will 
> be required to have further traversal mechanisms. Thus, any 
> application 
> will need to adopt a explicit RTCP port signalling rule.
> 
> Removing the port parity rule, will only result in that NATs 
> break even 
> more sessions. If there is very little cost associated with the 
> requirement I don't see a reason, why one can avoid having these 
> failing. There will be sufficient amount of sessions failing 
> anyway that 
> transition to applications with traversal capacity will be used.
> 
> Best Regards
> 
> Magnus Westerlund
> 
> Multimedia Technologies, Ericsson Research EAB/TVA/A
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: 
> magnus.westerlund@xxxxxxxxxxxx 
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> 
>

---

From: Melinda Shore <[email-masked]>
Date: Fri, 29 Oct 2004 10:11:51 -0700 (PDT)

On Friday, October 29, 2004, at 12:51 PM, Francois Audet wrote:
Is this good? Any suggested improvements?
Works for me.

Melinda

---

From: Jon Ringle <[email-masked]>
Date: Fri, 29 Oct 2004 10:23:12 -0700 (PDT)

> Is this good? Any suggested improvements?

I think this text is good. I'd just like to point out that as soon as an 
application negotiates RTP and RTCP independantly, there is no technical 
requirement by that application to maintain port parity. But since 
maintaining port parity by a NAT shouldn't be difficult, I see no problem in 
keeping that.

Having the +1 reservation requirement is frought with potential problems, as 
you've pointed out and race conditions.

Jon