Cant route incoming calls to extention

My system:
PBX in a Flash PURPLE Status Program

┌────────────────────────SYSTEM INFORMATION───────────────────────────┐
│ Asterisk = ONLINE | Dahdi = ONLINE | MySQL = ONLINE │
│ SSH = ONLINE | Apache = ONLINE | Iptables = ONLINE │
│ Fail2ban = ONLINE | Internet = ONLINE | Ip6Tables = ONLINE │
│ Disk Free = ADEQUATE| Mem Free = ADEQUATE| NTPD = ONLINE │
│ SendMail = ONLINE | Samba = OFFLINE | Webmin = ONLINE │
│ Ethernet0 = ONLINE | Ethernet1 = N/A | Wlan0 = N/A │
│ │
│ PIAF Installed Version = 2.0.6.2 under HARDWARE
│ FreePBX Version = 2.8.1.5 │
│ Running Asterisk Version = 1.8.8.0 │
│ Asterisk Source Version = 1.8.8.0 │
│ Dahdi Source Version = 2.6.0+2.6.0 │
│ Libpri Source Version = 1.4.12 │
│ IP Address = 192.168.1.100 on eth0 │
│ Operating System = CentOS release 6.2 (Final) │
│ Kernel Version = 2.6.32-220.7.1.el6.i686 - 32 Bit │

Testing the Les.net and making inbound route as described using the numbers after the / , advanced pattern matching strings, the phone number, heck even tried my birthdate! They all get caught by the “Any” DID routing entry. When I delete the “any” catch all entry all calls goto “number not in service” message from my PBX I assume.

The incoming rings through to the “catch all” but once that is deleted I get the “number you dialed is not in service” with the following log activity:
VERBOSE[13311] pbx.c: – Executing [[email protected]:1] Set(“SIP/123456789-00000325”, “__FROM_DID=2181112222”) in new stack
VERBOSE[13311] pbx.c: – Executing [[email protected]:2] NoOp(“SIP/123456789-00000325”, “Received an unknown call with DID set to 2181112222”) in new stack
VERBOSE[13311] pbx.c: – Executing [[email protected]:3] Goto(“SIP/123456789-00000325”, “s,a2”) in new stack
VERBOSE[13311] pbx.c: – Goto (from-trunk,s,2)
VERBOSE[13311] pbx.c: – Executing [[email protected]:2] Answer(“SIP/123456789-00000325”, “”) in new stack
VERBOSE[13311] pbx.c: – Executing [[email protected]:3] Wait(“SIP/123456789-00000325”, “2”) in new stack
VERBOSE[13308] app_dial.c: – SIP/future9-00000324 is making progress passing it to SIP/122-00000323
VERBOSE[13308] app_dial.c: – SIP/future9-00000324 answered SIP/122-00000323
VERBOSE[13308] rtp_engine.c: – Locally bridging SIP/122-00000323 and SIP/future9-00000324
VERBOSE[13311] pbx.c: – Executing [[email protected]:4] Playback(“SIP/123456789-00000325”, “ss-noservice”) in new stack
VERBOSE[13311] file.c: – <SIP/123456789-00000325> Playing ‘ss-noservice.gsm’ (language ‘en’)

For my incoming route here I used the 123456789 in the DID number field and at the bottom of the page the extention it was to go to.

My outgoing trunk settings: (many revisions have been tried here too)

host=did.voip.les.net
context=from-trunk
type=peer
insecure=very
nat=yes
canreinvite=no
username=123456789
secret=xxxxxxxxx
qualify=no
Does any of this look out of sorts?

The first question to ask is what is your provider actually sending as the DID. What they are sending must be matched exactly for inbound DID routing to work.

On the surface, from your logs, it looks like you are receiving the full 10 digits, so that is what uou would place in the DID field.

Also make sure there is nothing in the CID field.

When all is said and done, the route name should be “NNNNNNNNNN/Any CID”.

BF

We know based on this error message that the trunk is not working right, the call did not match any peer, you can test my theory bu turning on Anonymous Inbound for testing:

VERBOSE[13311] pbx.c: -- Executing [[email protected]:2] NoOp("SIP/123456789-00000325", "Received an unknown call with DID set to 2181112222") in new stack

You are not with me, the peer doesn’t match, your trunk must be configured wrong. The DID digits are fine. They are arriving as “2181112222”

If the trunk is not setup right the call will arrive in the “catch all” context and not go to the right context.

That is why I suggested turning anonymous SIP on as a test.

I have tried this setting and It didnt work for me as it did for other in the forums. My provider says it sends the peer name as my did to match. I have also tried MANY other strings to get it to match including advanced partial match string expressions and such.