Re: [MMUSIC] BUNDLE DISCUSION Q6: Do we always mandate 2 Offer/Answers during session establishment?

[Harald Alvestrand <[e-mail]>]

On 09/09/2013 08:28 PM, Christer Holmberg wrote:
> Hi,
>
>>> Sure. If the Offerer assigns a previously negotiated BUNDLE address (or, an address that will become the new BUNDLE address) to those m- lines, there is no need for a second o/a exchange.
>> Perhaps the single m-line offer/answer performed to establish the data
>> channel will include BUNDLE, but it would be a little redundant.
> Correct.
>
> The only advantage of putting a single m- line into a BUNDLE group is that you will, in the Answer, find out whether the Answerer supports BUNDLE.
>
> But, for that we could also define e.g. a feature/option-tag, so that one doesn't have to use BUNDLE just to figure out whether the other end supports it or not...

I don't like feature tags when I can get away without them.

When I have a feature tag and a feature, I have four possibilities:

- Feature tag and feature: OK.
- Feature tag and no feature: Have to remember the feature tag, 
otherwise OK.
- No feature tag and no feature: OK.
- No feature tag and feature: Bug on the other end, but I am the one who 
have to write code to detect it and do something appropriate.

Just saying "the other guy supports the feature if he uses it, otherwise 
I know nothing" is a state machine with just two states, unlike the four 
states above.
>
>> When you talk about initial offer, you should really be talking about the first offer that contains BUNDLE.
> Or, the offer when the offerer still doesn't know whether the answerer supports BUNDLE - IF there is a way for endpoints to exchange that data without actually using BUNDLE.
>
An one-element BUNDLE will solve that easily - and offers a hint on 
which transport it makes sense to extend to multiple m-lines.