Multiplexing RTP Data and Control Packets on a Single Port
draft-ietf-avt-rtp-and-rtcp-mux-07

[Ballot discuss]
It is my intention to clear this DISCUSS during the IESG call unless
others on the IESG or the author/shepherd request I hold this for
subsequent resolution.

When multiplexing on a single port, a common problem is the need
to prevent any sort of windowing or flow control of one channel from
interfering with another channel (much of the complexity in BEEP exists
to address this issue, for example).  In this case, it would be
important that any flow control or windowing of the RTP stream not
impact the RTCP packets.  Unfortunately, my understanding of RTP is
insufficient to know if the lack of text discussing this is a problem.

I would guess one of three situations applies:
1. This is an important issue which was overlooked and text needs to
  address this.
2. This is an implementation consideration but not an inherent problem
  in the protocol.  Text discussing the issue would help implementers,
  and improve the document, but I would not want to cause delay over
  this issue.  In this case, consider this a non-blocking comment.
3. RTP has no flow control or windowing issues that are relevant.

[Ballot discuss]
It is my intention to clear this DICUSS during the IESG call unless
others on the IESG or the author/shepherd request I hold this for
subsequent resolution.

When multiplexing on a single port, a common problem is the need
to prevent any sort of windowing or flow control of one channel from
interfering with another channel (much of the complexity in BEEP exists
to address this issue, for example).  In this case, it would be
important that any flow control or windowing of the RTP stream not
impact the RTCP packets.  Unfortunately, my understanding of RTP is
insufficient to know if the lack of text discussing this is a problem.

I would guess one of three situations applies:
1. This is an important issue which was overlooked and text needs to
  address this.
2. This is an implementation consideration but not an inherent problem
  in the protocol.  Text discussing the issue would help implementers,
  and improve the document, but I would not want to cause delay over
  this issue.  In this case, consider this a non-blocking comment.
3. RTP has no flow control or windowing issues that are relevant.

[Ballot discuss]
Given these constraints, it is RECOMMENDED to follow the guidelines
  in the RTP/AVP profile [7] for the choice of RTP payload type values,
  with the additional restriction that payload type values in the range
  64-95 MUST NOT be used.  Specifically, dynamic RTP payload types
  SHOULD be chosen in the range 96-127 where possible.  Values below 64
  MAY be used if that is insufficient, in which case it is RECOMMENDED
  that payload type numbers that are not statically assigned by [7] be
  used first.

It looks like this document if approved also updates RFC 3551 (reference [7]) and this should be marked in the document header.

IANA Last Call Comments:

*** IANA has questions:

Where is the "a=candidate" attribute (mentioned in 5.1.3)
assigned? Or is this a typo and you mean "a=capability"?

***

Upon approval of this document, the IANA will make
the following assignments in the "Session Description
Protocol (SDP) Parameters" registry located at

http://www.iana.org/assignments/sdp-parameters

sub-registry "att-field (media level only)"

Type SDP Name Reference
---- ------------------ ---------
rtcp-mux [RFC-avt-rtp-and-rtcp-mux-05]

We understand the above to be the only IANA Action
for this document.

PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Tom Taylor. I believe this version is ready.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document was announced informally to the BEHAVE and MMUSIC Working
Groups. Prior to that announcement, an MMUSIC Chair commented on the draft,
ICE from version 14 onwards has mentioned it, and the Chair of the BEHAVE
Working Group has been aware of it. Because RTP/RTCP multiplexing could
affect current QoS procedures developed by other SDOs, it is recommended
that these SDOs (ETSI TISPAN, ITU-T Q. 5/11, PacketCable) be formally
advised of the work.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization, or XML?

No.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No specific concerns. The issues raised during WG discussion (as
enumerated below under "Document History") have all been dealt with.
No related IPR disclosure.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

The list and meeting discussions involved a satisfactory number of people,
and did their job in raising and resolving issues. The document brought
about a discussion of architectural principles in San Diego, since it
represents a change to the RTP/RTCP architecture. The discussion concluded
that the potential benefits were worth the change. The document drew no
comments in AVT Working Group Last Call, but the issues raised in earlier
discussion had already been dealt with at that point.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.) Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type, and URI type reviews? If the document
does not already indicate its intended status at the top of
the first page, please indicate the intended status here.

Nits noted on the tools /avt page for this draft:

** Obsolete normative reference: RFC 2032 (ref. '3') (Obsoleted by RFC 4587)
The reference to RFC 2032 is intentional.

A later version of draft-ietf-mmusic-ice exists.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

References are split as required. There is a normative dependency on
draft-ietf-avt-rtcpssm, which is supposed to be ready but needs further
editorial work. The Chairs will work to bring this into WGLC ASAP.

(1.i) Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process, has the Document
Shepherd conferred with the Responsible Area Director so that
the IESG can appoint the needed Expert during IESG Evaluation?

One new SDP attribute registered, properly referred to RFC 4566 for
the registry and procedurtes.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

N/A.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up. Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
This memo discusses issues that arise when multiplexing RTP data
packets and RTP control protocol (RTCP) packets on a single UDP port.
It updates RFC 3550 to describe when such multiplexing is, and is
not, appropriate, and explains how the Session Description Protocol
(SDP) can be used to signal multiplexed sessions.

Working Group Summary
This document represents a solid consensus of the AVT Working Group,
with informal concurrence of the MMUSIC and BEHAVE Working Groups.
Following the initial proposal, the major issue subsequently considered
and resolved was how to negotiate the multiplexing capability and
achieve fail-safe behaviour. The decision was to provide a new SDP
attribute to signal the multiplexing capability explicitly. There was
also some discussion of how to signal bandwidth requirements. The
outcome was a decision to include allowance for RTCP traffic in the
b=AS: value.

Document Quality
The document has attracted considerable interest because it makes NAT
traversal easier. Jonathan Rosenberg, author of the ICE document,
reviewed the proposal in terms of its interaction with ICE and provided
related text. Randell Jesup deserves special mention for his careful
reviews of successive versions of the document and persistence in
analysis of the associated signalling issues.

Personnel
Document Shepherd was Tom Taylor.
Responsible Area Director was Cullen Jennings.

---------------------------
Document history:

draft-perkins-dccp-rtp-00.txt, published 17-10-2005, mentions possibility
of multiplexing RTP and RTCP onto the same port, but notes that care
would be required to do it right.

draft-perkins-avt-rtp-and-rtcp-mux-00.txt published 8-9-2006.

Hadriel Kaplan  had specific comments (thread
"Comments on draft-perkins-avt-rtp-and-rtcp-mux-00.txt" beginning
11-9-2006) on the following points:
-- why caution needed on PT values;
-- effect on bandwidth values coded in b=AS line.
Randell Jesup  agreed with the relevance of these
points and had a general suggestion on the bandwidth issue. Harikishan
Desineni made a more specific suggestion. Colin
Perkins agreed to clarify his concern over potential payload type
clashes and proposed to accept the essence of Harikishan's proposal for
calculation of the b=AS value.

Discussion between Randell Jesup and Hadriel Kaplan (main thread
"Fwd: I-D ACTION:draft-perkins-avt-rtp-and-rtcp-mux-00.txt" beginning
with Colin's announcement 8-9-2006) on issues with the overloading of
the a=rtcp: attribute in SDP signalling when middleboxes fail to
understand the signalling. Randell urged a more explicit signalling of
the proposed use of multiplexing.

A comment by Gunnar Hellstrom (main thread) on the additional need to
multiplex different media streams over the same port to further
simplify NAT traversal generated a side discussion not related to the
specific topic of the draft. Gunnar asked that the draft make clear
that it did not cover this point.

New thread ("Comments on draft-perkins-avt-rtp-and-rtcp-mux-00.txt"
beginning 21-9-2006) initiated by Roni Even. Points made:
-- advantage of multiplexing is that RTCP messages serve as NAT
keep-alive;
-- need to address case of one-way RTP flows;
-- may be an use case for multiplexing at one end only;
-- will it be possible to move in and out of the multiplexing state
through appropriate exchange of signalling?
-- prefers that b=AS and b=TIAS just specify RTP, not RTCP bandwidth;
-- separation of RTP and RTCP on different ports facilitates network
giving of priority treatment to RTP over RTCP.
Randell Jesup responded, suggesting that one-way RTP flows did not need
special treatment, discussing the single-ended case and whether it
could happen, and agreeing that it should be possible to renegotiate
the use or non-use of multiplexing in mid-session. Colin agreed with
Randell that one-way RTP flows did not need special treatment. He was
of the opinion that symmetric use of multiplexing should be forced,
bearing in mind the problems already posed by asymmetric RTP.

In an unrelated point on the same thread, Stephan Wenger
wondered whether RTCP multiplexing would have a
negative impact on compression (RoHC). Colin responded that he would
add something on this topic in the next version of the draft.

draft-perkins-avt-rtp-and-rtcp-mux-01.txt published 25-9-2006.

Gunnar Hellstrom pronounced himself content with the clarification of
scope provided in the new version.

Randell Jesup again questioned why it was worth restricting payload
type numbers. He also noted that when a=rtcp: is returned but shows a
different port number than the RTP stream, "rejecting" the session as
required by the draft involves killing the session or doing an
UPDATE/re-INVITE. Finally, he made alternative suggestions for setting
the b=AS: value, pointing out that mid-stream devices unaware of RTCP
multiplexing would reserve too little bandwidth with the procedure
Desineni asked for clarification of Randell's comments on the QOS
issue, and Randell gave an example involving DOCSIS-controlled cable
bandwidth.

Colin responded to Randell, agreeing that the payload type restrictions
did not buy much, but suggesting areas where implementations based on
misinterpretion of the specifications might send non-compound packets.
He agreed there was a signalling problem when the far end failed to act
correctly, and this was an open issue. He was concerned that including
RTCP bandwidth in the b=AS: value as Randell suggested would break
compatibility.

Behind the scenes: agreed as a charter item (Cullen Jennings,
20-9-2006).

draft-ietf-avt-rtp-and-rtcp-mux-00.txt published 2-10-2006.

Randell Jessup (2-10-2006) continued his analysis of the proper
procedure when the far end fails to assign the same port to RTP and
RTCP. He also continued to argue for inclusion of RTCP bandwidth in the
b=AS: value. [In fact, the new -00 version and subsequent versions do
so.]

draft-ietf-avt-rtp-and-rtcp-mux-01.txt published 26-10-2006.

Colin Perkins noted (27-10-2006) that it covered:
-- implications when the device receiving the offer understands
the a=rtcp: attribute, but does not understand RTCP multiplexing;
-- expanded discussion of interactions with ICE;
-- expanded discussion of SIP forking;
-- clarified failure behaviour during offer/answer negotiation;
-- added "Interactions with Header Compression" section.


Discussion in San Diego (7-11-2006) resulted in a resolution of the
signalling issue. A new attribute would be sent in the offer to
indicate use of multiplexing (as originally proposed by Randell Jesup).
If this attribute is understood, the receiver would ignore the a=rtcp:
attribute. The latter would be restricted to a fallback role.
Discussion also examined the broader question of whether RTCP
multiplexing offered real value. It was agreed that its main value
would be in port savings on the TURN server.

draft-ietf-avt-rtp-and-rtcp-mux-02.txt published 20-11-2006.

Signalling section updated as agreed in San Diego. ICE discussion
considerably expanded. Improvements in other sections.

draft-ietf-avt-rtp-and-rtcp-mux-03.txt published 12-5-2006.

Editorial changes only.

draft-ietf-avt-rtp-and-rtcp-mux-04.txt published 8-3-2007.

Added requirement that multiplexing be done for unicast sessions only
when previously signalled. Changed SHOULD NOT to MUST NOT multiplex if
answer does not indicate acceptance of multiplexing.

Working Group Last Call announced 18-3-2007, to conclude 7-4-2007. No
comments received. Notice extended to the BEHAVE and MMUSIC Working
Groups prior to completion of this writeup. No comments received in the
ensuing week.

draft-ietf-avt-rtp-and-rtcp-mux-05.txt published 21-5-2007.

Fixed some nits.


-30-