[rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]

"Ravindran Parthasarathi" <pravindran@sonusnet.com> Thu, 15 September 2011 23:59 UTC

Return-Path: <pravindran@sonusnet.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id F13E31F0C3C for <rtcweb@ietfa.amsl.com>; Thu, 15 Sep 2011 16:59:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.342
X-Spam-Status: No, score=-2.342 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id KQo6hb8XwHEO for <rtcweb@ietfa.amsl.com>; Thu, 15 Sep 2011 16:59:57 -0700 (PDT)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com []) by ietfa.amsl.com (Postfix) with ESMTP id 5EF6D1F0C3B for <rtcweb@ietf.org>; Thu, 15 Sep 2011 16:59:57 -0700 (PDT)
Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com []) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p8G02aCR011719; Thu, 15 Sep 2011 20:02:36 -0400
Received: from sonusinmail02.sonusnet.com ([]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Sep 2011 19:56:46 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 16 Sep 2011 05:26:45 +0530
Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com>
In-Reply-To: <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com>
Thread-Topic: RTCWeb default signaling protocol [was RE: [rtcweb] About defining a signaling protocol for WebRTC (or not)]
Thread-Index: AcxzfIlTZtq9ST3YRzeqHdWEUmGLFAAhHZdw
References: <CALiegfnOCxyTo9ffQ272+ncdu5UdgrtDT-dn10BWGTZMEjZoCg@mail.gmail.com> <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com>
From: "Ravindran Parthasarathi" <pravindran@sonusnet.com>
To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= <saul@ag-projects.com>
X-OriginalArrivalTime: 15 Sep 2011 23:56:46.0105 (UTC) FILETIME=[20363890:01CC7403]
Cc: rtcweb@ietf.org
Subject: [rtcweb] RTCWeb default signaling protocol [was RE: 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: Thu, 15 Sep 2011 23:59:58 -0000

Hi Saul,

I really didn't get your argument fully because in case there is no default signaling protocol, it is unavoidable to have island of devices without gateways but you argue other way around. 

I specifically asked for the scope of your opinion on RTCWeb work is between browser-to-browser or browser-to-other end-point to know whether parallel universe has to be build or not. In case there is no default signaling protocol, it is impossible to communicate between browser-to-endpoint without gateways. Let us assume that the intention of RTCWeb is to create island of browser devices even then the native signaling protocol for RTCWeb has advantage over Jquery library and plugin is not the solution.

Having said that, I agree that it is possible to implement RTP or STUN or SIP stack or codec using Javascript or plugins but interop and better performance is not guaranteed.


>-----Original Message-----
>From: Saúl Ibarra Corretgé [mailto:saul@ag-projects.com]
>Sent: Thursday, September 15, 2011 1:23 PM
>To: Ravindran Parthasarathi
>Cc: Iñaki Baz Castillo; rtcweb@ietf.org
>Subject: Re: [rtcweb] About defining a signaling protocol for WebRTC (or
>> My point is that the default signaling protocol has to be supported in
>RTCWeb client which should not be downloaded in runtime to make the
>dialog between two RTCWeb client. I asked for SIP initially as SIP is
>the de-facto protocol and mostly deployment. I agree with Peter & others
>that websocket could be another alternative in the web deployment. In
>case required, I'll come up the write up to show the needs of default
>signaling protocol for making dialog between browser to browser.
>Do you mean there should be a 'default signaling protocol' on every
>browser? I'm not sure I'd like that. I (personally) see RTCWeb as a
>framework on top of which we can build RTC applications. The fact that
>one would use SIP and someone else uses something else is not crucial,
>IMHO. Now if some new simplified protocol is chosen for browser-to-
>browser communication we'd have yet another island of devices (browsers
>in this case) to which we'd need to gateway somehow.
>>> 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).
>> <partha> I hope that the aim of the protocols is to enable multimedia
>stream between browser to browser only. In case browser to other end-
>point is outside the scope of RTCWEb. </partha>
>Well, why build a parallel universe just for the browsers? If RTCWeb
>would only define the media plane and developers themselves can choose
>the signaling protocol, the integration with existing communication
>systems (using SIP or XMPP for example since they are the most used
>ones) would be pretty straight-forward.
>My 2 cents.
>Saúl Ibarra Corretgé
>AG Projects