Re: [rtcweb] Comment on draft-ietf-rtcweb-overview-02 (Browser RTC trapezoid)

"Ravindran Parthasarathi" <> Wed, 19 October 2011 21:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8A7BE21F8ABE for <>; Wed, 19 Oct 2011 14:39:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.385
X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=-0.686, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ofHL+dYfhCvh for <>; Wed, 19 Oct 2011 14:39:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9276321F8AB9 for <>; Wed, 19 Oct 2011 14:39:25 -0700 (PDT)
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id p9JLdsZx028212; Wed, 19 Oct 2011 17:39:54 -0400
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Oct 2011 17:39:20 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Thu, 20 Oct 2011 03:09:13 +0530
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [rtcweb] Comment on draft-ietf-rtcweb-overview-02 (Browser RTC trapezoid)
Thread-Index: AcyOl5uqZPyfwxzMRhaOHW1Qi08ZGAAC1XhA
References: <><><> <>
From: "Ravindran Parthasarathi" <>
To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= <>
X-OriginalArrivalTime: 19 Oct 2011 21:39:20.0493 (UTC) FILETIME=[8F7D2DD0:01CC8EA7]
Subject: Re: [rtcweb] Comment on draft-ietf-rtcweb-overview-02 (Browser RTC trapezoid)
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: Wed, 19 Oct 2011 21:39:26 -0000


There are fundamentally two aspects in RTCWeb:

1) (on-wire) protocol mechanism - How protocol is designed between RTCWeb client (browser) and RTCWeb server, RTCWeb client and RTCWeb client. The protocol design does not focus on RTCWeb client only but also in RTCWeb server because the protocol has to be implemented in both entities. IOW, it is not 20 lines of JavaScript but impact of RTCWeb server design has to be noted as well. Here IETF has significant role and it has to come up with best protocol design between RTCWeb entities.

2) API design (JavaScript in browser) - Browser provides RTCWeb client framework and exposes its API as JavaScript and JavaScript is the language/script of choice for browsers. The interaction is between browser and JavaScript only. IMO, W3C plays the vital role in coming up with best API set and also, there is no on-wire stuff here. Here, the discussion focus is whether low level API or ROAP API or any other high level API. Of course, I have less experience in JavaScript based API design. Please note that I have designed and worked in protocol framework in other languages like C, TCL. 

My comment on "SIP over websocket is an overkill" is purely based on (on-wire) protocol mechanism and it is nothing do with API design. Irrespective of whether "SIP over websocket" is implemented in browser or in JavaScript or in other language, it is not the best protocol design. Hope this clarifies my stance.


>-----Original Message-----
>From: Iñaki Baz Castillo []
>Sent: Thursday, October 20, 2011 1:15 AM
>To: Ravindran Parthasarathi
>Cc: Harald Alvestrand;
>Subject: Re: [rtcweb] Comment on draft-ietf-rtcweb-overview-02 (Browser
>RTC trapezoid)
>2011/10/19 Ravindran Parthasarathi <>om>:
>> If you don't have a clear view of the Javascript execution model, I
>> recommend spending a few hours with an introductory Javascript text
>> playing with writing some Javascript in your own web pages. It will
>> lots of confused emails to the list.
>> <partha> In fact I tried couple of W3Cschools Javascript before
>starting the
>> mail thread in RTCWeb. I’ll learn more terminology in Javascript to
>> present my ideas </partha>
>Hi Ravindran, please let me understand:
>You recognize that you have no knowledge of JavaScript (you started
>reading some tutorials of JavaScript *yesterday*) but your draft
>clearly states:
>  [...]
>  There are lots of issues in Javascript based signaling protocol.
>  [...]
>And in other mail(s) you assert:
><partha> I’m not favor Inaki solution of SIP over websocket because it
>is overkill for signaling protocol. [...]</partha>
>So how should I interpret it? how can you make such assertions without
>knowledge?. I don't consider that to be very polite, and for me that
>means that you want to discredit proposals different than yours.
>Iñaki Baz Castillo