PRI-PRI Bouncing UP and Down

Owned by Nathaniel Halbrooks
Last updated: Feb 08, 2024 by Kelli Higdon
9 min read

  • The following information will help you troubleshoot if your PRI is bouncing Up and Down.

  • If your PRI is not coming up at all, please visit the following page for troubleshooting and exit this page
    -> PRI- PRI Down
     

If your PRI (or D-channel) is bouncing, you will notice the following messages while logged into the Asterisk CLI:

bouncing PRI seen from Asterisk CLI

There are a few reasons why your pri is bouncing:

  1. Telco Issue

  2. Physical layer is bouncing (continuous 'connected' and 'disconnected')

  3. Incorrect Clock configuration

  4. Incorrect HDLC configuration

 

Telco Issue

When you think your PRI or D-channel is bouncing, you should first contact your telco to investigate.  Contacting your telco and having them run a quick status check on your signalling is quick thing to do (or rule out) and will save you time instead of troubleshooting your server.

If you have issues getting this information when contacting your telco, ask to speak to level 2 personnel.  Sometimes your first point of contact at your telco is not able to help and unexperienced with this topic.

 

Physical layer is bouncing

Observing your PRI status bouncing 'up' and 'down' from your asterisk CLI does not necessarily mean the issue is with your PRI signalling.  If your physical layer is not stable and is also 'up' and 'down' then certainly your signalling (which relies on the physical layer being up) will also drop.

To check your physical layer you can type 'wanrouter status' in your Linux command line. The diagram below shows an example of wanrouter status for a card in 'connected' (or 'up') state.

This output is simply a snapshot of your physical layer and will not provide you information on physical layer stability.
Watch the wanrouter status output over time using the command below:

-> watch -n 1 "wanrouter status"
  

Watch the output of the command above for the period of time that you noticed your pri going up and down seen from your asterisk CLI.
When completed, type CTRL-C to exit 

If you see that your wanrouter status  stays in 'connected' state over time, then your issue is not with your physical layer- skip the rest of this section and move to the next section (Incorrect Clock configuration)

If you notice wanrouter status changing from 'connected' to 'disconnected' this means there is a physical layer alarm causing the entire layer to drop.
To investigate the alarm(s) use the wanpipemon utility and type the following command on your Linux command line:

-> wanpipemon -i wXg1 -c Ta

Note: Change X to the port number you wish to investigate.  (i.e. port 1: wanpipemon -i w1g1 -c Ta)

The output will provide you a snapshot of the physical layer status.  But it is important to see this output over time to notice if the alarms are going on and off.
To watch the wanpipemon output over time, type the following command:

-> watch -n 1 "wanpipemon -i wXg1 -c Ta"

 

Note:  Change X to the port number you wish to investigate.  (i.e. port 1: wanpipemon -i w1g1 -c Ta)

SCENARIO 1
Below is an example output where only RAI is going on and off for an E1 port on a Sangoma card:

 

 

 

Typically if RAI alarm is the only alarm ON, this would be a telco related issue since telco is sending this alarm to your server because telco is in alarm state.
The other reason for RAI to be 'on' is that your server is misconfigured and sending the telco something it does not like, which causes telco to go in alarm.

 

For E1, this would typically mean that you have selected NCRC4 where CRC4 should have been selected (or the opposite: CRC4 where NCRC4 was selected)

  • To fix this simple edit your wanpipe configuration file, and make the change

  • Your wanpipe configuration files are located in the /etc/wanpipe directory and are named wanpipe1.conf(port1), wanpipe2.conf(port2)...etc

  • Edit the FE_FRAME line , then save the file. Be consistent with all applicable ports

    Below is an example Wanpipe configuration file

 

  • you must restart wanpipe for the changes to take effect

  • Run through the above troubleshooting to verify if problem is resolved now. 

 

If the above E1 scenario did not help, or is not your issue, please continue 

SCENARIO 2

When using the watch command to see the wanpipemon output, if you notice the following output (in the order presented), you may have a more fundamental configuration issue:

Rx alarms

  1. RAI

  2. LOS

  3. RED
    TX Alarms 

  4.  AIS

  5. Yellow

  • Contact your telco to review what your line configuration should be (i.e. E1, line coding and line framing) and verify with your Wanpipe configuration file

  • verify that the performance monitoring counters are not incrementing quickly. If they are, this means that the information being received on the line (from remote side) is bad

          -> Its not important what the values are, it is important only when they are incrementing
          -> If they are incrementing, verify that the Rx Level= 2.5db (as shown above).  If the value is not -2.5db, then the reason for incrementing counters is due to poor physical line connection.  To solve this issue, you will need to make a new cable as the connection is poor.  If the RX level is -2.5db, then contact your telco (or investigate remote side) and get a line trace recorded because the inbound information is corrupted.

  • Open the file /var/log/messages and see if you notice an output similar to the diagram below (continuously)

     

     

    -> this means that your system is experiencing the term 'overruns' which basically means there is a clock sync issue from the lines plugged into your sangoma card, or that your system is underperforming- causing the Wanpipe driver to restart itself.
    -> For complete troubleshooting steps for 'overruns' please visit the overruns troubleshooting page

 

 

Incorrect Clocking Configuration

When you have configured your Sangoma card with wancfg_dahdi (or through webGUI for Elastix and FreePBX Distro), you were prompted for the following choices:

 

 

 

  • If your remote side is providing the clock, you should be selecting NORMAL and PRI_CPE

    • this is the typical configuration when connected directly to the telco

  • If your Sangoma card is supposed to drive the clock to a slave device on the remote side, you should be selecting MASTER, and PRI_NET

  • if you mixed these configurtions (i.e. NORMAL with PRI_NET, or MASTER with PRI_CPE) this is the reason your pri is bouncing.

    • re-run the wancfg_dahdi script to reconfigure your Sangoma system (or re-configure via WebGUI if you are using Elastix and FreePBX Distro)

 

As introduced in a previous step, your pri could be bouncing due to 'overruns'.  This scenario can be due to clocking as well. Sangoma cards operating using one clock source.  This means:

  • If all the lines connected to the sangoma card are from the telco, they must all have the same clock, otherwise the Sangoma card will be introduced to multiple clock sources and encounter an 'overruns' scenario

  • If overruns is very severe enough, the Sangoma Wanpipe driver will restart itself in order to try and correct the scenario. If this happens, your physical layer goes down. If your physical layer goes down, also will your pri signalling.  For this scenario, you will see the following, in your /var/log/messages file:

    Please review overruns troubleshooting page if you experience this, in order to correct your issue.

Incorrect HDLC Configuration 

All Sangoma cards use hardware HDLC and auto-configure for hardware HDLC. HDLC configuration is located in :

  • wanpipe configuration files, located in /etc/wanpipe directory (wanpipe1.conf, wanpipe2.conf...etc)

  • DAHDI configure file (/etc/dahdi/system.conf)

The following is an example of Hardware HDLC configuration (for an E1):

 

 

The following is an example of software HDLC configuration:

 

 

 

  • Hardware HDLC sets TDMV_DCHAN to the signalling channel, as well as with hardhdlc

  • Software HDLC sets TDMV_DCHAN=0, and dchan=<signalling channel)

Do not mix up the TDMV_DCHAN and hardhdlc/dchan in one system.
If you have them mixed up and conflicting, edit the files and then restart your server. 

 

If you have verified no issue wtih HDLC configuration, continue to the Taking a line trace.... section below.

 

How to troubleshoot with only logs

If you notice your PRI bouncing and do not have the luxury of running command on Linux command line, get access to the following logs files:

  • /var/log/asterisk/messages (or full)

  • /var/log/asterisk/messages

The /var/log/asterisk/messages file will present you with the Asterisk logs, particularly with messages indicating if the PRI is going 'up' or 'down'.

The /var/log/messages file will present you with information if the physical layer is going up/down, connected/disconnected, and information on any physical layer alarms being activated (just like using the watch command in previouswanpipemon commands)

 

Simply compare the files with respect to the time in the logs:

  •  If the PRI shows up and down in /var/log/asterisk/messages but /var/log/messages does not show any changes (regarding physical layer alarms, or Wanpipe restarting) at the same time then:

    • there is no issue with physical layer 

    • check HDLC settings and verify hardware HDLC is set consistently through your wanpipe and dahdi files

    • take a line trace.  Continue to the next section for instructions on how to take a wireshark trace.

  • If the PRI shows up and down in /var/log/asterisk/messages and /var/log/messages  shows the physical layer going down at the same time then:

    • There is no problem with your PRI signaling, the issue is with your physical layer

    • Check for physical layer alarms using the wanpipemon commands as described in above steps

    • Check for 'overruns' scenario, as described in above steps

 

Taking a line trace to identify if local or remote side is dropping the PRI/D-channel

 

If non of the steps above helped to diagnose your PRI bouncing scenario, then take a line trace to investigate if the issue is due to your server or due to remote end.

 

Line Trace commands:

Port configured for CPE Mode (default)

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

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:

  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 inbound 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:
   -> you have taken the trace on the wrong interface  (i.e. w1g1 instead of w2g1), or
  

The screen will be divided into two panes.  The top portion will show you Q931/Q921 messages 

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 SABME).  If source = ‘Remote Network’ this means the telco initiated the message (i.e. the call, if the message is SABME).  Use the same analogy to analyze the destination

When the D-channel us up the local and remote ends will send 'RR' (or Receive Ready) messages.
When one of the sides (remote/local) notices that the D-channel goes down, that side will send a SABME message to the other side to ask to bring up the D-channel.

 

As a last resort to resolve your PRI bouncing issue, you can re-configure your system using the wancfg_dahdi Sangoma configuration script (or via your WebGUI if you are using Elastix and FreePBX distro) contact Sangoma support at support.sangoma.com for more assistance.

 

Return to Documentation Home I Return to Sangoma Support