[Inline; Jonathan - see ICE discussion below]
On 10 May 2007, at 18:36, Lars Eggert wrote:
On 2007-5-3, at 5:34, ext Phelan, Tom wrote:
This is to announce the beginning of a working group last call for
draft-ietf-dccp-rtp-05.txt, "RTP and the Datagram Congestion Control
Protocol (DCCP)" (available at
http://www.ietf.org/internet-drafts/draft-ietf-dccp-rtp-05.txt.
I've done an early AD review of this document. Overall, it's in
great shape and should move on quickly. I have two questions/
suggestions and there are a few nits.
Lars
Section 4.1., paragraph 2:
> A DCCP connection is opened when an end system joins an RTP
session,
> and it remains open for the duration of the session. To
ensure NAT
> bindings are kept open, an end system SHOULD send a zero
length DCCP-
> Data packet once every 15 seconds during periods when it has
no other
> data to send. This removes the need for RTP no-op packets
[18], and
> similar application level keep-alives, when using RTP over DCCP.
> This application level keepalive does not need to be sent if
it is
> known that the DCCP CCID in use provides a transport level
keepalive.
15 seconds is pretty short. RFC4787 (NAT UDP Unicast Requirements)
says that "a NAT UDP mapping timer MUST NOT expire in less than two
minutes". If we assume that DCCP will be treated similarly to UDP, a
longer keep-alive interval may be sufficient. (The BEHAVE timeout
requirement for TCP is longer still.) And yes, someone should write
BEHAVE documents for DCCP and SCTP...
The 15 second value was chosen to match the default keep alive timer
in ICE. If it's too short, we should probably change ICE also.
Section 4.1., paragraph 4:
> RTP extensions that provide application-level congestion...
Nit: why is this paragraph indented?
Hold-over from a note in previous versions. I'll de-indent it.
Section 4.2., paragraph 1:
> The RTP Control Protocol (RTCP) is used in the standard manner
with
> DCCP. RTCP packets are grouped into compound packets, as
described
> in Section 6.1 of [1], and each compound RTCP packet is
transported
> in a single DCCP datagram.
It may be worth pointing out that DCCP imposes MTU restrictions
(Section 14 of RFC4340), which may not be obvious to folks who are
used to RTP over UDP. (To my understanding - and that may be off
- RTP
says nothing much about staying within the MTU, but it has been
recommended in payload specifications.)
The RTP specification talks about this (RFC 3550, section 6.1, top of
page 23), so I don't think anything needs to be added.
Section 4.2., paragraph 4:
> Since the nominal session bandwidth is chosen based on
media...
Nit: why is this paragraph indented?
It's an aside, and should probably start with the word "Note:".
Section 9.2., paragraph 7:
> [21] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie,
"Real-
> Time Transport Protocol (RTP) Payload Format and File
Storage
> Format for the Adaptive Multi-Rate (AMR) and Adaptive
Multi-
> Rate Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002.
Nit: Obsoleted by RFC 4867
Yep, I know and will fix (RFC 4867 was published after I submitted
this draft...).
Colin
