Re: [rtcweb] WebRTC JS object API with SDP shim option

[Robin Raymond <[e-mail]>]

Correct, it is a lot of work. And I am greatly concerned that it will be 
ignored despite it potentially being the better option. I truly hope 
that if I do undertake this effort it will be given serious 
consideration. I really do have the industry's future at heart and even 
believe the SIP guys would be much better off if they had it as a 
JavaScript shim instead of backed into the browser binary.

I will test in stages. Meaning, that I will provide unit tests with fake 
media/RTC engines underneath. Once I prove that the wiring works, I'll 
likely test this by taking our Open Peer client (which already works on 
webrtc C++ library's source internally) and interfacing to it from 
JavaScript and controlling it from the shim. With that I'll prove that 
it works by taking the SDP and connecting with real SIP networks and 
establishing calls. That will prove that we can do this entirely from 
JavaScript and interface between two independent signaling engines and 
connect to existing SIP networks at the same time. It's not the browser, 
but it's the same engine.

Despite this, I fear that this work will be ignored no matter what I go 
through to prove it works better for everyone, and I don't want to go 
with learning the entire Chrome or Firefox source code and forking it 
only to be told no even if I make it work. That's why I'm going to do it 
in stages.

-Robin


> Peter Thatcher <mailto:[e-mail]>
> 20 June, 2013 1:23 PM
>
>
>
> On Thu, Jun 20, 2013 at 9:54 AM, Robin Raymond <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>
>     You are right. It's time for those of us who are begging for an
>     alternative to SDP to come up with an alternative.
>
>     I'm willing to lead such an effort. I just ask others to please
>     have an open mind. I absolutely do understand the need for the SIP
>     world to have an easy API they can use for SDP. But I also know
>     SDP as an primary surface API is making anything beyond a basic
>     calling a requirement to mangle SDP as a mechanism to control and
>     obtain properties from an underlying media/RTC engine.
>
>     I think there is a really good compromise. That is to provide an
>     API that will adhere to the security policies needed (e.g.
>     respects the need to require ICE establishment), but provides a
>     simple shim API similar to what people already have with SDP but
>     not be required to use for those who want to a more direct approach.
>
>     There's no need to "burn" the entire thing to the ground and start
>     over and that is _not_ my desire.
>
>     This WebRTC thing must succeed but I can't imagine the W3C
>     accepting our proposal for mangling SDP as a primary surface API
>     to do common edge case scenarios. WIth an alternative proposal
>     that satisfies both camps, I believe they could accept and we can
>     stop the anit-SDP crowd grumblings once and for all.
>
>     To that end I'm going to write two drafts:
>     draft-raymond-webrtc-js-object-api-rationale-00 (to explain
>     requirements, philosophy, methodology, benefits/pitfalls, use
>     cases that are difficult/impossible with SDP+O/A)
>     draft-raymond-webrtc-js-object-api-00 (to outline the actual API)
>
>     Plus, I'll produce a shim on top of whatever API that will allow
>     the SDP folks to have a simple SDP based API similar to what
>     exists now but is entirely written in JavaScript to prove that
>     this can be done.
>
>
> How are you going to test that shim without a working implementation 
> of the clean API?
>
> One thing you could do is build a shim of clean API -> SDP.  Then, 
> you'd have two shims which would make a fun combination (SDP -> clean 
> API -> SDP) and you're prove that SDP munging and the clean API are 
> equivalent in power.
>
> Or you could fork Chrome or Firefox.
>
> Either way, you have a lot of work ahead of you.  Best of luck.
>
>     I really want a viable solutions for all interested in having a
>     really good proposal API to ultimately become accepted by the W3C.
>
>     If anyone has anything I should add to either of these drafts or
>     wants to be involved, please contact me.
>
>     -Robin
>
>
>     Christer Holmberg <mailto:[e-mail]>
>     20 June, 2013 12:55 AM
>     Hi,
>
>
>     At the virtual interim, the Plan A and Plan B folks were asked to
>     sit down and try to come up with a compromise "Plan AB" solution.
>
>     I guess it would be good if people that don't want SDP could try
>     to come up with a compromise "CU No Plan" solution :)
>
>     Regards,
>
>     Christer
>
>
>     _______________________________________________
>     rtcweb mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>