Read 424 as rejection of supplied location information
RFC 6442 defines 424 Bad Location Information for a request whose location contents are malformed or unsuitable, or whose location-by-reference URI cannot be dereferenced. Preserve the exact request, responder, Call-ID, CSeq, top Via branch, Geolocation and Geolocation-Routing fields, body Content-Type and Content-ID, response and timestamp on one signaling leg. The 424 response must contain Geolocation-Error.
Do not use 424 as a generic routing, address, caller-ID, authorization or media failure. A recipient must not send 424 merely because the request omitted Geolocation altogether. If an intermediary inserted the rejected value, that intermediary owns the corrective action rather than silently shifting it to the original sender.
Keep by-value and by-reference evidence distinct
A location by value is carried as a CID reference to a PIDF-LO body; a location by reference is carried as a URI the recipient dereferences. Preserve the exact locationValue, matching MIME part, Content-ID, URI scheme and dereference result. If several locationValues were supplied and at least one is usable, RFC 6442 treats the location as good and does not permit Geolocation-Error for the request.
Asterisk currently supports PIDF-LO location by value in INVITE handling, but its documentation says it does not retrieve an incoming location-by-reference URI automatically. A dialplan that accepts such a URI must own retrieval and processing. Do not convert a failed dereference into a civic-address rewrite without first proving which representation and owner failed.
Interpret the registered error code before its prose
Geolocation-Error carries exactly one location error value. RFC 6442 groups processing and quality errors under 1xx, permission failures under 2xx and dereference failures under 3xx. Code 100 is a general cannot-process-location failure, 200 a general permission failure, 201 denies retransmission, 202 denies routing based on the location and 300 covers a failed location URI dereference. Preserve any human-readable text, but use the registered numeric meaning as the stable diagnostic boundary.
A successful response can still carry Geolocation-Error when the call is accepted despite unusable location. A 424 is appropriate only when the recipient cannot accept the request without suitable location or is returning corrective location information. Do not treat absence of 424 as proof that location was valid.
Preserve corrective, privacy and dialog boundaries
A 424 can carry corrective location information. A forwarding intermediary is not allowed to alter Geolocation, Geolocation-Error or the PIDF-LO body in that response. Repeated rejections can solicit progressively more precise location, so RFC 6442 recommends limiting related rejections; do not automate unbounded retries or broaden location permissions to clear the status.
The response completes this transaction but must not terminate an existing dialog. Correct only the demonstrated malformed value, unavailable URI or denied permission, then use the provider's approved non-emergency validation process. Do not place an uncoordinated emergency call to test the repair. The Asterisk PJSIP investigation follows configuration and wire evidence without representing a deployed emergency route as validated.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IETF RFC 6442: Location Conveyance for SIP ↗
- IANA SIP response-code registry ↗
- Asterisk geolocation overview ↗
- Asterisk geolocation URI handling ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.