Subject: [AVT] RE: [Ietf-behave] RTP in draft-ietf-behave-nat-00

From: "Francois Audet" <[email-masked]>
Date: Mon, 8 Nov 2004 21:38:08 -0500

> If a SIP/SDP application receives instructions to send RTP to 
> an odd address (that is, port) when the SDP does not include 
> an a=rtcp attribute (RFC 3605) to specify the RTCP port 
> separately, then indeed, RFC 3550 does say that the RTP 
> should be sent to the even port that is one lower.  But, I 
> claim this SIP/SDP application is broken if it was expecting 
> the application to send RTP on the odd port and RTCP on the 
> next higher even port (or maybe the next lower even port, or 
> even the odd port two higher).  Do you disagree?

No, I do not disagree. In fact, I completely agree with you. 
The simple odd/even rule that we are adding does NOT address the port
contiguity rule (and we've added wording on that that you haven't 
seen yet for the next release).

This is one of the many reason why the next thing we do after
the NAT Behavior document (for UDP Unicast, then Multicast and
TCP) is the "Application" document which will explain all this.

I think it will be very important to have a review of
the upcoming Application document from AVT (at least for those
aspects related to RTP/RTCP. We will definitively seek your feedback.

Again, really what we were looking at addressing is the "substract
one to the odd port" statement (which one could read as applying
even if both the RTP and RTCP ports are seperately negotiated).
We are just ensuring that a NAT will not change the parity.

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 11 Nov 2004 16:18:51 -0500

Dan is correct.

The intent is definitively NOT that application can rely on ports being odd
or even.

We will address your points in an upcoming version of the document and in
the application
draft.

> -----Original Message-----
> From: Dan Wing [mailto:[email-masked]] 
> Sent: Thursday, November 11, 2004 07:32
> To: Randell Jesup
> Cc: Stephen Casner; Audet, Francois [SC100:9T51:EXCH]; 
> [email-masked]; AVT WG; [email-masked]
> Subject: RE: [AVT] RE: [Ietf-behave] RTP in draft-ietf-behave-nat-00
> 
> 
> Randell Jesup:
> 
> > "Dan Wing" <[email-masked]> writes:
> > >To your first point, I believe we resolved this, in a positive
> > way, on the
> > >list; -00 doesn't yet reflect those changes.  We decided 
> to require 
> > >NATs to preserve even and odd port numbers when they 
> create their UDP
> > bindings,
> > >as this provides the best interoperability for RTP 
> applications that 
> > >don't/can't provide explicit signaling of their RTCP port.
> >
> >         Ummm...
> >
> >         And how will you "require" NATs to do this?  This 
> would mean 
> > that all NATs would need to map all UDP traffic to the same oddness 
> > (even->even,
> > odd->odd).  While sure, the NAT vendors _could_ write code this
> > way (though
> > it may well break some current NAT-traversal code that tries to do 
> > predictive mapping), there are millions of NATs out there that will 
> > never implement this, and nothing to force new releases to do so.
> >
> >         The even/odd port thing was (IMHO) a Bad Idea (in 
> hindsight), 
> > I assume meant to avoid having to figure out how to signal 
> the number 
> > for the second port - and even for that even/odd wasn't 
> really needed, 
> > all you needed was contiguous.  Other TCP/UDP protocols 
> don't do these 
> > sorts of things with port numbers (even/odd, or implied 
> relationships 
> > between port
> > numbers) - it's much better to actually signal the ports to be used.
> >
> >         We shouldn't compound it by "requiring" NATs 
> maintain oddness 
> > (after the horse is not only out of the barn, but 12 miles down the 
> > road). We're apparently trying to avoid breaking "RTP applications 
> > that don't/can't provide explicit signaling of their RTCP port" by 
> > putting a requirement on NATs that will at best be phased in over 
> > years, and at worst totally ignored, instead of requiring RTP 
> > applications to specify both RTP and RTCP ports.  The 
> effect will be 
> > that RTP applications that attempt to rely on this NAT requirement 
> > will end up breaking in many situations, and quite probably in 
> > unpredictable ways.  (For example, many NATs try to maintain port 
> > numbers inside->outside, but if the port is in use will 
> then allocate 
> > other non-contiguous port numbers of different oddness.)
> >
> >         The original idea (even/odd pairs) wasn't a good 
> one, and was 
> > somewhat at odds with normal techniques in TCP/UDP, and 
> certainly at 
> > odds with any sort of NAT concept.  (Note: just my opinion, 
> of course)
> >
> >         Of course, having a NAT preserve oddness (and contiguity!) 
> > will improve the odds of an older RTP application working 
> from behind 
> > it, so it might be a *nice* thing to do in the NAT - but no 
> one should 
> > be counting on it, and it's yet another complication in NAT 
> design and 
> > limitation that could cause it to run out of ports (in a large 
> > corporate-style NAT).
> 
> I'll leave the draft-ietf-behave-nat authors to comment on 
> the specific text they're considering; it's my understanding 
> they are adding text which hits on your points above.
> 
> > >To your second, a reference to RFC3605 will be added to the 
> > >'application behavior' document, which will describe how 
> applications 
> > >should behave. The current BEHAVE document just describes how NATs 
> > >should behave.
> >
> >         If BEHAVE is how they "should" behave, then my 
> objections are 
> > lessened - though we need to make sure that people don't use this 
> > document as an excuse not to specify the RTCP port.
> 
> Application behavior will be in the application document (not 
> in draft-ietf-behave-nat); Francois and I are going to take a 
> first cut at the application document in the next month or 
> two.  The application document is described as "Produce a BCP 
> that discusses protocol design techniques for using the 
> existing set of NAT traversal approaches" in the BEHAVE 
> charter <http://www.ietf.org/html.charters/behave-charter.html>.
> 
> -d
> 
> 
>