Re: [MMUSIC] Bundle offer with different ports - where to expect media?

[Paul Kyzivat <[e-mail]>]

Martin,

On 5/28/13 12:34 PM, Martin Thomson wrote:
> On 28 May 2013 09:16, Martin Thomson <[e-mail]> wrote:
>> On 27 May 2013 08:47, Paul Kyzivat <[e-mail]> wrote:
>>> no
>
> FWIW, I can live with that.  (Sorry about the earlier empty email.)  I
> was simply trying to be aggressively minimalist.
>
> This model requires that each m-line has two independently negotiable
> properties:
>   - accepted/rejected (signaled using zero port)
>   - bundle membership (signaled using a=group)
>
> (and yes, this requires an update to 5888)
>
> Then we need, as you describe, rules for transitioning between states.
>
> Transition between accepted and rejected is always possible in both
> offers and answers.

Agreed.

> It seems like we are saying that bundle membership can transition in
> the following ways:
>
> Any group to no group:
>   - In an offer, under all circumstances.
>   - In an answer, if the m-line is rejected.
>   - In an answer, if unique transport parameters are provided in the offer.

Agreed.

> No group to any group:
>   - In an offer, under all circumstances.
>   - In an answer, never.

Agreed.

> Any group to any other group:
>   - In an offer, if the m-line was previously rejected.

Agreed.

>   - In an answer, if the lines were offered as a bundle and there are
> sufficient transport parameters on offer.

I don't understand what you mean here.
What are "sufficient transport parameters on offer"?
Do you mean when the addr/port in the offered m-line is unique?

I hadn't considered that case. I'm thinking its a bad idea to allow 
this, because it creates a bundling situation that the offerer hasn't 
consented to and has no way of refusing.

> Is that the rules you would like to see?

Yes, aside from my comment about the last one.
You describe it more clearly than I did.

> I think that the last option
> (splitting) is the only one that I haven't seen anyone else slavering
> for.  The model permits it, but I'd rather prohibit features fix it up
> later than start with something that ends up too permissive.

Without the last rule splitting is still possible, but it requires two 
O/A cycles. In the splitting case I have in mind, the initial offer puts 
a bunch of m-lines in one bundle. The answerer is decomposed so that it 
can't handle them all in one bundle. But perhaps it can handle them in 
two bundles. (The 2nd bundle has never been mentioned yet.)

So in its answer it refuses the m-lines that it wants in a separate 
bundle. Then it sends another offer, reviving the previously refused 
m-lines and putting them into a new bundle.

This can be accomplished with the rules you give above, dropping the 
last one. While it would be nice to accomplish this in a single O/A, I 
can see no way to accomplish that while giving both sides an opportunity 
to refuse what it can't do.

	Thanks,
	Paul

> For example, it would be possible to split a bundle that had multiple
> m-lines and only two sets of transport parameters like the following:
>
> offer:
> BUNDLE 1 2 3 4
> mid:1  transport A
> mid:2  transport A
> mid:3  transport A
> mid:4  transport B
>
> answer:
> BUNDLE 1 2
> BUNDLE 4 3
>
> Despite a (possible) preference from the offerer for bundling 1-3
> together, 3 has been split off.
>
> I'm sure that we can get the rules right, but I like avoiding these
> sorts of little complications.
>