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 8:59 AM, Robin Raymond <[e-mail]> wrote:

>
> Then why not move to a lower level API and do it as a shim (i.e. reverse
> polyfill)?
>


>
> If provided a lower level API that works without SDP where the individual
> network/media component wiring/attributes can be controlled, we could
> create the same WebRTC API that exists today for people who think "SDP out
> to be enough for anybody" layered on top of it; They lose absolutely
> nothing (in fact they gain a lot since now they can tweak the logic to be
> even more compatible with their networks and dynamically update it as
> needed instead of waiting for the next browser "patch" to be deployed
> everywhere on all platforms). The only different is that it's an JavaScript
> implementation rather than written in C++. They get what they want but we
> get what we need.
>

There are two separate things here: 1.  adding to the current API to allow
JS to avoid SDP.  2.  removing what is there that uses SDP.

You're saying you want to add new things and remove olds things.  But I
think really you just want to add what you want, and it would matter if
what you didn't want to use were still there.  So I think it's better to
talk about what we can add to the API to make it easier to work with rather
than talk about starting from scratch.  Removing the existing pieces would
not be nearly as easy as you make it sound.

That's the difference, they *want* this API as it "works/good enough for
> them", whereas many of *need* a lower level API to do anything
> sophisticated at all.
>

You don't need a lower level API.  SDP munging can get you what you need.
 But what you want is to not have to do SDP munging.

My proposal is to add two methods to PeerConnection that, if optionally
used by JS, will give you what you want for media streams: the ability to
control what is sent and received without SDP munging.  It does not,
however, relieve you from SDP munging on the transport side.  But as I've
pointed out, that's limited to about 10 lines of SDP, so at least it's much
less SDP munging.  Later, once could consider more simple additions that
reduce the need for SDP munging further.


> As it stands, it makes many use cases for us who whom don't want to do
> basic SIP/SDP signaling extremely challenging, complex, ugly, brittle, if
> not outright impossible. I've explained many times why using SDP with
> offer/answer is horribly bad idea (and I can re-share those links if
> needed).
>
>
I think your dislike of SDP is sufficiently clear.


>  -Robin
>
>
>    Peter Thatcher <[e-mail]>
>  19 June, 2013 11:15 AM
>
>
>
> I hope so as well.  Unfortunately, Microsoft's input seems to be "our way
> or the highway" and the input of others seems to be "SDP ought to be
> enough for anybody".  My thinking is that we can make incremental
> improvements toward a cleaner API without being so extreme at either end.
>  And I hope I can find others that think similarly.
>
>
>