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

"Ravindran Parthasarathi" <> Mon, 17 October 2011 13:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2065621F8B88 for <>; Mon, 17 Oct 2011 06:04:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uTJFAKe4yAu5 for <>; Mon, 17 Oct 2011 06:04:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8D96C21F8B87 for <>; Mon, 17 Oct 2011 06:04:09 -0700 (PDT)
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id p9HD4fOG017857; Mon, 17 Oct 2011 09:04:41 -0400
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 09:04:06 -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_01CC8CCD.3E90E198"
Date: Mon, 17 Oct 2011 18:34:03 +0530
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol
Thread-Index: AcyMomLtAl0IYhbeSN65p41bPoj/EwAJ2bQA
References: <><><><><><><><><><> <> <> <>
From: Ravindran Parthasarathi <>
To: Tim Panton <>
X-OriginalArrivalTime: 17 Oct 2011 13:04:06.0543 (UTC) FILETIME=[408341F0:01CC8CCD]
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: Mon, 17 Oct 2011 13:04:12 -0000



Please read inline.





From: Tim Panton [] 
Sent: Monday, October 17, 2011 1:27 PM
To: Ravindran Parthasarathi
Cc: Neil Stratford; samuel;
Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol



On 17 Oct 2011, at 08:45, Ravindran Parthasarathi wrote:

RTCWeb server signaling plays the key role which calls for standardization as browser & RTCWebserver is not required from the same vendor.


And that is where we differ. The web server can _serve_ it's javascript to the browser. 

<partha> Here, webserver acts as a configuration/provisional module to browser and dynamically load the Javascript based signaling protocol in the endpoint.  Please note that Javascript is a programming environment and not the signaling replacement. Apart from this webserver needs to develop its own signaling protocol to acts as RTCWeb server.  In case of Inaki SIP over websocket usecase, RTCWeb server acts as SIP proxy or SIP B2BUA.


The argument here is whether the complete protocol & application has to be developed in each webserver vs the signaling protocol API exists in browser, IETF defined standard signaling protocol in webserver, web programmer invokes server API & client API to make the RTCWeb application. I prefer the second approach because web developer has no need to understand the underlying intricacies.  You can easily the understand the complication involved in signaling protocol by the offer/answer discussion in RTCWeb alias. 




So the only standards needed are the pre-existing web standards of javascript and http.

<partha> HTTP is not replacement of SIP in RTCWeb. I agree to the extend that websocket change the signaling paradigm in RTCWeb because two communication established between client & server then routing issue is resolved automatically which is one of the core function of signaling protocol </partha>


The browser only has to be capable of running the javascript served to ensure compatibility.

<partha> Javascript is the programming environment </partha>

That's the way that everything on the web works these days, from shopping carts to realtime 

chat. The browser is given site-specific code to run that interacts with site-specific code on

the web server. The web server may choose to convert those requests into a standard protocol 

for further processing (e.g. SQL), or may deal with the request internally.


Note, I'm not ruling out the use of SIP, but as  Iñaki Baz Castillo has demonstrated, that too

can be accomplished purely with existing web technologies.


<partha> I'm not favor Inaki solution of SIP over websocket because it is overkill for signaling protocol. Websocket solves routing issues between browser-webserver- browser, so the lightweight protocol over websocket will be sufficient and there is no need of complicated SIP based Javascript stack. 


Also, I'm not believer of the downloading complete signaling protocol script because it will delay the setup time which is crucial in lot of real-time application. Of course, it may not be critical for free application but not for professional services.


AFAIK, signaling protocol codebase expands very quickly with the addition of new services and leads to more delay in the setup of the session.  </partha>


 No embedded signalling code 

is needed.