W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

Re: Cisco's position on the WebRTC API

From: cowwoc <cowwoc@bbs.darktech.org>
Date: Wed, 24 Jul 2013 00:58:40 -0400
Message-ID: <51EF5F00.1050003@bbs.darktech.org>
To: Eric Rescorla <ekr@rtfm.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 23/07/2013 11:59 PM, Eric Rescorla wrote:
>     We need more frequent webrtc-public IRC meetings
> I (and I suspect others) prefer con calls to IRC meetings. I don't 
> think this presents an undue
> barrier to entry.

     No problem. Please announce these on webrtc-public with 
instructions on how to join and we will happily meet you there.

>     and more Web Developer representation (ideally unaffiliated with
>     any business interest). A recurring theme I keep on bringing up is
>     that we have an insufficient number of active Web Developers in
>     the Working Group and official meetings. I've asked Stefan
>     recently (I don't think he's had the chance to respond yet) and
>     I'll ask you the same: what is the Working Group's plan to rectify
>     this?
> I'm not sure what you suggest we do. This is a volunteer effort and 
> the list
> is open to anyone. That said, this seems to me to be a fairly 
> representative
> WG in terms of non-company engagement when compared to the other
> two W3C WGs I am involved in (WebAppSec and peripherally WebCrypto).
> Both Google and Mozilla have mailing lists where there is active 
> discussion
> from Web Developers and I think the people from both organizations try to
> take that feedback onboard. of course that feedback still gets filtered
> through the representatives from those organizations, but there's nothing
> stopping developers from posting directly here.

     The solution I am leaning towards is divorcing WebRTC from Telecoms 
and Web Developers. This sounds like the easiest solution. In that case 
I would expect Browser Vendors to agree to a common API that is 
interoperable across all browsers and (key point!) does not unduly 
influence design decisions of APIs placed on top of it. From a 
decision-making process point of view, things should move a lot faster 
because each one of us will be negotiating with similarly-minded players.

     I would then layer a Telecom API and Web Developer API on top of 
the Browser API. The Telecom API would plug in SDP as a transport layer. 
The Web Developer API would use another transport layer. Both 
implementations would translate from/to Constraints on top of different 
transport layers.

     Figure out which API components need to be plugable (e.g. 
signaling). That's the goal, we can have more concrete discussions on 
how to achieve that.

Received on Wednesday, 24 July 2013 04:59:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:50 UTC