Last Call: draft-ietf-dccp-rtp (RTP and the DatagramCongestion Control Protocol (DCCP)) to Proposed Standard
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Last Call: draft-ietf-dccp-rtp (RTP and the DatagramCongestion Control Protocol (DCCP)) to Proposed Standard



The draft is easy to read and understand.

1. Section 5.2, "Service Codes", refers to DCCP service codes.  Several are
defined in this specification (SC:RTPA, SC:RTPV, SC:RTPT, and SC:RTPO).  The
draft needs to say something about the relationship between the SDP media
type field (the "audio" and "video" of m=audio and m=video) and the DCCP
service code -- I expect they SHOULD match.  

2. I wonder if an optimization would be useful, where
"a=dccp-service-code:SC:RTPV" is assumed if the associated media type is
"video" (m=video); a similar optimization seems reasonable for audio (RTPA
is assumed when the media type is audio (m=audio)).

3. I believe the draft needs to define a value for its IANA-registered DCCP
service codes, as service codes appear to be sent in the DCCP packets
themselves according to RFC4340.

4. I'm surprised a=rtcp (RFC3605) lacked normative language in section 5.1.
I know for UDP this is widely considered best practice.  I'm not confident
that we should expect DCCP will be able to avoid that quagmire.  I suggest
adding something like:

   If RTCP is to be sent on a separate DCCP connection
   to RTP, the RTCP connection SHOULD use the next higher destination
   port number, unless an alternative DCCP port is signalled using the
   "a=rtcp:" attribute [13].  For improved interoperability, "a=rtcp" 
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   SHOULD be used whenever an alternative DCCP port is used.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

-d

> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy at cisco.com] 
> Sent: Thursday, June 07, 2007 1:31 PM
> To: MMUSIC WG
> Subject: [MMUSIC] Fwd: Last Call: draft-ietf-dccp-rtp (RTP 
> and the DatagramCongestion Control Protocol (DCCP)) to 
> Proposed Standard 
> 
> 
> I would like to point out this last call is happening - if you have  
> opinions on the SDP usage in this draft - do not reply to 
> this email.  
> Reply on the IETF list.
> 
> 
> Begin forwarded message:
> 
> > From: The IESG <iesg-secretary at ietf.org>
> > Date: June 6, 2007 7:18:36 AM PDT
> > To: IETF-Announce <ietf-announce at ietf.org>
> > Cc: dccp at ietf.org
> > Subject: Last Call: draft-ietf-dccp-rtp (RTP and the Datagram  
> > Congestion  Control Protocol (DCCP)) to Proposed Standard
> > Reply-To: ietf at ietf.org
> >
> > The IESG has received a request from the Datagram Congestion Control
> > Protocol WG (dccp) to consider the following document:
> >
> > - 'RTP and the Datagram Congestion Control Protocol (DCCP) '
> >    <draft-ietf-dccp-rtp-06.txt> as a Proposed Standard
> >
> > The IESG plans to make a decision in the next few weeks, 
> and solicits
> > final comments on this action.  Please send substantive 
> comments to  
> > the
> > ietf at ietf.org mailing lists by 2007-06-20. Exceptionally,
> > comments may be sent to iesg at ietf.org instead. In either 
> case, please
> > retain the beginning of the Subject line to allow automated sorting.
> >
> > The file can be obtained via
> > http://www.ietf.org/internet-drafts/draft-ietf-dccp-rtp-06.txt
> >
> >
> > IESG discussion can be tracked via
> > https://datatracker.ietf.org/public/pidtracker.cgi? 
> > command=view_id&dTag=15015&rfc_flag=0
> >
> >
> > _______________________________________________
> > IETF-Announce mailing list
> > IETF-Announce at ietf.org
> > https://www1.ietf.org/mailman/listinfo/ietf-announce
> 
> _______________________________________________
> mmusic mailing list
> mmusic at ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf




Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.