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

A BSO would be used ONLY for synchronization purpose, or making the SDP "stable".

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, please keep the assumptions above in mind when reading my reply to the individual comments below :)


----------------------------------


>> 6.2.2.1.  Bundle Restart Offer (BRO)
>>
>>    A Bundle Restart Offer (BRO) is used to negotiate (or 
>>    re-negotiate)  the usage of the BUNDLE mechanism, and/or the bundle address used 
>>    by  the "m=" lines in a BUNDLE group.
>>
>>    In a BRO, the Offerer assigns a unique address to at least one "m="
>>    line in a BUNDLE group.  Such "m=" lines can be removed from the
>>
>>    BUNDLE group by the Answerer (see [xxx]), as the unique address  can
>>    be used outside the BUNDLE group.
>>
>>     In a BRO, the Offerer assigns, for each "m=" line in the BUNDLE
>>     group, either a unique address, or a previously negotiated bundle
>>     address, as long as a unique address is assigned to at least one "m="
>>     line in the BUNDLE group (if the bundle address is assigned to each
>>     "m=" line in the BUNDLE group, the SDP Offer is by definition a
>>     Bundle Sync Offer (BSO) Section 6.2.2.2.

> The above excludes the possibility of both proposing to change the previously negotiated bundle address and add a new m-line with a unique address.

Correct. But, with the suggested change in the beginning of the mail it should now be possible.


>>     When a session is initiated, if the Offerer does not know whether the
>>     Answerer supports the BUNDLE mechanism, the Offerer MUST initiate a
>>     BRO, and the Offerer MUST assign a unique address to each "m=" line
>>     in the BUNDLE group.
>
> The MUST above bothers me. I could go with SHOULD.
> IOW, even if the offerer doesn't know whether the answerer supports 
> bundle, it could take a chance, on the assumption that the odds are good 
> that it will be successful. Then it can deal with the consequences if 
> the answer indicates that bundle wasn't supported.

Ok.


>>     If, in the SDP Answer associated with the BRO, the offered BUNDLE
>>     group is accepted [ref-to-be-added], the Offerer MUST, for each "m="
>>     line in the BUNDLE group, start to use its local bundle address, and
>>     the remote bundle address, both selected by the Answerer [ref-to-be-
>>     added].  In addition, the Offerer MUST send a Bundle Sync Offer (BSO)
>>     Section 6.2.2.2, in which the bundle address is assigned to each "m="
>>     line in the BUNDLE group.
>
> In some cases things could be done with one O/A rather than two, and 
> whether a 2nd one is needed may depend on what was in the answer. What 
> is proposed seems to *require* two O/As when bundling is used.

I will make it more clear that the 2nd O/A (BSO) is required ONLY when a BRO was sent, AND each "m=" line did NOT have the same address information.


--------------------------------


> 6.2.2.2.  Bundle Sync Offer (BSO)
>
>     A Bundle Sync Offer (BSO) is used when the Offerer does not want to
>     re-negotiate the usage of the BUNDLE mechanism, and/or the bundle
>     address.  The Offerer can, using a BSO, re-negotiate other parameters
>     associated with the BUNDLE group, however.

> If all I want to do is change the bundle address, I should be able to 
> send an offer that does that.
> And after the answer all is done. I shouldn't be required to offer unique addresses for each (or any) m-line 
> in the bundle to do this.

The new BRO definition will allow you to do that, as you can now assign the same address (i.e. your suggested new bundle address) to each "m=" line.


>>     In a BSO, the Offerer MUST assign the bundle address to each "m="
>>     line in a BUNDLE group.  Such "m=" lines can not be removed from the
>>     BUNDLE group by the Answerer [ref-to-be-added], as the bundle address
>>     can not be used outside the BUNDLE group.
>
> Some of the m-lines in the bundle can be rejected (port zero), and then 
> be removed from the bundle.

I thought I had some text clarifying that, but if it's not there I will add it.


> And if there is then only one m-line left in the bundle, then I guess it can either 
> be left in the bundle or else the bundle can be removed.

I did have some text about BUNDLE groups with only one "m=" line, but it seems it got lost somewhere.

Personally I don't think we would need to forbid BUNDLE groups with only one "m=" line (unless it goes against RFC 5888), but it doesn't really give you anything.


--------------------------------


>> 6.2.3.1.  Offerer Bundle Address Request
>>
>>     In order to negotiate (or re-negotiate) the bundle address, the
>>     Offerer MUST send a BRO.  In the BRO, as the Offerer assigns a unique
>>     address to some (or all) "m=" lines in the BUNDLE group, the Offerer
>>     needs to indicate to the Answerer which address, associated with one
>>     of the "m=" lines in the BUNDLE group, it wishes to use as its local
>>     bundle address.  The first mid value in the SDP group:BUNDLE
>>     attribute mid value list represents the "m=" line address with the
>>     highest preference.
>
> Again, you say a BRO MUST be used to to change the bundle address.
> But the key defining feature of a BRO over a BSO is that it has at least 
> one m-line with a unique address. This doesn't suit the case well.
> But I can't use a BSO for this, because, by your definition it must have 
> the previously negotiated bundle address.

Correct. My suggestion in the beginning of the reply would change that.

You would still use a BRO for this, but you can assign the same 
address (previously negotiated bundle address OR suggested new bundle address)
to each "m=" line if you want.

--------------------------------

You had some more comments, but I'll leave them for now, because I *THINK* my new suggestion would solve most of them.

But, I'll go through them when I put together a proposal for new text.

Regards,

Christer