MMUSIC Working Group                                         C. Holmberg
Internet-Draft                                                  Ericsson
Updates: 3264 (if approved)                                H. Alvestrand
Intended status: Standards Track                           H. Alvestrand                                  Google
Expires: April 17, October 9, 2014                                           Google                                     C. Jennings
                                                                   Cisco
                                                        October 14, 2013
                                                           April 7, 2014

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

Abstract

   This specification defines a new 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 sending and
   receiving media associated with multiple SDP media descriptions ("m="
   lines).

   This specification also updates sections 5.1, 8.1 and 8.2 of RFC
   3264, in order to allow an answerer to in an SDP answer assign a non-
   zero port value to an "m=" line, even if the offerer in the
   associated SDP offer had assigned a zero port value to the "m=" line.

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 April 17, October 9, 2014.

Copyright Notice

   Copyright (c) 2013 2014 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   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4   5
   3.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   5   6
   4.  Applicability Statement . . . . . . . . . . . . . . . . . . .   5   6
   5.  SDP Grouping Framework BUNDLE Extension Semantics . . . . . .   5
   6.  SDP Offer/Answer Procedures   6
     5.1.  General . . . . . . . . . . . . . . . . .   5
     6.1.  General . . . . . . . .   6
     5.2.  SDP Offer/Answer Procedures . . . . . . . . . . . . . . .   6
       5.2.1.  General . .   5
     6.2.  Bundled SDP Information . . . . . . . . . . . . . . . . .   5
       6.2.1.  General . . . .   6
       5.2.2.  SDP Information Considerations  . . . . . . . . . . .   7
       5.2.3.  Generating the Initial Offer  . . . . . . . .   5
       6.2.2.  Bandwidth (b=) . . . .   7
       5.2.4.  Generating the Answer . . . . . . . . . . . . . . .   6
       6.2.3.  rtcp-mux Attribute .   8
       5.2.5.  Offerer Processing of the Answer  . . . . . . . . . .  10
       5.2.6.  Modifying the Session . . . . . .   6
       6.2.4.  rtcp Attribute . . . . . . . . . .  11
   6.  SDP 'bundle-only' Attribute . . . . . . . . .   6
       6.2.5.  DTLS-SRTP fingerprint Attribute . . . . . . . .  13
     6.1.  General . . .   6
       6.2.6.  SDES crypto Attribute . . . . . . . . . . . . . . . .   6
       6.2.7.  Other Attributes (a=) . . . . . .  13
     6.2.  SDP Offer/Answer Procedures . . . . . . . . . .   6
     6.3.  RFC 5888 restrictions . . . . .  13
       6.2.1.  Generating the Initial Offer  . . . . . . . . . . . .  13
       6.2.2.  Generating the Answer .   6
     6.4.  SDP Offerer Procedures . . . . . . . . . . . . . . .  13
       6.2.3.  Offerer Processing of the Answer  . .   7
       6.4.1.  General . . . . . . . .  14
       6.2.4.  Modifying the Session . . . . . . . . . . . . . . .   7
       6.4.2.  Request BUNDLE address selection .  14
   7.  Protocol Identification . . . . . . . . .   8
       6.4.3.  Bundle Address Synchronization (BAS) . . . . . . . .   8
       6.4.4.  Adding a media description to a BUNDLE group . .  14
     7.1.  General . .   8
       6.4.5.  Moving A Media Description Out Of A BUNDLE Group . .   9
       6.4.6.  Disabling A Media Description In A BUNDLE Group . . .   9
     6.5.  SDP Answerer Procedures . . . . . . . . . . . . . . . . .   9
       6.5.1.  Offerer Bundle Address Selection .  14
     7.2.  STUN, DTLS, SRTP  . . . . . . . . .  10
       6.5.2.  Anwerer Bundle Address Selection . . . . . . . . . .  10
       6.5.3.  Moving A Media Description Out Of A BUNDLE Group .  15
   8.  RTP Considerations  .  10
       6.5.4.  Rejecting A Media Description In A BUNDLE Group . . .  11
   7.  Single vs Multiple RTP Sessions . . . . . . . . . . . . . . .  11
     7.1.  General . .  15
     8.1.  Single RTP Session  . . . . . . . . . . . . . . . . . . .  15
       8.1.1.  General . . . .  11
     7.2.  Single RTP Session . . . . . . . . . . . . . . . . . . .  11
   8.  Usage With ICE  15
       8.1.2.  Payload Type (PT) Value Re-usage  . . . . . . . . . .  16
     8.2.  Associating RTP Packets With Correct SDP Media
           Description . . . . . . . . . . . . .  12
     8.1.  General . . . . . . . . . .  16
     8.3.  RTP/RTCP Multiplexing . . . . . . . . . . . . . . .  12
     8.2.  Candidates . . .  17
       8.3.1.  General . . . . . . . . . . . . . . . . . . . .  12
     8.3.  Candidates . . .  17
       8.3.2.  SDP Offer/Answer Procedures . . . . . . . . . . . . .  17
   9.  ICE Considerations  . . . . . . .  12
   9.  Security Considerations . . . . . . . . . . . . . .  19
     9.1.  General . . . . .  12
   10. Examples . . . . . . . . . . . . . . . . . . . .  19
     9.2.  SDP Offer/Answer Procedures . . . . . .  13
     10.1.  Example: Bundle Address Selection . . . . . . . . .  19
       9.2.1.  Generating the Initial Offer  . .  13
     10.2.  Example: Bundle Mechanism Rejected . . . . . . . . . .  19
       9.2.2.  Generating the Answer .  14
     10.3.  Example: Offerer Adds A Media Description To A BUNDLE
            Group . . . . . . . . . . . . . . .  20
       9.2.3.  Offerer Processing of the Answer  . . . . . . . . . .  15

     10.4.  Example: Offerer Moves A Media Description Out Of A
            BUNDLE Group  20
       9.2.4.  Modifying the Session . . . . . . . . . . . . . . . .  20
       9.2.5.  Keep-alives . . . . . .  17
     10.5.  Example: Offerer Disables A Media Description In A
            BUNDLE Group . . . . . . . . . . . . . . .  20
   10. Update to RFC 3264  . . . . . . .  19
   11. IANA Considerations . . . . . . . . . . . . . .  20
     10.1.  General  . . . . . . .  20
   12. Acknowledgements . . . . . . . . . . . . . . . . .  20
     10.2.  Original text of section 5.1 (2nd paragraph) of RFC 3264  20
     10.3.  New text replacing section 5.1 (2nd paragraph) of RFC
            3264 . . . . .  20
   13. Change Log . . . . . . . . . . . . . . . . . . . . .  21
     10.4.  Original text of section 8.2 (2nd paragraph) of RFC 3264  21
     10.5.  New text replacing section 8.2 (2nd paragraph) of RFC
            3264 . . . .  20
   14. References . . . . . . . . . . . . . . . . . . . . . .  21
     10.6.  Original text of section 8.4 (6th paragraph) of RFC 3264  22
     10.7.  New text replacing section 8.4 (6th paragraph) of RFC
            3264 . . .  21
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  21
     14.2.  Informative References . . . . .  22
   11. Security Considerations . . . . . . . . . . . .  22
   Appendix A.  Design Considerations . . . . . . .  22
   12. Examples  . . . . . . . .  22
     A.1.  General . . . . . . . . . . . . . . . . . .  22
     12.1.  Example: Bundle Address Selection  . . . . . . .  22
     A.2.  UA Interoperability . . . .  22
     12.2.  Example: Bundle Mechanism Rejected . . . . . . . . . . .  24
     12.3.  Example: Offerer Adds A Media Description To A BUNDLE
            Group  . . . .  23
     A.3.  Usage of port number value zero . . . . . . . . . . . . .  24
     A.4.  B2BUA And Proxy Interoperability . . . . . . . .  25
     12.4.  Example: Offerer Moves A Media Description Out Of A
            BUNDLE Group . . . .  25
       A.4.1.  Traffic Policing . . . . . . . . . . . . . . . . . .  25
       A.4.2.  Bandwidth Allocation  27
     12.5.  Example: Offerer Disables A Media Description Within A
            BUNDLE Group . . . . . . . . . . . . . . . .  25
     A.5.  Candidate Gathering . . . . . .  29
   13. IANA Considerations . . . . . . . . . . . . .  26
   Authors' Addresses . . . . . . . .  31
   14. Acknowledgements  . . . . . . . . . . . . . . .  26

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 . . . . . . .  31
   15. Change Log  . . . . . . . . . . . . . . . . . . . . . . . . .  31
   16. References  . . . . . . . . . . . . . . . . . . . . . . . . .  33
     16.1.  Normative References . . . . . . . . . . . . . . . . . .  33
     16.2.  Informative References . . . . . . . . . . . . . . . . .  33
   Appendix A.  Design Considerations  . . . . . . . . . . . . . . .  34
     A.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .  34
     A.2.  UA Interoperability . . . . . . . . . . . . . . . . . . .  34
     A.3.  Usage of Interactive Connectivity Establishment (ICE) [RFC5245]
   candidates for multiple media descriptions.  Normally different media
   types (audio, video etc) will be described using different port number value zero . . . . . . . . . . . . .  36
     A.4.  B2BUA And Proxy Interoperability  . . . . . . . . . . . .  36
       A.4.1.  Traffic Policing  . . . . . . . . . . . . . . . . . .  37
       A.4.2.  Bandwidth Allocation  . . . . . . . . . . . . . . . .  37
     A.5.  Candidate Gathering . . . . . . . . . . . . . . . . . . .  37
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  38

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 [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 sending and receiving media associated with multiple SDP media
   descriptions ("m=" lines).

   The Offerer offerer and Answerer answerer [RFC3264] use the BUNDLE mechanism to
   negotiate a single BUNDLE address addresses, one for the offerer (offerer BUNDLE
   address) and one for the answerer (answerer BUNDLE address) to be
   used for the bundled media associated with a BUNDLE group.

   The BUNDLE mechanism allows an SDP Offerer and SDP Answerer to assign
   identical addresses to multiple "m=" lines, if those "m=" lines are
   associated with a BUNDLE group.  However, until

   Once it is known whether that both the Offerer offerer and Answerer support the answerer supports the
   BUNDLE mechanism, unique
   addresses are assigned to each "m=" line, including those associated
   with a BUNDLE group.

   NOTE: As defined group and the associated BUNDLE addresses
   have been negotiated, each endpoint can assign its BUNDLE address to
   each "m=" line within, and use the address to send and receive all
   media associated with, the BUNDLE group.

   NOTE: As defined in RFC 4566 [RFC4566], the semantics of multiple
   "m=" lines using assigning
   the same port number value to multiple "m=" lines 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 an extension.

   SDP Offers and SDP Answer bodies can contain multiple BUNDLE groups.  For
   each  Each BUNDLE group, group
   MUST use a unique 5-tuple.  Any given "m=" line can only be
   associated with a single BUNDLE address is negotiated.  Multiple group.

   The procedures in this specification apply to a given BUNDLE
   groups cannot share the same bundle address. group.

   The default assumption is that all Real-Time Protocol (RTP) [RFC3550]
   based media flows within associated with a BUNDLE group belongs belong to the same
   RTP Session [RFC3550].  Future extensions can change that assumption.

   The BUNDLE mechanism is backward compatible.  Endpoints that do not
   support the BUNDLE mechanism are expected to generate SDP Offers offers and
   SDP Answers answers without an SDP group:BUNDLE 'group:BUNDLE' attribute, and are expected
   to assign a unique addresses address to each "m=" line, line within an SDP offer and
   SDP answer, according to the procedures in [RFC4566] and [RFC3264]

   This specification also updates sections 5.1, 8.1 and 8.2 of
   [RFC3264], in order to allow an answerer to assign a non-zero port
   value to an "m=" line in an SDP answer, even if the offerer in the
   associated SDP offer had assigned a zero port value to the "m=" line.

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.

   Unique address: This refers to an An IP address and IP port combination, combination that can only be associated with is
   assigned to a single "m=" line within in an SDP
   Session.

   BUNDLE offer or SDP answer.

   Shared address: This refers to an An IP address and IP port combination, combination that is associated with each
   assigned to multiple "m=" line within a BUNDLE group, within lines in an SDP Session. offer or SDP answer.

   Offerer suggested BUNDLE mid: The zero IP port first mid value BUNDLE address MUST NOT be
   used in a given SDP
   'group:BUNDLE' attribute mid list in an SDP offer.

   Answerer selected BUNDLE address.

   NOTE: "m=" lines that share a BUNDLE mid: The first mid value in a given SDP
   'group:BUNDLE' attribute mid list in an SDP answer.

   Offerer BUNDLE address: Within a given BUNDLE group, an IP address MUST also share other
   parameters related
   and IP port combination used by an offerer to send and receive all
   media associated with each "m=" line within the BUNDLE group.

   Answerer BUNDLE address: Within a given BUNDLE group, an IP address
   and IP port combination used by an answerer to send and receive all
   media transport plane, e.g. ICE candidate
   information. associated with each "m=" line within the BUNDLE group.

   BUNDLE group: A set of "m=" lines, created using an SDP offer/answer
   exchange, for which a single 5-tuple is used to send and receive
   media.  Each endpoint uses its BUNDLE address, associated with the
   BUNDLE group, to send and receive the media.

   Bundled "m=" line: An "m=" line, in an SDP offer or SDP answer,
   associated with a BUNDLE group.

   Bundle-only "m=" line: An "m=" line, to which an SDP 'bundle-only'
   attribute has been assigned.

   Bundled media: All media associated with a BUNDLE group.

   Initial SDP offer: The first SDP offer, in which the offerer
   indicates that it wants to create a given BUNDLE group.

   Subsequent SDP offer: An SDP offer which contains a BUNDLE group that
   has been created as part of a previous SDP offer/answer exchange.

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

5.1.  General

   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 SDP media-level mid attributes, belongs to a
   given BUNDLE group.

6.

5.2.  SDP Offer/Answer Procedures

6.1.

5.2.1.  General

   This section describes the usage of the SDP Offer/Answer offer/answer mechanism
   [RFC3264] to negotiate the for negotiating usage of the BUNDLE mechanism, to
   negotiate for creating
   a BUNDLE group, for selecting the BUNDLE address, addresses (offerer BUNDLE
   address and answerer BUNDLE address), for adding an "m=" line to add, remove a
   BUNDLE group, for moving an "m=" line out of a BUNDEL group, and reject SDP Media
   Descriptions ("m=" lines) [RFC4566] associated with for
   disabling an "m=" line within a BUNDLE group.

   The generic rules and procedures defined in [RFC3264] and [RFC5888]
   also apply when the SDP Offer/Answer mechanism is used with to the BUNDLE mechanism.  For example, if an SDP Offer offer is rejected,
   rejected by the answerer, the previously negotiated SDP parameters
   and characteristics (including those associated with a BUNDLE groups) group)
   apply.

   When  Hence, if an endpoint, acting as an Offerer or Answerer [RFC3264],
   generates an SDP Offer, or an SDP Answer, the endpoint MUST assign offerer generates an SDP media-level mid value for each "m=" line offer in which the
   offerer wants to create a BUNDLE group.  In
   addition, group, and the answerer rejects the endpoint MUST assign an
   SDP session-level group:BUNDLE
   attribute for each offer, the BUNDLE group, and place each mid associated with group is not created.

   The procedures in this section are independent of the media type or
   transport protocol represented by a bundled "m=" line.  [Section 8]
   defines additional considerations for RTP based media.  [Section 6]
   defines additional considerations for the usage of the SDP group:BUNDLE attribute mid list.

