Hi Inaki,

As your draft draft-ibc-rtcweb-sip-vs-websocket indicates, it is possible for Javascript application to write any signaling protocol and so, there is no blocking factor for innovation in browser platform. I'm seeing the current infrastructure in RTCWeb as "raw socket" in Socket library. The raw socket provides the flexibility and no doubt about it. Also, RTCWeb supports for SIP, XMPP, or some <content> XML using SDP,or some other TLV protocol. 

My point is that the default signaling protocol has to be supported in RTCWeb client which should not be downloaded in runtime to make the dialog between two RTCWeb client. I asked for SIP initially as SIP is the de-facto protocol and mostly deployment. I agree with Peter & others that websocket could be another alternative in the web deployment. In case required, I'll come up the write up to show the needs of default signaling protocol for making dialog between browser to browser.

Please read inline.

Thanks
Partha

>-----Original Message-----
>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
>Of Iñaki Baz Castillo
>Sent: Wednesday, September 14, 2011 8:27 PM
>To: rtcweb@ietf.org
>Subject: [rtcweb] About defining a signaling protocol for WebRTC (or
>not)
>
>Hi all,
>
>There are some threads about the need (or not) for a well defined
>signaling protocol within WebRTC. I would like to comment about it.
>
>WebRTC defines multimedia capabilities for web-browsers and mandates
>protocols as RTP, STUN, ICE, and understanding of SDP (RFC 4566). The
>aim of these protocols is to enable multimedia streams between a
>web-browser and other endpoint (which could also be a web-browser).
>
<partha> I hope that the aim of the protocols is to enable multimedia stream between browser to browser only. In case browser to other end-point is outside the scope of RTCWEb. </partha> 

>But having the above is not enough since a signaling
>protocol/mechanism for managing the media sessions is required (for
>requesting a multimedia session to the endpoint, for terminating it,
>for putting it in hold...).
>
>Both SIP and XMPP (with Jingle) behave as a signaling protocol and
>manage multimedia sessions based on SDP descriptions (SIP uses plain
>SDP grammar as defined in RFC 4566 while XMPP uses a XML version of
>the SDP format). So both SIP and XMPP could be a good choice. But also
>any custom signaling protocol carrying like-SDP information.
>
<partha> I agree with Cullen for his proposal on SDP but I'm not sure whether we will end-up there </partha>

>If WebRTC mandates a specific signaling protocol then all the web
>providers should incorporate such a protocol within their
>infrastructure, which seems not feasible for me (let's say web pages
>served by hosting datacenters which just provide an Apache server for
>the web developer, for example).
>
<partha> Please see the usecase, I have mentioned in http://www.ietf.org/mail-archive/web/rtcweb/current/msg00845.html. The issue in your argument is that you assume web server as RTCWEb server. I agree that it may be preferred but not a MUST item. </partha>

>So I wonder: why is a specific signaling protocol needed at all? AFAIK
>the only we need is an API (within WebRTC) to manage multimedia
>sessions (start it, terminate it, use codec XXXX, put on hold...). How
>the client application (let's assume the JavaScript code) obtains such
>information should be out of the scope of WebRTC. The client
>application (JavaScript) just needs to retrieve (via HTTP, WebSocket
>or whatever) the "SDP" information provided by the endpoint and use
>such data for making API calls to the WebRTC stack by passing as
>arguments the remote peer IP, port, type of session, codec to use, and
>so on.
>
>For example, if a web page makes usage of SIP over WebSocket or XMPP
>over WebSocket, the signaling (also containing SDP information) would
>be carried within SIP or XMPP messages. The only reqiremente would be
>for the WebSocket server to be integrated within a SIP proxy/server
>implementing draft-ibc-rtcweb-sip-websocket or a XMPP server
>implementing draft-moffitt-xmpp-over-websocket. The client application
>(JavaScript in the web page) should parse the SDP bodies and make
>WebRTC calls when appropriate to initiate or answer multimedia
>sessions. And then we get full interoperability with SIP/XMPP world
>out there (without requiring a server/gateway performing conversion of
>application level protocols).
>
>In the same way, other web page which just requires multimedia
>sessions between web-browsers, could prefer to implement a simple and
>custom JSON format as a signaling mechanism on top of WebSocket (or
>use HTTP Comet, long-polling, etc). It could map the SDP definition
>into a JSON struct. Again the JavaScript code parses the SDP
>information and calls WebRTC API functions to manage multimedia
>sessions. The only requirement would be for the HTTP server to
>implement WebSocket or HTTP Comet (or nothing if HTTP long polling is
>used).
>
>So my proposal is that WebRTC should not mandate a signaling protocol
>in the web-browser, but just define a requeriment for managing
>multimedia sessions from the JavaScript code given a well defined API.
>IMHO this is the way that fits well with the flexibility of the web
>and lets each web provider to decide which technology to use as
>signaling protocol, rather than forcing him to implement
>SIP/XMPP/other-protocol in server side.
>
>
>Best regards.
>
>--
>Iñaki Baz Castillo
><ibc@aliax.net>
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb