pjsip
"Rejected because extension not found in context" in Asterisk
An INVITE arrived, Asterisk looked up the dialled number in the context assigned to that endpoint, and found no extension matching it. The call was rejected before a channel ever existed - and the line prints all three facts you need: who called, what they dialled, and where Asterisk looked.
What it looks like in the log
[2026-08-17 07:44:31] NOTICE[1893] res_pjsip_session.c: Call from 'trunk-main' (UDP:203.0.113.40:5060) to extension '12025550166' rejected because extension not found in context 'from-trunk'.What it means
Every endpoint has a context, and every inbound call is looked up in it. This NOTICE means the lookup found nothing: the number the carrier sent, in the exact format they sent it, matched no extension and no pattern in that context.
It is the inbound cousin of "Cannot find extension" - that one fires when your own dialplan jumps somewhere missing mid-call; this one fires before the call starts at all. The caller typically hears a fast busy or a carrier announcement, and nothing beyond this line appears in your log because no channel was created.
Most common causes
-
01A DID format mismatch
The most common cause. The carrier delivers
+12025550166and the dialplan matches2025550166, or the reverse. Same number, different string, no match. The format in the NOTICE is the format to match - not the format on the carrier's portal. -
02A missing or wrong inbound route
On FreePBX, an inbound route's DID must match what the carrier actually sends. A deleted catch-all route, or a DID typed in a different format than delivered, produces exactly this rejection.
-
03The trunk pointed at the wrong context
An endpoint whose
context=names an internal or empty context sends every inbound call into a lookup that can never succeed. -
04Scanners dialling through your box
INVITEs from unknown addresses trying international numbers are toll-fraud probes hitting a context that (correctly) refuses them. Rejections of numbers nobody should be dialling, from IPs you do not recognise, are the system working.
-
05A new DID never added to the dialplan
A number recently purchased and pointed at the trunk arrives and matches nothing because nothing was ever configured for it. The carrier did their half; yours is missing.
How to tell which one it is
Read the extension exactly as printed in the NOTICE - leading plus, country code, everything - and search the named context for a pattern that matches that literal string. Testing the number you think is arriving instead of the one in the log is how this stays unfixed for an afternoon.
Then check the source. A rejection of your own DID from your carrier's IP is a routing bug. A rejection of a premium-rate international number from an unknown IP is an attack being correctly refused, and needs a firewall, not a dialplan edit.
How to fix it
-
Match the DID in the format the carrier sends it
Add the extension or pattern for the literal string in the NOTICE, or normalise inbound numbers at the top of the context so one format works for every route.
-
Fix the inbound route on FreePBX
Create or correct the inbound route whose DID equals what the carrier delivers. A temporary any/any catch-all route confirms the trunk works while you get the DID format right.
-
Point the trunk at the intended context
Check the endpoint's
context=names the context that actually holds your inbound routing. -
Leave fraud probes rejected
Do not widen a context to make unknown-source rejections disappear. Restrict who can reach the box instead.