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
- [rtcweb] Review request for RTCWeb standard signa… Ravindran Parthasarathi
- Re: [rtcweb] Review request for RTCWeb standard s… Iñaki Baz Castillo
- Re: [rtcweb] Review request for RTCWeb standard s… Ravindran Parthasarathi
- Re: [rtcweb] Review request for RTCWeb standard s… Iñaki Baz Castillo
- Re: [rtcweb] Review request for RTCWeb standard s… Saúl Ibarra Corretgé
- Re: [rtcweb] Review request for RTCWeb standard s… Harald Alvestrand
- Re: [rtcweb] Review request for RTCWeb standard s… Bernard Aboba
- Re: [rtcweb] Review request for RTCWeb standard s… Ravindran Parthasarathi
- Re: [rtcweb] Review request for RTCWeb standard s… Iñaki Baz Castillo
- Re: [rtcweb] Review request for RTCWeb standard s… Ravindran Parthasarathi
- Re: [rtcweb] Review request for RTCWeb standard s… Tim Panton
- Re: [rtcweb] Review request for RTCWeb standard s… samuel
- Re: [rtcweb] Review request for RTCWeb standard s… Ravindran Parthasarathi
- Re: [rtcweb] Review request for RTCWeb standard s… Iñaki Baz Castillo
- Re: [rtcweb] Review request for RTCWeb standard s… Ravindran Parthasarathi
- Re: [rtcweb] Review request for RTCWeb standard s… Markus.Isomaki
- Re: [rtcweb] Review request for RTCWeb standard s… Neil Stratford
- Re: [rtcweb] Review request for RTCWeb standard s… Ravindran Parthasarathi
- Re: [rtcweb] Review request for RTCWeb standard s… Neil Stratford
- Re: [rtcweb] Review request for RTCWeb standard s… Iñaki Baz Castillo
- Re: [rtcweb] Review request for RTCWeb standard s… Tim Panton
- Re: [rtcweb] Review request for RTCWeb standard s… Hadriel Kaplan
- Re: [rtcweb] Review request for RTCWeb standard s… Saul Ibarra Corretge
- Re: [rtcweb] Review request for RTCWeb standard s… Neil Stratford
- Re: [rtcweb] Review request for RTCWeb standard s… Saul Ibarra Corretge
- Re: [rtcweb] Review request for RTCWeb standard s… Iñaki Baz Castillo
- Re: [rtcweb] Review request for RTCWeb standard s… Ravindran Parthasarathi
- Re: [rtcweb] Review request for RTCWeb standard s… Ravindran Parthasarathi
- Re: [rtcweb] Review request for RTCWeb standard s… Tim Panton
- Re: [rtcweb] Review request for RTCWeb standard s… Ravindran Parthasarathi
- Re: [rtcweb] Review request for RTCWeb standard s… Roy, Radhika R USA CIV (US)
- Re: [rtcweb] Review request for RTCWeb standard s… Ravindran Parthasarathi
- Re: [rtcweb] Review request for RTCWeb standard s… Iñaki Baz Castillo
- Re: [rtcweb] Review request for RTCWeb standard s… Ravindran Parthasarathi
- Re: [rtcweb] Review request for RTCWeb standard s… Avasarala, Ranjit
- Re: [rtcweb] Review request for RTCWeb standard s… Iñaki Baz Castillo
- Re: [rtcweb] Review request for RTCWeb standard s… Iñaki Baz Castillo
- Re: [rtcweb] Review request for RTCWeb standard s… Iñaki Baz Castillo
- Re: [rtcweb] Review request for RTCWeb standard s… Ravindran Parthasarathi
- Re: [rtcweb] Review request for RTCWeb standard s… Saúl Ibarra Corretgé
- Re: [rtcweb] Review request for RTCWeb standard s… Ravindran Parthasarathi
- Re: [rtcweb] Review request for RTCWeb standard s… Avasarala, Ranjit
- Re: [rtcweb] Review request for RTCWeb standard s… Iñaki Baz Castillo
- Re: [rtcweb] Review request for RTCWeb standard s… Saúl Ibarra Corretgé
- Re: [rtcweb] Review request for RTCWeb standard s… Ravindran Parthasarathi
- Re: [rtcweb] Review request for RTCWeb standard s… Roy, Radhika R USA CIV (US)
- Re: [rtcweb] Review request for RTCWeb standard s… Asveren, Tolga
- Re: [rtcweb] Review request for RTCWeb standard s… Tim Panton
- Re: [rtcweb] Review request for RTCWeb standard s… Roy, Radhika R USA CIV (US)
- Re: [rtcweb] Review request for RTCWeb standard s… Roy, Radhika R USA CIV (US)
- Re: [rtcweb] Review request for RTCWeb standard s… Tim Panton
- Re: [rtcweb] Review request for RTCWeb standard s… Ted Hardie
- Re: [rtcweb] Review request for RTCWeb standard s… Tim Panton
- Re: [rtcweb] Review request for RTCWeb standard s… Ravindran Parthasarathi
- Re: [rtcweb] Review request for RTCWeb standard s… Asveren, Tolga
- Re: [rtcweb] Review request for RTCWeb standard s… Iñaki Baz Castillo
- Re: [rtcweb] Review request for RTCWeb standard s… Asveren, Tolga
- Re: [rtcweb] Review request for RTCWeb standard s… Iñaki Baz Castillo
- Re: [rtcweb] Review request for RTCWeb standard s… Jim McEachern
- Re: [rtcweb] Review request for RTCWeb standard s… Asveren, Tolga
- Re: [rtcweb] Review request for RTCWeb standard s… Ted Hardie
- Re: [rtcweb] Review request for RTCWeb standard s… Asveren, Tolga
- Re: [rtcweb] Review request for RTCWeb standard s… Hadriel Kaplan
- Re: [rtcweb] Review request for RTCWeb standard s… Ted Hardie
- Re: [rtcweb] Review request for RTCWeb standard s… Ravindran Parthasarathi
- [rtcweb] Gateway need and usecase [was RE: Review… Ravindran Parthasarathi
- Re: [rtcweb] Gateway need and usecase [was RE: Re… Hadriel Kaplan
- Re: [rtcweb] Review request for RTCWeb standard s… Randell Jesup
- Re: [rtcweb] Review request for RTCWeb standard s… Randell Jesup
- Re: [rtcweb] Review request for RTCWeb standard s… Neil Stratford
- Re: [rtcweb] Review request for RTCWeb standard s… Tim Panton
- Re: [rtcweb] Review request for RTCWeb standard s… Tim Panton
- Re: [rtcweb] Review request for RTCWeb standard s… Neil Stratford
- [rtcweb] UI for getUserMedia() Randell Jesup
- Re: [rtcweb] Gateway need and usecase [was RE: Re… Ravindran Parthasarathi
- Re: [rtcweb] Gateway need and usecase [was RE: Re… José Luis Millán