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