Re: [MMUSIC] BUNDLE: SDP Offer Types

Christer Holmberg <christer.holmberg@ericsson.com> Sun, 02 June 2013 18:42 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 122EB21F90F4 for <mmusic@ietfa.amsl.com>; Sun, 2 Jun 2013 11:42:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.801
X-Spam-Level:
X-Spam-Status: No, score=-5.801 tagged_above=-999 required=5 tests=[AWL=0.448, 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 wopOfYegdfqI for <mmusic@ietfa.amsl.com>; Sun, 2 Jun 2013 11:42:04 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 57D8921F911B for <mmusic@ietf.org>; Sun, 2 Jun 2013 11:42:04 -0700 (PDT)
X-AuditID: c1b4fb25-b7f4c6d000004656-8e-51ab91f996a0
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 41.87.18006.9F19BA15; Sun, 2 Jun 2013 20:42:02 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Sun, 2 Jun 2013 20:42:01 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] BUNDLE: SDP Offer Types
Thread-Index: Ac5d6erED7N11c9tSI+QddHtfsU6PgADod2AAAywgio=
Date: Sun, 02 Jun 2013 18:42:00 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C38134B@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C37F87C@ESESSMB209.ericsson.se>, <51A8B059.7070705@alum.mit.edu>
In-Reply-To: <51A8B059.7070705@alum.mit.edu>
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvre6viasDDc795rCYuvwxi8WKDQdY HZg8/r7/wOSxZMlPpgCmKC6blNSczLLUIn27BK6MjTe/MBXsFqr4dOk/YwPjbr4uRk4OCQET iVl39jFC2GISF+6tZ+ti5OIQEjjMKHH7601GCGcxo8TCbXuZuxg5ONgELCS6/2mDNIgI+Eo8 e3ybDcQWFtCVOLn7ERNEXE/i8637zBC2lUTb0YusIDaLgIrEyltX2UFsXqDe/4vvgdlCArkS d+40soGM5xTQkZizUgwkzAh0z/dTa8BGMguIS3w4eJ0Z4k4BiSV7zkPZohIvH/9jhbCVJBqX PGGFqNeRWLD7ExuErS2xbOFrZoi1ghInZz5hmcAoOgvJ2FlIWmYhaZmFpGUBI8sqRvbcxMyc 9HKjTYzASDi45bfqDsY750QOMUpzsCiJ8+rxLg4UEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnV wLjw3eKTnksC0+d/Flzd3vrwrUECxzoxV8+ZEobhCxsaE93ebBJ7U+c+T8CveYa7zbNMk4sr j95b32e5MfT+YzfXZbdWT1nxU2XPyjM5Z5QuhnSYO02+m5mr5/RWNdfrzrr/q/v2bGdovXso 1tK3L7BHtaaQc1bXrtZ77ysPrPwmKqB2u/LEui1KLMUZiYZazEXFiQBwf0K8UgIAAA==
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: Sun, 02 Jun 2013 18:42:11 -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. 

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

Regards,

Christer