PIDF-LO in SIP: location conveyance for internet-based voice E911

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.

PIDF-LO becomes operationally important when it enters the SIP call path. In many internet-based voice E911 designs, location is not just a record in a portal. It is information that must survive the trip from endpoint, phone system, UC platform, or session border controller into an emergency routing service and ultimately toward the 911 answering center.

RFC 6442 describes location conveyance for SIP. The basic idea is that SIP signaling can carry location-by-value, location-by-reference, or related routing indicators. In emergency calling, the question is not only whether the location exists, but whether every hop knows what to do with it.

Location-by-value versus location-by-reference

There are two common patterns.

Location-by-value
Endpoint/session border controller sends the PIDF-LO itself inside the signaling flow.

Location-by-reference
Endpoint/session border controller sends a URI or reference that an authorized recipient can dereference.

A rough comparison:

| Pattern | What moves in signaling | Strength | Risk | | --- | --- | --- | --- | | Location-by-value | The PIDF-LO document | Self-contained; easier to inspect in traces | Larger SIP messages; privacy exposure if mishandled | | Location-by-reference | A location URI/reference | Smaller signaling; location can be controlled centrally | Dereference failures; authorization and availability matter |

For many enterprise teams, location-by-value is easier to reason about during testing because the object can be captured in a SIP trace. Location-by-reference can be cleaner architecturally, but only if every emergency hop can retrieve it quickly and securely.

A SIP E911 location flow

[User dials 911]
       |
       v
[Phone / UC client]
       |
       | obtains location from LIS, app prompt, network map, or provider record
       v
[PIDF-LO created]
       |
       v
[SIP INVITE]
       |  Geolocation header or multipart body
       v
[session border controller / cloud voice platform]
       |  preserve, validate, route, do not strip
       v
[E911 provider]
       |  route based on location and callback number
       v
[Emergency network / 911 answering center]

The most important box in that diagram may be the session border controller. session border controllers are excellent at protecting and normalizing SIP, which also means they can accidentally remove, rewrite, or hide emergency location data.

What to check in the SIP trace

When testing, capture the actual emergency test call path if your provider supports it. Look for:

The emergency dialed number pattern.
The selected route or trunk.
The SIP Geolocation header if used.
The Geolocation-Routing behavior if present.
Multipart bodies that include PIDF-LO XML.
Content-Type boundaries and MIME correctness.
Whether the PIDF-LO is preserved across the session border controller.
Whether the emergency routing provider acknowledges the location used.

A trace review checklist:

Does the INVITE contain emergency location?       yes/no
Does the session border controller preserve the Geolocation header?     yes/no
Does the carrier/provider accept the body type?   yes/no
Does the provider route by that location?         yes/no
Does callback match the tested user/device?       yes/no
Does the 911 answering center/test center report expected data?   yes/no

Why normal SIP success proves almost nothing

A SIP voice trunk can pass ordinary calls all day and still fail E911. Emergency calls use special policy, special dial strings, special caller ID behavior, and sometimes special location conveyance. Normal call completion does not prove any of that.

Danger signs:

911 rides a default outbound route.
Emergency calls fail over to a trunk that has no E911 configuration.
The session border controller strips unknown headers by policy.
The carrier accepts the call but ignores the PIDF-LO.
Caller ID masking hides the emergency callback number.
A test confirms “call completed” but not location delivered.

session border controller design principles for PIDF-LO

For E911, session border controller policy should be boring, explicit, and documented.

Recommended controls:

Preserve emergency location headers and bodies for approved emergency routes.
Use explicit emergency dial-plan handling instead of broad local route matches.
Keep emergency caller ID behavior separate from marketing or privacy caller ID rules.
Document which trunks support PIDF-LO and which rely on registered address records.
Test failover trunks, not just primary trunks.
Keep a known-good SIP trace for each major architecture pattern.

Where providers differ

Providers may consume PIDF-LO differently. Some route from dynamic location data. Some validate location records before calls. Some use registered addresses tied to telephone numbers. Some support both dynamic and static models. Some expose test-call responses; others require support tickets or scheduled testing.

Ask providers:

Do you accept PIDF-LO by value over SIP?
Do you support location-by-reference?
Which SIP headers and MIME bodies must be preserved?
What happens if PIDF-LO is malformed or missing?
Can we run 933 or equivalent test calls?
What exact location did your platform use for routing?
Can we export test evidence?

Commentary

SIP location conveyance is where E911 stops being a compliance slide and becomes network engineering. The protocol may be standardized, but the route is still built by humans: UC admins, session border controller engineers, carriers, providers, security teams, and facilities records.

That is why the best E911 teams keep traces. Not because everyone wants to read XML for fun. Nobody sane wants that. They keep traces because a trace turns “we think location was sent” into “this is what crossed the boundary.” In an emergency system, boundaries are where assumptions go to die.

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.