MICA 调制解调器状态和断开原因
目录
简介
本文档介绍如何解释思科调制解调器ISDN信道聚合(MICA)调制解调器报告的呼叫断开原因代码。
注意： 本文档包含ITU标准中定义的许多术语，如V.90、V.44、V.42bis和V.34。有关这些术语的详细信息，请参阅相应的ITU-T 
标准。本文档未对ITU-T标准中指定的术语进行说明。
先决条件
要求
本文档的读者应了解以下内容：
每当清除或断开使用MICA域特定部件(DSP)的呼叫时，MICA会记录断开的原因。您可以使用此原因确定断开是否正常。否则，您可以使用它跟踪可能的故障源。调制解调器可能会因多种因素而断开连接，例如客户端断开、电信公司错误和网络接入服务器(NAS)的呼叫中断。典型的断开原因是一端的DTE（客户端调制解调器或NAS）希望关闭它。这种“正常”断开表示断开不是调制解调器或传输级错误造成的。有关确定断开原因是否正常的详细信息，请参阅通用调制解调器和NAS线路质量概述。
使用的组件
MICA调制解调器用于以下接入服务器：
-
Cisco 3600 系列路由器
-
AS5200
-
AS5300
-
AS5800
本文档中的信息都是基于特定实验室环境中的设备创建的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您是在真实网络上操作，请确保您在使用任何命令前已经了解其潜在影响。
规则
有关文件规则的更多信息请参见“ Cisco技术提示规则”。
确定调制解调器状态
使用show modem log slot/port命令查找MICA调制解调器的当前状态。在此日志输出中，最近的条目出现在日志末尾。当前MICA调制解调器状态显示在最后一个调制解调器状态（更改）事件中。在下面的示例输出中，调制解调器状态处于空闲状态，标有调制解调器状态事件00:00:28。有关可能的MICA调制解调器状态的详细信息，请参阅MICA调制解调器状态表。
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
确定断开原因
每当调制解调器连接终止时，NAS都会报告两个断开原因：DTE(IOS)原因和DCE(MICA)原因。使用以下三种主要方法可报告这些断开原因：
-
调制解调器呼叫记录:这些报告了IOS®软件和MICA调制解调器断开原因。
-
AAA 记账日志:这些报告仅报告IOS软件断开原因。
-
IOS命令：命令(如show modem operational-status和show modem log)仅报告MICA调制解调器断开原因。
调制解调器呼叫记录
特定连接的IOS和调制解调器断开原因显示在调制解调器呼叫记录(MCR)中。 MCR在每次呼叫终止期间由NAS发送到系统日志服务器。调制解调器呼叫记录在Cisco IOS软件版本11.3AA和12.0T中引入，并使用命令modem call-record terse激活(在NAS上)。有关实施调制解调器呼叫记录的详细信息，请参阅文档使用系统日志、NTP和调制解调器呼叫记录来隔离故障和排除故障。
在如下所示的调制解调器呼叫记录示例中，disk(radius)指示的IOS断开原因为Lost Carrier/Lost Carrier，而disk(modem)指示的调制解调器断开原因为:
A220 Rx (line to host) data flushing - not OK/EC condition - locally detected/received DISC frame -- normal LAPM termination
有关解释调制解调器断开原因的详细信息，请参阅表“Mica Modem Disconnect Reasons”。
*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 记账日志
AAA记帐日志也可用于确定IOS断开原因。在下面的示例AAA sql查询中，我们可以看到radius断开原因：
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
在上例中，断开代码(disk-cause=4)表示断开是由空闲超时到期引起的。
注意：AAA记帐日志不显示MICA断开原因，因此本文档中提供的表无法用于解释Radius断开原因。
有关实施AAA记帐的详细信息，请参阅文档实施基于服务器的AAA记帐。
show modem operational-status 和 show modem log 命令
IOS命令show modem operational-status slot/port和show modem log slot/port可用于确定MICA断开的原因。
此命令的输出显示了连接丢失的原因或当前连接不符合预期的原因。有关不同类型的断开连接的说明，请参阅以下断开原因。
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.
show modem log slot/port还显示断开连接原因
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
断开原因格式
断开原因包括四个十六进制数字。三个低位十六进制数字可用于确定断开原因。高位十六进制数字通常表示断开原因的类型或断开原因发生的时间。这些选项在断开原因一节中介绍：类型。例如，如果断开原因为0xWXYZ，则0xXYZ可以识别断开原因，而0xW表示断开原因的发生时间。
在上述示例中， 0xF03和0x220标识断开原因，而0xD和0x8 指示断开原因的时间。MICA调制解调器断开原因一节中提供了MICA断开原因的定义。
有关MICA调制解调器操作的详细信息，请参阅Cisco AS5x00基础IP调制解调器服务案例研究中的验证调制解调器性能和调制解调器管理操作文档。
MICA 调制解调器状态
| 状态 | 描述 |
|---|---|
| 空闲(#0) | 在此状态下，调制解调器会话当前处于非活动状态。从DSP接收所有操作都已关闭的验证后，从TERMINATING状态输入IDLE状态。 |
| CALL_SETUP(#5) | 在这种状态下，调制解调器信号处理器准备接收并生成T1、多频(MF)、双音多频(DTMF)、R1、R2和呼叫进度信号。调制解调器将保持CALL_SETUP状态，直到收到来自主机的LINK_TERMINATE、SOFTWARE_RESET或INITIATE_LINK消息。 |
| 连接(#10) | 仅当收到主机命令Initiate时，才从CALL_SETUP(#5)状态输入CONNECT状态。在应答模式下，调制解调器会话已启动活动，但尚未开始产生应答音。在“发起”模式下，调制解调器会话已启动活动，但尚未检测到应答音。 |
| 链路(#15) | 仅在检测到应答音（发起）或应答音（应答）启动时，才从CONNECT状态进入链路状态。 在应答模式下，调制解调器会话向线路发送应答音。在“发起”模式下，调制解调器会话已检测到所需的最小（可配置）应答音量。这表示存在远程对等体。 |
| QC(#16) | 如果QC已启用，并且在收到QCA序列（发起模式）或发送QCA序列（应答模式）时，从LINK或V.8 bis Exchange状态输入快速连接(QC)。 |
| 培训(#20) | 在此状态下，调制解调器会话协商链路期间使用的物理调制标准（如配置）。TRAINUP状态仅在以下情况下从LINK状态输入：
|
| EC_NEGOTIATION(#25) | 在此状态下，调制解调器会话协商链路期间使用的纠错和数据压缩协议。当两个调制解调器都同意设置（两个调制解调器功能和配置的交集）时，就能成功协商。如果交叉点为空，则调制解调器断开连接或启动非错误连接会话。EC_NEGOTIATING状态从TRAINUP状态进入，当成功完成物理调制同步。 |
| STEADY_STATE(#30) | 在此状态下，调制解调器会话能够在链路上传输数据。STEADY_STATE状态从EC_NEGOTIATION状态输入：
|
| STEADY_STATE_RETRAINING(#35) | 在此状态下，调制解调器会话当前正在重新培训。STEADY_STATE_RETRAINING状态从STEADY_STATE或STEADY_STATE_SHIFTINGSPEED状态进入：
|
| STEADY_STATE_SHIFTINGSPEED(#40) | 在此状态下，调制解调器会话当前处于变速状态。STEADY_STATE_SHIFTINGSPEED状态从STEADY_STATE状态进入：
|
| STEADY_STATE_ESCAPE(#45) | 在此状态下，调制解调器仍与远程对等体连接，但主机接口处于AT命令模式。此状态仅在收到有效的Hayes转义序列时输入。在传真模式下，此状态表示T30引擎正在接受来自主机的AT命令。有关传真呼叫的信息，请参阅STEADY_STATE(#30)状态。 |
| 终止(#50) | 在此状态下，调制解调器会话尝试刷新用户数据并清除数字信号处理器(DSP)。 在Software_reset上，没有有序刷新，DSP为RESET。TERMINATE状态从任何状态输入：
|
| 暂候(#55) | 调制解调器会话处于保持状态，链路上没有数据通过。在收到调制解调器保持(MoH)请求消息(MHReq)时，从稳定状态进入保持状态。 如果调制解调器处于保持状态(注册S62)，则调制解调器应发送调制解调器处于保持状态确认(MHack)序列，以在检测到静默或RT时授予请求并发送应答回音(ANSam)。如果在保持状态下检测到呼叫菜单(CM)信号（对于V.8）或快速连接确认QCA(QC — 注册S63)序列，调制解调器应退出保持状态并响应V.8或QC（注册S63）之后的启动序列()建议。如果在定义保持超时值后未检测到启动序列，调制解调器应退出保持状态并断开连接。如果调制解调器处于保持状态，则调制解调器应传输MHnack。如果在传输MHnack后检测到MHcda，调制解调器应断开。如果在MHnack传输后检测到MHfrr，调制解调器应发送应答回音，并准备从远程调制解调器检测CM(V.8)或QCA(QC — 注册S63)序列。有关保持调制解调器的详细信息，请参阅ITU-T V.92规范 。 注意：MICA状态#55以前是VOICE状态，现在已从2.9.1.0及更高版本中删除了该状态。 |
| V.8bis交换(#71) | 此状态仅在检测到CRe（发起模式）或CRe（应答模式）启动时从CONNECT状态进入。 应答模式：调制解调器会话正在向线路传输功能请求自动应答(CRe)。发起模式：调制解调器会话已检测到功能请求 — 自动应答(CRe)。 这表示存在远程对等体。 |
| 测距(#72) | 在开始往返延迟估计(RTDEd)时，从LINK或QC(注册器S63)状态输入测距。 此状态仅适用于V.32及以上标准。 |
| 测距短(#73) | 在启动往返延迟估计 — 数字调制解调器(RTDEd)时，从QC（寄存器S63）输入测距短 |
| HD系列(#74) | HD TRAIN（半双工培训）在自适应过滤器培训开始时从RANGING或RANGING SHORT输入。这适用于V.22bis及以上版本。 |
| STEADY_STATE_PIAFS_RESYNC(#80) | 输入STEADY_STATE_PIAFS_RESYNC表示个人手机互联网接入论坛标准(PIAFS)呼叫已失去同步并正在执行重新同步。 |
| STEADY_STATE_PIAFS_SPEEDSHIFT(#85) | 输入STEADY_STATE_PIAFS_SPEEDSHIFT表示PIAFS呼叫正在协商变速。这是一个短暂的过渡状态。MICA将永远不会处于此状态。如果重新同步导致速度转移，则MICA从STEADY_STATE_PIAFS_RESYNC转换到此状态，然后转到STEADY_STATE。如果重新同步不会导致速度转移，则完成时，STEADY_STATE_PIAFS_RESYNC会直接转换到STEADY_STATE。 |
Mica 调制解调器断开原因
MICA调制解调器断开原因由四个十六进制数字组成。三个低位十六进制数字唯一标识断开原因。高位十六进制数字表示断开原因的类型或断开原因发生的时间。在上例中，断开代码为十六进制0xDF03,0xF03标识断开原因，而0xD 指示断开原因(断开原因：类型)。
下面描述的断开原因不包括断开类型。因此，从您断开连接的原因中，删除最左侧的十六进制数字，并将其余数字与以下选项进行比较。在上例中，在下面的部分查找0xF03。
注：在本文档中，主机调制解调器是Cisco接入服务器上的MICA调制解调器，而客户端调制解调器是远程设备调制解调器（例如，客户端PC调制解调器）。
| 断开类型 | 断开原因代码 | 描述 |
|---|---|---|
| - | 0 | 尚未断开连接。如果在加载端口件后或呼叫期间立即查询断开原因（在稳定状态之前），您会看到此代码。 |
| 一般断开原因（0类） | ||
| 2 | 0x001 | Cisco IOS由于某种原因突然终止了呼叫，例如，第1层在包含该呼叫的物理跨度上关闭。 |
| 2 | 0x002 | 纠错(EC)层终端。 |
| 2 | 0x003 | Microcom网络协议5(MNP5)解压任务在数据流中收到非法令牌。此断开原因在数据模式(0x3003)期间发生。 调制解调器或合作伙伴执行解压或纠错时可能出现逻辑错误。（也可能是意外线路命中或内存错误。） |
| 2,4,6 | 0x004 | V.42bis或V.44解压任务在数据流中收到非法令牌。在数据模式(0x4004)期间可能会发生此断开原因。 调制解调器或合作伙伴执行解压或纠错时可能出现逻辑错误。（也可能是意外线路命中或内存错误。） 对于V.44，此代码由诊断链路信息字段索引119（用作调试工具的八字节信息字段）补充。 |
| 2 | 0x005 | MICA软件错误。此断开原因的错误代码为0x4005。出现MICA软件错误，表示协处理器状态变量错误。 |
| 6 | 0x006 | 本地调制解调器检测到ATH命令。此断开原因在数据模式（0xC006和0xE006）期间发生。 本地调制解调器(MICA)检测到ATH(Hangup)命令。 例如，在从IOS拨出时，在呼叫连接后，IOS DTE接口通过发送带内ATH命令来清除呼叫。 |
| 3 | 0x007 | AT拨号命令已中止。AT拨号命令被any key abort命令中止。例如，主机调制解调器发出呼叫。在连接建立期间，在STEADY STATE之前，按任何键将导致AT拨号命令中止。 |
| 3 | 0x008 | 呼叫用时过长，无法完成连接。请注意，此断开连接的S7计时器(拨号后等待载波)已过期。此断开原因在呼叫设置期间发生(0x6008)。 由于重新培训，主机调制解调器用时过长，无法建立连接。原因如下：难于选择（协商）第I层标准（例如，在返回前中止呼叫，断开原因为0x6102），或者第I层和第II层的组合建立时间过长。例如，纠错协商在重新培训之前需要较长的时间，或者由于客户端调制解调器尝试以积极速率连接时引入的比特错误（客户端调制解调器的接收器尝试以它无法维持的速率连接）。 此类断开对CSR计数。如果应答调制解调器没有听到来自信道的声音（例如，发起方不是调制解调器），也可能发生此断开。 |
| 2 | 0x009 | DSP已重置（命令，内部或自发）。 此断开原因的错误代码为0x4009。主机调制解调器中的DSP已由控制处理器(CP)或信号处理器(SP)重置。 如果未确认从CP到SP的邮件，CP将重置DSP。如果SP出现内部不一致错误，它将重置自己。 |
| 4,6 | 0x00A | 收到非法的STEPUP代码字。指定当STEPUP代码字导致C2（当前代码字大小）的值超过N1(最大代码字大小：协商)，仅对V.44和V.42bis有效。 |
| 4,6 | 0x00B | 收到非法的V.42bis代码字。指定在任何时候接收等于C1的代码字（下一个空字典条目），并且对V.42bis有效。（在V.42bis中接收代码字= C1是非法的，但在V.44中是合法的）。 |
| 4,6 | 0x00C | 在V.44或V.42bis中接收非法令牌（太大）。这意味着收到的V.42bis或V.44码字大小超过协商的最大值。指定在任何时间接收大于C1（下一个空字典条目）的代码字，并且对V.44和V.42bis有效。 |
| 4,6 | 0x00D | 收到V.44或V.42bis保留的命令代码。指定接收保留的命令代码，对V.44和V.42bis有效。 |
| 4,6 | 0x00E | V.42bis或V.44接收的代码字大于下一个空字典条目。收到V.44非法STEPUP字符。这表示收到STEPUP控制代码，该代码会导致C5（序数大小）的值超过8。这仅适用于V.44。 |
| 4,6 | 0x00F | V.44 Rx词典已满。指定在Rx节点树已满时接收不是字典重置的代码字。仅适用于V.44。 |
| 4,6 | 0x010 | V.44 Rx历史记录已满。指定在Rx历史记录已满时接收不是字典重置的代码字。仅适用于V.44。 |
| 4,6 | 0x011 | 超出V.44/V.42bis非法Rx字符串大小。指定接收导致超出最大协商字符串大小的代码字。它适用于V.44和V.42bis。 |
| 4,6 | 0x012 | 出现V.44协商错误，表示出现V.44协商错误。对于V.44，该代码由诊断链路信息字段索引119补充。诊断链路信息字段索引是用作调试工具的八字节信息字段。 |
| 4,6 | 0x013 | 出现V.44压缩错误，表示出现V.44压缩错误。对于V.44，该代码由诊断链路信息字段索引119补充。诊断链路信息字段索引是用作调试工具的八字节信息字段。 |
| DSP报告的条件（1类） | ||
| 0x1xx | SPE报告的DSP条件 | |
| 3,4,5 | 0x100 | DSP丢失了载波信号。即，MICA检测到客户端调制解调器载波丢弃。此断开原因在呼叫建立和数据模式（即0x6100、0x8100和0xA100）期间发生。 MICA DSP在大于寄存器S10中指定的值（载波丢失后的挂断延迟）的时间段内停止了听载波。 这可能意味着通话路径消失或客户端停止传输。如果第II层协议（V.42和/或V.42bis）生效，则出现这种断开情况将是异常的。此断开原因有时在EC协商期间（在数据模式之前）发生。 即，I层已成功协商（导致载波信号检测），并且尝试建立I层协议（V.42和/或V.42bis）时发生断开。 常见原因是用户在连接发生之前中止呼叫。由于连接时间过长（例如，第I层协商期间多次重排），意外拨号、中止启动和客户端应用超时。 此类故障对CSR有影响。在正常数据模式下，当客户端突然丢弃载波时，载波丢失情况也可能发生。常见原因是客户端调制解调器部分（即，客户端调制解调器仅丢弃载波信号）的未协商或脏断开。 如果链路突然断开（即网络错误），客户端调制解调器的电源关闭以断开呼叫，则会发生这种情况。这也可能发生在价格较低的客户端调制解调器上，这些调制解调器不在DTR丢弃上实施第I层和/或第II层清除协议。对于大量客户端调制解调器，这被视为正常断开。当客户端调制解调器进行脏断开时，0xA103、0xA100和0xDF06之间存在争用情况。如果主机调制解调器中的DSP检测到载波丢失，则0xA100将成功，并指示为断开原因。如果DSP在达到寄存器S40限制之前未检测到载波丢失并重新训练，则0xA103将成功。如果网络检测到呼叫已断开，并且向路由器发出断开信号，则0xDF06将获胜。当主机调制解调器处于数据模式时，此断开原因不计入CSR。 |
| 3 | 0x101 | 当发生呼叫故障时，当信号处理器(SP)处于应答回音(ABT)检测阶段时，会发生这种情况。 |
| 3 | 0x102 | 由于调制不兼容或线路不良，调制解调器培训期间的呼叫失败。呼叫建立期间(0x6102)发生此断开原因。 这可能表示尝试协商不受支持的调制，例如传统Rockwell专有调制（K56Plus、V.FC等）。 其他可能的原因包括：由于严重的线路损坏、冲激噪声、中断培训、调制参数不兼容，以及可能无法正确选择第I层标准，DSP无法进行训练。此类断开对CSR计算。 |
| 4,5 | 0x103 | 连续的轮班或变速太多。重新培训限制是通过注册S40指定的。此断开原因在呼叫建立和数据模式（0x6103、0x8103和0xA103）期间发生。 在呼叫过程中，发生了太多的重新训练，这使呼叫无效，因为数据速率将非常低，甚至无用。可能的情况是客户端调制解调器未完成清除协议（例如，电信公司在连接中断呼叫），MICA尝试通过重新发送恢复呼叫。一旦达到重新培训限制(使用S40寄存器可以更改重新培训限制),MICA会丢弃呼叫并报告此断开原因。在某些情况下（信道化T1/E1），此类断开可能被视为正常的STEADY状态断开。或者，这可能只是由于MICA无法从中恢复的可能线路错误而导致脏断开的结果。因此，由于呼叫已建立，此类断开不计入CSR。当客户端调制解调器对初始连接速率过于激进且无法维持呼叫时（如旧USRobotics客户端调制解调器所观察），EC协商期间也可能出现此断开原因。 此类断开对CSR而言确实有效。当客户端调制解调器进行脏断开时，0xA103、0xA100和0xDF06之间存在争用情况。如果主机调制解调器中的数字信号处理器(DSP)检测到载波丢失，则0xA100会赢，并指示为断开原因。如果DSP在达到寄存器S40限制之前未检测到载波丢失并重新训练，则0xA103将成功。如果网络检测到呼叫已断开，并且向路由器发出断开信号，则0xDF06将获胜。当主机调制解调器处于数据模式时，此断开原因不计入CSR。 |
| 3 | 0x104 | 检测应答回音(ABT)结束的问题。 V.34培训期间协商失败或噪音过大。主机调制解调器应答并发送V.8bis和调制的2100Hz应答回音(ABT)，并进行相位反转，但在训练序列期间会遇到过多的噪音。查找从主叫调制解调器到应答调制解调器的路径上的一个或两个方向的错误。当公共交换电话网(PSTN)中存在用于拨号的延迟超过一秒并导致调制解调器无法训练回声消除器时，会发生类似行为。其他可能的原因包括：
|
| 3 | 0x105 | SS7/COT（连续性测试）操作已成功完成此断开原因发生在呼叫建立期间(0x6105)。 SS7/COT（连续性测试）操作已成功完成。 |
| 3 | 0x106 | SS7/COT（连续性测试）操作失败：T8/T24超时等待音频打开。呼叫建立期间（即0x6106）会发生此断开原因。 SS7/COT（连续性测试）操作已失败，因为T8/T24计时器在等待音频打开时超时。 |
| 3 | 0x107 | SS7/COT（连续性测试）操作失败：T8/T24超时等待音频关闭。呼叫建立期间(0x6107)会发生此断开原因。 SS7/COT操作失败，因为T8/T24计时器在等待音调关闭时超时。 |
| 4 | 0x108 | MICA清除调制解调器保持(MOH)。从客户端调制解调器收到调制解调器保持清除请求。V.92指定清除原因可以是：
|
| 4 | 0x109 | 已达到调制解调器保持(MOH)超时值。 |
| 本地EC条件（2类） | ||
| 0x2xx | 本地EC条件 | |
| 3 | 0x201 | 在协商期间从未收到LR（链路请求）帧。呼叫建立期间（即0x6201）会发生此断开原因。 这意味着主机调制解调器在纠错协商期间从未收到LR帧。对等调制解调器可能不支持V.42中的MNP。 |
| 3 | 0x202 | 已收到包含错误参数的LR帧(PARAM1)。 已接收的MNP链路请求(LR)帧有错误或意外的PARAM1。有关PARAM1的详细信息，请参阅V.42规范。 |
| 3 | 0x203 | 收到不兼容的LR（链路请求）帧。呼叫建立期间(0x6203)会发生此断开原因。 收到的MNP LR帧与主机调制解调器的EC设置不兼容。 |
| 4,5 | 0x204 | 连续重新传输的次数过多。此断开原因在呼叫建立和数据模式（0x8204、0xA204和0x6204）期间发生。 此断开原因可能是线路噪音所致。例如，主机调制解调器将数据传输到客户端调制解调器，但线路上的噪音会导致客户端错误地（或根本没有）接收数据。因此，过多的噪音会导致过多的重新传输。如果MICA调制解调器不实现这一点，客户端调制解调器也可能已断开连接。因此，主机调制解调器在不知道客户端调制解调器不再存在的情况下持续重新传输。有时，当呼叫以错误压缩(EC)协议(调制解调器链路访问过程(LAPM)或Microcom网络协议(MNP))连接时，MICA无法将帧传输到客户端调制解调器。客户端调制解调器无法确认MICA的初始传输，然后无法响应S19（纠错重传限制）轮询（默认为12），因此MICA断开呼叫。一个原因可能是传输路径中的载波在客户端无法下移时严重降级。另一个原因可能是客户端的EC引擎问题（如果Windows停止响应，Windomed系统会发生问题）。 |
| 6,7 | 0x205 | 非活动超时，已发送MNP链路断开(LD)。此断开原因在数据模式（0xC205和0xE205）期间发生。 主机调制解调器向客户端调制解调器发送LD帧，指示出现非活动超时。 |
| 4,5 | 0x206 | EC协议错误。此断开原因在数据模式（0x8206和0xA206）期间发生。 这是一般的全捕获协议错误。它表示发生了LAPM或MNP EC协议错误。 |
| 3 | 0x210 | 没有可用的EC回退协议。此断开原因发生在呼叫建立(0x6210)中。 纠错协商未成功。呼叫被终止，因为没有可用的纠错回退协议。S-register S25（链路协议回退）确定可用的回退协议。选项包括异步成帧、同步成帧或断开（挂机）。 |
| 3 | 0x211 | 协商期间从未收到交换ID标识(XID)帧。呼叫建立期间(0x6211)会发生此断开原因。 这意味着主机调制解调器在纠错协商期间从未收到XID帧。客户端调制解调器可能不支持V.42中的LAPM。 |
| 3 | 0x212 | 收到的XID帧与本地设置不兼容。此断开原因发生在呼叫建立(0x6212)中。 收到的XID帧与主机调制解调器的设置不兼容。例如，客户端调制解调器可能指示MNP5，而主机调制解调器仅指示V.42和V.42bis。 |
| 3,4,5 | 0x220 | 已接收断开连接(DISK)帧。这是正常的LAP-M断开。此断开原因在呼叫建立和数据模式（0x 6220、0x8220和0xA220）期间发生。 呼叫正常终止，并从客户端正确清除。（即，V.42断开数据包从客户端调制解调器发送到NAS调制解调器。） 客户端调制解调器丢弃了DTR并完全协商了清除协议。 |
| 3,4,5 | 0x221 | 收到DM帧。对等体可能正在断开连接。此断开原因在呼叫建立和数据模式（0x6221、0x8221和0xA221）中发生。 客户端调制解调器指示它正在断开连接。在呼叫建立过程中，此原因表示客户端调制解调器正在放弃协商纠错。 |
| 4,5 | 0x222 | 收到错误的序列号。此断开原因在数据模式（0x8222和0xA222）中发生。 主机调制解调器收到的LAPM或MNP纠错帧序列号或确认号错误。LD或帧拒绝(FRMR)帧被发送到客户端调制解调器，表示主机调制解调器正在断开连接。 |
| 4,5 | 0x223 | 以稳定状态接收SABME帧。此断开原因在数据模式（0x8223和0xA223）中发生。 这被解释为LAPM纠错协议在稳态时出错。这意味着客户端调制解调器可能因收到帧拒绝(FRMR)而已重置。 |
| 4,5 | 0x224 | 稳态接收MNP XID帧。此断开原因在数据模式（0x8224和0xA224）中发生。 这被解释为LAPM纠错协议在稳态时出错。这意味着客户端调制解调器可能因收到帧拒绝(FRMR)而已重置。 |
| 4,5 | 0x225 | 在稳定状态下收到MNP LR帧。此断开原因在数据模式（0x8225和0xA225）中发生。 这被解释为MNP纠错协议在稳态时出错。这意味着客户端调制解调器已重置。 |
| PIAFS协议特定条件（2类，续） | ||
| 3,4 | 0x230 | 收到的消息比该消息类型的最小定义长度短。 |
| 3,4 | 0x231 | 收到未知或未实现的PIAFS帧类型。这包括FI（主帧类型），以及协商、同步或控制类（子类型）。 |
| 3,4 | 0x232 | 未知的PIAFS控制帧标识符(CFI)。收到的控制帧的类ID未知或未实现。请注意，连续帧和用户帧未实现，并且没有已知通知帧。 |
| 3,4 | 0x233 | PIAFS通信协商失败。初始同步后，交换通信参数Req/Ack帧。参数不可接受，或者发起方检测到NAK（否定确认）响应。 注意：MICA只能作为客户端/启动器运行，以用于测试 |
| 3,4 | 0x234 | PIAFS ARQ协商失败。重新同步后，交换ARQ请求(Req)/确认(Ack)帧。参数不可接受，或者发起方检测到Nak响应。 注意：MICA只能作为客户端/启动器运行，以用于测试 |
| 3,4 | 0x235 | 检测到PIAFS控制传输协议问题。发起方收到一个Ack/Nak/Rsp，其ID、类和序列与原始Req/Ntf不匹配。 注意：MICA只能作为客户端或启动器运行以用于测试 |
| 3,4 | 0x236 | 此断开原因不再表示收到DataLinkRelease请求帧。它现在表示断开，而先前未生成断开原因。这表示MICA正在断开呼叫，但发现没有发布任何原因。 |
| 3,4 | 0x237 | PIAFS同步接收等待计时器(T001)已过期。此计时器在发送同步请求帧时启动，在检测到同步接收帧时停止。只有当MICA端口作为客户端或启动器运行时，才会发生此错误，这仅在测试期间发生。默认值为 15 秒。 |
| 3,4 | 0x238 | PIAFS后同步接收传输计时器T002已过期。此计时器在发送同步接收帧时启动，在检测到同步接收（冲突情况）或控制帧时停止。只有当MICA端口作为服务器（应答模式）运行时，才会发生此错误，即正常操作模式。默认值为 15 秒。 |
| 3,4 | 0x239 | PIAFS同步请求等待计时器T003已过期。此计时器在检测到连续FCS错误时启动，在检测到有效的同步请求帧时停止。仅当MICA端口作为服务器（应答模式）运行时，才会发生此错误，即正常操作模式。默认值为 15 秒。 |
| 3,4 | 0x23A | PIAFS计时器T101已过期：控制帧确认等待计时器。发送控制帧请求或通知时开始，确认帧时停止。仅当MICA端口作为客户端或启动器运行时，才会出现此错误，仅在测试期间（10秒）发生。 |
| 3,4 | 0x23B | PIAFS:收到超出协商范围的FBI（ACK序列号），或收到FBI=0且数据帧非空。 |
| 3,4 | 0x23C | PIAFS:收到的FFI（MSG序列号）超出协商范围，或FFI=0。 |
| 3,4 | 0x23D | PIAFS:协商数据窗口小于RTF（往返延迟）值。Portware不再发布此错误，因此永远不应该看到。 |
| 3,4 | 0x23E | PIAFS:消息的数据长度字段太大。应为0-73。 |
| 3,4 | 0x23F | PIAFS内部错误：SREJ调用返回了错误代码。 |
| 3,4 | 0x240 | PIAFS常规协议错误。这是错误的集合，这些错误没有关联的断开原因。 |
| 3,4 | 0x241 | PIAFS:协议协商失败。两个站点都不接受任何协议（例如，数据传输协议固定速度、DTP可变速度类型1）。不可接受的协议为DTP变速类型3或实时协议。 |
| 3,4 | 0x242 | PIAFS:测量的RTF（往返延迟）值不在定义（可接受）范围内。 |
| 3,4 | 0x243 | PIAFS内部错误：事件处理程序中的未知事件。交换机语句的默认情况。 |
| 3,4 | 0x244 | 在PIAFS 2.1速移期间发生信号处理器(SP)响应超时。Mica的CP在200毫秒内未看到速度变化响应。 |
| 3,4 | 0x245 | MICA的CP在CP/SP共享控制结构中看到不一致的控制信息。特别地，数据缓冲器具有位于数据缓冲器边界(0-63)外的头或尾偏移。 |
| 从合作伙伴（3类）收到错误的MNP或LAPM协议命令 | ||
| 4.5 | 0x3xx | EC检测到错误的命令代码。接收的unknown命令位于最后两位。MNP LD或LAP-M帧拒绝(FRMR)帧会作为响应发送。 |
| LAPM合作伙伴表示MICA协议错误（4类） | ||
| 4,5 | 0x4xx | 客户端在LAP-M FRMR帧中指示的EC条件。位映射原因位于最后两位。 |
| 4,5 | 0x401 | LAPM:peer reports bad命令。主机调制解调器从客户端调制解调器收到FRMR帧。收到的FRMR帧表示客户端调制解调器从主机调制解调器收到错误纠正帧，该帧包含错误命令。 |
| 4,5 | 0x403 | LAPM:对等体报告数据字段不被允许或长度不正确（U帧）。 主机调制解调器从客户端调制解调器收到FRMR帧。接收的FRMR帧表示客户端调制解调器从主机调制解调器接收了错误纠正帧，该帧包含不允许的数据字段或包含长度不正确（U帧）的数据字段。 |
| 4,5 | 0x404 | LAPM:对等报告数据字段长度大于N401（V.42中指定的最大信息字段长度），但具有良好的帧校验序列(FCS)。 NextPort调制解调器从客户端调制解调器收到一个FRMR帧。接收的FRMR帧指示客户端调制解调器从NextPort接收了错误纠正帧，该帧包含的数据字段长度大于I帧、SREJ帧、XID帧、UI帧或TEST帧的信息字段(N401)中可承载的最大八位字节数。帧校验序列良好。 |
| 4,5 | 0x408 | LAPM:对等体报告接收序列号错误或N(R)。 主机调制解调器从客户端调制解调器收到FRMR帧。收到的FRMR帧表示客户端调制解调器从主机调制解调器收到错误纠正帧，该帧包含错误的接收序列号。 |
| MNP合作伙伴表示断开连接或MICA协议错误（5类） | ||
| 4,5 | 0x5xx | 客户端在MNP LD帧中指示的EC条件。原因字段位于最后两位 |
| 3 | 0x501 | MNP:对等体从未收到LR帧。主机调制解调器从客户端调制解调器收到LD帧。收到的LD帧表示客户端调制解调器从未收到来自主机调制解调器的链路请求。 |
| 3 | 0x502 | MNP:对等体报告LR帧的参数#1错误。主机调制解调器从客户端调制解调器收到LD帧。收到的LD帧表示客户端调制解调器从主机调制解调器接收了包含错误（即意外）PARAM1的链路请求帧。有关PARAM1的详细信息，请参阅V.42规范。 |
| 3 | 0x503 | MNP:对等体报告LR帧与其配置不兼容。主机调制解调器从客户端调制解调器收到LD帧。收到的LD帧表示客户端调制解调器从主机调制解调器收到与客户端调制解调器的配置不兼容的LR帧。 |
| 4,5 | 0x504 | MNP:对等体报告连续EC重新传输过多。主机调制解调器从客户端调制解调器收到LD帧。收到的LD帧表示客户端调制解调器收到的连续重新传输过多。 |
| 4,5 | 0x505 | MNP:对等体报告非活动计时器已过期。主机调制解调器从客户端调制解调器收到LD帧。收到的LD帧表示客户端调制解调器的主机(DTE)在一段时间内没有将数据传送到客户端调制解调器。 |
| 3 | 0x506 | MNP:对等报告错误。主机调制解调器从客户端调制解调器收到LD帧。收到的LD帧表示客户端调制解调器收到MNP协议错误。 |
| 3 | 0x5FF | 正常MNP断开。主机调制解调器从客户端调制解调器收到LD帧。收到的LD帧表示正常的MNP终止，表示客户端调制解调器的DTR已丢弃，或者它收到了+++或ATH命令。此断开原因在呼叫建立和数据模式（0x65FF、0x85FF和0xA5FF）中发生。 主机调制解调器收到LD，表示正常终止。呼叫正常终止时从客户端正确清除（例如，断开数据包从客户端调制解调器发送到主机调制解调器）。 客户端调制解调器丢弃了DTR并完全协商了清除协议。 |
| PIAFS合作伙伴表示断开连接或MICA协议错误（6类） | ||
| 3,4 | 0x6xx | MICA收到PIAFS DataLinkRelease(PDLR)，原因是xx（请参阅下面的详细值）。 |
| 3,4 | 0x61x | PIAFS DataLinkRelease(PDLR)的普通类：0 — 正常版本。1 — 正常发布，禁止数据链路继续。2 — 正常版本，数据链路继续。...其他普通类 — 某些客户端设备特有的未定义类。 |
| 3,4 | 0x62x | PIAFS DLR（繁忙情况）不能使用资源类：8 - DTE繁忙。9 — 暂时阻碍。...其他资源使用不可能的类 — 某些客户端设备特有的未定义类。 |
| 3,4 | 0x63x | PIAFS DLR（错误参数）的服务利用率不可能类。9 — 无法设置请求参数。A — 请求参数设置目前不可能。..其他服务利用率不可能的类 — 某些客户端设备特有的未定义类。 |
| 3,4 | 0x64x | 尚未为PIAFS DLR提供服务类。1 — 尚未提供参数指示。...其他服务尚未提供类 — 某些客户端设备特有的未定义类。 |
| 3,4 | 0x65x | PIAFS DLR的信息内容类无效。 8 — 终端属性不匹配。...其他无效信息内容类 — 某些客户端设备特有的未定义类。 |
| 3,4 | 0x66x | PIAFS DLR 0的序列错误类 — 基本参数不足。1 — 未定义或尚未提供信息内容。5 - ARQ条件和信号不匹配。6 — 计时器到期。...其他序列错误类 — 某些客户端设备特有的未定义类。 |
| 3,4 | 0x67x | PIAFS DLR 1的其他特性类 — 语音呼叫期间。...其他特殊类 — 某些客户端设备特有的未定义类。 |
| 主机/IOS请求断开连接（31类） | ||
| 6,7 | 0x1fxx | 主机启动的断开连接。值是0x1F00和SessionStopCommand值之和。这是另一台主机终止的原因。主机原因以低位字节xx表示。 |
| 3,6,7 | 0x1f00 | 非特定主机启动的断开连接。值是0x1F00和SessionStopCommand值之和。这是捕获所有IOS启动的断开原因。它用于所有非标准断开。例如，这可能是调制解调器管理软件决定终止呼叫的结果。一个可能的解释是更高级别的身份验证失败RADIUS、TACACS或向主机调制解调器发出DTR丢弃的另一个应用。当主机调制解调器处于数据模式时，此类断开不会计入CSR。 |
| 3 | 0x1f01 | 拨号号码忙。由于主机指示拨号号码忙，因此发生了断开。 |
| 3 | 0x1f02 | 拨号号码未应答。由于主机指示拨叫的号码未应答，因此发生断开。 |
| 3,6,7 | 0x1f03 | 已丢弃虚拟DTR。此状态从当前使用调制解调器的I/O端口重定向器反映。由于主机丢弃了虚拟DTR线路，因此发生了断开。此通用断开原因由Cisco IOS软件启动。可能的原因包括空闲超时、收到PPP LCP TERMREQ、身份验证失败、Telnet挂断等。要确定挂机原因，请从调制解调器call-record terse命令或身份验证、授权和记帐(AAA)检查Radius断开原因。 |
| 6,7 | 0x1f04 | 本地主机检测到ATH(hangup)命令。 |
| 3 | 0x1f05 | 无法访问电信网络。由于主机无法访问网络(ISDN)，因此发生了断开连接。 |
| 3,4,5, | 0x1f06 | 网络指示断开连接。在数据模式之前或期间都可能发生这种情况。0x1f06断开意味着IOS从电路网络接收了电路挂断信号（即Q.931断开或CAS挂机信号），然后IOS在指示MICA挂断时将其传达给MICA。如果MICA到达数据模式，且未协商EC协议（LAPM或MNP4），则可能是正常断开。当Windows 95或98拨号网络(DUN)的用户在培训期间和呼叫达到稳定状态之前点击取消时，也会生成此原因。此外，如果客户端突然拔掉电话线/关闭调制解调器，则此断开原因会被视为正常。但是，如果连接已协商EC（LAPM或MNP4），因此处于数据模式，则此断开原因可能由脏断开（即不是正常呼叫终止的断开）生成。 这是因为，如果客户端DTE（在数据模式下）以有序方式（使用DTR丢弃或+++/ATH）断开呼叫，则客户端调制解调器将在LAPM DISK（或MNP LD）挂机前向我们发送LAPM DISK（或MNP LD），从而生成断开原因0x20，而非0x1f06。因此，网络指示断开可能表示客户端调制解调器不满意，该调制解调器认为由于某种原因，它无法再维持载波。 |
| 3 | 0x1f07 | NAS终止了SS7/COT操作。发生断开连接，因为NAS终止了SS7/COT（连续性测试）操作。 |
| 3 | 0x1f08 | 由于T8/T24超时，SS7/COT操作被路由器终止。 |
| - | 0x1ff | 未经请求。正在终止。主机收到未经请求的终止消息时会发送此断开原因。 |
断开原因：类型
断开原因：类型描述了呼叫实际断开的时间。它们可分为两种主要类型：呼叫建立期间和数据模式期间（稳定状态）。 下表指定了最常见的断开原因类型及其值，如断开原因所示。
| 断开类型 | 断开类型（十六进制） | 描述 |
|---|---|---|
| 0 | 0x0... | （未使用） |
| 1 | 0x2... | （未使用） |
| 2 | 0x4... | 其他情况。 |
| 3 | 0x6... | 在呼叫建立期间出现情况。 |
| 4 | 0x8... | 在数据模式下。Rx（行到主机）数据刷新正常。在数据模式中出现断开连接情况。MICA尝试将任何已接收的数据传送到主机(IOS)。 对于某些断开连接（例如，PIAFS），这是唯一使用的数据模式类型；没有显示数据刷新方向。 |
| 5 | 0xA... | 在数据模式下。Rx（行到主机）数据刷新不正常。在数据模式中出现断开连接情况。MICA尝试将任何已接收的数据传送到主机(IOS)。 在传统MICA代码中，此类型相当于上述第4类。虽然IOS显示这种断开状态为“不正常”，但实际上并未发生任何问题。 |
| 6 | 0xC... | 在数据模式下。TX（主机到线路）数据刷新正常。在数据模式中出现断开连接情况。MICA尝试将缓冲主机(IOS)数据传输到伙伴调制解调器。 |
| 7 | 0xE... | 在数据模式下。TX（主机到线路）数据刷新不正常。在数据模式中出现断开连接情况。MICA尝试将缓冲主机(IOS)数据传输到伙伴调制解调器。在传统MICA代码中，此类型相当于上述类型6。虽然IOS显示这种断开状态为“不正常”，但实际上并未发生任何问题。 |
反馈