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

 Multiplexing Negotiation Using Session Description Protocol (SDP) Port
                                Numbers
            draft-ietf-mmusic-sdp-bundle-negotiation-03.txt
            draft-ietf-mmusic-sdp-bundle-negotiation-04.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 media associated
   with multiple SDP media descriptions ("m=" lines).

Status of this 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 22, December 16, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   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 . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Applicability Statement . . . . . . . . . . . . . . . . . . .  4   5
   5.  SDP Grouping Framework BUNDLE Extension Semantics . . . . . .  4   5
   6.  SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . .  4   5
     6.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   5
     6.2.  Bundled SDP Offerer Procedures . Information . . . . . . . . . . . . . . . . .   5
     6.3.  SDP Answerer Procedures
       6.2.1.  General . . . . . . . . . . . . . . . . .  7
     6.4.  Bundled SDP Information . . . . . .   5
       6.2.2.  Bandwidth (b=)  . . . . . . . . . . .  7
       6.4.1.  General . . . . . . . .   6
       6.2.3.  rtcp-mux Attribute  . . . . . . . . . . . . . . .  7
       6.4.2.  Bandwidth (b=) . .   6
       6.2.4.  rtcp Attribute  . . . . . . . . . . . . . . . . . .  7
       6.4.3.  Attributes (a=) .   6
       6.2.5.  DTLS-SRTP fingerprint Attribute . . . . . . . . . . .   6
       6.2.6.  SDES crypto Attribute . . . . . . .  7
   7.  Single vs Multiple RTP Sessions . . . . . . . . .   6
       6.2.7.  Other Attributes (a=) . . . . . .  8
     7.1.  General . . . . . . . . . .   6
     6.3.  RFC 5888 restrictions . . . . . . . . . . . . . . .  8
     7.2.  Single RTP Session . . .   6
     6.4.  SDP Offerer Procedures  . . . . . . . . . . . . . . . . .  8
   8.   6
       6.4.1.  SDP Offerer Bundle Address Request and Usage With ICE .  . . . .   7
       6.4.2.  Bundle Address Synchronization (BAS)  . . . . . . . .   7
       6.4.3.  Adding a media description to a BUNDLE group  . . . .   8
       6.4.4.  Moving A Media Description Out Of A BUNDLE Group  . .   8
       6.4.5.  Disabling A Media Description In A BUNDLE Group . . .   9
     6.5.  SDP Answerer Procedures . .  8
     8.1.  General . . . . . . . . . . . . . . .   9
       6.5.1.  Answerer Bundle Address Selection and Usage . . . . .   9
       6.5.2.  Moving A Media Description Out Of A BUNDLE Group  . .  10
       6.5.3.  Rejecting A Media Description In A BUNDLE Group . . .  8
     8.2.  Candidates  10
   7.  Single vs Multiple RTP Sessions . . . . . . . . . . . . . . .  11
     7.1.  General . . . . . . . . .  9
     8.3.  Candidates . . . . . . . . . . . . . . . .  11
     7.2.  Single RTP Session  . . . . . . . .  9
   9.  Security Considerations . . . . . . . . . . .  11
   8.  Usage With ICE  . . . . . . . .  9
   10. Example: SDP Offer with different port number values . . . . .  9
   11. Example: SDP Offer with identical port number values . . . . . 11
   12. IANA Considerations . . . . .  11
     8.1.  General . . . . . . . . . . . . . . . . 13
   13. Acknowledgements . . . . . . . . .  11
     8.2.  Candidates  . . . . . . . . . . . . . . 13
   14. Change Log . . . . . . . . .  11
     8.3.  Candidates  . . . . . . . . . . . . . . . . . 13
   15. References . . . . . .  12
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   10. Examples  . 14
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 14
     15.2. Informative References . . . . . .  12
     10.1.  Example: Bundle Address Selection  . . . . . . . . . . .  12
     10.2.  Example: Bundle Mechanism Rejected . 14
   Appendix A.  Design Considerations . . . . . . . . . .  14
     10.3.  Example: Offerer Adds A Media Description To A BUNDLE
            Group  . . . . . . 15
     A.1.  General . . . . . . . . . . . . . . . . . . .  15
     10.4.  Example: Offerer Moves A Media Description Out Of A
            BUNDLE Group . . . . . . 15
     A.2.  UA Interoperability . . . . . . . . . . . . . . . .  17

     10.5.  Example: Offerer Disables A Media Description In A
            BUNDLE Group . . . 15
     A.3.  Usage of port number value zero . . . . . . . . . . . . . 16
     A.4.  B2BUA And Proxy Interoperability . . . . . .  18
   11. IANA Considerations . . . . . . . 17 . . . . . . . . . . . . . .  19
   12. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  19
   13. Change Log  . . . . . . . . . . . . . . . . . . . . . . . . .  20
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  21
     14.2.  Informative References . . . . . . . . . . . . . . . . .  21
   Appendix A.  Design Considerations  . . . . . . . . . . . . . . .  21
     A.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .  21
     A.2.  UA Interoperability . . . . . . . . . . . . . . . . . . .  22
     A.3.  Usage of port number value zero . . . . . . . . . . . . .  23
     A.4.  B2BUA And Proxy Interoperability  . . . . . . . . . . . .  24
       A.4.1.  Traffic Policing  . . . . . . . . . . . . . . . . . . . 18  24
       A.4.2.  Bandwidth Allocation  . . . . . . . . . . . . . . . . . 18  25
     A.5.  Candidate Gathering . . . . . . . . . . . . . . . . . . . 18  25
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 18  25

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

   The SDP Offerer and SDP Answerer [RFC3264] use the "BUNDLE" grouping
   extension BUNDLE mechanism to indicate which media is associated with
   negotiate a single
   5-tuple.  For each media, BUNDLE address to be used for the associated "m=" line is bundled media
   associated with a "BUNDLE" BUNDLE group.

   For each "BUNDLE" group, the

   The BUNDLE mechanism allows an SDP Offerer and SDP Answerer use an to assign
   identical port number value in each addresses to multiple "m=" line lines, if those "m=" lines are
   associated with the
   "BUNDLE" a BUNDLE group.  However, until it is known that whether
   both the SDP Offerer and Answerer
   supports the "BUNDLE" grouping extension, when support the SDP Offerer
   generates an SDP Offer, a different port number value is inserted for BUNDLE mechanism, unique
   addresses are assigned to each "m=" line line, including those associated
   with the "BUNDLE" a 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" BUNDLE groups.  For
   each "BUNDLE" BUNDLE group, a different port number value MUST be used.

   When media BUNDLE address is transported using the Real-Time Protocol (RTP)
   [RFC3550], negotiated.  Multiple BUNDLE
   groups cannot share the same bundle address.

   The default assumption of the mechanism is that all Real-Time Protocol (RTP) [RFC3550]
   based media
   associated with flows within a "BUNDLE" BUNDLE group will form a single belongs to the same RTP
   Session [RFC3550].  However, future specifications  Future extensions 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. change that assumption.

   The BUNDLE mechanism is backward compatible.  Endpoints that do not
   support the "BUNDLE" grouping extension BUNDLE mechanism are expected to generate SDP Offers and
   SDP Answers without inserting a "BUNDLE" group, an SDP group:BUNDLE attribute, and are expected
   to assign unique addresses to insert
   different port number values in each "m=" line, in according to the SDP Offers and
   SDP Answers, as defined
   procedures in RFC 4566 [RFC4566] and RFC 3264. [RFC3264]

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

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

   BUNDLE address: This refers to an IP address and IP port combination,
   that is associated with each "m=" line within a BUNDLE group, within
   an SDP Session.  The zero IP port value BUNDLE address MUST NOT be
   used in a BUNDLE address.

   NOTE: "m=" lines that share a BUNDLE address MUST also share other
   parameters related to the media transport plane, e.g. ICE candidate
   information.

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". BUNDLE.

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

