RTCP Multiplexing

RTCP-MUX multiplexes RTP media packets and RTCP control packets onto a single UDP port instead of using separate ports for each. This is defined in RFC 5761 and is the standard transport mode for modern VoIP and WebRTC systems.

Why Use RTCP-MUX

Without RTCP-MUX, each media stream requires two UDP ports — one for RTP (even-numbered) and one for RTCP (odd-numbered, RTP port + 1). For a test with 500 endpoints, each with one audio and one video track, that means 2,000 UDP ports allocated on the worker.

With RTCP-MUX enabled, each media stream uses a single port for both RTP and RTCP. The same 500-endpoint test uses 1,000 ports — half as many. This reduces:

• Port exhaustion risk on workers and firewalls
• NAT binding count (fewer entries in NAT translation tables)
• Firewall rule complexity (one port per stream instead of two)

RTCP-MUX is also a prerequisite for DTLS-SRTP, which runs the DTLS handshake on the same port as RTP media.

How to Enable

RTCP-MUX is configured per media track in the test creation form:

1. Open the track's Advanced section (click the caret below codec selection)
2. Check RTCP-MUX to enable single-port multiplexing for that track

When enabled, the SDP offer includes the a=rtcp-mux attribute on the corresponding media line.

SDP Behavior

Offer (RTCP-MUX enabled)

m=audio 10000 RTP/AVP 0
a=rtcp-mux
a=rtpmap:0 PCMU/8000

When a=rtcp-mux is present, the answering endpoint should respond with a=rtcp-mux in its answer to confirm multiplexing. Both RTP and RTCP then flow over port 10000.

Offer (RTCP-MUX disabled)

m=audio 10000 RTP/AVP 0
a=rtcp:10001
a=rtpmap:0 PCMU/8000

Without RTCP-MUX, RTP uses port 10000 and RTCP uses port 10001.

Packet Demultiplexing

When RTCP-MUX is active, the endpoint distinguishes RTP from RTCP using the second byte of each packet. RTP payload types (0-127) do not overlap with RTCP packet types (200-211), so the receiver can reliably classify every packet without ambiguity.

Hold Connection Maintenance (RFC 8858)

When a call is placed on hold with RTCP-MUX enabled, the endpoint continues sending RTCP Sender Reports to maintain the port binding. This prevents NAT devices and firewalls from expiring the binding during hold, which would cause media failure when the call resumes.

This behavior follows RFC 8858 (Indicating Exclusive Support of RTP and RTP Control Protocol Multiplexing) and is automatic — no additional configuration is needed.

Metrics Impact

RTCP-MUX does not change which metrics are collected or their values. All RTCP-based metrics (jitter, round-trip time, packet loss from Receiver Reports) are collected identically whether RTCP arrives on a dedicated port or multiplexed with RTP.

Next Steps

• SDES-SRTP — Add media encryption via SDP key exchange
• DTLS-SRTP — Add media encryption via DTLS handshake (requires RTCP-MUX)
• Advanced Track Settings — DSCP marking and deferred track negotiation