On 2007-5-11, at 1:16, ext Colin Perkins wrote:
On 10 May 2007, at 18:36, Lars Eggert wrote: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 twominutes". If we assume that DCCP will be treated similarly to UDP, alonger 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.
Agreed. It would be good to behave uniformly here across protocols.
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 - RTPsays 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.
To me - and I'm no RTP expert - that text talks about RTCP, i.e., the control channel. Are MTU issues for the data channel discussed in the individual payload descriptions?
(In any event, this is probably a corner case, of where someone wants to migrate an RTP payload format that uses large packets that require UDP fragmentation over to DCCP, and will be surprised by DCCP's stricter MTU rules.)
Lars
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
