Re: [rtcweb] JSEP and draft-ietf-mmusic-sdp-bundle-negotiation-03

On 02/18/2013 09:01 PM, Bernard Aboba wrote:
> What are implications of this "new" approach on the SDP usage in the 
> JSEP API, if any?
>
> For example: do we expect the SDP output by createOffer() to support 
> this "different port" alternative by default?

If this ends up being the one alternative that people think is best, I 
think createOffer() should (of course) create that format by default.

>
> Also, overall is there a goal of "optimizing for the common case"?

I think the first focus is to have something that works; second focus is 
not failing in "interesting" ways in too many cases.

The browser-to-browser case should be able to send data after the first 
offer/answer, just as we do in the fastest proposals now. The second 
offer/answer to regularize port pairings shouldn't add time to the setup 
phase.

>
> > From: christer.holmberg@ericsson.com
> > To: mmusic@ietf.org
> > Date: Mon, 18 Feb 2013 19:50:21 +0000
> > Subject: [MMUSIC] Draft new version: 
> draft-ietf-mmusic-sdp-bundle-negotiation-03
> >
> >
> > Hi,
> >
> > I've submitted a new version (-03) of BUNDLE.
> >
> > Based on discussions with Cullen, and exchange of the concerns we 
> had with the different port alternatives (different-ports vs 
> identical-port), this version now describes a mechanism where both 
> alternatives more or less are combined. When the first BUNDLE offer is 
> sent, and it is now known whether the answerer supports BUNDLE (or, 
> even identical ports), different ports are used (read: the one-rtp 
> alterntaive). Once BUNDLE answer has been received, a new offer, with 
> identical port numbers, is sent.
> >
> > We think that having to send a second offer is not going to increase 
> complexity and delay, because in many use-cases subsequent offer(s) 
> will be sent anyway. For example, RTCWEB entities will do it because 
> of ICE.
> >
> > Cullen has also been added as co-author.
> >
> > Now, we do realize that there are still issues that have to be 
> described, and hopefully we will be able to focus on those from now 
> on, but our wish is that this proposal will unite the different "port 
> camps" :)
> >
> > Regards,
> >
> > Christer
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb