Re: [rtcweb] RTCWEB and emergency services

[Harald Alvestrand <[e-mail]>]

Bernard,
one more architecture-level question:

is it appropriate to address requirements on the equipment surrounding 
the browser in addition to those on the browser and JS running within 
the browser?

For instance, if traffic prioritization is required for proper 
operation, the CPE and intervening NAT boxes will have to offer 
functionality for (properly authorized ... aurgh) access to traffic 
prioritization functions.

On 09/26/11 02:13, 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.
>
> 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").
>
> 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.
>
>
>
>
>
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb