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

"Ravindran Parthasarathi" <> Fri, 07 October 2011 10:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B949021F84DC for <>; Fri, 7 Oct 2011 03:37:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.495
X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2pWdTRxj+Ib8 for <>; Fri, 7 Oct 2011 03:37:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C011721F84D9 for <>; Fri, 7 Oct 2011 03:37:20 -0700 (PDT)
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id p97Af3ke020368; Fri, 7 Oct 2011 06:41:03 -0400
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Oct 2011 06:36:27 -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_01CC84DC.F5ED0B41"
Date: Fri, 07 Oct 2011 16:06:22 +0530
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol
Thread-Index: AcyE3C+SnY6tf2ujRza4OzYU8jzKwgAAHS6g
References: <><><><><><> <>
From: Ravindran Parthasarathi <>
To: samuel <>, Tim Panton <>
X-OriginalArrivalTime: 07 Oct 2011 10:36:27.0201 (UTC) FILETIME=[F7CD7310:01CC84DC]
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:37:21 -0000



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. 




In case your proposal is not to invent new protocol for RTCWeb signaling.  Please look at my draft which is in the same line.





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,


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.


(*) 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.


rtcweb mailing list