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.

When an E911 test fails, PIDF-LO is often one of the places people point first. Sometimes the location object is wrong. Sometimes the object is fine but the SIP path strips it. Sometimes the provider ignores it. Sometimes the 911 answering center receives a different location than the enterprise expected.

This checklist is written for voice engineers, UC admins, network teams, and E911 program owners who need to isolate the failure without turning the incident bridge into XML karaoke.

Start with the symptom

Classify the failure before changing anything.

Symptom observed
   |
   +-- wrong 911 answering center reached
   +-- correct 911 answering center, wrong location
   +-- correct location, wrong callback
   +-- no location presented
   +-- provider rejects address
   +-- emergency call fails entirely

Each symptom points to a different part of the chain.

Step 1: Confirm the caller context

Collect the basics:

  • User or device.
  • Physical location at test time.
  • Calling platform.
  • Client type: desk phone, softphone, mobile app, common-area phone.
  • Network attachment: switch/port, Wi-Fi AP, subnet, VPN, home network.
  • Dialed digits.
  • Caller ID or emergency callback number.
  • Expected 911 answering center or test center.

Do not skip this. Many “protocol” problems are actually test-scope problems.

Step 2: Check the source location

Ask where the location came from:

Device location source
   |
   +-- LIS / HELD
   +-- Teams or UC location database
   +-- provider portal record
   +-- phone number-to-address record
   +-- user-entered remote address
   +-- wireless / handset-derived location
   +-- unknown fallback

Then compare expected versus actual:

| Field | Expected | Actual | Risk | | --- | --- | --- | --- | | Street address | Site address | Delivered address | Wrong city/county can route wrong 911 answering center | | Floor | Floor 3 | Blank | Responders may search | | Suite/room | Suite 310 | Main office | Too vague for large sites | | Callback | Direct callback | Auto attendant | 911 answering center may not reach caller | | Method | LIS/Wiremap | Manual stale address | Confidence problem |

Step 3: Inspect the PIDF-LO

If you can obtain the PIDF-LO or provider-exported object, inspect these areas:

  • Is there exactly one clear location for the caller?
  • Are civic fields populated correctly?
  • Is floor/suite/room/zone present where needed?
  • Are geodetic coordinates consistent with the civic address?
  • Is method present and believable?
  • Is timestamp current?
  • Do usage rules allow emergency handling?
  • Is the XML well formed?

A simple review flow:

PIDF-LO exists? ---- no ----> find why location was not generated
     |
    yes
     |
     v
Civic fields correct? ---- no ----> fix address/source record
     |
    yes
     |
     v
Interior detail enough? ---- no ----> add dispatchable detail
     |
    yes
     |
     v
SIP path preserves it? ---- no ----> fix session border controller/carrier route
     |
    yes
     |
     v
Provider routes by it? ---- no ----> provider ticket/test evidence

Step 4: Check the SIP path

If PIDF-LO starts correct but disappears, the problem is often signaling.

Check:

  • Does the SIP INVITE contain a Geolocation header or PIDF-LO body?
  • Does the session border controller preserve it toward the emergency route?
  • Does normalization remove unknown headers?
  • Does the trunk support multipart bodies?
  • Does failover use a different policy?
  • Does TLS/SIP inspection tooling show the same thing at each hop?
  • Does the provider confirm the object was received?

Step 5: Compare provider result and 911 answering center result

The provider may show one thing while the 911 answering center or test center reports another. That gap is gold. It tells you where to look.

Enterprise expects:     Building B, Floor 4, Suite 410
Provider portal shows:  Building B, Floor 4, Suite 410
Test center reports:    Main address only

Likely issue: provider-to-emergency-network delivery, route type, 911 location database/display limitation, or test script mismatch.

Another example:

Enterprise expects:     Chicago office
PIDF-LO shows:          Chicago office
Provider routes:        Dallas 911 answering center/test center

Likely issue: routing key, callback number association, stale phone number record, or provider route override.

Step 6: Create the fix record

Every failure should end with a clean record:

  • What failed.
  • Root cause.
  • Affected users/sites/devices.
  • Temporary risk control.
  • Owner.
  • Fix date.
  • Retest result.
  • Evidence file location.

Commentary

The fastest E911 troubleshooting teams do not start by arguing about standards. They start by drawing the path. Where did location come from? What object was created? What did the SIP path carry? What did the provider consume? What did the 911 answering center see?

That path turns a scary emergency-calling issue into a sequence of testable claims. It also protects the team from the most expensive phrase in operations: “we assumed.”

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