Re: [rtcweb] RTCWEB and emergency services

Bernard, great to hear you are doing this. Look forward to reading it.

On Sep 25, 2011, at 6:13 PM, Bernard Aboba wrote:

> I'm putting together a draft on the subject of RTCWEB and emergency services.  However, before submitting this, it seemed useful to get some feedback from the group on the general direction of the document. 
> 
> 1. The overall requirements for emergency services support will vary by jurisdiction and are likely to change.   Therefore the document, while citing ongoing regulatory proceedings within the US and EU, does not attempt to provide legal advice or offer a definitive statement of the regulatory requirements.  Instead, the document cites  documents from the ECRIT WG, such as the ECRIT Framework and Phone-BCP documents which provide guidance on best current or future practices.   

Some people in the WG are probably concerned about meeting various regulations but the way I will probably look at this is would that suggestions in the draft be likely to help save lives if they were widely available. For example, I'm meant people in PSAPs that personally have been involved in situations where they feel that turning off VAD on emergency calls help save a life - in this case the life of an emergency responder. Some other things might seem to me like just artifacts of the past that might be regulatory required in some places but are not the optimal way to solve the problem at this time. I'm also high interested in things that are likely to deploy for reasons other than 911 - no one makes money on 911 so hard to justify features that only work for that and they are poorly tested and operated unless they are a a key code path that gets used ever day. So, for the most part, I hope the things in your draft that we want for E911 are things that we want for all kinds of other reasons too. 

> 
> 2.  The overall requirements for emergency services support also vary by the type of service that is being implemented.   For example,  adding support for real-time conferencing to a social networking service or a game (e.g. non-interconnected VoIP) will result in different requirements than say, implementing a phone dialing service that can both make outgoing calls and take incoming calls from E.164 numbers (e.g. interconnected VoIP).   

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. 

> 
> It should therefore be understood that the burden for implementation of emergency services falls principally upon the operator of the service, and that the role of the RTCWEB implementer is to deliver basic capabilities and to enable an operator to add to this functionality, rather than providing for every possible need natively ("I want a pony").   

So in the case of me using a Skype like service that then calls a PSAP. Operator could refer to the Telephony Service Provider (TSP), which was Skype in my example here or the PSAP where the emergency operators are (as Ted points out).  My take is that the PSAP will forever be behind the times technology wise and underfunded. There are a bunch of reason for this best discussed over beer but the combination of budgeting, and a safety and approval process for things like PSAP software and air traffic control systems ensures that there is a very long deployment cycle and thus they lag leading edge technology - sometimes by 20 years or more. So consider a case like http://www.theglobeandmail.com/news/national/article682611.ece - The headline could have been "Baby dies after Comwave sends ambulance to wrong city".  As a a TSP, you don't want to see headlines like that - it's bad for business and seriously, no one at the TSP ever wanted anyone to get hurt. So the end result is the TSP are going to be the ones that end up dealing with making sure that they do whatever they need to get the right info to the PSAP. It won't be the PSAP leading here. It might be technologically easier if they did, but given how the financial incentives work, I believe we have to define a solutions where the TSP can deal with the hard parts of this. 

> 
> 3.  The emergency services capabilities of the browser are comprised of the functionality that is implemented in the browser, as well functionality that can be added via Javascript libraries.   In some circumstances, it may be viable to supplement functionality with plugins.

I would not even bother considering what can or can not be done with plugins - anything can be done with a plugin and more and more they are impossible to deploy.  For the things that you can't do in a browser without a plugin, I jus say int he context of RTCWeb, you can't do theses - sorry - out of scope. 

>  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. 

>  As a result, it is not required for an RTCWEB implementation to natively satisfy every requirement of ECRIT Phone-BCP.    Examples of requirements which may not be satisfiable without plugins include some of the endpoint media requirements of PhoneBCP Section 14, such as ED-77 (video codec support).   However, it would appear that some of the requirements of that section such as ED-71 (RTP Support) and ED-73 (G.711 support) are appropriate.  
> 
> 4. With respect to location capabilities, the W3C Location APIs and associated Location-Based Services are not adequate in terms of their support for emergency services location.
+1 - 
>  This gap exists in part because the requirements and scenarios for  Location-Based Services (LBS) are different from those of Location Information Services (LISes) used for emergency purposes.  

> While in the long-term it may be possible to close the gaps,  in the short term the gaps may be addressed via Javascript libraries implementing elements of the ECRIT architecture such as HELD, or even LoST.   

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. 
> 
> 
> 
> In addition, in some scenarios, it is quite feasible for this 
> 
> 2.  Similarly, the requirements for native browser functionality will vary according to the scenario.  
> 
> 2. In some scenarios, 
> 
> 
>  In meeting the requirements for emergency services support, the important question to answer is what functionality MUST be present natively within the browser

+1. 

And last but not least, thank you for tackling this thorny topic. 

> 
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb