Below are a list of protocol line traces that can be taken on your server if you experience the following scenarios:

     -> cannot make/receive calls: verify your system is setting/receiving the correct requirements
     -> incorrect variables sent/received: trace the line to verify 
     -> D-channel instability, and want to prove if the issue is your system or the telco 
     -> random call disconnects, and want to find out if you or the telco is disconnecting the call 
     -> SS7 link is not aligning, or cannot make/receive calls on aligned SS7 link 

WireShark application is required to analyze the following line capture (PCAP) traces.  
Using the wanpipemon utility, which is built into the Wanpipe driver, one can capture pcap/wireshark trace files that can be later opened and analyzed through Wireshark

Command Line friendly protocol traces

PRI/BRI (D-Channel) Wireshark trace

-> Port configured for CPE Mode (default):

-> Port configured for NET Mode:

SS7 Channel Wireshark trace

-> Use the trace below if MTP2 is aligned & stable

-> Use the trace below if the link is not aligned (MTP2 is down)

-> 7bit hdlc trace (not typical used)

WAN Protocols Wireshark trace

-> Use the trace below if your Sangoma card is configured as a router

-> Advanced Line trace options

How to Capture line trace

For all of the trace commands above:

1. Select the appropriate protocol trace above and copy and paste 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, for SS7=mtp2.pcap.  You may edit the names in the filter string

3. press <enter> to start your line trace

   Open

   

4. Make or receive your call now (direction is dependent on the way the issues is reproducible). 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)

PRI/BRI

For PRI/BRI, a typical pcap should look like this:

Open

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:

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” 

Analyzing a Call Disconnect

 The above information is very helpful when you are trying to analyze why a call has disconnected (i.e. why you have dropped calls). If the source of the RELEASE COMPLETE= Remote Network, this means the telco disconnected your call.  If we click on this message on the top pane of the pcap, we can start analyzing the details of the telco disconnect on the bottom pane. 

Below is an example of a failed outbound call due to the telco (because the RELEASE COMPLETE came from the Remote Network)

As seen in the picture above, by expanding the fields in the lower pane, we can see the Cause for the call disconnect was "Mandatory information elemtn 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

Analyzing Dropping D-Channel

If you believe that your D-channel is going down, which is causing your calls to drop, a pcap will verify which side is dropping the D-channel.  For example, if you see the following in your logs (if using asterisk):

WARNING on /var/log/asterisk/full :
[Jan 17 13:21:50] WARNING[3061] chan_dahdi.c: No D-channels available! Using Primary channel 24 as D-channel anyway!

The source that initiates SABME messages is the side that sees the D-Channel down and is asking the remote side to bring it up.  During normal operation, a pcap will will contain only RR (receive ready) messages, but if the D-channel goes down, you will notice a SABME message breaking up the RR’s.  If the SABME is initiated by the ‘network’, contact your telco to resolve the issue.

SS7

...to be continued

 Advanced Line Trace Options

==========================================

Advanced trace options include protocol decoding
and parsing, system timestamping as well as
packet filtering.

The Advanced trace command is: 'tri'

        wanpipemon -i <ifname> -c tri { trace options }

trace options:
-------------

        -prot   [FR|LAPB|X25]   #Filter packets based on
                                #protocol. Multiple protocols can
                                #be selected:
                                # <prot>-<prot>...
                                # eg: -prot LAPB-X25
                                #Default: All frames

                [FR|PPP|CHDLC|IP|ETH|LAPB|X25]
                                #Also used by -pcap option to
                                #specify what protocol we are
                                #capturing. By default protocol is
                                #autodetected, but in datascoping
                                #this option is a must.

        -pcap
                                #Trace to a pcap type file
                                #that can be read by Ethereal
                                #By default file name is wp_trace_pcap.bin
                                #writen in current/local directory

        -pcap_file <filename>

                                #Specify your own pcap file name

        -x25opt [DATA|PROT]     #Filter x25 packets based on
                                #protcol or information frames
                                #Default: All frames

        -lcn    <number>        #Filter x25 packets based on
                                #specific lcn number
                                #Default: All lcns

        -hex                    #Display packet info in HEX
                                #Default: Hex

        -ascii                  #Display packet info in ASCII

        -ebcdic                 #Display packet info in EBCDIC

        -systime                #Display timestamp as system time
                                #instead of absolute number

        -full                   #Display packet data in full.

Examples:
---------

#Trace and decode all frames, and display packets
#in full with timestampe decoded into system time.

  wanpipemon -i wp1mp -c tri -full -systime

#Trace LAPB and X25 protocol frames. Futhtermore,
#only decode x25 frames with LCN=1

  wanpipemon -i wp1mp -c tri -prot LAPB-X25 -lcn 1

#Trace X25 protocol frames and display x25 data
#in ASCII.

  wanpipemon -i wp1mp -c tri -prot X25 -ascii -full -systime

#Trace data to a pcap type file

  wanpipemon -i wan0 -pcap -c tr
  wanpipemon -i wan0 -pcap -pcap_file myfile.bin -c tr
  wanpipemon -i wan0 -pcap -prot FR -c tr