Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)

[Peter Thatcher <[e-mail]>]

On Wed, Jun 19, 2013 at 10:46 AM, Martin Thomson
<[e-mail]>wrote:

> On 19 June 2013 08:15, Peter Thatcher <[e-mail]> wrote:
> > Unfortunately, Microsoft's input seems to be "our way or the highway"
>
> The good thing about this forum is that correcting gross
> misrepresentation is as easy as it is to propagate it.
>

I'll happily be wrong about my representation of Mircosoft's standpoint,
but Matthew just said "My position is that there are no incremental
improvements possible without removing the O/A state machine from the
browser."  That's pretty hardline, with no room for compromise.

But to be fair, I retract my comment of "Microsoft's input seems to be 'our
way or the highway'" and would like to replace it with
 "Microsoft's input seems to be 'no incremental improvements without
removing O/A from the browser'".  How's that?


>
> Microsoft's input is that Offer/Answer is difficult to remove without
> also removing a reliance on SDP at the same time.  CU-RTC-Web is a
> demonstration of one solution to that problem that we believe is
> workable.  That proposal was input, not ultimatum.  We'd be happy to
> consider other alternatives, but we don't believe that any attempt
> that retains both O/A and SDP to be a worthwhile step.
>

I'm fine with the goal of avoiding SDP and O/A.  My proposal that started
this thread does just that for media streams (but not transports).

It's the "no incremental improvements" part that I have issue with.  I
believe we can do this with incremental improvements.



>
> The proposals I've seen for incremental refinement don't successfully
> avoid the SDPNG trap.  Most increase the API surface area, often
> dramatically, which burdens both browser implementations and API
> users.  I personally don't believe it to be possible to avoid this
> problem without tackling the core problem, which unfortunately
> requires a little bit of courage.
>

I disagree.  My proposal eliminates at least half of the pain by only
adding two methods to PeerConnection (and a few dictionaries).  That does
add some burden to the browser, but relieves a lot of burden from the API
users.