Bsoft Bangalore: Troubleshooting T1 and E1 Problems

T1 or E1 Interface Troubleshooting
To troubleshoot the T1 or E1 interface, perform the following steps:

SUMMARY STEPS

show controller {t1 | e1}
Check if the line is down.
Check for reported alarms.
Check for error events.
Check if the interface is T1 or E1 CAS, E1 R2, or PRI.

DETAILED STEPS

1. Enter the show controller t1 or show controller e1 command with the controller number for the voice port you are troubleshooting.

 Router# show controller {t1 | e1} controller-number

2. Check if the line is down. If so, see the Troubleshooting T1 and E1 Layer 1 Problems.
3. Check if there are any reported alarms. If so, refer to T1 Alarm Troubleshooting, document ID 14172 to troubleshoot alarm indications.
4. Check if there are any error events. If you encounter framing, line coding, or clock timing errors, see the Checking T1/E1 Controller Configuration.
Refer to T1 Alarm Troubleshooting Flowchart, document ID 14174 for a flowchart to troubleshoot error events.
5. Check if the interface is T1 or E1 CAS, E1 R2, or PRI. See the following sections for more information:

Troubleshooting T1 and E1 Layer 1 Problems

Most T1 and E1 errors are caused by incorrectly configured lines. Ensure that line coding, framing, and clock source are configured according to the recommendations of your Service Provider.
Use the show controllers t1 and show controllers e1 commands in privileged EXEC mode to display information about the T1 or E1 links or to display the hardware and software driver information for the controller. These commands show what state the T1 or E1 controller is in. The controller can be in one of three states:

Administratively down-If the controller is administratively down, you can manually bring it up using the procedure in the Controller Is Administratively Down section.
Down-If the controller is down, then the cause is one of the following:
- Loss of frame-See the Controller Has Loss of Frame section to resolve this issue.
- Loss of signal-See the Controller Has Loss of Signal section to resolve this issue.
Up-The controller is functioning properly on Layer 1.

Solutions for bringing the controller up follow.

Controller Is Administratively Down

The controller is administratively down when it has been manually shut down. Follow these steps to restart the controller to correct this error.

SUMMARY STEPS

enable
configure {terminal | memory | network}
controller t1 number
no shutdown
end

DETAILED STEPS

1. Enable privileged EXEC mode: enable Example:

 Router> enable

Enter your password if prompted.
2. Enter global configuration mode:
configure terminal
Example:

Router(config)# configure terminal

3. Enter controller configuration mode:
controller t1 number
The number syntax is platform-specific. For more information about the syntax of this command, see the Cisco IOS Interface and Hardware Component Command Reference.
Example:

Router(config)# controller t1 0

4. Restart the controller: no shutdown
Example:

Router (config-controller)#  no shutdown

5. Exit to privileged EXEC mode: end
Example:

Router(config)# end

What to Do Next

The controller should be running and normal configuration can continue.

Controller Has Loss of Frame

Complete the following steps if the receiver has loss of frame:

Ensure that the framing format configured on the port matches the framing format of the line. Check the framing format of the controller from the running configuration or the show controller t1 or show controller e1 command output. To change the framing format, use the framing command in controller configuration mode.

For T1, the options are sf and esf. For example:

Router# configure terminal  
Enter configuration commands, one per line. End with CNTL/Z.  
 Router(config)# controller t1 0  
 Router(config-controlle)# framing esf

For E1, the options are crc4 and no-crc4. For example:

Router>configure terminal  
Enter configuration commands, one per line. End with CNTL/Z.  
Router(config)# controller e1 0  
Router(config-controlle)# framing crc4

If the first framing format does not work, try the other framing format to see if the alarm clears. For more information on framing formats, see the Framing Formats on Digital T1/E1 Voice Ports.

For T1 lines, change the line build-out setting using the cablelength long or cablelength short command.

Line build-out (LBO) or cable length compensates for the loss in decibels based on the distance from the device to the first repeater in the circuit. A longer distance from the device to the repeater requires that the signal strength on the circuit be boosted to compensate for loss over that distance.

To configure transmit and receive levels for a cable length (line build-out) longer than 655 feet for a T1 trunk with a channel service unit (CSU) interface, use the cablelength long controller configuration command. To configure transmit attenuation for a cable length (line build-out) of 655 feet or shorter for a T1 trunk with a DSX-1 interface, use the cablelength short controller configuration command.

Contact your service provider and refer to the Cisco IOS Interface and Hardware Component Configuration Guide for details on build-out settings.

What to Do Next

If the preceding steps do not fix the problem, see the Controller Has Loss of Signal section.

Controller Has Loss of Signal

If your controller is experiencing loss of signal, check the following.

Note:

