Subject: [rtcweb] RTCWEB and emergency services

From: Bernard Aboba <[email-masked]>
Date: Sun, 25 Sep 2011 17:13:08 -0700

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

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 26 Sep 2011 11:48:56 +0200

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 
>  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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Ted Hardie <[email-masked]>
Date: Tue, 27 Sep 2011 11:33:38 -0700

Hi Bernard,

Some comments in-line.

On Sun, Sep 25, 2011 at 5:13 PM, Bernard Aboba <[email-masked]>wrote:

> 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.
>
> 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 meeting the requirements for emergency services support, the important
> question to answer is what functionality MUST be present natively within the
> browser
>
>
>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 27 Sep 2011 11:59:55 -0700

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.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 27 Sep 2011 12:24:37 -0700

In-line.

On Tue, Sep 27, 2011 at 11:59 AM, Bernard Aboba
<[email-masked]>wrote:

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

I think where we diverged was in my interpretation of your statement
"operator of the service"; I assumed you meant emergence service.  You,
however, are seeing RTC Web sites as if it they provide a voice service.

Speaking personally, I don't think that is the right model.  I can see an
emergency service provider providing an RTCWeb service as part of its
efforts, just as it may accept IMs, text messages, and other non-traditional
communications.  But assuming that any provider of an RTCWeb application
must provide a method to reach emergency services does not make sense to
me.   It takes the "voice is a service" vs. "voice is an application"
discussion back a dozen years.  Downloaded javascript from a system presumed
to be malicious is not how you want to make your 911/112 calls.

Imagine the poker site example.  Can the poker site require that emergency
services folks have a login to its system in monitor state in order to
provide this service?  Probably not even for one jurisdiction, much less
many.   The only other way to accomplish that in a closed-system approach
like the poker site is to have every site have a gateway capable of reaching
emergency services, and a break-out method to "dial an emergency number".

Even this will fail for sites that provide rendezvous but do not remain part
of the calling infrastructure post facto.  In the dating site example, two
members may initiate calling via a web site.  Once the peer-to-peer flows
are set-up, they can continue chatting *even if they lose reachability to
the rendezvous web site*.   Unlike the poker site, there is no necessary
access to the rest of the application.

Despite our re-use, it is vitally important to remember that these
applications are not phones.  I could set up a WebRTC applications called
"Subtitle" (after the old improv game) in which I get video from one player
and audio from another in order to mash them up and show the results to a
third parties.  There would not necessarily even be a facility in such an
application to get audio and video from the same party--since that would be
contrary to the point of the game.

If you must describe in the terms of telephony, please circumscribe your
terms--"For RTCWeb applications intended to provide telephony services, the
following considerations apply...."  But generalizing the whole application
space to telephony, even for the benefit of emergency services, is not where
I think we ought to go.

Speaking personally and without hats,

Ted

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 27 Sep 2011 21:48:19 +0200

> space to telephony, even for the benefit of emergency services, is not where

I agree. I don't know where this topic comes from, but IMHO it makes
no sense to consider a WebRTC provider a "usual" PSTN operator. It
would be a show-stopper.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 27 Sep 2011 15:02:46 -0700

Ted Hardie said: 

"Speaking personally, I don't think that is the right model.  I can see an emergency service provider providing an RTCWeb service as part of its efforts, just as it may accept IMs, text messages, and other non-traditional communications.  But assuming that any provider of an RTCWeb application must provide a method to reach emergency services does not make sense to me. "

[BA] I believe that is what I said in my original message.  The obligations of the RTCWeb application will depend on what it is doing, as well as the country/state and possibly the device it is running on.   Some applications (e.g. realtime enablement of a game or social network) may not have an emergency service obligation.  Others (such as service enabling phone calls to and from the PSTN) may have such an obligation.  YMMV.  

An emergency service provider or PSAP could also use RTCWeb as part of their efforts, of course.   Dispatcher workstations often do support browsers, although the sites that can be accessed may be controlled for security reasons.  That is definitely worth mentioning. 

Ted Hardie also said: 

"Downloaded javascript from a system presumed to be malicious is not how you want to make your 911/112 calls."

[BA] Indeed, this does raise potential issues, given concerns over attacks such as "swatting".   Currently this kind of attack isn't covered in the RTCWEB security document.  In addition to the malicious Javascript concern, there is experience with SIM-less calls, for example, which indicates that lack of authentication tends to lead to an increase in prank calls.  

Ted Hardie said:

"Can the poker site require that emergency services folks have a login to its system in monitor state in order to provide this service?"

[BA] I'm not aware of any jurisdiction which currently imposes an emergency services obligation on an online game.  Is this a real use case?

Ted Hardie said:

"Despite our re-use, it is vitally important to remember that these applications are not phones."

[BA] We've already seen a demo of a handset utilizing RTCWEB technology.   However, just because some applications *are* phones doesn't imply that *all* RTCWeb applications will have emergency service obligations, that an RTCWeb-enabled browser needs to natively support every potential emergency service scenario, or even that RTCWeb needs to handle all the obligations that do arise.   After all, many of the major issues in emergency services (like location determination) don't have that much to do with RTCWeb, and there are other APIs (such as the Mozilla WebAPI proposal) that could provide emergency services functionality based on the underlying telephony platform, distinct from RTCWeb.

Ted Hardie said:

"If you must describe in the terms of telephony, please circumscribe your terms--"For RTCWeb applications intended to provide telephony services, the following considerations apply...."  

