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

Henry Sinnreich <henry.sinnreich@gmail.com> Wed, 14 September 2011 15:37 UTC

Return-Path: <henry.sinnreich@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A6F21F85AA for <rtcweb@ietfa.amsl.com>; Wed, 14 Sep 2011 08:37:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.013
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3o-2Zsr0Cwz for <rtcweb@ietfa.amsl.com>; Wed, 14 Sep 2011 08:37:37 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5326121F856A for <rtcweb@ietf.org>; Wed, 14 Sep 2011 08:37:37 -0700 (PDT)
Received: by yxt33 with SMTP id 33so1689631yxt.31 for <rtcweb@ietf.org>; Wed, 14 Sep 2011 08:39:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.150.183.15 with SMTP id g15mr163947ybf.37.1316014786414; Wed, 14 Sep 2011 08:39:46 -0700 (PDT)
Received: from [192.168.15.2] (cpe-76-184-224-113.tx.res.rr.com [76.184.224.113]) by mx.google.com with ESMTPS id b4sm8147262ank.3.2011.09.14.08.39.44 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Sep 2011 08:39:44 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.30.0.110427
Date: Wed, 14 Sep 2011 10:39:40 -0500
From: Henry Sinnreich <henry.sinnreich@gmail.com>
To: =?ISO-8859-1?B?SfFha2k=?= Baz Castillo <ibc@aliax.net>, <rtcweb@ietf.org>
Message-ID: <CA9634EC.1D875%henry.sinnreich@gmail.com>
Thread-Topic: [rtcweb] About defining a signaling protocol for WebRTC (or not)
Thread-Index: Acxy9IQOdSmFoAqb+Uii2V30vpVrEQ==
In-Reply-To: <CALiegfnOCxyTo9ffQ272+ncdu5UdgrtDT-dn10BWGTZMEjZoCg@mail.gmail.com>
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-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Sep 2011 15:37:38 -0000

+1

Thanks, Henry


On 9/14/11 9:56 AM, "Iñaki Baz Castillo" <ibc@aliax.net>; 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
<ibc@aliax.net>;
_______________________________________________
rtcwe
> b mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb