[Asterisk-biz] Status of 911 for voip providers?

[David Pollak]

My Take:


        FCC VoIP 911 ruling is wrong
 
<https://www.lostlake.org/blog/index.php?/archives/3-FCC-VoIP-911-ruling-is-wrong.html>

The Order does not meet its stated goals. It is more costly and
burdensome than it has to be. It is over-broad, yet it will not achieve
the over-all safety goal that it uses as justification. My proposal will
lead to more 911 access from more devices, place the costs and the
regulatory burden on parties with the best access to location
information, the best ability to route the packets, and the best ability
to spread the costs over the group that will benefit from access to 911
service.

FCC 05-166, the VoIP 911 order, gets the stated goals wrong and will
wind up causing more failed emergency calls and significantly higher
costs than other solutions. In this note, I will outline the
deficiencies in the order and propose a significantly different method
for routing emergency calls from the Internet to existing E911 facilities.

FCC 05-166 (“The Order”) outlines a series of competing goals as the
reason for The Order and as way to justify that the FCC has the
authority to make the order. The goals are public safety (see footnote
2), meeting the expectations of existing telephone users, reasonable
cost and burden allocations, and minimal regulation of the Internet. The
Order acknowledges the difficulties in actually implementing The Order
(see footnotes 80 and 81), but takes the position that “If we mandate
it, it will be built,” (see II.C.25.)

The Order fails to meeting its goals because it is over-broad, it is
unsafe because relies on new behaviors by end users (registration and
re-registration each time the calling device is moved), and it is unsafe
and regulatorily burdensome by placing the burden of implementation on
the the companies that provide VoIP to PSTN connectivity, rather than
the end-user's network provider. This indicates an attempt to graft E911
onto VoIP rather than regarding the Internet as the primary network for
an increasing number of people.

The Order acknowledges that obvious: end user registration will not
work. The Order cites recent tragedies relating to people expecting PSTN
911 service from VoIP devices as a motivator for the terms and authority
of The Order. These tragedies were brought about because people have
expectations about the behavior of a telephone handset and in these
cases, the handsets did not work as expected. This is an indicator that
people will behave as they've been trained since “911” became the
emergency number 40 years ago. People do not expect to have to register
a device and then update that registration each time they move that
device any more than they think about registering their wireless devices
as being in a new location. Placing the burden of registration on the
end user, no matter the amount of warnings and notifications the user
receives, will not, in the next few years, change people's expectations.
A parent who brings an IP phone home from work so they can work at home
the next day may not register a new location for the phone. A child
using that phone for a 911 call will not receive the help they need.
Having a user-registration system will fail and lead to more tragedies,
thus the primary goal of The Order will not be met.

Placing a regulatory burden on VoIP to PSTN providers (“VoIP Providers”)
is not the most cost effective or regulatory minimizing mechanism for
achieving the important public safety goals of The Order. Providers have
a different relationship with their customers than do providers of PSTN
or IP network connectivity (“Network Access Providers”). VoIP Providers
supply a service to their customers similar to the services provided by
online gaming providers, long distance carriers, music download
services, and other providers of content. VoIP Providers provide service
to customers regardless of physical location or network connectivity
type. Because VoIP Providers do not have real-time or verifiable access
to location information and because they are not the fewest packet hops
away from the user, it is more costly, more burdensome, and less
reliable for VoIP Providers to maintain, and, in the case of an
emergency, transmit information and voice to the appropriate PSAP.

The Order uses as its justification the issues with people substituting
VoIP for PSTN service and expecting the VoIP service to provide the same
911 capabilities. This is logical for providers that supply an ATA
(Analog Telephone Adapter) into which the user can plug a normal
telephone. In this case, mistaking a VoIP handset for a PSTN handset,
especially in a high stress situation, can be reasonably understood to
lead to a bad outcome. However, The Order also regulates interconnected
VoIP providers (“iVoIP Providers”) that supply services through a
soft-phone running on a PC. While The Order goes to lengths to justify
regulation of an Internet service, it is over-broad in its regulation of
access to iVoIP Providers via soft-phones. An end user that has a
soft-phone does not have the expectation of access to 911. The Order
could have allowed iVoIP Providers to offer soft-phone only plans that
do not have 911 capability. Such a plan would offer cost-conscious
consumers and those consumers who are not looking to replace PSTN
service with VoIP (e.g., Skype users) with a choice of plans to suit
their needs and at the same time to offer minimal regulation of the
Internet. If the over-riding goal is public safety, only regulating
iVoIP Providers does not offer end-users 911 service on all their
networked devices. If the over-riding goal is minimal regulation, then
requiring iVoIP Providers to offer 911 service on soft-phone only plans
is over-broad.

Let's take a detour to discuss the players in a 911 call, what resources
they have, and what their expectations are. There are four players in a
911 call: the caller, the device provider, the network provider, and the
PSAP.

The caller has certain expectations based on 40 years of training that
when he picks up a voice communications device and dials 911, he gets
help. Making help available on any networked device that has voice
capabilities makes a ton of sense and increases safety.

The device provider used to be one company, AT&T. Then handsets were
provided by a variety of providers, but they all worked with the PSTN
infrastructure. Then came wireless phones. Over the last few years,
support for 911 service on wireless devices has gotten much better. I
remember once when I was in California with my Boston numbered cell
phone and I called 911 to report a traffic accident. I got a
Massachusetts state trooper. It wasn't much good. The device providers
are including GPS and other location systems in the devices callers use
to access 911. Extending that expectation (and associated cost burden)
to makers of other networked devices seems perfectly reasonable given
the over-riding safety goal.

The next player is the network provider. With a wireline device, the
network provider is the organization that provides the wireline to the
caller. The network provider has knowledge of the physical location of
the wireline. They have the ability to transport voice and location data
to the PSAP. In the case of wireless, the handler of the signal from the
wireless device provides transport of voice and location data. Over the
last few years, wireless providers have improved the location data
supplied as part of an E911 call.

The PSAP expects to receive voice (or TTY), location, and call-back
information in order to aid the caller. There are well-published
protocols for this information that have been enhanced to support
wireless E911.

I propose that the Network Access Provider be responsible for
transporting voice and/or text and location information from any of
their customers to the PSAP. This would make the group with the most
knowledge about and least distance from the caller responsible for
routing 911 information from the caller to the PSAP. Additionally,
makers of network devices capable of transmitting voice or text
conversations over a network would be responsible for implementing APIs
and applications to allow users of those devices and applications that
run on those devices to place calls to emergency services.

Network Access Providers are the parties responsible for supplying
network access to callers, whether the network is the PSTN, wireless to
PSTN, or IP based. In the case of a home, it would be the ISP or
telephone company. The ISP and telephone company have knowledge of the
physical location where customer equipment is located (in the case of
PSTN, DSL, T1, or cable modem) and can quickly correlate an IP address
or a wire pair to a physical location. In the case of a hotel or
apartment building that has network access provided by the hotel or
building management, these groups have the ability to correlate an IP
address or wire pair to the room or apartment number. In the case of a
large business or university, there would be a requirement that the
organization correlate IP to location. The Network Access Provider for
the Internet is no different from the phone company or a wireless
company, both of which provide access to the PSTN. In all cases, the
party that provides access to the network is the party that has the
burden of providing access to 911.

In the case of IP Network Access Providers, a currently unused class C
IP address block would be converted to a non-routable address and
allocated to 911 services. Each Network Access Provider would treat
packets addressed to that address block as high priority and route them
to SIP server that would correlate the IP address of the source to a
physical address and would stream SIP messages and SDP messages (either
voice or text) to the local PSAP over the PSTN with appropriate location
data and call-back data (call back in this case may be unreliable if the
callers device is behind a firewalls, etc.) The call-back data would be
a PSTN number that would be bridged back to a SIP call so that the PSAP
could use existing technology to call back.

The result of this proposal would be to treat an IP Network Access
Provider the same way that the FCC currently treats PSTN Network Access
Providers. Network Access Providers have the best access to location
data and the best ability to prioritize and transport emergency messages
to the appropriate PSAP. The burden to Network Access Providers would be
low. They would have to integrate customer location information that
they already have with a VoIP server in real-time. The VoIP server could
be built with an inexpensive Intel server running Linux and Asterisk for
less than $5,000. Such a server could handle 100 simultaneous emergency
calls. While this does place a regulatory burden on IP Network Access
Providers, they could pass the costs to their customers and because the
costs would be passed to all customers (rather than those that signed up
for VoIP service), the per-customer costs would be lower. Additionally,
because the information is already known to the Network Access Provider,
the aggregate costs of implementing such a system would be lower, while
providing 911 service to more devices.

One may argue that regulating the Internet rather than just the places
that the Internet touches the regulated PSTN is a slippery slope that we
don't want to go down. I argue that IP Network Access Providers must be
regulated in order that they remain common carriers. IP Network Access
Providers must be regulated so that they don't discriminate the traffic
that they carry (e.g., they block VoIP traffic from 3rd party VoIP
providers, but allow their own, they prioritize packets for video on
demand services that they provide over streaming video from a 3rd party,
etc.) Having a requirement that IP Network Access Providers also provide
emergency services does not discriminate among the providers, but sets a
requirement that they all must fulfill in order to serve the public.

The Order does not meet its stated goals. It is more costly and
burdensome than it has to be. It is over-broad, yet it will not achieve
the over-all safety goal that it uses as justification. My proposal will
lead to more 911 access from more devices, place the costs and the
regulatory burden on parties with the best access to location
information, the best ability to route the packets, and the best ability
to spread the costs over the group that will benefit from access to 911
service.

I look forward to your comments and feedback at
https://www.lostlake.org/blog/index.php?/archives/3-FCC-VoIP-911-ruling-is-wrong.html

Dustin Goodwin wrote:

