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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 961D821F8677 for <>; Mon, 17 Oct 2011 06:56:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Nt8Xhg6CogbN for <>; Mon, 17 Oct 2011 06:56:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 07F6E21F8672 for <>; Mon, 17 Oct 2011 06:56:58 -0700 (PDT)
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id p9HDvV40020643; Mon, 17 Oct 2011 09:57:31 -0400
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 09:56:57 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 17 Oct 2011 19:26:55 +0530
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol
Thread-Index: AcyE58qiQsg22CmbRQ+ec/AyTlzr8wHt+TLwAAzwHoAAADNJ4A==
References: <><><><><><><><><><><> <> <>
From: Ravindran Parthasarathi <>
To: "Roy, Radhika R USA CIV (US)" <>, Neil Stratford <>
X-OriginalArrivalTime: 17 Oct 2011 13:56:57.0476 (UTC) FILETIME=[A2893C40:01CC8CD4]
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:56:59 -0000

Hi Radhika,

I agree with you for "proxy" requirement and it is classified as
"federation" in RTCWeb which is outside the scope of current discussion.

IOW, single RTCWeb server knows where to route the session between any
two known RTCWeb client but RTCweb client will not aware how to route to
other RTCWeb client.


>-----Original Message-----
>From: Roy, Radhika R USA CIV (US) []
>Sent: Monday, October 17, 2011 7:21 PM
>To: Ravindran Parthasarathi; Neil Stratford
>Subject: RE: [rtcweb] Review request for RTCWeb standard signaling
>If servers are intelligent enough to "route" the calls among
>there are no need for any proxies.
>So, proxies are needed for "routing" in the application layer.
>-----Original Message-----
>From: [] On
>Of Ravindran Parthasarathi
>Sent: Monday, October 17, 2011 3:45 AM
>To: Neil Stratford
>Subject: Re: [rtcweb] Review request for RTCWeb standard signaling
><snip> My argument is that if we want the ultimate goal of simplicity
>for end user web developers then we should minimise everything they
>to touch - and that includes removing any requirement for server side
>infrastructure beyond the basic bare minimum, which would mean no SIP
>proxies, no websocket servers etc etc.
>But as I said, we don't need to standardise a protocol at all, so we
>shouldn't. If we are lucky we'll see a whole spectrum of solutions.
> </snip>
>Without server interaction, it is not possible for browser to establish
>the session with other browser. Unlike other endpoint, browser needs
>server to provide routing or  perform the authentication or atleast
>configuration information. AFAIK, RTCWeb client to RTCWeb client is not
>the motive of the work. If so, SIP is the IETF protocol between RTCWeb
>client to RTCWeb client which MUST be recommended because of the UA to
>UA communication nature. IOW, RTCWeb server signaling plays the key
>which calls for standardization as browser & RTCWebserver is not
>required from the same vendor.