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

From: Stephen Casner <[email-masked]>
Date: Mon, 8 Nov 2004 13:55:54 -0800 (PST)

draft-ietf-behave-nat-00 contains the following statement:

   There is some very unfortunate
   wording in RFC 3550 section 11, which can cause some problematic
   behavior in RTP clients.  The wording could be interpreted as saying
   that if a client receives an odd port for sending RTP, it SHOULD
   change it to the next lower even number.  This would obviously result
   in the loss of RTP/UDP.

The actual text in RFC3550 is:

   For applications that take a single port number as a parameter and
   derive the RTP and RTCP port pair from that number, if an odd number
   is supplied then the application SHOULD replace that number with the
   next lower (even) number to use as the base of the port pair.  For
   applications in which the RTP and RTCP destination port numbers are
   specified via explicit, separate parameters (using a signaling
   protocol or other means), the application MAY disregard the
   restrictions that the port numbers be even/odd and consecutive
   although the use of an even/odd port pair is still encouraged.

The key here is that when a session description specifies only one
port number to convey the RTP+RTCP port pair, then the recipient of
that description needs to know how to determine the second port number
from the first.  It is critical that the sender and receiver (or
receivers plural for multicast) do this the same way.  Since the
convention is to use an even port for RTP and an odd port for RTCP,
the spec says that when the given port number is odd, the RTP SHOULD
be the next lower (even) number, and the odd number SHOULD be the RTCP
port.

However, because of requirements imposed by NATs and other
considerations, the second sentence in the above quote from RFC3550
was added.  All the applications need to do is explicitly state the
two port numbers, and then there is no restriction on the even/odd
condition of the RTP port number.

If your concern is that applications that do not implement RTCP will
only have one number to specify, then I have four responses:

  - If the application uses SDP to specify the session and gives only
    one address, this still implies that RTCP will be sent, so the
    RTCP port needs to be inferred from the single port that is given.
    In this case, I claim it makes sense for the stated rules to
    apply.

  - If you need to be able to use an odd RTP port number in sessions
    specified with SDP, then specify another port for RTCP but don't
    use it.  I believe it would be acceptable for that other port
    number to be zero.

  - If the application will specify its session some other way, and
    intends to specify only a single port with the implicatin that
    RTCP will not be sent, then the specification of that session
    description method can specify that the SHOULD above be
    overridden.

  - Designing out RTCP is bad.

draft-ietf-behave-nat-00 also contains the following statement:

   NATs that use an "IP address pooling" behavior of "arbitrary" can
   cause issues for applications that use multiple ports from the same
   endpoint but have no way to negotiate IP addresses individually
   (e.g., RTP and RTCP ports).

RFC 3605, "Real Time Control Protocol (RTCP) attribute in Session
Description Protocol (SDP)" specifies a means to negotiate an
alternate IP address for RTCP as well as a port number.

                                                        -- Steve

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

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 8 Nov 2004 14:35:37 -0800

Stephen, 

Thanks for reviewing the document.

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.

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.

-d

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Stephen
> Casner
> Sent: Monday, November 08, 2004 1:56 PM
> To: [email-masked]; [email-masked]
> Cc: AVT WG; [email-masked]
> Subject: [Ietf-behave] RTP in draft-ietf-behave-nat-00
> 
> 
> Ietf-behave mailing list
> [email-masked]
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: Randell Jesup <[email-masked]>
Date: 10 Nov 2004 17:26:12 -0500

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

>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
[email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 11 Nov 2004 07:31:34 -0800

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

> 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