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

[Henry Sinnreich <[e-mail]>]

+1

Thanks, Henry


On 9/14/11 9:56 AM, "Iñaki Baz Castillo" <[e-mail]> wrote:

> 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]>
_______________________________________________
rtcwe
> b mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rtcweb