Asterisk Debugging

chan_dahdi

Asterisk PRI/BRI Debugging 

Follow one or more of the steps below to resolve an issue with any of your PRI/BRI spans:

1. 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 restart

   If you notice some error messages populate on your screen then check the driver output log in: /var/log/messages
   - 

2. 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.
   - 

3. 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-f8e21fff

   If 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 troubleshooting information
   -

4. 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)

5. 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 channels

   If there is no output from the above, this means that 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.
   -

6. 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 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 X

7. IS 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 Code

8. An 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 trd

   Replace '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.

  
9)If you are still having problems then please send the following to techdesk@sangoma.com along with a brief description of the problem:

-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 https://sangomakb.atlassian.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***

Hang-up Detection

This section describes terminology, tips and settings that might aid in troubleshooting hangup detection issues most notably within applications using analogue phones.  Hangup signals are generate by a FXS interface and are used to signal an FXO that the line has been hung up on the FXS end.  Note in the opposite case the FXO would indicate a hangup by bringing the line to the on-hook voltage level (this section is to help with configuring the former).

Disconnect Supervision

• Refers to opening/closing the 2-wire circuit (as in hanging up a telephone), and in some cases, reversing tip/ring (48 volt polarity change)

• It is something your telco should be providing to you

• Complain to your telco about them not giving you "disconnection supervision" on your line

Kewlstart signalling

• Under Asterisk, the term used to describe Remote Disconnect Supervision

• To enable - put "signalling=fx[s/o]_ks" in /etc/asterisk/chan_dahdi.conf

• Is by far the most reliable method of telling Asterisk that the line has been disconnected

• Try asking your Telco if they can supply you with Kewlstart or Forward Disconnect Supervision on your line

• what it does - momentarily reverses the polarity on the line to indicate that the line has been disconnected

CPC (Calling Party Control)

• an open circuit (0 V) signal sent from most modern electronic COs to indicate that the "Calling Party" has hung up

DAHDI Settings (EXAMPLES ONLY)

The following settings can be adjusted in the file /etc/asterisk/chan_dahdi.conf
NOTE* These values are examples and must be set according to your Telco's requirements and provided services
( source:  http://www.voip-info.org/wiki/view/chan_dahdi.conf  )

busydetect=yes

On trunk interfaces (FXS) and E&M interfaces (E&M, Wink, Feature Group D etc, it can be useful to perform
busy detection either in an effort to detect hangup or for detecting busies.  
This enables listening for the beep-beep busy pattern.

 busycount=6

If busydetect is enabled, it is also possible to specify how many busy tones  to wait for before hanging up. 
The default is 3, but it might be  safer to set to 6 or even 8.  Mind that the higher the number, the more
time that will be needed to hangup a channel, but lowers the probability  that you will get random hangups.

busypattern=500,500

If busydetect is enabled, it is also possible to specify the cadence of your busy signal.  In many countries,
it is 500msec on, 500msec off.  Without busypattern specified, we'll accept any regular sound-silence pattern
that repeats <busycount> times as a busy signal.  If you specify busypattern, then we'll further check the
length of the sound (tone) and silence, which will further reduce the chance of a false positive.

answeronpolarityswitch=yes

Use a polarity reversal to mark when a outgoing call is answered by the
remote party. In some countries, a polarity reversal is used to signal the
disconnect of a phone line.

hanguponpolarityswitch=yes

If the hanguponpolarityswitch option is selected, the call will be considered 
"hung up" on a polarity reversal.

callprogress=yes
progzone=uk

Few zones are supported at the time of this writing, but may be selected
with "progzone".  Progzone also affects the pattern used for buzydetect (unless
busypattern is set explicitly). The possible values are: 
  us (default)
  ca (alias for 'us')
  cr (Costa Rica)
  br (Brazil, alias for 'cr')
  uk

This feature can also easily detect false hangups. The symptoms of this is
being disconnected in the middle of a call for no reason.

tonezone = 0 

Set the tonezone. Equivalent of the defaultzone settings in
/etc/dahdi.conf . This sets the tone zone by number.
Note that you'd still need to load tonezones (loadzone in dahdi.conf).
The default is -1: not to set anything. 0 is US.

ringtimeout=8000

FXO (FXS signalled) devices must have a timeout to determine if there was a
hangup before the line was answered.  This value can be tweaked to shorten
how long it takes before DAHDI considers a non-ringing line to have hungup.
ring timeout will not update on a reload.

Wanpipe Settings

The following settings can be adjusted in the file /etc/wanpipe/wanpipeX.conf
NOTE* Try to fix hang up detection issues using DAHDI settings first !

RM_BATTTHRESH = 3

This value determines the level which the line voltage must be strictly less then in order for the line to be in a "battery removed" state. 

RM_BATTDEBOUNCE = 4 - 16 

This value defines the time period the wanpipe driver will wait for voltage level changes to settle on the line.
So if the far end sends a battery debounce (e.g. drops/reverses the line voltage level to indicate a hangup)  or a battery removal, this variable determines how long the driver will wait before making conclusions about the final battery state / voltage level on the line.
The value is decremented once every 4 interrupt periods (1 ms interrupts) and therefore determines the settling time with the simple relation:

settling time (ms) = RM_BATTDEBOUNCE * 4

External Resources

http://www.voip-info.org/wiki/index.php?page=Asterisk+Disconnect+Supervision
http://www.voip-info.org/wiki/view/Australia+Asterisk+Details

Caller ID

If there is a caller ID issue then, first insure that telco is sending the CID by using a normal analog phone on the line. Next after you know telco is sending caller id then go to the following URLS, and see if the suggestions there help resolve the issue.

http://www.voip-info.org/wiki-Asterisk+config+zapata.conf#CallerIDOptions
http://www.voip-info.org/wiki/view/Asterisk+and+UK+Caller+ID
http://www.voip-info.org/wiki/view/Asterisk+and+Australian+Caller+ID

NOTE: If caller ID is disabled on the line from the telco you can add "usecallerid=no" to stop Asterisk from waiting for the caller id. This decreases the time the call takes to enter the dial plan to be routed. 

Software Echo Canceler Debugging

Here are a few steps we have used to debug echo.

1. Find out if the Echo canceler is even ON. Sometimes the EC stays off for some reason.

Set echocancel = no, and make a call to a number that you know has bad echo.
Then make it with echocancel = yes. You should notice a _BIG_ difference. If you have to think about it, then there is no real difference and echo cancellation was off both times. The difference should be dramatic.

You can confirm by placing a call and using "zap show channel x" or "dahdi show channel x" to see the echo cancellation state. If you see that echo cancellation is set to zero taps, then somehow echo cancellation is not enabled. If you see echo cancellation set to 128, 64 or 32 taps, then the global echo cancellation is enabled.

1. If the EC is working play with the gains.

The software echo cancellers are quite good at reducing echo about 25dB, but you will often have a little echo remaining. This echo residual can be reduced a lot by playing with the tx and rx gains. Try txgain=rxgain=-10 to start. It should have a dramatic effect on the residual echo, at the expense of volume. You can adjust the attenuation and will usually find a setting with reasonable volume and acceptable echo.

1. Limitations of the software EC: The EC in zaptel/dahdi has been optimized for the lowest system load, so there have been several compromises made. Firstly the training sequence is run much less frequently than in a hardware EC, so training takes 10-15 seconds rather than about 1/4 second. So you will hear echo for the first 10-15 seconds, after which it will largely fade. There is nothing you can do about that in s/w, except use the echotraining feature.

The other problem is that the non-linear processor is missing entirely from the s/w EC so that there is always residual echo that has to be manipulated with the gains.

1. Try decreasing your txgain and rxgain in zapata.conf or chan_dahdi.conf, and increase the volume on your handsets. 

2. You can try a different software echo canceller. 

In your zaptel source. modify your zconfig.h file. 
Look for #define ECHO_CAN and try a different echo canceller.

1. If all other methods of reducing echo have failed, Asterisk also has an option in the zconfig.h to makethe echo cancellation more aggressive. You can enable it by uncommenting the following line:

      #define AGGRESSIVE_SUPPRESSOR

    Note that aggressive echo cancellation can create a walkie-talkie, half-duplex effect. This should be enabled only if all above methods have failed.

You will get better performance from good carrier-grade hardware EC such as used on our "d" models.

Hardware Echo Canceler Debugging

How to confirm that your hardware echo canceler is running and active on your Zap/Dahdi calls.

1. Confirm that you have a hardware echo canceler:

    After the Wanpipe drivers are installed, type "wanrouter hwprobe" it should say:    
    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           If it says HWEC=0, and you ordered a "d" model card then this card needs to be replaced so if you purchased this card from a reseller, contact your reseller. If you purchased this card directly from Sangoma, then please contact our RMA department.

1. If you have a hardware echo canceller,  confirm that:

• You have Wanpipe-2.3.4 or newer

• You have the parameter "

TDMV_HWEC = YES" in your /etc/wanpipe/wanpipe*.conf

• You have the parameter "echocancel=yes" in your /etc/asterisk/zapata.conf or /etc/asterisk/chan_dahdi.conf

1. Run "wanrouter start" to start our drivers then run "wan_ec_client wanpipe1 stats"

If you do not see any output, contact Sangoma Tech Support and attach /var/log/messages to the email.
       
You should see:       
wanpipe1: Running Get stats command to Echo Canceller device... Done!
***** Echo Canceller Chip Get Stats wanpipe1 *****
wanpipe1: Number of channels currently open    32 This confirms that the WANPIPE drivers can communicate with the hardware echo canceller chip properly.         4. Make a call through Asterisk. While the call is active type "zap show channel N" or "Dahdi show channel N" (N being the zap/Dahdi channel number) in the Asterisk CLI. In the output it should say "echocancel: 128 TAPS, currently ON" if it does not say "currently ON", check your /etc/asterisk/zapata.conf or /etc/asterisk/chan_dahdi.conf , if you are bridging TDM to TDM, and you want echo canceling to be performed, then you should also have "echocancelwhenbridged=yes"
          
If it says "currently ON" then check if the hardware EC is enabled or not, by running the command " wanpipemon -i <interface name> -c ehw "
For example:
#> wanpipemon -i w1g1 -c ehw
Sangoma HW echo canceller active on channel N
where N is your active channel. 
With wanpipe-3.2.x and wanpipe-2.3.4-5 or later, we have persistent hardware EC means hardware EC is enabled all the times, therefore you should see following for all the voice channels
#>  wanpipemon -i w1g1 -c ehw
Sangoma HW Echo Canceller is enabled for channel N  ( N: is your channel number)

Software DTMF Detection 

1. Edit your /etc/asterisk/zapata.conf or /etc/asterisk/chan_dahdi.conf and change set "relaxdtmf=yes" then restart Asterisk.

2. Go into the Asterisk CLI "asterisk -r" and run "zap show channel X" or "dahdi show channel X" (x being the zap/Dahdi channel in question) and this will tell you if relaxdtmf is enabled. Place some test calls and see if the issue has been resolved. 

3. If the issue remains then go into your /etc/asterisk/zapata.conf or /etc/asterisk/chan_dahdi.conf and increase your rxgain value. You can apply this change with just the command reload from the Asterisk CLI.

4. If the issue are still remaining then check the quality of the line and insure there is no echo or noise issues. 

5. If there is no noise issues then please upgrade and try our 

hardware DTMF, instructions for this can be found at Appendix --> Asterisk & Sangoma Hardware DTMF.

Hardware DTMF Detection

NOTE: You need a hardware echo canceler. To see if you have a HWEC run the command "wanrouter hwprobe" and it should say:

    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          

2. Insure that your line has no noise issues. If you have noise issues then check "ifconfig" for overruns.

3. Upgrade to the latest Beta driver which can be found at http://wiki.sangoma.com/wanpipe-linux-drivers#beta

4. 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.

5. 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.

-the output from "wanrouter version"
-the output from "wanrouter restart" (asterisk needs to be turned off for this so it may need to be done after hours)
-the file /var/log/messages (the entire file containing a wanrouter restart)
-the output from "wanrouter hwprobe verbose"
-the output from â??wanrouter statusâ?
-the file(s) /etc/wanpipe/wanpipeX.conf (where X is the wanpipe number)
-the file /etc/zaptel.conf  (Zaptel/Asterisk ONLY)
-the file(s) /etc/asterisk/zapata*.conf  (Zaptel/Asterisk ONLY)
-the file /etc/dahdi/system.conf  (Dahdi/Asterisk ONLY)
-the file(s) /etc/asterisk/chan_dahdi.conf (Dahdi/Asterisk ONLY)
-the output from "ifconfig", (re run a couple of times with a second or so delay in between each run)
-the output from "cat /proc/interrupts" (re run a couple of times with a second or so delay in between each run)
-the output from "wanpipemon -i wXg1 -c Ta" (where X is the interface number 1,2,3,etc) for each interface

 Checking the DTMF received

1. You can simply go into the Asterisk CLI with the command asterisk -rvvvvvv and then pick up the channel you want to debug and you will see the output below.

-- Starting simple switch on 'Zap/1-1'

2. 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.

3. 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]

4. You can also try our dial plan which plays back the DTMF digits to you.

DTMF_Dial_Plan.rar

Analog Caller ID Issues

Sangoma Hardware does not interpret or interfere with caller ID on the line and simply passes this information up to the software stack (ie. Dahdi/FreeTDM).  If you wish to troubleshoot Caller ID issues, the following steps may help:

A Caller ID issue could be caused by several factors. This section explores the possibility that the issue could be located at the telco or by noise on the lines.

• Connect an analog phone to the demarcation point. In telephony, the demarcation point is the point at which the telephone company network ends and connects with the wiring at the customer premises.

• Place a call -- using another line or mobile phone -- from the PSTN to the analog phone connected at the demarcation point and check if the phone displays Caller ID.  If the Caller ID information is not being shown by the phone, please contact your telco and ask them how to enable this feature.   

• Otherwise, please disconnect the phone and plug it to the line that is directly connected or closest to your Asterisk server and repeat the test call.

If the analog phone shows the CallerID on every call, we could potentially be facing a misconfiguration of your Asterisk server. The following section will discuss how Caller ID detection works in Asterisk and the different options that you have avaialble. 

In Asterisk, the CallerID detection is done by the chan_dahdi module.  Normally its configuration file is located on /etc/asterisk/chan_dahdi.conf  and there are three variables that control how the feature works:

• usecallerid: Sets whether to use caller ID, "yes" or "no" are the only available options

• cidsignalling:  Determine type of caller ID signaling in use. The Caller ID signaling types supported by Asterisk are:

bell: bell202 as used in US (default)
v23: v23 as used in the UK
v23_jp: v23 as used in Japan   
dtmf: DTMF as used in Denmark, Sweden and Netherlands
smdi: Use SMDI for caller ID.  Requires SMDI to be enabled

• cidstart: Determine signals the start of caller ID. The options supported by Asterisk are:

ring: A ring signals the start (default)
polarity: Polarity reversal signals the start
polarity_IN: Polarity reversal signals the start, DTMF dialtone detection in India
dtmf:  DTMF Caller ID spill begins only with DTMF, at various times before the ring.  This causes Asterisk to   constantly listen for DTMF CallerID signals on the specified channels
If cidstart is configured to use dtmf, the energy level on the line may need to be tuned to properly identify the DTMF tones. This tuning is done with the dtmfcidlevel configuration option. The specified value is compared to the average over a packet of audio level of the absolute value of 16 bit signed linear samples.  The default is set to 256, but this is completely arbitrary.  It must be set high enough to prevent false detections, while low enough to ensure no dtmf spills are missed.
 

dtmfcidlevel=256
 

If you are unsure how to set up these variables. Please contact your telco for more information about the type of signal that the use on the Caller ID (cidsignalling)and when their switches send it (cidstart) 

And example of the default configuration of Asterisk is:

file: chan_dahdi.conf 

[trunkgroups]
...
[channels]
...
usecallerid=yes
cidsignalling=bell
cidstart=ring
...

Note: "..." means that other configuration unrelated to Caller ID could be there.  Please take into consideration that chan_dahdi controls more aspects than the Caller ID. Please do not delete the other variables if you are not sure what those do.

P.S.  We have seen at least once where a telco disabled Caller ID by attenuating the Caller ID signal.  This disables it for Asterisk and DAHDI, but a plain old telephone service (POTS) handset with Caller ID display can still show Caller ID information in this scenario.  If you're sure you have the chan_dahdi.conf settings correct for your location, and you're still not getting Caller ID, be sure to contact the provider and make sure they actually have Caller ID enabled on the line.

(all the above information was taken from this link. )

dahdi_monitor audio recording

Use dahdi_monitor to record a Dahdi Channel if you are experiencing these symptoms:?

• Echo/noise?

• DTMF issues

• one-way audio issues

Below is a diagram of how dahdi_monitor is used:

Open

As seen in the diagram above, the result of audio recordings from dahdi_monitor will indicate from which direction the bad audio/issue is coming from.

Establish a call that has an echo, noise, dtmf, or one-way audio problem  

1. 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

3. When done capturing the audio, press 

ctrl + c to end the recording

4. 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)

 NOTE* If output_tx.raw has bad audio, the issue is coming from either the Asterisk layer, or your sip network (Sangoma technical support may not be able to help you resolve this scenario)

If your Sangoma hardware has a hardware echo cancellor, its best practice to take a hardware echo canceller recording at the same time you run dahdi_monitor recordings.  This will give you a complete picture of the audio (highlevel and low level) and determine where the audio issue is generated from