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

Hi Paul,

Thanks for your input!

I'd really also like to hear from others who have had opinions on this. Ekr, Hadriel, Cullen (perhaps - he still hasn't clarified what he meant by his previous statement regarding this :), to name a few...

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] Puolesta Paul Kyzivat
Lähetetty: 2. syyskuuta 2013 23:28
Vastaanottaja: mmusic@ietf.org
Aihe: Re: [MMUSIC] BUNDLE DISCUSION Q6: Do we always mandate 2 Offer/Answers during session establishment?

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
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic