Plain-English terms used in this guide

Before getting deep into E911, here are the few terms worth knowing. We keep them practical because most readers are managing a building, phone system, safety program, or vendor migration, not studying telecom law.

  • 911 answering center: the local emergency communications center that answers a 911 call and sends police, fire, or medical responders. Technical documents often call this a 911 answering center, but we use “911 answering center” wherever possible.
  • Business phone system: the office, hotel, school, factory, warehouse, retail, healthcare, or campus phone environment that lets multiple people call out. Regulations sometimes call this an business phone system, or multi-line telephone system.
  • Dispatchable location: the address plus the inside details responders need, such as building, floor, suite, room, warehouse dock, store entrance, classroom, hotel room, factory zone, or security desk.
  • Emergency callback number: the number the 911 answering center can call back if the emergency call drops.
  • Emergency-routing provider: the carrier or specialist service that helps get the call and location record to the right 911 answering center.

HELD and PIDF-LO are often mentioned together because they solve adjacent problems. HELD is a protocol for obtaining location information from a Location Information Server. PIDF-LO is a format for representing that location information. In an enterprise E911 program, HELD can help a device or client discover where it is, and PIDF-LO can package that location for routing or conveyance.

The practical question is simple: when a user dials 911, how does the phone system know where that user is?

The roles

LIS  = Location Information Server
HELD = HTTP-Enabled Location Delivery
PIDF-LO = XML location object
SIP  = Signaling path that may carry or reference location
911 answering center = Public safety answering point

The flow:

Endpoint / UC client
        |
        | HELD request
        v
Location Information Server
        |
        | location response
        v
PIDF-LO civic/geodetic object
        |
        v
Emergency call routing path
        |
        v
911 answering center or test center

What the LIS actually does

A Location Information Server is only as good as the evidence feeding it. In a corporate building, that evidence may include:

  • Switch and port mapping.
  • Wireless access point BSSID mapping.
  • IP subnet mapping.
  • LLDP-MED data.
  • Manually assigned user or device locations.
  • Validated civic addresses.
  • Floor plans, suites, rooms, zones, docks, entrances, or security desks.

A LIS does not magically know the building. Someone has to maintain the data.

HELD request/response thinking

A simplified HELD exchange looks like this:

Client: I am on this network. Give me my location.
LIS: I recognize your network attachment. Here is your location.
Client/voice platform: I will use that location for emergency calling.

That exchange can produce location-by-value or a location reference, depending on implementation and policy. In E911 terms, either path must be tested end to end.

Dynamic location is a governance problem

Dynamic location sounds automatic. It is not fully automatic. It depends on maintained network data.

If a network team moves an access point without updating the LIS, a softphone can receive the wrong location. If a subnet is reused in another building, devices can inherit stale location. If a switch replacement changes identifiers, port-based mapping may stop working. If facilities renames rooms without telling telecom, the location can be technically valid and operationally confusing.

The control loop should look like this:

Facilities change
       |
       v
Network change ticket
       |
       v
LIS / location database update
       |
       v
Provider validation
       |
       v
Emergency test
       |
       v
Evidence retained

HELD versus manual address entry

Remote workers often cannot rely on a corporate LIS. They may need a manual or application-level location workflow.

| Scenario | Likely source | E911 risk | | --- | --- | --- | | Desk phone on mapped switch port | LIS/network map | Stale port or switch data | | Softphone on corporate Wi-Fi | LIS/WAP map | Moved AP or ambiguous coverage | | VPN user at home | Manual/app prompt | User ignores prompt or enters bad address | | Coworking space | Manual/app prompt | Address lacks suite/floor/detail | | Hotel | Manual/app prompt | Room and front-desk workflow missing | | Mobile client | Carrier/handset/platform | Enterprise may not control final data path |

What to test

A HELD/PIDF-LO test should validate the full chain, not only whether the client received something.

Test cases:

  • Desk phone on known switch port.
  • Softphone on known corporate Wi-Fi.
  • Softphone on unknown guest Wi-Fi.
  • VPN user at home.
  • User moving between floors.
  • Access point moved but not updated.
  • Subnet reused or split.
  • New office before final floor labels.
  • session border controller failover during emergency route.

For each case, capture:

  • Location source.
  • Timestamp.
  • Civic address.
  • Floor/suite/room/zone.
  • PIDF-LO or provider location object.
  • Route selected.
  • Test result.

Commentary

HELD and PIDF-LO make dynamic E911 possible, but they do not remove ownership. They simply move the failure point from “somebody forgot to update a spreadsheet” to “somebody forgot to update the system that replaced the spreadsheet.” That is progress, but only if the new system has controls.

The best enterprise designs are boring in the right places: predictable naming, tight network-change triggers, validation before go-live, and test evidence after change. The protocol is clever. The operating model should be dull enough to trust.

What this means for real enterprise locations

E911 is easiest to understand when you walk the building. A caller is not a phone number on a spreadsheet. They are a person somewhere inside an office, plant, warehouse, store, clinic, hotel, school, public venue, or remote workspace.

For enterprise planning, ask what a dispatcher and responder would actually need:

  • Office floors: floor, suite, reception desk, conference rooms, shared phones, and after-hours access.
  • Factories and industrial sites: production line, machine area, gate, shift office, hazardous-material area, first-aid room, and responder entrance.
  • Warehouses and logistics sites: dock, bay, aisle range, mezzanine, yard gate, security post, and fire alarm zone.
  • Retail and public spaces: tenant name, mall level, entrance, back office, pharmacy, stockroom, food court, and security desk.
  • Hotels, dorms, and housing: tower, floor, room, front desk alerting, elevator/stair access, and guest callback process.
  • Healthcare and clinics: building, wing, unit, treatment room, nurses station, controlled access, and security notification.
  • Remote and hybrid workers: a simple way to keep home-office or temporary-work locations current before an emergency call.

The practical standard is simple: if responders would arrive at the street address and still need to search, the location record is probably too vague.

Sources and references