As the telephone system moved from human operators to an automated system, the need for a quick way to reach emergency services became a societal goal. The first emergency number was 999 in the UK in 1937. In the 1960s, national emergency services were launched in North America using the number 9-1-1. In Europe, similar services were launched using 1-1-2.

These systems were designed to enable rapid response to emergencies in two ways:

1. Any call to that number was routed to a geographical center called a Public Safety Answering Point (PSAP) where personnel would be available to talk to the caller and dispatch emergency resources. Essentially, phone numbers are mapped to a PSAP that has geographical coverage for the location of the caller so emergency responders can be dispatched as fast as possible.

2. Provide the location information from the phone to the emergency providers. By using the information from the phone line, more specifically the address of that line, the emergency dispatcher could see the location of the call without the caller telling them the address. This was particularly helpful for children or people that were incapacitated in some way. The emergency system has been based on the strict relationship between a phone line and the address connected to it.

In a traditional terrestrial phone system, each phone has an individual line and number that are tied in a database to the address where the phone is located. As these phones do not move or change often, the entire system is relatively static and can be completely managed by the incumbent telecom service provider.

The advent of VoIP and mobile telephony has changed the landscape and made emergency services a much harder capability to implement. However, the underlying requirements and needs have not changed, so it is incumbent on the alternative service provider to adequately provide emergency services.

The focus of this whitepaper is to clarify the requirements and discuss mechanisms for meeting these requirements in modern communications systems, especially for the provision of cloud communication services towards enterprise customers.

Requirements

The requirements for emergency services vary by location, local government and centralized changes. Often regulations can vary on not only on country, but on regional and even local requirements.

North America (US/Canada)

In the US, emergency services are mandatory for all telephony services, including those at enterprise or other large facilities. In the US, different states have different regulations about how Emergency Services must identify the call’s originating location. Some states only require identifying the call to the address registered, while other states require more granularity.

For example, Illinois requires identifying the floor of the building. In all cases, the PSAP that is the emergency location for all terminating service for a geography must have access to an Automatic Location Information (ALI) and associated master street address guide (MSAG) databases. The MSAG is used to determine the right PSAP for a call, while the ALI is a specific database for the relationship between a phone number and a physical location that can include additional information such as a building or floor number.

The ALI must be updated whenever a phone number changes locations. Together, these tell the emergency services dispatcher the originating location of the call and tie it to a defined street address or, in a large building, to a floor. The PSAP dispatchers and first responders use the data from the ALI, confirmed by the MSAG to respond to the emergency and go to the right location. For this reason, most PSAPs are local or regional. There are currently about 6,100 Primary and Secondary PSAPs in the United States.

European Union

The European Union regulations oblige providers of electronic communications services (ECS) to offer access to emergency services to end-users. Currently, the obligation is implemented by national telecom regulations and the decision of what to require is defined by each country’s regulators. As a result, every country functions differently from a process perspective. The European Emergency Number Association (EENA) is defining pan-EU recommendation, but currently, these recommendations need to be adopted by each country.

Another major factor in the EU is that the definition of what constitutes an ECS and the companies that fall under that umbrella is currently unclear. There is currently a major movement to either loosen the restrictions on traditional telecoms or increase the regulation on OTT providers.

While the current rule relates to phone numbers and ECS organizations using phone numbers, the extension to services that do not use phone numbers is receiving active consideration. In summary, there is strong activity to drive additional requirements for 1-1-2 across all providers to assure that EU citizens get emergency services regardless of their chosen communications solution.

The result is less clarity around exactly what is required. For example, if a US-based cloud vendor is providing OTT services that are used by someone in a defined office in the EU, do the regulations apply? At this point, this can vary by country and by service.

Requirements – a Patchwork

Both in North America and the European Union, there are strong regulations for emergency services. However, on both sides of the Atlantic, the level of requirements and how they are applied is under significant change. This makes assuring that a telecommunications system meets these requirements particularly challenging. While there may be limited initial penalties, there are major issues like litigation that can arise should a major emergency event happen and the system does not meet local requirements.

Emergency Services Are Complex

The act of tying an address to a phone number and then assuring that that information is available to emergency dispatchers and first responders is already difficult. This is dramatically increased by the range of implementations.

For example, in the US alone there are 6,100 primary and secondary PSAPs that must implement any change or requirement. As most funding for PSAPs is local, the time for implementation of change is extended by funding and other political issues.

A similar level of PSAPs exists in the EU and Canada. Each PSAP is integrated with location information databases and systems. These databases can be operated by the PSAPs themselves, the incumbent, individual operators or a state-controlled independent 3rd party. The mechanisms that are used to enter data into the PSAP by a carrier that controls a phone number and the associated address are not standardized so they vary by country and are sometimes even customized at the local PSAP level.

As the system has its roots back in the early days of digital telephony, most location databases are designed for relatively slow updates. This reflects the fact that, before Internet Protocol-based telephony, a typical residential telephone line would be in place for 7 years, the average of home ownership, or even longer in an office or PBX.

The result is that every change in an end-user location must, the data must be entered into the location database(s) through non-standard interfaces, and parsed to the appropriate PSAP. Plus, the entire system is generally changing due to new technology at multiple levels.

This has resulted in a requirement to supply phone/locations information by providers of next-generation services or enterprises deploying IP-based communications, while not having a clear readily accessible way of configuring the data. The outcome is continual complexity, and for the providers of next-generation services on an expanding international footprint, a major nightmare for compliance to avoid fines or litigation.

Potential Solutions

Cloud Communications Services providers are faced by this landscape of regulation along with the enterprises that are buying their services. Both providers of services and their customers must have a clear solution for emergency services in the regional areas they serve. Until recently, the solution options for adhering to the patchwork of emergency services regulations has been limited to just a few:

  • Ignore the whole thing
  • Install a local phone line with a gateway
  • Do it yourself
  • Hire an aggregator

