Alternative to the offer/answer mechanism

On 19/06/2013 1:08 PM, Iñaki Baz Castillo wrote:
> 2013/6/19 cowwoc <cowwoc@bbs.darktech.org>:
>>> Ironically, with the model we propose, SBC vendors will be able to
>>> provide their own JS SIP+SDP library so websites can buy licences of
>>> such a JS library to interop with the SBC :)
>>
>>      No one is going to play such a game (changing client code depending on
>> what SBC is being used). Gateways are supposed to be transparent.
>
> May be you could play such a game if you don't see WebRTC as a generic
> SIP phone running in a browser capable of connecting to any SIP
> provider. That's not WebRTC.
>
> WebRTC starts when a user navigates a web, gets a WebRTC JS code
> (unknowingly) and the web page offers him multimedia capabilities for
> contacting other users (or PSTN numbers if you want). Then the JS app
> connects, somehow, to the same web server or a different
> HTTP/WebSocket server for initializating the signaling channel (if
> needed), and then RTP happens.
>
> Now note that the WebRTC JS code and the HTTP/WebSocket server are
> provided by the *same* website / domain / provider, so forget
> interoperability problems.
>

     I'm not in a position to answer that question, only vendors and 
gateway providers are. If gateways are in a position to execute 
Javascript then this might work, but I don't think you necessarily have 
to force Javascript on them. There are plenty of "dumb" data formats 
(like SDP) that could act as a good replacement for the offer/answer 
mechanism without requiring gateways to implement an entire Javascript 
engine.

     In any case, I've taken the liberty of renaming the subject line 
because we're discussing two different topics. Please use this new 
subject line from now on in order to avoid hijacking the original 
discussion.

Thank you,
Gili

Received on Wednesday, 19 June 2013 19:49:40 UTC