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

Soo-Hyun Choi <> Thu, 15 September 2011 07:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9A58021F8508 for <>; Thu, 15 Sep 2011 00:28:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7N-Uy4rD+iay for <>; Thu, 15 Sep 2011 00:28:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 46B1721F84DC for <>; Thu, 15 Sep 2011 00:28:01 -0700 (PDT)
Received: by bkaq10 with SMTP id q10so2449815bka.31 for <>; Thu, 15 Sep 2011 00:30:10 -0700 (PDT)
Received: by with SMTP id u11mr442952bkw.143.1316071810101; Thu, 15 Sep 2011 00:30:10 -0700 (PDT)
Received: from ( []) by with ESMTPS id t18sm2100583bkb.9.2011. (version=SSLv3 cipher=OTHER); Thu, 15 Sep 2011 00:30:09 -0700 (PDT)
Received: by bkaq10 with SMTP id q10so2449777bka.31 for <>; Thu, 15 Sep 2011 00:30:08 -0700 (PDT)
Received: by with SMTP id m5mr427008bkm.171.1316071808202; Thu, 15 Sep 2011 00:30:08 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 15 Sep 2011 00:29:48 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Soo-Hyun Choi <>
Date: Thu, 15 Sep 2011 16:29:48 +0900
Message-ID: <>
Content-Type: multipart/alternative; boundary=0015175cd84ea079d304acf5d841
Subject: Re: [rtcweb] About defining a signaling protocol for WebRTC (or not)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 15 Sep 2011 07:28:02 -0000


On Wed, Sep 14, 2011 at 23:56, Iñaki Baz Castillo <> 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
> <>
> _______________________________________________
> rtcweb mailing list