Re: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)])

[Iñaki Baz Castillo <[e-mail]>]

2011/9/26 Ravindran Parthasarathi <[e-mail]>:
> What level of interop is required for the online registered players? All RTCWEb browser (Mozilla, chrome, IE) player should be able interop without need of browser specific JS or plugin.

Ravindran, you insist of that even when multiple comments tell you the
opposite. If Mozilla, Chrome or IE browsers are visiting the *same*
website then they *already* share the *same* JavaScript (loaded from
the website) so they can signal the media thought the web server (by
using HTTP or WebSocket) as defined in the retrieved JavaScript code.
This is easy to understand IMHO and this is how WWW works for years =>
interoperability between clients visiting the same website. Period.

If the browsers speak *native* SIP (as you suggest in many threads)
then the web server is unaware of what is happening at media level
between the visitors (because the web server, where the application
logic is, does not see the signaling traffic).


> Here, there is a need of defining the common underlying protocol (which is not RTCWeb developer concern).

No, it's not. You can repeat 1000 times by ignoring any rationale
already replied to you in multiple threads. But that changes nothing.
WebRTC does not need native SIP or native XMPP/Jingle spoken by web
browsers. In fact, that would stop innovation, would mandate website
admins to provide a SIP/XMPP server within their infrastructure (how!)
and would make WebRTC unfeasible in shared web hostings.


The only point of discussion here is the requirements for the custom
JavaScript code retrieved from the web server in order to interoperate
with the WebRTC stack in the browser, and the JS API defining the
methods to read and generate media descriptions (like-SDP) that would
be sent to the other peer via the signaling path (HTTP/WebSocket).


Regards.



-- 
Iñaki Baz Castillo
<[e-mail]>