...
The first step in troubleshooting your PRI/BRI issues is to try and restart the wanpipe driver for a resolve. This is done by typing the following command in your Linux CLI:
-> wanrouter restartIf you notice some error messages populate on your screen then check the driver output log in: /var/log/messages
-Check the line status by typing the wanpipe command: wanrouter status. The possible outputs are: "connected", "connecting" and "disconnected".
=> if the status indicates "connecting", or "disconnected", there is a possibility of alarms on the line. The alarms can be viewed by running the command: wanpipemon -i wXg1 -c Ta (replace X in "wXg1" with the wanpipe number in question). A description of the possible line alarms can be found Here: wanpipemon line alarm status.
-Check the Wanpipe network Interface for data processing issues. Run ifconfig and locate the wanpipe interface (w1g1,w2g1,w3g1..etc) and verify the Rx and Tx packets are incrementing. Below is an example output of ifconfig for "w1g1"
w1g1 Link encap:Point-to-Point Protocol
UP POINTOPOINT NOARP MTU:1500 Metric:1
RX packets:1232 errors:0 dropped:0 overruns:0 frame:0
TX packets:1424 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:169 Memory:f8e20000-f8e21fffIf you do not see the above packets increment when you run "ifconfig" multiple times consecutively, then please contact Sangoma Technical Support at techdesk@sangoma.com and include the the PRI the PRI troubleshooting information
-Register the wanpipe interfaces with the Dahdi/Zaptel stack:
-> dahdi_cfg -vvv (if you have dahdi)
-> ztcfg -vvv (if you have Zaptel)If you notice error messages after running the above commands, verify the configuration settings in /etc/dahdi/system.conf (dahdi) or /etc/zaptel.conf (zaptel)
Confirm that Asterisk is able to detect all the Dahdi/zaptel spans. Enter the Asterisk CLI and type the following:
-> (Dahdi): dahdi show channels
-> (zaptel): zap show channelsIf there is no output from the above, this means that chan chan_dahdi.so (dahdi) or zaptel.so was not able to load into Asterisk. The next step is to parse chan_dahdi.conf/zaptel.conf files to find the error.
*Note: If you are using a binary distro (Trixbox, Elastix..) then the actual dahdi channels/zaptel channels are configured in dahdi-channels.conf/zap-channels.confand #included into chan_dahdi.confg/zaptel.conf
RBS: for Robbed Bit Signaling, please click HERE for debugging steps.
-Verify that all the Dahdi/zaptel spans are "Up and Active". Type the following in the Asterisk CLI:-> pri show spans
NOT Scenario: If a paricular particular span is not "Up and Active" (if it should be), then turn on span debugging in the Asterisk CLI to trace the D-channel message on that span in question.
-> pri intense debug span X (replace X with the span)
Note: Asterisk 1.6.2 uses the following:
-> pri set debug 2 span X (replace X for the span value)Here you are trying to confirm that there are BOTH incoming and outgoing D-channel messages. Messages with arrows pointing towards the right of your Monitor (>) are outgoing and messages with arrows pointing to the Left of your Monitor (<) are incoming messages. The information you gather here is only from the highest layer (asterisk), verifying the D-channel message flow in the Asterisk CLI is not enough proof to indicate an issue. You must also verify the same issue is occurring in the lower physical layer to prove if the issue is line related, by using the following command:
-> wanpipemon -i wXg1 -c trd (replace X with the wanpipe interface in question)Note: this command only works when Wanpipe is performing HDLC framing (which is configured by default)
Below are steps to follow depending on the scenario:
=> If there are only incoming frames check the following link: Hardware HDLC
=> If there are only outbound frames then contact you telco and confirm that the D-channel has been activated
=> if there are both incoming AND outgoing messages and you are using the latest Wanpipe driver, then consult with HARDHDLC vs DCHAN to find out why the spans are not "Up and Active"Note: To disable intense debugging in the Asterisk CLI type the following:
-> no pri intense debug span X (replace X with the span)
-> Asterisk 1.6.2: pri set debug 0 span XIS Scenario: If the span IS "Up and Active", then verify if the test call is transferring to the zap/dahdi channel by enabling verbosity in the Asterisk CLI :
-> Asterisk CLI: core set verbose 10
-> search for dial (zap/dahdi...)If the call IS transferring to the zap/dahdi channel, check the PRI cause code by reading the PRI messages in the Asterisk CLI:
-> Asterisk CLI: pri intense debug span X (replace X with the span of your choice)
-> search for "Cause Code" and research the internet for ISDN Cause Codes with this CodeAn alternative to searching the Asterisk CLI for PRI message cause codes, you can take a pcap trace, which is a trace at the lower wanpipe driver level, of the PRI messages being sent and received on the physical line. This is a good way to indicate if you or the remote side is sending wrong information over the line. The pcap trace can then be analyzed through a program called wireshark. The syntax for the pcap trace is below:
CPE Mode: -> wanpipemon -i wXg1 -pcap -pcap_file isdn.pcap -prot ISDN -full -systime -c trd
NET Mode: -> wanpipemon -i wXg1 -pcap -pcap_file isdn.pcap -prot ISDN -pcap_isdn_network -full -systime -c trdReplace 'X' in 'wXg1' with the wanpipe of your choice. If you are connected directly to the telco, then use "CPE Mode". Run the command in a separate linux command line and let run until enough packets have been captured, and then complete the trace by pressing <enter>. The file created is called isdn.pcap and is saved in your local directory. Then analyze the trace in wireshark or send to Sangoma Technical Support with a brief description of the issue.
...
-log all output from the Asterisk console to a file:
=>open up the file /etc/asterisk/logger.conf
=>look for the line "messages=> notice,warning ..." and add this one line below "sangoma => notice,warning,error,event,verbose"
=>save the file and restart Asterisk
-increase the verbosity of Asterisk using "set verbose 10"
-the output from "pri show span X" from the Asterisk console, where X is the span having problems (i.e. 1,2,3,4,etc)
-run "pri intense debug span X" from the Asterisk console so that Asterisk captures debug information, where X is the span having problems (i.e. 1,2,3,4,etc)
-make a call out to reproduce the problem or leave the system running until it occurs
-turn off Asterisk logging to the file /var/log/asterisk/sangoma by:
=>open up the file /etc/asterisk/logger.conf
=>look for the line "sangoma => notice,warning,error,event,verbose", and either remove it or uncomment it
=>save the file and restart Asterisk
-send in the /var/log/asterisk/sangoma
-send in the support logger as shown at httphttps://wikisangomakb.sangoma.com/support-loggeratlassian.net/wiki/spaces/TC/pages/52858083/Support+Logger?search_id=9188d7f8-8cb5-4541-a92a-1843bf145f15
***To turn of the debugging in Asterisk run "pri no debug span X", where X is the span in question***
...
1. AFT-AXX-SH : SLOT=X : BUS=X : IRQ=X CPU=A: PORT=X : HWEC= 32 : V=X
HWEC values should be:
A200d : 32
A101d : 32
A102d : 64
A104d : 128
A108d : 256
A500d : 64
Insure that your line has no noise issues. If you have noise issues then check "ifconfig" for overruns.
Upgrade to the latest Beta driver which can be found at
...
Edit your /etc/wanpipe/wanpipe*.conf file and change "TDMV_HW_DTMF = YES" to "TDMV_HW_DTMF = NO" and then stop asterisk and run "Wanrouter restart" and then start asterisk back up and see if this resolves the issue.
Ether way if the hardware DTMF did not work then please send an email to
techdesk@sangoma.com along with the following information and a brief description of the issue.
...
-- Starting simple switch on 'Zap/1-1'
Once you see the output above simply run the command debug channel Zap/1-1 or debug channel Dahdi/1-1 to start the debugging.
Note: the channel has to be in use before running the debug command.
Then press DTMF digits and you will see the following output, note the digit that was pressed is highlighted in red.
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [Zap/1-1]
<< [ TYPE: DTMF End (1) SUBCLASS: 1 (49) ] [Zap/1-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [Zap/1-1]
<< [ TYPE: DTMF End (1) SUBCLASS: 2 (50) ] [Zap/1-1]
You can also try our dial plan which plays back the DTMF digits to you.
...
Analog Caller ID Issues
...
And example of the default configuration of Asterisk is:
file: chan_dahdi.conf conf
[trunkgroups]
...
[channels]
...
usecallerid=yes
cidsignalling=bell
cidstart=ring
...
...
(all the above information was taken from http://kb.digium.com/articles/Troubleshooting/How-to-troubleshoot-CallerID-issues-on-a-FXO-or-QuadFXO-module?retURL=%2Fapex%2FknowledgeProduct&popup=false this link. )
...
dahdi_monitor audio recording
...
Determine the call channel number by running "show channels" on Asterisk CLI:
|
2. Now use the dahdi recording command :
|
this command will initiate an audio recording on the specific channel in the Tx and Rx direction and place the audio data into separate .raw files
When done capturing the audio, press
ctrl + c to end the recording
Convert the raw audio streams into WAVE files using the sox program:
|
(You can use Audacity: http://audacity.sourceforge.net/ if you know what you're doing - import with a bit depth = 16)
...