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

Prakash <prakash.tester.im@gmail.com> Wed, 14 September 2011 20:59 UTC

Return-Path: <prakash.tester.im@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 A22D121F8C54 for <rtcweb@ietfa.amsl.com>; Wed, 14 Sep 2011 13:59:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Vw3RZ3WtoLEK for <rtcweb@ietfa.amsl.com>; Wed, 14 Sep 2011 13:59:28 -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 98A8E21F8C39 for <rtcweb@ietf.org>; Wed, 14 Sep 2011 13:59:28 -0700 (PDT)
Received: by yxt33 with SMTP id 33so1987040yxt.31 for <rtcweb@ietf.org>; Wed, 14 Sep 2011 14:01:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=YtAfECuF0BWol1mkugGrcLWt6mOIQDLU5mn/jFvUg8w=; b=BfQyy/AqUU6k2I15hRlpD4I3vfGt7/Fkxi5es7oZ3TJmr9auwzpvaNZiAZff6p2Lib doZ8Ee/7UJ9KLnrCK5L2/uYP5B40modNf+xoEz3DUn/a2WjTFgFWaiUZwf4JtQU7wIg5 NwYg+cq7+cmEKFZFn0HtexE8TaE4RcL+rPMCs=
MIME-Version: 1.0
Received: by 10.68.54.161 with SMTP id k1mr576212pbp.125.1316034044431; Wed, 14 Sep 2011 14:00:44 -0700 (PDT)
Received: by 10.68.63.42 with HTTP; Wed, 14 Sep 2011 14:00:44 -0700 (PDT)
In-Reply-To: <744B2B16-67AB-432D-92DE-7263C935E151@gmail.com>
References: <CA9634EC.1D875%henry.sinnreich@gmail.com> <snt0-eas3456818F7C5A81BEE1B9B9893040@phx.gbl> <CAD5OKxvp9ePN78bYo3nLFCHdT8ubDwLvp153gi6EV7DP-8nPRA@mail.gmail.com> <744B2B16-67AB-432D-92DE-7263C935E151@gmail.com>
Date: Wed, 14 Sep 2011 14:00:44 -0700
Message-ID: <CADwjbP2U+0q8ckZ7Yv2pRi5krugAJA2BEBfBQy4nqtp_z1x9ZA@mail.gmail.com>
From: Prakash <prakash.tester.im@gmail.com>
To: Victor Pascual <victor.pascual.avila@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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:59:29 -0000

+1

On Wed, Sep 14, 2011 at 1:59 PM, Victor Pascual
<victor.pascual.avila@gmail.com>; wrote:
> +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
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>