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

Neil Stratford <neils@belltower.co.uk> Fri, 07 October 2011 11:50 UTC

Return-Path: <neils@vipadia.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 7D95221F8B35 for <rtcweb@ietfa.amsl.com>; Fri, 7 Oct 2011 04:50:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.938
X-Spam-Level:
X-Spam-Status: No, score=-2.938 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 vKo40HOmAgFf for <rtcweb@ietfa.amsl.com>; Fri, 7 Oct 2011 04:50:38 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C7DF221F8AE1 for <rtcweb@ietf.org>; Fri, 7 Oct 2011 04:50:38 -0700 (PDT)
Received: by iaby26 with SMTP id y26so5029632iab.31 for <rtcweb@ietf.org>; Fri, 07 Oct 2011 04:53:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.46.66 with SMTP id i2mr3147938ibf.0.1317988431999; Fri, 07 Oct 2011 04:53:51 -0700 (PDT)
Sender: neils@vipadia.com
Received: by 10.231.200.146 with HTTP; Fri, 7 Oct 2011 04:53:51 -0700 (PDT)
In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com>
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>
Date: Fri, 07 Oct 2011 12:53:51 +0100
X-Google-Sender-Auth: 2piANS5nxWQv2UaRiDagJco4Dcg
Message-ID: <CABRok6n33QK0Si1Y0kT7+U0zgAWsJ4d5GENK_KL-JPx5a4erYg@mail.gmail.com>
From: Neil Stratford <neils@belltower.co.uk>
To: Ravindran Parthasarathi <pravindran@sonusnet.com>
Content-Type: multipart/alternative; boundary="001517740aba4eb4ea04aeb41827"
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: Fri, 07 Oct 2011 11:50:39 -0000

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