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. 

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

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

Regards,

Christer