


Network Working Group                                        C. Holmberg
Internet-Draft                                                  Ericsson
Updates: 5761 (if approved)                               August 8, 2016
Intended status: Standards Track
Expires: February 9, 2017


    Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP
                 draft-ietf-mmusic-mux-exclusive-10.txt

Abstract

   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 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 Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on February 9, 2017.

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




Holmberg                Expires February 9, 2017                [Page 1]

Internet-Draft           Exclusive RTP/RTCP Mux              August 2016


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  SDP rtcp-mux-only Attribute . . . . . . . . . . . . . . . . .   3
   4.  SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . .   4
     4.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  Generating the Initial SDP Offer  . . . . . . . . . . . .   5
     4.3.  Generating the Answer . . . . . . . . . . . . . . . . . .   5
     4.4.  Offerer Processing of the SDP Answer  . . . . . . . . . .   6
     4.5.  Modifying the Session . . . . . . . . . . . . . . . . . .   6
   5.  Update to RFC 5761  . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.2.  Update to 4th paragraph of section 5.1.1  . . . . . . . .   7
     5.3.  Update to 2nd paragraph of section 5.1.3  . . . . . . . .   8
   6.  ICE Considerations  . . . . . . . . . . . . . . . . . . . . .   8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   9
   10. Change Log  . . . . . . . . . . . . . . . . . . . . . . . . .   9
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     11.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12

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 Session Description Protocol (SDP) [RFC4566]
   attribute, 'rtcp-mux' that can be used by entities to indicate
   support, and negotiate usage of, RTP/RTCP multiplexing.

   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 to not implement
   separation of RTP and RTCP.  Examples of such applications are W3C
   WEBRTC [W3C.WD-webrtc-20120209] applications, that 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] by



Holmberg                Expires February 9, 2017                [Page 2]

Internet-Draft           Exclusive RTP/RTCP Mux              August 2016


   entities that ever need to interoperate with peers that do not
   support RTC/RTCP multiplexing may harm interoperability.  Also, while
   the SDP answerer [RFC3264] might support, and prefer usage of,
   fallback to non-multiplex, the attribute indicates that fallback to
   non-multiplex cannot be enabled.  One example of where non-multiplex
   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 the one
   endpoint is acting as a gateway to a network where RTP/RTCP
   multiplexing cannot be used.  In such case there endpoint may prefer
   non-multiplexing also towards the other network.  Otherwise the
   endpoint would have to perform de-multiplexing 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 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.

   The document also describes the Interactive Connectivity
   Establishment (ICE) [RFC5245] 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", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  SDP rtcp-mux-only Attribute

   This section defines a new SDP media-level attribute, 'rtcp-mux-
   only'.


















Holmberg                Expires February 9, 2017                [Page 3]

Internet-Draft           Exclusive RTP/RTCP Mux              August 2016


          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-only' attribute 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 SDP 'rtcp-mux-only' attribute is only defined for
   RTP-based media.

   The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'rtcp-
   mux-only' attribute is 'IDENTICAL', which means that the attribute,
   if used within a BUNDLE group
   [I-D.ietf-mmusic-sdp-bundle-negotiation], 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 [RFC3264] procedures associated with the
   attribute are defined in Section 4

4.  SDP Offer/Answer Procedures








Holmberg                Expires February 9, 2017                [Page 4]

Internet-Draft           Exclusive RTP/RTCP Mux              August 2016


4.1.  General

   This section defines the SDP offer/answer [RFC3264] procedures for
   indicating exclusive support of, and negotiating usage of, RTP/RTCP
   multiplexing.

   The procedures in this section apply to individual RTP-based SDP
   media descriptions ("m=" lines).

4.2.  Generating the Initial SDP Offer

   When an offerer sends the initial offer, if the offerer wants to
   indicate exclusive RTP/RTCP multiplexing for RTP-based media, the
   offerer 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 MAY
   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), if the answerer accepts the usage of RTP/RTCP
   multiplexing, the answerer MUST associate an SDP 'rtcp-mux-only'
   attribute with the corresponding SDP media description ("m=") in the
   associated answer.  If the answerer does not accept the usage of RTP/
   RTCP multiplexing, the answerer 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].

   In addition, if the answerer associates an SDP 'rtcp-mux-only'
   attribute with an SDP media description ("m=" line) in the answer,
   and if the corresponding "m=" line in the associated offer contained
   an SDP 'rtcp-mux' attribute, the answerer MUST in addition associate




Holmberg                Expires February 9, 2017                [Page 5]

Internet-Draft           Exclusive RTP/RTCP Mux              August 2016


   an SDP 'rtcp-mux' attribute with the same "m=" line, following the
   procedures in [RFC5761].

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-only' attribute, and/or 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-only' attribute,
   nor an SDP 'rtcp-mux' attribute, the offerer MUST either take
   appropriate actions in order to disable the associated RTP-based
   media, 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 e.g. send a new offer
   where the port value of the SDP media description is set to zero in
   order to terminate the RTP media.

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 MAY
   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 fallback 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.



Holmberg                Expires February 9, 2017                [Page 6]

Internet-Draft           Exclusive RTP/RTCP Mux              August 2016


   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 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, 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


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.





