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:
- Physical layer down
- Due to configuration issues
- Telco dropping the call for a specific reason
Physical layer down
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:
Due to Configuration issues
|WARNING 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 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
Port configured for NET Mode:
-> 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:
- 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.
- 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
- press <enter> to start your line trace
- Make your outbound call now. The information will be captured via the trace
- 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.
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
|SETUP||Caller sends a SETUP to the Switch|
|CALL PROCEEDING||If the SETUP is OK, the Switch sends a CALL PROCeeding to the Caller, and then a SETUP to the Receiver|
|ALERTING||The Receiver gets the SETUP. If it is OK, then it rings the phone and sends an ALERTING message to the Switch, which the forwards theALERTING message to the Caller|
|CONNECT||When the Receiver answers the call, it sends a CONNECT message to the Switch which forwards the CONNECT to the Caller|
|CONNECT ACKNOWLEDGE||The Caller sends a CONNECT ACKnowledge message to the Switch, which then forwards the CONNECT ACKnowledge to the Receiver|
|DISCONNECT||Whichever party wishes to disconnect the call sends a DISCONNECT message to the Switch, which then forwards the DISCONNECTmessage to the remote party|
|RELEASE||When the DISCONNECT messages are received by any recipient, it disconnects the call from its side, and sends a RELEASE to the Switch, which forwards it to the other side|
|RELEASE COMPLETE||The party who receives the RELEASE sends a RELEASE COMPLETE to acknowledge the end of the entire 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”