Network Working Group                                        C. Holmberg
Internet-Draft                                                  Ericsson
Updates: 5761 (if approved)                            December 15, 2015
Intended status: Standards Track
Expires: June 17, 2016


    Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP
                 draft-holmberg-mmusic-mux-exclusive-03

Abstract

   This document defines how an endpoint can indicate exclusive support
   of RTP/RTCP multiplexing using the Session Description Protocol
   (SDP).

   The document updates RFC 5761, by defining how the SDP 'rtcp'
   attribute is used, together with the SDP 'rtcp-mux' attribute, to
   indicate exclusive support of RTP/RTCP multiplexing.

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 June 17, 2016.

Copyright Notice

   Copyright (c) 2015 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



Holmberg                  Expires June 17, 2016                 [Page 1]


Internet-Draft           Exclusive RTP/RTCP Mux            December 2015


   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
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Update to RFC 5761  . . . . . . . . . . . . . . . . . . . . .   3
     4.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.2.  RFC 5761 Section 5.1.1 Update . . . . . . . . . . . . . .   3
     4.3.  RFC 5761 Section 5.1.3 Update . . . . . . . . . . . . . .   4
     4.4.  Issues And TBDs . . . . . . . . . . . . . . . . . . . . .   5
   5.  ICE Considerations  . . . . . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   6
   9.  Change Log  . . . . . . . . . . . . . . . . . . . . . . . . .   6
   10. Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   [RFC5761] defines how to multiplex RTP and RTCP on a single 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 of RTP/RTCP
   multiplexing.

   As defined in [RFC5761], if the peer endpoint does not support RTP/
   RTCP multiplexing, there must be a fallback to usage of separate
   ports for RTP and RTCP.  However, the RTCWEB WG have defined that
   support of the fallback is optional.  Therefore, there needs to be a
   mechanism for an endpoint to be able to indicate exclusive support of
   RTP/RTCP multiplexing, i.e. to be able to indicate that the endpoint
   only supports RTP/RTCP multiplexing and is not able to fallback to
   usage of separate ports for receiving RTP and RTCP.

   This document describes a mechanism, how the SDP 'rtcp-mux' attribute
   [RFC5761] and the SDP 'rtcp' attribute [RFC3605] can be used to
   indicate exclusive support of RTP/RTCP multiplexing.  The document
   updates sections 5.1.1 and 5.1.3 of [RFC5761] in order to enable
   usage of the mechanism.

   The document also describes the Interactive Connectivity
   Establishment (ICE) [I-D.ietf-ice-rfc5245bis] considerations when
   indicating exclusive support of RTP/RTCP multiplexing.



Holmberg                  Expires June 17, 2016                 [Page 2]


Internet-Draft           Exclusive RTP/RTCP Mux            December 2015


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

   As as described in [RFC5761], when an offerer sends an offer, and
   wants to indicate support of RTP/RTCP multiplexing, it must associate
   an SDP 'rtcp-mux' attribute with each RTP-based SDP media description
   ("m=" line) for which support of multiplexing is indicated.  In
   addition, the offerer may assign an SDP 'rtcp' attribute, in order to
   provide a fallback port for RTCP in case the answerer does not
   support (or is not willing to use) RTP/RTCP multiplexing.

   When an offerer sends an offer, and wants to indicate exclusive
   support of RTP/RTCP multiplexing it MUST, in addition to the SDP
   'rtcp-attribute, associate an SDP 'rtcp' attribute with each SDP
   media description for which exclusive support of RTP/RTCP
   multiplexing is indicated.  The offerer MUST assign a port value
   identical to the port value of the associated SDP media description
   to the 'rtcp' attribute.  The offerer MAY assign the optional IP
   address part to the 'rtcp' attribute.  If assigned, the IP address
   part value MUST be identical to the value of the associated
   connection address ("c=" line).

4.  Update to RFC 5761

4.1.  General

   This section updates sections 5.1.1 and 5.1.3 of [RFC5761], by adding
   a new paragraph in section 5.1.1 after the second paragraph, and by
   modifying the second paragraph in section 5.1.3.

4.2.  RFC 5761 Section 5.1.1 Update















Holmberg                  Expires June 17, 2016                 [Page 3]


Internet-Draft           Exclusive RTP/RTCP Mux            December 2015


  NEW PARAGRAPH:

     If the offerer is not able to use different ports
     for RTP and RTCP, the SDP offer MUST also include the "a=rtcp"
     attribute [10] with an attribute value identical to the associated
     port value for RTP. 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
         a=rtcp: 49170


4.3.  RFC 5761 Section 5.1.3 Update
































Holmberg                  Expires June 17, 2016                 [Page 4]


Internet-Draft           Exclusive RTP/RTCP Mux            December 2015


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. If the offerer supports
   a fallback port for RTCP in the case that the answerer does not
   support RTP and RTCP multiplexing, the initial offer MUST contain
   "a=candidate:" lines for both RTP and RTCP along with an "a=rtcp:"
   line indicating a fallback port for RTCP. If the offerer is not
   able to use separate ports for RTP and RTCP the offer MUST NOT
   contain "a=candidate:" lines for RTCP, and the "a=rtcp:" line
   MUST indicate the RTP port. If the "a=rtcp:" line indicates the
   RTP port, and if the "a=rtcp:" line also contains the optional
   IP address part, the IP address part value MUST be identical to
   the value of the associated "c=" line. The This MUST be done for
   each media where RTP and RTCP multiplexing is desired.


4.4.  Issues And TBDs

   ISSUE #1: We may want to specify an explicit procedure for the
   answerer too, saying that it must select mux if it receives rtcp-mux
   and rtcp with the RTP port value.

   ISSUE #2: We may want to specify something about the case when the
   answerer only supports mux, and receives an offer without mux.

5.  ICE Considerations

   As defined in [I-D.ietf-ice-rfc5245bis], 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




Holmberg                  Expires June 17, 2016                 [Page 5]


Internet-Draft           Exclusive RTP/RTCP Mux            December 2015


   support of exclusive RTP/RTCP multiplexing.  This document defines
   such mechanism using the SDP 'rtcp-mux' and 'rtcp' attributes.

6.  Security Considerations

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

7.  IANA Considerations

   This document makes no requests from IANA.

8.  Acknowledgments

   Thanks to Roman Shpount, Paul Kyzivat, Ari Keraenen, Bo Burman and
   Tomas Frankkila for their comments and input on the draft.

9.  Change Log

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

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

   o  Intended status changed to "Standards track".

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

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

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

   o  Additional updates to Section 5.1.1 of RFC 5761.

   o  ICE considerations added.

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




Holmberg                  Expires June 17, 2016                 [Page 6]


Internet-Draft           Exclusive RTP/RTCP Mux            December 2015


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

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

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

   [I-D.ietf-ice-rfc5245bis]
              Keranen, A. and J. Rosenberg, "Interactive Connectivity
              Establishment (ICE): A Protocol for Network Address
              Translator (NAT) Traversal", draft-ietf-ice-rfc5245bis-00
              (work in progress), October 2015.

Author's Address

   Christer Holmberg
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: christer.holmberg@ericsson.com






















Holmberg                  Expires June 17, 2016                 [Page 7]