Find the system that emitted the 404
Capture one failed INVITE exchange and preserve the timestamp, Call-ID, request URI, route, response direction and responding address. SIP 404 says that the recipient handling the addressed domain did not find the resource. It does not say whether Asterisk, an SBC or a remote carrier made that decision. Follow both call legs when Asterisk originated another INVITE.
A locally generated response and a 404 received from a next hop need different repairs. Do not change an inbound route solely because a phone display shows 404, and do not treat the status code as proof that a number is unassigned.
Verify identification before the dialplan
For an inbound request, confirm that Asterisk associated the INVITE with the intended PJSIP endpoint. An unidentified trunk is rejected before its intended dialplan path; use the endpoint-identification investigation for that boundary.
Once the endpoint is known, record its loaded context, the requested extension and the NOTICE or trace for the same call. Asterisk's troubleshooting guide shows that an extension-not-found notice identifies the endpoint, requested extension and searched context. Registration success by itself does not prove any of those values are correct.
Inspect the exact loaded context and digits
Compare the Request-URI user and the extension Asterisk actually searches after any inbound normalization. Run dialplan show <context> for the endpoint's loaded context. Asterisk searches explicit extensions, pattern matches, included contexts and switches in that order; inspect the complete path instead of only the source file you expected to load.
In a FreePBX-managed system, compare the delivered DID with the supported inbound route and Apply Config state. Do not edit generated dialplan files. Avoid a permissive catch-all added only to hide the 404: it can broaden toll or destination access while leaving the intended mapping unresolved.
Check registration contact routing separately
When inbound delivery follows an outbound registration, compare the registration object's effective contact_user with the extension the incoming request reaches. Asterisk documents that contact_user controls the Contact URI user and can determine the dialplan extension for incoming calls. The outbound registration and endpoint remain separate objects.
Changing authentication, AOR qualification or retry timing does not create a missing dialplan extension. Keep those controls separate unless the same trace demonstrates another failure.
If the next hop returned the 404
When Asterisk sent an outbound INVITE and received 404, preserve the outbound request URI, destination domain, selected endpoint and response source. Compare the number format, domain and account routing scope with the remote service's documented requirements. A correct local inbound context cannot repair a rejection returned on the outbound leg.
If an SBC or proxy sits between the systems, use the Via and route evidence to identify the responding hop. Ask the remote service for the matching transaction before assuming the final public number is absent or rerouting the call through an unrelated trunk.
Prove the narrow correction
Make one controlled change, then repeat the intended number plus a nearby valid and invalid destination. Confirm the expected endpoint, context, extension, next hop and final result without weakening unrelated routes. Remove temporary PJSIP logging and redact credentials, addresses and personal calling data from shared extracts.
Restore the prior route or object if the intended call still fails or another destination begins to match. No PBX, carrier, proxy, number, route or live-call behavior was tested for this guide.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IETF RFC 3261: request targets and SIP 404 ↗
- Asterisk PJSIP troubleshooting: extension not found in context ↗
- Asterisk dialplan contexts, extensions and search order ↗
- Asterisk outbound registrations and contact_user ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.