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

Harald Alvestrand <harald@alvestrand.no> Mon, 04 February 2013 03:31 UTC

Return-Path: <harald@alvestrand.no>
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 3447521F89D5 for <rtcweb@ietfa.amsl.com>; Sun, 3 Feb 2013 19:31:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.664
X-Spam-Level:
X-Spam-Status: No, score=-108.664 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 llFK0f6XmTUZ for <rtcweb@ietfa.amsl.com>; Sun, 3 Feb 2013 19:31:34 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3300021F89B2 for <rtcweb@ietf.org>; Sun, 3 Feb 2013 19:31:34 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0C08339E0A7; Mon, 4 Feb 2013 04:31:33 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsMed4bbWLqx; Mon, 4 Feb 2013 04:31:30 +0100 (CET)
Received: from [10.246.3.243] (244-3-11.connect.netcom.no [176.11.3.244]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 8813F39E04C; Mon, 4 Feb 2013 04:31:30 +0100 (CET)
User-Agent: K-9 Mail for Android
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>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----C4RI1EBQWQI7PHM6KQVS9L7Z4RHQR7"
From: Harald Alvestrand <harald@alvestrand.no>
Date: Mon, 04 Feb 2013 04:31:26 +0100
To: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>, rtcweb@ietf.org
Message-ID: <8bef5302-3bc7-43c6-ba81-d75627c97938@email.android.com>
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: Mon, 04 Feb 2013 03:31:35 -0000

All of the mentioned features except loopback belong in signalling, not in rtcweb.

Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> wrote:

>
>> 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
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.