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

Christer Holmberg <christer.holmberg@ericsson.com> Sun, 09 June 2013 18:13 UTC

Return-Path: <prvs=78725593e0=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 E373821F8A0B for <mmusic@ietfa.amsl.com>; Sun, 9 Jun 2013 11:13:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.009
X-Spam-Level:
X-Spam-Status: No, score=-6.009 tagged_above=-999 required=5 tests=[AWL=0.240, 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 M4eXiyYodSDt for <mmusic@ietfa.amsl.com>; Sun, 9 Jun 2013 11:13:40 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D921921F89FF for <mmusic@ietf.org>; Sun, 9 Jun 2013 11:13:39 -0700 (PDT)
X-AuditID: c1b4fb30-b7f9e6d000002643-ef-51b4c5d2c184
Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 37.BF.09795.2D5C4B15; Sun, 9 Jun 2013 20:13:38 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Sun, 9 Jun 2013 20:13:38 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Thread-Topic: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th)
Thread-Index: Ac5iprZaCgBOn7ljRxaMYhEaRiO+KgAHcYEAACvn8mAAB7QFAAAHB7kk///pOACAAzE39w==
Date: Sun, 9 Jun 2013 18:13:37 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C38693D@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C383F1E@ESESSMB209.ericsson.se> <51B0BCA8.6050304@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C384E6D@ESESSMB209.ericsson.se>, <51B21700.1020709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C384FDC@ESESSMB209.ericsson.se>, <51B23312.4040902@alum.mit.edu>
In-Reply-To: <51B23312.4040902@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.19]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyM+Jvre6lo1sCDXYsMLKYuvwxi8WKDQdY HZg8/r7/wOSxZMlPpgCmKG6bpMSSsuDM9Dx9uwTujCmftzAW7NKvuNe7grWBca9qFyMnh4SA icSdlhdMELaYxIV769m6GLk4hAQOM0ocbLvGAuEsZpT49WY2excjBwebgIVE9z9tEFNEQENi 0lY1EJNZQF3i6uIgkDHCAg4SWzZMYgWxRQQcJQ782sIGYYdJnHy6lhnEZhFQkdh8uwkszivg K7H42VWoTduZJI58u84CkuAU0JFYeuUMmM0IdNv3U2vA7mQWEJe49WQ+1M0CEkv2nGeGsEUl Xj7+xwphK0q0P21ghKjXkViw+xMbhK0tsWzha2aIxYISJ2c+YZnAKDYLydhZSFpmIWmZhaRl ASPLKkb23MTMnPRy802MwBg5uOW3wQ7GTffFDjFKc7AoifPq8y4OFBJITyxJzU5NLUgtii8q zUktPsTIxMEJIrikGhgdbe2Xp1gdD7mcGxzp/pL9lN7p0w+q99aFL4rkkvTWjt5n/Y3JLy6h f80eywqO9lkmLcG7m/UzNJj3CqzfpV7zvmBftPUK9aOCX0/5qcmlpZytbWlL/H3svbakxyF1 vaOHXDau+OEffOXN7reuf0rvdh7j23/fySpp7Q2NOW0fv+T8fH40Tl6JpTgj0VCLuag4EQA7 ogEdZAIAAA==
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: Sun, 09 Jun 2013 18:13:47 -0000

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.

Sure, but you could change things which are non-BUNDLE related.

For example, if you use ICE, you could combine the BUNDLE BSO with the ICE Offer which informs the other endpoint of the selected candidates (sorry, I don't remember all ICE terminology at the moment :)


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

Correct.


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

Actually, I have seen entities that do NOT perform any check if the o-line value is unchanged :)

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

I agree.

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

Correct.

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

Correct.

Regards,

Christer