6.2.  Bundled 'bundle-
   only' attribute.  [Section 9] defines additional considerations for
   the usage of Interactive Connectivity Establishment (ICE) mechanism
   [RFC5245].

5.2.2.  SDP Information

6.2.1. Considerations

5.2.2.1.  General

   This section describes restrictions associated with the usage of SDP
   parameters and extensions within a BUNDLE group.  It also describes, when parameter
   and attribute values have been assigned to each bundled "m="
   line in the BUNDLE group, line,
   how to calculate a value for the whole BUNDLE group.

6.2.2.

5.2.2.2.  Connection Data (c=)

   The "c=" line nettype value [RFC4566] assigned to a bundled "m=" line
   MUST be 'IN'.

   The "c=" line addrtype value [RFC4566] assigned to a bundled "m="
   line MUST be 'IP4' or 'IP6'.  The same value MUST be assigned to each
   "m=" line.

   NOTE: Extensions to this specification can specify usage of the
   BUNDLE mechanism for other nettype and addrtype values than the ones
   listed above.

5.2.2.3.  Bandwidth (b=)

   The total proposed bandwidth is the sum of the proposed bandwidth for
   each bundled "m=" line associated with line.

5.2.2.4.  Attributes (a=)

   [I-D.nandakumar-mmusic-sdp-mux-attributes] defines rules and
   restrictions for assigning different types of SDP attributes to a negotiated BUNDLE group.