6.  SDP Offer/Answer Procedures

6.1.  General

   This section describes the usage of the SDP Offer/Answer mechanism
   [RFC3264] to negotiate the usage of the BUNDLE mechanism, to
   negotiate the BUNDLE address, and to add, remove and reject SDP Media
   Descriptions ("m=" lines) [RFC4566] associated with a BUNDLE group.

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

   When an endpoint endpoint, acting as an Offerer or Answerer [RFC3264],
   generates an SDP Offer Offer, or an SDP Answer, which contains
   a "BUNDLE" group, it the endpoint MUST insert an SDP session-level 'group'
   attribute, with a "BUNDLE" value, and assign an
   SDP media-level 'mid'
   attribute values mid value for each "m=" line associated the "BUNDLE" in a BUNDLE group.

   Until it is known whether the SDP Answerer supports the "BUNDLE"
   grouping extension,  In
   addition, the endpoint MUST assign an SDP Offerer MUST, session-level group:BUNDLE
   attribute for each "m=" line BUNDLE group, and place each mid associated with a "BUNDLE" group:

   o  1.  Insert different port number values.
   o  2.  Insert identical connection data ("c=" line) value.
   o  3.  Insert different
   the SDP 'rtcp' group:BUNDLE attribute value, when used.
   o  4.  Insert different ICE candidate values, when used.
   o  5.  Insert an mid list.

