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

[Peter Thatcher <[e-mail]>]

On Thu, Jun 20, 2013 at 9:54 AM, Robin Raymond <[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 <[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]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>