RTP and the Datagram Congestion Control Protocol (DCCP)
updated by
- rfc-6773 — DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal
Extracted elements (30)
DCCP is preferred over TCP for RTP because TCP's reliable delivery and its congestion control dynamics make it inappropriate for most interactive real-time applications. DCCP offers unreliable delivery with a choice of congestion control algorithms, allowing applications to tailor transport to their needs.
Multiplexing RTP and RTCP onto a single DCCP connection is recommended because large telephony gateways can exhaust UDP ports (needing more than 32768 flows), and multiple ports complicate NAT traversal. DCCP exacerbates this since the naive mapping requires two connections per RTP flow.
End systems SHOULD NOT assume a single RTP SSRC when using DCCP framing. A unicast DCCP connection does not imply a two-party RTP session; RTP mixers and translators may introduce multiple synchronisation sources.
The RTP/SAVP integrity protection (message authentication) cannot be used in conjunction with DCCP partial checksums, since any bit error in the payload will cause authentication to fail. These two features are mutually exclusive.
The semantics of the RTP sequence number and the DCCP sequence number are not compatible, and the value of one cannot be inferred from the other. Header processing is not affected by DCCP framing.
There can be overlap between RTCP Loss RLE Report Blocks (RFC 3611) and the DCCP Ack Vector option. Using both simultaneously wastes capacity but is not otherwise harmful; applications should choose one mechanism.
A parser for the 'dccp-service-code' SDP attribute MUST interpret service codes according to their numeric value, independent of the format (hexadecimal, decimal, or ASCII) used to represent them in SDP.
Each RTP data packet MUST be conveyed in a single DCCP datagram. Fields in the RTP header MUST be interpreted according to the RTP specification and any applicable RTP profile and payload format.
If DCCP connection capacity falls significantly below the nominal session bandwidth causing RTCP delays, the session parameters SHOULD be re-negotiated to more closely match available capacity (e.g., via a SIP re-invite with an updated 'b=' line).
If DCCP partial checksums are enabled, the checksum MUST cover at least the DCCP and RTP headers to ensure correct delivery. Partial checksums MUST NOT be used unless supported by mechanisms in the RTP payload format.
If there is overlap between RTCP report packets and DCCP acknowledgements (e.g., RTCP Loss RLE and DCCP Ack Vector), an application SHOULD use either RTCP feedback or DCCP acknowledgements but not both, to avoid wasting network capacity.
It is RECOMMENDED that RTP and RTCP traffic for a single RTP session be multiplexed onto a single DCCP connection following RFC 5761, to reduce port usage and simplify NAT traversal.
Multiplexed RTP and RTCP on a single DCCP connection MUST be signalled using 'a=rtcp-mux'. If not multiplexing, 'a=rtcp-mux' MUST NOT be present in the SDP offer and a separate DCCP connection MUST be opened for RTCP.
RTCP packets MUST obey the DCCP congestion control algorithm negotiated for the connection. If there is insufficient capacity at the RTCP transmission timer expiry, the RTCP packet is delayed until capacity is available.
RTP data packets MUST obey the dictates of DCCP congestion control. Applications may use rate-adaptive payload formats or switch to lower-rate formats when the congestion control requires sending below the payload format's natural rate.
RTP extensions that provide application-level congestion control MUST NOT be used when running RTP over DCCP, as they will conflict with DCCP's own congestion control.
RTP payload formats used with the DCCP/RTP/* protocol identifiers MUST use the payload type number as their 'fmt' value. If dynamically assigned, an additional 'rtpmap' attribute MUST be included.
RTP profiles that are intolerant of packet corruption or mandate a non-DCCP lower-layer transport SHOULD NOT be used with DCCP unless conflicting features can be disabled.
The 'a=setup:' attribute MUST be used comparably with RFC 4145 to indicate which endpoint initiates the DCCP connection. The 'a=connection:' attribute MUST be used compatibly with RFC 4145 to manage connection reuse on re-negotiation.
The 'DCCP' SDP proto identifier MUST NOT be used to signal RTP sessions running over DCCP; those sessions MUST use a protocol identifier of the form 'DCCP/RTP/...'.
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 when using RTP over DCCP.
A new SDP media-level attribute 'a=dccp-service-code:' is defined to signal the DCCP service code for an RTP session. The attribute is not subject to the charset attribute and supports hexadecimal, decimal, or ASCII service code encoding.
Five DCCP service codes are defined for RTP: SC:RTPA (audio), SC:RTPV (video), SC:RTPT (text), SC:RTPO (other media), and SC:RTCP (RTCP-only connection). Applications SHOULD use these to identify RTP sessions for middlebox benefit.
Five SDP 'm=' proto field values are defined for RTP over DCCP: 'DCCP' (generic), 'DCCP/RTP/AVP', 'DCCP/RTP/SAVP', 'DCCP/RTP/AVPF', and 'DCCP/RTP/SAVPF', corresponding to the respective RTP profiles running over DCCP.
A new SDP attribute 'dccp-service-code' is registered as a media-level attribute not subject to charset, for signalling DCCP service codes in RTP sessions.
Five DCCP service code values are registered: 1381257281 (RTPA/audio), 1381257302 (RTPV/video), 1381257300 (RTPT/text), 1381257295 (RTPO/other), 1381253968 (RTCP/control-only). DCCP ports 5004 and 5005 are also registered for DCCP transport.
Five SDP 'proto' field identifiers are registered: DCCP, DCCP/RTP/AVP, DCCP/RTP/SAVP, DCCP/RTP/AVPF, and DCCP/RTP/SAVPF, all referencing RFC 5762.
DCCP partial checksums SHOULD NOT be used in conjunction with SRTP authentication. Message authentication codes cannot tolerate bit errors in the payload, and SRTP profiles require authentication for security even when using AES counter mode.
The provision of effective congestion control for RTP through DCCP is expected to reduce the potential for denial of service present when RTP flows ignore the RFC 3551 guidance to monitor packet loss and reduce sending rate under persistent congestion.
The 'dccp-service-code' SDP attribute uses ABNF syntax allowing the service code in hex (SC=x...), decimal (SC=...), or ASCII (SC:...) formats. The numeric value is canonical; all three representations are equivalent.