5. Multiplexing RTP and RTCP on a Single Port

The procedures for multiplexing RTP and RTCP on a single port depend on whether the session is a unicast session or a multicast session. For multicast sessions, the procedures also depend on whether Any Source Multicast (ASM) or Source-Specific Multicast (SSM) is to be used.

5.1. Unicast Sessions

It is acceptable to multiplex RTP and RTCP packets on a single UDP port to ease NAT traversal for unicast sessions, provided the RTP payload types used in the session are chosen according to the rules in Section 4, and provided that multiplexing is signalled in advance. The following sections describe how such multiplexed sessions can be signalled using the Session Initiation Protocol (SIP) with the offer/answer model.

5.1.1. SDP Signalling

When the Session Description Protocol (SDP) [8] is used to negotiate RTP sessions following the offer/answer model [9], the "a=rtcp-mux" attribute (see Section 8) indicates the desire to multiplex RTP and RTCP onto a single port. The initial SDP offer MUST include this attribute at the media level to request multiplexing of RTP and RTCP on a single port. For example:

v=0
o=csp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e
s=-
c=IN IP6 2001:DB8::211:24ff:fea3:7a2e
t=1153134164 1153137764
m=audio 49170 RTP/AVP 97
a=rtpmap:97 iLBC/8000
a=rtcp-mux

This offer denotes a unicast voice-over-IP session using the RTP/AVP profile with iLBC coding. The answerer is requested to send both RTP and RTCP to port 49170 on IPv6 address 2001:DB8::211:24ff:fea3:7a2e.

If the answerer wishes to multiplex RTP and RTCP onto a single port, it MUST include a media-level "a=rtcp-mux" attribute in the answer. The RTP payload types used in the answer MUST conform to the rules in Section 4.

If the answer does not contain an "a=rtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signalled port if the "a=rtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=rtcp-mux" attribute.

When SDP is used in a declarative manner, the presence of an "a=rtcp-mux" attribute signals that the sender will multiplex RTP and RTCP on the same port. The receiver MUST be prepared to receive RTCP packets on the RTP port, and any resource reservation needs to be made including the RTCP bandwidth.

5.1.2. Interactions with SIP Forking

When using SIP with a forking proxy, it is possible that an INVITE request may result in multiple 200 (OK) responses. If RTP and RTCP multiplexing is offered in that INVITE, it is important to be aware that some answerers may support multiplexed RTP and RTCP, some not. This will require the offerer to listen for RTCP on both the RTP port and the usual RTCP port, and to send RTCP on both ports, unless branches of the call that support multiplexing are re-negotiated to use separate RTP and RTCP ports.

5.1.3. Interactions with ICE

It is common to use the Interactive Connectivity Establishment (ICE) [19] methodology to establish RTP sessions in the presence of Network Address Translation (NAT) devices or other middleboxes. If RTP and RTCP are sent on separate ports, the RTP media stream comprises two components in ICE (one for RTP and one for RTCP), with connectivity checks being performed for each component. If RTP and RTCP are to be multiplexed on the same port some of these connectivity checks can be avoided, reducing the overhead of ICE.

If it is desired to use both ICE and multiplexed RTP and RTCP, the initial offer MUST contain an "a=rtcp-mux" attribute to indicate that RTP and RTCP multiplexing is desired and MUST contain "a=candidate:" lines for both RTP and RTCP along with an "a=rtcp:" line indicating a fallback port for RTCP in the case that the answerer does not support RTP and RTCP multiplexing. This MUST be done for each media where RTP and RTCP multiplexing is desired.

If the answerer wishes to multiplex RTP and RTCP on a single port, it MUST generate an answer containing an "a=rtcp-mux" attribute and a single "a=candidate:" line corresponding to the RTP port (i.e., there is no candidate for RTCP) for each media where it is desired to use RTP and RTCP multiplexing. The answerer then performs connectivity checks for that media as if the offer had contained only a single candidate for RTP. If the answerer does not want to multiplex RTP and RTCP on a single port, it MUST NOT include the "a=rtcp-mux" attribute in its answer and MUST perform connectivity checks for all offered candidates in the usual manner.

