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

[Paul Kyzivat <[e-mail]>]

Hi Christer,

I'm still finding problems when I read this, in spite of all the 
discussions. It feels to me like the problem is that the distinction 
between BRO and BSO isn't quite right, and it isn't just the names. 
Clearly there are a couple of different kinds of things. While reading 
and writing this I've been trying to figure out exactly what the problem 
is and how to fix it.

First, I'll comment inline where I see issues.
Then at the end I'll suggest something that might help.

On 6/6/13 7:17 AM, Christer Holmberg wrote:
> Ok folks,
>
> Below is some Offerer text for BUNDLE. I’ve also included some examples.
>
> As we have discussed, Bundle Sync Offer may not be good terminology, but
> again I’d like to focus more on the technical content, and the
> “understandability” of the text, for now :)
>
> Also note that the text currently assumes that a port zero m= line
> CANNOT be inside a BUNDLE group. That may change (depending on how we
> move forward with the plans etc), but
>
> should not have a huge impact on the text, apart from the section
> talking about disabling an “m=” line in a BUNDLE group.
>
> Also, the definition of “bundle address” WILL be defined, but it’s more
> or less the IP port, address and ICE information associated with the
> transport plane.
>
> Happy reading!
>
> Regards,
>
> Christer
>
> ----------------------------------
>
> 6.2.  SDP Offerer Procedures
>
> 6.2.1.  General
>
>     This section describes how an Offerer creates an SDP Offer which
>
>     includes a BUNDLE group.
>
>     An SDP Offer that includes a BUNDLE group can be categorized either
>
>     as a Bundle Restart Offer (BRO) Section 6.2.2.1 or as a Bundle Sync
>
>     Offer (BSO) Section 6.2.2.2.
>
> 6.2.2.  SDP Offer Types
>
> 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.

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

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

[snip]

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

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

[snip]

> 6.2.3.  Use Cases
>
> 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.

[snip]

ISTM that all bundle offers must meet some constraints:
- some of the m-lines may have *unique* addresses
- all the rest, if any, must have a single *common* address.
- if any share a common address, then the first mid in the
   bundle group must identify one of them

All answers to a bundle offer must also meet some constraints:
- all the standard grouping constraints on answers
- all m-lines in the bundle in the answer must have a single
   common address.
- m-lines bundled in the offer but unbundled in the answer
   must have either a zero port or a unique address in the answer.
   (Unique from each other and from the common address of the
   lines bundled in the answer.)
- An m-line that had a common address in the offer may only
   be removed from the bundle in the answer if:
   - it is given a zero port in the answer
   - all the other m-lines that had the same common address
     in the offer have been given a zero port in the answer

Then, a bundle offer where *all* the addresses are common is "stable". 
(It doesn't need to be "fixed up".) Maybe we can call that a BSO. :-)

That distinction is independent of whether it is used to initially 
establish a bundle, to change the address of a bundle, add or remove 
m-lines, etc.

A bundle offer that meets the general constraints but isn't a BSO is an 
"unstable" bundle offer, in that it will (probably) need to be followed 
up with another, stable, bundle offer.

One open issue I have here is that I think some answers might eliminate 
the need for an unstable bundle offer to be followed up by a stable 
offer. (IOW, the answer may stabilize an unstable offer.) Some examples 
where I think this may be so:

- if the bundling is entirely rejected, (no bundle group in answer),
   then no stable bundle offer is required

- if the offer would be stable if it only contained the m-lines in
   the answer bundle group, then a stable bundle offer *may* not be
   required. (IOW the answer removed everything from the bundle that
   made it unstable.) This needs further discussion.

So the bottom line is that you can do whatever you want (add, remove, 
reject m-lines, move them out of bundles, change addresses, etc.) in an 
offer or answer if and only if you meet the stated constraints for an 
offer or answer.

So the focus becomes one of making certain the constraints are specified 
precisely and clearly.

	Thanks,
	Paul