VoIP.info Diagnostic

Asterisk PJSIP 424 Bad Location Information: trace the rejected location

Follow the rejected Geolocation value through Asterisk profiles, PIDF-LO or URI handling and the peer's error code before changing emergency policy.

Reviewed 2026-09-28RFC 6442 and current Asterisk geolocation, res_pjsip and debugging documentation reviewed September 28, 2026; no PBX, endpoint, provider, profile, PIDF-LO body, dereference, emergency route or live call testedAdvancedDocumentation based · not lab tested

Bind the 424 to one request and PJSIP leg

Record the timestamp and timezone, user-visible symptom, Request-URI, endpoint or trunk, Call-ID, CSeq, top Via branch, Geolocation and Geolocation-Routing fields, every referenced MIME part, the responding element and the complete Geolocation-Error value. Determine whether Asterisk generated the response for an inbound request or received it on an outbound leg. Do not assign an emergency-routing failure to Asterisk, a carrier or an endpoint from a display label alone.

With authorization, use pjsip set logger on for one bounded reproduction, then disable it and protect identities, numbers, credentials and location bodies. Asterisk can terminate one SIP leg and originate another, so correlate channels without assuming the same location representation crossed the back-to-back user-agent boundary unchanged.

Identify the active location source and profile

Asterisk documents four possible location sources: the incoming INVITE, a caller endpoint profile, the dialplan and a callee endpoint profile. It cannot automatically merge conflicting locations or infer precedence. Inspect the loaded endpoint and its geoloc_incoming_call_profile or geoloc_outgoing_call_profile, then identify any dialplan function that adds, deletes or changes location.

Treat generated configuration ownership separately from runtime state. In FreePBX or another management layer, retain GUI and module ownership rather than making an undocumented durable edit to generated PJSIP files. Match the current Asterisk release to the option documentation before changing a profile.

Trace PIDF-LO by value or URI by reference

For a by-value location, match the Geolocation CID to the exact PIDF-LO MIME part and preserve its Content-Type and Content-ID. Check syntax and the peer's stated suitability requirement without guessing a civic element. For a by-reference location, preserve the URI and dereference result. Asterisk documentation says incoming location URIs are not retrieved automatically; the dialplan author must retrieve and process them.

Outgoing profiles can add location, but scope them to the intended call path. The Asterisk documentation specifically warns that applying location indiscriminately can leak it on ordinary calls. Do not copy an emergency location into every trunk request or broaden retransmission or routing permissions merely to remove 424.

Use Geolocation-Error to choose the repair owner

Separate 1xx processing or quality errors from 2xx permission errors and 3xx dereference failures. Preserve the exact numeric code and optional text. Code 201 concerns retransmission permission and 202 permission to route using the location; neither proves that the civic data itself is malformed. Code 300 points to dereferencing, not automatically to the address encoded behind the URI.

If the response contains corrective location information, retain it without allowing an intermediary to rewrite the Geolocation, Geolocation-Error or PIDF-LO body. A 424 without Geolocation-Error, a rejection when no Geolocation header was present, or a rejection despite another usable locationValue remains interoperability evidence for the peer.

Correct narrowly and verify without a live emergency call

Correct only the demonstrated owner: malformed or unsuitable PIDF-LO, a broken or unreachable location URI, the wrong active Asterisk profile, a dialplan transformation, or an explicit permission mismatch. Preserve the previous profile, body or policy and a rollback trigger. Avoid repeated automatic 424 retries because they can expose progressively more location.

Use the carrier or emergency-services provider's current approved non-emergency validation process, which may be account- and jurisdiction-specific. Confirm the exact outbound request, final response and provider-approved location readback where available; do not place an uncoordinated live emergency call. No PBX, endpoint, provider, profile, PIDF-LO body, URI dereference, emergency route or live call was tested for this guide.

Asterisk CLI — bounded 424 evidence
module show like geolocation
pjsip show endpoint <endpoint>
pjsip set logger on
# Reproduce one authorized non-emergency validation request and capture location fields and 424.
pjsip set logger off

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.