[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

MMUSIC Working Group                                         C. Holmberg
Internet-Draft                                                  Ericsson
Intended status: Standards Track                      September 14, 2011
Expires: March 17, 2012


 Multiplexing Negotiation Using Session Description Protocol (SDP) Port
                                Numbers
         draft-holmberg-mmusic-sdp-multiplex-negotiation-00.txt

Abstract

   This document defines how to use the Session Description Protocol
   (SDP) in order to negotiate the usage of multiplexed media.

Status of this Memo

   This Internet-Draft is submitted to IETF 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 March 17, 2012.

Copyright Notice

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





Holmberg                 Expires March 17, 2012                 [Page 1]


Internet-Draft                Multiplexing                September 2011


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Applicability Statement . . . . . . . . . . . . . . . . . . . . 3
   4.  SDP Grouping Framework MULTIPLEX Extension Semantics  . . . . . 3
   5.  SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . . 4
     5.1.  General . . . . . . . . . . . . . . . . . . . . . . . . . . 4
     5.2.  SDP Offerer Procedures  . . . . . . . . . . . . . . . . . . 4
     5.3.  SDP Answer Procedures . . . . . . . . . . . . . . . . . . . 5
   6.  Usage With ICE  . . . . . . . . . . . . . . . . . . . . . . . . 5
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   8.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   11. Change Log  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     12.1. Normative References  . . . . . . . . . . . . . . . . . . . 8
     12.2. Informative References  . . . . . . . . . . . . . . . . . . 9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 9































Holmberg                 Expires March 17, 2012                 [Page 2]


Internet-Draft                Multiplexing                September 2011


1.  Introduction

   In the IETF RTCWEB WG, a need for media multiplexing has been
   identified.  In order to be able to establish media sessions with
   entities that do not support multiplexing, there needs to be a
   mechanism to negotiate whether multiplexing will be used or not.

   This document defines a mechanism to negotiate the usage of
   multiplexing using the Session Description Protocol (SDP) [RFC4566],
   by indicating identical "m=" line port number values to every media
   stream that would be part of a multiplex.

   As defined in RFC 4566, the semantics of multiple "m=" lines using
   the same transport address are undefined, and there is no grouping
   defined by such means.  Instead, an explicit grouping mechanism needs
   to be used to express the intended semantics.  Therefore, this
   specification defines an SDP grouping framework [RFC5888] extension,
   MULTIPLEX, which is used to group media that is part of a multiplex.

   The mechanism is backward compatible.  Entities that do not support
   the MULTIPLEX grouping extension, or do not want to enable
   multiplexing within the session associated with the SDP offer, are
   expected to generate a "normal" SDP answer, are expected to generate
   a "normal" SDP answer, using different port numbers for each "m="
   line, to the SDP offer.  The offerer will still use a single port for
   each media, but as the answerer will use separate ports there will be
   no multiplexing of media between the endpoints.


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 BCP 14, RFC 2119
   [RFC2119].


3.  Applicability Statement

   The mechanism in this specification only applies to SDP, when used
   together with the SDP offer/answer media negotiation mechanism
   [RFC3264].


4.  SDP Grouping Framework MULTIPLEX Extension Semantics

   This section defines a new SDP Grouping Framework extension,
   MULTIPLEX.



Holmberg                 Expires March 17, 2012                 [Page 3]


Internet-Draft                Multiplexing                September 2011


   The MULTIPEX extension can be indicated using an SDP session-level
   "a=group" attribute.  Every "m=" line that is grouped together, using
   an SDP media-level "a=mid" attribute, is part of a specific
   multiplex.

   OPEN ISSUE: We need a reference to the specification defining the
   actual multiplexing mechanism.


5.  SDP Offer/Answer Procedures

5.1.  General

   This section defines the SDP offer/answer procedures for negotiating
   the usage of multiplexing.

5.2.  SDP Offerer Procedures

   When an SDP offerer wants to offer multiplexed media, it inserts the
   same port number value for each "m=" line that is part of the offered
   multiplex.  In addition, the SDP offerer inserts an SDP session-level
   "a=group" attribute, with a "MULTIPLEX" value, and assigns an SDP
   media-level "a=mid" attribute value for each "m=" line that is part
   of the offered multiplex.

   NOTE: If the SDP offerer wants to disable a specific stream within a
   multiplex, it will use a zero port number value for the "m=" line
   associated with the stream.

   If the associated SDP answer includes the session-level "a=group"
   attribute, with a "MULTIPLEX" value, and associated "m=" lines with
   identical port number values, the SDP offerer can enable media
   multiplexing between the entities.

   If the associated SDP does not include the session-level "a=group"
   attribute, with a "MULTIPLEX" value, the SDP offerer MUST NUT enable
   media multiplexing between the entities, even if two or more "m="
   lines in the SDP answer contain identical port number values.

   If the SDP answer indicates that multiplexing will not be enabled,
   the offerer will still receive multiple media on the single port that
   it included in the SDP offer, and it normally will be able to
   separate each individual media.  The default mechanism for doing this
   is by using a 5-tuple based mapping for each individual media.  If
   the offerer is aware of the SSRC values that the remote peer will use
   in the media it sends, and the values will be unique for each media,
   the offerer can also separate media based on the SSRC values.




Holmberg                 Expires March 17, 2012                 [Page 4]


Internet-Draft                Multiplexing                September 2011


   NOTE: Assuming symmetric media is used, the offerer can use the port
   information from the SDP answer in order to create the 5-tuple
   mapping for each media.

   If the offerer is not able to separate multiple media on a single
   port, it MUST send a new SDP offer, without using the "MULTIPLEX"
   grouping, where each media (m= line) is given a different port number
   value.

   NOTE: If the SDP offer is rejected, and the SDP offerer has reasons
   to believe that the rejection is due to the fact that the SDP offer
   contained identical "m=" line port number values, the SDP offerer
   might send a new SDP offer, without offered multiplex (and with
   separate port number values for each "m=" line).

5.3.  SDP Answer Procedures

   When an SDP answerer receives an SDP offer, offering multiplexing, if
   the SDP answerer accepts the offered multiplexing, it MUST include a
   session-level "a=group" attribute, with a "MULTIPLEX" value, in the
   SDP answer.  In addition, the SDP answerer assigns an SDP media-level
   "a=mid" attribute value for each "m=" line that is part of the
   multiplex.

   If the SDP answerer does not accept the offered multiplex, it MUST
   NOT include a session-evel "a=group" attribute, with a "MULTIPLEX"
   value, in the SDP answer.  In addition, it MUST assign separate port
   number values for each "m=" line in the SDP answer.

   NOTE: If the SDP answerer wants to disable a specific stream within a
   multiplex, it will use a zero port number value for the "m=" line
   associated with the stream.


6.  Usage With ICE

   When an entity that supports the Interactive Connectivity
   Establishment (ICE) mechanism [RFC5245] sends an SDP offer, it MUST
   include ICE candidates for each "m=" line of the SDP offer, even if
   it offers multiplexing and the SDP "m=" line port value numbers are
   identical.  This is true also for subsequent SDP offers, when the
   usage of multiplexing has previously been negotiated.

   When an entity that supports ICE and multiplexing receives an SDP
   offer, offering multiplexing and ICE, if it accepts the multiplex,
   and ICE, it MUST include ICE candidates for each "m=" line of the SDP
   answer, even if the SDP "m=" line port value numbers are identical.




Holmberg                 Expires March 17, 2012                 [Page 5]


Internet-Draft                Multiplexing                September 2011


   The candidate information inserted in an SDP offer or answer MUST be
   identical for each "m=" line associated with a specific MULTIPLEX SDP
   group.

   Once the usage of multiplexing has been negotiated, ICE connectivity
   checks and keep-alives only needs to be performed for the whole
   multiplex, represented by a MULTIPLEX SDP group, instead of for
   individual m= lines associated with the multiplex.


7.  Security Considerations

   TBA


8.  Example

   The example below shows an SDP offer, where multiplexing is offered.
   The example also shows two SDP answer alternatives: one where
   multiplexing is accepted, and one where multiplexing is rejected (or,
   not even supported) by the SDP answerer.

   SDP Offer (Multiplexing offered)

       v=0
       o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
       s=
       c=IN IP4 host.atlanta.com
       t=0 0
       a=group:MULTIPLEX foo bar
       m=audio 10000 RTP/AVP 0 8 97
       a=mid:foo
       b=AS:200
       a=rtpmap:0 PCMU/8000
       a=rtpmap:8 PCMA/8000
       a=rtpmap:97 iLBC/8000
       m=video 10000 RTP/AVP 31 32
       a=mid:bar
       b=AS:1000
       a=rtpmap:31 H261/90000
       a=rtpmap:32 MPV/90000


   SDP Answer (Multiplexing accepted)

       v=0
       o=bob 2808844564 2808844564 IN IP4 host.biloxi.com
       s=



Holmberg                 Expires March 17, 2012                 [Page 6]


Internet-Draft                Multiplexing                September 2011


       c=IN IP4 host.biloxi.com
       t=0 0
       a=group:MULTIPLEX foo bar
       m=audio 20000 RTP/AVP 0
       a=mid:foo
       b=AS:200
       a=rtpmap:0 PCMU/8000
       m=video 20000 RTP/AVP 32
       a=mid:bar
       b=AS:1000
       a=rtpmap:32 MPV/90000


   SDP Answer (Multiplexing not accepted)

       v=0
       o=bob 2808844564 2808844564 IN IP4 host.biloxi.com
       s=
       c=IN IP4 host.biloxi.com
       t=0 0
       m=audio 20000 RTP/AVP 0
       b=AS:200
       a=rtpmap:0 PCMU/8000
       m=video 30000 RTP/AVP 32
       b=AS:1000
       a=rtpmap:32 MPV/90000


   SDP Offer with ICE (Multiplexing offered)

       v=0
       o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
       s=
       c=IN IP4 host.atlanta.com
       t=0 0
       a=group:MULTIPLEX foo bar
       m=audio 10000 RTP/AVP 0 8 97
       a=mid:foo
       b=AS:200
       a=rtpmap:0 PCMU/8000
       a=rtpmap:8 PCMA/8000
       a=rtpmap:97 iLBC/8000
           a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host
       m=video 10000 RTP/AVP 31 32
       a=mid:bar
       b=AS:1000
       a=rtpmap:31 H261/90000
       a=rtpmap:32 MPV/90000



Holmberg                 Expires March 17, 2012                 [Page 7]


Internet-Draft                Multiplexing                September 2011


       a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host






9.  IANA Considerations

   This document requests IANA to register the new SDP Grouping semantic
   extension called MULTIPLEX.


10.  Acknowledgements

   The usage of the SDP grouping mechanism is based on a similar
   alternative proposed by Harald Alvestrand.  The SDP examples are also
   modified versions from the ones in the Alvestrand proposal.


11.  Change Log

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

   Changes from draft-holmberg-mmusic-sdp-multiplex-negotiation-xx
   o


12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              June 2002.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC5888]  Camarillo, G. and H. Schulzrinne, "The Session Description



Holmberg                 Expires March 17, 2012                 [Page 8]


Internet-Draft                Multiplexing                September 2011


              Protocol (SDP) Grouping Framework", RFC 5888, June 2010.

12.2.  Informative References

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245,
              April 2010.


Author's Address

   Christer Holmberg
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: christer.holmberg@ericsson.com
































Holmberg                 Expires March 17, 2012                 [Page 9]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/