[MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th)

Christer Holmberg <christer.holmberg@ericsson.com> Thu, 06 June 2013 11:18 UTC

Return-Path: <prvs=586938eb54=christer.holmberg@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF03E21F994F for <mmusic@ietfa.amsl.com>; Thu, 6 Jun 2013 04:18:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.448
X-Spam-Level:
X-Spam-Status: No, score=-4.448 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqVzAC2NV7zo for <mmusic@ietfa.amsl.com>; Thu, 6 Jun 2013 04:18:00 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7B92C21F995A for <mmusic@ietf.org>; Thu, 6 Jun 2013 04:17:59 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f5d6d000003d54-a3-51b06fe5a038
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 62.9B.15700.5EF60B15; Thu, 6 Jun 2013 13:17:57 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0328.009; Thu, 6 Jun 2013 13:17:57 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: BUNDLE TEXT: Offerer procedures (June 6th)
Thread-Index: Ac5iprZaCgBOn7ljRxaMYhEaRiO+Kg==
Date: Thu, 6 Jun 2013 11:17:56 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C383F1E@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.17]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C383F1EESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyM+Jvre7T/A2BBqf+2Vh0TGazONbXxWYx dfljFgdmjysTrrB6TPm9kdVjyZKfTAHMUdw2SYklZcGZ6Xn6dgncGW3HH7IWHNjBUtG78Rxr A+PRH8xdjJwcEgImEl3H5rFC2GISF+6tZwOxhQQOM0r8WqXdxcgFZC9mlLhwfBpQgoODTcBC ovufNkiNiIC6xNe9PcwgNcwCDYwSf261s4MkhAWMJWYvfcMIUWQhsenLEhYIW0/izv+JYMtY BFQkns3cBRbnFfCVWPfnJ1icEeiI76fWMIHYzALiEreezGeCOE5AYsme81BHi0q8fPyPFeQe CQFFieX9ciAms0C+RP+KYoiJghInZz5hmcAoPAvJoFkIVbOQVEGU6Egs2P2JDcLWlli28DUz jH3mwGMmZPEFjOyrGNlzEzNz0ssNNzECo+bglt+6OxhPnRM5xCjNwaIkzqvHuzhQSCA9sSQ1 OzW1ILUovqg0J7X4ECMTByeI4JJqYCxK0ik2z55j8+eX5W7XLvfHH/Ni11+weKC3OUjlk43U Ja3kCK/dHkfeZ266sUhmb+nns9OOvdjfYWIxcffRD1f9t5nNFy/mrljgduzVb73QLaGFUin/ v+Ydf61Ydrk4U9A1LiwudyEj44SbnpGq766db3v4eu0fSa2Vn+4mfjj2/vxy0/X13Q1KLMUZ iYZazEXFiQD+UT7VbQIAAA==
X-Mailman-Approved-At: Thu, 06 Jun 2013 04:19:04 -0700
Cc: "Cullen Jennings \(fluffy@cisco.com\)" <fluffy@cisco.com>
Subject: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jun 2013 11:18:08 -0000

Ok folks,

Below is some Offerer text for BUNDLE. I've also included some examples.

As we have discussed, Bundle Sync Offer may not be good terminology, but again I'd like to focus more on the technical content, and the "understandability" of the text, for now :)

Also note that the text currently assumes that a port zero m= line CANNOT be inside a BUNDLE group. That may change (depending on how we move forward with the plans etc), but
should not have a huge impact on the text, apart from the section talking about disabling an "m=" line in a BUNDLE group.

Also, the definition of "bundle address" WILL be defined, but it's more or less the IP port, address and ICE information associated with the transport plane.

Happy reading!

Regards,

Christer

----------------------------------


6.2.  SDP Offerer Procedures

6.2.1.  General

   This section describes how an Offerer creates an SDP Offer which
   includes a BUNDLE group.

   An SDP Offer that includes a BUNDLE group can be categorized either
   as a Bundle Restart Offer (BRO) Section 6.2.2.1 or as a Bundle Sync
   Offer (BSO) Section 6.2.2.2.

