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

"Dan Wing" <dwing@cisco.com> 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).

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

-- 
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team
rjesup@wgate.com


_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt