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

 Multiplexing Negotiation Using Session Description Protocol (SDP) Port
                                Numbers
            draft-ietf-mmusic-sdp-bundle-negotiation-02.txt
            draft-ietf-mmusic-sdp-bundle-negotiation-03.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, 22, 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
   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  4
   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  5
     6.2.  SDP Offerer Procedures . . . . . . . . . . . . . . . . . .  5
     6.3.  SDP Answerer Procedures  . . . . . . . . . . . . . . . . .  6  7
     6.4.  Bundled SDP Information  . . . . . . . . . . . . . . . . .  6  7
       6.4.1.  General  . . . . . . . . . . . . . . . . . . . . . . .  6  7
       6.4.2.  Bandwidth (b=) . . . . . . . . . . . . . . . . . . . .  6  7
       6.4.3.  Attributes (a=)  . . . . . . . . . . . . . . . . . . .  7
   7.  Single vs Multiple RTP Sessions  . . . . . . . . . . . . . . .  6  8
     7.1.  General  . . . . . . . . . . . . . . . . . . . . . . . . .  6  8
     7.2.  Single RTP Session . . . . . . . . . . . . . . . . . . . .  6  8
   8.  Usage With ICE . . . . . . . . . . . . . . . . . . . . . . . .  7  8
     8.1.  General  . . . . . . . . . . . . . . . . . . . . . . . . .  7  8
     8.2.  Candidates . . . . . . . . . . . . . . . . . . . . . . . .  7
   9.  Security Considerations  9
     8.3.  Candidates . . . . . . . . . . . . . . . . . . . .  8
   10. Example . . . .  9
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   10. Example: SDP Offer with different port number values . . . . .  8  9
   11. Example: SDP Offer with identical port number values . . . . . 11
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   12. 13
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   13. 13
   14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   14. 13
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     14.1. 14
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 10
     14.2. 14
     15.2. Informative References . . . . . . . . . . . . . . . . . . 11 14
   Appendix A.  Design Considerations . . . . . . . . . . . . . . . . 15
     A.1.  General  . . . . . . . . . . . . . . . . . . . . . . . . . 15
     A.2.  UA Interoperability  . . . . . . . . . . . . . . . . . . . 15
     A.3.  Usage of port number value zero  . . . . . . . . . . . . . 16
     A.4.  B2BUA And Proxy Interoperability . . . . . . . . . . . . . 17
       A.4.1.  Traffic Policing . . . . . . . . . . . . . . . . . . . 18
       A.4.2.  Bandwidth Allocation . . . . . . . . . . . . . . . . . 18
     A.5.  Candidate Gathering  . . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 18

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

   The SDP Offer or Offerer and SDP Answer [RFC3264], Answerer [RFC3264] use the "BUNDLE" grouping
   extension to indicate which includes media is associated with a single
   5-tuple.  For each media, the associated "m=" line is associated with
   a "BUNDLE" group.

   For each "BUNDLE" group, the SDP Offerer and SDP Answerer use an
   identical port number value in each "m=" line associated with the
   group will share
   "BUNDLE" group.  However, until it is known that the SDP Answerer
   supports the "BUNDLE" grouping extension, when the SDP Offerer
   generates an SDP Offer, a single different port number value. value is inserted for
   each "m=" line associated with the "BUNDLE" group.  The port number
   value associated with the first "m=" line associated with the
   "BUNDLE" group represents the port value number offered to be used in
   the single 5-tuple.

   NOTE: 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.

   SDP Offers and SDP Answer can contain multiple "BUNDLE" groups.  For
   each "BUNDLE" group, a different port number value MUST be used.

   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  Endpoints that do not support
   the "BUNDLE" grouping extension, or do not want to enable the
   mechanism for a given session, extension are expected to generate a "normal" SDP Answer, using Offers
   and SDP Answers without inserting a "BUNDLE" group, and to insert
   different port number values for in each "m=" line, to
   the SDP Offer.  The SDP Offerer [RFC3264] will still use a single
   port number value for each media, but as in 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", Offers and "OPTIONAL" in this
   document are to be interpreted
   SDP Answers, as described defined in RFC 2119 [RFC2119]. 4566 and RFC 3264.

2.  Terminology

   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 endpoint generates an SDP Offer or SDP Answer, that describes bundled media, which contains
   a "BUNDLE" group, it MUST insert an SDP session-
   level session-level 'group'
   attribute, with a "BUNDLE" value, and assign SDP media-
   level media-level 'mid'
   attribute values to for each "m=" line associated with the "BUNDLE" group.

   In addition, the entity that generates

   Until it is known whether the SDP Offer or Answerer supports the "BUNDLE"
   grouping extension, the SDP Answer Offerer MUST, for each "m=" line that is part of the
   associated with a "BUNDLE" group:

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

   NOTE: If an entity wants to disable specific media ("m=" line)
   o  6.  Insert identical DTLS-SRTP fingerprint attribute, when used
   o  7.  Insert different SDES crypto attribute, when used

   Once it is known that both endpoints support the "BUNDLE" grouping
   extension, the SDP Offerer and SDP Answerer MUST, for each "m=" line
   associated with a "BUNDLE" group, it will use a zero group:

   o  1.  Insert identical port number
   value values.
   o  2.  Insert identical connection data ("c=" line) value.
   o  3.  Insert identical SDP 'rtcp' attribute value, when used.
   o  4.  Insert identical ICE candidate values, when used.
   o  5.  Insert an SDP 'rtpc-mux' attribute.
   o  6.  Insert identical DTLS-SRTP fingerprint attribute, when used
   o  7.  Insert different SDES crypto attribute, when used

   Once both endpoints have indicated support of the "BUNDLE" grouping
   extension, they can start using the single port for the "m=" line media
   associated with each "m=" line in the media. "BUNDLE group".

   OPEN ISSUE #1: If the SDP Answerer supports "BUNDLE", do we mandate
   that "m=" lines must be grouped in the same way in the SDP Answer as
   they are grouped in the SDP Offer?

6.2.  SDP Offerer Procedures

   When an the SDP Offerer creates generates an SDP Offer, Offer that offers bundled media,
   it MUST create contains a "BUNDLE"
   group, the SDP Offer MUST be generated according to the procedures in
   Section 6.1.

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

   If SDP Offerer MUST generate the new SDP Answer does not include a session-level Offer immediately when it
   has received the SDP 'group'
   attribute, with a "BUNDLE" value, Answer indicating that the SDP Offerer cannot use Answerer supports
   the same
   5-tuple for media associated with multiple "m=" lines. "BUNDLE" grouping extension.  If ICE is used, the SDP Answererer indicates that it will not use bundled media, Offer can
   wait until the SDP Offerer will still use Offer indicating that ICE is finished is sent, as
   defined in RFC 5245.

   NOTE: The reason for sending the single new SDP Offer, which includes an
   identical port number value for in each
   "m= line" "m=" line associated with the offered
   "BUNDLE" group, and it is to ensure that intermediary entities that look at
   SDP information e.g. for different type of policing functions, have
   the correct information regarding which ports will
   normally be able to separate each individual media.  The default
   mechanism used for separating media received on a single IP address and media.

   If the SDP Offer contains different port doing this is by using a 5-tuple based mapping number values for each
   individual media.  If "m="
   lines associated with the "BUNDLE" group, and if the associated SDP
   Answer does not contain a "BUNDLE" group, the SDP Offerer is aware of MUST use
   the Synchronization
   Source (SSRC) [RFC3550] different port number values that the SDP Answerer will use were included in the
   media SDP Offer.

   Once it sends, and the SSRC values will be unique for each media, is known that both the SDP Offerer can separate media based on the SSRC values.

   NOTE: Assuming symmetric media is used, and SDP Answerer support
   the "BUNDLE" grouping extension, in each subsequent SDP Offerer can use Offer towards
   the
   port information from SDP Answerer, the SDP Answer Offer MUST insert an identical port number
   value in order to create the 5-tuple
   mapping for each media. "m=" line associated with the "BUNDLE" group.

   NOTE: If needed, the SDP Offerer is not able allowed to separate multiple media received on
   a single port, it MUST send a new SDP Offer, without offering bundled
   media, where a separate change the port number
   value is provide for each in an subsequent SDP Offer, but it still inserts the same
   identical port number value in each "m=" line of associated with the SDP Offer.

   If
   "BUNDLE" group.

   When generating an SDP Offer, offering a "BUNDLE" group, and if the SDP Offerer has
   reasons wants to believe that disable
   media associated with an "m=" line in a "BUNDLE" group, it will
   insert a zero port number value in the disabled "m=" line, as defined
   in RFC 3264.  However, if the "m=" lines associated with the "BUNDLE"
   group contain different port number values (i.e. the rejection SDP Offer is due to
   generated until it is known whether the usage SDP Answerer supports the
   "BUNDLE" grouping extension) the SDP Offerer MUST NOT set the port
   number value of a single the first "m=" line associated with the "BUNDLE"
   group to zero.

   The SDP Offerer MUST NOT insert an identical port number value for in
   multiple "m=" lines, unless the SDP Offerer SHOULD
   send a new SDP Offer, without "m=" lines are associated with a
   "BUNDLE" group, where a separate group.

   OPEN ISSUE #2: If the session has been established without BUNDLE, do
   we allow BUNDLE to be enabled later during the session?

   OPEN ISSUE #3: If the session has been established with BUNDLE, do we
   allow BUNDLE to be disabled later during the session, meaning that
   different port number value is provide values will be used for media associated with
   each "m=" line of the SDP offer. line?

6.3.  SDP Answerer Procedures

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

   If

   When generating the SDP Answer, if the SDP Answerer does not accept wants to reject
   media associated with an "m=" line in the "BUNDLE" group group, it will
   insert a zero port number value in the disabled "m=" line, as defined
   in RFC 3264.

   The SDP
   Offer, it Answerer MUST NOT include a session-evel 'group' attribute, with insert a "BUNDLE" value, group in an SDP Answer,
   unless the associated SDP Answer.  In addition, the Offer contains a "BUNDLE" group.

   The SDP Answerer MUST provide separate NOT insert an identical port number values for each value in
   multiple "m=" line
   of lines, unless the "m=" lines are associated with a
   "BUNDLE" group.

   Until the SDP Answerer receives the new SDP Answer. Offer, which contains an
   identical port number value for each "m=" line associated with a
   "BUNDLE" group, it MUST use the port, and related information (ICE
   candidates, SDES keys etc) associated with the first "m=" line in the
   "BUNDLE" group.

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.

6.4.3.  Attributes (a=)

   There are also special rules for handling many different attributes
   as defined in [I-D.nandakumar-mmusic-sdp-attributes].  It might not
   possible to use bundle with some attributes.

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.

   It is possible to use multiple "BUNDLE" groups, in case the RTP media
   within each group will be part of different RTP Sessions.

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
   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 extension
   together with the Interactive Connectivity Establishment (ICE)
   mechanism [RFC5245].

8.2.  Candidates

   When an ICE-enabled SDP Offerer sends endpoint generates an SDP offer, it Offer, which contains a
   "BUNDLE" group, the SDP Offerer MUST include ICE candidates for each
   "m=" line associated with a "BUNDLE" group.
   The group, except for any "m=" line
   with a zero port number value.  If the "m=" lines associated with the
   "BUNDLE" group contain different port number values, the SDP Offerer
   MUST also insert different candidate values MUST be identical for in each "m=" line
   associated with the "BUNDLE" group.  This rule applies also to subsequent SDP Offers,
   when  If the usage of bundled media has already been negotiated. "m=" lines associated
   with the "BUNDLE" group contain an identical port number value, the
   candidate values MUST also be identical.

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

8.3.  Candidates

   Once it is known that both endpoints support, and accept to use, the usage of bundled media has been negotiated,
   "BUNDLE" grouping extension, ICE connectivity checks and keep-alives
   only needs to be performed for the whole "BUNDLE" group, instead of
   for each individual m= "m=" line associated with the group.

9.  Security Considerations

   TBA

   This specification does not significantly change the security
   considerations of SDP which can be found in Section X of TBD.

   TODO: Think carefully about security analysis of reuse of same SDES
   key on multiple "m=" lines when the far end does not use BUNDLE and
   warn developers of any risks.

10.  Example  Example: SDP Offer with different port number values

   The example below shows an SDP Offer, where bundled media is offered. offered
   using different port number values in the "m=" lines associated with
   the "BUNDLE" group.  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 10002 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
       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 10002 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 10002 typ host

11.  IANA Considerations

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

12.  Acknowledgements Offer with identical port number values

   The usage of the example below shows an SDP grouping mechanism Offer, where bundled media is based on a similar
   alternative proposed by Harald Alvestrand.  The SDP examples are also
   modified versions from the ones offered
   an identical port number value in the Alvestrand proposal.

   Thanks to "m=" lines associated with 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.
   "BUNDLE" group.  The example also shows two SDP Answer alternatives:
   one where bundled media is accepted, and H. Schulzrinne, "An Offer/Answer Model 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
       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

12.  IANA Considerations

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

13.  Acknowledgements

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

14.  Change Log

   [RFC EDITOR NOTE: Please remove this section when publishing]
   Changes from draft-ietf-mmusic-sdp-bundle-negotiation-02
   o  Mechanism modified, to be based on usage of SDP Offers with both
      different and identical port number values, depending on whether
      it is known if the remote endpoint supports the extension.
   o  Cullen Jennings added as co-author.

   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.

15.  References

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

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

   [I-D.nandakumar-mmusic-sdp-attributes]
              Nandakumar, S. and C. Jennings, "A Framework for SDP
              Attributes when Multiplexing",
              draft-nandakumar-mmusic-sdp-attributes-00 (work in
              progress), February 2013.

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

Appendix A.  Design Considerations

A.1.  General

   One of the main issues regarding the "BUNDLE" grouping extensions has
   been whether, in SDP Offers and SDP Answers, the same port number
   value should be inserted in "m=" lines associated with a "BUNDLE"
   group, as the purpose of the extension is to negotiate the usage of a
   single 5-tuple for media associated with the "m=" lines.  Issues with
   both approaches, discussed in the Appendix have been raised.  The
   outcome was to specify a mechanism which uses SDP Offers with both
   different and identical port number values.

   Below are the primary issues that have been considered when defining
   the "BUNDLE" grouping extension:
   o  1) Interoperability with existing UAs.
   o  2) Interoperability with intermediary B2BUA- and proxy entities.
   o  3) Time to gather, and the number of, ICE candidates.
   o  4) Different error scenarios, and when they occur.
   o  5) SDP Offer/Answer impacts, including usage of port number value
      zero.

   NOTE: Before this document is published as an RFC, this Appendix
   might be removed.

A.2.  UA Interoperability

   Consider the following SDP Offer/Answer exchange, where Alice sends
   an SDP Offer to Bob:

   SDP Offer

       v=0
       o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
       s=
       c=IN IP4 host.atlanta.com
       t=0 0
       m=audio 10000 RTP/AVP 97
       a=rtpmap:97 iLBC/8000
       m=video 10002 RTP/AVP 97
       a=rtpmap:97 H261/90000

   SDP Answer

       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 97
       a=rtpmap:97 iLBC/8000
       m=video 20002 RTP/AVP 97
       a=rtpmap:97 H261/90000

   RFC 4961 specifies a way of doing symmetric RTP but that is an a
   later invention to RTP and Bob can not assume that Alice supports RFC
   4961.  This means that Alice may be sending RTP from a different port
   than 10000 or 10002 - some implementation simply send the RTP from an
   ephemeral port.  When Bob's endpoint receives an RTP packet, the only
   way that Bob know if it should be passed to the video or audio codec
   is by looking at the port it was received on.  This lead some SDP
   implementations to use the fact that each "m=" line had a different
   port number to use that port number as an index to find the correct m
   line in the SDP.  As a result, some implementations that do support
   symmetric RTP and ICE still use a SDP data structure where SDP with
   "m=" lines with the same port such as:

   SDP Offer

       v=0
       o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
       s=
       c=IN IP4 host.atlanta.com
       t=0 0
       m=audio 10000 RTP/AVP 97
       a=rtpmap:97 iLBC/8000
       m=video 10000 RTP/AVP 98
       a=rtpmap:98 H261/90000

   will result in the second "m=" line being considered an SDP error
   because it has the same port as the first line.

