A 9-1-1 call comes in from a university campus. The street address is right. The building is right. The floor is wrong, and the medic spends four minutes in the wrong stairwell.
Ask who was responsible for that floor number and you'll get several defensible answers depending on who you ask. That isn't a hypothetical about some future state of Next Generation 9-1-1 (NG9-1-1), the standards-based replacement for the legacy 911 network. It's the current condition of federal rules.
The title question has a plain answer, so let's put it first. The Location Information Server — the LIS, the database that holds where each customer is and answers when the 911 network asks — belongs to the originating service provider (OSP), meaning the carrier whose network the call starts on. Not to the enterprise, not to the vendor, and not to a standards body that hasn't finished its work. That holds whether a multi-line telephone system (MLTS) is involved or not.
The rule says so, and it never mentions MLTS
The transition runs in two phases. Phase 1 is delivery of all 911 traffic in Session Initiation Protocol (SIP), the signaling used to set up calls on IP networks, to the NG911 Delivery Points a 911 Authority designates. Phase 2 adds delivery that complies with NG9-1-1 commonly accepted standards, with location carried in a Presence Information Data Format Location Object (PIDF-LO), the standard container for sending a location along with a call.
Under 47 CFR § 9.29(b), once a 911 Authority serves a Phase 2 valid request, an OSP must
install and put into operation all equipment, software applications, and other infrastructure, or acquire all services, necessary to use a Location Information Server (LIS) or its functional equivalent for the verification of its customer location information and records.
Read what that reaches: its customer location information and records. All of them. There is no MLTS qualifier in that sentence, and none elsewhere in § 9.29. An OSP served with a Phase 2 valid request owes a LIS across its whole customer base — residential lines, single-line business, and MLTS extensions alike.
That matters, because this gets filed under "the MLTS problem," as though enterprise phone systems were a special case waiting on separate treatment. They aren't. MLTS is where the obligation is hardest to satisfy, not where it starts.
There's a real objection underneath this, worth stating plainly rather than waiting for someone to raise it. Carriers haven't had to run a LIS before, and § 9.29(b) arrives without a funding source attached. The rules are explicit about who pays: under 47 CFR § 9.33(a)(3), OSPs are responsible for the costs of "obtaining and delivering location and routing information using ALI/ANI databases, selective routers, or other means at Phase 1, and using LIS functionalities or other equivalent means at Phase 2." That's a genuine cost problem, and it's the part worth arguing about. It just isn't a question about who is responsible.
The actual problem is how the data gets in
An empty LIS satisfies nothing. The obligation is to operate one that carries accurate, validated location for the OSP's customers, which means the OSP has to solve a data problem it may never have owned before.
How hard that is depends entirely on where the OSP is starting from. There are three common starting positions, and they are not equally difficult: provisioning records into an Automatic Location Identification (ALI) database that somebody else runs; using a Voice over Internet Protocol (VoIP) Positioning Center (VPC); or carrying MLTS traffic on top of one.
Case one: the OSP that provisions to an ALI provider
This is the familiar arrangement. The OSP collects a civic address from the customer and provisions it into an ALI database operated by somebody else. ALI is the legacy record store a public safety answering point (PSAP) — the 911 center that answers the call — queries to find out where a caller is. The OSP's obligation effectively ends at handing over a correct record; the ALI provider holds the database and answers the query at call time.
At Phase 2 that ends. The OSP now has to use a LIS producing PIDF-LO, and § 9.29(b) gives it two ways to get there: build the infrastructure, or acquire the service. Either way the OSP is answering for a location database in a format it has never had to produce, holding records it has only ever handed off.
This is the simplest of the three cases and it is still real work. It is a format change, a validation change, and a change in who holds the record. The address that was good enough for an ALI record now has to clear the Location Validation Function (LVF), the service a 911 Authority publishes so a civic address can be checked against authoritative map data before it goes into service, and be corrected if it fails. (How the LVF and the map underneath it work is covered in Four Boxes, One Map.)
Case two: the OSP that uses a VPC
Here the OSP already relies on a third party, and acquiring the LIS service from that vendor is a perfectly reasonable answer to § 9.29(b). But acquiring a service does not discharge an obligation, and the OSP is still the party the rule names.
What changes is that the vendor picks up obligations of its own, under a different rule — the covered 911 service provider definition at 47 CFR § 9.19, which carries certification under penalty of perjury and a set of reliability duties. And it picks them up function by function, which is less obvious than it sounds, because the VPC and the Emergency Services Gateway (ESGW) that actually carries the call are two different things usually sold on one line item.
That analysis deserves more room than it would get here, so it will be the subject of a separate piece.
For present purposes, one point carries forward. The rules attach to functions, not to companies or product names. A vendor may hold several at once; so may a carrier.
Case three: MLTS on top of a VPC
Now add the third layer, and this is where the floor number lives.
Since January 6, 2021, any person "engaged in the business of installing, managing, or operating" a multi-line telephone system has had to convey dispatchable location — the street address plus the floor, room, or suite a responder actually needs — with a 9-1-1 call from an on-premises fixed phone. Non-fixed on-premises and off-premises devices followed on January 6, 2022. That's 47 CFR § 9.16, out of Kari's Law and Section 506 of RAY BAUM'S Act.
Section 9.16 splits that duty by role. Manufacturers, importers, sellers, and lessors must ship a system capable of dispatchable location. Installers must configure it. Managers and operators must see that location is actually conveyed, which is the heaviest of the three. The Commission's own guidance is that an organization running its own phone system is the manager or operator; there's no exemption for not being in the business of doing it for somebody else, and it reaches government agencies and non-profits along with for-profit companies.
The rule draws one more line that does real work here. The MLTS definition expressly covers "network and premises based systems, such as Centrex and VoIP." If a county runs a premises-based private branch exchange (PBX) — a phone system living in its own closet — the manager and the operator can be the same IT shop. If it runs a network-based system, which is what the market sells as hosted PBX, cloud PBX, or unified communications as a service (UCaaS), the platform belongs to the provider while the person assigning extension 4412 to Room 300 works for the county. Both sit in the manager-or-operator role and no rule divides it between them.
So stack it up. The room number originates with whoever administers the phone system, under § 9.16. It passes to a VPC or E911 vendor, which may hold covered 911 service provider obligations under § 9.19. It has to arrive, current and validated, in a LIS the OSP answers for under § 9.29(b). Three rules, three functions, and a floor number that has to survive all of it.
What none of the three rules does
None of them connects to the others.
Nothing requires the MLTS operator's vendor and the OSP to be the same entity, and nothing requires them to be different. Nothing requires the location record one holds to reach the LIS the other relies on. Where a single company holds several of these functions, the chain may hold together by accident of corporate structure rather than by obligation, which is a thin thing to rest a floor number on. And no single obligation runs the length of the record from the jack in the wall to the PIDF-LO on the call.
What that looks like in practice
A call comes in. The location arrives correctly formatted, validated, and delivered on time. The OSP did its job. The location is also wrong, because that phone moved from the third floor to the first eight months ago and nothing ever updated the record underneath it.
Section 9.16 does require dispatchable location to be conveyed with the call, so the record is supposed to be right when the call happens. What no rule does is say how it stays right. Nothing sets an update interval, names a synchronization mechanism, or requires the MLTS operator's record to reach the OSP's LIS at all. The duty is to be correct; nothing specifies the plumbing that keeps it correct. So the record goes stale quietly, and validation may not catch it, because a wrong floor inside a real building can still be a perfectly valid civic address.
Then the correction loop breaks in the same seam. The PSAP does exactly what it should and goes back to the OSP, because the OSP is the party that sent the record. But the OSP has no obligation to go back to the MLTS operator or its vendor and get the source corrected, and may have no relationship through which to do it. The complaint lands on the one party that can't fix it.
That's the cost of three rules that don't reference each other. A location can be validly formatted, validly delivered, and compliant at every step, and still send a medic to the wrong floor. Twice.
That's the actual problem. It isn't that nobody is responsible. It's that responsibility is assigned three times, by function, under rules written at different times that don't reference one another.
Standards can't fix this; contracts can
RAY BAUM'S is technology-neutral. It requires dispatchable location; it does not require the i3 standard from the National Emergency Number Association (NENA), the architecture that defines end-state NG9-1-1. The common compliance paths today are Private Switch ALI (PS-ALI), which extends the legacy ALI record down to a phone system's individual extensions, and vendor E911 service. Both were built for the ALI world of case one. Mapping them into an HTTP-Enabled Location Delivery (HELD) and PIDF-LO exchange an OSP can stand behind is real work, and no rule says who pays for it.
The Alliance for Telecommunications Industry Solutions (ATIS) runs the Emergency Services Interconnection Forum (ESIF), which is working the location-consistency piece now and published ATIS-0500048.2026, 9-1-1 Authority Readiness Guidelines for NG9-1-1 Connectivity, jointly with NENA. That work matters. But a standard describes an interface. It doesn't say whose LIS, and it can't bind parties to each other. Only the parties can do that, in contracts.
What an agency can do now
Four things, none of which require waiting on anyone.
Ask which case you're in. Before serving a Phase 2 valid request, find out what each OSP in your jurisdiction does today: provisions to an ALI provider, uses a VPC, or both, and which of them carry MLTS traffic. The three cases carry very different timelines, and the answer tells you where your risk is.
Ask who operates the LIS, and who delivers the call. They may be the same company. They may be the company your large MLTS operators are already paying. If it takes more than one call to find out, that's your finding.
Put chain of custody in the RFP. Name the parties by function: installer, manager or operator, OSP, LIS operator, gateway operator. Some may be one company; the contract still has to say which function it's being held to. Name who validates against the LVF, who holds the record when an extension moves to a different floor, and who is accountable when it doesn't.
Ask what the line item is buying. This work costs money, and the cost will land somewhere in vendor quotes or carrier pricing. The question isn't whether it appears. It's which of the obligations above the money discharges, and whether anyone will stand behind the record it produces.
And remember that validation happens before the call, not during it. The location source checks a civic address against the LVF at provisioning time and corrects the record if it fails. At call time the Emergency Call Routing Function (ECRF), the service that decides which 911 center a call goes to, does the routing. Nobody revalidates mid-call, and the PSAP is not a safety net for a bad record.
The LIS has an owner, and the rule names it. The geographic information system (GIS) data underneath it — the authoritative road, address, and boundary data a 911 Authority maintains — has an owner and a funding source. What has no single owner is the chain between them, and that's where the medic ends up in the wrong stairwell.
If you're anywhere in that chain, I'd like to hear how you're handling it.
Frequently asked questions
Who owns the Location Information Server (LIS) in NG9-1-1?
The originating service provider. Under 47 CFR § 9.29(b), once a 911 Authority serves a Phase 2 valid request, the OSP must install the infrastructure, or acquire the services, needed to use a LIS or its functional equivalent to verify its customer location information and records. The rule has no MLTS qualifier.
Does the OSP have to build its own LIS?
No. Section 9.29(b) lets the OSP either install the infrastructure or acquire all services necessary. Acquiring the service from a vendor doesn't move the obligation; the rule still names the OSP.
Who pays for the LIS?
Under 47 CFR § 9.33(a)(3), originating service providers are responsible for the costs of obtaining and delivering location and routing information using LIS functionalities or other equivalent means at Phase 2.
Who is responsible for the floor or room number on an MLTS call?
Under 47 CFR § 9.16, whoever installs, manages, or operates the multi-line telephone system must see that dispatchable location is conveyed with a 9-1-1 call. No rule requires that record to reach the OSP's LIS, or says how it stays current.
This article is part of the NG9-1-1 location series. Previous: Four Boxes, One Map. For terms used here, see the NG9-1-1 & GIS glossary.
Sources
- 47 CFR § 9.16 — Multi-line telephone systems; dispatchable location requirements
- 47 CFR § 9.19 — Covered 911 service provider definition and reliability certification
- 47 CFR § 9.28 — Next Generation 911 definitions, including originating service provider
- 47 CFR § 9.29 — Next Generation 911 transition requirements
- 47 CFR § 9.31 — Valid requests for delivery of 911 traffic in IP-based formats
- 47 CFR § 9.33 — Cost responsibilities
- FCC, Multi-line Telephone Systems: Kari's Law and RAY BAUM'S Act 911 Direct Dialing, Notification, and Dispatchable Location Requirements (fcc.gov/mlts-911-requirements) and the MLTS compliance FAQ
- FCC 24-78, Facilitating Implementation of Next Generation 911 Services (NG911); Location-Based Routing for Wireless 911 Calls, Report and Order, 89 Fed. Reg. 78066 (Sept. 24, 2024), corrected by 89 Fed. Reg. 83628 (Oct. 17, 2024)
- NENA-STA-010.3, NENA i3 Standard for Next Generation 9-1-1
- NENA-INF-027.1-2018, NENA Information Document for Location Validation Function Consistency
- ATIS-0500048.2026, 9-1-1 Authority Readiness Guidelines for NG9-1-1 Connectivity