Fixing ‘Extension s Rejected Because Extension Not Found’ on Inbound Calls

Inbound calls fail. The CLI shows:

chan_sip.c:15147 handle_request_invite: Call from 'myprovider' to extension 's'
rejected because extension not found in context 'trunkinbound'

The s is the clue. It means Asterisk received an INVITE with no usable dialled number and fell back to the start extension. This post explains why that happens and how to fix it properly rather than papering over it.

What s Actually Means

In Asterisk, s is the “start” extension — the destination used when a call enters a context without a specific target. It is normal for analogue FXO lines, where there is no digit information to work with.

On a SIP trunk it means one of three things:

1. The carrier is sending an INVITE whose request URI contains no DID
2. The DID is present but somewhere other than where Asterisk looks
3. Your inbound context has no pattern matching the format the carrier sends

VICIdial’s trunkinbound context normally contains:

[trunkinbound]
exten => _X.,1,AGI(agi-DID_route.agi)
exten => _X.,n,Hangup()

_X. requires at least one digit. s is a letter, so it does not match, and the call is rejected.

Step 1: Look at the Actual INVITE

Do not guess. Capture it.

asterisk -rvvvvv

sip set debug peer myprovider

For PJSIP:

pjsip set logger on

Place a test call and read the first lines of the INVITE:

INVITE sip:@203.0.113.10 SIP/2.0
To: <sip:@203.0.113.10>
From: "Caller" <sip:15559876543@sip.provider.com>;tag=as1b2c3d4

An empty user part before the @ confirms the carrier is sending no DID in the request URI. Now check whether it appears anywhere else — some providers put it in To:, some in a custom header like X-DID or Diversion.

Turn debug off when you are done:

sip set debug off

Fix 1: Ask the Carrier (Correct Answer)

If the provider sends no DID, the right fix is on their side. Ask them to send the DID in the request URI. Most can enable this; it is often a checkbox on the trunk configuration in their portal.

Phrase it precisely: “Please send the called number in the SIP request URI user part, in national format.” Vague requests get vague responses.

This is worth pursuing first, because everything below is a workaround that becomes fragile the moment you add a second DID.

Fix 2: Pattern Mismatch, Not a Missing DID

Sometimes the DID is there and your context simply does not match it.

[trunkinbound]
exten => _+X.,1,Goto(trunkinbound,${EXTEN:1},1)
exten => _X.,1,AGI(agi-DID_route.agi)
exten => _X.,n,Hangup()

exten => _00X.,1,Goto(trunkinbound,${EXTEN:2},1)

Verify what loaded:

asterisk -rx "dialplan show trunkinbound"

Fix 3: Extract the DID From a Header

If the DID exists in To: but not in the request URI, pull it out.

For chan_sip:

[trunkinbound]
exten => s,1,NoOp(Extracting DID from To header)
exten => s,n,Set(TOHDR=${SIP_HEADER(To)})
exten => s,n,Set(TMP=${CUT(TOHDR,@,1)})
exten => s,n,Set(DID=${CUT(TMP,:,2)})
exten => s,n,Set(DID=${FILTER(0-9,${DID})})
exten => s,n,NoOp(Resolved DID: ${DID})
exten => s,n,GotoIf($["${DID}" = ""]?fallback,1)
exten => s,n,Goto(trunkinbound,${DID},1)

exten => fallback,1,NoOp(No DID found, routing to default)
exten => fallback,n,Goto(trunkinbound,15551234567,1)

exten => _X.,1,AGI(agi-DID_route.agi)
exten => _X.,n,Hangup()

FILTER(0-9,...) strips anything that is not a digit, which handles the + and any stray characters in one step.

For PJSIP, swap the header function:

exten => s,n,Set(TOHDR=${PJSIP_HEADER(read,To)})

If the carrier uses a custom header:

exten => s,n,Set(DID=${SIP_HEADER(X-DID)})

Ask them which header. Guessing wastes time.

Fix 4: Route s Directly (Last Resort)

If there is genuinely only ever one DID on the trunk — a single inbound number, no plans to add more — you can send s straight to the AGI:

[trunkinbound]
exten => s,1,AGI(agi-DID_route.agi)
exten => s,n,Hangup()
exten => _X.,1,AGI(agi-DID_route.agi)
exten => _X.,n,Hangup()

The AGI will not find a matching DID pattern and will fall through to the default DID entry in VICIdial. So this only works if you have configured that default sensibly.

• DID Route: IN_GROUP
• In-Group: your inbound group

Understand the trade-off before choosing this. Every inbound call on that trunk lands in the same place regardless of which number was dialled. Add a second DID later and you will be back here.

Where to Put These Changes

VICIdial rewrites extensions-vicidial.conf from the database, so hand edits there are lost. Put custom inbound logic in /etc/asterisk/extensions.conf instead, which VICIdial leaves alone:

#include extensions-vicidial.conf

[trunkinbound]
exten => s,1,Set(TOHDR=${SIP_HEADER(To)})
; ... rest of your logic

Be careful not to define trunkinbound in both files with conflicting priority 1 entries. Check what is actually live:

asterisk -rx "dialplan show trunkinbound"

Verifying

After any change:

asterisk -rx "dialplan reload"

Then place a test call with the CLI open. You want to see the AGI execute and the call reach an in-group:

-- Executing [15551234567@trunkinbound:1] AGI("SIP/myprovider-0000001a", "agi-DID_route.agi")

If the AGI runs but the call still drops, the problem has moved downstream — check that the in-group exists, the campaign has Allow Inbound and Blended: Y, and at least one agent is logged in with that in-group selected.

Related Failure Worth Knowing

A near-identical message naming a different context:

rejected because extension not found in context 'default'

That means your carrier’s Account Entry has context=default instead of context=trunkinbound. Inbound calls are hitting the outbound dialplan. Fix it in the carrier entry, not the dialplan.

Summary

Capture the INVITE before changing anything. If the DID is genuinely absent, get the carrier to send it. If it is present in a header, extract it. Routing s straight through works but locks you to a single inbound number, so treat it as the option of last resort rather than the first thing you try.