Use the show controller t1 EXEC command after each step to see if the controller exhibits any errors.

Ensure that the cable between the interface port and the T1 service provider’s equipment or T1 terminal equipment is connected correctly. Ensure that the cable is hooked up to the correct ports. Correct the cable connections if necessary.
Check the cable integrity by looking for breaks or other physical abnormalities in the cable. Ensure that the pinouts are set correctly. Replace the cable if necessary.
Check the cable connectors. A reversal of the transmit and receive pairs or an open receive pair can cause errors. Depending on the type of module used, the cable terminates on a male DB-15 or RJ-45/48 connector.

On a DB-15 connector, the receive pair should be on pins 2 and 9, and the transmit pair on pins 8 and 15. A DB-15 connector is shown in Figure: DB-15 Connector.

Figure: DB-15 Connector

The pins on a RJ-45/48 jack are numbered from 1 through 8. With the metal pins facing toward you, pin 1 is the left-most pin. Figure: RJ-45 Pin Numbering shows the pin numbering on an RJ-45 jack. The receive pair should be on lines 1 and 2, and the transmit pair should be on lines 4 and 5.

Figure: RJ-45 Pin Numbering

If you have completed all of the steps above and you are still experiencing problems, try using a crossover cable. Crossover cable pinouts are shown in the Using the Cisco 2524-2525 Back-to-Back document. Additionally, you can try a rollover cable to check if the T1/E1 is passing through a reverse-wired wiring path. Pin locations are shown in Figure: Pin Location.

Figure: Pin Location

Checking T1/E1 Controller Configuration

Digital T1/E1 voice ports must have controller configurations that match the configuration of the router to the line characteristics of the telephony network connection being made so that voice and signaling can be transferred between them. This configuration also affects allows the logical voice ports, or DS0 groups, to be established. Make sure to check the following:

Contact your service provider for framing and line coding settings. Common settings are as follows:

For T1 lines, it is common to use binary 8-zero substitution (B8ZS) line coding with extended superframe (ESF), and alternate mark inversion (AMI) line coding with superframe (SF).
For E1 lines, both HDB3 and AMI line coding are available, but CRC4 framing is most widely used.

Framing Formats on Digital T1/E1 Voice Ports

The framing format parameter describes the way that bits are robbed from specific frames to be used for signaling purposes. The controller must be configured to use the same framing format as the line from the PBX or CO that connects to the voice port you are configuring.
Digital T1 lines use the SF or ESF framing format. SF provides two-state, continuous supervision signaling, in which a 0 bit value is used to represent on-hook and a 1 bit value is used to represent off-hook. ESF robs four bits instead of two, yet has little impact on voice quality. ESF is required for 64-kbps operation on DS0 and is recommended for Primary Rate Interface (PRI) configurations.
E1 lines can be configured for cyclic redundancy check (CRC4) or no cyclic redundancy check, with an optional argument for E1 lines in Australia.
To change the framing format, use the framing command in controller configuration mode. Refer to the Cisco IOS Voice Port Configuration Guide for configuration information.

Path Code Violations Increasing

Ensure that the framing format configured on the port matches the framing format of the line. Path code violations and line code violations are typically present simultaneously. Always verify that your line coding is correct. Look for the following in the show controller command output:

For E1 lines, look for “Framing is {crc4|no-crc4}”
For T1 lines, check the line coding, as described in the Line Coding on Digital T1/E1 Voice Ports. For T1 lines, path code violation error event is a frame synchronization bit error in the D4 (SF) format, or a CRC error in the ESF format.

If path code violations keep increasing, contact your service provider to check the line, because path code violations can also be caused by physical line problems.

Clock Sources on Digital T1/E1 Voice Ports

Digital T1/E1 interfaces use clock timers to ensure that voice packets are delivered and assembled properly. All interfaces handling the same packets must be configured to use the same source of timing so that packets are not lost or delivered late. The timing source that is configured can be external (from the line) or internal to the router’s digital interface.
If the timing source is internal, timing derives from the onboard phase-lock loop (PLL) chip in the digital voice interface. If the timing source is line (external), timing derives from the PBX or PSTN CO to which the voice port is connected. It is generally preferable to derive timing from the PSTN because PSTN clocks are maintained at an extremely accurate level. This is the default setting for the clock source. When two or more controllers are configured, one should be designated as the primary clock source; it drives the other controllers.
To change the clock source, use the clock source command in controller configuration mode. Refer to the Cisco IOS Voice Port Configuration Guide for configuration information.

Slip Seconds Error Counter Increasing

Use the show controller command to see if there are alarms or errors displayed by the controller. To see if the framing, line coding, and slip seconds error counters are increasing, use the show controller e1 command repeatedly. Note the values of the counters for the current interval.
If slips are present on the line, there is a clocking problem. The customer premises equipment (CPE) needs to synchronize to the clocking from the T1/E1 service provider. Complete the following steps to correct this problem:

SUMMARY STEPS

enable
show controller
configure terminal
controller {t1 | e1}
clock source {line [primary | secondary} | internal}

DETAILED STEPS

1. Enter enable to enter privileged EXEC mode. Enter a password, if necessary.
2. Ensure that the clock source is derived from the network. In the show controller EXEC command output, look for "Clock Source is Line Primary."

Note:

If there are multiple lines into an access server, only one can be the primary source. The other lines derive the clock from the primary source. If there are multiple lines, ensure that the line designated as the primary clock source is configured correctly. You can also configure a second line to provide clocking in case the primary source goes down. To do this, use the clock source line secondary command from controller configuration mode.

3. Enter configure terminal to enter global configuration mode.
4. Enter controller t1 or controller e1 to enter controller configuration mode.
5. Set both the primary and secondary clock sources from controller configuration mode. For example:

 Router(config-controlle)#clock source line primary

and

 Router(config-controlle)#clock source line secondary 1

Ensure that the lines that you specify as the primary and secondary are both active and stable.

Note:

On Cisco universal gateways and access servers, the clock source is specified using the dial-tdm-clock command. Refer to the "Managing Dial Shelves" chapter in the Cisco IOS Interface Configuration Guide.

Framing Loss Seconds Increasing

Follow these instructions when dealing with a framing loss seconds increase:

SUMMARY STEPS

enable
show controller
configure terminal
controller {t1 | e1}
framing {sf | esf} or framing {crc4|no-crc4}
cablelength {long|short}

DETAILED STEPS

1. Enter enable to enter privileged EXEC mode. Enter a password, if necessary.
2. Ensure that the framing format configured on the port matches the framing format of the line. Look for the following in the show controller output

For T1 lines, look for "Framing is {ESF|SF}"
For E1 lines, look for "Framing is {crc4|no-crc4}"

3. Enter configure terminal to enter global configuration mode.
4. Enter controller t1 or controller e1 to enter controller configuration mode.
5. To change the framing format, use the following commands in controller configuration mode:

For T1 lines, use framing {sf | esf}. For example:

 Router(config-controlle)#framing esf

For E1 lines, use framing {crc4|no-crc4}. For example:

 Router>(config-controller)#framing crc4

6. For T1 lines, change the line build-out using the cablelength long or cablelength short command.
Contact your service provider and consult the Voice Port Configuration Guide for details on settings.

Line Coding on Digital T1/E1 Voice Ports

Digital T1/E1 interfaces require that line encoding be configured to match that of the PBX or CO that is being connected to the voice port. Line encoding defines the type of framing used on the line.
T1 line encoding methods include alternate mark inversion (AMI) and binary 8 zero substitution (B8ZS). AMI is used on older T1 circuits and references signal transitions with a binary 1, or "mark." B8ZS, a more reliable method, is more popular and is recommended for PRI configurations as well. B8ZS encodes a sequence of eight zeros in a unique binary sequence to detect line-coding violations.
Supported E1 line encoding methods are AMI and high-density bipolar 3 (HDB3), which is a form of zero-suppression line coding.
Use the show controller command to see if there are alarms or errors displayed by the controller. To see if the framing, line coding, and slip seconds error counters are increasing, use the show controller command repeatedly. Note the values of the counters for the current interval.

Line Code Violations Increasing

Ensure that the line coding configured on the port matches the line coding of the line. Change the line code in controller configuration mode if necessary.

For E1 lines, look for "Line Code is HDB3" in the show controller e1 output.
For T1 lines, look for "Line Code is {B8ZS|AMI}" in the show controller t1 output.

For T1 lines, change the line build-out using the cablelength long or cablelength short command.
If line code violations keep increasing, contact your service provider to check the line, because line code violations can also be caused by physical line problems.

Path Code Violations Increasing

Ensure the framing format configured on the port matches the framing format of the line. Path code violations and line code violations are typically present simultaneously. Always verify that your line coding is correct. Look for the following in the show controller output:

For T1 lines, look for "Line Code is {B8ZS|AMI}"

For T1 lines, path code violation error event is a frame synchronization bit error in the D4 (SF) format, or a CRC error in the ESF format.

For E1 lines, check the framing as described in the Framing Formats on Digital T1/E1 Voice Ports.

For T1 lines, change the line build-out using the cablelength long or cablelength short command.
If path code violations keep increasing, contact your service provider to check the line. Path code violations can also be caused by physical line problems.

T1/E1 Channel-Associated Signaling

