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

Randell Jesup <randell-ietf@jesup.org> Wed, 19 October 2011 07:17 UTC

Return-Path: <randell-ietf@jesup.org>
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 2204E11E8095 for <rtcweb@ietfa.amsl.com>; Wed, 19 Oct 2011 00:17:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level:
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 bN6tdK4sdx0K for <rtcweb@ietfa.amsl.com>; Wed, 19 Oct 2011 00:17:56 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 69F0811E8096 for <rtcweb@ietf.org>; Wed, 19 Oct 2011 00:17:56 -0700 (PDT)
Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1RGQPP-0001wg-8f for rtcweb@ietf.org; Wed, 19 Oct 2011 02:17:51 -0500
Message-ID: <4E9E7887.4000806@jesup.org>
Date: Wed, 19 Oct 2011 03:13:11 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
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>
In-Reply-To: <7357A569-83A3-43B6-80A7-E2374D78CE28@phonefromhere.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
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 07:17:57 -0000

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)

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?


-- 
Randell Jesup
randell-ietf@jesup.org