6.2.2.  SDP Offer Types

6.2.2.1.  Bundle Restart Offer (BRO)

   A Bundle Restart Offer (BRO) is used to negotiate (or re-negotiate)
   the usage of the BUNDLE mechanism, and/or the bundle address used by
   the "m=" lines in a BUNDLE group.

   In a BRO, the Offerer assigns a unique address to at least one "m="
   line in a BUNDLE group.  Such "m=" lines can be removed from the
   BUNDLE group by the Answerer (see [xxx]), as the unique address can
   be used outside the BUNDLE group.

   In a BRO, the Offerer assigns, for each "m=" line in the BUNDLE
   group, either a unique address, or a previously negotiated bundle
   address, as long as a unique address is assigned to at least one "m="
   line in the BUNDLE group (if the bundle address is assigned to each
   "m=" line in the BUNDLE group, the SDP Offer is by definition a
   Bundle Sync Offer (BSO) Section 6.2.2.2.

   When a session is initiated, if the Offerer does not know whether the
   Answerer supports the BUNDLE mechanism, the Offerer MUST initiate a
   BRO, and the Offerer MUST assign a unique address to each "m=" line
   in the BUNDLE group.

   If, in the SDP Answer associated with the BRO, the offered BUNDLE
   group is accepted [ref-to-be-added], the Offerer MUST, for each "m="
   line in the BUNDLE group, start to use its local bundle address, and
   the remote bundle address, both selected by the Answerer [ref-to-be-
   added].  In addition, the Offerer MUST send a Bundle Sync Offer (BSO)
   Section 6.2.2.2, in which the bundle address is assigned to each "m="
   line in the BUNDLE group.

   NOTE: The Offerer needs to send the BSO as soon as possible, in order
   to make sure intermediaries are aware that the bundle address will be
   used for each "m=" line in the BUNDLE group.  However, the exact
   moment for sending the BSO might depend on other features and
   extensions (e.g. ICE) also used by the Offerer, that also require the
   sending of subsequent SDP Offers.

   Example: The example shows a BRO, where a unique address is assigned
   to each "m=" line in the BUNDLE group.  The Offerer requests the
   address associated with the audio "m=" line to be selected as its
   bundle address, by placing the mid value associated with the "m="
   line first in the SDP group:BUNDLE attribute mid list.


   SDP Offer (Bundle Restart Offer)

       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 20000 RTP/AVP 31 32
       a=mid:bar
       b=AS:1000
       a=rtpmap:31 H261/90000
       a=rtpmap:32 MPV/90000



6.2.2.2.  Bundle Sync Offer (BSO)

   A Bundle Sync Offer (BSO) is used when the Offerer does not want to
   re-negotiate the usage of the BUNDLE mechanism, and/or the bundle
   address.  The Offerer can, using a BSO, re-negotiate other parameters
   associated with the BUNDLE group, however.

   In a BSO, the Offerer MUST assign the bundle address to each "m="
   line in a BUNDLE group.  Such "m=" lines can not be removed from the
   BUNDLE group by the Answerer [ref-to-be-added], as the bundle address
   can not be used outside the BUNDLE group.

   Example: The example shows a BSO, where the bundle address is
   assigned to each "m=" line in the BUNDLE group.


   SDP Offer (Bundle Sync Offer)

       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



6.2.3.  Use Cases

6.2.3.1.  Offerer Bundle Address Request

   In order to negotiate (or re-negotiate) the bundle address, the
   Offerer MUST send a BRO.  In the BRO, as the Offerer assigns a unique
   address to some (or all) "m=" lines in the BUNDLE group, the Offerer
   needs to indicate to the Answerer which address, associated with one
   of the "m=" lines in the BUNDLE group, it wishes to use as its local
   bundle address.  The first mid value in the SDP group:BUNDLE
   attribute mid value list represents the "m=" line address with the
   highest preference.

   The Answerer will select the local bundle address for the Offerer, as
   described in Section 6.3.3.  The Offerer MUST use the bundle address
   selected by the Answerer.  If the Offerer is not able to use that
   bundle address, it MUST either terminate the session, or send a new
   BRO.

   Example: The example shows a BRO, where a unique address is assigned
   to each "m=" line in the BUNDLE group.  The Offerer requests the
   address associated with the audio "m=" line to be selected as its
   bundle address, by placing the mid value associated with the "m="
   line first in the SDP group:BUNDLE attribute mid list.


   SDP Offer (Bundle Restart Offer)

       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 20000 RTP/AVP 31 32
       a=mid:bar
       b=AS:1000
       a=rtpmap:31 H261/90000
       a=rtpmap:32 MPV/90000



6.2.3.2.  Adding a media description to a BUNDLE group

   When adding an "m=" line to a BUNDLE group, the Offerer generates
   either a BRO or BSO.  In case of a BSO, the Offerer assigns the
   bundle address to each "m=" line (including the new one) in the
   BUNDLE group.  In case of a BRO, the Offerer assigns, for each "m="
   line (including the new one), either a unique address, or the bundle
   address (only the bundle address can be assigned to more than one
   "m=" line in the BUNDLE group).

   Example: The example shows a BRO, where a new "m=" line, identified
   by the "zen" mid value, is added to a BUNDLE group.  The bundle
   address is assigned to each of the current "m=" lines in the BUNDLE
   group, while a unique address is assigned to the new "m=" line.  The
   Offerer requests that the bundle address is not changed, by placing
   the mid value associated with the audio "m=" line, for which the
   previously negotiated bundle address is assigned, first in the SDP
   group:BUNDLE attribute mid list.


   SDP Offer (Bundle Restart Offer)

       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
       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 30000 RTP/AVP 60
       a=mid:zen
       b=AS:1000
       a=rtpmap:60 H261/90000



   Example: The example shows a BSO, where a new "m=" line, identified
   by the "zen" mid value, is added to a BUNDLE group.  The previously
   negotiated bundle address assigned to each "m=" line (the current
   ones and the new one) in the BUNDLE group.


   SDP Offer (Bundle Sync Offer)

       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
       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 60
       a=mid:zen
       b=AS:1000
       a=rtpmap:60 H261/90000



6.2.3.3.  Removing A Media Description From A BUNDLE Group

   In order to remove an "m=" line from a BUNDLE group, the Offerer
   generates either a BRO or BSO.  The Offerer MUST remove the "m="
   line, and its associated mid value, from the BUNDLE group, and the
   Offerer MUST assign a unique address to the removed "m=" line.

   Example: The example shows a BSO, where an "m=" line is removed from
   a BUNDLE group.  The Offerer removes the mid ("zen") associated with
   the "m=" line from the SDP group:BUNDLE attribute mid value list, and
   assigns a unique address to the removed "m=" line.


   SDP Offer (Bundle Sync Offer)

       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 40000 RTP/AVP 60
       b=AS:1000
       a=rtpmap:60 H261/90000



6.2.3.4.  Disabling A Media Description In A BUNDLE Group

   In order to disable an "m=" line in a BUNDLE group, the Offerer
   generates either a BRO or BSO.  The Offerer MUST remove the disabled
   "m=" line, and its associated mid value, from the BUNDLE group.  In
   addition, the Offerer assigns a zero port value to the "m=" line,
   according to the procedures in RFC 3264.

   Example: The example shows a BSO, where an "m=" line is disabled in
   (and removed from) a BUNDLE group.  The Offerer removes the mid
   ("zen") associated with the disabled "m=" line from the SDP
   group:BUNDLE attribute mid value list, and assigns a port zero value
   to the "m=" line.


   SDP Offer (Bundle Sync Offer)

       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 0 RTP/AVP 60
       a=rtpmap:60 H261/90000



   OPEN ISSUE: It is FFS whether it is allowed to include a port zero
   media descriptions in a BUNDLE group.