CAS exists in many networks today. CAS systems carry signaling information in the same channels in which voice and data are carried. Current telecommunication networks require more efficient means of signaling. CAS exists in many varieties that operate over analog and digital facilities. The analog facilities are either two- or four-wire, and the digital facilities are either North American T1 or European E1. Each CAS system uses either supervision signaling or address signaling over analog and digital facilities.
Three groups of signals are present in these facilities:

Supervision signals represent events occurring on a trunk and can be specific to CAS. Signal types include seizure, wink, and answer.
Address signals represent the digits dialed or called party number and, in some instances, other information. Address signals are based on multiflex signaling.
Tone and announcement signals include ringing and busy tones and announcements specific to an event. Service circuits are used in most exchanges to send and receive address signals and tones as well as to play announcements.

This section describes CAS signaling, which is sometimes called robbed-bit signaling because user bandwidth is robbed by the network for signaling. A bit is taken from every sixth frame of voice data to communicate on- or off-hook status, wink, ground start, dialed digits, and other information about the call.
In addition to setting up and tearing down calls, CAS provides for the receipt and capture of dialed number identification (DNIS) and automatic number identification (ANI) information, which are used to support authentication and other functions. The main disadvantage of CAS signaling is its use of user bandwidth to perform these signaling functions.
For more information about troubleshooting CAS, refer to Configuring and Troubleshooting T1 CAS Signaling, document ID 24642.
If your CAS-configured router gets stuck in the EM_PARK state, refer to Troubleshooting EM_PARK Issues for E&M Digital CAS Signaling, document ID 18959.

Troubleshooting Commands

Certain show commands are supported by the Output Interpreter tool, which allows you to view an analysis of show command output.

debug voip ccapi inout-Traces the execution path through the call control API, which serves as the interface between the call session application and the underlying network-specific software. You can use the output from this command to understand how calls are being handled by the router.
debug vpm all-Enables all of the debug vpm commands: debug vpm spi, debug vpm signal, and debug vpm dsp.

Note:

This debug command generates a large amount of output.

show call active voice-Displays the contents of the active call table, which shows all of the calls currently connected through the router.
show call history voice-Displays the call history table. The call history table contains a listing of all calls connected through this router in descending time order since VoIP was enabled. You can display subsets of the call history table by using specific keywords.
show voice port-Displays configuration information about a specific voice port.
debug vtsp all-Enables the following debug vtsp commands: debug vtsp session, debug vtsp error, and debug vtsp dsp.

E1 R2 Interfaces

R2 signaling is a CAS system developed in the 1960s and still in use today in Europe, Latin America, Australia, and Asia. R2 signaling exists in several country versions or variants in an international version called Consultative Committee for International Telegraph and Telephone-R2 (CCITT-R2). The R2 signaling specifications are contained in International Telecommunication Union Telecommunication Standardization Sector (ITU-T) Recommendations Q.400 through Q.490. E1 R2 signaling is an international signaling standard that is common to channelized E1 networks.
E1 R2 signaling support allows the Cisco gateways to communicate with a central office (CO) or PBX trunk and act as a tie-line replacement. Although R2 signaling has been defined in ITU-T Q.400-Q.490 recommendations, R2 is implemented in many different ways. (Various countries implement R2 differently.) Cisco's implementation of R2 signaling on routers can accommodate most of the variations.

Troubleshooting E1 R2 Failures

Follow the instructions below to troubleshoot your configuration.

SUMMARY STEPS

show controller e1
show vfc slot number interface
Configure DID on the POTS peer.
cptone
Match line and register signaling provisions to the switch configuration.
Turn on appropriate debugs.
Check for communication between the router and PBX or switch.

DETAILED STEPS

1. Verify that controller E1 0 is up with the show controller e1 0 command.
If it is down, check framing, line coding, clock source, and alarms. Replace the cable and reseat the card. To run these tests, see the following sections:

2. If you are using an AS5300, check that the DSPs are correctly installed with the show vfc slot number interface command.
3. Configure direct inward dial (DID) on the plain old telephone service (POTS) peer, so that the received digits are used to choose an outgoing peer.
4. Specify cptone'(cptone is specific for your country) on the voice-ports.
A cptone country must be configured to match cas-custom country. The cptone parameter sets the call progress tones for a particular country, and more importantly sets the encoding to a-law or u-law, depending on the country. For u-law, use the us keyword. For a-law, use the gb keyword. To configure cptone, see the Voice Port Configuration Guide.
5. Match line and register signaling provisions to the switch configuration.
6. Turn on some of the debugs shown in the following section and study the outputs.
7. Check for communication between the router and PBX or switch:

Is the line seized?
Does the router receive/send digits?
Find out which side is clearing the call.

If possible, use the latest Cisco IOS software release.

debug and show Commands

Certain show commands are supported by the Output Interpreter Tool, which allows you to view an analysis of show command output.
For Cisco IOS Software Release 12.0 and newer, use the following debugs:

