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

Thanks for your input, Partha! :)

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: Parthasarathi R [mailto:partha@parthasarathi.co.in] 
Lähetetty: 3. syyskuuta 2013 21:37
Vastaanottaja: Christer Holmberg; 'Paul Kyzivat'; mmusic@ietf.org
Aihe: RE: [MMUSIC] BUNDLE DISCUSION Q6: Do we always mandate 2 Offer/Answers during session establishment?

Hi all,

As Paul mentioned that mandating ICE in RTCWeb as the network is not known in advance and let us continue the same assumption for BUNDLE as well. Just adding to that point, ICE requires two offer/answer (O/A) handling anyway and so, BUNDLE is not the first mechanism in RTCWeb requires two O/A for the session establishment. 

The advance with the current BUNDLE mechanism is that it provides better interop with SIP/legacy devices. I prefer the current mechanism.

Also, I have earlier replied in the another mail thread (http://www.ietf.org/mail-archive/web/mmusic/current/msg12184.html), RFC3264 must not be violated to achieve the single offer/answer for BUNDLE. 

Thanks
Partha

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On 
> Behalf Of Christer Holmberg
> Sent: Tuesday, September 03, 2013 4:48 PM
> To: Paul Kyzivat; mmusic@ietf.org
> Subject: 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
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic