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

Tim Panton <tim@phonefromhere.com> Wed, 19 October 2011 11:06 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 EC6EA21F85B1 for <rtcweb@ietfa.amsl.com>; Wed, 19 Oct 2011 04:06:08 -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 lY8mcuYdjxXj for <rtcweb@ietfa.amsl.com>; Wed, 19 Oct 2011 04:06:08 -0700 (PDT)
Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 080DE21F85A8 for <rtcweb@ietf.org>; Wed, 19 Oct 2011 04:06:08 -0700 (PDT)
Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 2333137A902; Wed, 19 Oct 2011 12:18:56 +0100 (BST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Tim Panton <tim@phonefromhere.com>
In-Reply-To: <4E9E7887.4000806@jesup.org>
Date: Wed, 19 Oct 2011 12:06:04 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <898B2A25-BF04-4F48-91FD-CA868FB5A79F@phonefromhere.com>
References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.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> <7357A569-83A3-43B6-80A7-E2374D78CE28@phonefromhere.com> <4E9E7887.400 0806@jesup.org>
To: Randell Jesup <randell-ietf@jesup.org>
X-Mailer: Apple Mail (2.1084)
Cc: 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: Wed, 19 Oct 2011 11:06:09 -0000

On 19 Oct 2011, at 08:13, Randell Jesup wrote:

> On 10/18/2011 10:19 AM, Tim Panton wrote:
>> 
>> 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.
> 
> This example you give raises some security issues based on the current proposals.  We require that the user ok access to the camera and microphone; this is a call set up "on the fly" with apparently no individual certification from the user.
> 
> This use-case would require the JS application get pre-authorization of media access, before any actual access occurs, and have that access persist until <something>, across multiple individual connections.
> 
> So is this outside of the current security model, since it seems to bring in a number of new requirements?  To support this, we would need:
> 
> 1) pre-authorization of camera/mic access
> 2) authorization continues until a particular active state with the server ends (leaving the game)

Oh, I thought that there had been some discussion on preserving authorization for a site - so that I can mark a site as
'trusted' and not have to see the permission request again. Without that sort of feature, rtcWEB/webRTC will get annoying _really_ fast.
Once it is 'trusted' the game can create and tear down calls at will, with no need to fork anything.
(I have to authorize each call separately in the current model ?!?)

> 
> This could be handled most simply by considering this to be a single 'call' to the server, which has a default 'forked' instance answered by the server with media 'on-hold'.  This 'call' is also forked by the server as needed to other players who happen to be nearby/call/etc. Since these are forks of an existing call, no individual authorization is required (effectively it's the equivalent to a mesh conference where users join and leave over time).  The 'call' ends when the user terminates the call to the server.
> 
> With that sort of setup, I think we can probably handle it within the current security model.  The big thing we would need to make sure of is making sure forking is available, and that authorization could occur at the start with the server, even if the server doesn't want to actually receive media.  (In a push, it could receive and drop media.)
> 
> As this is all forking of an initial "call", you can handle it with normal forking negotiation.  The server would take the two active "calls" from the users, and generate a forked "answer" to each.  It does point out that each side thinks it made an offer and the other side answered.  It requires the server handle the answer generation correctly in order to give a proper answer that will match what the device it's masquerading as will be ok with.
> 
>> 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.
> 
> I do not see that as the reason for offer-answer semantics; and I don't know that we can meet that requirement thus far - and which requirement from the use-case document covers this?  What exactly does it require?

(sorry, loose terminology - let's call it a desire or wish rather than a requirement).

As I recall (from somewhere on this list) Cullen's draft-jennings-rtcweb-api foundered on the difficulty of specifying video codecs in a way that was
SDP compatible. I'm afraid I can't cite where - a quick search didn't turn it up. If we accepted that video media was always from browser to browser, or
browser to rtcWEB aware proxy that wouldn't be an issue (as far as I can see).

Tim.

> 
> 
> -- 
> Randell Jesup
> randell-ietf@jesup.org
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb