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

Tim Panton <tim@phonefromhere.com> Tue, 18 October 2011 15:02 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 5AD8721F8B7E for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 08:02:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 EkT-IyXPCcor for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 08:02:10 -0700 (PDT)
Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 2B89021F8B5C for <rtcweb@ietf.org>; Tue, 18 Oct 2011 08:02:09 -0700 (PDT)
Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 7CEFB37A902; Tue, 18 Oct 2011 16:14:54 +0100 (BST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary="Apple-Mail-6--806976963"
From: Tim Panton <tim@phonefromhere.com>
In-Reply-To: <CA+9kkMAeb-SKeTMhaGZKXWh4NZDi6U3c=7=JPvR73szfJuNzWg@mail.gmail.com>
Date: Tue, 18 Oct 2011 16:02:02 +0100
Message-Id: <73409596-7D52-495B-92F5-4C917364EEDC@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> <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> <7357A569-83A3-43B6-80A7-E2374D78CE28@phonefromhere.com> <CA+9kkMAeb-SKeTMhaGZKXWh4NZDi6U3c=7=JPvR73szfJuNzWg@mail.gmail.com>
To: Ted Hardie <ted.ietf@gmail.com>
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 15:02:11 -0000

On 18 Oct 2011, at 15:46, Ted Hardie wrote:

> On Tue, Oct 18, 2011 at 7:19 AM, Tim Panton <tim@phonefromhere.com> wrote:
> 
> 
> 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.
> 
> 
> The working group decided very early on to require a mandatory-to-implement codec to ensure that there were no negotiation failures.  If the web server always selects the mandatory to implement codec, then this should work.  It may be sub-optimal (a better codec might have been available for this session), but it would cause a complete connection.

That would be the trivial case of the intersection algorithm.

> 
> The issue comes when you use a pair of codec sets from time T and run the intersection algorithm at some later time.  The risk is that the overall resource set available at one or more of the nodes may have changed, and this can have an impact on its ability or preferences.  The classic example is battery life on mobiles.  If I send you a capability set when I have a fully charged battery, it may include computationally expensive algorithms that take a lot of energy; those might be lower preference or elided from the set after hours of game play in which I drew the battery down.  

On the other hand, As a user I might find the next 20 seconds of play critical and opt to go 'hi-def' despite the low battery warning. Some of the current proposals would make that very hard to do.

> 
> I also note that this is not really protocol free, it's just that the format by which the API results are returned to the webserver running the intersection algorithm are not standard; there's still a (private) protocol in use.

Agreed, the data has to move somehow. I'm not sure I dignify sending some JSON object over HTTP as a 'protocol', I see it as a pre-existing transport.
There is indeed a private (in the sense that it isn't standardized) intersection algorithm running, but my point was that it wouldn't _have_ to
run in the browser, it might well run in the server. The current round of proposals seem to me to preclude that almost completely , which very much
goes against the grain in the context of a web service.

Tim.
> 
> regards,
> 
> Ted 
> 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.
> >
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>