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

Victor Pascual <victor.pascual.avila@gmail.com> Wed, 14 September 2011 20:57 UTC

Return-Path: <victor.pascual.avila@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 84BAC21F8B68 for <rtcweb@ietfa.amsl.com>; Wed, 14 Sep 2011 13:57:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.202
X-Spam-Level:
X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 Wir72d72Va5H for <rtcweb@ietfa.amsl.com>; Wed, 14 Sep 2011 13:57:02 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id E44E521F8B43 for <rtcweb@ietf.org>; Wed, 14 Sep 2011 13:57:01 -0700 (PDT)
Received: by wyg24 with SMTP id 24so2133129wyg.31 for <rtcweb@ietf.org>; Wed, 14 Sep 2011 13:59:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:references:from:content-type:x-mailer:in-reply-to :message-id:date:to:content-transfer-encoding:mime-version; bh=A7XUCrrQ0J/Zsl4hD+1tXXpHy5k/hXsR0LGUWK46flA=; b=tWnANvvjeVCnrEf6eX8TOY7qLJmgQXgiY6bPiVF7M4305+AYOd71rPztMpMTApkKJl gmilebQD7Ij8doKrUGWsC3O/jIJgiqykSeLwv+NMGPglbjVdalgYKYOhKecl22zDCDY5 ZZExCVYM+P222374bzPP5gBeb0lI+rJVe2WBM=
Received: by 10.216.22.202 with SMTP id t52mr253076wet.100.1316033951103; Wed, 14 Sep 2011 13:59:11 -0700 (PDT)
Received: from [192.168.1.26] (47.59-64-87.adsl-dyn.isp.belgacom.be. [87.64.59.47]) by mx.google.com with ESMTPS id fp5sm5446905wbb.2.2011.09.14.13.59.08 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Sep 2011 13:59:09 -0700 (PDT)
References: <CA9634EC.1D875%henry.sinnreich@gmail.com> <snt0-eas3456818F7C5A81BEE1B9B9893040@phx.gbl> <CAD5OKxvp9ePN78bYo3nLFCHdT8ubDwLvp153gi6EV7DP-8nPRA@mail.gmail.com>
From: Victor Pascual <victor.pascual.avila@gmail.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-25-571813362
X-Mailer: iPhone Mail (8K2)
In-Reply-To: <CAD5OKxvp9ePN78bYo3nLFCHdT8ubDwLvp153gi6EV7DP-8nPRA@mail.gmail.com>
Message-Id: <744B2B16-67AB-432D-92DE-7263C935E151@gmail.com>
Date: Wed, 14 Sep 2011 22:59:02 +0200
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (iPhone Mail 8K2)
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:57:03 -0000

+1

On Sep 14, 2011, at 10:22 PM, Roman Shpount <roman@telurix.com>; wrote:

> +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
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb