[MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th)
Christer Holmberg <christer.holmberg@ericsson.com> Wed, 12 June 2013 14:12 UTC
Return-Path: <prvs=68754efaf8=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 800AD21F9BEB for <mmusic@ietfa.amsl.com>; Wed, 12 Jun 2013 07:12:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.403
X-Spam-Level:
X-Spam-Status: No, score=-3.403 tagged_above=-999 required=5 tests=[AWL=-2.605, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_56=0.6]
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 LJp4iN-BaHKH for <mmusic@ietfa.amsl.com>; Wed, 12 Jun 2013 07:12:29 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2521021F9BFE for <mmusic@ietf.org>; Wed, 12 Jun 2013 07:12:27 -0700 (PDT)
X-AuditID: c1b4fb38-b7fa16d0000027dd-60-51b881cad5f6
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 43.CE.10205.AC188B15; Wed, 12 Jun 2013 16:12:26 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0328.009; Wed, 12 Jun 2013 16:12:26 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: BUNDLE TEXT: Offerer procedures (June 12th)
Thread-Index: Ac5nc6hv2h/XxszpTAuUKcpTd0hH9A==
Date: Wed, 12 Jun 2013 14:12:25 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C388BD8@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_7594FB04B1934943A5C02806D1A2204B1C388BD8ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+Jvre6pxh2BBv2fdSymLn/M4sDosWTJ T6YAxihum6TEkrLgzPQ8fbsE7owP5/cyFXx+y1LRteUpcwPjiqUsXYycHBICJhKHJm1jg7DF JC7cWw9kc3EICRxllHi8fS6Us4RR4tHsz8xdjBwcbAIWEt3/tEEaRATUJb7u7WEGsYWBBv2d 8Y8dIm4pMefiTShbT2Lvk/dgy1gEVCU+NC5gBLF5BXwlHs+czwRiMwIt/n5qDZjNLCAucesJ RFxCQEBiyZ7zzBC2qMTLx/9YQU6QEFCUWN4vB1GeLzHtbzcbxEhBiZMzn7BMYBSahWTSLCRl s5CUQcR1JBbs/sQGYWtLLFv4mhnGPnPgMROy+AJG9lWMHMWpxUm56UYGmxiBwX9wy2+LHYyX /9ocYpTmYFES501U3REoJJCeWJKanZpakFoUX1Sak1p8iJGJgxNEcEk1MMrvPmcx/ciqrbFF 5WLLbivMO9V+Xlp14+W7ggfXCczJFzYNZNOS27lQ8y/zopq9pSuXnvptzGHS2GPnIblxd0Rh /KkrPr0vuDP85m7Y5xizee0XJS6/hoN1ISf35BZPOnNt50QFnqjj8VpTX7jbSXLMfbppY0M2 +3KGawJH/z44tN2No9zIa7cSS3FGoqEWc1FxIgDCyRtdUQIAAA==
X-Mailman-Approved-At: Wed, 12 Jun 2013 07:13:30 -0700
Subject: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12th)
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: Wed, 12 Jun 2013 14:12:36 -0000
Hi, I've gone through the comments received, and made some conclusions. First, defining Offer "types" was probably not a good idea. It caused confusion, and it was unclear whether it refers to the whole SDP body, or only individual BUNDLE groups within it. So, I've removed the BSO and BRO. I HAVE defined a procedure called 'Bundle Address Synchronization (BAS)', which is basically what the BSO was previously used for. But, it is not a new Offer type, it is simply a procedure that an Offerer does (using an SDP Offer, though). Also, we probably DO need more text on when a BAS is needed, but I hope you understand what the intention of it is :) Second, there were different opinions on how flexible the mechanism should be when it comes to re-negotiating the bundle address, and whether it should be allowed to do it in the same Offer used to e.g. adding an m= line. I tried to come up with a compromise: What Paul wanted, but didn't get: - Paul wanted to be able to assign a new bundle address to multiple m- line, even if the bundle address hasn't been negotiated yet. What Paul got: - In order to negotiate/re-negotiate a bundle address, the Offerer MUST assign unique addresses to each m- line. There Offerer CANNOT simply add a new bundle address to multiple m- lines, until it has been negotiated. What Martin wanted, but didn't get: - Martin wanted to use separate O/A transactions for negotiating the bundle address, and for adding m- lines to a BUNDLE group. What Martin got: - It IS allowed to add an m- line, and re-negotiate the bundle address, in the same SDP Offer. However, as described above, in that case the Offerer needs to assign unique addresses to each m- line. I am not saying we can't change what you got, and didn't get, but just keep the assumptions above in mind when you read the text :) Third, I removed "Use Cases" section naming. The procedures contains lots of normative text, while Use Cases are normally informative, and used to provide background information. Fourth, I know the especially Martin suggested some terminology changes. I didn't forget those, but as many of those are no more valid, I thought it's better to work based on the new text. Fifth, in section 6.1, please do not spend too much time on the numbered list at this point. It is still something we need to discuss, but I believe we need to make some progress on the Plan A vs B stuff first. At least I personally think the text is more clear, and easier to understand, now :) Regards, Christer ----------------------------------------------- 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) associated with a BUNDLE group. The generic rules and procedures defined in [RFC3264] and [RFC5888] apply when the SDP Offer/Answer mechanism is used for BUNDLE. 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 generates an SDP Offer, or an SDP Answer, which contains a BUNDLE group, the endpoint MUST assign SDP media-level mid value for each "m=" line in the BUNDLE group. In addition, the endpoint MUST insert an SDP session-level group:BUNDLE attribute, and place each mid value associated with the BUNDLE group in the attribute mid value list. Until the Offerer knows whether the Answerer supports the BUNDLE mechanism, the Offerer MUST, for each "m=" line in a BUNDLE group: o 1. Insert a unique address. o 2. Insert different SDP 'rtcp' attribute value, when used. o 3. Insert an SDP 'rtpc-mux' attribute. o 4. Insert identical DTLS-SRTP fingerprint attribute, when used o 5. Insert different SDES crypto attribute, when used Once it is known that both endpoints support the BUNDLE grouping extension, the SDP Offerer and Answerer MUST, for each "m=" line associated with a BUNDLE group: o 1. Insert either a unique address, or the bundle address associated with the BUNDLE group (see sections below for details). o 2. Insert identical SDP 'rtcp' attribute value, when used. o 3. Insert an SDP 'rtpc-mux' attribute. o 4. Insert identical DTLS-SRTP fingerprint attribute, when used o 5. Insert different SDES crypto attribute, when used READER'S HELP: The detailed definition of the 'Unique Address' and 'Bundle Address' terminology will be elsewhere in the document, but is basically contains the IP address, IP port and ICE candidates. Perhaps also media security parameters? 6.2. SDP Offerer Procedures 6.2.1. SDP Offerer Bundle Address Request and Usage An Offerer can assign an address to multiple "m=" lines in a BUNDLE group, once the address has been selected as the Offerer's local bundle address. An Offerer MUST NOT assign an address to multiple "m=" lines until the address has been selected as a bundle address for that BUNDLE group. 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 to use as its local bundle address. There Offerer places the mid value, associated with the "m=" line that contains the preferred address first in the SDP group:BUNDLE attribute mid list. The Answerer then selects the local 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 bundle address to more than one "m=" line in a BUNDLE group, the first mid value in the SDP group:BUNDLE attribute mid value 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 a BUNDLE group. An Offerer MUST NOT assign a bundle address, that has been negotiated for a BUNDLE group, to an "m=" line that is associated with another BUNDLE group. Example: The example shows an SDP Offer, 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 local bundle address, by placing the mid value associated with the "m=" line first in the SDP group:BUNDLE attribute mid value list. SDP 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. Bundle Address Synchronization (BAS) When an Offerer has sent an SDP Offer, a bundle address has been selected by the Answerer, and the bundle address was in the SDP Offer not assigned to each "m=" line in the BUNDLE group, the Offerer MUST send a new SDP Offer, in which it assigns the negotiated bundle address to each "m=" line in the BUNDLE group. This procedure is referred to as Bundle Address Synchronization (BAS). The Offerer MUST NOT modify any parameters associated with the BUNDLE group when it performs a BAS. NOTE: Eventhough the Offerer is not allowed to modify parameters associated with a BUNDLE group when it performs a BAS, the Answerer might modify parameters in the associated SDP Answer. For example, the Answerer can in the SDP Answer reject an "m=" line, by removing the rejected "m=" line from the BUNDLE group and assigning a zero port value to the rejected "m=" line ([ref-to-be-added]). Example: The example shows an SDP Offer, where the Offerer assigns the bundle address to each "m=" line in the BUNDLE group, in order to perform a Bundle Address Synchronization. SDP Offer (BAS) 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. Adding a media description to a BUNDLE group When an Offerer adds an "m=" line to a BUNDLE group, the Offerer MUST assign either a unique address, or the bundle address associated with the BUNDLE group, to the "m=" line that is added. In addition, the Offerer MUST assign a mid value for the "m=" line, and place it in the SDP group:BUNDLE attribute mid value list associated with the BUNDLE group. NOTE: If the Offerer assigns a unique address to the "m=" line that is added to the BUNDLE group, it allows the Answerer to remove the "m=" line from the BUNDLE group without having to reject the "m=" line ([ref-to-be-added]). To the other "m=" lines (that previously have been added to the BUNDLE group), the Offerer assigns addresses according to the procedures in Section 6.2.1. Example: The example shows an SDP Offer, where a new "m=" line, identified by the "zen" mid value, is added to a BUNDLE group. The Offerer assigns a unique address to the "m=" line, and the bundle address to each of the other "m=" lines in the BUNDLE group. SDP 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 6.2.4. Removing A Media Description From A BUNDLE Group When an Offerer removes an "m=" line from a BUNDLE group, the Offerer MUST assign a unique address to the "m=" line that is removed. In addition, the Offerer MUST NOT place the mid value that was previously defined for the "m=" line in the SDP group:BUNDLE attribute mid value list associated with the BUNDLE group. To the other "m=" lines (that previously have been added to the BUNDLE group), the Offerer assigns addresses according to the procedures in Section 6.2.1. Example: The example shows a BRO, 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. Example: The example shows an SDP Offer, where an "video" "m=" line (previously identified by the "zen" mid value), is removed from a BUNDLE group. The Offerer assigns a unique address to the "m=" line, and the bundle address to each of the remaining "m=" lines in the BUNDLE group. SDP 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.5. Rejecting A Media Description In A BUNDLE Group When an Offerer rejects an "m=" line in a BUNDLE group, the Offerer MUST assign a unique address, with a zero port value [RFC3264], to the "m=" line that is rejected. In addition, the Offerer MUST NOT place the mid value that was previously defined for the "m=" line in the SDP group:BUNDLE attribute mid value list associated with the BUNDLE group. To the other "m=" lines (that previously have been added to the BUNDLE group), the Offerer assigns addresses according to the procedures in Section 6.2.1. Example: The example shows an SDP Offer, where an "video" "m=" line (previously identified by the "zen" mid value), is rejected, and removed from a BUNDLE group. The Offerer assigns a unique address, with a zero port value, to the "m=" line, and the bundle address to each of the remaining "m=" lines in the BUNDLE group. SDP 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
- [MMUSIC] BUNDLE TEXT: Offerer procedures (June 12… Christer Holmberg
- Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (Jun… Belling, Thomas (NSN - DE/Munich)
- Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (Jun… Christer Holmberg
- Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (Jun… Belling, Thomas (NSN - DE/Munich)
- 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… Paul Kyzivat
- 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