- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Thu, 20 Jun 2013 14:31:14 +0200
- To: public-webrtc@w3.org
On 06/19/2013 11:56 PM, Iñaki Baz Castillo wrote: > 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. > > Javascript gets executed in surprising places. but this group is in the business of writing API specs for a browser. If you want to be normative about what gateways should be doing, go to rtcweb@ietf.org. If a specification is written in the form of Javascript, an easy path to implementation is to execute that Javascript. It is significantly harder to implement the same spec in another language. More abstract specs may be easier to implement in multiple languages. YMMV.
Received on Thursday, 20 June 2013 12:31:43 UTC