- From: Iñaki Baz Castillo <ibc@aliax.net>
- Date: Wed, 19 Jun 2013 19:08:05 +0200
- To: cowwoc <cowwoc@bbs.darktech.org>
- Cc: Adrian Georgescu <ag@ag-projects.com>, Jesús Leganés Combarro <piranna@gmail.com>, Frédéric Luart <frederic.luart@apizee.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>
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ñaki Baz Castillo <ibc@aliax.net>
Received on Wednesday, 19 June 2013 17:08:52 UTC