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

Henry Sinnreich <> Wed, 14 September 2011 15:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 20A6F21F85AA for <>; Wed, 14 Sep 2011 08:37:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.013
X-Spam-Status: No, score=-3.013 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id n3o-2Zsr0Cwz for <>; Wed, 14 Sep 2011 08:37:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5326121F856A for <>; Wed, 14 Sep 2011 08:37:37 -0700 (PDT)
Received: by yxt33 with SMTP id 33so1689631yxt.31 for <>; Wed, 14 Sep 2011 08:39:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=MLFbFy1bSddmCq5vIK8Frd1QDfp2Asj9EjWzw6Xrn/A=; b=h3EM8unW2XryneUWrrEbPmmZm7g3tvzZ9Ra3Op29pcgItX2wBG41JWnVGNRu3plyfe HZ3Ap8odllO0k94//yxU/uPfkjR9DPs78I7IFqSfUNmJI9RN6v6z0WPFx2xI1J3+s61a IRvJUwuv8YoLujkrbJmB89b1M+uLMu/wxV+vI=
Received: by with SMTP id g15mr163947ybf.37.1316014786414; Wed, 14 Sep 2011 08:39:46 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id b4sm8147262ank.3.2011. (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Sep 2011 08:39:44 -0700 (PDT)
User-Agent: Microsoft-Entourage/
Date: Wed, 14 Sep 2011 10:39:40 -0500
From: Henry Sinnreich <>
To: =?ISO-8859-1?B?SfFha2k=?= Baz Castillo <>, <>
Message-ID: <>
Thread-Topic: [rtcweb] About defining a signaling protocol for WebRTC (or not)
Thread-Index: Acxy9IQOdSmFoAqb+Uii2V30vpVrEQ==
In-Reply-To: <>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
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: Wed, 14 Sep 2011 15:37:38 -0000


Thanks, Henry

On 9/14/11 9:56 AM, "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).

> 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
> 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
> draft-ibc-rtcweb-sip-websocket or a XMPP server
> 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

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
> lets each web provider to decide which technology to use as
> protocol, rather than forcing him to implement
SIP/XMPP/other-protocol in
> server side.

Best regards.

Iñaki Baz
> Castillo
> b mailing list