6.2.  Bundled SDP 'rtpc-mux' attribute.
   o  6.  Insert identical DTLS-SRTP fingerprint attribute, when used
   o  7.  Insert different SDES crypto attribute, Information

6.2.1.  General

   This section describes restrictions associated with the usage of SDP
   parameters and extensions within a BUNDLE group.  It also describes,
   when used

   Once it parameter and attribute values have been assigned to each "m="
   line in the BUNDLE group, how to calculate a value for the whole
   BUNDLE group.

6.2.2.  Bandwidth (b=)

   The total proposed bandwidth is known that both endpoints support the "BUNDLE" grouping
   extension, sum of the SDP proposed bandwidth for
   each "m=" line associated with a negotiated BUNDLE group.

6.2.3.  rtcp-mux Attribute

   For each "m=" line in a BUNDLE group, an Offerer and SDP Answerer MUST, MUST
   assign an SDP rtcp-mux attribute [RFC5761].

6.2.4.  rtcp Attribute

   When used, for each RTP media "m=" line
   associated with in a "BUNDLE" group:

   o  1.  Insert identical port number values.
   o  2.  Insert identical connection data ("c=" line) value.
   o  3.  Insert identical BUNDLE group, an Offerer
   and Answerer MUST assign an SDP 'rtcp' rtcp attribute value, when used.
   o  4.  Insert [RFC3605] with an
   identical ICE candidate values, when used.
   o  5.  Insert attribute value.

6.2.5.  DTLS-SRTP fingerprint Attribute

   When DTLS-SRTP is used, for each RTP media "m=" line in a BUNDLE
   group, an Offerer and Answerer MUST assign an SDP 'rtpc-mux' attribute.
   o  6.  Insert identical DTLS-SRTP
   fingerprint attribute, when used
   o  7.  Insert different attribute with identical attribute values.

6.2.6.  SDES crypto attribute, when used

   Once both endpoints have indicated support of the "BUNDLE" grouping
   extension, they can start using the single port Attribute

   When SDES is used, for the each RTP media "m=" line in a BUNDLE group, an
   Offerer and Answerer MUST assign an SDP crypto attribute, with 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-attributes].  It might not
   possible to use bundle with some attributes.

