Home / server / Questions / 319316
Accepted
Sam Hanes
Asked: 2011-10-07 20:17:53 +0800 CST

Asterisk - inbound calls from SIP DID trunk "rejected because extension not found"

  • 772

I have a DID with DIDforSale that's pointed at my Asterisk server. When I call it from my landline phone I get the AT&T disconnected line recording. The Asterisk CLI shows the error message:

[Oct  6 17:03:00] NOTICE[10563]: chan_sip.c:20163 handle_request_invite: Call from 'didforsale_1' to extension '###########' rejected because extension not found.

The "from" part indicates it's correctly matching the sip.conf peer entry. The "to" part shows that the peer is correctly sending the DID number as the target extension. The DID number is a valid extension in the peer's incoming context (details below) so I can only assume that Asterisk is looking in the wrong context.

Configuration

I'm using Asterisk 1.6.2.5-0ubuntu1.4 installed via Apt on a physical server running Ubuntu Server 10.04 (lucid). I have the trunk configured in sip.conf with one peer per originating IP (there are two). These are the relevant stanzas:

[didforsale_base](!)
    type=peer
    context=from-did
    nat=no
    insecure=port,invite

    ; configure codecs
    disallow=all
    allow=ulaw
    allow=alaw
    allow=g729
    dtmfmode=rfc2833

[didforsale_1](didforsale_base)
    host=AAA.AAA.AAA.AAA

[didforsale_2](didforsale_base)
    host=BBB.BBB.BBB.BBB

The peers are configured to send calls to the from-did context, which contains an extension per DID number. The context is configured in extensions.ael like this:

// starting context for calls originating from DID trunks
// the call is matched on the DID number and routed appropriately
context from-did {
    // test DID from DIDforSale
    ########### => jump s@inbound;
}

Debug Output

With core set verbose 5, core set debug 5, and sip set debug on the only additional CLI output besides the SIP packet dumps is:

  == Using SIP RTP CoS mark 5
Sending to AAA.AAA.AAA.AAA : 5060 (no NAT)
Using INVITE request as basis request - [email protected]
Found peer 'didforsale_1' for '+###########' from AAA.AAA.AAA.AAA:5060
Found RTP audio format 18
Found RTP audio format 0
Found RTP audio format 101
Found audio description format G729 for ID 18
Found audio description format PCMU for ID 0
Found audio description format telephone-event for ID 101
Capabilities: us - 0x10c (ulaw|alaw|g729), peer - audio=0x104 (ulaw|g729)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0x104 (ulaw|g729)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
Peer audio RTP is at port CCC.CCC.CCC.CCC:5432

Prior Troubleshooting

I've verified with sip show peer didforsale_1 that the peers are using the correct context. dialplan show from-did indicates that the context parsed correctly. If I include it in the default context for my desk phone calling the DID number gives me the IVR menu as expected.

I read the first several pages of Google results for a few sets of search terms around the error message but didn't find anything useful. It's mostly people using FreePBX or a similar product needing help setting up the equivalent of my from-did context in the GUI. A few posts look like they could be the same problem I'm having, but none of them have answers. I would post links but my reputation is too low. Once it's high enough I'll edit to add them.

asterisk voip sip

2 Answers

  1. Best Answer

    I ended up reading the source for the handle_request_invite function from chan_sip.c mentioned in the error message. That function calls get_destination (in the same file) to resolve the destination address. If get_destination returns an error it produces the error message I was seeing.

    The domain of the URI in the incoming SIP INVITE request from the DID provider is set to the IP address of my PBX, not its domain. I had allowexternaldomains disabled in sip.conf and my IP wasn't in the domain list so the destination address was being rejected. Looking at the source for get_destination it looks like that should produce an error message at debug level 1 before returning the error, but for some reason I'm not seeing it.

    Adding my IP address to the domain list seems to have fixed the issue.

    • 1

  2. The thing I see at the moment with the numbers hidden is the difference between the numbers and the numbers with the + prepended.

    The easiest test to see if this is the problem would be something like:

    // starting context for calls originating from DID trunks
// the call is matched on the DID number and routed appropriately
context from-did {
    // test DID from DIDforSale
    ########### => jump s@inbound;
    +########### => jump s@inbound;
}

    or the 'what did I miss' option logging:

    // starting context for calls originating from DID trunks
// the call is matched on the DID number and routed appropriately
context from-did {
    // test DID from DIDforSale
    _.+ => NoOp(debug incoming exten = ${EXTEN})
    _.+ => jump s@inbound;
}

    This will log the actual extension to your console. Using _.+ is frowned upon (because it matches everything) and will give you a warning.

    The + is from the ITU standard for publishing international phone numbers. Different SIP providers will have different ways of dealing with this. But the fact that you mention AT&T (a US based company) and use 10 # signs for the number give me the hint that the core of the problem is the difference between the notation usual in the US for long distance dialing: 1-NNN-YYY-ZZZZ and the ITU international notation +1-NNN-YYY-ZZZZ.

    • 0