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

José Luis Millán <> Thu, 15 September 2011 07:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BCF9221F84F5 for <>; Thu, 15 Sep 2011 00:48:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.65
X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iELa7yTQUuMb for <>; Thu, 15 Sep 2011 00:48:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6473D21F84DC for <>; Thu, 15 Sep 2011 00:48:08 -0700 (PDT)
Received: by iadj38 with SMTP id j38so297226iad.1 for <>; Thu, 15 Sep 2011 00:50:19 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id j4mr678217ict.135.1316073017827; Thu, 15 Sep 2011 00:50:17 -0700 (PDT)
Received: by with HTTP; Thu, 15 Sep 2011 00:50:17 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Thu, 15 Sep 2011 09:50:17 +0200
Message-ID: <>
From: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= <>
To: Soo-Hyun Choi <>
Content-Type: multipart/alternative; boundary=90e6ba613858b9e0e804acf62007
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:48:12 -0000

Totally agree, Iñaki


2011/9/15 Soo-Hyun Choi <>

> +1
> 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
> _______________________________________________
> rtcweb mailing list