W3C home > Mailing lists > Public > public-webrtc@w3.org > March 2012

Re: Draft of alternative JSEP API proposal

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Fri, 16 Mar 2012 15:49:44 +0100
Message-ID: <4F635308.9000906@ericsson.com>
To: Neil Stratford <nstratford@voxeo.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>

On 03/15/2012 12:34 PM, Neil Stratford wrote:
> Thanks for posting this draft.
> We now have some experience developing real applications using the
> existing ROAP based API and have running code using Phono using
> WebRTC ROAP as the media layer in Chrome Canary to make both
> WebRTC/WebRTC and WebRTC/PSTN calls.

Thanks for you feedback and for sharing your developer experience. 
(Although I don't think it's entirely correct to to talk about "the 
existing ROAP based API" since ROAP is a signaling protocol and the API 
has been around since before ROAP was created.)

> Some observations and feedback:
> - While the browser maintaining the signalling state machine and
> invoking the JS using callbacks makes the simple case very easy, it
> can easily result in spaghetti code for anything more complicated
> where the state machine needs to be maintained by the JS application.
> You end up with a split system where you are waiting for a callback
> which could have just as easily been synchronous (and a lot easier to
> understand).

The existing API is indeed optimized for the simple browser to browser 
case where signaling messages are conveyed to the remote peer without 
modification. It's really important to support more advanced use cases 
as well, but I think it's less problematic if extra code is needed for 
developers who want to adapt the system to work in a specific way.

> - The desire for SIP interop and it's influence on the API is
> possibly a red herring. From our experience with the SDP generated by
> Chrome Canary it's very unlikely we'll ever find an existing third
> party device that will be able to parse it, let alone act on it
> correctly. We ended up developing a special SBC that could both parse
> and generate compatible SDP and relay RTP from the SRTP/ICE that is
> required by WebRTC.

I think you're right about this. The SDPs will probably look the same 
regardless of how the API looks like.

Received on Friday, 16 March 2012 14:55:40 UTC

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