Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP

defines how to multiplex RTP and RTCP on a single port, referred to as RTP/RTCP multiplexing. also defines an Session Description Protocol (SDP) attribute, 'rtcp-mux' that can be used by entities to indicate support of RTP/RTCP multiplexing. As defined in , if the peer endpoint does not support RTP/RTCP multiplexing, there must be a fallback to usage of separate ports for RTP and RTCP. However, the RTCWEB WG have defined that support of the fallback is optional. Therefore, there needs to be a mechanism for an endpoint to be able to indicate exclusive support of RTP/RTCP multiplexing, i.e. to be able to indicate that the endpoint only supports RTP/RTCP multiplexing and is not able to fallback to usage of separate ports for receiving RTP and RTCP. This document describes a mechanism, how the SDP 'rtcp-mux' attribute and the SDP 'rtcp' attribute can be used to indicate exclusive support of RTP/RTCP multiplexing. The document updates sections 5.1.1 and 5.1.3 of in order to enable usage of the mechanism. The document also describes the Interactive Connectivity Establishment (ICE) considerations when indicating exclusive support of RTP/RTCP multiplexing.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

As as described in , when an offerer sends an offer, and wants to indicate support of RTP/RTCP multiplexing, it must associate an SDP 'rtcp-mux' attribute with each RTP-based SDP media description ("m=" line) for which support of multiplexing is indicated. In addition, the offerer may assign an SDP 'rtcp' attribute, in order to provide a fallback port for RTCP in case the answerer does not support (or is not willing to use) RTP/RTCP multiplexing. When an offerer sends an offer, and wants to indicate exclusive support of RTP/RTCP multiplexing it MUST, in addition to the SDP 'rtcp-attribute, associate an SDP 'rtcp' attribute with each SDP media description for which exclusive support of RTP/RTCP multiplexing is indicated. The offerer MUST assign a port value identical to the port value of the associated SDP media description to the 'rtcp' attribute. The offerer MAY assign the optional IP address part to the 'rtcp' attribute. If assigned, the IP address part value MUST be identical to the value of the associated connection address ("c=" line).

This section updates sections 5.1.1 and 5.1.3 of , by adding a new paragraph in section 5.1.1 after the second paragraph, and by modifying the second paragraph in section 5.1.3.

ISSUE #1: We may want to specify an explicit procedure for the answerer too, saying that it must select mux if it receives rtcp-mux and rtcp with the RTP port value. ISSUE #2: We may want to specify something about the case when the answerer only supports mux, and receives an offer without mux.

As defined in , if an entity is aware that the remote peer supports, and is willing to use, RTP/RTCP multiplexing, the entity will only provide RTP candidates (component ID 1). However, only providing RTP candidates does not as such imply exclusive support of RTP/RTCP multiplexing. RTCP candidates would not be provided also in cases where RTCP is not supported at all. Therefore, additional information is needed in order to indicate support of exclusive RTP/RTCP multiplexing. This document defines such mechanism using the SDP 'rtcp-mux' and 'rtcp' attributes.

This document does not introduce new security considerations in additions to those specified in and .

This document makes no requests from IANA.

Thanks to Roman Shpount, Paul Kyzivat, Ari Keränen, Bo Burman and Tomas Frankkila for their comments and input on the draft.

[RFC EDITOR NOTE: Please remove this section when publishing] Changes from draft-holmberg-mmusic-mux-exclusive-01 Clarified that the SDP rtcp attribute may contain the optional IP address part. Changes from draft-holmberg-mmusic-mux-exclusive-00 Additional updates to Section 5.1.1 of RFC 5761. ICE considerations added.