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... Section 4.1., paragraph 4: > RTP extensions that provide application-level congestion... Nit: why is this paragraph indented? 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 areused 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.) Section 4.2., paragraph 4: > Since the nominal session bandwidth is chosen based on media... Nit: why is this paragraph indented? 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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