Each of these options has certain value, but also significant issues.

Ignore the whole thing

One option is to not offer any emergency services or minimal capabilities. However, for a cloud provider or an enterprise deploying cloud services, this can be a major issue. While users may have cell phones that can be used for emergency services, these are currently much less accurate and do not have the same level of location assurance.

For the cloud provider, not having a defined emergency services solution will result in a substantial loss of opportunities as customers are generally educated enough to demand it. Finally, if an incident occurs, there may be significant legal action, ranging from local fines and penalties to litigation for compensation from injury impact or death.

Install a backup simple phone line

There are two ways to provide a connection from a cloud communications system to enable local emergency services. One path is to implement either a SIP gateway (GW) or session border controller (SBC) at the edge of the local site that connects to a simple analog PSTN line with the incumbent. The GW or SBC can then be programmed to “intercept” an emergency call to 9-1-1 or 1-1-2 and route to a local telephone line.

As this line is managed by the local service provider, responsibility for the emergency services moves to this provider. However, this solution has significant cost and the potential for performance issues. The GW or SBC generally has some level of cost and requires set-up and programming, making it less effective for smaller sites. As all traffic must be forced through it, the node becomes a single point of on-site failure.

In all cases, the GW or the SBC and the local line must be managed, and this solution does not typically extend to single user locations such as work from home. Another option that was used in the early days of VoIP is to have a dedicated “red phone” for emergency access.

This is a single phone in the facility that is identified as the phone to use to call emergency numbers because this is a direct line to the local service provider. However, experience in VoIP deployments has revealed a major challenge in changing the typical assumption that any phone should be able to do emergency services directly, so this option is not generally considered as a viable option. In addition, there is an additional cost for the red phone and line as well as assuring that it is tested, fully staffed and operational 24/7.

Do it yourself

Of course, one option for a cloud provider is to bite the bullet and provide emergency services themselves. For the Cloud communications providers that started in a defined geography, this was an option. However, the continued globalization of economies, in combination with the ubiquitous nature of IP, makes this a challenge to keep local.

As more customers want the ability to have a single provider that supports a range of locations, the complexity increases rapidly.

For example, a mid-size customer of a cloud UC provider decides to open an office in an adjacent state or country. For the provider to support this single location requires building out a complete emergency services system and process to deal with emergency services in that particular country.

The option of suggesting the customer should get the emergency service at that site from someone else will create more complexity in the solution and often result in a complete loss of the customer. Therefore, as a cloud UC/PBX and SIP trunking organization grows, the complexity of managing operations for an in-house solution may grow at an exponential rate of customer growth, resulting in complexity and margin impact.

Hire an emergency services aggregator

There are emergency services aggregators that will take data on a phone number and location and enter it into the appropriate location database. While these services can provide emergency services and have been used by enterprises to manage this aspect of their offering, they are more complex for service providers. In addition, today they are all restricted to one geography, limiting their value for modern global providers.

Commercial emergency services solutions

For most implementations, the best option is to use a commercial emergency services vendor. In North America, the advent of VoIP led to the development of companies that provide the services to assure that the VoIP solution is integrated into the right PSAP and ALI. Companies like Intrado, 911 Enable and others provide this service.

Another option is to leverage the Voxbone global SIP infrastructure for emergency services. Voxbone has built a global SIP trunking network with local access in 60 countries around the world.

Voxbone maintains an integrated location database that can link a user’s telephone number to a local PSAP number based on that user’s actual location. So, an office in France that is supported for communications from a cloud service in the US will have those local numbers mapped in the Voxbone system to a local PSAP number. So if an employee calls 1-1-2, the call is identified as an emergency call and an originating call is made to the correct PSAP with an originating number that will betide to the address of the device location.

The result is a uniform global emergency services solution that is not an overlay but integrated directly into the SIP trunking and international dialing services. With local outbound calling capabilities, Voxbone combines local PSTN access, full ALI integration and correct PSAP dialing into the most comprehensive emergency services solution available.

As it is integrated with the core Voxbone services, the incremental cost is minimal. For cloud communications providers, Voxbone emergency services combined with SIP trunking are an ideal way to address organization locations that are outside of a more traditionally serviced footprint.

For example, a regional communications provider might provide emergency services through a system implemented internally and use the Voxbone solution for all of their out of areas implementations, dramatically reducing the complexity and cost of a geographic expansion necessary to maintain competitive potion in the ever-increasing competition in the cloud.

For enterprises that have implemented emergency services at a major site as an extension of the local IP PBX, Voxbone’s emergency services are an ideal way to use that system to support remote locations.

Conclusions

In North America, the EU and Australia/New Zealand, supporting emergency services is mandatory. The penalties and legal consequences of not complying and implementing an emergency service integration are significant.

For VoIP providers, not having a comprehensive emergency service can result in regulatory penalties, service curtailment or even potential lawsuits. In addition, as end customers are more educated, not having a viable emergency service solution will result in customer loss and lost opportunities.

Voxbone is the easy way to provide a comprehensive emergency services solution that meets regulatory requirements, is easy to implement and operate, and can be positioned as a value enhancement for any cloud communication offer. If you are a cloud communications services provider, you should review your emergency services position and work with Voxbone to optimize a global offering. As an enterprise expanding an internally managed VoIP solution, Voxbone offers an ideal way to meet the emergency services requirements with minimal cost and time investment.

If you are an enterprise looking to move to the cloud for your communications solutions, assuring that your cloud vendor options have a comprehensive global emergency services solution is critical. Regardless of where you fall on this spectrum, lives depend on making the right decisions, and Voxbone is prepared to deliver the right solution for your organization.