- From: Iñaki Baz Castillo <ibc@aliax.net>
- Date: Wed, 19 Jun 2013 23:56:44 +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>: >> 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. But... why do you say that "gateways should execute JavaScript"??? JS is just executed in the browser. >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. ¿? I think I have not expressed myself well :) -- Iñaki Baz Castillo <ibc@aliax.net>
Received on Wednesday, 19 June 2013 21:57:31 UTC