[MMUSIC] BUNDLE (pre-5): SDP Offerer Procedures
Christer Holmberg <christer.holmberg@ericsson.com> Mon, 09 September 2013 12:36 UTC
Return-Path: <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 A780811E81DC for <mmusic@ietfa.amsl.com>; Mon, 9 Sep 2013 05:36:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.123
X-Spam-Level:
X-Spam-Status: No, score=-4.123 tagged_above=-999 required=5 tests=[AWL=-2.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 oxUzjgZ+Ns7D for <mmusic@ietfa.amsl.com>; Mon, 9 Sep 2013 05:35:58 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 24CB211E81DA for <mmusic@ietf.org>; Mon, 9 Sep 2013 05:33:54 -0700 (PDT)
X-AuditID: c1b4fb38-b7fcf8e0000062b8-df-522dc031d359
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id B9.A4.25272.130CD225; Mon, 9 Sep 2013 14:33:54 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0328.009; Mon, 9 Sep 2013 14:33:53 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: BUNDLE (pre-5): SDP Offerer Procedures
Thread-Index: Ac6tV84ucPIB6qHWTwC2csaUp78d3Q==
Date: Mon, 09 Sep 2013 12:33:53 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C49B5DC@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.19]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C49B5DCESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+Jvja7RAd0gg89HWCymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJdN/AUT/zFWTOnZz9jAuPE+YxcjB4eEgInE+X6DLkZOIFNM 4sK99WxdjFwcQgJHGSXuP97MDOEsZpQ4srGRGaSBTcBCovufNkiDiIC6xNe9PcwgtrCAvsSd l5dZIOImEssnrwcrFxHQk/h/txjEZBFQkdi61B+kglfAV2LO4utMIDYj0Nrvp9aA2cwC4hK3 nsxngjhHQGLJnvPMELaoxMvH/1ghbEWJ9qcNjBD1+RKrt89khJgpKHFy5hOWCYxCs5CMmoWk bBaSMoi4jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KkaM4tTgpN93IYBMjMOgPbvltsYPx 8l+bQ4zSHCxK4rxb9M4ECgmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBkkRBdfCMj9vMa+4Xr xPd9KJlQ7HpGRTy7abqw/XHZzNMzlnKbKQdNk8pUlJtt8KGbWfGXpejs+hOqS5ZLHNjL/Zg3 XjVRa1H9/FUqZdlzH6QIZyc8elubER/XkB3KufuP8ftTrNvyT6qcsYp9uiGAd+ddxm33tDfd LZ2uncXddVdw9wr/c8+UWIozEg21mIuKEwHN5ORWSAIAAA==
Subject: [MMUSIC] BUNDLE (pre-5): SDP Offerer Procedures
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: Mon, 09 Sep 2013 12:36:12 -0000
Hi, Based on recent discussions, and my own text review, I have again produced new text for the BUNDLE Offerer procedures. The new text is shorter, and at least in my opinion more clear, than the previous text. But, comments and suggestions are as always welcome. (Some references still have to be fixed, so no need to focus on that) Note the Open Issue, about whether it's allowed to use a shared address (an address assigned to multiple m- lines within a BUNDLE group) before the Answerer has indicated support of BUNDLE. Note that there is a separate thread about that, and I would really like people who have an opinion to participate in the discussions. Many people ARE participating (and I am very thankful for that), but there are also some key individuals who aren't. I want to try to reach an agreement before Vancouver. Regards, Christer ----------------------- 6.4. SDP Offerer Procedures 6.4.1. General When an Offerer generates an Offer, it assigns an address to each "m=" line, according to the procedures in [RFC3264]. To each "m=" line within a BUNDLE group the Offerer assigns either an address that is unique address to that "m=" line, or a shared address that is also assigned to other "m=" lines within the BUNDLE group. Such shared address can be, but does not have to be, a previously selected BUNDLE address [ref-to-be-added]. OPEN ISSUE: There is a discussion on whether assigning a shared address to multiple "m=" lines shall be allowed until the Answerer has indicated support of BUNDLE. The Offerer MUST NOT assign an address (unique or shared), that it has assigned to an "m=" line within a BUNDLE group, to an "m=" line outside the BUNDLE group. The Offerer MUST, for a BUNDLE group, on the SDP session level [RFC4566], insert an SDP group:BUNDLE attribute associated with the BUNDLE group. The Offerer MUST assign an SDP 'mid' attribute [RFC5888] to each "m=" line within the BUNDLE group, and place the mid value in the group:BUNDLE attribute mid list. The Offerer MAY assign an SDP 'bundle-only' attribute [ref-to-be- added] to one or more "m=" lines within a BUNDLE group. 6.4.2. Request BUNDLE address selection When an Offerer generates an Offer, it MUST indicate which address (unique or shared) within a BUNDLE group it wishes the Answer to select as the Offerer's BUNDLE address for the BUNDLE group. The Offerer MUST do this even if the Answerer has, in a previous Answer within the dialog, already selected the Offerer's BUNDLE address. In order to request an address (unique or shared) to be selected as the Offerer's BUNDLE address for a BUNDLE group, the Offerer places the mid value, associated with the "m=" line representing the requested address, first in the SDP group:BUNDLE attribute mid list associated with the BUNDLE group. Section 10.1 shows an example of a Bundle Address Request. 6.4.3. Bundle Address Synchronization (BAS) When an Offerer receives an Answer, in which an offered BUNDLE group is accepted, if the Offerer in the associated Offer assigned an address (unique or shared), that does not represent the BUNDLE address selected for the Offerer, to an "m=" line within the BUNDLE group, the Offerer MUST send a subsequent Offer, in which it assigns the BUNDLE address selected for the Offerer to each "m=" line within the BUNDLE group. This procedure is referred to as Bundle Address Synchronization (BAS), and the Offer is referred to as a BAS Offer. The Offerer MAY modify any SDP parameter in a BAS Offer. NOTE: It is important that the BAS Offer gets accepted by the Answerer, so the Offerer needs to consider the necessity to modify SDP parameters that could get the Answerer to reject the BAS Offer. Removing "m=" lines, or reducing the number of codecs, in the BAS Offer used for the is considered to have a low risk of being rejected. NOTE: The main purpose of the BAS Offer is to make sure that intermediaries, that might not support the BUNDLE mechanism, have correct information regarding which address is going to be used for the bundled media. Section 11.1 shows an example of an BAS Offer. 6.4.4. Adding A Media Description To A BUNDLE Group When an Offerer generates an Offer, in which it adds an "m=" line to a BUNDLE group, the Offerer assigns an address (unique or shared) to the "m=" line, assigns an SDP 'mid' attribute to the "m=" line, and places the mid value in the group:BUNDLE attribute mid list associated with the BUNDLE group, according to the procedures in Section 6.4.1.1. If the Offerer wishes the Answerer to select the address assigned to the added "m=" as the Offerer's BUNDLE address, the mid value associated with the "m=" line is placed first in the list, according to the procedures in Section 6.4.1.2. Section 11.3 shows an example of an Offer used to add an "m=" line to a BUNDLE group. 6.4.5. Moving A Media Description Out Of A BUNDLE Group When an Offerer generates an Offer, in which an "m=" line is moved out of a BUNDLE group, the Offerer MUST assign a unique address to the moved "m=" line. In addition, the Offerer MUST NOT anymore include a mid value, representing the "m=" line, in the SDP group:BUNDLE attribute mid list associated with the BUNDLE group. Section 11.4 shows an example of an Offer used to move an "m=" line out of a BUNDLE group. 6.4.6. Disabling A Media Description In A BUNDLE Group When an Offerer generates an Offer, in which an "m=" line associated with a BUNDLE group is disabled, the Offerer MUST assign an address with a zero port value [RFC3264] to the disabled "m=" line. In addition, the Offerer MUST NOT anymore include a mid value, representing the "m=" line, in the SDP group:BUNDLE attribute mid list associated with the BUNDLE group. Editor's note: Whether a port zero "m=" line can be associated with a BUNDLE group depends on the outcome of the bundle-only discussions. Section 11.5 shows an example of an Offer used to disable an "m=" line in a BUNDLE group.
- [MMUSIC] BUNDLE (pre-5): SDP Offerer Procedures Christer Holmberg