6.2.3.  rtcp-mux Attribute

   For each
   bundled "m=" line line.

5.2.3.  Generating the Initial Offer

5.2.3.1.  General

   When an offerer generates an initial SDP offer, in order to create a
   BUNDLE group, an Offerer and Answerer the offerer MUST
   assign an in the SDP rtcp-mux attribute [RFC5761].

6.2.4.  rtcp Attribute

   When used, for offer assign a unique
   address to each RTP media "m=" line in with a non-zero port value, following the
   procedures in [RFC3264].

   The offerer MUST in the SDP offer insert an SDP session level
   'group:BUNDLE' attribute, associated with the BUNDLE group, an Offerer and Answerer MUST
   assign an SDP rtcp 'mid' attribute [RFC3605] with an
   identical attribute value.

6.2.5.  DTLS-SRTP fingerprint Attribute

   When DTLS-SRTP is used, for [RFC5888] to each RTP media "m=" line in a that the
   offerer wants to be within the BUNDLE group, an Offerer and Answerer MUST assign an SDP DTLS-SRTP
   fingerprint place the 'mid'
   attribute with identical value in the 'group:BUNDLE' attribute values.

6.2.6.  SDES crypto Attribute mid list.

   [Section 12.1] shows an example of an initial SDP offer.

5.2.3.2.  Request offerer BUNDLE address selection

   When SDES is used, for each RTP media "m=" line an offerer generates an initial SDP offer, in order to create a
   BUNDLE group, an
   Offerer and Answerer the offerer MUST assign an in the SDP crypto attribute, with offer indicate which unique
   attribute values.

6.2.7.  Other Attributes (a=)

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

6.3. one of the "m=" lines that the offerer wants
   to be within the BUNDLE group, that the offerer wants the answerer to
   select as the offerer BUNDLE address [Section 5.2.4.2].  In the SDP
   offer, the offerer BUNDLE mid value represents that address.

5.2.4.  Generating the Answer

5.2.4.1.  RFC 5888 restrictions

   Based on

   When an answerer generates an SDP answer, the rules and procedures following restrictions,
   defined in [RFC5888], the following
   restrictions also apply to a BUNDLE groups in SDP Answers: group:

   o  1) A BUNDLE group must not be added to an The answerer MUST NOT in the SDP Answer, answer include a BUNDLE group,
      unless the
      same BUNDLE group was included offerer in the associated SDP Offer; offer requested the
      BUNDLE group to be created; and

   o  2) An The answerer MUST NOT in the SDP answer include an "m=" line must not be added to
      within a BUNDLE group in the SDP
      Answer, group, unless it was in the same BUNDLE group offerer in the associated SDP Offer.

6.4.  SDP
      offer requested the "m=" line to be within the BUNDLE group.

5.2.4.2.  Answerer Selection of Offerer Procedures

6.4.1.  General Bundle Address

   When an Offerer answerer generates an Offer, SDP answer, it assigns an MUST select a BUNDLE
   address for the offerer, referred to each
   "m=" line, according to as the procedures in [RFC3264].  To each "m="
   line within a offerer BUNDLE group the Offerer assigns either address.
   The answerer MUST select an address that
   is unique to that "m=" line, or a shared address that is also
   assigned which the offerer in the
   associated SDP answer requested to other "m=" lines be within the BUNDLE group.  Such shared
   address can be, but does not have to be, a previously selected

   In the SDP offer, the offerer suggested BUNDLE
   address Section 6.5.1.

   OPEN ISSUE (Q6): There is a discussion on whether assigning a shared
   address to multiple mid represents the
   "m=" lines shall be allowed until line to which the Answerer offerer in the SDP offer has indicated support of BUNDLE.

   o  (http://www.ietf.org/mail-archive/web/mmusic/current/
      msg12245.html)

   The Offerer MUST NOT assign an assigned the
   address (unique or shared), that it
   has assigned wants the answerer to an "m=" line within a select as the offerer BUNDLE group, to an
   address [Section 5.2.3.2].  The answerer MUST first select the "m="
   line
   outside associated with the offerer suggested BUNDLE group. mid, and check
   whether it fulfils the following criteria:

   o  The Offerer MUST, for a BUNDLE group, on answerer will in the SDP session level
   [RFC4566], insert an SDP group:BUNDLE attribute associated with answer create the BUNDLE group. group;
   o  The Offerer MUST assign an answerer will not in the SDP 'mid' attribute
   [RFC5888] to each answer move the "m=" line within out of
      the BUNDLE group, and place the
   mid value group [Section 5.2.4.4];

   o  The answerer will not in the group:BUNDLE attribute mid list.

   The Offerer MAY assign an SDP 'bundle-only' attribute [ref-to-be-
   added] to one or more answer reject the "m=" lines within a BUNDLE group.

   OPEN ISSUE (Q8): It still needs to be decided whether line
      [Section 5.2.4.5]; and

   o  The offerer did not in the associated SDP offer assign a zero port
      value can be assigned to a 'bundle-only' the "m=" line.

   o  (http://www.ietf.org/mail-archive/web/mmusic/current/
      msg12075.html)

   o  (http://www.ietf.org/mail-archive/web/mmusic/current/
      msg12226.html)

   o  (http://www.ietf.org/mail-archive/web/mmusic/current/
      msg12339.html)

6.4.2.  Request BUNDLE address selection

   When an Offerer generates an Offer, it

   If all of the criteria above is fulfilled, the answerer MUST indicate which select
   the address
   (unique or shared) within a BUNDLE group it wishes associated with the Answer to
   select "m=" line as the Offerer's offerer BUNDLE address for
   address.

   If all of the BUNDLE group
   Section 6.5.1.  The Offerer criteria is not fulfilled, the answerer MUST do this even if select the Answerer has,
   next mid value in
   a previous Answer within the dialog, already selected the Offerer's
   BUNDLE address.

   In order to request an address (unique or shared) to be selected as mid list, and perform the Offerer's BUNDLE address same criteria check
   for a BUNDLE group, the Offerer places
   the mid value, associated with the "m=" line representing associated with the
   requested address, first in mid value.

   In the SDP group:BUNDLE attribute answer, the answerer selected BUNDLE mid list value represents
   the "m=" line which address (in the associated with SDP offer) the
   answerer has selected as the offerer BUNDLE group.

   Section 10.1 address.

   [Section 12.1] shows an example of a Bundle Address Request.

6.4.3.  Bundle an offerer BUNDLE address
   selection.

5.2.4.3.  Answerer Selection of Answerer BUNDLE Address Synchronization (BAS)

   When an Offerer receives an Answer, in which answerer generates an offered SDP answer, the answerer MUST select a
   BUNDLE group
   is accepted, if address for itself, referred to as the Offerer answerer BUNDLE
   address, and in the associated Offer assigned an
   address (unique or shared), that does not represent SDP answer assign the answerer BUNDLE address selected for the Offerer, to an
   each "m=" line within the created BUNDLE
   group, the Offerer group.

   The answerer MUST send a subsequent Offer, NOT in which it assigns the SDP answer assign the answerer BUNDLE
   address selected for the Offerer to each an "m=" line within that is not associated with the BUNDLE group.  This procedure is referred group,
   or to as Bundle Address
   Synchronization (BAS), and the Offer an "m=" line that is referred associated with another BUNDLE group.

   The answerer is allowed to as select a BAS Offer.

   The Offerer MAY modify any SDP parameter new answerer BUNDLE address in a BAS Offer.

   NOTE: It is important
   every SDP answer that the BAS Offer gets accepted by the
   Answerer, so the Offerer needs to consider the necessity to modify
   SDP parameters that could get the Answerer to reject the BAS Offer.
   Removing "m=" lines, or reducing the number of codecs, in the BAS
   Offer used for the is considered to have a low risk of being
   rejected.

   NOTE: The main purpose of the BAS Offer is to make sure that
   intermediaries, that might not support the BUNDLE mechanism, have
   correct information regarding which address is going to be used for
   the bundled media.

   Section 10.1 answerer generates.

   [Section 12.1] shows an example of an BAS Offer.

6.4.4.  Adding a media description to a answerer BUNDLE group address
   selection.

5.2.4.4.  Moving A Media Description Out Of A BUNDLE Group

   When an Offerer answerer generates an Offer, SDP answer, in which it adds an the answerer moves
   a bundled "m=" line to out a BUNDLE group, the Offerer answerer assigns an
   address (unique or shared) to the moved "m=" line based on the type of address that the
   offerer in the associated SDP offer assigned to the "m=" line.

   o  If the offerer in the SDP offer has assigned a shared address
      (e.g. a previously selected offerer BUNDLE address) to the "m="
      line, assigns the answerer MUST in the SDP answer reject the moved "m="
      line, according to the procedures in [Section 5.2.4.5].

   o  If the offerer in the SDP offer assigned an SDP 'mid' 'bundle-only'
      attribute to the "m=" line, and
   places the mid value answerer MUST in the group:BUNDLE attribute mid list
   associated with SDP answer
      reject the BUNDLE group, moved "m=" line, according to the procedures in
   Section 6.4.2.
      [Section 5.2.4.5].

   o  If the Offerer wishes offerer in the Answerer SDP offer assigned a unique address to select the
      "m=" line, the answerer MUST in the SDP answer assign a unique
      address assigned to the added moved "m=" as line.

   In addition, in either case above, the Offerer's BUNDLE address, answerer MUST NOT in the SDP
   answer include a mid value value, associated with the moved "m=" line is placed first line, in
   the
   list, according to SDP 'group:BUNDLE' attribute mid list associated with the procedures in Section 6.4.2.

   Section 10.3 shows an example of an Offer used to add an "m=" line to
   a BUNDLE
   group.

6.4.5.  Moving

5.2.4.5.  Rejecting A Media Description Out Of In A BUNDLE Group

   When an Offerer answerer generates an Offer, SDP answer, in which the answerer
   rejects an "m=" line is moved
   out of a BUNDLE group, line, the Offerer answerer MUST in the SDP answer assign a unique an
   address with a zero port value to the moved rejected "m=" line. line, according
   to the procedures in [RFC4566].

   In addition, the Offerer answerer MUST NOT anymore in the SDP answer include a mid
   value, representing associated with the rejected "m=" line, in the SDP
   group:BUNDLE
   'group:BUNDLE' attribute mid list associated with the BUNDLE group.

   Section 10.4 shows an example of an Offer used to move an "m=" line
   out

5.2.5.  Offerer Processing of a BUNDLE group.

6.4.6.  Disabling A Media Description In A BUNDLE Group the Answer

5.2.5.1.  General

   When an Offerer generates an Offer, in which offerer receives an "m=" line associated
   with a BUNDLE group is disabled, SDP answer, the Offerer offerer MUST assign an apply the
   selected offerer BUNDLE address
   with a zero port value [RFC4566] to the disabled each bundled "m=" line.  In
   addition,  If the Offerer MUST NOT anymore include
   offerer generates a mid value,
   representing subsequent SDP offer, the "m=" line, offerer MUST in the SDP group:BUNDLE attribute mid
   list associated with
   offer assign the offerer BUNDLE group.

   OPEN ISSUE (Q8): It still needs to be decided whether a zero port
   value can be assigned to a 'bundle-only' "m=" line.

   o  (http://www.ietf.org/mail-archive/web/mmusic/current/
      msg12075.html)

   o  (http://www.ietf.org/mail-archive/web/mmusic/current/
      msg12226.html)

   o  (http://www.ietf.org/mail-archive/web/mmusic/current/
      msg12339.html)

   Section 10.5 shows an example of an Offer used address to disable an each bundled "m=" line in a BUNDLE group.

6.5.
   (including any 'bundle-only' "m=" line) [Section 5.2.6].

   If the SDP Answerer Procedures
6.5.1.  Offerer Bundle Address Selection

   When an Answerer generates an Answer that contains answer does not contain a BUNDLE group, the Answer offerer MUST select
   cease to use any procedure associated with the Offerer's BUNDLE address.  The first mid
   value in the SDP group:BUNDLE attribute mid list of mechanism.

5.2.5.2.  Bundle Address Synchronization (BAS)

   If the Offer
   represents selected offerer BUNDLE address is different than the address which
   that the Offerer wishes offerer in the Answer to select
   as associated SDP offer assigned to a bundled
   "m=" line (including an "m=" line that the offerer in the Offerer's SDP offer
   added to an existing BUNDLE address Section 6.4.2.

   The Answerer SHOULD select group [Section 5.2.6.2]), and the address represented bundled
   "m=" line was not rejected [Section 5.2.4.5], or moved out of the
   BUNDLE group [Section 5.2.4.4] by the first mid
   value, unless answerer, the Answerer offerer SHOULD as
   soon as possible generate a subsequent SDP offer, in which the associated Answer will reject
   offerer assigns the offerer BUNDLE address to each bundled "m=" line associated with the mid value, or remove line.
   This procedure is referred to as Bundle Address Synchronization
   (BAS), and the "m=" line from SDP offer is referred to as a BAS Offer.

   The offerer MAY in the BUNDLE group.  In such case BAS offer modify any SDP parameter.

   NOTE: It is important that the Answerer MUST select an address
   associated with BAS offer gets accepted by the first unrejected mid value
   answerer.  For that remains in reason the
   SDP group:BUNDLE attribute mid list of offerer needs to consider the Offer.

   In
   necessity to in the BAS offer modify SDP Answer, parameters that could get
   the Answerer MUST place answerer to reject the mid value associated
   with BAS offer.  Disabling "m=" lines, or
   reducing the selected Offerer's BUNDLE address first number of codecs, in a BAS offer is considered to have a
   low risk of being rejected.

   NOTE: The main purpose of the SDP
   group:BUNDLE attribute mid list associated with BAS offer is to ensure that
   intermediaries, that might not support the BUNDLE group.

   Section 10.1 mechanism, have
   correct information regarding the address is going to be used to
   transport the bundled media.

   [Section 12.1] shows an example of where an Offerer's BUNDLE address
   selection.

6.5.2.  Anwerer Bundle Address Selection offerer sends a BAS offer.

5.2.6.  Modifying the Session

5.2.6.1.  General

   When an Answerer creates an Answer that contains offerer generates a BUNDLE group, subsequent SDP offer, the
   Answerer offerer MUST assign a local shared address, in
   the Answerer's SDP offer assign the previously selected offerer BUNDLE
   address, address
   [Section 5.2.4.2] to each bundled "m=" line within (including any bundle-
   only "m=" line), unless the offerer in the SDP offer moves the "m="
   line out of the BUNDLE group.

   The Answerer is allowed group [Section 5.2.6.3], or disables the "m="
   line [Section 5.2.6.4].

   If the SDP offerer in the SDP offer adds an "m=" line to change its the BUNDLE
   group [Section 5.2.6.2], the offerer MAY assign the previously
   selected offerer BUNDLE address to the added "m=" line.

   In addition, the offerer MUST in any the SDP
   Answer. offer indicate which address
   (unique or previously selected offerer BUNDLE address) it wants the
   answerer to select as the offerer BUNDLE address, following the
   procedures in [Section 5.2.3.2].  The Answerer offerer MUST NOT assign do this even if
   the offerer in the SDP offer assigns a shared address, that it has assigned previously selected offerer
   BUNDLE address to each bundled "m=" line.

5.2.6.2.  Adding a media description to a BUNDLE group

   When an offerer generates an SDP offer, in which the offerer wants to
   add an "m=" line within to a BUNDLE group, the offerer assigns in the SDP
   offer an address (unique or previously selected offerer BUNDLE
   address) to the "m=" line, assigns an SDP 'mid' attribute to the "m=" line outside
   line, and places the mid value in the SDP 'group:BUNDLE' attribute
   mid list associated with the BUNDLE group.

   Section 10.1 group [Section 5.2.3.2].

   NOTE: If the offerer wants that the answerer selects the address
   associated with the added "m=" as the offerer BUNDLE address, the
   offerer suggested BUNDLE mid MUST represent the added "m=" line
   [Section 5.2.3.2].

   [Section 12.3] shows an example of where an Answerer's local offerer sends an SDP offer
   in order to add an "m=" line to a BUNDLE address
   selection.

6.5.3. group.

5.2.6.3.  Moving A Media Description Out Of A BUNDLE Group

   When an Answerer offerer generates an Answer, SDP offer, in which an the offerer wants to
   move a bundled "m=" line is moved out of a BUNDLE group, the Answerer assigns an offerer MUST
   assign a unique address to the moved "m=" line based on line.  In addition, the type of address that offerer
   MUST NOT place a mid value associated with the Offerer assigned to
   the associated "m=" line in the SDP
   'group:BUNDLE' attribute mid list associated Offer, as described below.

   If with the Offerer assigned BUNDLE group.

   NOTE: The offerer MAY keep a shared address to the "m=" line, the
   answerer MUST reject the moved "m=" line, according to the procedures
   in Section 6.5.4.

   If the Offerer previously assigned an SDP 'bundle-only' 'mid' attribute to the "m="
   line, the Answerer MUST reject the moved
   in an "m=" line, according line that it wants to the
   procedures in Section 6.5.4.

   If the Offerer assigned move out of a unique address to the "m=" line, BUNDLE group, e.g. if
   the Answer
   MUST assign a unique address mid value is used for some other SDP grouping extension than
   BUNDLE.

   [Section 12.4] shows an example where an offerer sends an SDP offer
   in order to the moved move an "m=" line.

   In addition, in either case above, the Answerer MUST NOT anymore
   include line out of a mid value, representing the "m=" line, in the SDP
   group:BUNDLE attribute list associated with the BUNDLE group.

6.5.4.  Rejecting

5.2.6.4.  Disabling A Media Description In A BUNDLE Group

   When an Answerer offerer generates an Answer, SDP offer, in which an "m=" line
   associated with the offerer wants to
   disable a BUNDLE group is rejected, bundled "m=" line, the Answerer offerer MUST assign an address with
   a zero port value alue to the rejected "m=" line,
   according to following the procedures in
   [RFC4566].  In addition, the Answerer offerer MUST NOT anymore include place a mid value, representing value
   associated with the "m=" line, line in the SDP group:BUNDLE 'group:BUNDLE' attribute midlist mid
   list associated with the BUNDLE group.

7.  Single vs Multiple RTP Sessions

7.1.  General

   By default, all RTP based media flows

   NOTE: The offerer MAY assign an SDP 'mid' attribute to an "m=" line
   that it wants to disable, e.g. if the mid value is used for some
   other SDP grouping extension than BUNDLE.

   [Section 12.5] shows an example where an offerer sends an SDP offer
   in order to disable an "m=" line within a given BUNDLE group
   belong to group.

6.  SDP 'bundle-only' Attribute

6.1.  General

   This section defines a single RTP session [RFC3550].  Multiple BUNDLE groups
   will form multiple RTP Sessions.

   The usage of multiple RTP Sessions within new SDP media-level attribute [RFC4566],
   'bundle-only'.  An offerer can in an SDP offer assign a given BUNDLE group, or
   the usage of 'bundle-only'
   "m=" line to a single RTP Session bundled "m=" line (including an "m=" line that spans over multiple BUNDLE
   groups, is outside the scope of this specification.  Other
   specification needs
   offerer wants to add to extend the BUNDLE mechanism group [Section 5.2.6.2]), in order
   to allow
   such usages.

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, ensure that the following rules and restrictions apply for a single
   RTP Session:

   o  The dynamic payload type values used in answerer only accepts 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 if the same SSRC.  If transmission of multiple media types are done
   with time overlap RTP
   answerer supports the BUNDLE mechanism, and RTCP fails to function.  Even if done the answerer 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
   SDP answer keeps the "m=" line within the BUNDLE grouping extension
   together with group.

6.2.  SDP Offer/Answer Procedures

6.2.1.  Generating the Interactive Connectivity Establishment (ICE)
   mechanism [RFC5245].

8.2.  Candidates Initial Offer

   When an ICE-enabled endpoint offerer generates an initial SDP Offer, which contains offer, in order to create a
   BUNDLE group, the offerer can in the SDP Offerer MUST include ICE candidates for each
   "m=" offer assign an SDP 'bundle-
   only' attribute to an "m=" line that the offerer wants to be within
   the BUNDLE group.

   The offerer MUST in the SDP offer assign a zero port value the
   bundle-only "m=" line.

6.2.2.  Generating the Answer

   When the answerer selects the offerer BUNDLE address
   [Section 5.2.4.2], the answerer MUST also take a bundle-only "m="
   line associated with a "BUNDLE" group, except for non-zero port value into consideration.

   If the offerer in the SDP offer has assigned a zero port value to a
   bundle-only "m=" line, and if the answerer accepts the "m=" line, the
   answerer will treat the "m=" line as any other bundle "m=" line
   with when
   the answerer generates the SDP answer [Section 5.2.4].

   NOTE: If the offerer in the SDP offer has assigned a zero port number value. value
   to a bundled "m=" line, but the offerer has not assigned a 'bundle-
   only' SDP attribute to the "m=" line, it is an indication that the
   offerer wants to disable the "m=" line [Section 5.2.6.4].

   If the answerer in the SDP answer does not keep the bundle-only "m=" lines
   line within the BUNDLE group, the answerer MUST in the SDP answer
   reject the "m=" line [Section 5.2.4.5].

   The answerer MUST NOT in the SDP answer assign an SDP 'bundle-only'
   attribute to an "m=" line (even if the offerer in the associated SDP
   offer has assigned a 'bundle-only' attribute to the "m="line).

6.2.3.  Offerer Processing of the Answer

   When the offerer receives an SDP answer, the offerer follows the
   procedures in [Section 5.2.5].  If the offerer in the associated SDP
   offer assigned an SDP 'bundle-only' attribute to an "m=" line, and
   the "m=" line was accepted (and was kept within the BUNDLE group) by
   the answerer, the selected offerer BUNDLE address also applies to the
   "m=" line.

6.2.4.  Modifying the Session

   When an offerer creates a subsequent SDP offer, the offerer follows
   the procedures in [Section 5.2.6].  If the offerer in the SDP offer
   assigns an SDP 'bundle-only' attribute to a bundled "m=" line, in
   order to ensure that the answerer accepts the "m=" line only if the
   answerer keeps the "m=" line within the BUNDLE group, the offerer
   MUST NOT assign a zero port value to the "m=" line.  Instead, the
   offerer MUST in the SDP offer assign the offerer BUNDLE address or,
   if the "m=" line is added to the BUNDLE group [Section 5.2.6.2],
   either the offerer BUNDLE address or a unique address, to the "m="
   line.

   NOTE: The offerer can in a subsequent SDP offer assign an SDP
   'bundle-only' attribute to a bundled "m=" line even if the offerer
   did not assign a 'bundle-only' attribute to the "m=" line in a
   previous SDP offer.

   If the offerer in the SDP offer wants to move a bundled "m=" line out
   of a BUNDLE group [Section 5.2.6.3], the offerer MUST NOT in the SDP
   offer assign a 'bundle-only' attribute to the "m=" line.

   If the offerer in the SDP offer wants to disable a bundled "m=" line
   [Section 5.2.6.4], the offerer MUST NOT in the SDP offer assign a
   'bundle-only' attribute to the "m=" line.

7.  Protocol Identification

7.1.  General

   If bundled "m=" lines represent different transport protocols, there
   MUST exist a specification which describes a mechanism, for this
   specific transport protocol combination, how to associate a received
   packet with the correct transport protocol.

   In addition, if a received packet can be associated with more than
   one bundled "m=" line, there MUST exist a specification which
   describes a mechanism how to associated the received packet with the
   correct "m=" line.

7.2.  STUN, DTLS, SRTP

   Section 5.1.2 of [RFC5764] describes a mechanism how to identify the
   protocol among the STUN, DTLS and SRTP protocols (in any
   combination).  If an offer or answerer in SDP offers or answers
   include bundled "m=" lines that represent these protocols, the
   offerer or answerer MUST support the mechanism described in
   [RFC5764], and no explicit negotiation is required in order to
   indicate support and usage of the mechanism.

   [RFC5764] does not describe how to identify different protocols
   transported on DTLS, only how to identify the DTLS protocol itself.
   If multiple protocols are transported on DTLS, there MUST exist a
   specification describing a mechanism how to identify each individual
   protocol.  In addition, if a received DTLS packet can be associated
   with more than one "m=" line, there MUST exist a specification which
   describes a mechanism how to associate the received DTLS packet with
   the correct "m=" line.

   [Section 8.2] describes how to associate a received (S)RTP packet
   with the correct "m=" line.

8.  RTP Considerations

8.1.  Single RTP Session

8.1.1.  General

   By default, all RTP based media within a BUNDLE group belong to a
   single RTP session [RFC3550].  Multiple BUNDLE groups will form
   multiple RTP Sessions.

   NOTE: The usage of multiple RTP sessions within a BUNDLE group, or
   the usage of a single RTP session that spans over multiple BUNDLE
   groups, is outside the scope of this specification.  Other
   specification needs to extend the BUNDLE mechanism in order to allow
   such usages.

   When a single RTP session is used, all bundled "m=" lines
   representing RTP based media share a single SSRC numbering space
   [RFC3550].

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

   o  A specific payload type value can be used in multiple bundled "m="
      lines if each codec associated with the payload type number shares
      an identical codec configuration [Section 8.1.2].

   o  The "proto" value in each bundled "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 bundled "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.1.2.  Payload Type (PT) Value Re-usage

   Multiple bundled "m=" lines might represent RTP based media.  As all
   RTP based media associated with a BUNDLE group belong to the same RTP
   session, in order for a given payload type value to used inside more
   than one bundled "m=" line, all codecs associated with the payload
   type numbers MUST share an identical codec configuration.  This means
   that the codecs MUST share the same media type, encoding name, clock
   rate and any parameter that can affect the codec configuration and
   packetization.  [I-D.nandakumar-mmusic-sdp-mux-attributes] lists SDP
   attributes, which attribute values must be identical for all codecs
   that use the same payload type value.

8.2.  Associating RTP Packets With Correct SDP Media Description

   In general, there are multiple mechanisms that can be used by an
   endpoint in order to associate received RTP packets with the bundled
   "m=" line representing the RTP packets.  Such mechanisms include
   using the local address:port combination on which the RTP packets are
   received, the payload type value carried inside the RTP packets, the
   SSRC values carried inside the RTP packets, and other "m=" line
   specific information carried inside the RTP packets.

   As all RTP packets associated with a BUNDLE group are sent and
   received using the same 5-tuple, the local address:port combination
   cannot be used to associate received RTP packets with the correct
   "m=" line.

   As described in [Section 8.1.2], the same payload type value might be
   used inside RTP packets described by multiple "m=" lines.  In such
   cases, the payload type value cannot be used to associate received
   RTP packets with the correct "m=" line.

   An offerer and answerer can in an SDP offer and answer inform each
   other which SSRC values they will use inside sent RTP packets by, by
   assigning an SDP 'ssrc' attribute [RFC5576] to each bundled "m=" line
   which contains a payload type value that is also used inside another
   bundled "m=" line.  As the SSRC values will be carried inside the RTP
   packets, the offerer and answerer can then use that information to
   associate received RTP packets with the correct "m=" line.  However,
   an offerer will not know which SSRC values the answerer will use
   until it has received the SDP answer providing that information.  Due
   to this, before the offerer has received the SDP answer, the offerer
   will not be able to associate received RTP packets with the correct
   "m=" line using the SSRC values.

   In order for an offerer and answerer to always be able to associate
   received RTP packets with the correct "m=" line, the offerer and
   answerer MUST in an SDP offer and answer assign an SDP "receiver-id"
   attribute [receiver-id-reference-to-be-added] to each bundled "m="
   line which contains a payload type value that is also used inside
   another bundled "m=" line.  If an answerer accepts such "m=" line,
   and keeps it within the BNDLE group, the answerer MUST insert the
   'receiver-id' attribute value in RTP packets, associated with the
   "m=" line, sent towards the offerer.

   OPEN ISSUE: We need a mechanism that implements the 'receiver-id'
   mechanism and the associated SDP attribute.

8.3.  RTP/RTCP Multiplexing

8.3.1.  General

   When a BUNDLE group, which contains RTP based media, is created, the
   offerer and answerer MUST negotiate whether to enable RTP/RTCP
   multiplexing for the RTP based media associated with the BUNDLE group
   [RFC5761].

   If RTP/RTCP multiplexing is not enabled, separate 5-tuples will be
   used for sending and receiving the RTP packets and the RTCP packets.

8.3.2.  SDP Offer/Answer Procedures

8.3.2.1.  General

   This section describes how an offerer and answerer can use the SDP
   'rtcp-mux' attribute [RFC5761] and the SDP 'rtcp' attribute [RFC3605]
   to negotiate usage of RTP/RTCP multiplexing for RTP based associated
   with a BUNDLE group.

8.3.2.2.  Generating the Initial Offer

   When an offerer generates an initial SDP offer, if the offerer wants
   to negotiate usage of RTP/RTCP multiplexing within a BUNDLE group,
   the offerer MUST in the SDP offer assign an SDP 'rtcp-mux' attribute
   [RFC5761] to each bundled "m=" line (including any bundle-only "m="
   line).  In addition, the offerer MUST in the SDP offer assign an SDP
   'rtcp' attribute [RFC3605] to each bundled "m=" line (including any
   bundle-only "m=" line), with an attribute value that is identical to
   the port value assigned to the "m=" line itself.

   If the offerer does not want to negotiate usage of RTP/RTCP
   multiplexing, the offerer MUST NOT assign the SDP attributes above to
   any bundled "m=" line.

8.3.2.3.  Generating the Answer

8.3.2.3.1.  Generating the Answer to an Initial Offer

   When the answerer generates an SDP answer to an initial SDP offer, if
   the offerer in the associated SDP offer indicated support of RTP/RTCP
   multiplexing [RFC5761] within a BUNDLE group, the answerer MUST in
   the SDP answer either accept or reject usage of RTP/RTCP
   multiplexing.

   If the answerer accepts usage of RTP/RTCP multiplexing within the
   BUNDLE group, the answerer MUST in the SDP answer assign an SDP
   'rtcp-mux' attribute to each bundled "m=" line.  The answerer MUST
   NOT in the SDP answer assign an SDP 'rtcp' attribute to any bundled
   "m=" line.

   OPEN ISSUE: Do we want to include the SDP 'rtcp' attribute also in
   the SDP answer, eventhough it is not needed?

   If the answerer rejects usage of RTP/RTCP multiplexing within the
   BUNDLE group, the answerer MUST NOT in the SDP answer assign an SDP
   'rtcp-mux' or SDP 'rtcp' attribute to any bundled "m=" line.

8.3.2.3.2.  Generating the Answer to a Subsequent Offer

   When the answerer generates an SDP answer to a subsequent SDP offer,
   if the offerer in the associated SDP offer indicated support of RTP/
   RTCP multiplexing [RFC5761] within a BUNDLE group, the answerer MUST
   in the SDP answer assign an SDP 'rtcp-mux' attribute and SDP 'rtcp'
   attribute to each bundled "m=" line.

   NOTE: The BUNDLE mechanism does not allow the answerer to, in a
   subsequent SDP answer, disable usage of RTP/RTCP multiplexing, if the
   offerer in the associated SDP offer indicates that it wants to
   continue using RTP/RTCP multiplexing.

8.3.2.4.  Offerer Processing of the Answer

   When the offerer receives an SDP answer, it follows the procedures
   defined in [RFC5245].

8.3.2.5.  Modifying the Session

   When an offerer generates a subsequent SDP offer, if the offerer
   wants to negotiate usage of RTP/RTCP multiplexing within a BUNDLE
   group, or if the offerer wants to continue usage of previously
   negotiated RTP/RTCP multiplexing within the BUNDLE group, the offerer
   MUST in the SDP offer assign 'rtcp-mux' and 'rtcp' attributes to each
   bundled "m=" line (including bundle-only "m=" lines), unless the "m="
   line is disabled or removed from the BUNDLE group.

   If the offerer does not want to negotiate usage of RTP/RTCP
   multiplexing within the BUNDLE group, or if the offerer wants to
   disable previously negotiated usage of RTP/RTCP multiplexing within a
   BUNDLE group, the offerer MUST NOT in the SDP offer assign 'rtcp-mux'
   and 'rtcp' attributes to any bundled "m=" line.

   NOTE: It is RECOMMENDED that, once usage of RTP/RTCP multiplexing has
   been negotiated within a BUNDLE group, that the usage of not
   disabled.  Disabling RTP/RTCP multiplexing means that the offerer and
   answerer need to reserve new IP ports, to be used for sending and
   receiving RTCP packets.

9.  ICE Considerations

9.1.  General

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

   Support and usage of ICE mechanism together with the BUNDLE mechanism
   is optional.

9.2.  SDP Offer/Answer Procedures

9.2.1.  Generating the Initial Offer

   When an offerer generates an initial SDP offer, which contains a
   BUNDLE group, the offerer MUST assign ICE candidates [RFC5245] to
   each bundled "m=" line, except to an "m=" line to which the offerer
   assigns a zero port value (e.g. a bundle-only "m=" line).  The
   offerer MUST assign unique ICE candidate values to each "m=" line.

9.2.2.  Generating the Answer

   When an answerer generates and SDP Answer, which contains a BUNDLE
   group, the answerer MUST assign ICE candidates to each bundled "m="
   line.  The answerer MUST assign identical ICE candidate values to
   each bundled "m=" line.

9.2.3.  Offerer Processing of the Answer

   When the offerer receives an SDP answer, it follows the procedures
   defined in [RFC5245].

9.2.4.  Modifying the Session

   When an offerer generates a subsequent SDP offer, for each bundled
   "m=" line to which the offerer assigns its BUNDLE address, the
   offerer MUST assign identical ICE candidate values.  The offerer MUST
   assign the ICE candidate values associated with the "m=" line that
   was used by the answerer to select the offerer BUNDLE address [ref-
   to-be-added].

9.2.5.  Keep-alives

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

10.  Update to RFC 3264

10.1.  General

   This section replaces the text of the following sections of RFC 3264:

   o  Section 5.1 (Unicast Streams).

   o  Section 8.2 (Removing a Media Stream).

   o  Section 8.4 (Putting a Unicast Media Stream on Hold).

10.2.  Original text of section 5.1 (2nd paragraph) of RFC 3264

   For recvonly and sendrecv streams, the port number and address in the
   offer indicate where the offerer would like to receive the media
   stream.  For sendonly RTP streams, the address and port number
   indirectly indicate where the offerer wants to receive RTCP reports.
   Unless there is an explicit indication otherwise, reports are sent to
   the port number one higher than the number indicated.  The IP address
   and port present in the offer indicate nothing about the source IP
   address and source port of RTP and RTCP packets that will be sent by
   the offerer.  A port number of zero in the offer indicates that the
   stream is offered but MUST NOT be used.  This has no useful semantics
   in an initial offer, but is allowed for reasons of completeness,
   since the answer can contain a zero port indicating a rejected stream
   (Section 6).  Furthermore, existing streams can be terminated by
   setting the port to zero (Section 8).  In general, a port number of
   zero indicates that the media stream is not wanted.

10.3.  New text replacing section 5.1 (2nd paragraph) of RFC 3264

   For recvonly and sendrecv streams, the port number and address in the
   offer indicate where the offerer would like to receive the media
   stream.  For sendonly RTP streams, the address and port number
   indirectly indicate where the offerer wants to receive RTCP reports.
   Unless there is an explicit indication otherwise, reports are sent to
   the port number one higher than the number indicated.  The IP address
   and port present in the offer indicate nothing about the source IP
   address and source port of RTP and RTCP packets that will be sent by
   the offerer.  A port number of zero in the offer by default indicates
   that the stream is offered but MUST NOT be used, but an extension
   mechanism might specify different semantics for the usage of a zero
   port value.  Furthermore, existing streams can be terminated by
   setting the port to zero (Section 8).  In general, a port number of
   zero by default indicates that the media stream is not wanted.

10.4.  Original text of section 8.2 (2nd paragraph) of RFC 3264

   A stream that is offered with a port of zero MUST be marked with port
   zero in the answer.  Like the offer, the answer MAY omit all
   attributes present previously, and MAY list just a single media
   format from amongst those in the offer.

10.5.  New text replacing section 8.2 (2nd paragraph) of RFC 3264

   A stream that is offered with a port of zero MUST by default be
   marked with port zero in the answer, unless an extension mechanism,
   which specifies semantics for the usage of a non-zero port value, is
   used.

10.6.  Original text of section 8.4 (6th paragraph) of RFC 3264

   RFC 2543 [10] specified that placing a user on hold was accomplished
   by setting the connection address to 0.0.0.0.  Its usage for putting
   a call on hold is no longer recommended, since it doesn't allow for
   RTCP to be used with held streams, doesn't work with IPv6, and breaks
   with connection oriented media.  However, it can be useful in an
   initial offer when the offerer knows it wants to use a particular set
   of media streams and formats, but doesn't know the addresses and
   ports at the time of the offer.  Of course, when used, the port
   number MUST NOT be zero, which would specify that the stream has been
   disabled.  An agent MUST be capable of receiving SDP with a
   connection address of 0.0.0.0, in which case it means that neither
   RTP nor RTCP should be sent to the peer.

10.7.  New text replacing section 8.4 (6th paragraph) of RFC 3264

   RFC 2543 [10] specified that placing a user on hold was accomplished
   by setting the connection address to 0.0.0.0.  Its usage for putting
   a call on hold is no longer recommended, since it doesn't allow for
   RTCP to be used with held streams, doesn't work with IPv6, and breaks
   with connection oriented media.  However, it can be useful in an
   initial offer when the
   BUNDLE group contain different port number values, offerer knows it wants to use a particular set
   of media streams and formats, but doesn't know the SDP Offerer
   MUST also insert different candidate values in each "m=" line
   associated with addresses and
   ports at the BUNDLE group.  If time of the "m=" lines associated with offer.  Of course, when used, the BUNDLE group contain an identical port
   number value, the
   candidate values MUST also NOT be identical.

   When an ICE-enabled endpoint generates and SDP Answer, which contains
   a BUNDLE group, the Answerer MUST include ICE candidates for each
   "m=" line associated with zero, if it would specify that the "BUNDLE" group, except for any "m="
   line where stream has been
   disabled.  However, an extension mechanism might specify different
   semantics of the zero port number value is set to zero.  The Answerer usage.  An agent MUST
   insert identical candidate values in each "m=" line associated be capable of
   receiving SDP with
   the BUNDLE group.

8.3.  Candidates

   Once a connection address of 0.0.0.0, in which case it is known
   means that both endpoints support, and accept to use, the
   BUNDLE grouping extension, ICE connectivity checks and keep-alives
   only needs to neither RTP nor RTCP should be performed for the whole BUNDLE group, instead of for
   each individual "m=" line associated with sent to the group.

9. peer.

11.  Security Considerations

   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.

12.  Examples

10.1.

12.1.  Example: Bundle Address Selection

   The example below shows:

   o  1.  An SDP Offer, offer, in which the Offerer offerer assigns a unique addresses address to
      each bundled "m=" line in the BUNDLE group, and requests the Answerer to
      select within the Offerer's BUNDLE address. group.

   o  2.  An SDP Answer, answer, in which the Answerer answerer selects the offerer
      BUNDLE
      address for the Offerer, address, and assigns in which selects its own local BUNDLE address
      to (the
      answerer BUNDLE address) and assigns it each bundled "m=" line in
      within the BUNDLE group.

   o  3.  A subsequent SDP Offer, offer (BAS offer), which is used to perform a
      Bundle Address Synchronization (BAS).

   SDP Offer (1)

       v=0
       o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
       s=
       c=IN IP4 atlanta.example.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 10002 RTP/AVP 31 32
       a=mid:bar
       b=AS:1000
       a=rtpmap:31 H261/90000
       a=rtpmap:32 MPV/90000

   SDP Answer (2)

       v=0
       o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
       s=
       c=IN IP4 biloxi.example.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 Offer (3)

       v=0
       o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
       s=
       c=IN IP4 atlanta.example.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

10.2.

