04/16: Troubleshooting T1 PRIs

Since the last article lightly covered some of the things that are necessary for configuring gateways and specifically configuring PRIs, we thought it would be nice to follow up with an article on troubleshooting PRIs. That's right, this week we will cover how to pinpoint the cause of PRI troubles and how to look at and interpret PRI debugging output. Let's get right down to some of the issues that you may face and how to address them:

Layer 1 Issues

The first and most basic issue that some people can run into with a PRI is physical connectivity. A simple way to check this out would be to check the light on the T1 card, but if you don't have access to it (for instance if you are remotely configuring it) a simple command can provide you with the information that you need. The command is: show isdn stat
The output from this command for an interface that has no physical connectivity is shown below:

Global ISDN Switchtype = primary-ni
ISDN Serial1/0/0:23 interface
dsl 0, interface ISDN Switchtype = primary-ni
Layer 1 Status:
DEACTIVATED
Layer 2 Status:
TEI = 0, Ces = 1, SAPI = 0, State = TEI_ASSIGNED
Layer 3 Status:
0 Active Layer 3 Call(s)
Active dsl 0 CCBs = 0
The Free Channel Mask: 0x00000000
Number of L2 Discards = 0, L2 Session ID = 42
Total Allocated ISDN CCBs = 0

The layer 1 status shows as DEACTIVATED and by that you know that for one reason or another the physical connectivity to the T1 interface on the other side (whether PSTN or PBX) is not up. This could be for a number of reasons including: the local interface being administratively shut down, the remote interface being disabled (which sometimes happens when a carrier puts a new PRI in and there isn't anything to connect it to), or a physical cabling issue. If the first two check out and show to be good, then you are left with cabling, which probably meanse that you need a T1 crossover cable, which is different than a regular data crossover cable. If you make your own cables and would like to make a T1 crossover cable, simply cross wires 1 and 2 (usually the white-orange and orange wires) with wires 4 and 5 (usually the blue and white-blue). One of those three solutions (checking local interface status, remote interface status and cabling) will usually resolve any layer 1 connectivity as long as there isn't some sort of hardware failure.

Layer 2 Issues

If you still have PRI issues once you have Layer 1 taken care of, then it's time to look at Layer 2. If your show isdn stat command does not show that the layer 2 status is MULTIPLE_FRAME_ESTABLISHED then you will need to start troubleshooting Layer 2. The first thing that I always like to do when troubleshooting an issue with Layer 2 is verify that the configuration information that I initially got from the carrier when the circuit was ordered is actually what shows up on the circuit now. Take a few minutes to call the carrier support line and verify the line coding, framing and ISDN switch-type for the PRI. If they do not match up, change the configuration on your gateway (whether MGCP or H.323) and check the status again. If they do match up and you are still not getting the multiple frame established, then enable the layer 2 debug by typing the following command:

debug isdn q921

This will show any layer 2 messages going back and forth between your T1 card and the T1 card on the carrier side. There are a couple of things that this debug will show you. If your PRI is bouncing up and down, those messages will show. If the connection status is stable, then verify that you are getting back and forth communication between your PRI card and the other end of the PRI card. Here is an example of something you might see:

Apr 7 23:45:19 UTC: ISDN Se1/0/0:23 Q921: User TX -> SABMEp sapi=0 tei=0

The TX in this debug output means that your router is transmitting a message. This specific message is a Set Asynchronous Balanced Mode Extended (SABME) message it is is attempting to start layer 2 communication with the other side of the circuit. If you do not receive an Q921 message back for SABME then you are not receiving messages back from the other end. Unfortunately, this is something that you need to put back on the carrier or the other side of the PRI in order to get it resolved. For some reason the other side of the link is not sending (or you are not receiving) the setup messages from their side and so layer 2 will never be fully established.

Other Issues

Once you have MULTIPLE_FRAME_ESTABLISHED on your PRI, you still may have issues receiving or placing calls. This is where another handy debug command comes into play:

debug isdn q931

Where the debug isdn q921 would debug layer 2 messages with the PRI, debug isdnq931 will show information pertaining to layer 3 of the PRI. Most of the information that you want to take a look at if the PRI is up but you are having issues is the information pertaining to the dial plan. Take a look at the information below:

Apr 7 23:51:08 UTC: ISDN Se1/0/0:23 Q931: RX <- SETUP pd = 8 callref = 0x03BC
Bearer Capability i = 0x8090A2
Standard = CCITT
Transer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA9838C
Exclusive, Channel 12
Calling Party Number i = 0x2183, '2145555555'
Plan:ISDN, Type:National
Called Party Number i = 0x80, '6699'
Plan:Unknown, Type:Unknown

From this, we can see that the calling party for this call is 2145555555 and the called number is 6699, so this is an incoming call. If we weren't sure about it from the calling and called party number, the first line above says RX so we are receiving the setup message from the carrier. The first thing that we need to do is determine that the call processor can handle the call to the number that is coming in. A lot of the issues that we see with this are maybe that the carrier is sending more digits than you have set up for extensions. Let's take a look at some of the ways to resolve dialplan issues:

If the number that the carrier is sending is too long, then there are several ways to handle it:

1. Significant Digits - If you go to the gateway configuration in CallManager, you can define the number of significant digits that CallManager should expect coming from the gateway. So in our example above, if we had three digit extensions we would just set significant digits to 3. This solution will work for both MGCP and H.323 gateways.

2. Translation Patterns - Another way to handle this is translation patterns. Again, using the example above, you would create a translation pattern for 6699 and the called party transform mask would be XXX or 699 if you wanted to be specific. This solution will also work for both MGCP and H.323 gateways.

3. Translation Profile - The last way that you can address this issue is by applying a translation profile on an H.323 gateway to the route pattern that would handle the call. This solution would only work on an H.323 gateway.

Other things to check for incoming calls to make sure that they work is just to make sure that the number is in the phone system and can be handled. Specifically with H.323 gateways, make sure that you have a route pattern that will handle any call that comes into the gateway that you want routed.

That wraps up this weeks overview of troubleshooting T1 PRIs. While there is much more information contained in the Q921 and Q931 traces, this should serve as a good primer to get you into troubleshooting these PSTN connections.

Category: Gateways | Posted by: John | 22 Comments