MICA Modem States and Disconnect Reasons
Available Languages
Contents
Introduction
This document describes how to interpret the call disconnect reason codes reported by Cisco Modem ISDN channel aggregation (MICA) modems.
Note: This document contains many terms that are defined in the ITU standards such as V.90, V.44, V.42bis, and V.34. For more information on these terms please refer to the appropriate ITU-T 
standard. Terms specified in the ITU-T standards are not explained in this document.
Prerequisites
Requirements
Readers of this document should be aware of the following:
Whenever a call that uses the MICA domain specific parts (DSPs) is cleared or disconnected, MICA records the reason for the disconnect. You can use this reason to determine whether the disconnection was normal. If not, you can use it to track down the possible sources of failure. Modems can be disconnected due to a variety of factors such as client disconnects, Telco errors and call drops at the network access server (NAS). A typical disconnect reason is that the DTE (client modem or NAS) at one end wants to shut it down. Such "normal" disconnects indicate that the disconnect was not a result of modem or transmission level errors. For more information on determining whether a disconnect reason is normal, refer to Overview of General Modem and NAS Line Quality.
Components Used
MICA modems are used in the following Access servers:
-
Cisco 3600 series routers
-
AS5200
-
AS5300
-
AS5800
The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.
Conventions
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
Determining the Modem State
Use the show modem log slot/port command to find the current state of a MICA modem. In this log output, the most recent entries occur towards the end of the log. The current MICA modem state is displayed in the last modem state (change) event. In the example output below, the modem state is idle, indicated by the Modem State event stamped 00:00:28. Refer to the MICA Modem States table for further information on the possible MICA modem states.
maui-nas-02#show modem log 1/0
Modem 1/0 Events Log:
00:03:33:Startup event:MICA Hex modem (Managed)
Modem firmware = 2.7.3.0
!--- This modem is using portware 2.7.3.0
00:03:33:RS232 event: noRTS, noDTR, CTS, noDCD
...
...
!--- This output was removed for brevity.
...
00:00:28:Modem State event:
State: Terminate
00:00:28:RS232 event: noRTS, DTR, CTS, noDCD
00:00:28:RS232 event: RTS, DTR, CTS, noDCD
00:00:28:Modem State event:
State: Idle
!--- The last modem state event !--- This indicates that the modem is in state Idle
Determining the Disconnect Reason
Whenever a modem connection is terminated, the NAS reports two disconnect reasons: the DTE (IOS) reasons and the DCE (MICA) reasons. These disconnect reasons can be reported using three primary methods:
-
Modem Call Records: These report both the IOS® Software and MICA modem disconnect reasons.
-
AAA accounting logs: These report only the IOS Software disconnect reason.
-
IOS commands: Commands such as show modem operational-status and show modem log report only the MICA modem disconnect reason.
Modem Call Records
The IOS and modem disconnect reason for a particular connection are displayed in the modem call record (MCR). The MCR is sent to a syslog server by the NAS during the termination of each call. Modem call records were introduced in Cisco IOS Software Release 11.3AA and 12.0T and are activated (on the NAS) using the command modem call-record terse. For more information on implementing modem call records, refer to the document Using Syslog, NTP, and Modem Call Records to Isolate and Troubleshoot Faults.
In the sample modem call record shown below, the IOS disconnect reason indicated by disc(radius) is Lost Carrier/Lost Carrier, while the modem disconnect reason indicated by disc(modem) is:
A220 Rx (line to host) data flushing - not OK/EC condition - locally detected/received DISC frame -- normal LAPM termination
Refer to the table Mica Modem Disconnect Reasons for more information on interpreting the modem disconnect reason.
*May 31 18:11:09.558: %CALLRECORD-3-MICA_TERSE_CALL_REC: DS0 slot/contr/chan=2/0/18, slot/port=1/29, call_id=378, userid=cisco, ip=0.0.0.0, calling=5205554099, called=4085553932, std=V.90, prot=LAP-M, comp=V.42bis both, init-rx/tx b-rate=26400/41333, finl-rx/TX brate=28800/41333, rbs=0, d-pad=6.0 dB, retr=1, sq=4, snr=29, rx/TX chars=93501/94046, bad=5, rx/TX ec=1612/732, bad=0, time=337, finl-state=Steady, disc(radius)=Lost Carrier/Lost Carrier, disc(modem)=A220 Rx (line to host) data flushing - not OK/EC condition - locally detected/received DISC frame -- normal LAPM termination
AAA Accounting Logs
The AAA accounting logs can also be used to determine the IOS disconnect reason. In the sample AAA sql query below, we can see the radius disconnect cause:
SQL> select * from cs_accounting_log where blob_data like '%rad_dial%';
LOG_ID BLOB_ORDINAL BLOB_DATA
-------------------------------------------------------------------------------
172.22.87.3 rad_dial Async20 65004 stop server=danvers time=17:36:33
date=04/17/2000 task_id=40 timezone=CST service=ppp protocol=ip
addr=172.22.83.12 disc-cause=4 disc-cause-ext=1021 pre-bytes-in=132
pre-bytes-out=139 pre-paks-in=5 pre-paks-out=7 bytes_i
The disconnect code (disc-cause=4), in the above example, indicates the disconnect was caused by the expiration of the Idle Time-out.
Note: The AAA accounting logs do not display the MICA disconnect reason, hence the table provided in this document cannot be used to interpret the Radius disconnect reason.
For more information on implementing AAA accounting refer to the document Implementing Server-Based AAA Accounting.
The show modem operational-status and show modem log Commands
The IOS commands show modem operational-status slot/port and show modem log slot/port can be used to determine the MICA disconnect reason.
The output from this command shows why your connection was lost or why the current connection is not what you expect. See the disconnect reasons below for explanations on the different types of disconnection.
as5300-2#show modem operational-status 1/1
Modem(1/1) Operational-Status:
Parameter #0 Disconnect Reason Info: (0xDF03)
Type (=6 ): TX (host to line) data flushing - OK
Class (=31): Requested by host
Reason (=3 ): DTR dropped
! --- This output was shortened for brevity.
The show modem log slot/port also displays the disconnect reason
maui-nas-02#show modem log 1/0
Modem 1/0 Events Log:
00:03:33:Startup event:MICA Hex modem (Managed)
Modem firmware = 2.7.3.0
...
...
! --- This output was removed for brevity.
...
00:00:26:End Connect event:
Call Timer: 124 secs
Disconnect Reason Info: (0x8220)
Type (=4 ): Rx (line to host) data flushing - OK
Class (=2 ): EC condition - locally detected
Reason (=32): received DISC frame -- normal LAPM termination
Disconnect Reason Format
A disconnect reason consists of four hexadecimal digits. The three low order hexadecimal digits can be used to identify the disconnect reason. The high order hexadecimal digit generally indicates the type of disconnect reason or the time at which the disconnect reason occurred. These options are described in the section Disconnect Reason: Types. For example, if the disconnect reason is 0xWXYZ, then 0xXYZ can identify the disconnect reason while 0xW indicates when the disconnect reason occurred.
In the examples above, 0xF03 and 0x220 identify the disconnect reason while 0xD and 0x8 indicate when the disconnect reason occurred. The definitions for the MICA disconnect reasons are provided in the section MICA Modem Disconnect Reasons.
For further information on MICA modem operations, see the Verifying Modem Performance and Modem Management Operations documentation in the Cisco AS5x00 Case Study for Basic IP Modem Services.
MICA Modem States
| State | Description |
|---|---|
| IDLE (#0) | In this state, the modem session is currently inactive. The IDLE state is entered from the TERMINATING state upon receiving verification from the DSP that all operations have shut down. |
| CALL_SETUP (#5) | In this state, the modem signal processor is prepared to receive and generate T1, multiple frequency (MF), dual tone multi-frequency (DTMF), R1, R2 and call progress signals. The modem remains in the CALL_SETUP state until it receives a LINK_TERMINATE, SOFTWARE_RESET, or INITIATE_LINK message from the host. |
| CONNECT (#10) | The CONNECT state is entered from the CALL_SETUP(#5) state only upon receiving the host command to Initiate. In Answer mode, the modem session has initiated activity, but has not yet begun to produce an Answerback Tone. In Originate mode, the modem session has initiated activity, but has not yet detected an Answerback Tone. |
| LINK (#15) | The LINK state is entered from the CONNECT state only upon detecting an Answerback Tone (originate) or the initiation of an Answerback Tone (answer). In Answer mode, the modem session transmits an Answerback Tone to the line. In Originate mode, the modem session has detected the minimum (configurable) amount of Answerback Tone required. This indicates that there is a remote peer. |
| QC (#16) | Quick Connect (QC) is entered either from LINK or V.8 bis Exchange state if QC is enabled and upon receiving a QCA sequence (Originate Mode) or sending a QCA sequence (Answer Mode). |
| TRAINUP (#20) | In this state, the modem session negotiates the physical modulation standard (as configured) used during the link. The TRAINUP state is entered from the LINK state only upon:
|
| EC_NEGOTIATING (#25) | In this state, the modem session negotiates the error correction and data compression protocol to be used during the link. When the settings are agreeable to both modems (the intersection of the two modems capabilities and configuration), a successful negotiation is reached. If the intersection is null, the modem either disconnects or starts a non-error connected session. The EC_NEGOTIATING state is entered from the TRAINUP state upon successfully completing physical modulation synchronization. |
| STEADY_STATE (#30) | In this state, the modem session is able to pass data on the link. The STEADY_STATE state is entered from the EC_NEGOTIATING state:
|
| STEADY_STATE_RETRAINING (#35) | In this state, the modem session is currently retraining. The STEADY_STATE_RETRAINING state is entered from the STEADY_STATE or STEADY_STATE_SHIFTINGSPEED states:
|
| STEADY_STATE_SHIFTINGSPEED (#40) | In this state, the modem session is currently speed-shifting. The STEADY_STATE_SHIFTINGSPEED state is entered from the STEADY_STATE state:
|
| STEADY_STATE_ESCAPE (#45) | In this state, the modem is still connected with the remote peer, but the host interface is in AT command mode. This state is only entered upon receiving a valid Hayes escape sequence. In Fax mode, this state means the T30 engine is accepting AT commands from the host. See the STEADY_STATE (#30) state for information about a Fax call. |
| TERMINATING (#50) | In this state, the modem session attempts to flush user data and clear-down the digital signal processor (DSP). On a Software_reset, there is no orderly flush, and the DSP is RESET. The TERMINATE state is entered from any state:
|
| ON HOLD ( #55 ) | The modem session is on hold, and no data passes on the link. The On Hold state is entered from steady state upon receiving Modem on Hold (MoH) request message (MHReq). If modem on hold is enabled (Register S62), the modem shall transmit the Modem on Hold Acknowledgment (MHack) sequence to grant the request and transmit Answer back tone (ANSam) when silence or RT is detected. If a Call Menu (CM) signal (for V.8) or Quick Connect Acknowledge-QCA (QC - Register S63) sequence is detected in the On Hold state, the modem shall exit the On Hold state and respond to the initiating sequence following the V.8 or QC (Register S63) Recommendations respectively. If no initiating sequence is detected after the on hold time-out value defined, the modem shall exit the On Hold state and disconnect. If modem on hold is disabled, the modem shall transmit MHnack. If MHcda is detected after MHnack is transmitted, the modem shall disconnect. If MHfrr is detected after MHnack is transmitted, the modem shall transmit Answer Back Tone and get ready to detect CM (V.8) or QCA (QC - Register S63) sequences from the remote modem. For more information about Modem on Hold, refer to the ITU-T V.92 specifications . Note: MICA state #55 was formerly the VOICE state, which has now been removed from portware versions 2.9.1.0 and above. |
| V.8bis EXCHANGE(#71) | This state is entered from CONNECT state only upon detecting CRe (Originate Mode) or the initiation of CRe(Answer Mode). Answer Mode: The modem session is transmitting an Capability Request-autoanswer (CRe) to the line. Originate Mode: The modem session has detected the Capability Request-autoanswer (CRe). This indicates there is a remote peer. |
| RANGING(#72) | RANGING is entered from LINK or QC (Register S63) state upon starting the round trip delay estimate (RTDEd). This state only applies to standards V.32 and up. |
| RANGING SHORT(#73) | RANGING SHORT is entered from QC (Register S63) upon starting the Round Trip Delay Estimate-Digital Modem (RTDEd) |
| HD TRAIN(#74) | HD TRAIN (Half Duplex Trainup) is entered either from RANGING or RANGING SHORT upon the start of the adapt filter training. This applies to V.22bis and up. |
| STEADY_STATE_PIAFS_RESYNC(#80) | Entering STEADY_STATE_PIAFS_RESYNC indicates that a Personal Handyphone Internet Access Forum Standard (PIAFS) call has lost sync and is performing a resync. |
| STEADY_STATE_PIAFS_SPEEDSHIFT(#85) | Entering STEADY_STATE_PIAFS_SPEEDSHIFT indicates that a PIAFS call is negotiating a speed shift change. This is a momentary, transitional state. MICA will never remain in this state. If resynchronization results in a speed shift, then MICA transitions to this state from STEADY_STATE_PIAFS_RESYNC, and then goes on to STEADY_STATE. If resynchronization does NOT result in a speed shift, then STEADY_STATE_PIAFS_RESYNC transitions directly to STEADY_STATE when complete. |
MICA Modem Disconnect Reasons
A MICA modem disconnect reason consists of four hexadecimal digits. The three low order hexadecimal digits uniquely identifies the disconnect reason. The high order hexadecimal digit indicates the type of disconnect reason or the time at which the disconnect reason occurred. In the example above,where the disconnect code is hexadecimal 0xDF03, the 0xF03 identifies the disconnect reason while 0xD indicates when the disconnect reason occurred (Disconnect Reason: Types).
The disconnect reasons described below do not include the disconnect type. Hence, from the disconnect reason you have, strip off the leftmost hex digit and compare the remaining digits with the options below. From the example above, look for 0xF03 in the section below.
Note: In this document, the host modem is the MICA modem on the Cisco Access Server, while client modem is the remote device modem (for example, a client PC modem).
| Disconnect Type | Disconnect Reason Code | Description |
|---|---|---|
| - | 0 | No disconnect has yet occurred. You see this code if the disconnect reason is queried immediately after Portware loading or during a call, prior to steady state. |
| General Disconnect Reasons (Class 0) | ||
| 2 | 0x001 | Cisco IOS abruptly terminated the call for some reason - for example, because layer 1 went down on the physical span containing the call. |
| 2 | 0x002 | Error Correction (EC) layer termination. |
| 2 | 0x003 | The Microcom Network Protocol 5 (MNP5) decompression task received an illegal token in the data stream. This disconnect reason occurs during data mode (0x3003). There is probably a logic error in either the modem or partner's implementation of de/compression or error correction. (There is also the possibility of a fortuitous line hit or a RAM memory error.) |
| 2,4,6 | 0x004 | The V.42bis or V.44 decompression task received an illegal token in the data stream. This disconnect reason can occur during data mode (0x4004). There is probably a logic error in either the modem or partner's implementation of de/compression or error correction. (There is also the possibility of a fortuitous line hit or a RAM memory error.) For V.44, this code is supplemented by the diagnostic link information field index 119 (an eight byte information field used as a tool for debugging). |
| 2 | 0x005 | MICA software error. The error code for this disconnect reason is 0x4005. A MICA software error has occurred that indicates a bad co-processor state variable. |
| 6 | 0x006 | ATH command was detected by local modem. This disconnect reason occurs during data mode (0xC006 and 0xE006). The ATH (Hangup) command was detected by the local modem (MICA). For example, during a dialout from IOS, after the call was connected, the IOS DTE interface cleared the call by transmitting an inband ATH command. |
| 3 | 0x007 | The AT dial command was aborted . The AT dial command was aborted by the any key abort command. For example, the host modem originates a call. During connection establishment, prior to STEADY STATE, pressing any key will cause the AT dial command to be aborted. |
| 3 | 0x008 | The call took too long to complete the connection. Note that the S7 timer (wait for carrier after dial) expired for this disconnect. This disconnect reason occurs during call set-up (0x6008). The host modem took too long to establish a connection due to retraining. The causes are: difficulty choosing (negotiating) a Layer I standard (for example, aborting the call before returning with disconnect reason 0x6102), or a combination of Layer I and Layer II establishment taking too long. For example, error correction negotiation takes an extended amount of time on top of a retrain or because of bit-errors introduced when the client modem tries to connect at an aggressive rate (the client modem's receiver tries to connect at a rate it can't sustain). This type of disconnect counts against CSR. This disconnect can also happen if the answer modem heard no tone from the channel (For example, the originator was not a modem). |
| 2 | 0x009 | DSP was reset (command, internal or spontaneous). The error code for this disconnect reason is 0x4009. The DSP within the host modem was reset by the Control Processor (CP) or Signal Processor (SP). The CP will reset the DSP if mail messages from the CP to SP are not being acknowledged. The SP will reset itself if it gets an internal inconsistency error. |
| 4,6 | 0x00A | Receipt of an illegal STEPUP code word. Specifies the receipt of a STEPUP code word when it would cause the value of C2 (current code word size) to exceed N1 (maximum code word size: negotiated) and is valid for V.44 and V.42bis only. |
| 4,6 | 0x00B | Receipt of an illegal V.42bis code word. Specifies the receipt of a code word, at any time, equal to C1 (next empty dictionary entry) and is valid for V.42bis. (Receipt of a code word = C1 is illegal in V.42bis, but legal in V.44). |
| 4,6 | 0x00C | Receipt of an Illegal Token (too large) in V.44 or V.42bis. This means that the received V.42bis or V.44 code word size exceeded the negotiated maximum. Specifies the receipt of a code word, at any time, greater than C1 (next empty dictionary entry) and is valid for V.44 and V.42bis. |
| 4,6 | 0x00D | Receipt of a V.44 or V.42bis reserved command code. Specifies the receipt of a reserved command code and is valid for V.44 and V.42bis. |
| 4,6 | 0x00E | V.42bis or V.44 received code word greater than the next empty dictionary entry. Receipt of a V.44 Illegal STEPUP character. This indicates the receipt of a STEPUP control code that would cause the value of C5 (ordinal size) to exceed eight. This is valid for V.44 only. |
| 4,6 | 0x00F | V.44 Rx Dictionary Full. Specifies the receipt of a code word that is not a dictionary reset when the Rx node-tree is full. Valid for V.44 only. |
| 4,6 | 0x010 | V.44 Rx History Full. Specifies the receipt of a code word that is not a dictionary reset when the Rx history is full. Valid for V.44 only. |
| 4,6 | 0x011 | V.44/V.42bis Illegal Rx String Size Exceeded. Specifies the receipt of a code word that causes the maximum negotiated string size to be exceeded. It is valid for V.44 and V.42bis. |
| 4,6 | 0x012 | A V.44 Negotiation Error has Occurred Specifies a V.44 negotiation error has occurred. For V.44, this code is supplemented by the diagnostic link information field index 119. The diagnostic link information field index is an eight byte information field used as a tool for debugging. |
| 4,6 | 0x013 | A V.44 Compression Error has Occurred Specifies a V.44 compression error has occurred. For V.44, this code is supplemented by the diagnostic link information field index 119. The diagnostic link information field index is an eight byte information field used as a tool for debugging. |
| Conditions Reported by DSP (Class 1) | ||
| 0x1xx | DSP conditions reported by SPE | |
| 3,4,5 | 0x100 | The DSP lost the Carrier signal. That is, MICA detected a client modem carrier drop. This disconnect reason occurs during call setup and data mode(that is, 0x6100, 0x8100, and 0xA100). The MICA DSP stopped hearing carrier for a period greater than the value specified in Register S10 (hang-up delay after carrier loss). This can mean that the talk path went away or that the client stopped transmitting. If a layer II protocol (V.42 and/or V.42bis) is in effect, it would be abnormal to see such a disconnect. This disconnect reason sometimes occurs during EC negotiation (before data mode). That is, Layer I has been successfully negotiated (resulting in a carrier signal detection) and the disconnection occurs while trying to establish the Layer II protocol (V.42 and/or V.42bis). Common causes are users aborting the call before a connection takes place. Incidental dialing, aborted starts, and client applications timing out because of taking too long to connect (for example, Multiple retrains during Layer I negotiation). This type of failure counts against CSR. The carrier lost condition can also occur during normal data mode when the client abruptly drops carrier. The common cause is a non-negotiated or dirty disconnect on the part of the client modem (that is, the client modem just drops the carrier signal). This can occur if the link is abruptly dropped (that is, network error), the client modem's power is shut off to disconnect the call. This can also occur with cheaper client modems that do not implement the Layer I and/or Layer II clear-down protocols on a DTR drop. For a large number of client modems, this is considered a normal disconnection. When the client modem does a dirty disconnection, a race condition exists between 0xA103, 0xA100, and 0xDF06. If the DSP within the host modem detects a carrier loss, 0xA100 wins and is indicated as the disconnect reason. If the DSP doesn't detect a carrier loss and retrains until it hits the Register S40 limit, then 0xA103 wins. If the network detects that the call has been disconnected and signals the router to disconnect, then 0xDF06 wins. This disconnect reason does not count against CSR when the host modem is in data mode. |
| 3 | 0x101 | This occurs when the Signal Processor (SP) is in Answer Back Tone (ABT) detection phase when the call failure occurs. |
| 3 | 0x102 | Call failure during modem train up due to incompatible modulation or bad line. This disconnect reason occurs during call setup(0x6102). This may be indicative of attempts to negotiate an unsupported modulation such as a legacy Rockwell proprietary modulation(K56Plus, V.FC, and so on). Other possible causes are DSP failures to train-up due to severe line impairments, impulse noises, interrupting training, incompatible modulation parameters, and perhaps the inability to properly select a Layer I standard. This type of disconnection counts against CSR. |
| 4,5 | 0x103 | Too many consecutive retrains or speed-shifts. The retrain limit is specified with Register S40. This disconnect reason occurs during call setup and data mode (0x6103, 0x8103, and 0xA103). During the progress of a call, too many retrains occurred which rendered the call ineffective since the data rate would be so poor as to be useless. Possible conditions are where the client modem does not complete the clear-down protocol (for example, the telco tore down the call in the middle of the connection) and MICA attempts to recover the call by issuing retrains. Once the retrain limit is reached (the retrain limit can be altered using the S40 register), MICA drops the call and report this disconnect reason. Under some circumstances (channelized T1/E1) this type of disconnect may be considered a normal STEADY state disconnect. alternatively, this could simply be the result of a dirty disconnection due to possible line errors that MICA cannot recover from. Hence, this type of disconnection does not count towards CSR since the call is already established. This disconnect reason can also occur during EC negotiation when the client modem is overly aggressive with the initial connection rate and cannot maintain the call (as observed with old USRobotics client modems). This type of disconnection does count against CSR. When the client modem does a dirty disconnection, a race condition exists between 0xA103, 0xA100, and 0xDF06. If the Digital Signal Processor (DSP) within the host modem detects a carrier loss, 0xA100 wins and is indicated as the disconnect reason. If the DSP doesn't detect a carrier loss and retrains until it hits the register S40 limit, then 0xA103 wins. If the network detects that the call has been disconnected and signals the router to disconnect, then 0xDF06 wins. This disconnect reason does not count against CSR when the host modem is in data mode. |
| 3 | 0x104 | Problem detecting end of Answer-Back Tone(ABT). Negotiation failure or excessive noise during V.34 training. Host modems answer and send out V.8bis and modulated 2100Hz answer back tones (ABTs) with phase reversals, but encounter excessive noise during the trainup sequence. Look for errors on the path from the calling modem to the answering modem in either one or both directions. Similar behavior occurs when there is latency in the Public Switched Telephone Network (PSTN) for dial up that exceeds one second and causes the modems to be unable to train up the echo cancellers. Other possible causes are:
|
| 3 | 0x105 | SS7/COT (Continuity Test) operation completed successfully This disconnect reason occurs during call setup (0x6105). The SS7/COT (Continuity Test) operation was completed successfully. |
| 3 | 0x106 | SS7/COT (Continuity Test) operation failed: T8/T24 timeout waiting for tone on. This disconnect reason occurs during call setup (that is, 0x6106). The SS7/COT (Continuity Test) operation has failed because the T8/T24 timer has timed out while waiting for tone on. |
| 3 | 0x107 | SS7/COT (Continuity Test) operation failed: T8/T24 timeout waiting for tone off. This disconnect reason occurs during call setup (0x6107). The SS7/COT operation has failed because the T8/T24 timer has timed out while waiting for tone off. |
| 4 | 0x108 | Modem On Hold (MOH) cleardown by MICA. The Modem On Hold Cleardown request was received from the client modem. V.92 specifies that the cleardown reason can be:
|
| 4 | 0x109 | Modem On Hold (MOH) timeout value reached. |
| Local EC Conditions (Class 2) | ||
| 0x2xx | Local EC conditions | |
| 3 | 0x201 | Never received a LR (Link Request) frame during negotiation. This disconnect reason occurs during call setup (that is, 0x6201). This means that the host modem never received the LR frame during error correction negotiation. The peer modem may not support MNP within V.42. |
| 3 | 0x202 | Received a LR frame with a bad parameter (PARAM1). The Received MNP Link Request (LR) frame had a bad or unexpected PARAM1. For more information on PARAM1 refer to the V.42 specification. |
| 3 | 0x203 | Received an incompatible LR (Link Request) frame. This disconnect reason occurs during call setup (0x6203). The received MNP LR frame is incompatible with the host modem's settings for EC. |
| 4,5 | 0x204 | Too many consecutive retransmissions. This disconnect reason occurs during call setup and data mode (0x8204, 0xA204 and 0x6204). This disconnect reason can be caused by noise on the line. For instance, the host modem transmits data to the client modem, but noise on the line causes the data to be received incorrectly (or not at all) by the client side. So excessive noise can lead to excessive retransmissions. The client modem could also have disconnected without the MICA modem realizing this. So the host modem continuously retransmits, without knowing that the client modem is no longer present. Sometimes, when the call connects in an error compression (EC) protocol (Link Access Procedure for Modems (LAPM) or Microcom Networking Protocol (MNP)), MICA is unable to transmit a frame to the client modem. The client modem fails to acknowledge MICA's initial transmission, then fails to respond to S19 (Error Correction Retransmission Limit) polls (the default is 12), so MICA disconnects the call. One cause can be that the carrier in the transmit path degraded substantially while the client failed to downshift. Another cause could be a problem with the client's EC engine (as would happen on a Winmodem system if Windows stops responding). |
| 6,7 | 0x205 | Inactivity timeout, MNP Link Disconnect (LD) sent. This disconnect reason occurs during data mode (0xC205 and 0xE205). The host modem sends the client modem an LD frame indicating an inactivity timeout has occurred. |
| 4,5 | 0x206 | EC protocol error. This disconnect reason occurs during data mode (0x8206 and 0xA206). This is a general catch-all protocol error. It indicates that a LAPM or MNP EC protocol error has occurred. |
| 3 | 0x210 | No EC fallback protocol available. This disconnect reason occurs in call setup (0x6210). Error correction negotiation has not been successful. The call is terminated because there is no error correction fallback protocol available. S-register S25 (link protocol fallback) determines the available fallback protocol. The options are asynchronous framing, synchronous framing, or disconnect (hangup). |
| 3 | 0x211 | Never received eXchange IDentification (XID) frame during negotiation. This disconnect reason occurs during call setup (0x6211). This means that the host modem never received the XID frame during error correction negotiation. The client modem may not support LAPM within V.42. |
| 3 | 0x212 | The received XID frame is incompatible with local settings. This disconnect reason occurs in call setup (0x6212). The received XID frame is incompatible with the host modem's settings. For example, the client modem may indicate MNP5, whereas the host modem indicates V.42 and V.42bis only. |
| 3,4,5 | 0x220 | Received Disconnect (DISC) frame. This is the normal LAP-M disconnect. This disconnect reason occurs during call setup and data mode (0x 6220, 0x8220, and 0xA220). The call terminated normally with a proper clear down from the client side. (that is, a V.42 disconnect packet was sent from the client modem to the NAS modem.). The client modem dropped DTR and cleanly negotiated a clear-down protocol. |
| 3,4,5 | 0x221 | Received DM frame. Peer is possibly disconnecting. This disconnect reason occurs in call setup and data mode (0x6221, 0x8221, and 0xA221). The client modem indicates that it is disconnecting. During call setup, this reason indicates that the client modem is giving up on negotiating error correction. |
| 4,5 | 0x222 | Received a bad sequence number. This disconnect reason occurs in data mode (0x8222 and 0xA222). The host modem received a LAPM or MNP error correction frame with a bad sequence number or acknowledgment number. An LD or Frame Reject (FRMR) frame is sent to the client modem indicating that the host modem is disconnecting. |
| 4,5 | 0x223 | Received SABME frame in steady-state. This disconnect reason occurs in data mode (0x8223 and 0xA223). This is interpreted as a LAPM error correction protocol error in steady state. It means that the client modem may have reset due to receiving a Frame Reject (FRMR). |
| 4,5 | 0x224 | Received MNP XID frame in steady-state. This disconnect reason occurs in data mode (0x8224 and 0xA224). This is interpreted as a LAPM error correction protocol error in steady state. It means that the client modem may have reset due to receiving a Frame Reject (FRMR). |
| 4,5 | 0x225 | Received MNP LR frame while in steady-state. This disconnect reason occurs in data mode (0x8225 and 0xA225). This is interpreted as an MNP error correction protocol error in steady state. It means that the client modem has reset. |
| PIAFS Protocol Specific Conditions (Class 2, Continued) | ||
| 3,4 | 0x230 | A received message is shorter than the minimum defined length for that message type. |
| 3,4 | 0x231 | Unknown or unimplemented PIAFS frame type received. This includes the FI (major frame type), and negotiate, sync or control class (sub-type). |
| 3,4 | 0x232 | Unknown PIAFS Control Frame Identifier (CFI). A control frame was received with an unknown or unimplemented ID for its class. Note that continuous and user frames are unimplemented, and that there are no known notification frames. |
| 3,4 | 0x233 | PIAFS Communication negotiation failed. After initial synchronization, Communication Parameter Req/Ack frames are exchanged. Either the parameters were unacceptable, or the initiator detected a NAK (Negative Acknowledgment) response. Note: MICA can only operate as an client/initiator for testing purposes |
| 3,4 | 0x234 | PIAFS ARQ negotiation failed. After resynchronization, ARQ Request (Req)/Acknowledgment (Ack) frames are exchanged. Either the parameters were unacceptable, or the initiator detected a Nak response. Note: MICA can only operate as an client/initiator for testing purposes |
| 3,4 | 0x235 | PIAFS Control Transfer Protocol problems detected. The initiator received an Ack/Nak/Rsp whose ID, Class and Sequence did not match the original Req/Ntf. Note: MICA can only operate as a client or initiator for testing purposes |
| 3,4 | 0x236 | This disconnection reason no longer indicates receipt of a DataLinkRelease request frame. It now indicates a disconnect without a disconnect reason previously being generated. This means that MICA is disconnecting a call, but finds that no reason has been posted. |
| 3,4 | 0x237 | The PIAFS sync reception wait timer (T001) expired. This timer starts when a sync-request frame is sent, and it stops when a sync-reception frame is detected. This error will only occur when the MICA port is operating as a client or initiator, which occurs only during testing. The default value is 15 seconds. |
| 3,4 | 0x238 | The PIAFS post-sync reception-transmission timer T002 expired. This timer starts when a sync-reception frame is sent, sand it stops when a sync-reception (collision case) or a control frame is detected. This error will only occur when the MICA port is operating as a server (answer mode), which is the normal operating mode. The default value is 15 seconds. |
| 3,4 | 0x239 | The PIAFS sync request wait timer T003 expired. This timer starts when continuous FCS errors are detected, and it stops when a valid sync-request frame is detected. This error will only occur with the MICA port is operating as a server (answer mode), which is the normal operating mode. The default value is 15 seconds. |
| 3,4 | 0x23A | PIAFS timer T101 expired: control frame confirmation wait timer. Starts when control frame request or notification is sent, stops when the frame is confirmed. This error will only occur when the MICA port is operating as a client or initiator, which occurs only during testing (ten seconds). |
| 3,4 | 0x23B | PIAFS: received FBI (ACK sequence #) out of negotiated range, or received FBI=0 with a non-empty data frame. |
| 3,4 | 0x23C | PIAFS: received FFI (MSG sequence #) out of negotiated range, or FFI=0. |
| 3,4 | 0x23D | PIAFS: negotiated data window is less than RTF (round trip delay) value. This error is no longer posted by Portware, and should never be seen. |
| 3,4 | 0x23E | PIAFS: message's data length field is too large. Should be 0-73. |
| 3,4 | 0x23F | PIAFS internal error: SREJ call returned an error code. |
| 3,4 | 0x240 | PIAFS general protocol error. This is a catchall for errors which don't have an associated disconnect reason. |
| 3,4 | 0x241 | PIAFS: protocol negotiation failed. No protocol (for example, Data Transfer Protocol Fixed Speed, DTP Variable Speed Type1) was acceptable to both stations. Unacceptable protocols would be DTP Variable Speed Type3, or Real Time Protocol. |
| 3,4 | 0x242 | PIAFS: the measured RTF (round trip delay) value was not in the defined (acceptable) range. |
| 3,4 | 0x243 | PIAFS internal error: unknown event in event handler. A switch statement fell through to its default case. |
| 3,4 | 0x244 | Signal Processor (SP) response timeout occurred during a PIAFS 2.1 speedshift. Mica's CP did not see the speed change response within 200 msec. |
| 3,4 | 0x245 | Mica's CP saw inconsistent control information in the CP/SP shared control structures. In particular, the data buffer had a head or tail offset which was outside the data buffer bounds (0-63). |
| Received Bad MNP or LAPM Protocol Command from Partner (Class 3) | ||
| 4.5 | 0x3xx | EC detected bad command code. The received unknown command is in the last two digits. An MNP LD or LAP-M Frame Reject (FRMR) frame is sent in response. |
| LAPM Partner Indicates MICA Protocol Error (Class 4) | ||
| 4,5 | 0x4xx | EC conditions indicated by client in LAP-M FRMR frame. The bit-mapped reason is in the last two digits. |
| 4,5 | 0x401 | LAPM: peer reports bad command. The host modem received a FRMR frame from the client modem. The received FRMR frame indicates that the client modem received an error correction frame from the host modem that contained a bad command. |
| 4,5 | 0x403 | LAPM: peer reports that data field is not permitted or is incorrect length (U frames). The host modem received a FRMR frame from the client modem. The received FRMR frame indicates that the client modem received an error correction frame from the host modem that contained a data field that is not permitted or contained a data field with an incorrect length (U frame). |
| 4,5 | 0x404 | LAPM: peer reports data field length is greater than N401 (the maximum information field length specified in V.42), but has good Frame Check Sequence(FCS). The NextPort modem received a FRMR frame from the client modem. The received FRMR frame indicates that the client modem received an error correction frame from NextPort that contained a data field length that is greater than the maximum number of octets that can be carried in the information field (N401) of an I frame, an SREJ frame, an XID frame, a UI frame, or a TEST frame. The frame check sequence is good. |
| 4,5 | 0x408 | LAPM: peer reports bad receive sequence number or N(R). The host modem received a FRMR frame from the client modem. The received FRMR frame indicates that the client modem received an error correction frame from the host modem that contained a bad receive sequence number. |
| MNP partner indicates disconnect or MICA protocol error (Class 5) | ||
| 4,5 | 0x5xx | EC conditions indicated by client in MNP LD frame. Reason field is in the last two digits |
| 3 | 0x501 | MNP: peer never received LR frame. The host modem received a LD frame from the client modem. The received LD frame indicates that the client modem never received a link request from the host modem. |
| 3 | 0x502 | MNP: peer reports LR frame has bad parameter #1. The host modem received an LD frame from the client modem. The received LD frame indicates that the client modem received a link request frame from the host modem that contained a bad (that is, unexpected) PARAM1. For more information on PARAM1 refer to the V.42 specification. |
| 3 | 0x503 | MNP: peer reports LR frame is incompatible with its configuration. The host modem received an LD frame from the client modem. The received LD frame indicates that the client modem received a LR frame from the host modem that is incompatible with the client modem,s configuration. |
| 4,5 | 0x504 | MNP: peer reports too many consecutive EC retransmissions. The host modem received a LD frame from the client modem. The received LD frame indicates that the client modem received too many consecutive retransmissions. |
| 4,5 | 0x505 | MNP: peer reports inactivity timer expired. The host modem received an LD frame from the client modem. The received LD frame indicates that the client modem?s host (DTE) hasn?t passed data to the client modem within a period of time. |
| 3 | 0x506 | MNP: peer reports error. The host modem received a LD frame from the client modem. The received LD frame indicates that the client modem received a MNP protocol error. |
| 3 | 0x5FF | Normal MNP disconnect. The host modem received an LD frame from the client modem. The received LD frame indicates a normal MNP termination, indicating that the client modem's DTR dropped or that it received a +++ or ATH command. This disconnect reason occurs in call setup and data mode (0x65FF, 0x85FF, and 0xA5FF). The host modem received an LD, which indicates normal termination. The call terminated normally with a proper clear down from the client side (for example, a disconnect packet was sent from the client modem to the host modem). The client modem dropped DTR and cleanly negotiated a clear-down protocol. |
| PIAFS Partner Indicates Disconnect or MICA Protocol Error (Class 6) | ||
| 3,4 | 0x6xx | MICA received a PIAFS DataLinkRelease (PDLR) with reason xx (see detailed values below). |
| 3,4 | 0x61x | Normal class for PIAFS DataLinkRelease (PDLR): 0 - Normal release. 1 - Normal release, data link continuation forbidden. 2 - Normal release, data link continuation. ... Other Normal classes - undefined classes peculiar to some client devices. |
| 3,4 | 0x62x | Resource use not possible class for PIAFS DLR (busy conditions): 8 - DTE busy. 9 - Temporary obstruction. ... Other Resource use not possible classes - undefined classes peculiar to some client devices. |
| 3,4 | 0x63x | Service utilization not possible class for PIAFS DLR (bad parameters). 9 - Request parameter setting not possible. A - Request parameter setting not possible presently. .. Other Service utilization not possible classes - undefined classes peculiar to some client devices. |
| 3,4 | 0x64x | Service not yet provided class for PIAFS DLR. 1 - Not yet provided parameter indication. ... Other Service not yet provided classes - undefined classes peculiar to some client devices. |
| 3,4 | 0x65x | Invalid information content class for PIAFS DLR. 8 - Terminal attribute not matched. ... Other Invalid information content classes - undefined classes peculiar to some client devices. |
| 3,4 | 0x66x | Sequence error class for PIAFS DLR 0 - Essential parameters insufficient. 1 - Information content undefined or not yet provided. 5 - ARQ condition and signal not matched. 6 - Timer expires. ... Other Sequence error classes - undefined classes peculiar to some client devices. |
| 3,4 | 0x67x | Other peculiarities class for PIAFS DLR. 1 - During voice call. ... Other Other peculiar classes- undefined classes peculiar to some client devices. |
| Host/IOS requested disconnect (Class 31) | ||
| 6,7 | 0x1fxx | Host initiated disconnect. Value is a sum of 0x1F00 and SessionStopCommand value. This is the other host terminate reason. The host reason is indicated in the low order bytes xx. |
| 3,6,7 | 0x1f00 | Non-specific host initiated disconnect. Value is a sum of 0x1F00 and SessionStopCommand value. This is the catch-all IOS initiated disconnect reason. It is used for all non-standard disconnects. For example, this could be a result of modem management software deciding to terminate the call. One possible explanation is a higher-level authentication failure RADIUS, TACACS, or another application issuing a DTR drop to the host modem. This type of disconnect will not count towards CSR when the host modem is in data mode. |
| 3 | 0x1f01 | Dialed number was busy. Disconnection has occurred because the host is indicating that the dialed number is busy. |
| 3 | 0x1f02 | Dialed number didn't answer. Disconnection has occurred because the host is indicating that the dialed number didn't answer. |
| 3,6,7 | 0x1f03 | Virtual DTR dropped. This status is reflected from the I/O port redirector which is currently using the modem. Disconnection has occurred because the host dropped the virtual DTR line. This generic disconnect cause is initiated by the Cisco IOS Software. Possible causes are idle timeout, PPP LCP TERMREQ received, authentication failure, Telnet hangup, and so on. To determine the reason for the hang up, examine the Radius disconnect reason from the modem call-record terse command or from Authentication, Authorization, and Accounting (AAA). |
| 6,7 | 0x1f04 | ATH (hangup) command was detected by local host. |
| 3 | 0x1f05 | No access to telco network. Disconnection has occurred because the host couldn't access the network (ISDN). |
| 3,4,5, | 0x1f06 | Network indicated disconnect. This can happen either before or during data mode. A 0x1f06 disconnect means that IOS received a circuit hangup signal from the circuit network (that is, a Q.931 disconnect or a CAS onhook signal), and IOS then communicated this to MICA when it instructed MICA to hang up. If MICA reaches data mode and an EC protocol (LAPM or MNP4) was not negotiated, then this could be a normal disconnect. This reason can also be generated when users of Windows 95 or 98 Dial Up Networking (DUN) hit cancel during trainup and before the call reaches steady state. Also, if the client were abruptly to unplug the phone line/turn off the modem, then this disconnect reason would be considered normal. However, if the connection has negotiated EC (LAPM or MNP4), and hence in data mode, then this disconnect reason could be generated by a dirty disconnect (that is, a disconnection that is not a graceful call termination). This is due to the fact that if the client DTE (in data mode) disconnects the call in an orderly fashion (with DTR drop or +++/ATH), then the client modem will send us a LAPM DISC (or MNP LD) before it goes onhook, thus generating a disconnect reason 0x220 rather than 0x1f06. So network indicated disconnect is, in this case, probably indicative of an unhappy client modem, one that decided it could no longer sustain carrier for some reason. |
| 3 | 0x1f07 | NAS terminated SS7/COT operation. Disconnection has occurred because the NAS has terminated the SS7/COT (Continuity Test) operation. |
| 3 | 0x1f08 | The SS7/COT operation was terminated by the router because of a T8/T24 timeout. |
| - | 0x1fff | Unsolicited. TERMINATING. The host sends this disconnect reason when it receives a unsolicited terminating message. |
Disconnect Reason: Types
The disconnect reason:types describes when the call disconnect actually occurred. They can be categorized into two main types:during call setup and during data mode (steady state). The following table specifies the most common disconnect reason types and their values as indicated in the disconnect reason.
| Disconnect Type | Disconnect Type (Hex) | Description |
|---|---|---|
| 0 | 0x0... | (unused) |
| 1 | 0x2... | (unused) |
| 2 | 0x4... | Other situations. |
| 3 | 0x6... | Condition occurred during call setup. |
| 4 | 0x8... | In data mode. Rx (line to host) data flushing OK. The disconnect condition occurred in data mode. MICA attempts to deliver any received data to the host (IOS). For some disconnects (for example, PIAFS), this is the only data mode type used; no indication is made of data flushing direction. |
| 5 | 0xA... | In data mode. Rx (line to host) data flushing not OK. The disconnect condition occurred in data mode. MICA attempts to deliver any received data to the host (IOS). In legacy MICA code, this type is equivalent to type 4 above. Though IOS displays such disconnects as not OK, no problems have actually occurred. |
| 6 | 0xC... | In data mode. TX (host to line) data flushing OK. The disconnect condition occurred in data mode. MICA attempts to transmit buffered host (IOS) data to the partner modem. |
| 7 | 0xE... | In data mode. TX (host to line) data flushing not OK. The disconnect condition occurred in data mode. MICA attempts to transmit buffered host (IOS) data to the partner modem. In legacy MICA code, this type is equivalent to type 6 above. Though IOS displays such disconnects as not OK, no problems have actually occurred. |
Related Information
FeedbackContact Cisco
- Open a Support Case
- (Requires a Cisco Service Contract)