Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10 - emergency service access

Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> Sun, 03 February 2013 23:15 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
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 480CC21F8871 for <rtcweb@ietfa.amsl.com>; Sun, 3 Feb 2013 15:15:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6]
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 TzMBupAJBNhE for <rtcweb@ietfa.amsl.com>; Sun, 3 Feb 2013 15:15:08 -0800 (PST)
Received: from vsp-authed-01-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 31C4221F886A for <rtcweb@ietf.org>; Sun, 3 Feb 2013 15:15:06 -0800 (PST)
Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-01-02.binero.net (Halon Mail Gateway) with ESMTP for <rtcweb@ietf.org>; Mon, 4 Feb 2013 00:14:28 +0100 (CET)
Received: from [10.220.17.165] (unknown [93.158.48.126]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-04-01.atm.binero.net (Postfix) with ESMTPA id 8DFA03A0F6 for <rtcweb@ietf.org>; Mon, 4 Feb 2013 00:14:28 +0100 (CET)
Message-ID: <510EEF55.7000902@omnitor.se>
Date: Mon, 04 Feb 2013 00:14:29 +0100
From: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <BLU002-W149D09F7296C2465CA4968093030@phx.gbl> <CA+9kkMCkJN5TrUA=UWu1g2D5p_RHcBVu3C1zK323hrrd84n+Rw@mail.gmail.com> <CABkgnnVVsn74Cff8JtFTUQ1B9NgaU1YYkJ7LmxbyzH2qNVyF0g@mail.gmail.com> <BLU404-EAS1806A8F1496C3D027E304FB93020@phx.gbl>
In-Reply-To: <BLU404-EAS1806A8F1496C3D027E304FB93020@phx.gbl>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Sun, 03 Feb 2013 23:15:09 -0000

> Martin said:
>
> "I'm highly sympathetic to the view that emergency services should not be regarded as special.  The argument goes: "If emergency services are special, how do I know that the special parts work when I need them?  They aren't used all the time."
>
> [BA] Exactly.   If all of the emergency services functionality that we need isn't already covered by mainstream WebRTC use cases and requirements, the answer isn't to change the use cases.   Even use cases that we expect to be frequently utilized will have bugs.   So why would anyone want to risk their life on non-mainstream use cases that are much less likely to be extensively used and tested?
(changed subject line to emergency service access )

Right, the emergency calls need to be as mainstream as possible.
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
-use SIP
-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.

Thus, for emergency services, I assume that we would need to specify 
protocol elements and API:s for approximately the following:

-Mark call as emergency call ( From application to browser )
-Provide location with the call
-Provide urn: address ( possibly, can also be handled by server )
-Provide call-back address
-Provide user modality and language preferences and capabilities.

This is not much and not much to vary between countries. If variations 
between countries are needed, they should be concentrated in the server.

/Gunnar