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

If you notice your PRI status is not coming up run through the following steps:

  1. 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.
     
  2. 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 


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

  4. 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
     
  5. 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
  • No labels