Hi, my problem is I have no outgoing calls on the PRI which always reports busy yet incoming calls work. The far end sees the PRI as working and when I turn on level 2 debug on the PRI the failure occurs without anything hitting the PRI link itself.
There are 4 telephone extensions on the AEX800 and they all work
We have a number of IVRâs provisioned and they all seem to work
We have 8 SIP lines provisioned and they also seem to work
I have 2 PRI links where FreePBX is network connected to a protocol converter and onto some V5.2 equipment. I can make calls from the V5.2 equipment to the handsets and IVRâs and all works OK. I cannot terminate a call on the V5.2 equipment. The whole network is a test environment with no real world/ telco connections.
What I have tried so far:
Change FreePBX from pri_net to pri_cpe (and do the opposite on the protocol converter)
Circuit seizure on Protocol Converter to be descending thus making FreePBX ascending and the Protocol Converter Descending
Set the following: priindication=outofband, busydetect=no, pridialplan=unknown, prilocaldialplan=unknown in chan_dahdi.conf(including asterisk stop, dahdi restart and asterisk start)
moved the group = 63 from my dahdi-channels.conf file to come just before the signalling = pri_net line. (not sure why this should make a difference but 1 post said it did).
I added a handset as the 3rd option to one of my outgoing routes and the call failed as below on the pri links but worked to the handset so it look like the numbing is correct (even if it is a bit wacky as my V5.2 equipment has single and 2 digit numbers right now except for one line which has a 4 digit number but results are the same on single, double and 4 digit numbers.)
I turned on âcore set debug 9 app_dial.câ from the CLI thinking I would get more details of the failure but it looks exactly the same as the trace below.
I canât seem to figure out why the call fails without asterisk ever communicating with the PRI. There must be a setting wrong somewhere but I canât find it.
All the gory details below and in the 3 linked files:
I have
dahdi Ver 2.6.1
FreePBX ver 2.10.0-28
Asterisk 1.8.13.0
running on IntelÂŽ Coreâ˘2 CPU 6400 @ 2.13GHz
uname -a
Linux localhost.localdomain 2.6.18-308.4.1.el5 #1 SMP Tue Apr 17 17:08:00 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux
256Meg RAM
110Gig HDD with root partition 3% used 100G free. Boot partition 13% used 82Meg Free
See below for config files
I have 3 links to pastebin files but the system wonât let me post them the codes are 2917729, 2917629 and 2917636 with pastebin.ca/ in front of the number
Your system is extremely out of date. Please upgrade. Saying that, it sounds like your outbound trunk for dahdi is incorrect. But before you go chasing down that rabbit hole, you need to upgrade (at least to FreePBX 12 and asterisk 11)
Thank you for the advice, It was one of the things on our list of things to try but thought we should ask first in case we had made some stupid mistake.
I have just started the upgrade now but using a new HDD and FreePBX 6.12.25. Figure this way we can access config on the old drive and revert if necessary.
Thankyou for the advice, will post once we are up, running and configured on the new version.
It is unlikely that a dahdi channel will complete a call to 6154 unless it is an internal trunk, if it is then your tie-line trunkâs far end translation of extension 6154 is mis-configured against your outbound routing to accept such calls, if that is your scenario then check both ends for correct routing . . .
-- Executing [s@macro-dialout-trunk:22] Dial("DAHDI/128-1", "DAHDI/0,11/6154,300,") in new stack
**[2015-02-06 12:29:39] WARNING[5131]: app_dial.c:2274 dial_exec_full: Unable to create channel of type 'DAHDI' (cause 0 - Unknown) == Everyone is busy/congested at this time (1:0/0/1) -- Executing [s@macro-dialout-trunk:23] NoOp("DAHDI/128-1", "Dial failed for some reason with DIALSTATUS = CHANUNAVAIL and HANGUPCAUSE = 0") in new stack**
Maybe dahdi is not loaded, from asterisk CLI
post the issue of:-
module unload chan_dahdi.so
module load chan_dahdi.so
dahdi show status
dahdi show channels
You should be using a GROUP to dialout, not a range of channels (eg, the default is to use âg0â, which would be fine).
Secondly, as dicko spotted, youâre only sending 4 digits out the PRI. Whatâs on the other end of the link?
(Iâm assuming âqldâ means âqueenslandâ, and if thatâs true, Iâm guessing its a Telstra Onramp 10, which has a limit to the number of simultaneous calls, not the the specific channels. Use g0)
Thank you for the advice,
I am rebuilding with the latest version so there is still some config work to do getting us back to where we were.
The GROUP dialout is a very real possibility which I will test as soon as I have enough config back in. The previous version we were running didnât seem to have a g0.
qld does indeed mean Queensland well spotted.
Our numbing plan is unusual because there is no external connectivity, we donât connect to any carriers either on E1, ethernet or ATM (we built a BRAS in a separate box. This part all works, or did until I upgraded).
The 4 digit numbers (in our case 61XX and 62XX) are meant to be put out to the E1 links exactly as 4 digit numbers, it hits a protocol converter that does a PRI to V5.2 translation and then gets pushed to a bunch of telephones connected to a DSLAM. The DSLAM is limited to the L3 number range it can cope with, 4 digits only. It is easier to use these 4 digits all the way to FreePBX rather than get the Protocol Converter to do a translation to a full 10 digit number
The system was all working because I could dial from the DSLAM phones and ring the FreePBX extensions or RVAâs. The busy problem was only going from FreePBX out the E1 card.
Will update as soon as we have enough config to test. Currently working through the configuration document trying to do things in the correct order. Thought this was better than putting old and possibly faulty config back in.
Really, as far as I can remember, itâs install Distro. Go to Dahdi Setup, and click âconfigureâ, and thatâs pretty much it.
The major issue youâre going to have is a timing source. Asterisk doesnât make THAT wonderful a timing source, so you normally want to have âthe other endâ act as the source, unless the other end is even worse than Asterisk.
The 6154 number is intentional. 6154 is meant to be routed out the PRI E1. It goes to a Protocol Converter that translates this to V5.2 on an E1 that terminates through a DSLAM to a PSTN phone. The DSLAM is limited to 4 digit L3 numbers and rather than have the protocol converter change that to a 10 digit number we just use it as is.
As for the commands here is the output
CLI> dahdi show status
Description Alarms IRQ bpviol CRC Fra Codi Options LBO
T4XXP (PCI) Card 0 Span 1 OK 2 0 0 CCS HDB3 CRC4 0 db (CSU)/0-133 feet (DSX-1)
T4XXP (PCI) Card 0 Span 2 OK 2 0 0 CCS HDB3 CRC4 0 db (CSU)/0-133 feet (DSX-1)
T4XXP (PCI) Card 0 Span 3 RED 2 0 0 CAS Unk 0 db (CSU)/0-133 feet (DSX-1)
T4XXP (PCI) Card 0 Span 4 RED 2 0 0 CAS Unk 0 db (CSU)/0-133 feet (DSX-1)
Wildcard AEX800 OK 0 0 0 CAS Unk 0 db (CSU)/0-133 feet (DSX-1)
localhostCLI>
localhostCLI> dahdi show channels
Chan Extension Context Language MOH Interpret Blocked State Description
pseudo default default In Service
1 from-digital au default In Service
2 from-digital au default In Service
3 from-digital au default In Service
4 from-digital au default In Service
as above all the way down to
62 from-digital au default In Service
125 from-analog au default In Service
126 from-analog au default In Service
127 from-analog au default In Service
128 from-analog au default In Service
129 from-analog au default In Service
130 from-analog au default In Service
131 from-analog au default In Service
132 from-analog au default In Service
The module unload and load made no difference to the above results. The only errors I get are on the load when it tells me my 4 FXS lines have a red alarm.
unload
CLI> module unload chan_dahdi.so
Unloaded chan_dahdi.so
== Unregistered application âDAHDISendKeypadFacilityâ
== Unregistered application âDAHDISendCallreroutingFacilityâ
== Unregistered application âDAHDIAcceptR2Callâ
== Manager unregistered action DAHDIDialOffhook
== Manager unregistered action DAHDIHangup
== Manager unregistered action DAHDITransfer
== Manager unregistered action DAHDIDNDoff
== Manager unregistered action DAHDIDNDon
== Manager unregistered action DAHDIShowChannels
== Manager unregistered action DAHDIRestart
== Manager unregistered action PRIShowSpans
== Manager unregistered action WATSendSms
== Manager unregistered action WATShowSpan
== Manager unregistered action WATShowSpans
== Unregistered channel type âDAHDIâ
â Unregistered channel -2
â Unregistered channel 1
and so on down to 132
Load
CLI> module load chan_dahdi.so
Loaded chan_dahdi.so
== Registered application âDAHDISendKeypadFacilityâ
== Registered application âDAHDISendCallreroutingFacilityâ
â Registered libwat
== Parsing â/etc/asterisk/chan_dahdi.confâ: Found
== Parsing â/etc/asterisk/chan_dahdi_general.confâ: Found
== Parsing â/etc/asterisk/chan_dahdi_general_custom.confâ: Found
== Parsing â/etc/asterisk/chan_dahdi_channels_custom.confâ: Found
== Parsing â/etc/asterisk/chan_dahdi_groups.confâ: Found
== Parsing â/etc/asterisk/chan_dahdi_additional.confâ: Found
â Registered channel 1, ISDN PRI signalling
â Registered channel 2, ISDN PRI signalling
and so on down to
â Registered channel 62, ISDN PRI signalling
[2015-02-10 11:53:29] WARNING[6175]: chan_dahdi.c:8386 handle_alarms: Detected alarm on channel 129: Red Alarm
â Registered channel 129, FXS Kewlstart signalling
[2015-02-10 11:53:29] WARNING[6175]: chan_dahdi.c:8386 handle_alarms: Detected alarm on channel 130: Red Alarm
â Registered channel 130, FXS Kewlstart signalling
[2015-02-10 11:53:29] WARNING[6175]: chan_dahdi.c:8386 handle_alarms: Detected alarm on channel 131: Red Alarm
â Registered channel 131, FXS Kewlstart signalling
[2015-02-10 11:53:29] WARNING[6175]: chan_dahdi.c:8386 handle_alarms: Detected alarm on channel 132: Red Alarm
â Registered channel 132, FXS Kewlstart signalling
â Registered channel 125, FXO Kewlstart signalling
â Registered channel 126, FXO Kewlstart signalling
â Registered channel 127, FXO Kewlstart signalling
â Registered channel 128, FXO Kewlstart signalling
â Automatically generated pseudo channel
== Starting D-Channel on span 1
== Starting D-Channel on span 2
== Registered channel type âDAHDIâ (DAHDI Telephony Driver w/PRI & SS7 & MFC/R2 & WAT)
== Registered application âDAHDIAcceptR2Callâ
== Manager registered action DAHDITransfer
== Manager registered action DAHDIHangup
== Manager registered action DAHDIDialOffhook
== Manager registered action DAHDIDNDon
== Manager registered action DAHDIDNDoff
== Manager registered action DAHDIShowChannels
== Manager registered action DAHDIRestart
== Manager registered action PRIShowSpans
== Manager registered action WATSendSms
== Manager registered action WATShowSpan
== Manager registered action WATShowSpans
Loaded chan_dahdi.so => (DAHDI Telephony Driver w/PRI & SS7 & MFC/R2 & WAT)
== Primary D-Channel on span 2 up
== Primary D-Channel on span 1 up
â Restart requested on entire span 1
â Restart requested on entire span 2
Ahh so you are nearby then in relative terms but far enough further north to add several degrees to already warm temperatures. You must like the heat
Dahdi does seem to be up and happy, just working on the rest of the config. PSTN lines, RVAâs, SIP phones and then the E1âs to the DSLAM
Timing should be OK as the DSLAM has a reasonable clock which is passed thru the protocol converter, it was all working last time except for outgoing calls.
pri set debug 2 span 1 doesnât show any issues with slips or errors
You appear to have a 4 port PRI card. You have a PRI link plugged into the first two ports. The other two ports are vacant.
However, youâre then trying do stuff to ports three and four which have nothing plugged into them.
Either way - you need to set them up in groups, properly, unless you really do care about the port â which you may do with the AEX800.
Itâs a bit hard to help you out, however, if itâs real digium hardware, they DO offer support. Contact whoever you bought them from, and theyâll help you set it up properly.
Edit: Oh wait. I misread. Sorry. Yes, youâre right. You have channels 1-62 as PRI signalling. So you should add those channels to group 0. Then create a DAHDI trunk that uses that group, and THEN an outbound route that matches 6XXX (or ⌠whatever the other end is expecting) that goes to that new DAHDi trunk group 0.
I think Rob is on the right track and your trunk(s)-? are possibly restrictively defined, just use one trunk G[012âŚ] as appropriate or possibly g[012âŚ] if it is a dslam on the other end and the protocol converter/dslam is not âglare awareâ it will reduce call collisions and âisdn cause 0âsâ , the group concept will skip busy channels without you having to worry about failover trunk sequences and âhuntingâ conversely for inbound/outbound calls on the same trunk has always been a âgood thingâ.
Good news I think the FreePBX side of things is all working properly. I can call out of FreePBX and see the call on the outgoing PRI. I havenât quite got calls terminating properly on the DSLAM but that looks like a CIC misalignment between the protocol converter and DSLAM (which is now part of tomorrowâs problem and nothing to do with FreePBX or the Digium cards).
Ultimately looks like you both correctly diagnosed my problem which was to do with outbound routing not going via groups.
Upgrading was a neat way around this because it created g0 as part of the install/firstboot script and with DAHDI config done the 2 spans were automatically put into the g0 group.
This new version is hugely more developed and whilst it seems the speaking clock has disappeared there is a lot more functionality available. I have also created a document with the rebuild info so I donât have to try and remember what I did.
The protocol converter is actually pretty smart. It doesnât map between PRI and V5.2 but dynamically assigns. Can also do fancy SIP things but I havenât got a driverâs licence for that part yet
and nothing to do with FreePBX or the Digium cards).