12.2.  Example: Bundle Mechanism Rejected

   The example below shows:

   o  1.  An SDP Offer, offer, in which the Offerer offerer assigns a unique addresses address to
      each bundled "m=" line in the BUNDLE group, and requests the Answerer to
      select within the Offerer's BUNDLE address. group.

   o  2.  An SDP Answer, answer, in which the Answerer answerer rejects the offered
      BUNDLE group, and assigns a unique addresses to each "m=" line. line
      (following normal RFC 3264 procedures).

   SDP Offer (1)

       v=0
       o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
       s=
       c=IN IP4 atlanta.example.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 10002 RTP/AVP 31 32
       a=mid:bar
       b=AS:1000
       a=rtpmap:31 H261/90000
       a=rtpmap:32 MPV/90000

   SDP Answer (2)

       v=0
       o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
       s=
       c=IN IP4 biloxi.example.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

10.3.

12.3.  Example: Offerer Adds A Media Description To A BUNDLE Group

   The example below shows:

   o  1.  An SDP Offer, offer, in which the Offerer offerer adds an a new "m=" line,
      represented by the "zen" mid value, to a previously negotiated
      BUNDLE group, assigns a unique address to the added "m=" line, and
      assigns the previously negotiated selected offerer BUNDLE address to each of
      the previously
      added other bundled "m=" lines in within the BUNDLE group.

   o  2.  An SDP Answer, answer, in which the Answerer answerer assigns its own local the answerer
      BUNDLE address to each bundled "m=" line (including the newly
      added "m=" line)
      in within the BUNDLE group.

   o  3.  A subsequent SDP Offer, offer (BAS offer), which is used to perform a
      Bundle Address Synchronization (BAS).

   SDP Offer (1)

       v=0
       o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
       s=
       c=IN IP4 atlanta.example.com
       t=0 0
       a=group:BUNDLE foo bar zen
       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
       m=video 20000 RTP/AVP 66
       a=mid:zen
       b=AS:1000
       a=rtpmap:66 H261/90000

   SDP Answer (2)

       v=0
       o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
       s=
       c=IN IP4 biloxi.example.com
       t=0 0
       a=group:BUNDLE foo bar zen
       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
       m=video 20000 RTP/AVP 66
       a=mid:zen
       b=AS:1000
       a=rtpmap:66 H261/90000

   SDP Offer (3)

       v=0
       o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
       s=
       c=IN IP4 atlanta.example.com
       t=0 0
       a=group:BUNDLE foo bar zen
       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
       m=video 10000 RTP/AVP 66
       a=mid:zen
       b=AS:1000
       a=rtpmap:66 H261/90000

10.4.

12.4.  Example: Offerer Moves A Media Description Out Of A BUNDLE Group

   The example below shows:

   o  1.  An SDP Offer, offer, in which the Offerer offerer moves an a bundled "m=" line
      out of a
      previously negotiated BUNDLE group, assigns a unique address to the moved "m="
      line, and assigns the previously negotiated offerer BUNDLE address to the remaining each other bundled
      "m=" lines in line within the BUNDLE group.

   o  2.  An SDP Answer, answer, in which the Answerer answerer moves the corresponding "m=" line out
      of the BUNDLE group, and assigns unique address to the moved "m="
      line, and assigns the previously negotiated answerer BUNDLE address to the remaining each other
      bundled "m=" lines in line within the BUNDLE group.

   SDP Offer (1)

       v=0
       o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
       s=
       c=IN IP4 atlanta.example.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
       m=video 50000 RTP/AVP 66
       b=AS:1000
       a=rtpmap:66 H261/90000

   SDP Answer (2)

       v=0
       o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
       s=
       c=IN IP4 biloxi.example.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
       m=video 60000 RTP/AVP 66
       b=AS:1000
       a=rtpmap:66 H261/90000

10.5.

12.5.  Example: Offerer Disables A Media Description In Within A BUNDLE
       Group

   The example below shows:

   o  1.  An SDP Offer, offer, in which the Offerer moves an offerer disables a bundled "m="
      line out of a
      previously negotiated within BUNDLE group, assigns a zero port number the
      moved disabled
      "m=" line in order to disable it, line, and assigns the previously
      negotiated offerer BUNDLE address to each of the remaining
      other bundled "m=" lines in within the BUNDLE group.

   o  2.  An SDP Answer, answer, in which the Answerer answerer moves the corresponding disabled "m="
      line out of the BUNDLE group, and assigns a zero port value to the moved
      disabled "m=" line in order to disable it, line, and assigns the
      previously negotiated answerer BUNDLE address to
      each of the remaining other bundled "m=" lines
      in within the BUNDLE group.

   SDP Offer (1)

       v=0
       o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
       s=
       c=IN IP4 atlanta.example.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
       m=video 0 RTP/AVP 66
       a=rtpmap:66 H261/90000

   SDP Answer (2)

       v=0
       o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
       s=
       c=IN IP4 biloxi.example.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
       m=video 0 RTP/AVP 66
       a=rtpmap:66 H261/90000

11.

13.  IANA Considerations

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

12.

14.  Acknowledgements

   The usage of the SDP grouping extension for negotiating bundled media
   is based on a similar alternatives proposed by Harald Alvestrand and
   Cullen Jennings.  The BUNDLE mechanism described in this document is
   based on the different alternative proposals, and text (e.g. SDP
   examples) have been borrowed (and, in some cases, modified) from
   those alternative proposals.

   The SDP examples are also modified versions from the ones in the
   Alvestrand proposal.

   Thanks to Paul Kyzivat and Martin Thompson for taking the the time to
   read the text along the way, and providing useful feedback.

13.

15.  Change Log

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

   Changes from draft-ietf-mmusic-sdp-bundle-negotiation-05

   o  Major re-structure of SDP Offer/Answer sections, to align with RFC
      3264 structure.

   o  Additional definitions added.

   o  - Shared address.

   o  - Bundled "m=" line.

   o  - Bundle-only "m=" line.

   o  - Offerer suggested BUNDLE mid.

   o  - Answerer selected BUNDLE mid.

   o  Q6 Closed (IETF#88): An Offerer MUST NOT assign a shared address
      to multiple "m=" lines until it has received an SDP Answer
      indicating support of the BUNDLE mechanism.

   o  Q8 Closed (IETF#88): An Offerer can, before it knows whether the
      Answerer supports the BUNDLE mechanism, assign a zero port value
      to a 'bundle-only' "m=" line.

   o  SDP 'bundle-only' attribute section added.

   o  Connection data nettype/addrtype restrictions added.

   o  RFC 3264 update section added.

   o  Indicating that a specific payload type value can be used in
      multiple "m=" lines, if the value represents the same codec
      configuration in each "m=" line.

   Changes from draft-ietf-mmusic-sdp-bundle-negotiation-04

   o  Updated Offerer procedures (http://www.ietf.org/mail-archive/web/
      mmusic/current/msg12293.html).

   o  Updated Answerer procedures (http://www.ietf.org/mail-archive/web/
      mmusic/current/msg12333.html).

   o  Usage of SDP 'bundle-only' attribute added.

   o  Reference to Trickle ICE document added.

   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.

14.

16.  References

14.1.

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

   [RFC5761]  Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
              Control Packets on a Single Port", RFC 5761, April 2010.

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

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

14.2. February 2014.

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

   [RFC3605]  Huitema, C., "Real Time Control Protocol (RTCP) attribute
              in Session Description Protocol (SDP)", RFC 3605, October
              2003.

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

   [RFC5576]  Lennox, J., Ott, J., and T. Schierl, "Source-Specific
              Media Attributes in the Session Description Protocol
              (SDP)", RFC 5576, June 2009.

   [RFC5764]  McGrew, D. and E. Rescorla, "Datagram Transport Layer
              Security (DTLS) Extension to Establish Keys for the Secure
              Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.

   [I-D.ietf-mmusic-trickle-ice]
              Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE:
              Incremental Provisioning of Candidates for the Interactive
              Connectivity Establishment (ICE) Protocol ", Protocol", draft-ietf-
              mmusic-trickle-ice-00
              mmusic-trickle-ice-01 (work in progress), October 2013. February 2014.

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 atlanta.example.com
       s=
       c=IN IP4 atlanta.example.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 biloxi.example.com
       s=
       c=IN IP4 biloxi.example.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 atlanta.example.com
       s=
       c=IN IP4 atlanta.example.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 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 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 atlanta.example.com
       s=
       c=IN IP4 atlanta.example.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 port) in
   order to control traffic gating functions, and 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 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 each port.
   This takes approximately 20 ms extra for 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
   one of the "m=" lines and then use trickle ICE
   [I-D.ietf-mmusic-trickle-ice] 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