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

[Christer Holmberg <[e-mail]>]

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