6.3.  RFC 5888 restrictions

   Based on the rules and procedures in [RFC5888], the following
   restrictions also apply to BUNDLE groups in SDP Answers:

   o  1) A BUNDLE group must not be added to an SDP Answer, unless the
      same BUNDLE group was included in the associated SDP Offer; and

   o  2) An SDP "m=" line must not be added to a BUNDLE group in the SDP
      Answer, unless it was in the same BUNDLE group in the associated
      SDP Offer.

6.4.  SDP Offerer Procedures
6.4.1.  SDP Offerer Bundle Address Request and Usage

   An Offerer can assign a BUNDLE address to multiple "m=" lines in a
   BUNDLE group, once the Answerer has selected the BUNDLE address for
   the Offerer.  An Offerer MUST NOT assign a BUNDLE address to multiple
   "m=" lines until the Answerer has selected the BUNDLE address.

   OPEN ISSUE: Should it be allowed to assign a new BUNDLE address to
   multiple "m=" lines in a BUNDLE group, before the Answerer has
   selected the BUNDLE address?

   In order to negotiate (or, to re-negotiate) the BUNDLE address
   associated with a BUNDLE group, the Offerer, in the SDP Offer,
   assigns a unique address to each "m=" line in the BUNDLE group.  In
   addition, the Offerer indicates which unique address it wishes the
   Answerer to select as the Offerer's BUNDLE address.  The Offerer
   places the mid, associated with the unique address requested to be
   selected as the BUNDLE address, first in the SDP group:BUNDLE
   attribute mid list.  The Answerer will then select the BUNDLE address
   for the Offerer ([ref-to-be-added]).

   If the Offerer, in a subsequent SDP Offer, wants to re-negotiate the
   BUNDLE address associated with a BUNDLE group, it MAY assign the
   previously negotiated BUNDLE address as a unique address to one of
   the "m=" lines in the BUNDLE group.

   If the Offerer assigns the previously selected BUNDLE address to more
   than one "m=" line in a BUNDLE group, the first mid in the SDP
   group:BUNDLE attribute mid list MUST represent an "m=" line to which
   the BUNDLE address is assigned.  Hence, in order to re-negotiate the
   BUNDLE address, the Offerer needs to assign a unique address to each
   "m=" line in the BUNDLE group, as described above.

   An Offerer MUST NOT assign a BUNDLE address to an "m=" line that is
   not associated with each a BUNDLE group.  An Offerer MUST NOT assign a
   BUNDLE address, that has been negotiated for a BUNDLE group, to an
   "m=" line in the "BUNDLE group".

   OPEN ISSUE #1: If the SDP Answerer supports "BUNDLE", do we mandate that "m=" lines must be grouped in is associated with another BUNDLE group.

   Section 10.1 shows an example of a Bundle Address Request.

6.4.2.  Bundle Address Synchronization (BAS)

   When an Offerer has requested the same way in Answerer to select the SDP Answer as
   they are grouped in Offerer's
   BUNDLE address, and the SDP Offer?