On receipt of the answer, the offerer looks for the presence of the "a=rtcp-mux" line for each media where multiplexing was offered. If this is present, then connectivity checks proceed as if only a single candidate (for RTP) were offered, and multiplexing is used once the session is established. If the "a=rtcp-mux" line is not present, the session proceeds with connectivity checks using both RTP and RTCP candidates, eventually leading to a session being established with RTP and RTCP on separate ports (as signalled by the "a=rtcp:" attribute).

5.1.4. Interactions with Header Compression

Multiplexing RTP and RTCP packets onto a single port may negatively impact header compression schemes, for example, Compressed RTP (CRTP) [20] and RObust Header Compression (ROHC) [21] [22]. Header compression exploits patterns of change in the RTP headers of consecutive packets to send an indication that the packet changed in the expected way, rather than sending the complete header each time. This can lead to significant bandwidth savings if flows have uniform behaviour.

The presence of RTCP packets multiplexed with RTP data packets can disrupt the patterns of change between headers and has the potential to significantly reduce header compression efficiency. The extent of this disruption depends on the header compression algorithm used and on the way flows are classified. A well-designed classifier should be able to separate RTP and RTCP multiplexed on the same port into different compression contexts, using the payload type field, such that the effect on the compression ratio is small. A classifier that assigns compression contexts based only on the IP addresses and UDP ports will not perform well. It is expected that implementations of header compression will need to be updated to efficiently support RTP and RTCP multiplexed on the same port.

This effect of multiplexing RTP and RTCP on header compression may be especially significant in those environments, such as some wireless telephony systems, that rely on the efficiency of header compression to match the media to a limited-capacity channel. The implications of multiplexing RTP and RTCP should be carefully considered before use in such environments.

5.2. Any Source Multicast Sessions

The problem of NAT traversal is less severe for Any Source Multicast (ASM) RTP sessions than for unicast RTP sessions, and the benefit of using separate ports for RTP and RTCP is greater due to the ability to support third-party RTCP-only monitors. Accordingly, RTP and RTCP packets SHOULD NOT be multiplexed onto a single port when using ASM RTP sessions and SHOULD instead use separate ports and multicast groups.

5.3. Source-Specific Multicast Sessions

RTP sessions running over Source-Specific Multicast (SSM) send RTCP packets from the source to receivers via the multicast channel, but use a separate unicast feedback mechanism [6] to send RTCP from the receivers back to the source, with the source either reflecting the RTCP packets to the group or sending aggregate summary reports.

Following the terminology of [6], we identify three RTP/RTCP flows in an SSM session:

1. RTP and RTCP flows between media sender and distribution source. In many scenarios, the media sender and distribution source are co-located, so multiplexing is not a concern. If the media sender and distribution source are connected by a unicast connection, the rules in Section 5.1 of this memo apply to that connection. If the media sender and distribution source are connected by an Any Source Multicast connection, the rules in Section 5.2 apply to that connection. If the media sender and distribution source are connected by a Source-Specific Multicast connection, the RTP and RTCP packets MAY be multiplexed on a single port, provided this is signalled (using "a=rtcp-mux" if using SDP).

2. RTP and RTCP sent from the distribution source to the receivers. The distribution source MAY multiplex RTP and RTCP onto a single port to ease NAT traversal issues on the forward SSM path, although doing so may hinder third-party monitoring devices if the session uses the simple feedback model. When using SDP, the multiplexing SHOULD be signalled using the "a=rtcp-mux" attribute.

3. RTCP sent from receivers to distribution source. This is an RTCP-only path, so multiplexing is not a concern.

Multiplexing RTP and RTCP packets on a single port in an SSM session has the potential for interactions with header compression described in Section 5.1.4.