> " " Furthermore, providers of interconnected VoIP services that can be
> utilized from more than one physical location must provide their end 
> users
> one or more methods of updating information regarding the user's physical
> location. "
>
> --If there was any question about not having to handle updates, it's 
> settled
> here. If they can be at more than one location, they have to be able to
> update. "
>
> * Sorry if this has has hurdled off-topic *
>
> The real problem is all Voip service is *capable* of being nomadic. Only
> ISPs can practically offer a Voip service that is non-nomadic. Every
> other Vonage of the world is nomadic by it's nature. Let's just go ahead
> and assume a nomadic user is not going to update a web form every time
> they plug in. It's a process designed to fail. IMHO Voip providers will
> need an automatic way to resolve an IP address to a street address.
> While this will not work for mobile wireless IP services like
> 1xRTT/EVDO. It will work for most Metro Ethernet, T-1,DSL, Cable Modem,
> fixed wireless services,etc. Maybe what these rules really need is to
> mandate a DNS style LOC record for every IP address. The current DNS LOC
> record is designed to provide latitude and longitude coordinates. Which
> is not all that useful for E911 services (hello cellular!). But a street
> address equivalent of LOC record system would do well. *
>
> *Unfortunately the needed ISP rules might some how be outside the
> jurisdiction of the FCC. But if this was in place Voip providers could
> update the ALI database by reading the location information when the
> user registers from a different IP address. If no LOC records exists
> the client software can notify the end user that E911 is not available.
> Privacy considerations with a reverse lookup database like this would be
> significant. So perhaps a closed system that only allows authorized
> queries is needed.
>
> The big danger for the FCC is that the rules they have put in place are
> creating a system dependent on end user cooperation. Bottom line is you
> CANNOT depend on the consumer to help themselves.
>
> - Dustin -
>
> Michael Giagnocavo wrote:
>
>> Not that I know of. From the FCC order:
>>
>> " To achieve these goals, the Commission adopts a broadly-stated E911
>> requirement that applies to all interconnected VoIP services, while 
>> allowing
>> providers flexibility to choose among technological solutions. "
>>
>> --Key word is *all*.
>>
>> " The Order recognizes that some VoIP services, particularly those 
>> nomadic
>> services that allow consumers to take their VoIP service from their 
>> home to
>> their office or their beach house, face significant implementation
>> challenges. Access to the trunks, selective routers, and databases of 
>> the
>> E911 network is essential to meet the obligations set out here."
>>
>> --Here the FCC recognizes nomadic services, and adds that there might be
>> "significant implementation challenges".
>> " Furthermore, providers of interconnected VoIP services that can be
>> utilized from more than one physical location must provide their end 
>> users
>> one or more methods of updating information regarding the user's 
>> physical
>> location. "
>>
>> --If there was any question about not having to handle updates, it's 
>> settled
>> here. If they can be at more than one location, they have to be able to
>> update.
>> One thing the order is not clear on is how fast the updates need to 
>> happen.
>> The FCC says "timely", and refuses to set any specific performance 
>> metric.
>> Some people are working on a "one business day" response, and others 
>> (inc.
>> the company I work for), are doing ~15 minutes. I personally believe 
>> the FCC
>> is going to see what people do and decide to then set some standards. 
>> I.e.,
>> if 90% of providers are doing 15 minute updates, and a few are only 
>> doing
>> 1-day updates, I'm pretty sure they'll address the issue. (I 
>> certainly don't
>> think 1-day is "timely").
>>
>> I personally believe it's better to side on being a bit more cautious 
>> and
>> implementing something that will most certainly work, versus looking 
>> for a
>> loophole and hoping to slide through. Even doing a rough calculation for
>> risk shows it's not worth it.
>>
>> Disclaimer:
>> This is my own opinion which I believe is reasonably informed and 
>> does not
>> necessarily represent the views of Dash911. I work for Dash911, which
>> provides 911 services, so I could have some slight bias in my personal
>> views.
>>
>> -Michael
>>
>> -----Original Message-----
>> From: asterisk-biz-bounces at lists.digium.com
>> [mailto:asterisk-biz-bounces at lists.digium.com] On Behalf Of Dustin 
>> Goodwin
>> Sent: Monday, August 08, 2005 10:06 AM
>> To: Commercial and Business-Oriented Asterisk Discussion
>> Subject: Re: [Asterisk-biz] Status of 911 for voip providers?
>>
>> Were there any exemption for nomadic services in the FCC ruling?
>>
>> - Dustin -
>>
>> Michael Giagnocavo wrote:
>>
>>
>>
>>>> Everyone,
>>>>
>>>> I've been trying to keep up with this 911 issue for voip providers. 
>>>> Does
>>>> anyone
>>>> have a handle on:
>>>>
>>>> 1. What must be done to be compliant?
>>>>
>>>>
>> <snip>
>>
>> _______________________________________________
>> Asterisk-Biz mailing list
>> Asterisk-Biz at lists.digium.com
>> http://lists.digium.com/mailman/listinfo/asterisk-biz
>>
>>
>> _______________________________________________
>> Asterisk-Biz mailing list
>> Asterisk-Biz at lists.digium.com
>> http://lists.digium.com/mailman/listinfo/asterisk-biz
>>
>>
>
>
> _______________________________________________
> Asterisk-Biz mailing list
> Asterisk-Biz at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-biz