6.2.  SDP Offerer Procedures

   When did not assign the SDP Offerer generates an SDP Offer that contains a "BUNDLE"
   group, requested BUNDLE
   address to each "m=" line in the BUNDLE group of the SDP Offer MUST be generated according used
   to request the procedures in
   Section 6.1.

   If BUNDLE address, when the associated SDP Answer contains is
   received the Offerer MUST send a "BUNDLE" group, and subsequent SDP Offer.  In the
   subsequent SDP Offer contained different port number values in each "m=" line
   associated with the "BUNDLE" group, the SDP Offerer MUST generate a
   new SDP Offer, and insert an identical port number value for assign the selected BUNDLE
   address to each "m=" line associated with in the "BUNDLE" BUNDLE group.  Unless ICE  This procedure is used,
   referred to as Bundle Address Synchronization (BAS).

   When the SDP Offerer MUST generate performs a BAS, the new Offerer MAY modify SDP Offer immediately when it
   has received
   parameters in the same SDP Answer indicating Offer.

   NOTE: It is important that the SDP Answerer supports Offer used for the "BUNDLE" grouping extension.  If ICE is used, BAS gets
   accepted by the SDP Offer can
   wait until Answerer, so the Offerer needs to consider the
   necessity to modify SDP Offer indicating parameters that ICE is finished is sent, as
   defined in RFC 5245.

   NOTE: The reason for sending could get the Answerer to
   reject the new SDP Offer, which includes an
   identical port Offer.  Removing "m=" lines, or reducing the number value of
   codecs, in each "m=" line associated with the
   "BUNDLE" group, SDP Offer used for the BAS is considered to have a low
   risk of being rejected.

   NOTE: The main purpose of the BAS is to ensure make sure that intermediary entities
   intermediaries, that look at
   SDP information e.g. for different type of policing functions, have might not support the BUNDLE mechanism, have
   correct information regarding which ports will IP address and port is going to
   be used for media.

   If the bundled media.

   Section 10.1 shows an example of an SDP Offer contains different port number values for each used to perform a BAS.

6.4.3.  Adding a media description to a BUNDLE group

   When an Offerer adds an "m="
   lines line to a BUNDLE group, the Offerer MUST
   assign either a unique address, or the BUNDLE address associated with
   the "BUNDLE" BUNDLE group, and if to the associated SDP
   Answer does not contain a "BUNDLE" group, added "m=" line.  In addition, the SDP Offerer
   MUST use assign a mid value to the different port number values that were included "m=" line, and place the mid in the
   SDP Offer.

   Once it is known that both group:BUNDLE attribute mid list associated with the BUNDLE group,
   in order to group the "m=" line to the BUNDLE group.

   NOTE: If the SDP Offerer and SDP assigns a unique address to the added "m=" line,
   it allows the Answerer support to move the "BUNDLE" grouping extension, "m=" line out of the BUNDLE group
   without having to reject the "m=" line ([ref-to-be-added]).

   To the previously added "m=" lines in each subsequent SDP Offer towards the SDP Answerer, BUNDLE group, the Offerer
   assigns either unique addresses or the BUNDLE address associated with
   the BUNDLE group, according to the procedures in Section 6.4.1.

   Section 10.3 shows an example of an SDP Offer MUST insert used to add an identical port number "m="
   line to a BUNDLE group.

6.4.4.  Moving A Media Description Out Of A BUNDLE Group

   When an Offerer moves an "m=" line out of a BUNDLE group, the Offerer
   MUST assign a unique address to the moved "m=" line.  In addition,
   the Offerer MUST NOT anymore use a mid value in each to group the "m=" line associated
   with the "BUNDLE" group.

   NOTE: If needed, BUNDLE group.

   To the remaining "m=" lines in the BUNDLE group, the SDP Offerer is allowed assigns
   either unique addresses or the BUNDLE address associated with the
   BUNDLE group, according to change the port number
   value procedures in Section 6.4.1.

   Section 10.4 shows an example of an subsequent SDP Offer, but it still inserts the same
   identical port number value in each Offer used to move an "m="
   line associated with the
   "BUNDLE" out of a BUNDLE group.

6.4.5.  Disabling A Media Description In A BUNDLE Group

   When generating an SDP Offer, if the SDP Offerer wants to disable
   media associated with disables an "m=" line in a "BUNDLE" BUNDLE group, it will
   insert the Offerer
   MUST assign a zero port number value in [RFC3264] to the disabled "m=" line, as defined
   in RFC 3264.  However, if line.
   In addition, the Offerer MUST NOT anymore use a mid value to group
   the "m=" lines associated line with the "BUNDLE"
   group contain different port number values (i.e. the SDP Offer is
   generated until it is known whether BUNDLE group.

   To the SDP Answerer supports remaining "m=" lines in the
   "BUNDLE" grouping extension) BUNDLE group, the SDP Offerer MUST NOT set the port
   number value of assigns
   either unique addresses or the first "m=" line BUNDLE address associated with the "BUNDLE"
   group
   BUNDLE group, according to zero.

   The the procedures in Section 6.4.1.

   Section 10.5 shows an example of an SDP Offerer MUST NOT insert Offer used to move an identical port number value in
   multiple "m=" lines, unless the "m=" lines are associated with
   line out of a
   "BUNDLE" BUNDLE group.

   OPEN ISSUE #2:

6.5.  SDP Answerer Procedures

6.5.1.  Answerer Bundle Address Selection and Usage

6.5.1.1.  Offerer Bundle Address Selection

   If the session has been established without BUNDLE, do
   we allow Offerer, in an SDP Offer, assigned a unique address to each
   "m=" line in a BUNDLE group, it means that the Offerer has requested
   the Answerer to be enabled later during select a BUNDLE address for the session?

   OPEN ISSUE #3: If Offerer.  The first
   mid in the SDP group:BUNDLE attribute mid list of the SDP Offer
   represents the unique address which the Offerer requests the Answer
   to select as the session has been established with BUNDLE, do we
   allow Offerer's BUNDLE to be disabled later during address.

   The Answerer SHOULD select the session, meaning that
   different port number values will be used for media unique address associated with
   each "m=" line?

6.3.  SDP Answerer Procedures

   When an SDP the
   first mid to become the Offerer's BUNDLE address, unless the Answerer receives an
   in the SDP Offer which contains a "BUNDLE" Answer will move the "m=" line represented by the mid out
   of the BUNDLE group, and or if there is some other reason why the SDP
   Answerer accepts can not select the offered "BUNDLE" group, unique address associated with the mid.
   In that case, the
   SDP Answerer MUST generate an SDP Answer according to try the procedures next mid in Section 6.1.

   When generating the list.

   In the SDP Answer, if the SDP Answerer wants to reject
   media MUST place the mid associated with an "m=" line
   the selected BUNDLE address first in the "BUNDLE" group, it will
   insert SDP group:BUNDLE attribute
   mid list associated with the BUNDLE group.

   Section 10.1 shows an example of an Offerer's BUNDLE address
   selection.

6.5.1.2.  Anwerer Bundle Address Selection

   The Answerer MUST select a zero port number value local BUNDLE address, and in the disabled SDP
   Answer assign it to each "m=" line, as defined
   in RFC 3264. line associated with the BUNDLE group.

   The Answerer is allowed to change its BUNDLE address in any SDP
   Answer.

   The Answerer MUST NOT insert assign a "BUNDLE" group in BUNDLE address to an SDP Answer,
   unless the "m=" line that is
   not associated SDP Offer contains with a "BUNDLE" BUNDLE group.  The SDP Answerer MUST NOT insert assign a
   BUNDLE address, associated with a BUNDLE group, to an identical port number value in
   multiple "m=" lines, unless the "m=" lines are line
   associated with another BUNDLE group.

   Section 10.1 shows an example of an Answerer's local BUNDLE address
   selection.

6.5.2.  Moving A Media Description Out Of A BUNDLE Group

   When an Answerer moves an "m=" line out of a
   "BUNDLE" BUNDLE group, the
   Answerer MUST assign a unique address to the moved "m=" line.  In
   addition, the Answerer MUST NOT anymore use a mid value to group the
   "m=" line with the BUNDLE group.

   Until

   To the remaining "m=" lines in the BUNDLE group, the SDP Answerer receives assigns
   the new SDP Offer, which contains Answerer's BUNDLE address.

   An Answerer MUST NOT move an
   identical port number value for each "m=" line associated with out of a
   "BUNDLE" BUNDLE group, it MUST use unless:

   o  1) The Offerer assigned a unique address to the "m=" line in the port, and related information (ICE
   candidates, SDES keys etc)
      associated with SDP Offer; or

   o  2) The Answerer also rejects the first "m=" line Section 6.5.3.

6.5.3.  Rejecting A Media Description In A BUNDLE Group

   When an Answerer rejects an "m=" line in a BUNDLE group, 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 Answerer
   MUST assign a single zero port value for a "BUNDLE" group.

6.4.2.  Bandwidth (b=)

   The total proposed bandwidth is to the sum of rejected "m=" line.  In
   addition, the Answerer MUST NOT anymore use a mid value to group the proposed bandwidth for
   each
   "m=" line associated with a negotiated the BUNDLE group.

6.4.3.  Attributes (a=)

   There are also special rules for handling many different attributes
   as defined

   To the remaining "m=" lines in [I-D.nandakumar-mmusic-sdp-attributes].  It might not
   possible to use bundle with some attributes. the BUNDLE group, the Answerer assigns
   the Answerer's BUNDLE address.

7.  Single vs Multiple RTP Sessions

7.1.  General

   When entities negotiate the usage of bundled media, the default
   assumption is that

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

   The usage of multiple RTP Sessions within a "BUNDLE" group given 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 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. 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, 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). 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" BUNDLE grouping extension
   together with the Interactive Connectivity Establishment (ICE)
   mechanism [RFC5245].

8.2.  Candidates
   When an ICE-enabled endpoint generates an SDP Offer, which contains a
   "BUNDLE"
   BUNDLE group, the SDP Offerer MUST include ICE candidates for each
   "m=" line associated with a "BUNDLE" group, except for any "m=" line
   with a zero port number value.  If the "m=" lines associated with the
   "BUNDLE"
   BUNDLE group contain different port number values, the SDP Offerer
   MUST also insert different candidate values in each "m=" line
   associated with the "BUNDLE" BUNDLE group.  If the "m=" lines associated with
   the "BUNDLE" BUNDLE group contain an identical port number value, the
   candidate values MUST also be identical.

   When an ICE-enabled endpoint generates and SDP Answer, which contains
   a "BUNDLE" BUNDLE group, the SDP Answerer MUST include ICE candidates for each
   "m=" line associated with the "BUNDLE" group, except for any "m="
   line where the port number value is set to zero.  The SDP Answerer MUST
   insert identical candidate values in each "m=" line associated with
   the "BUNDLE" BUNDLE group.

8.3.  Candidates

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

9.  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.  Examples

10.1.  Example: SDP Offer with different port number values Bundle Address Selection

   The example below shows an shows:

   o  1.  An SDP Offer, where bundled media is offered
   using different port number values in which the Offerer assigns unique addresses to
      each "m=" lines associated with line in the "BUNDLE" BUNDLE group, and requests the Answerer to
      select the Offerer's BUNDLE address.

   o  2.  An SDP Answer, in which the Answerer selects the BUNDLE
      address for the Offerer, and assigns its own local BUNDLE address
      to each "m=" line in the BUNDLE group.

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

   SDP Offer (1)

       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 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 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 Offer (3)

       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

10.2.  Example: Bundle Mechanism Rejected

   The example also shows two below shows:

   o  1.  An SDP Answer
   alternatives: one where bundled media is accepted, Offer, in which the Offerer assigns unique addresses to
      each "m=" line in the BUNDLE group, and one where
   bundled media is rejected (or, not even supported) by requests the Answerer to
      select the Offerer's BUNDLE address.

   o  2.  An SDP Answer, in which the SDP
   Answerer. Answerer rejects the BUNDLE group,
      and assigns unique addresses to each "m=" line.

   SDP Offer (Bundled media offered) (1)

       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 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) (2)

       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

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

   The example below shows:

   o  1.  An SDP Offer, in which the Offerer adds an "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 BUNDLE address to the previously
      added "m=" lines in the BUNDLE group.

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

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

   SDP Offer (1)

       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 zen
       m=audio 20000 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 20000 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 (Bundled media not accepted) (2)

       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 zen
       m=audio 20000 RTP/AVP 0
       a=mid:foo
       b=AS:200
       a=rtpmap:0 PCMU/8000
       m=video 30000 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 with ICE (Bundled media offered) (3)

       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 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
       a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host
       m=video 10002 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 10002 typ host

