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

Tim Panton <tim@phonefromhere.com> Tue, 18 October 2011 13:25 UTC

Return-Path: <tim@phonefromhere.com>
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 245B121F8B1C for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 06:25:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 tdgh-iRv6enc for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 06:25:37 -0700 (PDT)
Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 712E621F8B08 for <rtcweb@ietf.org>; Tue, 18 Oct 2011 06:25:37 -0700 (PDT)
Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id D356D37A902; Tue, 18 Oct 2011 14:38:22 +0100 (BST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="iso-8859-1"
From: Tim Panton <tim@phonefromhere.com>
In-Reply-To: <8486C8728176924BAF5BDB2F7D7EEDDF3E091CA3@ucolhp4d.easf.csd.disa.mil>
Date: Tue, 18 Oct 2011 14:25:31 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <2E2B1F85-1DED-460D-B17D-0850DB3ACBA9@phonefromhere.com>
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>
To: "Roy, Radhika R USA CIV (US)" <radhika.r.roy.civ@mail.mil>
X-Mailer: Apple Mail (2.1084)
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:25:38 -0000

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.