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