11.
       m=video 10000 RTP/AVP 66
       a=mid:zen
       b=AS:1000
       a=rtpmap:66 H261/90000

10.4.  Example: SDP Offer with identical port number values Offerer Moves A Media Description Out Of A BUNDLE Group

   The example below shows an shows:

   o  1.  An SDP Offer, where bundled media is offered
   an identical port number value in which the Offerer moves an "m=" line out of a
      previously negotiated BUNDLE group, assigns a unique address to
      the moved "m=" line, and assigns the previously negotiated BUNDLE
      address to the remaining "m=" lines associated with in the
   "BUNDLE" BUNDLE group.  The example also shows two

   o  2.  An SDP Answer alternatives:
   one where bundled media is accepted, Answer, in which the Answerer moves the corresponding
      "m=" line out of the BUNDLE group, and one where bundled media is
   rejected (or, not even supported) by assigns unique address to
      the moved "m=" line, and assigns the SDP Answerer. previously negotiated BUNDLE
      address to the remaining "m=" lines in the BUNDLE group.

   SDP Offer (Bundled media offered) (1)

       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
       m=video 50000 RTP/AVP 66
       b=AS:1000
       a=rtpmap:66 H261/90000

   SDP Answer (Bundled media accepted) (2)

       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
       m=video 60000 RTP/AVP 66
       b=AS:1000
       a=rtpmap:66 H261/90000

10.5.  Example: Offerer Disables A Media Description In A BUNDLE Group

   The example below shows:

   o  1.  An SDP Answer (Bundled media not accepted) Offer, in which the Offerer moves an "m=" line out of a
      previously negotiated BUNDLE group, assigns a zero port number the
      moved "m=" line in order to disable it, and assigns the previously
      negotiated BUNDLE address to the remaining "m=" lines in the
      BUNDLE group.

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

   SDP Offer (1)

       v=0
       o=bob 2808844564 2808844564
       o=alice 2890844526 2890844526 IN IP4 host.biloxi.com host.atlanta.com
       s=
       c=IN IP4 host.biloxi.com host.atlanta.com
       t=0 0
       a=group:BUNDLE foo bar
       m=audio 20000 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 30000 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 Offer with ICE (Bundled media offered) Answer (2)

       v=0
       o=alice 2890844526 2890844526
       o=bob 2808844564 2808844564 IN IP4 host.atlanta.com host.biloxi.com
       s=
       c=IN IP4 host.atlanta.com host.biloxi.com
       t=0 0
       a=group:BUNDLE foo bar
       m=audio 10000 20000 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 20000 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.
       m=video 0 RTP/AVP 66
       a=rtpmap:66 H261/90000

11.  IANA Considerations

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

13.

12.  Acknowledgements
   The usage of the SDP grouping extension for negotiating bundled media
   is based on a similar alternative alternatives proposed by Harald Alvestrand. 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.

14.

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

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

14.  References

15.1.
14.1.  Normative References

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

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

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

   [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-attributes]
              Nandakumar, S. and C. Jennings, "A Framework for SDP
              Attributes when Multiplexing",
              draft-nandakumar-mmusic-sdp-attributes-00 draft-nandakumar-mmusic-
              sdp-attributes-00 (work in progress), February 2013.

15.2.

14.2.  Informative References

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

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

Appendix A.  Design Considerations

A.1.  General

   One of the main issues regarding the "BUNDLE" 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" 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 a "BUNDLE" 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 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 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 [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