diff options
Diffstat (limited to 'doc/rfc/rfc8858.txt')
| -rw-r--r-- | doc/rfc/rfc8858.txt | 458 |
1 files changed, 458 insertions, 0 deletions
diff --git a/doc/rfc/rfc8858.txt b/doc/rfc/rfc8858.txt new file mode 100644 index 0000000..7a350f6 --- /dev/null +++ b/doc/rfc/rfc8858.txt @@ -0,0 +1,458 @@ + + + + +Internet Engineering Task Force (IETF) C. Holmberg +Request for Comments: 8858 Ericsson +Updates: 5761 January 2021 +Category: Standards Track +ISSN: 2070-1721 + + + Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP) + Multiplexing Using the Session Description Protocol (SDP) + +Abstract + + This document defines a new Session Description Protocol (SDP) media- + level attribute, 'rtcp-mux-only', that can be used by an endpoint to + indicate exclusive support of RTP and RTP Control Protocol (RTCP) + multiplexing. The document also updates RFC 5761 by clarifying that + an offerer can use a mechanism to indicate that it is not able to + send and receive RTCP on separate ports. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8858. + +Copyright Notice + + Copyright (c) 2021 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 2. Conventions + 3. SDP 'rtcp-mux-only' Attribute + 4. SDP Offer/Answer Procedures + 4.1. General + 4.2. Generating the Initial SDP Offer + 4.3. Generating the Answer + 4.4. Offerer Processing of the SDP Answer + 4.5. Modifying the Session + 5. Update to RFC 5761 + 5.1. General + 5.2. Update to 4th Paragraph of Section 5.1.1 + 5.3. Update to 2nd Paragraph of Section 5.1.3 + 6. ICE Considerations + 7. Security Considerations + 8. IANA Considerations + 9. References + 9.1. Normative References + 9.2. Informative References + Acknowledgements + Author's Address + +1. Introduction + + [RFC5761] defines how to multiplex RTP and RTCP on a single IP + address and port, referred to as RTP/RTCP multiplexing. [RFC5761] + also defines an SDP [RFC4566] attribute, 'rtcp-mux', that can be used + by entities to indicate support of RTP/RTCP multiplexing and + negotiate usage of it. + + As defined in [RFC5761], if the peer endpoint does not support RTP/ + RTCP multiplexing, both endpoints should use separate ports for + sending and receiving of RTCP (referred to as fallback to usage of + separate ports for RTP and RTCP). + + Some newer applications that do not require backward compatibility + with peers that cannot multiplex RTCP might choose not to implement + separation of RTP and RTCP. Examples of such applications are W3C + WebRTC applications [WebRTC], which are not required to interoperate + with non-WebRTC clients. For such applications, this document + defines an SDP attribute to signal intent to require multiplexing. + The use of this attribute in SDP offers [RFC3264] may harm the + interoperability of entities that ever need to interoperate with + peers that do not support RTC/RTCP multiplexing. Also, while the SDP + answerer [RFC3264] might support, and prefer usage of, fallback to + nonmultiplex, the attribute indicates that fallback to nonmultiplex + cannot be enabled. One example of where nonmultiplex is preferred is + where an endpoint is connected to a radio interface and wants to use + different bearers (possibly with different quality characteristics) + for RTP and RTCP. Another example is where one endpoint is acting as + a gateway to a network where RTP/RTCP multiplexing cannot be used. + In such a case, the endpoint may also prefer nonmultiplexing towards + the other network. Otherwise, the endpoint would have to perform + demultiplexing of RTP and RTCP. + + This document defines a new SDP media-level attribute, 'rtcp-mux- + only', that can be used by an endpoint to indicate exclusive support + of RTP/RTCP multiplexing. The document also updates [RFC5761] by + clarifying that an offerer can use a mechanism to indicate that it is + not able to send and receive RTCP on separate ports. + + This document also describes the Interactive Connectivity + Establishment (ICE) [RFC8445] considerations when indicating + exclusive support of RTP/RTCP multiplexing. + +2. Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +3. SDP 'rtcp-mux-only' Attribute + + This section defines a new SDP media-level attribute, 'rtcp-mux- + only'. + + Name: rtcp-mux-only + + Value: N/A + + Usage Level: media + + Charset Dependent: no + + Syntax: rtcp-mux-only + + Example: a=rtcp-mux-only + + In an SDP offer, the offerer uses the SDP 'rtcp-mux-only' attribute + to indicate exclusive support of RTP/RTCP multiplexing for the RTP- + based media associated with the SDP media description ("m=" line). + + In an SDP answer, the 'rtcp-mux' attribute [RFC5761] indicates that + the answerer supports, and accepts usage of, RTP/RTCP multiplexing + for the RTP-based media associated with the SDP media description + ("m=" line). + + The usage of the 'rtcp-mux-only' attribute in an SDP answer is + forbidden. + + The usage of the SDP 'rtcp-mux-only' attribute is only defined for + RTP-based media. + + The mux category [RFC8859] for the 'rtcp-mux-only' attribute is + "IDENTICAL", which means that the attribute, if used within a BUNDLE + group [RFC8843], must be associated with all multiplexed RTP-based + media descriptions within the BUNDLE group. + + The 'rtcp-mux-only' attribute applies to the whole associated media + description. The attribute MUST NOT be defined per source (using the + SDP 'ssrc' attribute [RFC5576]). + + The SDP offer/answer procedures [RFC3264] associated with the + attribute are defined in Section 4. + +4. SDP Offer/Answer Procedures + +4.1. General + + This section defines the SDP offer/answer procedures [RFC3264] for + indicating exclusive support of RTP/RTCP multiplexing and negotiating + usage of it. + + The procedures in this section apply to individual RTP-based SDP + media descriptions ("m=" lines). + +4.2. Generating the Initial SDP Offer + + When sending the initial offer, if the offerer wants to indicate + exclusive RTP/RTCP multiplexing for RTP-based media, it MUST + associate an SDP 'rtcp-mux-only' attribute with the associated SDP + media description ("m=" line). + + In addition, if the offerer associates an SDP 'rtcp-mux-only' + attribute with an SDP media description ("m=" line), the offerer MUST + also associate an SDP 'rtcp-mux' attribute with the same SDP media + description ("m=" line), following the procedures in [RFC5761]. + + If the offerer associates an SDP 'rtcp' attribute [RFC3605] with an + SDP media description ("m=" line), and if the offerer also associates + an SDP 'rtcp-mux-only' attribute with the same SDP media description + ("m=" line), the address and port values of the SDP 'rtcp' attribute + MUST match the corresponding values for RTP. + + NOTE: This specification does not mandate the usage of the SDP 'rtcp' + attribute for RTP/RTCP multiplexing. + +4.3. Generating the Answer + + When an answerer receives an offer that contains an SDP 'rtcp-mux- + only' attribute associated with an RTP-based SDP media description + ("m=" line), then if the answerer accepts the usage of RTP/RTCP + multiplexing, it MUST associate an SDP 'rtcp-mux' attribute with the + corresponding SDP media description ("m=") in the associated answer, + following the procedures in [RFC5761]. If the answerer does not + accept the usage of RTP/RTCP multiplexing, it MUST either reject the + SDP media description ("m=") by setting the port value to zero in the + associated answer, or reject the whole offer, following the + procedures in [RFC3264]. + + The answerer MUST NOT associate an SDP 'rtcp-mux-only' attribute with + an SDP media description ("m=" line) in the answer. + +4.4. Offerer Processing of the SDP Answer + + If an offerer associated an SDP 'rtcp-mux-only' attribute with an + RTP-based SDP media description ("m=" line) in an offer, and if the + corresponding SDP media description ("m=" line) in the associated + answer contains an SDP 'rtcp-mux' attribute, the offerer MUST apply + the RTP/RTCP multiplexing procedures [RFC5761] to the associated RTP- + based media. If the corresponding SDP media description ("m=" line) + in the associated answer does not contain an SDP 'rtcp-mux' + attribute, the offerer MUST either take appropriate actions in order + to disable the associated RTP-based media -- e.g., send a new offer + with a zero port value associated with the SDP media description + ("m=" line) -- or send a new offer without associating an SDP 'rtcp- + mux-only' attribute with the SDP media description ("m=" line). + + NOTE: This document does not mandate specific actions on how to + terminate the RTP media. The offerer might, for example, terminate + the RTP media by sending a new offer in which the port value of the + SDP media description is set to zero. + +4.5. Modifying the Session + + When an offerer sends a subsequent offer, if the offerer and answerer + have previously negotiated usage of exclusive RTP/RTCP multiplexing + for the media associated with an RTP-based SDP media description + ("m=" line), the offerer SHOULD associate an SDP 'rtcp-mux-only' with + the corresponding SDP media description ("m=" line). + + In addition, if the offerer associates an SDP 'rtcp-mux-only' + attribute with an SDP media description ("m=" line), the offerer MUST + also associate an SDP 'rtcp-mux' attribute with the same SDP media + description ("m=" line), following the procedures in [RFC5761]. + + If the offerer does not associate the attributes with the + corresponding SDP media description ("m=" line), it is an indication + that the offerer no longer wants to use RTP/RTCP multiplexing and + instead MUST fall back to usage of separate ports for RTP and RTCP + once the offer has been accepted by the answerer. + + When an offerer sends a subsequent offer, if the offerer and answerer + have not previously negotiated usage of RTP/RTCP multiplexing for the + media associated with an RTP-based SDP media description ("m=" line), + the offerer MAY indicate exclusive support of RTP/RTCP multiplexing, + following the procedures in Section 4.2. The offerer MUST process + the associated answer following the procedures in Section 4.4. + + It is RECOMMENDED to not switch between usage of RTP/RTCP + multiplexing and usage of separate ports for RTP and RTCP in a + subsequent offer, unless there is a use case that mandates it. + +5. Update to RFC 5761 + +5.1. General + + This section updates Sections 5.1.1 and 5.1.3 of [RFC5761] by + clarifying that an offerer can use a mechanism to indicate that it is + not able to send and receive RTCP on separate ports, and that the + offerer shall terminate the affected streams if the answerer does not + indicate support of RTP/RTCP multiplexing. It also clarifies that, + when the offerer is not able to send and receive RTCP on separate + ports, the offerer will not provide an SDP 'candidate' attribute for + RTCP, nor will the offerer provide a fallback port for RTCP (using + the SDP 'rtcp' attribute). + +5.2. Update to 4th Paragraph of Section 5.1.1 + + NOTE: [RFC8035] also updates Section 5.1.1 of [RFC5761]. While the + paragraph updated in this document is not updated by [RFC8035], the + location of the paragraph within Section 5.1.1 is moved. + + OLD TEXT: + + | 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. + + NEW TEXT: + + | 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 signaled 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. However, if the offerer + | indicated in the offer that it is not able to send and receive + | RTCP on a separate port, the offerer MUST disable the media + | streams associated with the attribute. The mechanism for + | indicating that the offerer is not able to send and receive RTCP + | on a separate port is outside the scope of this specification. + +5.3. Update to 2nd Paragraph of Section 5.1.3 + + OLD TEXT: + + | 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. + + NEW TEXT: + + | 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. + | However, if the offerer indicates in the offer that it is not able + | to send and receive RTCP on a separate port, the offerer MUST NOT + | include "a=candidate:" lines for RTCP and MUST NOT provide a + | fallback port for RTCP using the "a=rtcp:" line. + +6. ICE Considerations + + As defined in [RFC8445], 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 also would not be provided + 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 a mechanism using the + SDP 'rtcp-mux-only' attribute. + +7. Security Considerations + + This document does not introduce new security considerations beyond + those specified in [RFC3605] and [RFC5761]. + +8. IANA Considerations + + This document updates the "Session Description Protocol Parameters" + registry as specified in Section 8.2.4 of [RFC4566]. Specifically, + it adds the SDP 'rtcp-mux-only' attribute to the table for SDP media- + level attributes. + + Attribute name: rtcp-mux-only + + Type of attribute: media-level + + Subject to charset: no + + Purpose: Indicate exclusive support of RTP/RTCP multiplexing + + Appropriate Values: N/A + + Contact name: Christer Holmberg (christer.holmberg@ericsson.com) + + Mux Category: IDENTICAL + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model + with Session Description Protocol (SDP)", RFC 3264, + DOI 10.17487/RFC3264, June 2002, + <https://www.rfc-editor.org/info/rfc3264>. + + [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session + Description Protocol", RFC 4566, DOI 10.17487/RFC4566, + July 2006, <https://www.rfc-editor.org/info/rfc4566>. + + [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and + Control Packets on a Single Port", RFC 5761, + DOI 10.17487/RFC5761, April 2010, + <https://www.rfc-editor.org/info/rfc5761>. + + [RFC8035] Holmberg, C., "Session Description Protocol (SDP) Offer/ + Answer Clarifications for RTP/RTCP Multiplexing", + RFC 8035, DOI 10.17487/RFC8035, November 2016, + <https://www.rfc-editor.org/info/rfc8035>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive + Connectivity Establishment (ICE): A Protocol for Network + Address Translator (NAT) Traversal", RFC 8445, + DOI 10.17487/RFC8445, July 2018, + <https://www.rfc-editor.org/info/rfc8445>. + + [RFC8843] Holmberg, C., Alvestrand, H., and C. Jennings, + "Negotiating Media Multiplexing Using the Session + Description Protocol (SDP)", RFC 8843, + DOI 10.17487/RFC8843, January 2021, + <https://www.rfc-editor.org/info/rfc8843>. + + [RFC8859] Nandakumar, S., "A Framework for Session Description + Protocol (SDP) Attributes When Multiplexing", RFC 8859, + DOI 10.17487/RFC8859, January 2021, + <https://www.rfc-editor.org/info/rfc8859>. + +9.2. Informative References + + [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute + in Session Description Protocol (SDP)", RFC 3605, + DOI 10.17487/RFC3605, October 2003, + <https://www.rfc-editor.org/info/rfc3605>. + + [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific + Media Attributes in the Session Description Protocol + (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, + <https://www.rfc-editor.org/info/rfc5576>. + + [WebRTC] Jennings, C., Boström, H., and J-I. Bruaroey, "WebRTC 1.0: + Real-time Communication Between Browsers", W3C Proposed + Recommendation, <https://www.w3.org/TR/webrtc/>. + +Acknowledgements + + Thanks to Roman Shpount, Paul Kyzivat, Ari Keränen, Bo Burman, Tomas + Frankkila, and Martin Thomson for their comments and input on the + document. Thanks to Francis Dupont for the GENART review. + +Author's Address + + Christer Holmberg + Ericsson + Hirsalantie 11 + FI-02420 Jorvas + Finland + + Email: christer.holmberg@ericsson.com |