PRI-Outbound Calls fail

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

 
outbound calling scenario

Open

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

1. Physical layer down

2. Due to configuration issues

3. Telco dropping the call for a specific reason 

Physical layer down

The most common reason that your outbound calls are failing is due to the physical layer being down and disconnected.

Always verify that your physical layer is active/Connected state.
To do this type the following wanrouter command in your Linux command line
-> wanrouter status

If your physical layer is Active you should see 'Connected' as seen below:

Open

If your physical layer is down you should see 'Disconnected' as seen below:

If your physical layer is down, visit the following link to resolve this issue, which should resolve your outbound calling issue:

-> Wanpipe Driver status shows 'Disconnected'

If your physical layer is Active and "connected', proceed below to help resolve your outbound calling issue.

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:

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 0

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.

If using the originate command still does not help solve your  "cause 34 - Circuit/channel congestion" try the following step to see if there is Q931 information being sent out over the physical line

Telco dropping the call for a specific reason 

To find out why your outbound calling is failing you can use the wanpipemon utility to take a line trace.  Your outbound calls may be leaving your server, proceeding to the telco and then dropped.  Investigation of a line trace may help you resolve your issue by fixing your configuration or contacting your telco.

Line Trace commands:

Port configured for CPE Mode (default)

-> wanpipemon -i w1g1 -pcap -pcap_file isdn.pcap -prot ISDN -full -systime -c trd

-> wanpipemon -i w1g1 -pcap -pcap_file isdn.pcap -prot ISDN -pcap_isdn_network -full -systime -c trd

Note: change 'w1g1' to the wanpipe port specific to your trace. (w2g1 for wanpipe2, w3g1 for wanpipe3...etc)

How to Capture line trace

For the trace commands above:

1. copy and paste the trace command above into into your command line.  Interface 'w1g1' is used by default (i.e. "wanpipemon -i w1g1 -pcap -pcap_file isdn.pcap -prot ISDN -full -systime -c trd").
   If you are taking the line trace on a different interface, change 'w1g1' to 'wXg1' (replacing X) in the filter.  To find a list of Wanpipe interfaces, type "ifconfig" in your command line. 

2. The trace will save a '.pcap' file in the local directory that the trace was taken.  For PRI/BRI= isdn.pcap.  You may edit the names in the filter string

3. press <enter> to start your line trace

4. Make your outbound call now. The information will be captured via the trace

5. press <enter> to end the trace when you have completed the call.  Search the local directory for the file and open it up in wireshark to start investigating

How to Analyze your captured wireshark pcap trace

Now that you have captures a pcap trace from the steps above, it is time to analyze them in wireshark.

-> If your pcap trace does not open up properly in wireshark, verify that the trace is not 0 bytes.  If the trace is empty, that means:
   -> Either you have taken the trace on the wrong interface  (i.e. w1g1 instead of w2g1), or
   -> The call never left the server (for outbound call), or the telco did not pass the call to your server (for inbound call)

Below is a line trace opened in wireshark of a failed outbound call

Notice how the screen is divided into two panes.  The top portion will show you Q931 messages (i.e. SETUP, RELEASE COMPLETE). When clicking on each one, the bottom pane describes the details of each message. You will have to expand the fields on the bottom pane to view details.

Notice the source and destination Columns.  This tells you where the call originated from and is being sent to, respectively.  If source = ‘Local User’ this means your server initiated the message(i.e the call, if the message is SETUP).  If source = ‘Remote Network’ this means the telco initiated the message (i.e. the call, if the message is SETUP).  Use the same analogy to analyze the destination

As seen from the picture above the source of the RELEASE COMPLETE= Remote Network, so this means the telco disconnected your call

In the lower pane, we can see the Cause for the call disconnect was "Mandatory information element is missing (96).  96 is the ISDN cause code, and can be referenced on the internet to investigate details.
To look up your cause code, please visit http://networking.ringofsaturn.com/Routers/isdncausecodes.php .
You will need to contact the telco and ask them why they disconnected your outbound call attempt.  If you believe the call was disconnected by the telco due to a mis-configured option on your side, start expanding the SETUP message.  I.e. an empty calling party number is a typical reason for the telco to drop your call attempt.  Use the same process described above to analyze an inbound call disconnect.

BEST PRACTICE

If the ISDN Cause code above is not descriptive enough to resolve your issue, the best way to analyze an outbound call disconnect is to take a pcap trace of an inbound call and compare what values the telco has set against yours.  When you notice the difference, change your settings to match the telcos to resolve your issue

Just for reference, below are details on the messages that should occur for a successful call

NOTE* PROCEEDING/PROGRESS/ALERTING  messages are optional.
          Also, the CONNECT ACKNOWLEDGE message is only sent from NET to CPE (inbound calls from telco).
          So for calls made from CPE to NET (outbound calls), the CONNECT message is the last message before
          call is considered “up”