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

Roman Shpount <roman@telurix.com> Wed, 14 September 2011 20:20 UTC

Return-Path: <roman@telurix.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 AA58321F8C0C for <rtcweb@ietfa.amsl.com>; Wed, 14 Sep 2011 13:20:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.713
X-Spam-Level:
X-Spam-Status: No, score=-2.713 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 zsuWCgpT0U-N for <rtcweb@ietfa.amsl.com>; Wed, 14 Sep 2011 13:20:08 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7F33821F8BE8 for <rtcweb@ietf.org>; Wed, 14 Sep 2011 13:20:08 -0700 (PDT)
Received: by ywa6 with SMTP id 6so1953821ywa.31 for <rtcweb@ietf.org>; Wed, 14 Sep 2011 13:22:18 -0700 (PDT)
Received: by 10.90.38.10 with SMTP id l10mr278577agl.101.1316031738134; Wed, 14 Sep 2011 13:22:18 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by mx.google.com with ESMTPS id s15sm9683792ank.8.2011.09.14.13.22.17 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Sep 2011 13:22:17 -0700 (PDT)
Received: by yxt33 with SMTP id 33so1955152yxt.31 for <rtcweb@ietf.org>; Wed, 14 Sep 2011 13:22:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.5.162 with SMTP id t2mr500634pbt.241.1316031736358; Wed, 14 Sep 2011 13:22:16 -0700 (PDT)
Received: by 10.68.55.39 with HTTP; Wed, 14 Sep 2011 13:22:16 -0700 (PDT)
In-Reply-To: <snt0-eas3456818F7C5A81BEE1B9B9893040@phx.gbl>
References: <CA9634EC.1D875%henry.sinnreich@gmail.com> <snt0-eas3456818F7C5A81BEE1B9B9893040@phx.gbl>
Date: Wed, 14 Sep 2011 16:22:16 -0400
Message-ID: <CAD5OKxvp9ePN78bYo3nLFCHdT8ubDwLvp153gi6EV7DP-8nPRA@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary=bcaec52159a528a59d04acec8473
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 20:20:09 -0000

+1
_____________
Roman Shpount


On Wed, Sep 14, 2011 at 4:08 PM, Bernard Aboba <bernard_aboba@hotmail.com>wrote:

> +1
>
>
>
> On Sep 14, 2011, at 10:39 AM, "Henry Sinnreich" <henry.sinnreich@gmail.com>;
> wrote:
>
> > +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
> >
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>