Re: [MMUSIC] BUNDLE: SDP Offer Types

Christer Holmberg <christer.holmberg@ericsson.com> Tue, 04 June 2013 08:31 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 1C0A821F9B5B for <mmusic@ietfa.amsl.com>; Tue, 4 Jun 2013 01:31:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.913
X-Spam-Level:
X-Spam-Status: No, score=-5.913 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 cTrItVwo+OPo for <mmusic@ietfa.amsl.com>; Tue, 4 Jun 2013 01:31:19 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 08C0421E810B for <mmusic@ietf.org>; Tue, 4 Jun 2013 00:28:07 -0700 (PDT)
X-AuditID: c1b4fb30-b7f9e6d000002643-2a-51ad9707c265
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id CE.36.09795.7079DA15; Tue, 4 Jun 2013 09:28:07 +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; Tue, 4 Jun 2013 09:28:06 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Thread-Topic: [MMUSIC] BUNDLE: SDP Offer Types
Thread-Index: Ac5d6erED7N11c9tSI+QddHtfsU6PgADod2AAAywgioAlxfJgAAbOWHA
Date: Tue, 4 Jun 2013 07:28:06 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C38248B@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C37F87C@ESESSMB209.ericsson.se>, <51A8B059.7070705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C38134B@ESESSMB209.ericsson.se> <51ACFB79.1080207@alum.mit.edu>
In-Reply-To: <51ACFB79.1080207@alum.mit.edu>
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+JvrS779LWBBrPP8VpMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGqo2rmQvOSFRMv9LJ0sC4W7iLkZNDQsBE YuLmG8wQtpjEhXvr2boYuTiEBA4zSmzasoIdwlnMKHH96magKg4ONgELie5/2iCmiICGxKSt aiAms4C6xNXFQSBjhAV0JU7ufsQEYosI6El8vnWfGcJ2k5jcOYERxGYRUJFYN7cTrIZXwFfi 8YFNUGsvM0rMmveOFSTBKaAjcbTtFBuIzQh02/dTa8AamAXEJW49mc8EcbOAxJI956HuF5V4 +fgfK8g9EgKKEsv75SDKdSQW7P7EBmFrSyxb+JoZYq+gxMmZT1gmMIrNQjJ1FpKWWUhaZiFp WcDIsoqRPTcxMye93HwTIzA+Dm75bbCDcdN9sUOM0hwsSuK8+ryLA4UE0hNLUrNTUwtSi+KL SnNSiw8xMnFwSjUwll7t2qeh9leYszIg+sFktTW7o99N6/3MvcJpU1DzoqMC1qYJ1+eXtVW2 L2LKvPidY6Ff7F1PCU6951k/y7ut+CQZxRpsThsp6y8p6ZkhemSZsKHFoSXb35zRkyllsFkl 5xTy302lWyP1YWSwY77Nu0nmxhzTOZ/UmwSeuhl4ZkegJAPzhXtKLMUZiYZazEXFiQCyl+Kc XQIAAA==
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] BUNDLE: SDP Offer Types
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: Tue, 04 Jun 2013 08:31:35 -0000

Hi,

>>>> I'll throw the ball out with suggesting the following ones:
>>>>
>>>> -*Bundle restart offer* (different port value, currently referred to 
>>>> as "first offer")
>>>>
>>>> The reason I use "restart" wording is because this is used, no 
>>>> matter whether in the beginning of the session or mid-session, to 
>>>> (re-)negotiate the usage of BUNDLE, and the bundle address 
>>>> information selection.
>>>>
>>>> -*Bundle sync offer* (identical port value, currently referred to as 
>>>> "second offer")
>>>>
>>>> The reason I used "sync" wording is because this is used to ensure 
>>>> that intermediaries have correct address information for each m- line.
>>>>
>>>> Keep in mind that we may even need to split the sync offer into more 
>>>> sub types, when we get into the details of adding new m- lines etc, 
>>>> but I'd like to agree a base to start from :)
>>>
>>> Above seems like a good start, but I'm still grappling with some 
>>> things and don't know how to talk about concisely:
>>>
>>> I understand that the next offer after a Bundle Restart Offer will 
>>> typically be a Bundle Sync Offer. But if there is another offer after 
>>> a Bundle Sync Offer, and it doesn't change anything about the bundle, 
>>> then is it still a Bundle Sync Offer?
>>
>> Currently, yes.
>
> I agree that without adjusting the terminology this is the only right choice to make. But it is a little obscure. I'm not certain this needs to be improved, but I thought I would suggest that it might.
>>
>>> Also, I don't believe the above are mutually exclusive. If I send an 
>>> offer to add a new m-line to a bundle, and I give it distinct address 
>>> info so that the answerer may take it out of the bundle if needed, 
>>> then is that a Bundle Restart Offer or a Bundle Sync Offer? It seems 
>>> to be a bit of each. And of course there may be multiple bundles 
>>> described by the SDP, and these terms apply independently to each.
>>>
>>> Maybe we need a couple more terms for:
>>>
>>> - offer that adds a new m-line to bundle using the existing bundle
>>>    address info.
>>
>> Technically that is a Bundle Sync Offer, but I DO agree that the wording is not good in this case - as it's not only about synchronization.
>>
>>> - offer that adds a new m-line to an existing bundle using unique
>>>    address info.
>>
>> I agree that doesn't fit the current definitions.
>>
>> However, we will have to agree on whether we allow that in the first place, or whether the offerer will have to use 1) same address information or 2) different address information for ALL m- lines (Bundle Restart Offer).
>
> Yes, we need to settle on whether either or both of these are permitted.
>
> But I can think of reasons why I might wish to use either one, and no good reason not to allow both. So allowing both is my preference.

I personally think we should allow BOTH 1) and 2).

The question is whether we should allow 3), which is new m- line with unique address, while the other m- lines use the bundle address.

Regards,

Christer