Page tree
Skip to end of metadata
Go to start of metadata

For the purpose of this discussion, we will be referencing the below diagram:


outbound calling scenario


There are two reasons why your outbound calling is not working:

  1. Physical layer issue
  2. Due to configuration issues
  3. Telco dropping the call for a specific reason

Physical layer issue

Verify that the Sangoma Driver (called Wanpipe) is started and running.

Type the following command in your Linux Command line: 

-> 
wanrouter status

 

Below is the status of the Driver when  Active and running properly: 

If you do not see the connected  status line when running the wanrotuer status command then that means that you need to start the Wanpipe Driver.  To start the Wanpipe driver simply run the following command in your Linux command line:

-> wanrouter start
 

Next step is to check the voltage level on the line to verify that your system is able to make an outbound call on that line. 

In a separate Linux terminal window run a live watch of the voltage on the port using the wanpipemon command:

-> 
watch -n 1 "wanpipemon -i w1g1 -c astats -m X"

 

NOTE: replace X with the port number where the call is coming in on that line
(w1g1 is used to reference the entire analog card)

The command above should be run on an FXO line, not FXS.

Find below a sample output of the above command for an FXO port idle and ready for a call
  

  • 48 volts: line is idle and ready for a call (no call processing at the moment)
  • 7 volts: the line is off-hook and there is a call currently on the line
  • 0-130 volts: the line is ringing.  
If the above command shows you an output similar to the one below, this means there is no line physically connected to that port.
analog line not connected to port 


  • If you see the voltage changing when you are attempting to make an outbound call this means that the issue is on the remote side (i.e. telco), and that the call has processed through your system properly (i.e. no configuration issues).  
  • If you are unable to see any voltage changes when making outbound call attempt then perhaps the issue is with your configuration, so proceed to next step section.

Due to Configuration issues

When you are making outbound calls (from your SIP phone) a common reason for failure is due to incorrect DAHDI channel (or DAHDI group) selection.
You may see something like the following output from your Asterisk CLI:

WARNING[4140] app_dial.c: Unable to create channel of
type 'DAHDI' (cause 34 - Circuit/channel congestion)

When you configure a Sangoma card in your system (with wancfg_dahdi script), the physical channels on the card are grouped together into call-groups in the chan_dahdi.conf file (located in /etc/asterisk).
(for FreePBX and Elastix users, the information is located in /etc/asterisk/dahdi-channels.conf)

Groups are used to make outbound calling (Sangoma card -> PSTN).  

Below is an example excerpt of a chan_dahdi.conf file where outbound group dialing is 1


Verify that your call path is using the correct dial group by viewing the call output from the Asterisk CLI.
You may want to increase the verbosity in the Asterisk CLI so that you get more detailed information for your call.

To do this simply type the following inside your Asterisk CLI:
-> core set verbose 10 

If you are correctly dialling out the proper group in chan_dahdi.conf (or dahdi-channels.conf) try to eliminate the possibility that your SIP side is causing the issue, try dialling attempting a call directly from the Asterisk core.

To do this use the asterisk originate command.
From your Asterisk cli type:

-> originate dahdi/gX/333 application playback demo-congrats

    Note: replace X with the calling from chan_dahdi.conf and '333' with a real phone number you can call.

This will attempt to make an outbound call directly from Asterisk and call 333 and when the called person picks up the phone, they will hear and automated message. If this is successful, then that means your system is able to make outbound calls, but your SIP end point is the cause of the issue.

  • No labels