DID not found in inbound calls over a PRI

New Installation All modules up to date and the system is at 10.13.66-13

Here is the logfile entry. I can make calls.

[2016-08-18 16:43:14] VERBOSE[13690][C-00000009] pbx.c: Executing [[email protected]:1] NoOp(“DAHDI/i1/9895135627-a”, “No DID or CID Match”) in new stack
[2016-08-18 16:43:14] VERBOSE[13690][C-00000009] pbx.c: Executing [[email protected]:2] Answer(“DAHDI/i1/9895135627-a”, “”) in new stack
[2016-08-18 16:43:14] WARNING[13690][C-00000009] chan_sip.c: This function can only be used on SIP channels.
[2016-08-18 16:43:14] VERBOSE[13690][C-00000009] pbx.c: Executing [[email protected]:3] Log(“DAHDI/i1/9895135627-a”, "WARNING,Friendly Scanner from ") in new stack
[2016-08-18 16:43:14] WARNING[13690][C-00000009] Ext. s: Friendly Scanner from
[2016-08-18 16:43:14] VERBOSE[13690][C-00000009] pbx.c: Executing [[email protected]:4] Wait(“DAHDI/i1/9895135627-a”, “2”) in new stack
[2016-08-18 16:43:16] VERBOSE[13690][C-00000009] pbx.c: Executing [[email protected]:5] Playback(“DAHDI/i1/9895135627-a”, “ss-noservice”) in new stack
[2016-08-18 16:43:16] VERBOSE[13690][C-00000009] file.c: <DAHDI/i1/9895135627-a> Playing ‘ss-noservice.ulaw’ (language ‘en’)
[2016-08-18 16:43:20] VERBOSE[13690][C-00000009] pbx.c: Executing [[email protected]:6] SayAlpha(“DAHDI/i1/9895135627-a”, “”) in new stack
[2016-08-18 16:43:20] VERBOSE[13690][C-00000009] pbx.c: Executing [[email protected]:7] Hangup(“DAHDI/i1/9895135627-a”, “”) in new stack
[2016-08-18 16:43:20] VERBOSE[13690][C-00000009] pbx.c: Spawn extension (from-digital, s, 7) exited non-zero on ‘DAHDI/i1/9895135627-a’
[2016-08-18 16:43:20] VERBOSE[13690][C-00000009] pbx.c: Executing [[email protected]:1] Macro(“DAHDI/i1/9895135627-a”, “hangupcall,”) in new stack
[2016-08-18 16:43:20] VERBOSE[13690][C-00000009] pbx.c: Executing [[email protected]:1] GotoIf(“DAHDI/i1/9895135627-a”, “1?theend”) in new stack
[2016-08-18 16:43:20] VERBOSE[13690][C-00000009] pbx_builtins.c: Goto (macro-hangupcall,s,3)
[2016-08-18 16:43:20] VERBOSE[13690][C-00000009] pbx.c: Executing [[email protected]:3] ExecIf(“DAHDI/i1/9895135627-a”, “0?Set(CDR(recordingfile)=)”) in new stack
[2016-08-18 16:43:20] VERBOSE[13690][C-00000009] pbx.c: Executing [[email protected]:4] Hangup(“DAHDI/i1/9895135627-a”, “”) in new stack
[2016-08-18 16:43:21] VERBOSE[13690][C-00000009] app_macro.c: Spawn extension (macro-hangupcall, s, 4) exited non-zero on ‘DAHDI/i1/9895135627-a’ in macro ‘hangupcall’

I originally uploaded the DIDs thru the bulk manager. I have 90 DIDs. I deleted one of the DIDs and recreated it, still the no service message. I know the PRI is working properly since it is working on an existing Mitel system.

Is there a setting I missed???


Why are you using the “from-digital” context instead of “from-pstn”?

Do you have an “Any/Any” inbound route to catch cases like this?

There is a context in extensions.conf

; from-did-direct:
; forces ext-findmefollow to take precedence over ext-local. Also exposed to
; the public side to allow an extension number to be used as an external DID
; without requiring inbound routes to be created, common in many PRI installations
; where the last 4 digits are used as the extnension and DIDs are delivered in
; 4 digit formats.
include => ext-findmefollow
include => ext-local

Using that context saves time and effort for US PRI’s

of note in the same file

; from-digital:
; Context to set for PRI's and equivalent
include => from-pstn
1 Like


This setup is all at default. I will have to figure out where that needs to be changed


Thanks dicko.

default won’t get you there unless you program your 90 did’s individually, if you use from-did-direct than there is an intrinsic mapping of what your provider sends over the “D-channel” into your local endpoints, be they extensions,ring-groups,IVR’s whatever . It is up to you to know how the PRI is provisioned, you can ask for any number of “most significant digits” equal or longer to the size of your “common block” look to your mitel configuration, it is probably 4 digits, unless you send the calls through a pre-programmed mitel “digit modification” form.

I compared 4 other locations that I am using a PRI circuit/ same card same provider. In all of them in the dahdi config the setting are all from-digital. I looked at the extensions.conf and that is the same as dicko related. I originally exported the DID numbers from the Mitel system into a spreadsheet. I created a couple of DIDs in the system and used the bulk handler to get the format of the csv file. Then I copied the dids into the new spreadsheet and uloaded it. Then I input the destinations into the system. I just exported the dids and the destinations for extensions are using from-did-direct. The digits sent by the provider is only 7 digits in this case. Anytime I have a problem with a pri and incoming calls I check the logs to see just exactly what they are sending me, I have caught them in a fib many times. But not getting ANY did info from them is new. Is it possible that the import process got hosed somehow? I will individually put the dids in if that is what it takes.

I would check again it looks like the provider is sending 10 digits.

Check with 'pri set debug . . ’

Thanks Dicko,

I am going out there this afternoon to troubleshoot some more. I am unfamiliar with the pri set debug. I run it from the Asterisk CLI in the gui I run this command pri set debug 1 span 1 it says that debugging is on but no activity when a call is placed. Should I be seeing what is going on?

Thanks for all the help

From bash

tailf /var/log/asterisk/full|grep -Ei "span|executing"

I get the same information as the original post. No DID information. I have tried even setting the dahdi config to from-pstn. I have tried 7, 10 and 11 digits. For some reason they are not hitting the system

Well from your original post

It suggests that the calls ARE “hitting your system” , do you have an inbound route for 9895135627 ?

dialplan show [email protected]

That phone number is the number I was calling from into the system. Anyway, Even after checking 5 other systems that are using PRIs with this carrier they are all setup as Signalling pri-cpe, AND a call to their NOC to ask them what they saw. I decided to change the signalling to pri-net, and voila it works just fine. Now in the past if I had this incorrect I would see an error in the log stating something like “we think we are the clock when they think they are the clock” So it appears to be operating. We tested several numbers and all is good.

Thanks for the help guys