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

"Ravindran Parthasarathi" <pravindran@sonusnet.com> Mon, 17 October 2011 07:55 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 28EAF21F849C for <rtcweb@ietfa.amsl.com>; Mon, 17 Oct 2011 00:55:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 Wvh2cEPWCnUY for <rtcweb@ietfa.amsl.com>; Mon, 17 Oct 2011 00:55:58 -0700 (PDT)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 6A37821F8493 for <rtcweb@ietf.org>; Mon, 17 Oct 2011 00:55:58 -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 p9H7uTL1012651; Mon, 17 Oct 2011 03:56:29 -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:55:55 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 17 Oct 2011 13:26:05 +0530
Message-ID: <2E239D6FCD033C4BAF15F386A979BF511598F1@sonusinmail02.sonusnet.com>
In-Reply-To: <1636CB96-8B00-4387-8ED2-9B74EB818E45@acmepacket.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol
Thread-Index: AQHMhSH3WAYm6sWfE0aVzRoo8GFJXZWAN0Jg
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> <1636CB96-8B00-4387-8ED2-9B74EB818E45@acmepacket.com>
From: "Ravindran Parthasarathi" <pravindran@sonusnet.com>
To: "Hadriel Kaplan" <HKaplan@acmepacket.com>, <rtcweb@ietf.org>
X-OriginalArrivalTime: 17 Oct 2011 07:55:55.0336 (UTC) FILETIME=[32E4FC80:01CC8CA2]
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:55:59 -0000

Hadriel,

<snip> Neil makes an excellent point which has only been briefly brought
up but
>should be made more explicit: picking a standard signaling protocol for
>the Browser to implement is only half the problem - the other half of
>the problem is the Web Server has to implement it too, tie it into a
>location database, possibly with authentication and authorization
policy
>rules, and whatever else the specific Web application needs. </snip>

My way of looking at the problem is between RTCWeb client (browser +
javascript) and RTCWeb server signaling. I think that we are in the
agreement that server has to perform couple of functionality like
authentication and authorization policy which is normally dealt in all
signaling protocol. My point is that it is better to spell out RTCWeb
standard protocol between RTCWeb client and RTCWeb server by which
RTCWeb server vendors shall interop smoothly with RTCWeb client. I
missed to spell out in my draft about RTCWeb server dependency but
pointed out the issues in gateway development of RTCWeb server & legacy
server and it may be because I'm more concern about gateways ;-) I'll
clarify in the next revision.

Also, I'm not against creative RTCweb developer to innovate new
signaling protocol for their website. But IETF MUST not mandate every
web developer to create the signaling protocol to make RTCWeb solution
work. 

Thanks
Partha

>-----Original Message-----
>From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]
>Sent: Saturday, October 08, 2011 12:20 AM
>To: <rtcweb@ietf.org>;
>Cc: Ravindran Parthasarathi; Neil Stratford
>Subject: Re: [rtcweb] Review request for RTCWeb standard signaling
>protocol
>
>
>Neil makes an excellent point which has only been briefly brought up
but
>should be made more explicit: picking a standard signaling protocol for
>the Browser to implement is only half the problem - the other half of
>the problem is the Web Server has to implement it too, tie it into a
>location database, possibly with authentication and authorization
policy
>rules, and whatever else the specific Web application needs.
>
>There is no "20 lines of code" solution once you realize that.  It may
>be 20 lines of JavaScript, but that's only part of the
problem/solution.
>In fact, the most likely way to get to 20 lines of code for the Web
>Server owner is for him/her to use a public JS library for signaling
>which is paired with a web server module written for that specific JS
>library.
>
>-hadriel
>
>
>On Oct 7, 2011, at 7:16 AM, Neil Stratford wrote:
>
>>
>> If we did go down the hypothetical new standard protocol route (which
>I really think we shouldn't) my requirements would be:
>> - 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.
>>
>> Which would lead to something looking like a browser maintained peer
>to peer network, at which point we are re-inventing the web, which
>sounds like something beyond this group. So I strongly support not
>picking a default and instead encourage some innovation at the
>javascript level.
>>
>> Neil
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb