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

Tim Panton <tim@phonefromhere.com> Tue, 18 October 2011 14:19 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 78AB721F8B95 for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 07:19:59 -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 gntKDSW48+bZ for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 07:19:58 -0700 (PDT)
Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 83ABA21F8B5B for <rtcweb@ietf.org>; Tue, 18 Oct 2011 07:19:58 -0700 (PDT)
Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id B6A5F37A902; Tue, 18 Oct 2011 15:32:41 +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: <8486C8728176924BAF5BDB2F7D7EEDDF3E091D31@ucolhp4d.easf.csd.disa.mil>
Date: Tue, 18 Oct 2011 15:19:50 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <7357A569-83A3-43B6-80A7-E2374D78CE28@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> <2E2B1F85-1DED-460D-B17D-0850DB3ACBA9@phonefromhere.com> <8486C8728176924BAF5BDB2F7D7EEDDF3E091D31@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 14:19:59 -0000

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

> 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.

The example I gave had _no_ negotiation, no back and forth, because the application's webserver was
told all the capabilities in advance, (at login in my example), it simply _decided_ based on
it's view of the union of the capabilities of the two ends. It then informed them of the choice
(which may have been asymmetric by the way) and told them to get on with it.

To the extent that there was a 'negotiation',  it took place in a single thread on the web server, 
with no propagation delays or locks needed.


> 
> 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.

Offer - Answer really only crops up because there is a requirement (which I personally put very low on our priorities) to be able
to interop with legacy video phones without  needing a media gateway. 

Tim.

> 
> 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.
>