RTP and the Datagram Congestion Control Protocol (DCCP)
draft-ietf-dccp-rtp-07

[Ballot discuss]
Holding this for Russ.

Based on the dialogue following the Gen-ART Review by Miguel Garcia:
 
  The IANA  Considerations need to clearly indicate that the
  RTP/AVP profile is using RTP on port 5004 and RTCP on port 5005
  in all three cases.

[Ballot discuss]
Based on the dialogue following the Gen-ART Review by Miguel Garcia:
 
  The IANA  Considerations need to clearly indicate that the
  RTP/AVP profile is using RTP on port 5004 and RTCP on port 5005
  in all three cases.

[Ballot discuss]
Based on the dialogue following the Gen-ART Review by Miguel Garcia:
 
  The IANA  Considerations need to clearly indicate that the
  RTP/AVP profile is using RTP on port 5004 and RTCP on port 5005
  in all three cases.

[Ballot discuss]
Based on the dialogue following the Gen-ART Review by Miguel Garcia:
 
  The IANA  Considerations ought to say:
  >
  > This memo requests IANA to add the folowing new values to the
  > 'proto' subregistry of the 'Session Description Protocol (SDP)
  > Parameters' registry:

  Also, the IANA  Considerations need to clearly indicate that the
  RTP/AVP profile is using RTP on port 5004 and RTCP on port 5005
  in all three cases.

[Ballot comment]
I remain unconvinced by the claim that DCCP partial checksums conflict
with integrity protection.  You end up with full rather than partial
integrity, but it seems like it would work interoperably.  However I
see few if any situations where you'd want to do that so have no
objection to the current text.

IANA Last Call Comments:

[ IANA Has Questions ]

Upon approval of this document, the IANA will take
the following actions:

Action 1:

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 "proto"

Type SDP Name Reference
---- ------------------ ---------
proto
DCCP [RFC-dccp-rtp-06]
DCCP/RTP/AVP [RFC-dccp-rtp-06]
DCCP/RTP/SAVP [RFC-dccp-rtp-06]
DCCP/RTP/AVPF [RFC-dccp-rtp-06]
DCCP/RTP/SAVPF [RFC-dccp-rtp-06]


Action 2:

[ The document does not specify the name of the
"SDP Attribute" registry.
It LOOKS like they mean "att-field" but the
document should specify it explicitly. It should
also specify WHICH att-field registry should be
used. It APPEARS to be "media level only" but
again the document should clarify and specify
this in the IANA Considerations section. ]

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
---- ------------------ ---------
att-field (media level only)
dccp-service-code [RFC-dccp-rtp-06]


Action 3:

[ The document does not specify the actual service
codes, only the ASCII values. The document should
explicitly state the service code values that should
be placed into the registry. Adding the descriptions
would be useful, too. ]

Upon approval of this document, the IANA will make
the following assignments in the "Service Codes"
registry located at

http://www.iana.org/assignments/service-codes

Service Code ASCII Description
Reference
--------------------- ----- -------------------------------------------------
---------

1381257281 RTPA RTP session conveying audio data
(and associated RTCP) [RFC-dccp-rtp-06]
1381257302 RTPV RTP session conveying video data
(and associated RTCP) [RFC-dccp-rtp-06]
1381257300 RTPT RTP session conveying text media
(and associated RTCP) [RFC-dccp-rtp-06]
1381257295 RTPO RTP session conveying other media
(and associated RTCP) [RFC-dccp-rtp-06]
1381253968 RTCP RTCP connection, separate from
the corresponding RTP [RFC-dccp-rtp-06]


[ Note to document authors: Please verify the
conversion from ASCII to Decimal for the above
service codes. ]

Action 4:

[ NOTE: ports 5004 and 5005 are already assigned
to avt-profile-1 and avt-profile-2, but only in
the udp/tcp frames, not in the dccp frame. ]

Upon approval of this document, the IANA will make
the following assignments in the "PORT NUMBERS"
registry located at

http://www.iana.org/assignments/port-numbers

sub-registry "REGISTERED PORT NUMBERS"

Keyword Decimal Description References
------- ------- ----------- ----------
rtp 5004/dccp dccp-rtp [RFC-dccp-rtp-06]
rtcp 5005/dccp dccp-rtcp [RFC-dccp-rtp-06]


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

PROTO Write-up

1.a) Who is the Document Shepherd for this document?

Me (Tom Phelan). Yes, I have read this version and believe it's ready
for the IESG.

1.b) Has the document had adequate review both from key WG members and
from key non-WG members?

Yes. It has had active discussion on the list and during the course of
at least the last two meetings. There has also been review from the AVT
working group.

Does the Document Shepherd have any concerns about the depth or breadth
of the reviews that have been performed?

No. The topic is well-handled in the draft and there's little
controversy.

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, there don't seem to any complications of this type.

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?

The one area of "controversy" in the document is the recommendation to
use zero-length DCCP-Data packets as keep-alives after an idle period of
15 seconds. WG discussion has decided that this is a "proper" use of
zero-length DCCP-Data packets. We've also had discussion about what the
idle period timer should be. There were several competitive proposals
to consider, but in the end we decided that the guidelines used by ICE
seemed the most appropriate.

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?

WG consensus is quite solid.

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

No.

1.g) Has the Document Shepherd personally verified that the document
satisfies all ID nits?

Yes (no errors, two warnings about outdated references -- those drafts
were updated after this one was submitted).

Has the document met all formal review criteria it needs to, such as the
MIB Doctor, media type and URI type reviews?

None necessary.

1.h) Has the document split its references into normative and
informative?

Yes.

Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?

There are two normative references in the draft state -- one is in IESG
review and the other has completed WG last call.

1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of the
document?

Yes.

If the document specifies protocol extensions, are reservations
requested in appropriate IANA registries? Are the IANA registries
clearly identified?

Yes.

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?

No new registry.

If the document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG can
appoint the needed Expert during the IESG Evaluation?

No expert review process is involved.

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?

Not my area of expertise, but the author says they pass the parser at
http://rtg.ietf.org/~fenner/abnf.cgi.

1.k) Technical Summary
The Real-time Transport Protocol (RTP) is a widely used transport for
real-time multimedia on IP networks. The Datagram Congestion Control
Protocol (DCCP) is a newly defined transport protocol that provides
desirable services for real-time applications. This memo specifies a
mapping of RTP onto DCCP, along with associated signalling, such that
real-time applications can make use of the services provided by DCCP.

Working Group Summary
The consensus within the DCCP WG to publish this document as a draft
standard RFC is strong.

Document Quality
The document is clear and the mechanisms involved are fairly
straight-forward and simple. There is believed to be at least one
implementation in progress.

Tom P.