This section is only applicable to troubleshooting ISDN BRI Layer 1 deactivated status. If the ISDN BRI Layer 1 is up and active as shown in the show isdn status EXEC command, kindly proceed to Troubleshooting ISDN BRI Layer 2.
Detailed information on ISDN Layer 1 states and signals are defined in the ITU-T I.430 standard.
The show controller bri {num} EXEC command is used for advanced ISDN Layer 1 troubleshooting by displaying the information about the ISDN Layer 1 activation status.
Router>sh controllers bri0/0 BRI unit 0: Layer 1 is ACTIVATED. (ISDN L1 State F7) --- output omitted ---
Use the following table to interpret the ISDN Layer 1 states:
| L1 State | L1 State Name | L1 State Description |
| F1 | Inactive | In this inactive (powered off) state, the terminal equipment (TE) is not transmitting and cannot detect the presence of any input signal. |
| F2 | Sensing | This state is entered after the TE has been powered on but has not determined the type of signal (if any) that the TE is receiving. When in this state, a TE may go into a lower power consumption state. |
| F3 | Deactivated | This is the deactivated state of the physical protocol. Neither the network termination (NT) nor the TE is transmitting. When in this state, a TE may go to a low power consumption mode. |
| F4 | Awaiting Signal | When the TE wishes to initiate activation, it sends an Activation signal to the NT and awaits a response. |
| F5 | Identifying Input | At the first receipt of any signal from the NT, the TE stops sending Activation signals and awaits the activation signal or synchronized frame from the NT. |
| F6 | Synchronized | When the TE has received an Activation signal from the NT, it responds with a synchronized frame and is awaiting a synchronized frame from the NT. |
| F7 | Activated | This is the normal active state, with the protocol activated in both directions. Both the NT and the TE are transmitting normal frames. State F7 is the only state where the B and D channels contain operational data. |
| F8 | Lost Framing | This is the condition when the TE has lost frame synchronization and is awaiting re-synchronization. |
Note: Most of the ISDN Layer 1 states are temporary and can be cleared with the clear interface bri {num} privileged command or a router reboot. Contact the Telco for further troubleshooting if those states persist for a long period.
Troubleshooting ISDN E1/T1 Physical Layer Alarms and Error Events
This section explains the common alarm types and error events that may appear during the operations of ISDN E1/T1 as well as the troubleshooting techniques.
The show controller e1 | t1 {num} EXEC command displays the controller status specific to the controller hardware, error statistics about the E1/T1 link, local or remote alarm information, and information for identifying and troubleshooting ISDN physical and data link layer problems.
Issue the show controller e1 | t1 {num} EXEC command repeatedly to see if the counters for the frame loss, line code, and slip seconds errors and various alarms are increasing for a particular duration of time, eg: 1 minute, 5 minutes.
Below shows the sample output of the show controller e1 | t1 {num} EXEC command. The output comprises of the alarm and error event sections.
Router>sh controller e1 E1 1/0 is up. Applique type is Channelized E1 - balanced No alarms detected. alarm-trigger is not set Framing is CRC4, Line Code is HDB3, Clock Source is Line. Module type is Channelized E1/T1 PRI Version info Firmware: 0000001D, FPGA: C Hardware revision is 0.0 , Software revision is 29 Protocol revision is 1 number of CLI resets is 16 Last clearing of alarm counters 1d22h receive remote alarm : 0, transmit remote alarm : 0, receive AIS alarm : 0, transmit AIS alarm : 0, loss of frame : 0, loss of signal : 0, Loopback test : 0, transmit AIS in TS 16 : 0, receive LOMF alarm : 0, transmit LOMF alarm : 0, MIB data updated every 10 seconds. Data in current interval (443 seconds elapsed): 0 Line Code Violations, 0 Path Code Violations 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs Total Data (last 24 hours) 0 Line Code Violations, 0 Path Code Violations, 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins, 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs Router>
Contact the Telco for encoding and framing settings. HDB3 is the only defined encoding scheme for E1 links, while CRC4 framing format is most widely used. Look for Clock Source is Line in the output of the show controller e1 | t1 {num} EXEC command to verify that the clocking is derived from the Telco.
Alarms are serious conditions that require attentions. Excessive errors, hardware problems, and signal disruption can trigger alarms. The alarms are coded as colors. Different vendors define alarm differently, and finding the details descriptions of the alarms can be challenging. RFC 1232 describes most alarms; however, they are defined for use in SNMP and are not intended to become a standard for hardware implementation.
A Red Alarm is triggered when a Loss of Signal (LoS) or Loss of Frame (LoF) error is detected. After a local device has a red alarm, it would send a yellow alarm to the far-end. When the far-end receives the yellow alarm, it would trigger a yellow alarm.
Note: A red alarm is usually indicated on the opposite end of the yellow alarm, and vice versa.
Loss of Signal (LoS) is the state where no electrical pulses have been detected – the line is dead, there is no alarm and signal. LoS is equivalent to not connecting any cable to the interface.
Loss of Frame (LoF) indicates that a certain number of frames have been received with framing bits in error. The data is considered garbage as the synchronization between both ends is invalid.
A sample scenario of red alarm is when something has failed on an ISDN switch, the switch would trigger a local red alarm and sends out yellow alarm signal to alert the neighboring router regarding the problem. Another sample scenario is when an ISDN switch is sending garbled frame to the neighboring router, which sees consecutive LoF errors and declares a red alarm. When the router declares a red alarm, a yellow alarm is sent back out across the link.
Interpreting the behaviors of red alarms can be challenging and confusing. Generally, a red alarm indicates that there is a problem happening on the local device. However, the router in the 2nd scenario above was receiving too much LoF errors until it is unable to recognize the signals and frames from the ISDN switch.
A Yellow Alarm is also known as a Remote Alarm Indication (RAI). A yellow alarm is declared when a yellow alarm signal is received from the far-end. A yellow alarm does not necessarily indicate a problem on the local device; rather there is a problem at the far-end device, which has declared a red alarm and notifies the local device. Generally, a yellow alarm indicates that the far-end receiver is in a LoS or LoF state. When the receiver experiences LoS or LoF, the transmitter sends a yellow alarm. The circuit is considered as a one-way link – the transmitting line towards the far-end device is experiencing problem while the transmitting line towards the local device is functioning as it is able to receive the Yellow Alarm signal.
Note: A yellow alarm is usually indicated on the opposite end of the red alarm, and vice versa.
A Blue Alarm is also known as an Alarm Indication Signal (AIS). RFC 1232 does not define about this condition. A blue alarm is triggered when the receiver receives an AIS. Generally, a blue alarm indicates that there is a problem upstream. An AIS in a framed or unframed all-1s signal which is transmitted to maintain transmission continuity. It typically occurs when the far-end CSU has lost its terminal side equipment or a cable is disconnected.
The blue alarm is often sent from the service provider to both ends of the circuit to notify them that there is a problem within the service provider’s network.
Below addresses ISDN E1/T1 controller alarms along with the procedures to correct them:
| Receive Alarm Indication Signal (rxAIS) | Indicates that a stream of framed or unframed all-1s signal is received. This problem should be cleared when the LoF error is rectified. Change the framing format with the framing {esf | sf | crc4 | no-crc4} interface subcommand. |
| Receive Remote Alarm Indication (rxRAI) | Indicates that the far-end device has a problem with the signal which is receiving from the local device. Perform hard plug loopback tests to verify the ISDN controller hardware is OK. Check or replace cables to isolate cabling problems. |
| Transmit Remote Alarm Indication (txRAI) | Indicates that the ISDN interface has a problem with the signal it receives from the far-end equipment. Check the settings at the remote end to ensure that they match the local port settings. |
| Transmit Alarm Indication Signal (txAIS) | Indicates that the ISDN controller is shut down. Issue the show controller e1 | t1 {num} EXEC command to verify that the ISDN controller is up. If the ISDN controller is down, issue the no shutdown interface subcommand to bring it up. |
Below describes the various error events that occur on ISDN E1/T1 lines along with the troubleshooting guidelines for them:
| Linecode Violations | Indicates that either a Bipolar Violation (BPV) or excessive zero error event is present. BPVs are inserted upon the synchronization of circuits with B8ZS linecoding. Linecode errors occur when BPVs that are used for synchronization are received. Excessive zero errors occur when 8 or more 0s in sequence are received on circuits with AMI linecoding. These errors normally occur due to an AMI/B8ZS linecoding misconfiguration on the intermediate devices along the transmission path. |
| Pathcode Violations | Examples are frame synchronization errors for SF and cyclic redundancy check (CRC) errors for ESF. Both linecode and pathcode violations are often present at the same time; hence always verify the linecoding configuration. Note that some errors can occur due to impulse noise, in which the errors might appear only a few times a day and the impact or interrupt is minimal. |
| Slip Seconds | Indicates a clocking problem. The ISDN network would provide the clocking in which the CPE must synchronize. Look for Clock Source is Line in the output of the show controller e1 | t1 {num} EXEC command to verify that the clocking is derived from the Telco. |
| Loss of Frame | Triggered when the receiver detects multiple framing-bit errors. The data is considered garbage as the synchronization between both ends is invalid. When this state is triggered, the framer starts searching for a correct framing pattern. The LoS state ends when reframe occurs. Ensure the framing format is configured correctly. Change the framing format with the framing {esf | sf | crc4 | no-crc4} interface subcommand. |
| Loss of Signal | Triggered upon observing 175 +/- 75 contiguous pulse positions with no pulses of either positive or negative polarity for T1 lines; or when more than 10 consecutive 0s are detected for E1 lines. |
| Code Violation Error | The CRC value in the received frame does not match with the corresponding locally calculated CRC value. |
| Bipolar Violation | Occurs when 2 mark signals (1s) occur in sequence with the same polarity (when not part of a B8ZS substitution). T1 signaling specifies that each mark must be the opposite polarity of the one preceding it. It also includes other error patterns such as 8 or more consecutive 0s and incorrect parity. |
| Errored Second | A second with one or more Code Violation Error or Loss of Frame events have occurred. The presence of Bipolar Violations also triggers an Errored Second. Some errored seconds may occur on a normal circuit. |
| Severely Errored Second | A second with 320 or more Code Violation Error or Loss of Frame events have occurred. Also known as Extreme Errored Second (EES). |
| Unavailable Second | A second that the CSU is in the Unavailable Signal state, including the initial 10 seconds to enter the state, but excluding the 10 seconds to exit the state. |
Troubleshooting ISDN Layer 2
Understanding the output messages of the debug isdn q921 command is vital in troubleshooting ISDN Layer 2 Firstly, issue the debug isdn q921 to enable the ISDN Layer 2 debugging which provides the details of ISDN Layer 2 transactions between the router and the Telco ISDN switch. Subsequently, issue the clear interface bri {num} or clear interface serial {num:15} privileged command to reset the ISDN interface which forces the router to renegotiate ISDN Layer 2 information with the Telco ISDN switch.
Below shows the sample output messages of the debug isdn q921 command:
Router#debug isdn q921 debug isdn q921 is ON. Router# Router#sh isdn status Global ISDN Switchtype = basic-net3 ISDN BRI0/0 interface dsl 0, interface ISDN Switchtype = basic-net3 Layer 1 Status: ACTIVE Layer 2 Status: TEI = 76, 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: 0x80000003 Total Allocated ISDN CCBs = 0 Router# Router#clear int bri0/0 Router# 23:20:28: ISDN BR0/0 Q921: User TX -> IDREQ ri=24872 ai=127 23:20:28: ISDN BR0/0 Q921: User RX <- IDASSN ri=24872 ai=75 23:20:28: ISDN BR0/0 Q921: L2_EstablishDataLink: sending SABME 23:20:28: ISDN BR0/0 Q921: User TX -> SABMEp sapi=0 tei=75 23:20:28: ISDN BR0/0 Q921: User RX <- UAf sapi=0 tei=75 23:20:28: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0/0, TEI 75 changed to up 23:20:38: ISDN BR0/0 Q921: User RX <- RRp sapi=0 tei=75 nr=0 23:20:38: ISDN BR0/0 Q921: User TX -> RRf sapi=0 t Total Allocated ISDN CCBs = 0 23:20:48: ISDN BR0/0 Q921: User RX <- RRp sapi=0 tei=75 nr=0 23:20:48: ISDN BR0/0 Q921: User TX -> RRp sapi=0 tei=75 nr=0 23:20:48: ISDN BR0/0 Q921: User TX -> RRf sapi=0 tei=75 nr=0 23:20:48: ISDN BR0/0 Q921: User RX <- RRf sapi=0 tei=75 nr=0 Router# Router#sh isdn status Global ISDN Switchtype = basic-net3 ISDN BRI0/0 interface dsl 0, interface ISDN Switchtype = basic-net3 Layer 1 Status: ACTIVE Layer 2 Status: TEI = 75, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED Layer 3 Status: 0 Active Layer 3 Call(s) Active dsl 0 CCBs = 0 The Free Channel Mask: 0x80000003 Total Allocated ISDN CCBs = 0 Router#
--- output omitted --- 23:23:05: ISDN BR0/0 Q921: User RX <- DISCp sapi=0 tei=75 23:23:05: %ISDN-6-LAYER2DOWN: Layer 2 for Interface BR0/0, TEI 75 changed to down 23:23:05: ISDN BR0/0 Q921: User TX -> UAf sapi=0 tei=75 Router#sh isdn status Global ISDN Switchtype = basic-net3 ISDN BRI0/0 interface dsl 0, interface ISDN Switchtype = basic-net3 Layer 1 Status: ACTIVE Layer 2 Status: TEI = 75, 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: 0x80000003 Total Allocated ISDN CCBs = 0
| IDREQ | Identity Request transmitted from the router to the ISDN switch requesting a Terminal Endpoint Identifier (TEI). All IDREQ messages have an AI value of 127 which indicates that the ISDN switch can assign any available TEI value. |
| IDASSN | Identity Assigned message with the TEI value of 75 assigned by ISDN switch is received from the ISDN switch. |
| SABMEp | Request the connection to be in Multiple Frame Established state. SABME > Set Asynchronous Balanced Mode Extended. |
| UAf | Unnumbered Acknowledgment (UA) of the SABME message. The ISDN Layer 2 is now in Multiple Frame Established state. |
An operational and functioning ISDN circuit (Multiple Frame Established) should have periodic exchanges of RRp sapi = 0 and RRf sapi = 0 messages between the router and ISDN switch. The interval between Receiver Ready poll (RRp) and Receiver Ready final (RRf) messages is usually 10 or 30 seconds.
Note: TX -> indicates that a message is generated by the router while RX <- indicates that a message is received by the router.
Below shows the debug isdn q921 messages originated from the ISDN switch which indicate various ISDN Layer 2 problems:
Message | Description |
| ID-Denied | The ISDN switch cannot assign the requested TEI. If this message has an AI value of 127, it indicates that the ISDN switch has no TEI available. |
| IDREM | The ISDN switch has removed the TEI from the connection. The router must terminate all existing communication using the particular TEI. |
| DISC | The sending side of the DISConnect message has terminated the operation of ISDN Layer 3 for the connection. It may be unnumbered acknowledged by the other side. The router should then send a SABME message to reestablish the link. |
| DM | Indicates the Acknowledged Disconnect mode. The ISDN switch does not wish to enter the Multiple Frame Established state, and hence the router will remain in Layer 2 TEI_ASSIGNED state. The router will continuously send SABME messages until the ISDN switch responds with a UA instead of DM. |
| FRMR | The Frame Reject Response indicates an error that cannot be recovered by retransmission. The router will initiate a Layer 2 reset and transmit a SABME message to request to enter into Multiple Frame Established state. |
Troubleshooting ISDN Layer 3
Only proceed to this section after ISDN Layers 1 and 2 on both ends of a circuit are verified OK.
ISDN call failures could be due to any of the following:
i) Dial-on-Demand Routing (DDR) related issues.
ii) ISDN Layer 1, 2, or 3 problems.
iii) Point-to-Point Protocol (PPP), including authentication, Link Control Protocol (LCP), or IP Control Protocol (IPCP) related issues.
The figure below illustrates common Q.931 transactions during a successful ISDN call setup and teardown.
Pay attention to the direction of the output messages from the debug isdn q931 privileged command. The TX -> indicates that a message is generated by the router while the RX <- indicates that a message is received by the router.
The source of a problem can be identified by following the direction of a particular message and the response. Ex: If the local router unexpectedly receives a RELEASE message from the ISDN switch, then it will reset its end of the call as well. This indicates that there is an issue in the ISDN switch or the remote router.
Verify that the message received or sent is the expected one. Ex: If the called party receives a SETUP message but responses with a DISCONNET message instead of a CONNECT message, then troubleshoot the called router and not the ISDN network.
Below lists all the possible Q.931 messages during call establishment and termination:
| Message | Description |
| SETUP | Indicates that a device would like to establish an ISDN Layer 3 call. |
| CALL_PROC | The SETUP message is received and is being processed by the network and/or the remote device. |
| ALERTING | Informs the network that the router is alerting the user, which would normally be the case for a telephone and the alert would ring the handset. This message is normally associated with equipment using a handset, eg: an ISDN telephone or TA and is not usually seen for data calls. |
| CONNECT | Call is accepted. |
| CONNECT_ACK | Connect Acknowledge. The device has received the CONNECT message. Higher layer protocols (eg: PPP) should now begin the negotiation process. |
| DISCONNECT | A router initiates a DISCONNECT message, which usually indicates that an operational ISDN call is disconnected due to some higher layer issues (eg: DDR, PPP, etc). The 3-way Disconnect Handshake will be accompanied by a RELEASE message, a Disconnect Cause Code, and a RELEASE_COMP message. |
| RELEASE | A router acknowledges the DISCONNECT message and continues the circuit termination process. The RELEASE message is sent between the DISCONNECT and RELEASE_COMP messages. |
| RELEASE_COMP | Release Complete. The call termination is completed. This message is often seen during a normal call termination initiated by one of the routers; in response to a SETUP message from the calling party when there is a mismatch of bearer capability between the ISDN switch and the router; or due to protocol error if the coding of the SETUP message does not comply with the Q.931 standard or the ISDN switch configuration. |
If the calling router does not send a SETUP message to the ISDN switch, the problem is likely related to ISDN Layer 1, 2, or DDR issues, and is not ISDN Layer 3 related.
Perform the following troubleshooting tasks on the calling and called routers:
i) Verify that the ISDN switch types on both routers are configured correctly.
ii) Verify that the ISDN Layers 1 and 2 on both routers are functioning.
iii) Perform ISDN loopback test calls on both routers to verify they are able to initiate and accept calls.
iv) Verify the ISDN network of the called side is functioning by making a test call to the called router with a regular analog phone, in which the router should receive a SETUP message, although the call would eventually fail as it is not an ISDN call.
v) Verify that the calling router has a route to the destination with the show ip route EXEC command.
vi) Verify that the interesting traffic on the calling router is identified correctly.
vii) Verify that the appropriate dialer string or dialer map interface subcommand on the calling router refers to the correct number to the called router.
viii) Check the DDR configuration and use the debug dialer privileged command to verify that the calling router is able to initiate calls.
ix) If the called router does not send a CONNECT message, check if the call is rejected due to the misconfiguration of the isdn caller {incoming-number} interface subcommand.
x) Contact the Telco and determine whether the long distance call service is activated.
ISDN Loopback Test Call
In a loopback call, a router dials the ISDN number of its own BRI. The call is proceed to the ISDN switch, which then being switched to the 2nd BRI channel. The call is seen by the router as an incoming call on the 2nd channel. Therefore, the router both sends and receives an ISDN call on different B channels and act as both the called and calling routers.
Loopback call tests the ability of a router to initiate and accept ISDN calls. It can also provide an indication that the physical links to the ISDN switch along with the ISDN switch are functioning.
Q.931 ISDN Layer 3 Disconnect Cause Codes
This section explains how to interpret the ISDN disconnect cause codes which appear in the output of the debug isdn q931 privileged command to indicate the reason for ISDN call disconnection or failure.
The ISDN Layer 3 disconnect cause code the has the following format:
Cause i = 0xAABBCC - reason.
| AA | Cause Code Origination Point |
| BB | Disconnect Cause Code |
| CC | Optional Diagnostics Field |
Below lists all the Cause Code Origination Points:
| 80 | Router |
| 81 | Private network near the local router (possibly a local private branch exchange – PBX) |
| 82 | Public network near the local router (local Telco switch) |
| 83 | Transit network in the ISDN cloud |
| 84 | Public network near the remote router (remote Telco switch) |
| 85 | Private network near the remote router (possibly a remote private branch exchange – PBX) |
| 87 | International network |
| 8A | Network beyond the internetworking point |
Below lists all the standard ITU-T Q.931 Disconnect Cause Codes:
| 80 | Normal Disconnect. The ISDN call disconnects normally. |
| 81 | Unallocated or unassigned number. The ISDN switch receives the ISDN number in the correct format. However, the number is not in the ISDN switch’s routing table or it has no path across the ISDN network. Check the routing table to see whether the number is available; and check the correct digits were dialed and it is a valid number. |
| 82 | No route to specified transit network. The ISDN switch receives a request to route the call through an unrecognized intermediate (or transit) network – the ISDN switch has no route to the transit network. This problem can be due to either the transit network does not exist, or the transit network exists but does not serve the ISDN switch. This cause is supported on a network-dependent basis. |
| 83 | No route to destination. The dialed number is in the ISDN switch’s routing plan, but there is no physical route to the destination and hence the called party is not reachable. This problem can be due to either the D channel is down at either end, or the span or WAN is not connected correctly. This cause is supported on a network-dependent basis. |
| 84 | Send special information tone. The called party is not reachable and a special information tone should be returned from the calling party. Check the dialing number and verify whether any prefix is required to access the network, eg: a 9 might need to be dialed for outbound calls through a PBX. Contact the Telco or PBX administrator for details. |
| 85 | Misdialed trunk prefix. There is erroneous inclusion of a trunk prefix in the dialed number. Check the dialing number and verify whether any prefix is required to access the network, eg: a 9 might need to be dialed for outbound calls through a PBX. Contact the Telco or PBX administrator for details. |
| 86 | Channel unacceptable. The service quality of the specified channel is insufficient to accept the connection. The call fails due to the channel is not acceptable (unusable) for the call. If a PBX is in used, check the configuration of the PBX. If a PRI is in used, find out how many channels are provided by the Telco. |
| 87 | Call awarded and being delivered in an established channel. The called party receives an incoming call, but the call is being connected to a channel already established for similar calls (eg: packet-mode virtual calls). |
| 88 | Preemption. The call is being preempted or blocked. Sometimes calls are blocked if another call has a higher priority than the current call, which is common with voice calls. Wait and call again later. If a local or remote PBX is in used, check the configuration of the PBX. Contact the Telco if the problem persists. |
| 89 | Preemption, circuit reserved for re-use. The call is being cleared as one of the routers involved in the call has requested to terminate and clear the call. |
| 90 | Normal call clearing. The call disconnects and normal call clearing occurs due to one of the routers involved in the call requested to terminate and clear the call. This is one of the most common cause codes and is received for many reasons. Most of the time, the ISDN network is not the source of this cause. If a call fails with this cause, it is most likely fails with a higher layer protocol, eg: PPP, authentication, or idle timeout related issues. Verify the router configuration to resolve such problems. Additionally, if callback is configured on the local router, the remote router will disconnect the calls, generates this code, and calls the local router back. |
| 91 | User busy. The called party acknowledges the connection request. However, it is unable to accept the call due to all B channels are in use (the dialed number is busy). The routers are compatible with the call in this situation. Note: If there are multiple ISDN circuits, the Telco can configure them in a hunt-group, which calls are switched to next available circuit. |
| 92 | No user response. The called party does not respond to the call establishment message within a prescribed duration, or it does not wish to answer the call. The called party must respond with either an alert or connect indication according to ITU-T Q.931, when either timer T303 or T310 expires. |
| 93 | No answer from user. The called party is alerted to the connection request but does not respond with a connect indication to establish the connection within a prescribed duration. This cause is not necessary generated by Q.931 procedures; it may be generated by internal network timers. The problem is at the remote router. |
| 94 | Subscriber absent. The remote router is unavailable or disconnected from the ISDN network. Contact the person responsible for the remote router. |
| 95 | Call rejected. The remote router rejects the call due to an unknown reason. Note: The remote router is able to accept the call as it is able to respond with this cause, it is neither busy nor incompatible. This cause may also be generated by the ISDN network indicating that the call was cleared due to a supplementary service constraint. |
| 96 | Number changed. The called number is no longer assigned to any device. The new called number may optionally be included in the diagnostic field. If the network does not support this cause, the caller receives disconnect cause code 81 – unallocated or unassigned number. |
| 97 | Redirection to new destination. The call is routed to a different number. Check the called number and verify the configuration of the PBX if PBX is in used. |
| 99 | Exchange routing error. The call cannot be successfully routed to the remote router. Check the called number and verify the configuration of the PBX if a PBX is in used. |
| 9A | Non-selected user clearing. The remote router is able to accept the call. However, it rejects the call due to the call is not assigned to any user. |
| 9B | Destination out of order. The remote router is not reachable as there is a problem sending the signaling message to the remote router. This condition is often temporary, but can also last for an extended period in some cases. Possible causes are ISDN layer 1 or 2 fails at the remote end, or the remote router is powered off. |
| 9C | Invalid number format. The call fails due to the called number is not in a valid format or is incomplete. This can also happen when the local router calling out using network-specific ISDN Type of Number (TON) when it should be calling out using National or Unknown for the ISDN Type of Number (TON). Verify whether the format of the number is correct, which includes any necessary digits for a PBX or long distance. |
| 9D | Facility rejected. The ISDN network is unable to provide a requested supplementary service. |
| 9E | Response to STATUS ENQUIRY. This cause code is included in a STATUS message when the STATUS message is generated upon the receipt of a STATUS ENQUIRY message. |
| 9F | Normal, unspecified. This is a very common cause code and happens when the network is not able to determine the next course of action for the call. No action is required. |
| A1 | Circuit out of order. The call fails due to some problems in the ISDN network. |
| A2 | No circuit / channel available. The call fails due to no B channel is available to answer the call. |
| A3 | Destination unattainable. The destination is not reachable through the ISDN network. Contact the Telco. |
| A4 | Out of order. Some parts of the ISDN network necessary to route the call is out of order. The destination is not reachable due to a network malfunction. This condition can last for a relatively long period. An immediate attempt to reconnect will probably fail. Try to use a Presubscribed Inter-exchange Carrier (PIC) if a long distance carrier is being used. A PIC allows us to verify whether the problem lies with the long distance carrier. |
| A6 | Network out of order. The destination is not reachable due to a network malfunction. This condition can last for a relatively long period. An immediate attempt to reconnect will probably fail. Try to use a Presubscribed Inter-exchange Carrier (PIC) if a long distance carrier is being used. A PIC allows us to verify whether the problem lies with the long distance carrier. |
| A7 | Permanent frame mode connection out of service. This cause code is included in a STATUS message to indicate that a permanently established frame mode connection is terminated. Contact the Telco if the problem persists. |
| A8 | Permanent frame mode connection operational. This cause code is included in a STATUS message to indicate that a permanently established frame mode connection is fully operational again and capable of carrying user information after a termination. The connection is probably terminated by a faulty equipment previously. |
| A9 | Temporary failure. The call is disconnected due to a network malfunction. This condition is not likely to last a long period of time; another call attempt can be tried immediately. Contact the Telco if the problem persists. |
| AA | Switching equipment congestion. The destination is unreachable due to a temporary high traffic load on the network switching equipment. Try again later. |
| AB | Access information discarded. The ISDN network is unable to provide the requested access information. Note: The diagnostics field may indicate the particular type of discarded access information, eg: user-to-user information, low layer compatibility, high layer compatibility, and sub-address. |
| AC | Requested circuit / channel not available. The remote router is unable to provide the requested channel due to an unknown reason. This may happen when there is a glare condition, in which both sides are selected top-down or bottom-up channel hunting. This problem is usually temporary. |
| AF | Resources unavailable, unspecified. This cause code is used to report a resource unavailable event only when no other cause in the resource unavailable class applies. This problem is usually temporary. |
| B1 | Quality of service (QoS) unavailable. The ISDN network unable to provide the requested Quality of Service as defined in Recommendation X.213. This problem can occur due to a subscription problem, or the ISDN network does not support throughput or transit delay. |
| B2 | Requested facility not subscribed. The local router is not authorized to use a requested supplementary service which is implemented by the ISDN switch. The administrator has probably not completed the necessary administrative arrangements with the service provider. The ISDN network can also return this cause code if a call is made without supplying the SPIDs, or the SPIDs are entered wrongly. Ensure that the SPIDs are correct, or contact the Telco for verification. |
| B4 | Outgoing calls barred. There are some restrictions on outgoing calls. The ISDN network does not allow the local router to make outgoing calls. |
| B5 | Outgoing calls barred within CUG. There are some restrictions on outgoing calls. The ISDN network does not allow the local router to make outgoing calls although the calling party is a member of the CUG for the outgoing CUG call. Outgoing calls are not allowed for this member of the CUG. Contact the Telco. |
| B6 | Incoming calls barred. The ISDN network does not allow the local router to receive calls. Contact the Telco. |
| B7 | Incoming calls barred within CUG. The ISDN network does not allow the local router to receive calls although the called party is a member of the CUG for the incoming CUG call. Incoming calls are not allowed for this member of the CUG. Contact the Telco. |
| B9 | Bearer capability not authorized. The local router requests a bearer capability that the ISDN switch implements, however the local router is not authorized to use the capability. A subscription problem usually causes this problem. |
| BA | Bearer capability not presently available. The ISDN network normally provides the requested bearer capability. However, the capability is unavailable at the particular moment. Normally caused by a temporary ISDN network problem or a subscription problem. |
| BE | Inconsistency in designated outgoing access information and subscriber class. There is an inconsistency in the designated outgoing access information and subscriber class. |
| BF | Service or option not available, unspecified. This cause code is used to report a service or option is unavailable event only when no other cause in the service or option not available class applies. Normally caused by a subscription problem. |
| C1 | Bearer capability not implemented. The ISDN network is unable to provide the requested bearer capability, eg: requesting 64kb data when only speech is supported. Contact the Telco for further troubleshooting. |
| C2 | Channel type not implemented. The equipment sending this cause does not support the requested channel type. |
| C5 | Requested facility not implemented. The equipment sending this cause does not support the requested supplementary service. |
| C6 | Only restricted digital info bearer capability available. The equipment sending this cause does not support and hence unable to provide unrestricted digital information bearer service (64kb). It only supports the restricted version of the requested bearer capability. |
| CF | Service or option not implemented, unspecified. This cause code is used to report a service or option not implemented event only when no other cause in the service or option not implemented class applies. Normally caused by a subscription problem. |
| D1 | Invalid call reference value. The equipment sending this cause receives a call with a call reference that is not currently in use or assigned on the user-network interface. Ex: The call that is being referenced by the call reference value does not exist on the system. |
| D2 | Identified channel does not exist. The equipment sending this cause receives a request to use an inactive channel for a call. Ex: When a PRI is subscribed to use channels 1 to 12 and the router or the ISDN network attempts to assign a call to channels 13 to 25. |
| D3 | A suspended call exists, but this call identity does not. The ISDN switch receives a call resume request which contains a Call Identify (ID) information element that differs from the ID in use for any currently suspended call. |
| D4 | Call identity in use. The ISDN switch receives a call suspend request which contains a call ID that is already in use for a suspended call which the call can be resumed instead of suspended again. |
| D5 | No call suspended. The ISDN switch receives a call resume request when there is no currently suspended call. This transient error can be resolved through successive call retries. |
| D6 | Call having the requested call identity has been cleared. The ISDN switch receives a call resume request which contains a call ID that indicates a suspended call. However, either a network timeout or the remote router has cleared the call while the call was suspended. |
| D7 | User not member of CUG. The called party for the incoming CUG call is not a member of the specified CUG; or the calling party is an ordinary subscriber calling a CUG subscriber. |
| D8 | Incompatible destination. Indicates an attempt to connect to non-ISDN device (eg: an analog line), in which the equipment sending this cause is not capable of answering a particular type of call – it is unable to accommodate a low layer compatibility, high layer compatibility, or other compatibility attributes. This cause code often appears when the calling device dials a wrong number and reaches a non-ISDN device; a data call is made to a voice number; a voice call is made to a number that only supports data; calling a restricted line in unrestricted mode; or calling a POTS phone using unrestricted mode. Check that the correct number is dialed. If the dialed number is correct, contact the Telco to verify that the ISDN switch configuration. |
| DA | Non-existent CUG. The specified CUG does not exist. Contact the Telco if the problem persists. |
| DB | Invalid transit network selection. The ISDN switch is requested to route the call through an unrecognized intermediate network – it receives a transit network identification which is in an incorrect format as defined in Annex C of ITU-T Q.931. |
| DF | Invalid message, unspecified. This cause code is used to report an invalid message event only when no other cause in the invalid message class applies. This problem usually occurs due to a D channel error. Contact the Telco if the problem occurs systematically. |
| E0 | Mandatory information element missing. The equipment sending this cause receives a message is missing an information element that is necessary for it to process the message. This problem usually occurs due to a D channel error. Upgrade the Cisco IOS software on the router to resolve this problem. Contact the Telco if the problem occurs systematically. |
| E1 | Message type non-existent or not implemented. The equipment sending this cause receives an unrecognized message due to either the message type is invalid, or it does not support or implement the message type. The problem usually occurs due to the D channel of the local router or the configuration of the remote router. |
| E2 | Message not compatible with call state or message type non-existent or not implemented. The equipment sending this cause receives a message that is not permissible in the call state according to the procedures, or it receives a STATUS message which indicates an incompatible call state. This problem usually occurs due to a D channel error. Contact the Telco if the problem occurs. |
| E3 | Information element non-existent or not implemented. The equipment sending this cause receives a message that contains an unrecognized information element which it does not support or implement. However, the message does not need to contain the information element in order for the equipment sending this cause to process the message. This problem usually occurs due to a D channel error. Contact the Telco if the problem occurs. |
| E4 | Invalid information element contents. The ISDN switch receives a message that contains invalid contents in the information element – the information element is implemented, but one or more of the fields in the information element are coded differently. This cause is usually followed by the information element that is causing the problem. |
| E5 | Message not compatible with call state. The ISDN switch receives a message that does not correspond to the current call state for the call. |
| E6 | Recovery on timer expired. Occurs when ISDN messages do not arrive in specified time according to the Q.931 specification. This cause if sometimes followed by the expired timer. Wait and try again later. Contact the Telco if the problem persists. |
| E7 | Parameter not implemented. The equipment sending this cause receives a message which contains an unrecognized parameter which it does not support or implement. Contact the Telco if the problem occurs. |
| EE | Message with unrecognized parameter discarded. The equipment sending this cause has discarded a received message which contains an unrecognized parameter. |
| EF | Protocol error, unspecified. This cause code is used to report a protocol error event only when no other cause in the protocol error class applies. This problem usually occurs due to a D channel error. |
| FF | Interworking, unspecified. The ISDN network is interworking with another network which does not provide the next course of action. The precise problem is unknown. |
No comments:
Post a Comment