Dan,
On 8 Jun 2007, at 18:38, Dan Wing wrote:
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.
Yes - I'll clarify.
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)).
I tend to prefer explicit to implicit, so while this would reduce the
size of the SDP slightly, I'm not sure it's worthwhile.
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.
The service codes sent in the DCCP packets are the 4-character ASCII
strings listed (e.g. RTPV).
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.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Makes sense - I'll add this.
Cheers,
--
Colin Perkins
http://csperkins.org/
