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

[Justin Uberti <[e-mail]>]

In a closed app environment, you can ensure that the remote side can do
BUNDLE. I expect this sort of deployment to be common for WebRTC.

This is distinct from the ICE case, where it's not the app capabilities
that are in question, but rather the network topology. Even in a closed app
environment, the network will most likely be unknown to the app.

The setup cost of 1 signaling RTT is significant enough that some
applications will want to be able to avoid this.


On Mon, Sep 2, 2013 at 1:27 PM, Paul Kyzivat <[e-mail]> wrote:

> On 9/2/13 10:11 AM, Christer Holmberg wrote:
>
>> Hi,
>>
>> The text below applies to the INITIAL Offer only.
>>
>> Currently, BUNDLE (-04) specifies that:
>>
>> 1)In the initial Offer, the “1^st Offer”, the Offerer assigns a unique
>>
>> address to each m- line in a BUNDLE group.
>>
>> 2)When the Answer is received, if the Answerer accepted BUNDLE, the
>> Offerer MUST send a “2^nd Offer” (called a BAS in the draft), in which
>>
>> the selected BUNDLE address is assigned to each m- line associated with
>> a BUNDLE group.
>>
>> This is based on the “merger” of the earlier BUNDLE version, and
>> Cullen’s CUNDLE suggestion, and currently there are NO exceptions
>> defined to the rule above (we have agreed to relax this in mid-call
>> Offers, but that’s a separate topic).
>>
>> Now, lately people have suggested exceptions to the rule.
>>
>> E.g. the following has been suggested:
>>
>> 1)The Offerer does NOT need to send the 2^nd Offer (BAS), it the Offerer
>>
>> “knows” it is operating in an environment where there are no
>> intermediaries etc that need to get the correct address for each m- line.
>>
>> 2)The Offerer can already in the 1^st Offer assign the same address to
>>
>> each m- line associated with a BUNDLE group, if it “knows” entities will
>> be able to handle it.
>>
>> Then, there are variants of the suggestions, where there are specific
>> rules to bundle-only m- lines, where it depends on whether BUNDLE is
>> used in the API or on the wire, etc etc etc.
>>
>> At the moment it is impossible for me to parse the input, and try to
>> come up with some new suggested text that would make everyone happy.
>>
>> So, those of want to change the current rules, I would be really happy
>> if you could explain exactly how you want to change it :)
>>
>
> I have a feeling we aren't being very consistent.
> We (mostly) embrace ICE, which is based on the assumption that you can't
> know in advance what is going to work, and must test every time.
>
> Then we have proposals like these that assume there may be cases where you
> do know in advance.
>
> I'm as guilty as others. I've been in support of (2), but not necessarily
> because I think people will *know* with certainty. IMO people may know that
> this case is highly probable in the deployments they care about. And that
> they may be willing to take the risk, and attempt to cope with the side
> effects in cases where it turns out to be true. But bundle-only gives most
> of the same advantage.
>
> I don't see a strong justification for (1). While it takes extra
> signaling, it doesn't slow anything down except in those cases when it was
> actually necessary.
>
>         Thanks,
>         Paul
>
> ______________________________**_________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/**listinfo/mmusic<https://www.ietf.org/mailman/listinfo/mmusic>
>