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



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):

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


SS7 Channel Wireshark trace

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

 

wanpipemon -i w1g1 -pcap -pcap_file mtp3.pcap -mtp2-msu -prot MTP2 -full -systime -c trd

 

-> Use the trace below if the link is not aligned (MTP2 is down)
wanpipemon -i w1g1 -pcap -pcap_file mtp2.pcap -prot MTP2 -full -systime -c trd

 

-> 7bit hdlc trace (not typical used)
wanpipemon -i w1g1 -pcap -pcap_file mtp2-7bit.pcap -prot MTP2 -7bit-hdlc -full -systime -c trd

WAN Protocols Wireshark trace

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

wanpipemon -i p1fr1 -pcap -systime -full -prot FR -c tr

-> 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


  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:

 

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:


SETUPCaller sends a SETUP to the Switch
CALL PROCEEDINGIf the SETUP is OK, the Switch sends a CALL PROCeeding to the Caller, and then a SETUP to the Receiver
ALERTINGThe Receiver gets the SETUP. If it is OK, then it rings the phone and sends an ALERTING message to the Switch, which the forwards the ALERTING message to the Caller
CONNECTWhen the Receiver answers the call, it sends a CONNECT message to the Switch which forwards the CONNECT to the Caller
CONNECT ACKNOWLEDGEThe Caller sends a CONNECT ACKnowledge message to the Switch, which then forwards the CONNECT ACKnowledge to the Receiver
DISCONNECTWhichever party wishes to disconnect the call sends a DISCONNECT message to the Switch, which then forwards the DISCONNECT message to the remote party
RELEASEWhen 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 COMPLETEThe 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” 

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


  • No labels