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

"Roy, Radhika R USA CIV (US)" <radhika.r.roy.civ@mail.mil> Tue, 18 October 2011 13:59 UTC

Return-Path: <radhika.r.roy.civ@mail.mil>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212B621F8B84 for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 06:59:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.454
X-Spam-Level:
X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7K5E0jUI-Cvl for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 06:59:48 -0700 (PDT)
Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.6]) by ietfa.amsl.com (Postfix) with ESMTP id 72A5421F8B78 for <rtcweb@ietf.org>; Tue, 18 Oct 2011 06:59:48 -0700 (PDT)
Received: from UCOLHP3F.easf.csd.disa.mil (131.64.100.145) by UCOLHP4Z.easf.csd.disa.mil (131.64.100.6) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 18 Oct 2011 08:59:41 -0500
Received: from UCOLHP4D.easf.csd.disa.mil ([169.254.9.97]) by UCOLHP3F.easf.csd.disa.mil ([169.254.56.193]) with mapi id 14.01.0323.003; Tue, 18 Oct 2011 08:59:41 -0500
From: "Roy, Radhika R USA CIV (US)" <radhika.r.roy.civ@mail.mil>
To: Tim Panton <tim@phonefromhere.com>
Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol
Thread-Index: AQHMjWPJQsg22CmbRQ+ec/AyTlzr85WCFU0AgAAXFYD//+Y8kIAAWT2A//+zcOA=
Date: Tue, 18 Oct 2011 13:59:41 +0000
Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF3E091D31@ucolhp4d.easf.csd.disa.mil>
References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><CALiegf=ejF2kUC1m=74o9eprF1M8wYtgE-Crwa1x14rzDOf+gQ@mail.gmail.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><CAOg=WDcC9t2KhQUg0gDJ60gO_2mNyMv9HKt=otCdPDfj4TnoTg@mail.gmail.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com><CABRok6mM7TfbLgGhoQvdRh1Kwoi5BhRweLcqWg7VZOFnaa8VOw@mail.gmail.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com><CABRok6n33QK0Si1Y0kT7+U0zgAWsJ4d5GENK_KL-JPx5a4erYg@mail.gmail.com><2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com><665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com> <CALiegfmrncjsLVSiWk0tEgzwB00YaBGiqj0SDf9JTm9p1ZNoVA@mail.gmail.com> <2E239D6FCD033C4BAF15F3 86A979B F51159950@so nusinmail02.sonusnet.com> <0950F0E1-6E4B-407F-9563-654AFE79F64B@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> <6398F67A-5E41-44BB-ABB2-831AB7C48DCC@ag-projects.com> <8486C8728176924BAF5BDB2F7D7EEDDF3E091CA3@ucolhp4d.easf.csd.disa.mil> <2E2B1F85-1DED-460D-B17D-0850DB3ACBA9@phonefromhere.com>
In-Reply-To: <2E2B1F85-1DED-460D-B17D-0850DB3ACBA9@phonefromhere.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [131.64.77.9]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Oct 2011 13:59:49 -0000

Tim:

The puzzle is this. The other user may not agree completely with the offer of the first user. Even the other user may agree with a given codec type, he/she may not agree other features including bandwidth of the codec.

It simple turns out that a freedom needs to be given for negotiations some-like offer/answer.

Well, if we can avoid these complexities, let us find out (e.g. Pre-defined some constraints etc.).

Or, if an API is good enough exposing all the codec parameters and offer/answer signaling can be avoided, let us find it out.

BR/Radhika

-----Original Message-----
From: Tim Panton [mailto:tim@phonefromhere.com] 
Sent: Tuesday, October 18, 2011 9:26 AM
To: Roy, Radhika R USA CIV (US)
Cc: Saúl Ibarra Corretgé; Ravindran Parthasarathi; rtcweb@ietf.org
Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol


On 18 Oct 2011, at 14:08, Roy, Radhika R USA CIV (US) wrote:

> Hi, Saúl
> 
> Is there a way to do negotiations with different codec types and different features of a given codec without using a signaling protocol between the two functional entities?
> 
> BR/Radhika

No, you always need  a transport to get the supported codec description list from one end to the other. 
What you don't have to specify is the protocol that the transport uses, or the decision making process that each end uses to select the capabilities it wants to employ in this instance of this web app.

Here is an example that illustrates how it could work in a 'protocol free' way.

User A could query the browser for the codec description list at the start of a web game session, the web app could upload that to the session storage on the game server. 
User B does the same thing.
At some point later users A and B encounter each other in the game. - the server _already_knows_ the capabilites of their respective browsers and instructs them to do an ice negotiation to find a transport between them.
Once that is done it informs them _both_ of it's codec selection - which may be based on their game status.

The video session proceeds as part of the game until the 2 users part, at which point the session is torn down.


I'm by no means saying that this is the _only_ way connections can be made, just that if we get this API right we can do things this way.
Tim.