diff options
Diffstat (limited to 'doc/rfc/rfc8035.txt')
| -rw-r--r-- | doc/rfc/rfc8035.txt | 395 |
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] + |