debug cas-For line signaling
debug csm voice-For interregister signaling
debug vtsp all -Exchanges output of all messages (digits) between the PBX and the router

For Cisco IOS Software Release IOS 11.3, use the following commands:

modem-mgmt csm debug-rbs -For line signaling (specify service internal in global configuration mode.)
debug csm voice - For interregister signaling
debug vtsp all -Exchanges output of all messages (digits) between the PBX and the router

For the AS5400 and AS5350 platforms, use the following debugs:

debug sigsm r2-For interregister signaling
debug vtsp all -Exchanges output of all messages (digits) between the PBX and the router

ISDN Interfaces

An ISDN network can consist of T1, T3, E1, and E3 and has two types of subscriber access: Basic Rate Interface (BRI) and Primary Rate Interface (PRI). Each access comprises B and D channels.
ISDN BRI provides two B channels, each capable of transferring voice or data at 64 kbps, and one 16-kbps D channel that carries signaling traffic. The D channel is used by the telephone network to carry instructions about how to handle each of the B channels. ISDN BRI (also referred to as "2 B + D") provides a maximum transmission speed of 128 kbps.
ISDN PRI provides 23 B channels plus a D channel (in North America and Japan) or 30 B channels plus a D channel (in the rest of the world). Similar to the ISDN BRI D channel, the ISDN PRI D channel carries signaling traffic. ISDN PRI is often referred to as "23 B + D" (in North America and Japan) or "30 B + D" (in the rest of the world). The D channel notifies the central office switch to send the incoming call to particular time slots on the Cisco access server or router. Each one of the B channels carries data or voice. The D channel carries signaling for the B channels. The D channel indicates whether the call is a circuit-switched digital call or an analog modem call. Analog modem calls are decoded and then sent to the onboard modems. Circuit-switched digital calls are relayed directly to the ISDN processor in the router.
The ISDN interfaces for Cisco gateways enable Cisco IOS software to replicate the PSTN interface to a PBX that is compatible with European Telecommunications Standards Institute (ETSI) NET3 and QSIG switch types.
The application shown in Figure: Typical Application Using ISDN BRI NT/TE VICs or ISDN BVMs allows enterprise customers with a large installed base of legacy telephony equipment to bypass the PSTN.

Figure: Typical Application Using ISDN BRI NT/TE VICs or ISDN BVMs

Topics for ISDN voice troubleshooting are as follows:

ISDN PRI Troubleshooting Tips

If you are having trouble connecting a call and you suspect that the problem is associated with voice port configuration, you can try to resolve the problem by performing the following tasks:

Ping the associated IP address to confirm connectivity.
Determine if the voice feature card (VFC) has been correctly installed. For more information, refer to Installing Voice-over-IP Feature Cards in Cisco AS5300 Universal Access Servers.
To learn if the VFC is operational, use the show vfc slot_number command.
To view layer status information, use the show isdn status command. If you receive a status message stating that Layer 1 is deactivated, make sure the cable connection is not loose or disconnected.
With T1 lines, determine if your a-law setting is correct. With E1 lines, determine if your u-law setting is correct. To configure both a-law and u-law values, use the cptone command. For more information about the cptone command, refer to the Cisco IOS Voice Command Reference.
If dialing cannot occur, use the debug isdn q931 command to check the ISDN configuration.

For more information about troubleshooting T1 PRI, refer to T1 PRI Troubleshooting, document ID 9344.

Verifying the ISDN Switch Type and PRI Group Timeslot Configuration

Use the show running-config command to ensure that isdn switch-type and pri-group timeslots are configured correctly. To specify the central office switch type on the ISDN interface, use the isdn switch-type global configuration command. Options for this command include primary-net5. Contact your service provider for the correct values to use.

Note:

If you have defined ISDN PRI groups and channel groups on the same controller, ensure that you do not overlap time slots or use the ISDN D-channel timeslot in a channel group. When configuring a Primary Rate Interface (PRI), use the isdn switch-type global configuration command to configure the switch type.

To configure the isdn switch-type and pri-group:

 Router# configure terminal  
 Router(config)# isdn switch-type primary-net5
 Router(config)# controller e1 0
 Router(config-controlle)# pri-group timeslots 1-31

Note:

In some countries, service providers offer fractional PRI lines. This means that fewer than 30 B-channels may be used for ISDN connections. For fractional PRI lines, the time slot range must include the operational B channels, plus the D channel (this is fixed on time slot 16).

For example:

pri-group timeslots 1-10, 16 for the first ten B-channels.
timeslots 1-21 for the first 20 B-channels.

Verifying the Signaling Channel

If the error counters do not increase, but the problem persists, complete the following steps to verify that the signaling channel is up and configured correctly

