Re: [rtcweb] RTCWEB and emergency services

[Bernard Aboba <[e-mail]>]

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



Ted Hardie said:

"Do I understand you correctly to be saying "The emergency service must stand up an RTCWEB server which provides downloadable javascript applications, rather than presuming that other javascript applications provide this functionality."? "

[BA] I'm saying that the provider of the RTCWEB service is ultimately responsible for satisfying the regulatory requirements, which may vary by the location and functionality of the service.    If they utilize Javascript libraries, they need to make sure that those libraries can provide the required functionality.  For example, there are various location libraries that support the W3C Location APIs as well as potentially other Location APIs.  However, in general those libraries and underlying services were built to provide "Location Based Services" and not a "Location Information Service" in the sense that the term is used in IETF, NENA and other emergency services specifications.   However, there may be other libraries that *are* built to support emergency services (e.g. a library that supports HELD).    Also, there may be APIs available (such as the WebAPI proposed by Mozilla, see http://hacks.mozilla.org/2011/08/introducing-webapi/) that can enable an HTML5 application to access the underlying telephony capabilities of the device on which the browser runs (e.g. a mobile handset that is capable of making emergency calls with location).   The service provider needs to understand their responsibilities and utilize the right APIs and libraries to satisfy them.  

---------------------------------------

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.    



Ted Hardie also said:

"It doesn't make sense to use LoST alone in the case you've described, at least if I understood you.  LoST takes a desired service and a location as inputs and discovers the service provider associated with that location.  If we're presuming that someone starts at a particular server, LoST must run prior to reaching that server.  So you'd need some sort of libraries provided prior to that server being reached to run LoST.  If you start from a known server that provides javascript libraries for discovering location (by pulling from DHCP or HELD, for example) and running LoST, you could then get to the Emergency Service Provider's RTCWEB server, but it would be pretty fragile."

[BA] Richard Barnes has been developing an ECRIT client that runs in the browser, so I suspect he will have some observations on how LoST functionality could be provided.  My main point was that just because something is a requirement in ECRIT PhoneBCP doesn't necessarily imply that it needs to be provided natively in the browser.  Before making that determination we need to understand if the functionality could be viably provided another way -- such as in Javascript, via a plugin, or maybe even via server-side functionality.