Re: Draft of alternative JSEP API proposal

Hi,

On 16 Mar 2012, at 15:10, Stefan Hakansson LK wrote:
>>> - 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).

I agree that we would never want to block, but is there anything besides candidate gathering that could block? The candidate state machine needs to be driven by the browser, but codec negotiation etc presumably would never block. (or can it?)

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

I think the problems stem from the split state machine. The javascript is maintaining a higher level state machine which is occasionally driven by waiting for an event from the browser from a callback, so we have both the user, the remote agent, and the browser all asynchronously causing things to happen. Keeping synchronous actions in synchronous APIs seems to make that easier to deal with, but it's not a big complication - I suspect most developers will use a third party library which will hide all the nasty async stuff as much as possible.

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

I guess I'm just saying that from our experience so far the fact it's SDP rather than some other JSON or XML format session description doesn't seem to have helped a lot. Assuming that because it's SDP it's a standard that everyone can parse seems a little optimistic, and once you need to modify it anyway, it would be a lot easier if it was in a format that made that easy. (This will get better I'm sure as we start testing implementations against each other.)

Neil

Received on Friday, 16 March 2012 16:12:24 UTC