A.3.  Usage of port number value zero

   In an SDP Offer or SDP Answer, the media associated with an "m=" line
   can be disabled/rejected by setting the port number value to zero.

   This is different from e.g. using the SDP direction attributes, where
   RTCP traffic will continue even if the SDP "inactive" attribute is
   indicated for the associated "m=" line.

   If each "m=" line associated with Session Description Protocol (SDP)", a "BUNDLE" group would contain
   different port number values, and one of those port would be used for
   the 5-tuple, problems would occur if an endpoint wants to disable/
   reject the "m=" line associated with that port, by setting the port
   number value to zero.  After that, no "m=" line would contain the
   port number value which is used for the 5-tuple.  In addition, it is
   unclear what would happen to the ICE candidates associated with the
   "m=" line, as they are also used for the 5-tuple.

A.4.  B2BUA And Proxy Interoperability

   Some back to back user agents may be configured in a mode where if
   the incoming call leg contains an SDP attribute the B2BUA does not
   understand, the B2BUS still generates that SDP attribute in the Offer
   for the outgoing call leg.  Consider an B2BUA that did not understand
   the SDP "rtcp" attribute, defined in RFC 3264,
              June 2002.

   [RFC4566]  Handley, M., Jacobson, V., 3605, yet acted this way.
   Further assume that the B2BUA was configured to tear down any call
   where it did not see any RTCP for 5 minutes.  In this cases, if the
   B2BUA received an Offer like:

   SDP Offer

       v=0
       o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
       s=
       c=IN IP4 host.atlanta.com
       t=0 0
       m=audio 49170 RTP/AVP 0
       a=rtcp:53020

   It would be looking for RTCP on port 49172 but would not see any
   because the RTCP would be on port 53020 and after five minutes, it
   would tear down the call.  Similarly, an SBC that did not understand
   BUNDLE yet put BUNDLE in it's offer may be looking for media on the
   wrong port and tear down the call.  It is worth noting that a B2BUA
   that generated an Offer with capabilities it does not understand is
   not compliant with the specifications.

A.4.1.  Traffic Policing

   Sometimes intermediaries do not act as B2BUA, in the sense that they
   don't modify SDP bodies, nor do they terminate SIP dialogs.  Still,
   however, they may use SDP information (e.g.  IP address and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC5888]  Camarillo, G. port) in
   order to control traffic gating functions, 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., to set traffic
   policing rules.  There might be rules which will trigger a session to
   be terminated in case media is not sent or received on the ports
   retrieved from the SDP.  This typically occurs once the session is
   already established and V.
              Jacobson, "RTP: A Transport Protocol ongoing.

A.4.2.  Bandwidth Allocation

   Sometimes intermediaries do not act as B2BUA, in the sense that they
   don't modify SDP bodies, nor do they terminate SIP dialogs.  Still,
   however, they may use SDP information (e.g. codecs and media types)
   in order to control bandwidth allocation functions.  The bandwidth
   allocation is done per "m=" line, which means that it might not be
   enough if media associated with all "m=" lines try to use that
   bandwidth.  That may either simply lead to bad user experience, or to
   termination of the call.

A.5.  Candidate Gathering

   When using ICE, an candidate needs to be gathered for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol each port.
   This takes approximately 20 ms extra for Network Address Translator (NAT)
              Traversal each extra "m=" line due to
   the NAT pacing requirements.  All of this gather can be overlapped
   with other things while the page is loading to minimize the impact.
   If the client only wants to generate TURN or STUN ICE candidates for Offer/Answer Protocols", RFC 5245,
              April 2010.
   one of the "m=" lines and then use trickle ICE [TODO REF] to get the
   non host ICE candidates for the rest of the "m=" lines, it MAY do
   that and will not need any additional gathering time.

   Some people have suggested a TURN extension to get a bunch of TURN
   allocation at once.  This would only provide a single STUN result so
   in cases where the other end did not support BUNDLE, may cause more
   use of the TURN server but would be quick in the cases where both
   sides supported BUNDLE and would fall back to a successful call in
   the other cases.

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

   Cullen Jennings
   Cisco
   400 3rd Avenue SW, Suite 350
   Calgary, AB  T2P 4H2
   Canada

   Email: fluffy@iii.ca