Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th)

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 07 June 2013 19:23 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 4056721F964C for <mmusic@ietfa.amsl.com>; Fri, 7 Jun 2013 12:23:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.362
X-Spam-Level:
X-Spam-Status: No, score=-0.362 tagged_above=-999 required=5 tests=[AWL=0.075, 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 fnNdshFy3SrH for <mmusic@ietfa.amsl.com>; Fri, 7 Jun 2013 12:23:01 -0700 (PDT)
Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 1944A21F9412 for <mmusic@ietf.org>; Fri, 7 Jun 2013 12:22:59 -0700 (PDT)
Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta08.westchester.pa.mail.comcast.net with comcast id lP7J1l0021ZXKqc58XNzWM; Fri, 07 Jun 2013 19:22:59 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id lXNz1l0053ZTu2S3hXNzZL; Fri, 07 Jun 2013 19:22:59 +0000
Message-ID: <51B23312.4040902@alum.mit.edu>
Date: Fri, 07 Jun 2013 15:22:58 -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: Christer Holmberg <christer.holmberg@ericsson.com>
References: <7594FB04B1934943A5C02806D1A2204B1C383F1E@ESESSMB209.ericsson.se> <51B0BCA8.6050304@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C384E6D@ESESSMB209.ericsson.se>, <51B21700.1020709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C384FDC@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C384FDC@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370632979; bh=PDQjkiODW1+BZ5ASsZrXRashwGSd8WVWuphTJNLi0LU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qgdWEc0LtqbBvPWsfPQTnd+5+dNEm/4TdXcacZ0/WpNaU+H3Ptlx5b+RdEMBx43T+ YeUqQQTdNa39C4zRFHC5Sckag178be/41UAyQc+n4Ym31PFmy5+JmBfOcv4CugtwS6 8t4eDC2156VIc84gImciVyCaXDzgRee7YdEaKbN6kiA3Luejo0bykJTAE84hEgcep2 j/OvpgqFvvNBc84BN4OPvcdlTKWK7U81CM/t9nIGxpwVtWK9Bq9tymeV5sS0AoJ0sN v1/9nrDpM2kC25vZJVpS7TEMeU85DSNK5Q2P4ZJ8Y5KZK+IBzpD+sLyIG2WjEjAvO8 MZ/grwYoBd8YQ==
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th)
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, 07 Jun 2013 19:23:07 -0000

On 6/7/13 2:55 PM, Christer Holmberg wrote:
>
> Hi,
>
>>> After reading Paul's and Martin's comments, I am suggesting a change to the separation between BSO and BRO.
>>>
>>> Again, the names will be changed, but I'll leave that for now - but I DO like the Bundle Negotiation Offer (BNO) suggestion made by Martin :)
>>>
>>> In the current text, I separate between BSO and BRO pretty much based on the type address information in the "m=" lines of the SDP Offer. I have realized that it doesn't work very well.
>>>
>>> So, a new suggestion is that the separation is done based on the PURPOSE of the SDP Offer, NOT the type of address information in the "m=" lines (of course, in many cases they go hand-in-hand).
>>
>> Note that offers and answers may contain more than just one set of
>> bundled m-lines. They may contain unbundled m-lines, and multiple
>> bundles. So the purpose of a particular offer may be complex, trying to
>> satisfy different needs for various parts of the SDP. That complicates
>> making such a distinction.
>
> I guess it should be more clear that the definition is per bundle group within an SDP Offer, not necessairly the whole SDP body.

I think the BSO must be determined over the entire O/A, not on a 
per-bundle basis. Otherwise the new offer is being sent with the intent 
to change *something* in it.

>>> A BSO would be used ONLY for synchronization purpose, or making the SDP "stable".
>>
>> So this is just intended to describe the case where both ends have
>> reached agreement on what they want to do, and don't want to change
>> that, but the agreed pair of SDPs doesn't describe that agreement in the
>> standard way? This additional O/A is used *solely* to put things into
>> the standardized representation?
>
> Correct.
>
>> And if things end up in the standardized form without a BSO then one is
>> not sent?
>
> Correct.
>
>> If so, then the receiver of the offer can tell that it is a BSO by
>> analyzing it in the context of what the prior O/A had been. But there is
>> no particular reason to do so, because it doesn't affect the behavior of
>> the answerer.
>>
>> The value of the term must be simply to facilitate the description of
>> offerer behavior. Following an O/A exchange that has left things in a
>> non-canonical form, the offerer in that exchange is required to send a BSO.
>>
>> And I think the need for a BSO can indeed only be determined after
>> receiving the answer. It is largly driven by the structure of the offer,
>> but even so, certain answers may eliminate the need for the BSO.
>
> The reason for sending the BSO is not the Answerer - it is because of intermediaries that don't understand BUNDLE.

I realize that the BSO is not being sent for the benefit of the 
answerer. My point was that the need to send the BSO is determined by 
the offerer, but cannot be determined until the answer has been received.

>>> A BRO would be used to negotiate the usage of BUNDLE, to add/remove/modify "m=" lines and/or the bundle address. So, even an with
>>> the same address information in each "m=" line could be an BRO, if the purpose is to modify the SDP in one way or another.
>>
>> So an offer that *changes* *anything* is a BRO, while one that changes
>> nothing but puts things in the correct form is called a BSO.
>
> Correct.
>
>> That definition might work from the point of view of the offer.
>> But note that even with a BSO the answer might change something.
>>
>> E.g. the answerer could change its bundle address, or it could reject
>> some m-lines. (But I don't think it is possible for the answer to do
>> anything valid that will prevent the intent of the BSO from being achieved.)
>
> I think that's ok.
>
> Because, even without BUNDLE, if an Offerer sends a SIP re-INVITE/UPDATE with an unmodified SDP Offer (e.g. because of session-timer usage), the SDP Answer may still change.
>
> One question, though, is whether the SDP o= line version number should be incremented when sending a BSO (assuming everything, including the non-BUNDLE stuff, in the SDP body is unmodified). From a pure SDP perspective, the address information for certain "m=" lines may have changed, eventhough from a BUNDLE perspective it is just about synchronization.

I've always had a problem with o-lines.
AFAICT the only value they bring (at least in the context of O/A) is as 
an optimization: if the new one says via the o-line that it is identical 
to the prior one then perhaps you can simply not process it.

But I think an implementation would be insane to trust this. There is 
too much of a chance that there will be a changed SDP with an unchanged 
o-line. So I think a reasonable implementation will at least do a 
comparison of the whole body before optimizing for an unchanged one. (Or 
else it will do any optimization on an element by element basis.)

BUT, on the off chance that anybody does use the o-line that way, then I 
think it must be marked as changed. It isn't identical, and the reason 
its not, and is being sent, is because of the changes it contains. Those 
changes may have different significance to intermediaries than to the 
UAS, but its important that the difference be recognized.

If *nothing* is changed, then there is no reason to send the BSO.

Of course the *answer* to the BSO most likely will be unchanged from the 
prior answer, so the o-line for that ought to reflect that.

	Thanks,
	Paul