Re: [rtcweb] RTCWEB and emergency services

Hi Bernard,

Some comments in-line.

On Sun, Sep 25, 2011 at 5:13 PM, Bernard Aboba <bernard_aboba@hotmail.com>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.
>
> 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).
>
> 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").
>
>
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."?

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

regards,

Ted

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