Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 - emergency service access
Ted Hardie <ted.ietf@gmail.com> Tue, 05 February 2013 14:41 UTC
Return-Path: <ted.ietf@gmail.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 72CE621F8962 for <rtcweb@ietfa.amsl.com>; Tue, 5 Feb 2013 06:41:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnJ+l9AVb3lG for <rtcweb@ietfa.amsl.com>; Tue, 5 Feb 2013 06:41:18 -0800 (PST)
Received: from mail-ie0-x234.google.com (ie-in-x0234.1e100.net [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id D7C6721F894E for <rtcweb@ietf.org>; Tue, 5 Feb 2013 06:41:17 -0800 (PST)
Received: by mail-ie0-f180.google.com with SMTP id bn7so253335ieb.39 for <rtcweb@ietf.org>; Tue, 05 Feb 2013 06:41:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=NatpJHHN8dLKk3cJwF58dZQGZw58xMdFG/d0aQ3vhDQ=; b=dTKIJnl9fLf9Cf25CUOB9JO5UOaUXJ7htRYrcthzWycWIOtKS2qvtvvnBugJwPkGVZ gqU1o3OnzhGTtPLJjyq9cQVzsg5zxccNlYUBTs7q9G7BtdLjygmQoEXBDEFeolh562yI gBWzHiFBfV5+MveI5ZCZNAA5O5du+reZkLifSzj3q4Rusy4sC4jkgvPIwL888Ecbl1vA nK+iC4x12dD3s/ddzdJBWavLvxjLKekD2UpYFRfj9SL9gQNCIyMsImNofhaemDYdc6l5 3lyUYWWcW8ucSOmEemTVevkzD5+DjdNhUCQOmGdymB17hFNX0SCnkly+V2AGscAMAo2v wj6w==
MIME-Version: 1.0
X-Received: by 10.50.88.136 with SMTP id bg8mr13654292igb.96.1360075277324; Tue, 05 Feb 2013 06:41:17 -0800 (PST)
Received: by 10.43.135.202 with HTTP; Tue, 5 Feb 2013 06:41:17 -0800 (PST)
In-Reply-To: <510EEF55.7000902@omnitor.se>
References: <BLU002-W149D09F7296C2465CA4968093030@phx.gbl> <CA+9kkMCkJN5TrUA=UWu1g2D5p_RHcBVu3C1zK323hrrd84n+Rw@mail.gmail.com> <CABkgnnVVsn74Cff8JtFTUQ1B9NgaU1YYkJ7LmxbyzH2qNVyF0g@mail.gmail.com> <BLU404-EAS1806A8F1496C3D027E304FB93020@phx.gbl> <510EEF55.7000902@omnitor.se>
Date: Tue, 05 Feb 2013 09:41:17 -0500
Message-ID: <CA+9kkMB_2v9RbsubPO9yE+sryHum891Gi8YqokaTKQDDSgA_2A@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 - emergency service access
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, 05 Feb 2013 14:41:18 -0000
On Sun, Feb 3, 2013 at 6:14 PM, Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> wrote: > Right, the emergency calls need to be as mainstream as possible. For devices that make phone calls, this is a sensible statement. But we're not building phone-in-a-browser. It's entirely possible to use RTCWEB to set up a data channel between two consenting peers where there is no audio, no video, and no real time text but, say, games play exchanges. And in cases where there are audio and video streams, there is no requirement that this be a general facility. Look, for example, at the puzzlible application here: http://cargocollective.com/mimmijostell/PROTOTHON-PROJECTS. Expecting that this is useful to contact emergency services doesn't make sense to me personally. > But there are RFCs about how emergency calls are expected to appear, and > they require a couple of "special" actions from the client and service > provider. > Since next generation emergency services are now planned based on these RFCs > it is best to make sure rtcweb based systems can comply. > > It is mainly: > -provide location If you would like several months entertainment, please go back to the ECRIT and GEOPRIV mailing lists and read up on how little emergency services like trusting user generated location. Then you might consider working through how exactly we're going to get what they would consider trustable location through browser chrome and into javascript *that we know many come from an untrustable server* in a way that doesn't provide a very nice attack surface indeed. > -use SIP In this case, that would have to be "know where there is a trustable SIP gateway", right, since there is no requirement to use SIP in WebRTC? > -use supported codecs for audio, video and real-time text > -either client or server use urn:service:sos.... addressing > > In order to test if it really works, a method for testing is specified in > RFC 6443, requesting automatic loopback of a couple of RTP packets, and an > opportunity to verify that the right emergency service was reached. > (I am a bit afraid that the load of these test calls will be overwhelming > for the network resources compared to real calls, and might need a > rethinking, but they at least do not load any operational human call taker. > So, the mechanisms you ask for are there.) > > It is true with all features in rtcweb that they are not required to be used > in all application implementations. But they need to be described and > included in the support from the browsers and APIs. > If you would like to describe how to build an emergency service WebRTC app, I see know problem in your doing so. But requiring all applications have this facility simply misses the point of the technology. To repeat myself, we are not building a technology for creating phones in browsers. Still speaking personally, regards, Ted Hardie
- Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-… Bernard Aboba
- Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-… Ted Hardie
- Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-… Martin Thomson
- Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-… Bernard Aboba
- Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-… Gunnar Hellstrom
- Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-… Harald Alvestrand
- Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-… Ted Hardie
- Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-… Ted Hardie