Multiplexing RTP Data and Control Packets on a Single Port
updated by
- rfc-8035 — Session Description Protocol (SDP) Offer/Answer Clarifications for RTP/RTCP Multiplexing
- rfc-8858 — Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP) Multiplexing Using the Session Description Protocol (SDP)
updates
Extracted elements (22)
RTP and RTCP were originally assigned separate UDP ports for three reasons: simplicity (clean separation of data and control planes), efficiency (demultiplexing at a single transport layer point), and support for third-party monitors in multicast sessions that can receive RTCP without access to data packets.
The restriction against using RTP payload types outside 72-73 (not just those two) when multiplexing is due to RFC 5506, which allows non-compound RTCP packets in some circumstances. Without this broader restriction, a non-compound RTCP packet of any type in the range 64-95 could be mistaken for an RTP data packet.
With increased NAT deployment, the original two-port design became a liability requiring complex signalling to open multiple NAT pinholes. RTP/RTCP multiplexing onto a single UDP port trades some implementation simplicity for easier NAT traversal.
Known RTP payload type / RTCP packet type conflicts exist: PT 64-65 conflict with obsolete RTCP FIR/NACK; PT 72-76 conflict with RTCP SR, RR, SDES, BYE, APP; PT 77-78 conflict with RTCP RTPFB and PSFB; PT 79 conflicts with RTCP XR; PT 80 conflicts with RSI packets. These ranges are blocked for use when multiplexing.
Multiplexing RTP and RTCP on a single port can disrupt header compression (CRTP, ROHC) by breaking the expected header change patterns. A classifier that assigns compression contexts based only on IP addresses and UDP ports will not perform well; classifiers should use the payload type field to separate RTP and RTCP into different compression contexts.
The multiplexing of several different media types (e.g., audio and video) onto a single port is explicitly out of scope for this memo; RFC 5761 addresses only multiplexing RTP data and RTCP control packets for a single media type onto one port.
When SIP forking results in multiple 200 OK responses to an INVITE that offers RTP/RTCP multiplexing, some answerers may support multiplexing and some may not. The offerer must listen and send RTCP on both the RTP port and the usual RTCP port until call branches are re-negotiated.
An ICE answerer that wishes to multiplex MUST generate an answer with 'a=rtcp-mux' and only a single 'a=candidate:' line for the RTP port (no RTCP candidate) per multiplexed media. If not wishing to multiplex, it MUST NOT include 'a=rtcp-mux' and MUST perform connectivity checks for all offered candidates.
Any QoS reservation for a multiplexed RTP/RTCP stream SHOULD be made for 105% of the SDP 'b=AS:' value to account for RTCP's standard 5% bandwidth allocation. If non-standard RTCP bandwidth fractions are signalled via 'b=RR:' and 'b=RS:', the reservation SHOULD equal AS + RS + RR.
For Any Source Multicast (ASM) RTP sessions, RTP and RTCP packets SHOULD NOT be multiplexed onto a single port; they SHOULD instead use separate ports and multicast groups to preserve third-party monitoring capability.
For Source-Specific Multicast (SSM), the distribution source MAY multiplex RTP and RTCP onto a single port on the forward SSM path, though doing so may hinder third-party monitoring in the simple feedback model. Multiplexing between media sender and distribution source follows unicast or ASM rules depending on connection type.
Future RTCP packet type assignments SHOULD be made from the range 209-223 first, then 194-199, so that only payload types 64-95 are blocked when multiplexing. Ranges 1-191 and 224-254 SHOULD only be used when other values are exhausted.
If an answerer wishes to multiplex RTP and RTCP onto a single port, it MUST include a media-level 'a=rtcp-mux' attribute in the answer, and RTP payload types used in the answer MUST conform to the conflict-avoidance rules in Section 4.
If both ICE and RTP/RTCP multiplexing are desired, the initial offer MUST contain 'a=rtcp-mux', candidate lines for both RTP and RTCP, and an 'a=rtcp:' fallback port for each multiplexed media stream.
To request RTP/RTCP multiplexing, the initial SDP offer MUST include the 'a=rtcp-mux' attribute at the media level. If the answer does not contain 'a=rtcp-mux', the offerer MUST NOT multiplex RTP and RTCP on a single port.
When multiplexing RTP and RTCP on a single port, RTP payload type values in the range 64-95 MUST NOT be used. Dynamic RTP payload types SHOULD be chosen in the range 96-127 where possible.
When SDP is used declaratively, the receiver of an 'a=rtcp-mux' attribute MUST be prepared to receive RTCP packets on the RTP port, and any resource reservation must include the RTCP bandwidth.
When RTP and RTCP are multiplexed on a single port, demultiplexing uses the second octet of the packet, which in RTP encodes the M bit and payload type (PT), and in RTCP encodes the packet type. Two constraints must hold: PT values used must not conflict with RTCP packet types, and PT+128 must also not conflict.
IANA registered a new SDP media-level attribute 'rtcp-mux' (long form: 'RTP and RTCP multiplexed on one port'). It is a property attribute that takes no value and signals that RTP and RTCP traffic should be multiplexed on a single port.
The rules for assignment of RTCP Control Packet Types in the RTP Parameters registry are updated: IANA should assign values from 200-223 first, then 194-199, then 1-191 and 224-254. Values 0 and 255 are avoided to improve validity checking against random packets.
Multiplexing RTP and RTCP is not believed to introduce new security considerations. The primary concerns remain integrity and authentication of the multiplexing signalling, and integrity, authentication, and confidentiality of RTP/RTCP traffic, which are addressed by the base RTP spec and applicable profiles.
When SRTP is used with multiplexed RTP and RTCP, multiplexing MUST be performed below the SRTP layer. The sender generates SRTP and SRTCP packets independently using their separate cryptographic contexts and multiplexes them immediately before transmission. The receiver derives cryptographic context from SSRC, destination address, and port, then uses payload type / RTCP packet type to demultiplex before cryptographic processing.