SUMMARY STEPS

show interfaces serial number :15
Ensure that the interface is up.
Ensure that encapsulation is PPP.
Ensure that the interface is not in loopback mode.
Power cycle the router.
Turn on appropriate debugs.
Contact TAC.

DETAILED STEPS

1. Run the show interfaces serial number:15 command, where the number is the interface number.
2. Ensure that the interface is up. If the interface is not up, use the no shutdown command to bring the interface up. For example:

 Router# config terminal  
 Enter configuration commands, one per line. End with CNTL/Z.  
 Router(config)# interface serial 0:15
 Router(config-if)# no shutdown

3. Ensure that encapsulation is PPP. If not, use the encapsulation ppp command to set encapsulation. For example:

 Router(config-if)# encapsulation ppp

4. Ensure that the interface is not in loopback mode. Loopback should be set only for testing purposes. Use the no loopback command to remove loopbacks. For example:

 Router(config-if)# no loopback

5. Power cycle the router.
6. Turn on appropriate debugs.
7. If the problem persists, contact your service provider or the Cisco Technical Assistance Center (TAC).

Ringback

In some situations, a gateway might intermittently fail to provide ringback tone (RBT) to an incoming ISDN caller. This problem has been seen on local, long-distance, and international calls.
The gateway generates ringback towards the network side (PSTN or PBX) if the setup contains Progress IE = 3, meaning the originating address (calling party) is NON-ISDN.
The gateway does not generate a ringback towards the network side (PSTN or PBX) if the setup contains no Progress IE (Progress IE =0), meaning the originating address (calling party) is ISDN.
The following figure is an example of when this might occur. International calls are arriving on ISDN.
PSTN (ISDN) --------- Cisco IOS gateway ------------ Cisco CallManager ------------ IP phone

Example of a Call That Gets Ringback Tone

You receive a call from a non-ISDN terminal. The setup contains a Progress IE = 3. The gateway generates ringback when it receives an alert from Cisco CallManager.
The following debugs were captured with the Cisco IOS command debug isdn q931:

 01:34:48: ISDN Se0:15: RX <- SETUP pd = 8 callref = 0x002B  
 01:34:48: Sending Complete  
 01:34:48: Bearer Capability i = 0x9090A3  
 01:34:48: Channel ID i = 0xA9838D  
 01:34:48: Progress Ind i = 0x8583 - Origination address is non-ISDN  
 01:34:48: Calling Party Number i = 0x2183, '27045000', Plan:ISDN, Type:National  
 01:34:48: Called Party Number i = 0xA1, '27182145', Plan:ISDN, Type:National  
 01:34:48: ISDN Se0:15: TX -> CALL_PROC pd = 8 callref = 0x802B  
 01:34:48: Channel ID i = 0xA9838D  
 01:34:48: act_alert: Tone Ring Back generated in direction Network One  
 01:34:48: act_gen_tone: Tone Ring Back generated in direction Network  
 01:34:48: ISDN Se0:15: TX -> ALERTING pd = 8 callref = 0x802B

Example of a Call That Does Not Get Ringback Tone

You receive a call from an ISDN terminal. There is no Progress IE in the setup. (Progress IE = 0). The gateway is not generating ringback when it receives the alert from Cisco CallManager.

 01:37:01: ISDN Se0:15: RX <- SETUP pd = 8 callref = 0x002E  
 01:37:01: Sending Complete  
 01:37:01: Bearer Capability i = 0x8090A3  
 01:37:01: Channel ID i = 0xA98391  
 01:37:01: Calling Party Number i = 0x2183, '478681058', Plan:ISDN, Type:International  
 01:37:01: Called Party Number i = 0xA1, '27182145', Plan:ISDN, Type:International  
 01:37:01: High Layer Compat i = 0x9181  
 01:37:01: ISDN Se0:15: TX -> CALL_PROC pd = 8 callref = 0x802E  
 01:37:01: Channel ID i = 0xA98391  
 01:37:01: ISDN Se0:15: TX -> ALERTING pd = 8 callref = 0x802E

In the case above, the gateway is expecting the ISDN to generate the ringback (due to no PI of 3). The ISDN, however, is not generating a ringback tone. This results in the caller hearing only silence until the called party answers the call. This might be due to an ISDN interworking issue caused because the call originated internationally (normally ring is generated at the terminating device for international calls).

Forcing Ringback

You can force the gateway to generate a ringback with the progress_ind setup enable 3 command. Configure the forced ringback on the VoIP dial peer that points to Cisco CallManager.

 !  
 dial-peer voice 500 voip  
 destination-pattern 5...  
 progress_ind setup enable 3  
 !--forces ring back tone for this peer  
 session target ipv4:10.200.73.15  
 codec g711ulaw  
 !

