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

"Ravindran Parthasarathi" <> Tue, 18 October 2011 18:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 41B2C21F8BBB for <>; Tue, 18 Oct 2011 11:05:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.818
X-Spam-Status: No, score=-2.818 tagged_above=-999 required=5 tests=[AWL=-0.519, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wiJeR8Of5hu3 for <>; Tue, 18 Oct 2011 11:05:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0BA6621F8BB7 for <>; Tue, 18 Oct 2011 11:05:30 -0700 (PDT)
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id p9II62IW019632; Tue, 18 Oct 2011 14:06:02 -0400
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Oct 2011 14:05:27 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 18 Oct 2011 23:35:22 +0530
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol
Thread-Index: AQHMjWPJQsg22CmbRQ+ec/AyTlzr85WCFU0AgAAGWYCAAE3QgP//tE4QgABB3qA=
References: <><><><><><><><><><><><><><><><2E239D6FCD033C4BAF15F38 6A979B F 51159950@so><><><> <> <>
From: Ravindran Parthasarathi <>
To: "Roy, Radhika R USA CIV (US)" <>, "Asveren, Tolga" <>, "Avasarala, Ranjit" <>, Saúl Ibarra Corretgé <>
X-OriginalArrivalTime: 18 Oct 2011 18:05:27.0723 (UTC) FILETIME=[84261FB0:01CC8DC0]
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: Tue, 18 Oct 2011 18:05:32 -0000


In case I read Ranjit mail correctly, the "simpler" protocol than "SIP over websocket" is required which does not require to perform signaling routing functionality like via header, route header handling as two-way communication between browser to RTCWeb server is established using websocket. But, It does not mean that media negotiation ("offer/answer") is not required. I have mentioned this media negotiation requirement for signaling in Bullet 2 of Sec 5 in draft-partha-rtcweb-signaling-00 draft as 

    " The mechanism has to provide the way to pass description about the
      media transmission between two RTCweb clients"

Also, the attempt for "standard" signaling protocol is not an attempt to stop custom-build signaling protocol and Sec 4 of draft-partha-rtcweb-signaling-00 draft explains this as

"The defining signaling protocol is not a hindrance for any innovative
   RTCWeb signaling protocol development as it is complementary

but standard signaling protocol facilities for the quick development of the generic RTCWeb usecase without the need of developing of new signaling protocol per website. In case you still feel that my draft does not reflect this notion, Please let me know.


>-----Original Message-----
>From: Roy, Radhika R USA CIV (US) []
>Sent: Tuesday, October 18, 2011 7:19 PM
>To: Asveren, Tolga; Avasarala, Ranjit; Ravindran Parthasarathi; Saúl
>Ibarra Corretgé
>Subject: RE: [rtcweb] Review request for RTCWeb standard signaling
>Tolga is right.
>We have a very complex problem to solve. It is called negotiations
>between different types of codecs and between different features of each
>codec type.
>Let us see how simple a protocol can be based on these simple
>-----Original Message-----
>From: [] On Behalf
>Of Asveren, Tolga
>Sent: Tuesday, October 18, 2011 9:17 AM
>To: Avasarala, Ranjit; Ravindran Parthasarathi; Saúl Ibarra Corretgé
>Subject: Re: [rtcweb] Review request for RTCWeb standard signaling
>Yes, something "simple" would be nice but the definition of "simple
>enough but still allowing me to do what I want to achieve" is very much
>dependent on the needs of each specific use case/service. There is no
>universal definition of "simple" here. So, I guess this is yet another
>argument in favor of not standardizing the protocol between browser and
>webserver so that everybody can design/use whatever is "simple but good
>enough" from their perspective.