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

Re: Draft of alternative JSEP API proposal

From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
Date: Fri, 16 Mar 2012 16:10:21 +0100
Message-ID: <4F6357DD.1030901@ericsson.com>
To: public-webrtc@w3.org
On 03/16/2012 03:49 PM, Adam Bergkvist wrote:
> Hi
>
> 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).

I think the reason for asynchronous callbacks is to not stop the JS 
execution (which would lead to unresponsive apps). E.g., if the 
signaling messaged could be delivered immediately on request that would 
not be needed. I don't know if that is possible or not (guess it depends 
a bit on the underlying implementation and if new candidates must be 
obtained and so on).

It would be interesting to learn a bit more of the "spagetti" problems! 
We have also done a lot of testing (including PSTN and SIP interop - 
including DTMF; some info is available here: 
https://labs.ericsson.com/developer-community/blog/webrtc-interworking-traditional-telephony-services), 
and have not found it that cumbersome.

>
> 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.
>
> /Adam
>
Received on Friday, 16 March 2012 15:10:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 16 March 2012 15:10:51 GMT