doc: Add RFC documents

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