For the purpose of this discussion, we will be referencing the below diagram:
inbound call scenario
The below information is assuming that you can make outbound calls (where only inbound calling is an issue)
If both inbound & outbound calling is an issue, please visit the following page for assistance:
-> PRI- PRI Down
A very quick way to diagnose inbound calling issues/Disconnect is to take a line trace.
A line trace can prove if the inbound call is being received by your Asterisk PBX or not, and who is dropping the call (asterisk pbx or telco).
You can take a line trace by using the wanpipemon utility, see below:
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 inbound 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 reached 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 inbound call
The above is an example of an inbound call.
Notice how the screen is divided into two panes. The top portion will show you Q931 messages (i.e. SETUP, CONNECT, DISCONNECT). 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
A successful call will include all of the following messages in this order:
|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”