For more information, refer to PSTN Callers not Hearing any Ring Back When they Call IP Phones, document ID 8331.

QSIG Protocol Support

QSIG is a peer-to-peer signaling system used in corporate voice networking. Internationally, QSIG is known as Private Signaling System No. 1 (PSS1). This open standard is a variant of ISDN D-channel voice signaling that is based on the ISDN Q.921 and Q.931 standards. Therefore, as well as providing inter-PBX communications, QSIG is compatible with public and private ISDN systems.
QSIG also has one important mechanism known as Generic Functional Procedures (QSIG GF). This mechanism provides a standard method for transporting features transparently across a network.
Integration of QSIG protocol support with Cisco voice switching services allows Cisco devices to connect PBXs, key systems, and central office switches (COs) that communicate by using the QSIG protocol. With QSIG, Cisco networks emulate the functionality of the PSTN, and QSIG signaling messages allow the dynamic establishment of voice connections across a Cisco WAN to a peer router, which can then transport the signaling and voice packets to a second PBX, as shown in Figure: QSIG Signaling.

Figure: QSIG Signaling

The Cisco voice packet network appears to the traditional QSIG PBXs as a distributed transit PBX that can establish calls to any PBX, non-QSIG PBX, or other telephony endpoint served by a Cisco gateway, including non-QSIG endpoints.

QSIG Support Troubleshooting Tips

Table: QSIG Troubleshooting Commands lists debug and show commands that can help you analyze problems with your QSIG configuration.

Table: QSIG Troubleshooting Commands

!Command	!Purpose
show isdn status	Displays the status of all ISDN interfaces, including active layers, timer information, and switch type settings.
show controller t1/e1	Displays information about T1 and E1 controllers.
show voice port summary	Displays summary information about voice port configuration.
show dial-peer voice	Displays how voice dial peers are configured.
show cdapi	Displays the Call Distributor Application Programming Interface (CDAPI) information.
show call history voice record	Displays information about calls made to and from the router.
show rawmsg	Displays information about any memory leaks.
debug isdn event	Displays events occurring on the user side (on the router) of the ISDN interface. The ISDN events that can be displayed are Q.931 events (call setup and teardown of ISDN network connections).
debug tsp	Displays information about the telephony service provider (TSP).
debug cdapi {events \| detail}	Displays information about CDAPI application events, registration, messages, and so on.

Troubleshooting Drop-and-Insert

When a router is configured for drop-and-insert, also called TDM cross connect, traffic is passed as a transparent bit stream between the configured ports. The router acts as a conduit between the ports, ensuring that the bit stream and clocking are preserved. Because of this, there are no commands to monitor traffic or debug signaling bits. You can confirm the physical status of the T1 interfaces (carrier loss) and line quality (line errors, clock slips, framing errors) using the show controller t1 slot/port command.
You can connect the PBX directly to the voice mail system to isolate signaling problems. If the system is still not working when the router has been bypassed, you might need to use T1 analyzers (for example, the Acterna Tberd T1 analyzer) to verify that the PBX or voice mail system is sending the correct information on the T1 trunk. You can also use the analyzer to verify that the drop-and-insert feature is working correctly from one port to the other.
For more information on troubleshooting drop-and-insert, refer to Integrating PBXs into VoIP Networks Using the TDM Cross Connect Feature, document ID 27789.

Troubleshooting Transparent Common Channel Signaling

Transparent Common Channel Signaling (T-CCS) allows the connection of two PBXs with digital interfaces that use a proprietary or unsupported CCS protocol without the need for interpretation of CCS signaling for call processing.
With T-CCS, the PBX voice channels can be "nailed-up" and compressed between sites, and the accompanying signaling channel(s) can be transparently tunneled across the IP/FR/ATM backbone between PBXs. Thus, calls from the PBXs are not routed by Cisco on a call-by-call basis but follow a preconfigured route to the destination.
For information about troubleshooting T-CCS, refer to Configuring and Troubleshooting Transparent CCS, document ID 19087.

Dial Tone Issues

This section discusses troubleshooting of the voice network when no dial tone is heard from a voice port that is in the off-hook condition. Some issues include:

A common problem in the voice network involves no dial tone being heard from a voice port in the off-hook condition. This might be related to configuration issues, a hardware problem, a DSP problem, or a bug in Cisco IOS software. A voice port configured with connection trunk does not provide dial tone. A faulty network module or Foreign Exchange Station (FXS) card might cause silence or no dial tone in a voice port.
For more information, refer to Troubleshooting No Dial Tone Issues, document ID 22372.
The following sections describe these various problems and related solutions.

Router Does Not Recognize Voice Port

