Subject: [AVT] Comments on draft-ietf-avt-rtp-new-11.txt

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 19 Feb 2002 13:59:31 -0500

Folks,

I noted that in the latest RTP draft has changed the hard requirement for
odd/even RTP/RTCP port pairs to "SHOULD".  I understand there are a number
of good reasons for this, but I'm concerned about backward compatibility
implications.

What I would like to propose is that we do relax the requirement, but
require that even/odd ports MUST be used unless otherwise negotiated
out-of-band between the session applications.  What I would expect is that
SIP or H.323 applications will have to negotiate the fact that the ports
used will not be paired as they are today.  Of course, this does not close
the door to incompatibility problems, but I think it will be more helpful
than simply trying to use various ports and failing to get media through
without any feedback as to why.

Paul

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

---

From: Stephen Casner <[email-masked]>
Date: Tue, 19 Feb 2002 17:27:36 -0800 (PST)

> of good reasons for this, but I'm concerned about backward compatibility

Since RFC 1889 did not use RFC 2119 keywords, it is not clear that the
draft revision has made a change in the requirement level.
Nevertheless, it is good to be concerned about proper interpretation.
The reason for the SHOULD is that RTP is a framework that might be
used in a various ways, possibly including some application using
preassigned, static port numbers.

> without any feedback as to why.

Is there really a problem?  The revised text says that ports MAY be
selected without the even/odd constraint if both the RTP and RTCP port
numbers are specified explicitly.  In applications where only one port
is specified and the other is implicitly derived from the first, then
the implementation must be assuming some rule for their relationship.
I can't see any motivation for an implementation to make up some
different rule rather than using the one the draft says SHOULD be
used.

The real backwards compatibility problems that I see have to do with
entities that may process RTP and/or RTCP packets without being party
to the session establishment protocol.  Examples would be a
third-party RTCP monitor and an RTP header compression box.  These
entities won't be able to rely on RTCP being on an odd port.  However,
we agreed to accept this backwards incompatibility liability because
NAT boxes forced us to accept port translations we could not control.

By the way, I am happy to see that you are reading the draft and
thinking carefully about the changes.
							-- Steve

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 20 Feb 2002 17:15:45 -0500

Steve,

As you pointed out, the real concern are the boxes in the middle.  Most
endpoints (note "most") can properly handle RTP/RTCP ports with no specific
association.  However, I have seen some implementations (NATs, proxies, and
real endpoints) wherein there was an assumed association.  H.323 actually
does allow one to signal separate RTP and RTCP port numbers, but some
implementations just ignore the RTCP port number field, assuming that the
odd/even rule exists.

RFC 2327 (SDP) states quite clearly that the m= line contains the RTP port
and that the RTCP port is assumed.  I know this is subject to change, as
well, but we also have the compatibility problems.  I certainly do not
object to making such as change, as it would align with H.323.  Nonetheless,
I think the "capability" of supporting something other than even/odd ports
should be advertised so that entities can properly inform users or network
operators of such issues.

In the RTP draft, I'd be quite happy with removing the odd/even requirement
(SHOULD is fine), so long as there is also a statement that says that when
RTP is used without even/odd port paring, that the session applications MUST
negotiate the usage of non-even/odd ports.

Paul

---

From: Stephen Casner <[email-masked]>
Date: Wed, 20 Feb 2002 19:03:17 -0800 (PST)

Paul,

> association.

Perhaps not even most.  Those that use SDP per RFC 2327 for signaling
do not have a way to express the RTCP port number separately.

> However, I have seen some implementations (NATs, proxies, and

That sounds like an implementation bug -- not following the H.323
spec.  If those implementations want to uphold the even/odd
requirement in RFC 1889, then they should refuse the connection when
the RTCP port number field does not comply.

> well, but we also have the compatibility problems.

Proposals to extend SDP in this regard have been made.

> I certainly do not

Here's where we run into trouble.  "Advertised" to whom and with what
protocol?  An RTP header compressor box in the middle is not party to
any signaling protocol.

> negotiate the usage of non-even/odd ports.

The existing statement is something like the contrapositive of that
statement:

   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.

We could follow that with a restatement in the same direction as
yours:

   Applications using RTP and RTCP destination port numbers that are
   not an even/odd port pair MUST specify both port numbers via
   explicit, separate parameters (using a signaling protocol or other
   means).

However, that seems like stating the obvious: if the RTCP port number
can't be inferred from the RTP port number, then you have to tell the
program what RTCP port number to use.  Do we need to say this?

Note that my restatement differs from your statement in a subtle way:
the RTP spec can't specify what a "session application" will do nor
make any assumption that a signaling protocol will be used.

							-- Steve

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 21 Feb 2002 14:14:02 -0500

Steve,

When I mentioned "most" endpoints, I was limiting that to H.323... sorry: I
should have been more explicit.

H.323 allows RTP and RTCP ports numbers to be signaled, but the text also
requires that the ports be even/odd paired: there was no deviation made from
RFC 1889.  As such, some implementation simply ignore the extra fields and
some applications do not include them.  Of course, there have always been
questions as to whether those fields were needed in the first place...
indeed, according to RFC 1889, they were not.

>    although the use of an even/odd port pair is still encouraged.

I have a hard time with this, since the text preceeding this in the draft
now includes the word SHOULD.  To say that an endpoint SHOULD use even/odd
pair means that it is not required to do so.  This part of the paragraph is
perfectly fine to me if we remove the SHOULD text from the ealier part of
the paragraph.

> program what RTCP port number to use.  Do we need to say this?

I agree with you: I have no objections to this text, but I'm not sure that
it adds any value.

What I would prefer to have is something like this:

---------
RTP relies on the underlying protocol(s) to provide demultiplexing of RTP
data and RTCP control streams. For UDP and similar protocols, RTP uses an
even destination port number and the corresponding RTCP stream uses the next
higher (odd) destination port number. 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 MUST 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 RTP and RTCP port numbers MUST NOT be the
same since RTP relies on the port numbers to demultiplex the RTP data and
RTCP control streams.
---------

I have simply removed the SHOULD text, which retains backward compatibility,
but opens the door for external signaling to use other port numbers.

Paul