[rtcweb] About defining a signaling protocol for WebRTC (or not)

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

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).

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.

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).

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
<[e-mail]>