When a router does not recognize a voice port, it might be because the router is not loaded with the Cisco IOS image required for voice support. In the case of a Cisco 1750 router, make sure that it does not have PVDM-256K-4 and PVDM-256K-8 DSPs. These are packet voice/data modules (PVDMs) for Cisco routers 1751 and later. If the Cisco 1750 router does not have the correct PVDM, the voice ports might show up in show version and show diag command output, however, there is no dial tone. Also, no DSPs are seen in the show voice dsp command output. The Cisco 1750 router should carry the proper PVDM-4 and PVDM-8 DSP cards.
For Cisco modular access routers , another problem could be a bad network module. If there is an alarm light on the network module, remove the module, put it back in the slot and power cycle. If the alarm light is still lit, replace the network module. Also, try plugging an analog phone into the FXS port with a good cable. If there is no dial tone, replace the FXS card.

Note:

FXS-Direct Inward Dialing (DID) does not provide dial tone.

Voice Ports Are in the Shutdown State

When voice ports are in the shutdown state, they do not provide dial tone. To fix this, enable the voice port with the no shut command under the voice port.

Voice Ports Configured as Connection Trunk

If voice ports are configured as connection trunk, the ports are in the S_TRUNKED state. Voice ports do not provide dial tone if configured for connection private line auto ringdown (PLAR). Use the show voice call summary command to verify the VPM state. In the example below, the dial-tone is given by the remote PBX/PSTN.

 Router# show voice call summary
 PORT CODEC VAD VTSP STATE VPM STATE  
 ==== ===== === ========== ==========  
 1/0/0 g729ar8 y S_CONNECT S_TRUNKED  
 1/0/1 g729ar8 y S_CONNECT S_TRUNKED

Remove the connection trunk/PLAR configuration to ensure that you are getting the dial-tone.

No Dial Tone on Digital Voice Port

Use the show dial-peer command to see if the dial-peer ports are configured with the direct-inward-dial command. This command disables dial tone from the voice port. For example:

 dial-peer voice 1 pots  
 destination-pattern .T  
 direct-inward-dial  
 port 0:D

Removing the direct-inward-dial command from dial-peer pots causes the digital voice port to provide dial tone.

Debug Command Output Shows VTSP Timeout

The VTSP and DSP timeouts are known issues that appear in many forms. Use the test dsps slot# command to see if processors are alive. Cisco IOS Releases 12.2.6a [12.2.6cM1] and later include fixes for many of these issues, but possibly not all. The problem can be temporarily cleared by a power cycle. If you experience this problem, you should open a case with the Cisco Technical Assistance Center (TAC).

Total Pageviews

Wednesday, 17 October 2012

Troubleshooting T1 and E1 Problems

SUMMARY STEPS

DETAILED STEPS

Troubleshooting T1 and E1 Layer 1 Problems

Controller Is Administratively Down

SUMMARY STEPS

DETAILED STEPS

What to Do Next

Controller Has Loss of Frame

What to Do Next

Controller Has Loss of Signal

Figure: DB-15 Connector

Figure: RJ-45 Pin Numbering

Figure: Pin Location

Checking T1/E1 Controller Configuration

Framing Formats on Digital T1/E1 Voice Ports

Path Code Violations Increasing

Clock Sources on Digital T1/E1 Voice Ports

Slip Seconds Error Counter Increasing

SUMMARY STEPS

DETAILED STEPS

Framing Loss Seconds Increasing

SUMMARY STEPS

DETAILED STEPS

Line Coding on Digital T1/E1 Voice Ports

Line Code Violations Increasing

Path Code Violations Increasing

T1/E1 Channel-Associated Signaling

Troubleshooting Commands

E1 R2 Interfaces

Troubleshooting E1 R2 Failures

SUMMARY STEPS

DETAILED STEPS

debug and show Commands

ISDN Interfaces

Figure: Typical Application Using ISDN BRI NT/TE VICs or ISDN BVMs

ISDN PRI Troubleshooting Tips

Verifying the ISDN Switch Type and PRI Group Timeslot Configuration

Verifying the Signaling Channel

SUMMARY STEPS

DETAILED STEPS

Ringback

Example of a Call That Gets Ringback Tone

Example of a Call That Does Not Get Ringback Tone

Forcing Ringback

QSIG Protocol Support

Figure: QSIG Signaling

QSIG Support Troubleshooting Tips

Table: QSIG Troubleshooting Commands

Troubleshooting Drop-and-Insert

Troubleshooting Transparent Common Channel Signaling

Dial Tone Issues

Router Does Not Recognize Voice Port

Voice Ports Are in the Shutdown State

Voice Ports Configured as Connection Trunk

No Dial Tone on Digital Voice Port

Debug Command Output Shows VTSP Timeout

No comments:

Post a Comment