Re: [MMUSIC] BUNDLE: SDP Offer Types

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 31 May 2013 14:14 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 95D8021F89C3 for <mmusic@ietfa.amsl.com>; Fri, 31 May 2013 07:14:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.245
X-Spam-Level:
X-Spam-Status: No, score=-0.245 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
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 cT5xtVDOmrlf for <mmusic@ietfa.amsl.com>; Fri, 31 May 2013 07:14:51 -0700 (PDT)
Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 8024D21F8F7B for <mmusic@ietf.org>; Fri, 31 May 2013 07:14:50 -0700 (PDT)
Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta14.westchester.pa.mail.comcast.net with comcast id icVt1l00116LCl05EeEq3f; Fri, 31 May 2013 14:14:50 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id ieEq1l00C3ZTu2S3SeEqqt; Fri, 31 May 2013 14:14:50 +0000
Message-ID: <51A8B059.7070705@alum.mit.edu>
Date: Fri, 31 May 2013 10:14:49 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: mmusic@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B1C37F87C@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C37F87C@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370009690; bh=4UbE2AxuBQIxG7FtiwtXaBBoYaV0oMjAMRG2fYltm/U=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=KkBqnuiZUS6y17LpMAMND0K/lMHXC7zaVZy4hFSXkbQ0MU73RCcOGJzXRdEhmexFN b6gqT/+3a/XPC3URFzrPyM+puMYrJl1q1PZygmseuVAfHjRSSqm0aobIzes/VRTH4j /YuOky5wbjGzC46k+2K4D1DXoJmB07XJgwfE5TdvCyXxLvUymw1GRVJRxMbFWpF9Uo ENbZNb7ll9bt+TeXwSXEKcJZoeWWzdYeirw6Wq/jf3gytSz3LWGo6C8SA4Dqrh9XX+ U3Jc+1oqy5OtO7po9O4qOK3PHoKZxx0PKT03XdB4cEVZhTjPqVvbASiXCf3jQ/PCXn BTLs9m5tqWtjw==
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: Fri, 31 May 2013 14:14:57 -0000

On 5/31/13 6:30 AM, Christer Holmberg wrote:
> Hi,
>
> As we know, BUNDLE currently uses two main ”types” of SDP Offers: one
> where each m- line in the BUNDLE group has a different port number
> value, and one where each m- line has the same port value.
>
> Often we refer to these as “the first offer” resp. “the second offer”.
>
> Now, this works fine when we talk about the session establishment, but
> as we know a session can contain multiple additional offers, and with
> BUNDLE those can be of either type.
>
> So, my question is whether we should come up with some better wording.

Yes, I agree we need something better.

> 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?

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.

- offer that adds a new m-line to an existing bundle using unique
   address info.

And even if we do that we still need to explain that they only describe 
typical cases, not all cases. Or else we need to find a way to use terms 
that apply more narrowly than to a complete offer or answer.

	Thanks,
	Paul