SIP 404
SIP 404 Not Found in Asterisk
A 404 is the far end saying it has never heard of the number you dialled. Since you almost certainly dialled a number that exists, the interesting question is what your PBX actually sent, which is rarely exactly what the user typed.
What it looks like in the log
[2026-08-17 10:22:08] VERBOSE[7781][C-000004a2] res_pjsip_logger.c: <--- Received SIP response (640 bytes) --->
SIP/2.0 404 Not Found
To: <sip:0012025550143@sip.provider.net>;tag=as3f19b2
CSeq: 102 INVITEWhat it means
Between the user pressing dial and the INVITE leaving the box, the number passes through pattern matching, one or more Set() calls, possibly a prefix strip and an outbound caller ID rewrite. Any of those can produce a technically valid number that the carrier does not route.
The far end is not being unhelpful here. It genuinely has no entry for the string it received, and the string it received is printed in the To header of the request Asterisk sent - which is the single most useful line in the whole trace.
Most common causes
-
01E.164 versus national formatting
The carrier wants
+12025550143and the dialplan sent0012025550143or2025550143. All three describe the same phone. Only one of them routes. -
02A dial prefix that was never stripped
Sites that dial 9 for an outside line frequently leave the 9 in the string on one route while stripping it on another. The route that works masks the one that does not until someone dials the wrong pattern.
-
03A DID not provisioned on the far end
On inbound calls, a number the carrier delivers that has no matching extension in your dialplan produces the same 404 in the other direction. The carrier sees your PBX reject a number they were told to send.
-
04A misdialled or transposed number
Worth ruling out first when the 404 affects one call rather than every call on the route, because it costs nothing to check and it is often the answer.
-
05A trunk that routes only a subset of destinations
International, premium-rate and short-code destinations are commonly barred at the carrier and expressed as 404 rather than 403, which makes a policy decision look like a routing fault.
How to tell which one it is
Read the request URI and the To header on the INVITE Asterisk transmitted, not the number the user reported dialling. Compare that string against the format the carrier documents. In the majority of these cases the difference is visible immediately: a leading zero, a missing plus, a country code applied twice.
Then check whether the same destination routes from a different trunk. A number that works on one carrier and 404s on another is a provisioning question for the second carrier, not a dialplan bug.
How to fix it
-
Normalise to E.164 before the trunk
Convert to a single canonical format early in the dialplan and let the trunk-specific context adapt from there. Doing the conversion once removes the class of bug where two routes disagree about the format.
-
Strip the outside-line prefix in one place
If a 9 or 0 prefix is in use, remove it in the pattern match rather than in each route, so a new route cannot forget to do it. On FreePBX, prefix stripping and number rewriting live in the outbound route's dial patterns - check every route that can match the number, not just the first.
-
Confirm the DID is provisioned
For inbound 404s, check the number is both purchased and pointed at your trunk on the carrier portal - buying a DID and routing it are separate steps and the second is easy to skip.
-
Check for destination barring
If the 404 only affects international or premium destinations, ask the carrier whether the account is permitted to reach them before rewriting any dialplan.