[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, 06 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.
- Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (Jun… Martin Thomson
- [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6t… Christer Holmberg
- Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (Jun… Martin Thomson
- Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (Jun… Paul Kyzivat
- Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (Jun… Paul Kyzivat
- Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (Jun… Christer Holmberg
- Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (Jun… Christer Holmberg
- Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (Jun… Martin Thomson
- Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (Jun… Paul Kyzivat
- Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (Jun… Christer Holmberg
- Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (Jun… Martin Thomson
- Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (Jun… Christer Holmberg
- Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (Jun… Paul Kyzivat
- Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (Jun… Christer Holmberg
- Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (Jun… Christer Holmberg
- Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (Jun… Paul Kyzivat
- Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (Jun… Martin Thomson
- Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (Jun… Christer Holmberg
- Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (Jun… Martin Thomson