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

[Paul Kyzivat <[e-mail]>]

On 9/6/13 2:49 PM, Justin Uberti wrote:
> 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.

But one of the main justifications for the 2nd O/A is the presence of 
intermediaries who depend upon this. Even if you know all about the 
application at the other end, you probably don't know about the presence 
of intermediaries that care any more than you know about intermediaries 
that force the use of ICE.

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

If its just the extra RTT you are concerned with, it shouldn't matter in 
this case, because you have your media flowing and so the extra RTT 
isn't delaying you. Or else the media isn't flowing due to media-gating 
intermediaries, in which case you really must pay that extra RTT to get 
the media going.

Or are you concerned with the other costs (processing, bandwidth) of the 
extra round trip?

	Thanks,
	Paul

> On Mon, Sep 2, 2013 at 1:27 PM, Paul Kyzivat <[e-mail]
> <mailto:[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] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/__listinfo/mmusic
>     <https://www.ietf.org/mailman/listinfo/mmusic>
>
>