Re: [rtcweb] Review request for RTCWeb standard signaling protocol

"Ravindran Parthasarathi" <pravindran@sonusnet.com> Mon, 17 October 2011 07:45 UTC

Return-Path: <pravindran@sonusnet.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 5DDDE21F8B35 for <rtcweb@ietfa.amsl.com>; Mon, 17 Oct 2011 00:45:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 xgcoCYTIv84g for <rtcweb@ietfa.amsl.com>; Mon, 17 Oct 2011 00:45:13 -0700 (PDT)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBFA21F8B33 for <rtcweb@ietf.org>; Mon, 17 Oct 2011 00:45:13 -0700 (PDT)
Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p9H7jeBE005300; Mon, 17 Oct 2011 03:45:40 -0400
Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 03:45:05 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC8CA0.AD35D50C"
Date: Mon, 17 Oct 2011 13:15:15 +0530
Message-ID: <2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com>
In-Reply-To: <CABRok6n33QK0Si1Y0kT7+U0zgAWsJ4d5GENK_KL-JPx5a4erYg@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol
Thread-Index: AcyE58qiQsg22CmbRQ+ec/AyTlzr8wHt+TLw
References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><CALiegf=ejF2kUC1m=74o9eprF1M8wYtgE-Crwa1x14rzDOf+gQ@mail.gmail.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><CAOg=WDcC9t2KhQUg0gDJ60gO_2mNyMv9HKt=otCdPDfj4TnoTg@mail.gmail.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com><CABRok6mM7TfbLgGhoQvdRh1Kwoi5BhRweLcqWg7VZOFnaa8VOw@mail.gmail.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com> <CABRok6n33QK0Si1Y0kT7+U0zgAWsJ4d5GENK_KL-JPx5a4erYg@mail.gmail.com>
From: Ravindran Parthasarathi <pravindran@sonusnet.com>
To: Neil Stratford <neils@belltower.co.uk>
X-OriginalArrivalTime: 17 Oct 2011 07:45:05.0876 (UTC) FILETIME=[AFC94140:01CC8CA0]
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol
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: Mon, 17 Oct 2011 07:45:14 -0000

<snip> My argument is that if we want the ultimate goal of simplicity
for end user web developers then we should minimise everything they have
to touch - and that includes removing any requirement for server side
infrastructure beyond the basic bare minimum, which would mean no SIP
proxies, no websocket servers etc etc.

 

But as I said, we don't need to standardise a protocol at all, so we
shouldn't. If we are lucky we'll see a whole spectrum of solutions.

 </snip>

 

Without server interaction, it is not possible for browser to establish
the session with other browser. Unlike other endpoint, browser needs
server to provide routing or  perform the authentication or atleast
configuration information. AFAIK, RTCWeb client to RTCWeb client is not
the motive of the work. If so, SIP is the IETF protocol between RTCWeb
client to RTCWeb client which MUST be recommended because of the UA to
UA communication nature. IOW, RTCWeb server signaling plays the key role
which calls for standardization as browser & RTCWebserver is not
required from the same vendor.

 

Thanks

Partha

 

From: neils@vipadia.com [mailto:neils@vipadia.com] On Behalf Of Neil
Stratford
Sent: Friday, October 07, 2011 5:24 PM
To: Ravindran Parthasarathi
Cc: samuel; Tim Panton; rtcweb@ietf.org
Subject: Re: [rtcweb] Review request for RTCWeb standard signaling
protocol

 

On Fri, Oct 7, 2011 at 12:40 PM, Ravindran Parthasarathi
<pravindran@sonusnet.com> wrote:

	Browser to browser real time communication is no different from
other real-time communication apart from the existing web
infrastructure. In case your argument is to use the existing web
infrastructure like websocket, I agree with you.

 

It is different to traditional RTC - we have a javascript execution
engine intimately tied in to every client. This completely changes the
solution space.

 

	But in case it is not the reason, Could you please list the
reason for new signaling protocol requirement .

 

I already listed them: 

	 

	- No server side infrastructure (SIP proxies etc) to maintain or
configure.

	- No special understanding in the server side web application
beyond discovering peer identities you might want to communicate with.

 

My argument is that if we want the ultimate goal of simplicity for end
user web developers then we should minimise everything they have to
touch - and that includes removing any requirement for server side
infrastructure beyond the basic bare minimum, which would mean no SIP
proxies, no websocket servers etc etc.

 

But as I said, we don't need to standardise a protocol at all, so we
shouldn't. If we are lucky we'll see a whole spectrum of solutions.

 

Neil