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

Tim Panton <> Fri, 07 October 2011 10:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D997D21F8AF7 for <>; Fri, 7 Oct 2011 03:20:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.497
X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TO2wrueeooPH for <>; Fri, 7 Oct 2011 03:20:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E297021F8AB9 for <>; Fri, 7 Oct 2011 03:20:34 -0700 (PDT)
Received: from [] (unknown []) by (Postfix) with ESMTP id 0B49F37A903; Fri, 7 Oct 2011 11:36:35 +0100 (BST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Tim Panton <>
In-Reply-To: <>
Date: Fri, 07 Oct 2011 11:23:41 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <><><> <> <>
To: Ravindran Parthasarathi <>
X-Mailer: Apple Mail (2.1084)
Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Oct 2011 10:20:40 -0000

On 7 Oct 2011, at 07:05, Ravindran Parthasarathi wrote:

> Inaki,
> I understand that you don't want any signaling protocol for RTCWeb  to be standardized. I'm strong believer of "something is better than nothing". Also, My standard signaling protocol proposal is never a hindrance to your innovative custom-build signaling protocol (SIP over websocket) development and the standard signaling protocol is not meant for you in case you are building custom-build signaling protocol. 
> From the RTCweb client programmer perspective, there will be an set of API for building custom build signaling and another top level API which is based on proposed standard signaling. I could not understand why are you so against the standardization of the signaling protocol. 

Because it is a distraction. It is unnecessary, the advantages don't outweigh the disadvantages.

It isn't essential to the success of this effort and would slow us down by _years_ debating the details.

Even if we could magically all instantly agree to use (say) RFC 5456 as the standard (*) , it would then immediately impact the 
core effort, the temptation to add features and helper methods to the core media API that suited the 'standard' signalling protocol
would be irresistible. Pretty soon we'd find we had a media layer that could _only_ work well through the standard signalling protocol.


(*) In my view no one of the currently available signalling protocols are suitable for this effort. They were all designed with 
a totally different set of constraints to the ones faced by rtcweb.