[BA] I would prefer not to give advice as to what applications do and do not have emergency service obligations.  Given some of the proceedings now in progress that is a complex subject and I'm not a lawyer.  But we can say "For those RTCWeb applications that have emergency services obligations, the following considerations apply.... "  leaving it up to the reader (and their lawyer) to parse through the existing and future regulations to figure out what their obligations might be.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 27 Sep 2011 15:19:15 -0700

> no sense to consider a WebRTC provider a "usual" PSTN operator. It

[BA] Agree.    Not sure where this topic comes from either, since I didn't suggest this in my original post (in fact, I specifically noted that emergency obligations would not apply to many RTCWeb applications). 

For example, a WebRTC application that does not provide the ability to make or 
receive calls from the PSTN would not be classified as an "inter-connected VoIP" 
provider and AFAIK would not currently have an obligation to provide emergency services (at least within the US).

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 28 Sep 2011 09:00:43 +0200

I'm waiting for the draft to read in context, but what I hear Bernard 
saying is:

"IF the RTCweb service falls within the scope of 911 regulations
THEN here are some things it needs to consider...."

Some RTCWeb services will certainly not fall within the scope of 911 
regulations.
If someone creates a service where it does matter (sets out to emulate a 
phone perfectly in the browser, for instance) they may very well find 
themselves in a situation where they do become subject to regulation, 
and in that case, the implementor may have benefit from reading 
Bernard's draft (or the document that eventually results from it).

All other service implementors can disregard it.

I hope....

On 09/28/2011 12:19 AM, Bernard Aboba wrote:
> [BA] Agree.    Not sure where this topic comes from either, since I 
> didn't suggest this in my original post (in fact, I specifically noted 
> that emergency obligations would not apply to many RTCWeb applications).
>
> For example, a WebRTC application that does not provide the ability to 
> make or receive calls from the PSTN would not be classified as an 
> "inter-connected VoIP" provider and AFAIK would not currently have an 
> obligation to provide emergency services (at least within the US).
>
>

---

From: Randell Jesup <[email-masked]>
Date: Wed, 28 Sep 2011 10:33:21 -0400

On 9/28/2011 3:00 AM, Harald Alvestrand wrote:
> If someone creates a service where it does matter (sets out to emulate 
> a phone perfectly in the browser, for instance) they may very well 
> find themselves in a situation where they do become subject to 
> regulation, and in that case, the implementor may have benefit from 
> reading Bernard's draft (or the document that eventually results from it).
>

I hope too.  I'll note that in the US the FCC has a history of changing 
the rules on 911 compliance (and other legal requirements like intercept 
(CALEA)).

VoIP was originally excluded; then it was included only for calls to the 
PSTN, then it was included for all calls if your "network" was attached 
to the PSTN (even if the call was totally on-net).  (This refers to 
CALEA.)  There's even been talk of extending it to non-PSTN-connected 
networks like XBox Live.

So I wouldn't assume that there won't (now or in the future) be a 
requirement for application developers to support either 911 or CALEA 
(in the US) or the equivalent in other countries.  And the requirement 
already exists for anyone who wants to connect an WebRTC client to the 
PSTN in the US.

As far as *we're* concerned, I think it just means we should make sure 
some basic functionalities are available to the applications so *they* 
can comply - and I think that's what Bernard is addressing.

For example, see
http://paranoia.dubfire.net/2011/02/deconstructing-calea-hearing.html
(Good article, BTW)

    Voice services that do not connect to the public telephone network.
    Google and Facebook both offer in-network audio chat to their users
    (Google also offers video). Microsoft's XBox 360 service, Blizzard
    and several other online video game platforms allow users to insult
    each other chat while they play against other users online. At least
    from published information, I'm not aware of any one of these
    companies offering interception capabilities -- and so law
    enforcement agencies almost certainly want access to this

I'll also note that browser<->browser WebRTC communication currently 
won't be covered by the CALEA requirement-to-decrypt even if the service 
provider's network attaches to the PSTN because (if we're using DTLS) 
the keys aren't known to the provider (or the app).

-- 
Randell Jesup
[email-masked]

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 28 Sep 2011 09:41:18 -0600

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

> 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 an…

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 network…

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 deli…

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

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 28 Sep 2011 08:45:29 -0700

> the rules on 911 compliance (and other legal requirements like intercept 

[BA] The draft isn't going to cover CALEA, and won't provide guidelines on
when an RTCWEB application would or would not be subject to emergency
services obligations.  

Although the draft can cite some existing rules and the rulemakings now in progress, 
trying to summarize the situation globally is difficult even for existing rules, let alone
future ones. 

> CALEA.)  There's even been talk of extending it to non-PSTN-connected 

[BA]  As you say, the rules change over time, which is a good reason not to
try to summarize them in an IETF document.  At best, the document could
summarize them accurately prior to publication, after which the rules would
change and the document would become out of date and misleading.  

> (in the US) or the equivalent in other countries. 

[BA] Predicting the future is always challenging, which is a good reason to
avoid doing so in an IETF document. 

> And the requirement already exists for anyone who wants to connect an WebRTC client to the 
> PSTN in the US.

[BA] The exact nature of this requirement may potentially change, so even
for this case, it is probably best to avoid making statements.  For example, 
see the questions relating to an amendment to the definition of "interconnected
VoIP" included in the Location NPRM:
http://transition.fcc.gov/Daily_Releases/Daily_Business/2011/db0713/FCC-11-107A1.pdf

Also, note the questions relating to accessibility in the NG911 NPRM:
http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-11-134A1.pdf

> http://paranoia.dubfire.net/2011/02/deconstructing-calea-hearing.html

[BA] Yes, that is the question -- but I'm only planning to address emergency
services issues, not CALEA.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 28 Sep 2011 09:31:28 -0700

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

> 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 sayi…

[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 n…

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