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

From: Robin Raymond <[email-masked]>
Date: Thu, 20 Jun 2013 12:54:57 -0400

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.

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:[email-masked]>
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

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 20 Jun 2013 10:23:04 -0700

On Thu, Jun 20, 2013 at 9:54 AM, Robin Raymond <[email-masked]> wrote:

> 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.
>
> 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.
>
> 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)
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.

> If anyone has anything I should add to either of these drafts or wants to
> be involved, please contact me.
>
> -Robin
>
>
>   Christer Holmberg <[email-masked]>
>  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.
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Robin Raymond <[email-masked]>
Date: Thu, 20 Jun 2013 13:48:08 -0400

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:[email-masked]>
> 20 June, 2013 1:23 PM
>
>
>
> On Thu, Jun 20, 2013 at 9:54 AM, Robin Raymond <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     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.
>
>     requirements, philosophy, methodology, benefits/pitfalls, use
>     cases that are difficult/impossible with SDP+O/A)
>     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.
>
>     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
>
>
>     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
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 20 Jun 2013 10:48:55 -0700

Peter Thatcher said: 
"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."
[BA] Getting a working implementation of a clean API is not the biggest issue.  The biggest issue is how to determine whether a shim is "successful" or not.   At this point, the reality is that the  implementation code (including undocumented behavior) represents the WebRTC 1.0 specification, rather than the documents produced by W3C and IETF.  This makes the bar (either "backward compatibility" or "equivalent in power") difficult to define, let alone satisfy.

---

From: Robin Raymond <[email-masked]>
Date: Thu, 20 Jun 2013 13:52:38 -0400

Would someone produce unit tests against the produced SDP and offered 
SDP that is the "defined webrtc spec" so the bar could be set? Hitting a 
moving target will be challenging. Seems to me a lot of what is SDP is 
not extremely well defined at this point so the only thing I can do is 
produce "good" SDP since the exact definition of what is webRTC SDP 
seems a bit lacking.

-Robin

> Bernard Aboba <mailto:[email-masked]>
> 20 June, 2013 1:48 PM
> Peter Thatcher said:
>
> [BA] Getting a working implementation of a clean API is not the 
> biggest issue.  The biggest issue is how to determine whether a shim 
> is "successful" or not. At this point, the reality is that the 
>  implementation code (including undocumented behavior) represents the 
> WebRTC 1.0 specification, rather than the documents produced by W3C 
> and IETF.  This makes the bar (either "backward compatibility" or 
> "equivalent in power") difficult to define, let alone satisfy.
>
>

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 20 Jun 2013 10:55:20 -0700

On Thu, Jun 20, 2013 at 10:48 AM, Bernard Aboba
<[email-masked]>wrote:

> [BA] Getting a working implementation of a clean API is not the biggest
> issue.
>

If implementing the clean API in browser is the small issue, then poor
Robin has a massive challenge ahead.

> The biggest issue is how to determine whether a shim is "successful" or
> not.   At this point, the reality is that the  implementation code
> (including undocumented behavior) represents the WebRTC 1.0 specification,
> rather than the documents produced by W3C and IETF.  This makes the bar
> (either "backward compatibility" or "equivalent in power") difficult to
> define, let alone satisfy.
>
>
>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 20 Jun 2013 11:01:59 -0700

Robin said: 

"Would someone produce unit tests against the produced SDP and offered 
SDP that is the "defined webrtc spec" so the bar could be set?"
[BA] If there actually was a "defined webrtc spec" that covered the SDP blob in detail, that would be possible.   But at the moment, that doesn't exist (and seems unlikely to be produced).  
Robin also said: 
"Hitting a
 moving target will be challenging. Seems to me a lot of what is SDP is 
not extremely well defined at this point so the only thing I can do is 
produce "good" SDP since the exact definition of what is webRTC SDP 
seems a bit lacking."
[BA] I would suggest that the SDP subset relating to Audio probably can be well defined enough to produce unit tests.  Given the state of the "Plan A" vs. "Plan B" debate, and the other video-related uncertainties, trying to develop test cases for video would probably be a fool's errand.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 20 Jun 2013 23:27:25 +0200

IMHO this is the way to go, something that will make feasible to build any
*future* protocol that just relies in RTP but not on SDP O/A.

+1

2013/6/20 Robin Raymond <[email-masked]>

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Bossiel thioriguel <[email-masked]>
Date: Thu, 20 Jun 2013 23:44:57 +0100 (BST)

+1 for SDP ...but we (Doubango Telecom) would provide a gateway to SIP/IMS world for any such draft as proof of concept.
I've seen on many posts on msdn blog that it's easy to interop with SIP using CU-RTC-WEB but haven't seen any demo.

________________________________
 De : Iñaki Baz Castillo <[email-masked]>
À : Robin Raymond <[email-masked]> 
Cc : "[email-masked]" <[email-masked]> 
Envoyé le : Jeudi 20 juin 2013 23h27
Objet : Re: [rtcweb] WebRTC JS object API with SDP shim option

IMHO this is the way to go, something that will make feasible to build any *future* protocol that just relies in RTP but not on SDP O/A.

+1

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.
 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.
>Christer Holmberg
>20 June, 2013 
12:55 AM
>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 :)

---

From: Roman Shpount <[email-masked]>
Date: Thu, 20 Jun 2013 18:50:24 -0400

+1 on this as well. We will provide a service which will connect something
that implements this draft to public PSTN/SIP
_____________
Roman Shpount

On Thu, Jun 20, 2013 at 6:44 PM, Bossiel thioriguel <[email-masked]>wrote:

> +1 for SDP ...but we (Doubango Telecom) would provide a gateway to SIP/IMS
> world for any such draft as proof of concept.
> I've seen on many posts on msdn blog that it's easy to interop with SIP
> using CU-RTC-WEB but haven't seen any demo.
>
>   ------------------------------
>  *De :* Iñaki Baz Castillo <[email-masked]>
> *À :* Robin Raymond <[email-masked]>
> *Cc :* "[email-masked]" <[email-masked]>
> *Envoyé le :* Jeudi 20 juin 2013 23h27
> *Objet :* Re: [rtcweb] WebRTC JS object API with SDP shim option
>