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

[Stephen Casner <casner at acm.org>]

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