doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc8035.txt b/doc/rfc/rfc8035.txt
new file mode 100644
index 0000000..b120b10
--- /dev/null
+++ b/doc/rfc/rfc8035.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       C. Holmberg
+Request for Comments: 8035                                      Ericsson
+Updates: 5761                                              November 2016
+Category: Standards Track
+ISSN: 2070-1721
+
+
+     Session Description Protocol (SDP) Offer/Answer Clarifications
+                       for RTP/RTCP Multiplexing
+
+Abstract
+
+   This document updates RFC 5761 by clarifying the SDP offer/answer
+   negotiation of RTP and RTP Control Protocol (RTCP) multiplexing.  It
+   makes it clear that an answerer can only include an "a=rtcp-mux"
+   attribute in a Session Description Protocol (SDP) answer if the
+   associated SDP offer contained the attribute.
+
+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
+   http://www.rfc-editor.org/info/rfc8035.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Holmberg                     Standards Track                    [Page 1]
+
+RFC 8035               RTP/RTCP Mux Clarifications         November 2016
+
+
+Copyright Notice
+
+   Copyright (c) 2016 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
+   (http://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.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Holmberg                     Standards Track                    [Page 2]
+
+RFC 8035               RTP/RTCP Mux Clarifications         November 2016
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   3
+   3.  Update to RFC 5761  . . . . . . . . . . . . . . . . . . . . .   3
+     3.1.  Update to Section 5.1.1 . . . . . . . . . . . . . . . . .   4
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
+   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
+   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   6
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7
+
+1.  Introduction
+
+   RFC 5761 [RFC5761] specifies how to multiplex RTP data packets and
+   RTP Control Protocol (RTCP) packets on a single UDP port, and how to
+   negotiate usage of such multiplexing using the SDP offer/answer
+   mechanism [RFC3264] with an "a=rtcp-mux" attribute.  However, the
+   text is unclear on whether an answerer is allowed to include the
+   attribute in an answer even if the associated offer did not contain
+   an attribute.
+
+   This document updates RFC 5761 [RFC5761] by clarifying that an
+   answerer can only include an "a=rtcp-mux" attribute in an answer if
+   the associated offer contained the attribute.  It also clarifies that
+   the negotiation of RTP and RTCP multiplexing is for usage in both
+   directions.
+
+2.  Conventions
+
+   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 [RFC2119].
+
+3.  Update to RFC 5761
+
+   This section updates Section 5.1.1 of RFC 5761 by clarifying that an
+   answerer can only include an "a=rtcp-mux" attribute in an answer if
+   the associated offer contained the attribute, and by clarifying that
+   the negotiation of RTP and RTCP multiplexing is for usage in both
+   directions.
+
+
+
+
+
+
+
+
+
+
+Holmberg                     Standards Track                    [Page 3]
+
+RFC 8035               RTP/RTCP Mux Clarifications         November 2016
+
+
+3.1.  Update to Section 5.1.1
+
+   In this section, any references to Sections 4 and 8 are to those
+   sections in [RFC5761].
+
+   OLD TEXT:
+
+   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.
+
+
+
+
+
+
+Holmberg                     Standards Track                    [Page 4]
+
+RFC 8035               RTP/RTCP Mux Clarifications         November 2016
+
+
+   NEW TEXT:
+
+   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, and the usage is always negotiated for both
+   directions.
+
+   If the offerer wishes to multiplex RTP and RTCP onto a single port,
+   the initial SDP offer MUST include the 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 Internet Low Bit Rate Codec (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 offer contains the "a=rtcp-mux" attribute, and 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 offer does not contain the "a=rtcp-mux" attribute, the answerer
+   MUST NOT include an "a=rtcp-mux" attribute in the answer, and the
+   answerer MUST NOT multiplex RTP and RTCP packets on a single port.
+
+   If the answer contains an "a=rtcp-mux" attribute, the offerer and
+   answerer MUST multiplex RTP and RTCP packets on a single port.
+
+   If the answer does not contain an "a=rtcp-mux" attribute, the offerer
+   and answerer MUST NOT multiplex RTP and RTCP packets on a single
+   port.  Instead, they 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.
+
+
+
+
+
+
+Holmberg                     Standards Track                    [Page 5]
+
+RFC 8035               RTP/RTCP Mux Clarifications         November 2016
+
+
+   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.
+
+4.  Security Considerations
+
+   The security considerations for RTP and RTCP multiplexing are
+   described in RFC 5761.  This specification does not impact those
+   security considerations.
+
+5.  IANA Considerations
+
+   IANA has added a reference to this document for the att-field (media
+   level only) registration "rtcp-mux" in the "Session Description
+   Protocol (SDP) Parameters" registry.
+
+6.  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,
+              <http://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,
+              <http://www.rfc-editor.org/info/rfc3264>.
+
+   [RFC5761]  Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
+              Control Packets on a Single Port", RFC 5761,
+              DOI 10.17487/RFC5761, April 2010,
+              <http://www.rfc-editor.org/info/rfc5761>.
+
+Acknowledgements
+
+   Thanks to Colin Perkins, Magnus Westerlund, Paul Kyzivat, and Roni
+   Even for providing comments on the document.  Thomas Belling provided
+   useful input in the discussions that took place in 3GPP and resulted
+   in the submission of the document.  Elwyn Davies performed the
+   Gen-ART review.  Rick Casarez performed the Ops-Dir review.  Alissa
+   Cooper and Spencer Dawkins provided IESG review comments.
+
+
+
+
+
+
+
+
+Holmberg                     Standards Track                    [Page 6]
+
+RFC 8035               RTP/RTCP Mux Clarifications         November 2016
+
+
+Author's Address
+
+   Christer Holmberg
+   Ericsson
+   Hirsalantie 11
+   Jorvas  02420
+   Finland
+
+   Email: christer.holmberg@ericsson.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Holmberg                     Standards Track                    [Page 7]
+