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

Tim Panton <> Fri, 07 October 2011 12:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4124221F8B19 for <>; Fri, 7 Oct 2011 05:37:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.5
X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0A9uLynaD9Up for <>; Fri, 7 Oct 2011 05:37:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A04A321F85B9 for <>; Fri, 7 Oct 2011 05:37:20 -0700 (PDT)
Received: from [] (unknown []) by (Postfix) with ESMTP id 51D7437A903; Fri, 7 Oct 2011 13:53:21 +0100 (BST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary="Apple-Mail-11-381611972"
From: Tim Panton <>
In-Reply-To: <>
Date: Fri, 07 Oct 2011 13:40:28 +0100
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 12:37:25 -0000

If you had the curtesy to actually read what I'd written, you would have seen that I made 3 arguments.

Just to reinforce my point about the un-suitability of existing protocols, I've now worked on 4 web-rtc
like projects, using 4 different pre-existing protocols (XMPP, SIP, IAX2, proprietary),
so I have quite a bit experience on which to base my remarks. They all worked ok in the problem
space we used them in (which is why we selected each of them for their respective projects),
but no one protocol would have done the job for all the projects. 

Premature standardisation is the enemy of innovation - to coin a phrase. 
This isn't a sunset market, it is a new dawn, we should standardize as little as we possibly can.

You can choose not to agree with my opinions, but please don't mis-represent my remarks.


On 7 Oct 2011, at 11:36, Ravindran Parthasarathi wrote:

> Tim,
> Your argument is "Time to market" RTCWeb compliance and few folks already mentioned about it and also proposing to develop the new protocol.
> At this moment, I don't think that there is a need for developing new signaling protocol for RTCweb. IMO, The argument may be which is best suitable rather than none of the protocol is suitable.
> Sam,
> In case your proposal is not to invent new protocol for RTCWeb signaling.  Please look at my draft which is in the same line.
> Thanks
> Partha
> From: samuel [] 
> Sent: Friday, October 07, 2011 4:01 PM
> To: Tim Panton
> Cc: Ravindran Parthasarathi;
> Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol
> Hi all,
> The point Iñaki is pushing forward is crucial, as Tim also stated, because it will save us the burden of implementing another protocol, the marketing fight between protocols (do you want another SIP vs. H323 "war"?) Please, don't reinvent the wheel, keep it simple.
> Best regards,
> Samuel
> On 7 October 2011 12:23, Tim Panton <> wrote:
> 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.
> Tim.
> (*) 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.
> T.
> _______________________________________________
> rtcweb mailing list