PRI- PRI Down

The first step is to verify that the physical layer of all the ports on your Sangoma card is up/active.  
Type the following in your Linux CLI:

-> wanrouter status

If your physical layer is up/active you will see the follow type of output

      * If the wanrouter status command fails, please visit the Wanpipe driver error page for assistance (and skip the next steps)

If your physical layer is down (or 'DISCONNECTED), this is the reason the your PRI is down, and go to wanpipemon line alarm status. for troubleshooting.
 

Check the Wanpipe network Interface for data processing issues. Run the ifconfig command and locate the wanpipe interface (w1g1,w2g1,w3g1..etc) and verify the Rx and Tx packets are incrementing.  Below is an example output of ifconfig for "w1g1"

w1g1      Link encap:Point-to-Point Protocol
              UP POINTOPOINT NOARP  MTU:1500  Metric:1
              RX packets:1232 errors:0 dropped:0 overruns:0 frame:0
              TX packets:1424 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0      txqueuelen:100
              RX bytes:0 (0.0 b)      TX bytes:0      (0.0 b)
              Interrupt:169 Memory:f8e20000-f8e21fff

If you do not see the above packets increment when you run "ifconfig" multiple times consecutively, then please contact Sangoma Technical Support at support.sangoma.com 

Register the wanpipe interfaces with the DAHDI signalling stack. Type the following in your Linux CLI
-> dahdi_cfg -vvv  

If you notice error messages after running the above commands, verify the configuration settings in /etc/dahdi/system.conf 

Confirm that Asterisk is able to detect all the DAHDI spans.  Enter the Asterisk CLI and type the following:
-> dahdi show channels 

If there is no output from the above, this means that chan_dahdi.so module was not able to load into Asterisk.  The next step is to parse chan_dahdi.conf file to find the error. 
For quick diagnosis try loading chan_dahdi.so into the asterisk CLI, and when that fails check the end of the asterisk log file for error:
-> module load chan_dahdi.so
-> vi /var/log/asterisk/messages

*Note: If you are using a binary distro (Trixbox, Elastix..) then the actual dahdi channels/zaptel channels are configured in dahdi-channels.conf/zap-channels.conf and#included into chan_dahdi.confg/zaptel.conf
RBS: for Robbed Bit Signaling.

Typically the solution here is to re-run the wancfg_dahdi script to reconfigure your entire Sangoma configuration. Then reload wanpipe and asterisk
 

Verify that all the DAHDI spans are "Up and Active".  
Type the following in the Asterisk CLI:

-> pri show spans 

If your PRI Spans are down, you will see a similar output to the below:

If a paricular span is not "Up and Active", then turn on span debugging in the Asterisk CLI to trace the D-channel message on that span in question.
-> pri set debug on span X  (replace X with the span)

Here you are trying to confirm that there are BOTH incoming and outgoing D-channel messages.  
Messages with arrows pointing towards the right of your Monitor (>) are outgoing and messages with arrows pointing to the Left of your Monitor (<) are incoming messages. 

The example below displays an output of pri set debug span 1 where only incoming message appear (<)

The information you gather here is only from the highest layer (asterisk).  Verifying the D-channel message flow in the Asterisk CLI is not enough proof to indicate an issue.  
You must also verify the same issue is occurring in the lower physical layer to prove if the issue is line related, by using the following command:

-> wanpipemon -i wXg1 -c trd  (replace X with the wanpipe interface in question)

Example of wanpipemon -i w1g1 -c trd for only inbound frames:

          Note: this command only works when Wanpipe is performing HDLC framing (which is configured by default)

Below are steps to follow depending on the scenario:

If there are only incoming frames: 
-> Verify your HDLC settings are consistent. If you are using hardware HDLC (as default), make sure you don't see software HDLC used anywhere in the layers
    -> Verify this by looking in the wanpipe configuration files (i.e /etc/wanpipe/wanpipeX.conf) and /etc/dahdi/system.conf 
    
For Hardware HDLC, you should see the following:

    WanpipeX.conf:
 

    TDMV_DCHAN= <signalling channel>   (not 0)

      system.conf
  

      hardhdlc= <signalling channel>

  For Software HDLC you should see the following:
  wanpipeX.conf
  

  TDMV_DCHAN=0

  system.conf
  

  dchan= <signallig channel>

If there are only outbound frames:
->contact you telco and confirm that the D-channel has been activated