Re: [MMUSIC] 10 BUNDLE questions

[Paul Kyzivat <[e-mail]>]

On 4/22/13 11:25 AM, Cullen Jennings (fluffy) wrote:

[snip]

>>> Also imagine case where
>>>
>>> Alice offers A, B, and C and offers to bundle them all
>>>
>>> Bob wants to accept A and B in a bundle and C separate
>>>
>>> When I talked to Justin this, I was convinced we don't want to bother to support this as it complicated gathering ports for future offers. So what it comes down to the device receive the offer can either accept the bundle or not. (and separate accept or reject each m line in the bundle but can't refactor the bundling).
>>
>> This is actually the same sort of problem as the above.  The question
>> is whether the bundle is negotiated as a whole, or whether answers can
>> differentiate on per-line basis.  I can appreciate the desire to
>> simplify, but you have to examine use cases.
>>
>> Example: Alice offers A and B bundled, Bob accepts the bundling.
>> Later, Alice adds C to the bundle.  How can Bob get that m= line
>> routed over a different path?  Do we require that Bob reject the line
>> and offer the same line, potentially inverted, without bundling in a
>> subsequent offer?
>>
>> I'm thinking here about a case where a session escalates from audio to
>> audio+video and there might be a middlebox involved.  I guess in that
>> case the middlebox needs to drive the addition.
>>
>> I can probably live with the simplification, but this needs to be
>> crystal clear.  A more complete discussion of the implications of this
>> particular choice would be really helpful.
>
> +1 on we need to be crystal clear.
>
> I think I am leaning towards once a bundle is set up, a new update to it can offer things in the bundle or not it the bundle. And if offered in the bundle, the answer can choose to put it in the bundle or not. But I want to avoid all things like the answer can move a m-line from one one bundle to another bundle or something like that. It's too complicated and I don't see the need for it.

This is a subcase of "splitting" a bundle, which I posted on earlier:

http://www.ietf.org/mail-archive/web/mmusic/current/msg10683.html

IMO it *must* be permissible to accomplish this in some way.
For the case of splitting one bundle into two bundles, I concluded that 
it will take another O/A. Just leaving some of the proposed bundle 
candidates out of single bundle seems to be acceptable to 5888. I see no 
reason to circumvent that for bundle groups.

The second o/a I proposed for splitting a bundle would not be allowed by 
what the two of you are proposing. There are real use cases for this, 
where the offerer processes all the streams at a single network access 
point, but the other endpoint processes them at multiple access points.

	Thanks,
	Paul