Re: [rtcweb] RTCWEB and emergency services

Bernard Aboba <bernard_aboba@hotmail.com> Wed, 28 September 2011 16:28 UTC

Return-Path: <bernard_aboba@hotmail.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 649731F0C80 for <rtcweb@ietfa.amsl.com>; Wed, 28 Sep 2011 09:28:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level:
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 2Hi2XRYNqXKk for <rtcweb@ietfa.amsl.com>; Wed, 28 Sep 2011 09:28:40 -0700 (PDT)
Received: from blu0-omc4-s2.blu0.hotmail.com (blu0-omc4-s2.blu0.hotmail.com [65.55.111.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED6B1F0C69 for <rtcweb@ietf.org>; Wed, 28 Sep 2011 09:28:40 -0700 (PDT)
Received: from BLU152-W65 ([65.55.111.135]) by blu0-omc4-s2.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Sep 2011 09:31:29 -0700
Message-ID: <BLU152-W65F649561F7DFF7C343E2593F10@phx.gbl>
Content-Type: multipart/alternative; boundary="_a6f532e0-1944-4e66-b976-a107e1c0389a_"
X-Originating-IP: [98.237.179.165]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: fluffy@cisco.com
Date: Wed, 28 Sep 2011 09:31:28 -0700
Importance: Normal
In-Reply-To: <2579F4E0-9595-4ABB-9596-1FD39C91FABF@cisco.com>
References: <BLU152-W318BAE2CE0C609B1BB45CD93F30@phx.gbl>, <2579F4E0-9595-4ABB-9596-1FD39C91FABF@cisco.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 28 Sep 2011 16:31:29.0152 (UTC) FILETIME=[13097800:01CC7DFC]
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] RTCWEB and emergency services
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, 28 Sep 2011 16:28:41 -0000

Cullen said:

> Sure and the goal here should be to make sure that if someone was providing a Skype like service using RTCWeb, that they have enough support in the browser to do a good job of E911 calls. 

[BA] The key question is what exactly needs to be natively implemented in the browser, versus in Javascript libraries and even plugins.  

For example, the results from W3C Location APIs (or other Javascript location APIs, for that matter) appear to vary greatly depending on the device, browser and location.   While in some circumstances the location accuracy provided by a Location API could be better than that provided from say, cellular Phase II,  depending on the browser used, the device and the location, the Location API may not provide location or will return an accuracy that is much worse.   In some cases, even the country could be wrong.   As a result, it is probably prudent to advise applications implementing emergency services support to consider alternatives, which might include:

1. Use of Javascript libraries developed specifically to support location determination for emergency purposes; 
2. APIs which provide browser applications with access to the underlying telephony platform (such as the Mozilla WebAPI)

> My take is that the PSAP will forever be behind the times technology wise and underfunded. 

[BA]  Looking at the fiscal situation in most countries, and the current funding models, that's probably a reasonable conclusion.  

> >  For example, a "webphone" intended for use with an IP PBX, whose firmware is controlled by the IP PBX vendor,  could include within its code load plugins to provide additional functionality, including signaling protocols and codecs.
> 
> I agree one could do that - but they could do anything and that is well context of this. I's just ignore all that stuff. And I think it is fine if there are things in phone BCP that you end up saying, sorry, can't do that with RTCWeb - would need something else. 

[BA]  There a number of potential requirements in PhoneBCP that could be considered onerous to implement natively.   An example is ED-77, which relates to video codecs.   A limited set of RTCWeb applications will require the ability to send video to a PSAP.   Should every RTCWeb-enabled browser be required to natively support requirements like this?  I would suggest that the answer is no.

Where applications are implemented on a dedicated device,  it might be quite reasonable for the required codec support to be provided in a plugin.  Also, there might be situations where having a mandatory-to-implement video codec of any kind would be sufficient to provide  interoperability.  For example, consider an application which connects a caller to an ASL interpreter so as to implement a browser-based Video Relay Service (VRS).  In that application, there is no need to satisfy ED-77, if the caller and the interpreter implement a common video codec.  

> Hmm, I think your draft will lead to some interesting discussion on this. Browser JS is a surprisingly limited environment. It may be that your draft raises some addition requirements that the OS needs to reveal to the browser and the browser needs to expose to the JS. I'm thinking of things like information that came in DHCP options, and doing things like finding the browser location *before* bringing up a VPN. 

[BA] Yes, this is one of the key aspects that we need to talk about.  Richard Barnes has done some work that may be relevant here.