MMUSIC Working Group                                         C. Holmberg
Internet-Draft                                                  Ericsson
Intended status: Standards Track                           H. Alvestrand
Expires: August 16, 2013                                          Google
                                                       February 12, 2013


 Multiplexing Negotiation Using Session Description Protocol (SDP) Port
                                Numbers
            draft-ietf-mmusic-sdp-bundle-negotiation-02.txt

Abstract

   This specification defines a new SDP Grouping Framework SDP grouping
   framework extension, "BUNDLE", that can be used with the Session
   Description Protocol (SDP) Offer/Answer mechanism to negotiate the
   usage of bundled media, which refers to the usage of a single 5-tuple
   for media associated with multiple SDP media descriptions ("m="
   lines).

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 August 16, 2013.

Copyright Notice

   Copyright (c) 2013 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 & Alvestrand    Expires August 16, 2013                [Page 1]


Internet-Draft                Bundled media                February 2013


   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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  4
   5.  SDP Grouping Framework BUNDLE Extension Semantics  . . . . . .  4
   6.  SDP Offer/Answer Procedures  . . . . . . . . . . . . . . . . .  4
     6.1.  General  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     6.2.  SDP Offerer Procedures . . . . . . . . . . . . . . . . . .  5
     6.3.  SDP Answerer Procedures  . . . . . . . . . . . . . . . . .  6
     6.4.  Bundled SDP Information  . . . . . . . . . . . . . . . . .  6
       6.4.1.  General  . . . . . . . . . . . . . . . . . . . . . . .  6
       6.4.2.  Bandwidth (b=) . . . . . . . . . . . . . . . . . . . .  6
   7.  Single vs Multiple RTP Sessions  . . . . . . . . . . . . . . .  6
     7.1.  General  . . . . . . . . . . . . . . . . . . . . . . . . .  6
     7.2.  Single RTP Session . . . . . . . . . . . . . . . . . . . .  6
   8.  Usage With ICE . . . . . . . . . . . . . . . . . . . . . . . .  7
     8.1.  General  . . . . . . . . . . . . . . . . . . . . . . . . .  7
     8.2.  Candidates . . . . . . . . . . . . . . . . . . . . . . . .  7
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   10. Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 10
     14.2. Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11

















Holmberg & Alvestrand    Expires August 16, 2013                [Page 2]


Internet-Draft                Bundled media                February 2013


1.  Introduction

   In the IETF RTCWEB WG, a need to use a single 5-tuple for sending and
   receiving media associated with multiple SDP media descriptions ("m="
   lines) has been identified.  This would e.g. allow the usage of a
   single set of Interactive Connectivity Establishment (ICE) [RFC5245]
   candidates for multiple media descriptions.  Normally different media
   types (audio, video etc) will be described using different media
   descriptions.

   This specification defines a new SDP Grouping Framework SDP grouping
   framework [RFC5888] extension, "BUNDLE", that can be used with the
   Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264]
   to negotiate the usage of bundled media, which refers to the usage of
   a single 5-tuple for media associated with multiple SDP media
   descriptions ("m=" lines).

   When an endpoint generates an SDP Offer or SDP Answer [RFC3264],
   which includes a "BUNDLE" group, each "m=" line associated with the
   group will share a single port number value.

   As defined in RFC 4566 [RFC4566], the semantics of multiple "m="
   lines using the same port number value 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.  This
   specification provides such extension.

   When media is transported using the Real-Time Protocol (RTP)
   [RFC3550], the default assumption of the mechanism is that all media
   associated with a "BUNDLE" group will form a single RTP Session
   [RFC3550].  However, future specifications can extend the mechanism,
   in order to negotiate RTP Session multiplexing, i.e.  "BUNDLE" groups
   where media associated with a group form multiple RTP Sessions.

   The mechanism is backward compatible.  Entities that do not support
   the "BUNDLE" grouping extension, or do not want to enable the
   mechanism for a given session, are expected to generate a "normal"
   SDP Answer, using different port number values for each "m=" line, to
   the SDP Offer.  The SDP Offerer [RFC3264] will still use a single
   port number value for each media, but as the SDP Answerer [RFC3264]
   will use separate ports a single 5-tuple will not be used for media
   associated with multiple "m=" lines between the endpoints.


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this



Holmberg & Alvestrand    Expires August 16, 2013                [Page 3]


Internet-Draft                Bundled media                February 2013


   document are to be interpreted as described in RFC 2119 [RFC2119].

   5-tuple: A collection of the following values: source address, source
   port, destination address, destination port and protocol.

   Bundled media: Two or more RTP streams using a single 5-tuple.  The
   RTCP streams associated with the RTP streams also use a single
   5-tuple, which might be the same, but can also be different, as the
   one used by the RTP streams.


3.  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].


4.  Applicability Statement

   The mechanism in this specification only applies to the Session
   Description Protocol (SDP) [RFC4566], when used together with the SDP
   Offer/Answer mechanism [RFC3264].


5.  SDP Grouping Framework BUNDLE Extension Semantics

   This section defines a new SDP Grouping Framework extension,
   "BUNDLE".

   The "BUNDLE" extension can be indicated using an SDP session-level
   'group' attribute.  Each SDP media description ("m=" line) that is
   grouped together, using an SDP media-level 'mid' attribute, is part
   of a specific "BUNDLE" group.


6.  SDP Offer/Answer Procedures

6.1.  General

   When an SDP Offerer or SDP Answerer generates an SDP Offer or SDP
   Answer, that describes bundled media, it MUST insert an SDP session-
   level 'group' attribute, with a "BUNDLE" value, and assign SDP media-
   level 'mid' attribute values to each "m=" line associated with the
   "BUNDLE" group.

   In addition, the entity that generates the SDP Offer or SDP Answer



Holmberg & Alvestrand    Expires August 16, 2013                [Page 4]


Internet-Draft                Bundled media                February 2013


   MUST, for each "m=" line that is part of the "BUNDLE" group:

   o  1.  Use the same port number value.
   o  2.  Use the same connection data ("c=" line) value.
   o  3.  Use the same SDP 'rtcp' attribute value, when used.
   o  4.  Use the same ICE candidate values, when used.
   o  5.  Insert an SDP 'rtpc-mux' attribute.

   NOTE: If an entity wants to disable specific media ("m=" line)
   associated with a "BUNDLE" group, it will use a zero port number
   value for the "m=" line associated with the media.

6.2.  SDP Offerer Procedures

   When an SDP Offerer creates an SDP Offer, that offers bundled media,
   it MUST create the SDP Offer according to the procedures in
   Section 6.1.

   If the associated SDP Answer contains an SDP session-level 'group'
   attribute, with a "BUNDLE" value, and the SDP Answer is created
   according to the proceudres in Section 6.1 (the same port number
   value is used for each "m=" line associated with the "BUNDLE" group,
   etc), the SDP Offerer can start using the same 5-tuple for sending
   and receiving media, associated with the group, between the entities.

   If the SDP Answer does not include a session-level SDP 'group'
   attribute, with a "BUNDLE" value, the SDP Offerer cannot use the same
   5-tuple for media associated with multiple "m=" lines.

   If the SDP Answererer indicates that it will not use bundled media,
   the SDP Offerer will still use the single port number value for each
   "m= line" associated with the offered "BUNDLE" group, and it will
   normally be able to separate each individual media.  The default
   mechanism for separating media received on a single IP address and
   port doing this is by using a 5-tuple based mapping for each
   individual media.  If the SDP Offerer is aware of the Synchronization
   Source (SSRC) [RFC3550] values that the SDP Answerer will use in the
   media it sends, and the SSRC values will be unique for each media,
   the SDP Offerer can separate media based on the SSRC values.

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

   If the SDP Offerer is not able to separate multiple media received on
   a single port, it MUST send a new SDP Offer, without offering bundled
   media, where a separate port number value is provide for each "m="
   line of the SDP Offer.



Holmberg & Alvestrand    Expires August 16, 2013                [Page 5]


Internet-Draft                Bundled media                February 2013


   If an SDP Offer, offering a "BUNDLE" group, and the SDP Offerer has
   reasons to believe that the rejection is due to the usage of a single
   port number value for multiple "m=" lines, the SDP Offerer SHOULD
   send a new SDP Offer, without a "BUNDLE" group, where a separate port
   number value is provide for each "m=" line of the SDP offer.

6.3.  SDP Answerer Procedures

   When an SDP Answerer receives an SDP Offer, which offers bundled
   media, and the SDP Answerer accepts the offered bundle group, the SDP
   Answerer MUST create an SDP Answer according to the procedures in
   Section 6.1.

   If the SDP Answerer does not accept the "BUNDLE" group in the SDP
   Offer, it MUST NOT include a session-evel 'group' attribute, with a
   "BUNDLE" value, in the associated SDP Answer.  In addition, the SDP
   Answerer MUST provide separate port number values for each "m=" line
   of the SDP Answer.

6.4.  Bundled SDP Information

6.4.1.  General

   This section describes how SDP information, given for each media
   description, is calculated into a single value for a "BUNDLE" group.

6.4.2.  Bandwidth (b=)

   The total proposed bandwidth is the sum of the proposed bandwidth for
   each "m=" line associated with a negotiated BUNDLE group.


7.  Single vs Multiple RTP Sessions

7.1.  General

   When entities negotiate the usage of bundled media, the default
   assumption is that all media associated with the bundled media will
   form a single RTP session.

   The usage of multiple RTP Sessions within a "BUNDLE" group is outside
   the scope of this specification.  Other specification needs to extend
   the mechanism in order to allow negotiation of such bundle groups.

7.2.  Single RTP Session

   When a single RTP Session is used, media associated with all "m="
   lines part of a bundle group share a single SSRC [RFC3550] numbering



Holmberg & Alvestrand    Expires August 16, 2013                [Page 6]


Internet-Draft                Bundled media                February 2013


   space.

   In addition, the following rules and restrictions apply for a single
   RTP Session:

   o  - The dynamic payload type values used in the "m=" lines MUST NOT
      overlap.
   o  - The "proto" value in each "m=" line MUST be identical (e.g.
      RTP/AVPF).
   o  - A given SSRC SHOULD NOT transmit RTP packets using payload types
      that originates from different "m=" lines.

   NOTE: The last bullet above is to avoid sending multiple media types
   from the same SSRC.  If transmission of multiple media types are done
   with time overlap RTP and RTCP fails to function.  Even if done in
   proper sequence this causes RTP Timestamp rate switching issues [ref
   to draft-ietf-avtext-multiple-clock-rates].


8.  Usage With ICE

8.1.  General

   This section describes how to use the "BUNDLE" grouping mechanism
   together with the Interactive Connectivity Establishment (ICE)
   mechanism [RFC5245].

8.2.  Candidates

   When an ICE-enabled SDP Offerer sends an SDP offer, it MUST include
   ICE candidates for each "m=" line associated with a "BUNDLE" group.
   The candidate values MUST be identical for each "m=" line associated
   with the group.  This rule applies also to subsequent SDP Offers,
   when the usage of bundled media has already been negotiated.

   When an ICE-enabled SDP Answerer receives an SDP Offer, offering a
   "BUNDLE" group and ICE, if the SDP Answerer enables ICE, MUST include
   ICE candidates for each "m=" line of the SDP Answer.  This also
   applies for "m=" lines that are part of a "BUNDLE" group, in which
   case the candidate values MUST be identical for each "m=" line
   associated with the group.  This rule applies also to subsequent SDP
   Answers, when the usage of bundled media has already been negotiated.

   Once the usage of bundled media has been negotiated, ICE connectivity
   checks and keep-alives only needs to be performed for the whole
   "BUNDLE" group, instead of for each individual m= line associated
   with the group.




Holmberg & Alvestrand    Expires August 16, 2013                [Page 7]


Internet-Draft                Bundled media                February 2013


9.  Security Considerations

   TBA


10.  Example

   The example below shows an SDP Offer, where bundled media is offered.
   The example also shows two SDP Answer alternatives: one where bundled
   media is accepted, and one where bundled media is rejected (or, not
   even supported) by the SDP Answerer.

   SDP Offer (Bundled media offered)

       v=0
       o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
       s=
       c=IN IP4 host.atlanta.com
       t=0 0
       a=group:BUNDLE 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 (Bundled media accepted)

       v=0
       o=bob 2808844564 2808844564 IN IP4 host.biloxi.com
       s=
       c=IN IP4 host.biloxi.com
       t=0 0
       a=group:BUNDLE 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



Holmberg & Alvestrand    Expires August 16, 2013                [Page 8]


Internet-Draft                Bundled media                February 2013


       a=rtpmap:32 MPV/90000


   SDP Answer (Bundled media 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 (Bundled media offered)

       v=0
       o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
       s=
       c=IN IP4 host.atlanta.com
       t=0 0
       a=group:BUNDLE 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
       a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host












Holmberg & Alvestrand    Expires August 16, 2013                [Page 9]


Internet-Draft                Bundled media                February 2013


11.  IANA Considerations

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


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

   Thanks to the nice flight crew on AY 021 for providing good sparkling
   wine, and a nice working athmosphere, for working on this draft.


13.  Change Log

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

   Changes from draft-ietf-mmusic-sdp-bundle-negotiation-01
   o  No changes.  New version due to expiration.

   Changes from draft-ietf-mmusic-sdp-bundle-negotiation-00
   o  No changes.  New version due to expiration.

   Changes from draft-holmberg-mmusic-sdp-multiplex-negotiation-00
   o  Draft name changed.
   o  Harald Alvestrand added as co-author.
   o  "Multiplex" terminology changed to "bundle".
   o  Added text about single versus multiple RTP Sessions.
   o  Added reference to RFC 3550.


14.  References

14.1.  Normative References

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

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




Holmberg & Alvestrand    Expires August 16, 2013               [Page 10]


Internet-Draft                Bundled media                February 2013


   [RFC5888]  Camarillo, G. and H. Schulzrinne, "The Session Description
              Protocol (SDP) Grouping Framework", RFC 5888, June 2010.

14.2.  Informative References

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

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


Authors' Addresses

   Christer Holmberg
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: christer.holmberg@ericsson.com


   Harald Tveit Alvestrand
   Google
   Kungsbron 2
   Stockholm  11122
   Sweden

   Email: harald@alvestrand.no


















Holmberg & Alvestrand    Expires August 16, 2013               [Page 11]