Holmberg                Expires February 9, 2017                [Page 7]

Internet-Draft           Exclusive RTP/RTCP Mux              August 2016


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 the offerer MUST NOT provide a fallback port for
   RTCP using the "a=rtcp:" line.


6.  ICE Considerations

   As defined in [RFC5245], 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-only' attributes.

7.  Security Considerations

   This document does not introduce new security considerations in
   additions to those specified in [RFC3605] and [RFC5761].






Holmberg                Expires February 9, 2017                [Page 8]

Internet-Draft           Exclusive RTP/RTCP Mux              August 2016


8.  IANA Considerations

   This document updates the "Session Description Protocol Parameters"
   registry as specified in Section 8.2.2 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.  Acknowledgments

   Thanks to Roman Shpount, Paul Kyzivat, Ari Keranen, Bo Burman, Tomas
   Frankkila and Martin Thomson for their comments and input on the
   document.  Thanks to Francis Dupont for the genart review.

10.  Change Log

   [RFC EDITOR NOTE: Please remove this section when publishing]

   Changes from draft-ietf-mmusic-rtcp-mux-exclusive-09

   o  Changes based on IESG review comments from Alexey Melnikov and
      Mirja Kuhlewind:

   o  - References to draft-mux-attributes and draft-sdp-bundle made
      normative.

   o  - Text added regarding cases where entities might want to use non-
      multiplexed RTP and RTCP.

   Changes from draft-ietf-mmusic-rtcp-mux-exclusive-08

   o  Editorial changes based on genart comments from Francis Dupont.

   Changes from draft-ietf-mmusic-rtcp-mux-exclusive-07

   o  Comments from Ben Campbell.





Holmberg                Expires February 9, 2017                [Page 9]

Internet-Draft           Exclusive RTP/RTCP Mux              August 2016


   o  - Additional text regarding applications for which the mechanism
      is suitable.

   o  - Removal of pre-RFC5378 disclaimer.

   o  - Editorial fixes.

   Changes from draft-ietf-mmusic-rtcp-mux-exclusive-06

   o  - Editorial fix.

   o  - Addition of pre-RFC5378 disclaimer.

   Changes from draft-ietf-mmusic-rtcp-mux-exclusive-05

   o  Editorial fix.

   Changes from draft-ietf-mmusic-rtcp-mux-exclusive-04

   o  Changes based on comments from Flemming Andreasen.

   o  - Attribute mux category changed to IDENTICAL.

   o  - Reference to draft-5245bis changed to RFC 5245.

   Changes from draft-ietf-mmusic-rtcp-mux-exclusive-03

   o  Editorial changes based on comments from Martin Thomson.

   o  Change of attribute name.

   o  RFC 5761 updates added.

   Changes from draft-ietf-mmusic-rtcp-mux-exclusive-02

   o  Minor editorial fix.

   Changes from draft-ietf-mmusic-rtcp-mux-exclusive-01

   o  Mux category and source-specific applicability added.

   Changes from draft-ietf-mmusic-rtcp-mux-exclusive-00

   o  Defined new SDP attribute for indicating rtcp-mux-exclusive.

   o  Updates to RFC 5761 removed.

   o  IANA considerations added.



Holmberg                Expires February 9, 2017               [Page 10]

Internet-Draft           Exclusive RTP/RTCP Mux              August 2016


   Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-03

   o  Submitted as draft-ietf-mmusic-rtcp-mux-exclusive-00.

   Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-02

   o  Intended status changed to "Standards track".

   Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-01

   o  Clarified that the SDP rtcp attribute may contain the optional IP
      address part.

   Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-00

   o  Additional updates to Section 5.1.1 of RFC 5761.

   o  ICE considerations added.

11.  References

11.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,
              <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>.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
              July 2006, <http://www.rfc-editor.org/info/rfc4566>.

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245,
              DOI 10.17487/RFC5245, April 2010,
              <http://www.rfc-editor.org/info/rfc5245>.

   [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>.




Holmberg                Expires February 9, 2017               [Page 11]

Internet-Draft           Exclusive RTP/RTCP Mux              August 2016


   [I-D.ietf-mmusic-sdp-mux-attributes]
              Nandakumar, S., "A Framework for SDP Attributes when
              Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-13
              (work in progress), June 2016.

   [I-D.ietf-mmusic-sdp-bundle-negotiation]
              Holmberg, C., Alvestrand, H., and C. Jennings,
              "Negotiating Media Multiplexing Using the Session
              Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
              negotiation-31 (work in progress), June 2016.

11.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,
              <http://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,
              <http://www.rfc-editor.org/info/rfc5576>.

   [W3C.WD-webrtc-20120209]
              Bergkvist, A., Burnett, D., Jennings, C., and A.
              Narayanan, "WebRTC 1.0: Real-time Communication Between
              Browsers", World Wide Web Consortium WD WD-webrtc-
              20120209, February 2012,
              <http://www.w3.org/TR/2012/WD-webrtc-20120209>.

Author's Address

   Christer Holmberg
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: christer.holmberg@ericsson.com












Holmberg                Expires February 9, 2017               [Page 12]
