The Enterprise NG911 Accountability Gap
To best understand today’s environment, you’re likely best suited with a brief history lesson on the evolution of telecommunications and the legacy 911 world. Before ‘divestiture’ and the break-up of Ma Bell, figuring out who the OSP (Originating Service Provider), or the originating phone company, usually didn’t require a corporate committee, a whiteboard, three vendors, a couple of lawyers, and someone in the corner quietly questioning their career choices. Before the mid-1980s, you typically didn’t even have a choice.
The carrier was the LEC (Local Exchange Carrier), period. The phone company originated the call, delivered the call, maintained the trunking in their market, handled long-distance connections to other carriers, populated the legacy records, and had a defined role in the 911 ecosystem. If something went wrong, you had a pretty good idea where to go with any questions.
The mid-80s brought the CLEC (Competitive Local Exchange Carrier), which would provide local competition, and you now had your choice of LD (long-distance) carrier on a call-by-call basis. That era also brought “slamming,” the practice of switching a customer’s long-distance carrier without proper authorization, often at inflated rates. The issue was widespread until the government stepped in with crackdowns, but it still exists today, although only in rare cases.
In the past, your LEC or CLEC was mostly a physical choice, and there was no question that they were the OSP.
But today, cloud-based MLTS (Multi-Line Telephone Systems), UCaaS (Unified Communications as a Service), and CCaaS (Contact Center as a Service) introduce new service capabilities. For emergency services, LIS (Location Information Servers) provide 911 address storage, and 911 TPSPs (Third-Party Service Providers) provide 911 routing, the database services required for cloud-based solutions. Finally, the state NGCS (Next Generation 911 Core Services) is quickly phasing out legacy E9-1-1 hardware in many states with NG911 capabilities, and the state ESInets (Emergency Services IP Networks), which replace the legacy E9-1-1 network connections with IP connectivity to the PSAPs and ECCs, have completely changed the picture. The clear delineations are now much blurrier, especially when it comes to defining the OSP.
Today, an enterprise may own the endpoint, maintain control of its internal network, understand the caller’s location, and generate and/or supply the PIDF-LO (Presence Information Data Format – Location Object). This electronic data container carries information across the network to a state ESInet and NGCS.
You can now better appreciate the complexity. When legislation or regulation points to the OSP, determining who actually fills that role becomes a major concern.
Today, the question becomes:
Who is the OSP?
And more specifically:
In a cloud-based MLTS environment, where the enterprise 911 call uses a LIS, a TPSP, or other cloud 911 service as an intermediary connection point to a state NGCS, is the originating MLTS owner or operator an OSP?
That may sound like a legal question, and to be clear, it is one that lawyers and regulators need to answer in the appropriate context. I am not a lawyer. I live my life vicariously through several very accomplished ones.
What is this questioning? Is this:
• An architecture question
• An operational question
• A public safety question
• And it’s an accountability question.
The Old Model Was Much Easier
True. The legacy enterprise 911 call path was not difficult to understand.
A user picked up a phone on a business telephone system and dialed 9-1-1.
The call moved through the PBX or MLTS.
The local carrier delivered the call to the legacy state 911 network.
The selective router used ANI (Automatic Number Identification) and ALI (Automatic Location Identification) records to route the call and to present the caller’s location information to the ECC.
Was it perfect? Not even close.
Legacy enterprise 911 was full of problems. Bad station records. The main billing telephone numbers appeared instead of the actual caller’s number and location. Phones were moved without updating the records. Remote workers appeared at headquarters, and branch locations often shared a centralized trunking system, eliminating local phone lines.
We have been fighting those dragons for years, but the model had familiar boundaries.
There was a carrier. There was a 911 network. There was an enterprise phone system. There were trunks, records, or some trail to follow.
NG911 changes the trail.
The New Model Is Not Just a New Pipe
NG911 is often described as the transition from legacy, circuit-switched 911 infrastructure to IP-based emergency communications. That’s true, but it’s incomplete. NG911 is not just a newer, shinier pipe carrying a voice call.
Think of NG911 as an architecture that supports IP-based signaling, data exchange, policy-based routing, location objects, additional incident data, and multimedia payloads. This creates a new ecosystem for public safety communications that enables this information to be openly shared over a purpose-built, interoperable ESInet (Emergency Services IP Network) and NGCS. It’s this public safety ecosystem that allows citizens to send and agencies to receive richer information about the emergency, the individual or device initiating the request, precise geospatial location, and the surrounding environment.
Legacy E9-1-1 generally followed a more linear carrier-based path. NG911 introduces additional functional components that can improve capability but also complicate accountability, as shown here.
Even today, a traditional telecom carrier may still be involved, or it may only provide generic transport over a SIP trunk. That connection may not provide meaningful visibility into the enterprise network or device-location environment.
Meanwhile, in NG911 environments, the 911 TPSP may be providing routing, location validation, or call delivery functions. The LIS provider may produce a location by value or by reference. The UCaaS provider may be handling the voice platform. The enterprise may be managing the building network, users, devices, subnets, access points, rooms, floors, and on-site notification.
That is a lot of hands touching one emergency call, and the various LEGO™ blocks can be placed in multiple different orders, depending on the architecture. Network architects need to remember that when five entities touch the call path, the question is no longer, “Who touched it?”
The critical question becomes: “Who owns it when it fails?”
Why the OSP Label May Not Match Functional Reality
Recent NG911 transition rules and related state-level legislation increasingly reference the role of the OSP, something that makes complete sense in a traditional telecommunications model. The OSP originates or carries 911 traffic and, under the FCC’s current NG911 transition rules, may be required to deliver it in the required format to the State 911 Authority’s designated 911 Delivery Point. That typically means utilizing SIP-based interconnection and a new termination point that is not the legacy 911 selective router.
That is also the type of issue state authorities like Massachusetts are raising with the FCC, particularly when legacy carriers resist or challenge connectivity models that do not align with their existing network assumptions. But this raises a second and very different problem for the enterprise.
If an enterprise MLTS owner or operator is treated as the OSP, or even confused with one, it may suddenly find itself in the middle of rules, expectations, and delivery obligations originally designed for carriers, not private enterprise networks.
That is the danger.
Cloud MLTS can blur that model. Consider a modern enterprise deployment.
The enterprise owns or controls the building network. It knows where the endpoints are connected. It knows the subnet, switch port, wireless access point information, building, floor, suite, room, zone, or common area.
It may employ commercially available applications to collect and extract that location information, provide that information to a provider-hosted LIS, or insert PIDF-LO into the call signaling. It may also communicate directly with a TPSP through a standard or proprietary interface, which would then connect to a NENA I3 standards-based state NG911 environment.
The UCaaS provider may host the voice platform, but it may not know whether Room 312 is Room 312 or whether someone moved a phone last Friday afternoon and forgot to update the database.
The carrier may transport packets, but it may have no idea whether the endpoint is in Boston, Worcester, Springfield, a home office, a hotel room, or a conference room with three identical-looking phones and one very bad day waiting to happen.
So, is the enterprise the OSP?
Maybe. Maybe not. That answer depends on the applicable law, regulation, contract language, service architecture, and facts of the deployment.
But from an operational perspective, the enterprise may absolutely be performing OSP-critical functions. That is the distinction that matters.
The formal legal label may be one question. The functional accountability is another. And public safety cares a great deal more about the latter.
Routing Is Not the Same as Responsibility
One of the mistakes we often make in these discussions is treating the act of routing a request for help as if that function were a complete answer to the question of responsibility.
NO. It does not.
Even though correct routing is an important element of success, on its own, routing remains just one element of the emergency accountability question.
911 requests can be perfectly routed to the wrong jurisdiction if the location data elements contain incorrect information. A beautifully formatted PIDF-LO object with a bad address is still of no use to anyone. A platform may deliver every required standards-compliant field and still be useless to the person experiencing the emergency because the upstream enterprise data was stale, incomplete, or never validated.
A beautifully formatted wrong location is still a wrong location.
Incorrect NG911 information cannot be magically detected or corrected if it’s wrong. The information is just delivered faster, with a loud, authoritative-sounding voice.
That is why the real accountability question must be broader than just, “Who routed the call?”
- Authoritative responsibility needs to be established by:
- Who owns the device location discovery?
- Who assigned the location to the device?
- Who validated the civic address, and what was the confidence level of that decision?
- Who validated the dispatchable location sub-address data inside the building?
- Who generated or supplied PIDF-LO?
- What network entity controls the SIP signaling?
- Who performed the call routing?
- Who delivered the call to the state-designated NG911 Delivery Point?
- Who is responsible for testing, monitoring, and maintenance of the overall service health?
- Who is responsible for notifications to the enterprise or 911 authority during an outage?
- Who is responsible for fixing the failure?
- And after an incident is over, who provides the after-action details, such as:
- • What was supposed to happen
- • What actually happened
- • Where the breakdown occurred
If no one can answer those tough questions, the architecture is not just incomplete but also likely too convoluted.
The Location Validation Problem
At the center of this issue is what I call the location validation problem.
In legacy 911 networks, the system relied on telephone numbers to establish service addresses. That particular model worked well for fixed-line residential locations, the primary source for most emergency call requests. For commercial enterprise environments, it was less effective and significantly strained. Cellular wireless networks did not yet exist, so at least the environment was understood, and the limitations were accepted.
In today’s cloud, MLTS, and UCaaS environments, that important location truth may reside within the enterprise network, hidden from public safety unless it is intentionally collected, validated, and shared.
The enterprise may know information such as:
• The identity of the user and device
• Information about the building, floor, and room of the caller
• The wireless access point providing the service footprint
This information helps the enterprise determine whether the caller is in a lobby, lab, classroom, dormitory, patient care area, factory floor, or restricted-access facility.
If the TPSP, or NGCS, for that matter, doesn’t have access to the raw information required to determine location or provide a level of confidence in its accuracy, location cannot magically be determined inside a private building.
The ECC can’t dispatch responders to the right location based on information that was never collected, never validated, or never provided. This is why the enterprise is no longer a passive telephone subscriber in the emergency call chain. They have become an active participant in the emergency response process.
And in some cloud MLTS deployment architectures, the enterprise may be the only party with the information that public safety needs most.
The Dangerous Comfort of Vendor Labels
This is where vendor labels can become dangerous.
One provider may say, “We are just the LIS.”
Another may say, “We are just the routing provider.”
Another may say, “We are just the UCaaS platform.”
Another may say, “We are just the SIP trunk provider.”
The enterprise may say, “We bought the service, so we assumed they handled 911.”
That is a wonderful sentence right up until the deposition in a tort lawsuit, where the question may become less about the vendor label and more about what each party knew, controlled, and failed to do.
My Responsibility Matrix
Every cloud MLTS NG911 deployment should have a written responsibility matrix.
I’m not talking about a marketing diagram, or a vague statement that says “911 is included”, or a checkbox on some procurement form. No, a real responsibility matrix that identifies the entity responsible for things like:
• Device discovery
• Location assignment
• Civic address validation
• Dispatchable location validation
• LIS operation and data integration
• PIDF-LO content generation and insertion
• SIP signaling and header preservation
• 911 call routing and delivery to the NG911 Delivery Point
• On-site notification and callback handling
• Service monitoring functions and outage procedures
• Failure remediation, including test call procedures before and after an outage
• Post-incident report and audit support
That matrix should be reviewed by the enterprise, the UCaaS provider, the LIS provider, the TPSP, the 911 authority, and, where appropriate, legal counsel.
And it should be completed before go-live. Not after the first failed call, or after the first news story when someone says, “We thought the other vendor had that.”
Where Enterprise Thinking Fits
This is where the next generation of enterprise 911 accountability needs to be.
Enterprises need much more than a service provider that supplies dial tone or routes calls. They need someone who delivers an operational control layer that understands devices, users, locations, policies, testing, notifications, outages, and evidence.
They need to prove they are ready for NG911, not just claim they are connected to it.
That is the market gap, and it is meaningful.
As NG911 becomes more capable, it will also become less forgiving of errors. Certainly, the system will be able to carry far better information, richer context, and more precise location. But that also means bad, stale, and unowned information will be exposed faster and more clearly.
NG911 does not eliminate enterprise responsibility. It exposes it.
The Bottom Line
The question, “Who is the OSP?” is not going away any time soon. Cloud MLTS and UCaaS architectures are making it more relevant. What’s the legal answer? That depends on regulations, contracts, and the facts of each deployment. Because the enterprise controls the endpoint, it manages its network, and knows the location, when it delivers the call to 911, the enterprise is no longer an innocent bystander.
Even though a commercial business, school, or hospital may not be the traditional carrier, and may not be formally labeled as the OSP, it may still be performing functions that closely resemble the traditional OSP role.
And that means the enterprise must understand exactly where responsibility begins, where it transfers, and who owns the failure when the call doesn’t work.
Because in 911 networks, ambiguity is not a strategy. It is a liability waiting for a ringtone.
A trial jury doesn’t care how many logos were on the PowerPoint slide. They don’t care which provider was responsible for which API. They are unlikely to care that the PIDF-LO was technically well-formed if it sent responders to the wrong place.
The only thing that matters is whether the call reached the right ECC, with the right location information, and included enough context for responders to help.
Everything else is just paperwork: important paperwork, but paperwork.