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

Christer Holmberg <> Sun, 09 June 2013 18:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E373821F8A0B for <>; Sun, 9 Jun 2013 11:13:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.009
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M4eXiyYodSDt for <>; Sun, 9 Jun 2013 11:13:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D921921F89FF for <>; Sun, 9 Jun 2013 11:13:39 -0700 (PDT)
X-AuditID: c1b4fb30-b7f9e6d000002643-ef-51b4c5d2c184
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 37.BF.09795.2D5C4B15; Sun, 9 Jun 2013 20:13:38 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Sun, 9 Jun 2013 20:13:38 +0200
From: Christer Holmberg <>
To: Paul Kyzivat <>
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: <>
References: <> <> <>, <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
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: "" <>
Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 09 Jun 2013 18:13:47 -0000


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


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


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