拨号和接入 : 异步连接

MICA 调制解调器状态和断开原因

2016 年 10 月 27 日 - 机器翻译
其他版本: PDFpdf | 英语 (2015 年 8 月 22 日) | 反馈


目录


简介

本文描述如何解释思科ISDN调制解调器信道集中(MICA)调制解调器报告的呼叫断开原因代码。

注意: 本文包含在ITU标准定义例如V.90、V.44、V.42bis和V.34的许多期限。关于请参考适当的ITU-T标准的这些leavingcisco.com 期限的更多信息。在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)原因。使用三主要方法,这些断开原因可以报告:

  1. 调制解调器呼叫记录:这些报告IOSï ¿  ½软件和MICA调制解调器断开原因。

  2. Aaa accounting日志:这些报告仅IOS软件断开原因。

  3. IOS命令:命令例如show modem operational-statusshow modem log报告仅MICA调制解调器断开原因。

调制解调器呼叫记录

IOS和调制解调器断开原因特定的连接的在调制解调器呼叫记录(MCR)显示。MCR发送到系统日志服务器由NAS在每呼叫的终端时。调制解调器呼叫记录在Cisco IOS软件版本11.3AA和12.0T介绍和激活(在NAS)使用modem call-record terse命令。关于实现调制解调器呼叫记录的更多信息,参考本文使用Syslog、NTP和调制解调器呼叫记录隔离和排除故障故障

在如下所示的示例调制解调器呼叫记录,而disc(modem)表示的调制解调器断开原因是, disc(radius)表示的IOS断开原因是Lost carrier/Lost carrier

A220 Rx (line to host) data flushing - not OK/EC condition - locally detected/received    
DISC frame -- normal LAPM termination

参考表MICA调制解调器断开原因关于解释调制解调器断开原因的更多信息。

*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 accounting日志可能也用于确定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

断开代码(disc c ause=4),在上述示例,指示断开由空闲超时的有效期造成。

注意: Aaa accounting日志不显示MICA断开原因,因此在本文提供的表不可能用于解释RADIUS断开原因。

关于实现参考实现基于服务器的AAA核算的本文的Aaa accounting的更多信息。

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指示时,当断开原因发生了。

在以上示例中, 0xF030x220识别断开原因,当0xD0x8指示时,当断开原因发生了。MICA断开原因的定义在部分MICA调制解调器断开原因提供。

欲知关于MICA调制解调器操作的详情,请参阅在Cisco AS5x00案例研究的正在验证的调制解调器性能调制解调器管理操作文档关于基本IP调制解调器服务

MICA 调制解调器状态

状态 说明
IDLE (#0) 在此状态下,调制解调器会话是当前不激活的。空闲状态从在接收验证的终止的状态进入从DSP所有操作关闭了。
CALL_SETUP(-5) 在此状态下,调制解调器信号信号处理器准备收到和生成T1、多个频率(MF), Dual Tone Multi-frequency (DTMF), R1、R2和呼叫进展信号。调制解调器留在CALL_SETUP状态,直到收到从主机的一个LINK_TERMINATE、SOFTWARE_RESET或者INITIATE_LINK消息。
连接(#10) 连接状态从CALL_SETUP(-5)仅状态进入在接收host命令启动。在应答模式,调制解调器会话开展了活动,但是未开始导致应答信号音。在起动模式,调制解调器会话开展了活动,但是未检测应答信号音。
LINK (#15) LINK状态从仅连接状态进入在检测应答信号音(请产生)或应答信号音(答案)的开始。在应答模式,调制解调器会话传达应答信号音给线路。在起动模式,调制解调器会话检测应答信号音要求的最低的(可配置)相当数量。这表明有远端对等体。
QC (#16) 快速连接(QC)从LINK或V.8bis Exchange状态被输入QC是否启用和在接收QCA顺序(起动模式)或发送QCA顺序(应答模式)。
TRAINUP (#20) 在此状态下,调制解调器会话协商在链路期间(如配置)使用的物理调制标准。连接状态从LINK状态进入只:
  • 检测应答信号音的结尾(请产生)。
  • 完成应答信号音(答案)的发射。
EC_NEGOTIATING (#25) 在此状态下,调制解调器会话协商在链路期间和数据压缩协议将使用的错误纠正。当设置是愉快的对两调制解调器(两调制解调器容量和配置的交叉点),成功的协商被到达。如果交叉点空,调制解调器断开或开始一非错误连接会话。EC_NEGOTIATING状态从在成功完成物理调制同步的连接状态进入。
STEADY_STATE (#30) 在此状态下,调制解调器会话能传递在链路的数据。STEADY_STATE状态从EC_NEGOTIATING状态进入:
  • 在成功的协议协商(如配置)。
  • 从STEADY_STATE_RETRAINING和STEADY_STATE_SHIFTINGSPEED状态,作为物理链路顺利地重新协商。
  • 在传真模式;此状态意味T30引擎运转。在传真呼叫期间,有在STEADY_STATE之间的一切换对STEADY_STATE_ESCAPE。这代表通过其传真(T30)会话的不同的相位的传真呼叫。
STEADY_STATE_RETRAINING (#35) 在此状态下,调制解调器会话当前再培训。STEADY_STATE_RETRAINING状态从STEADY_STATE或STEADY_STATE_SHIFTINGSPEED状态进入:
  • 在主机Link_Control - [Retrain]命令。
  • 通过往返内部极限(可配置)。
STEADY_STATE_SHIFTINGSPEED (#40) 在此状态下,调制解调器会话当前速度转变。STEADY_STATE_SHIFTINGSPEED状态从STEADY_STATE状态进入:
  • 在Host_Link_Control - [Fallback, Fall-Forward]。
  • 通过往返内部极限(可配置)。
STEADY_STATE_ESCAPE (#45) 在此状态下,调制解调器仍然连接与远端对等体,但是主机接口在AT命令模式。此状态只进入在接收一有效Hayes转义序列。在传真模式,此状态意味T30引擎接受从主机的AT命令。请参阅STEADY_STATE (#30)关于传真呼叫的信息,状态。
终止(#50) 在此状态下,调制解调器会话尝试冲洗用户数据和清除数字信号信号处理器(DSP)。在Software_reset,没有顺序的冲洗,并且DSP是RESET。终止状态从所有状态进入:
  • 在LINK_TERMINATE或Software_reset从主机。
  • 在从DSP丢失的载波。
  • 在收据一ATH命令从DTE。
  • 在一个DISC/LD (断开)错误修正帧的收据从线路的。
  • 通过往返多种内部极限(可配置)。
暂挂中(#55) 调制解调器会话暂挂,并且数据不传递链路。保留状态从在接收Request信息的调制解调器保持(MOH)的稳定状态被输入(MHReq)。如果调制解调器保持启用(寄存器S62),调制解调器将传送调制解调器保持确认(MHack)顺序授权请求和传输答复音(ANSam),当沉默或RT检测。如果呼叫菜单(CM)信号(V.8)或快速连接确认QCA (QC -寄存器S63)顺序在保留状态检测,调制解调器将退出保留状态并且回应对遵从各自V.8或QC (寄存器S63)建议的启动的顺序。如果启动的顺序没有在定义的暂挂超时值以后检测,调制解调器将退出保留状态和断开。如果调制解调器保持禁用,调制解调器将传送MHnack。如果MHcda检测,在MHnack传送后,调制解调器将断开。如果MHfrr检测,在MHnack传送后,调制解调器将传送答复音并且准备好检测从远程调制解调器的CM (V.8)或QCA (QC -请注册S63)顺序。关于调制解调器保持的更多信息,参考ITU-T V.92规格leavingcisco.com

注意: MICA状态#55以前是语音状态,从端口件版本2.9.1.0当前删除以上。

V.8bis EXCHANGE(-71) 此状态从仅连接状态进入在检测CRe (起动模式)或CRe (应答模式)的开始。应答模式:调制解调器会话传送请求自动回答能力(CRe)到线路。起动模式:调制解调器会话检测请求自动回答能力(CRe)。这指示有远端对等体。
RANGING(-72) 范围从在开始往返时延估计(RTDEd)的LINK或QC (寄存器S63)状态被输入。此状态只适用于标准V.32并且向上。
排列的SHORT(-73) 排列肖特从QC (寄存器S63)被输入在开始往返形成延迟估算-数字调制解调器(RTDED)
HD TRAIN(-74) HD系列(半双工培训)从范围或范围被输入短缺在适应过滤器培训的开始。这适用于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调制解调器断开原因包括四十六进制数字。三个低阶十六进制数字独特识别断开原因。高阶十六进制数字指示断开原因发生断开原因或时间的种类。在以上示例中,断开代码是十六进制0xDF030xF03识别断开原因,当0xD指示时,当断开原因发生了(断开原因:类型)。

下述的断开原因不包括断开类型。因此,从断开原因您有,剥去最左边的十六进制数字并且比较与下面选项的剩余数字。从以上示例,请寻找在下面部分的0xF03

注意: 在本文中,主机调制解调器是在Cisco接入服务器的MICA调制解调器,而客户端调制解调器是远程设备调制解调器(例如,客户端PC调制解调器)。

断开类型 断开原因原因代码 说明
-- 0 断开未发生。您在稳定状态之前看到此代码,如果在呼叫期间,断开原因被查询在端口件加载之后或。
一般断开原因(中集集团0)
2 0x001 因为第一层在包含呼叫的物理间距去下来例如由于某种原因Cisco IOS突然终止呼叫-。
2 0x002 错误改正(EC)层终端。
2 0x003 Microcom网络协议5 (MNP5)解压任务接收在数据流的一个非法令牌。在数据模式(0x3003)期间,此断开原因发生。很可能有在调制解调器或de/compression或错误纠正的合作伙伴的实施的一个逻辑错误。(也有偶然性线路干扰或RAM存储器错误的可能性。)
2,4,6 0x004 V.42bis或V.44解压任务接收在数据流的一个非法令牌。在数据模式(0x4004)期间,此断开原因能发生。很可能有在调制解调器或de/compression或错误纠正的合作伙伴的实施的一个逻辑错误。(也有偶然性线路干扰或RAM存储器错误的可能性。)对于V.44,此代码由诊断链路信息域索引119 (作为调试的一个工具使用的八补充字节信息域)。
2 0x005 MICA软件错误。此断开原因的错误代码是0x4005。指示一个坏并行处理器状态变量的MICA软件错误出现。
6 0x006 ATH命令由本地调制解调器检测。此断开原因发生在数据模式期间(0xC006和0xE006)。ATH (挂断)命令由本地调制解调器(MICA)检测。例如,在从IOS的一拨出期间,在呼叫连接后, IOS DTE接口通过传送inband ath命令清除了呼叫。
3 0x007 AT dial命令中止。AT dial命令any key abort命令中止。例如,主机调制解调器发起呼叫。在连接建立期间,在稳定状态之前,按所有密钥将导致AT dial命令中止。
3 0x008 呼叫采取太长以至于不能完成连接。注意为此断开(请在拨号以后等待载波)超时的S7计时器。在呼叫建立(0x6008)期间,此断开原因发生。主机调制解调器采取太长以至于不能建立连接由于再培训。原因是:困难选择(协商) 1层标准的(例如,中止呼叫在返回与断开原因0x6102)前,或者1层和2层建立的组合采取太长的。例如,错误改正协商花费时间在再培训顶部或由于位错误介绍,当客户端调制解调器设法连接以不能持续)的激进的速率时(客户端调制解调器的接收方设法连接以速率。CSR的此种断开计数。此断开能也发生,如果应答调制解调器听不到从信道的音(例如,创建人不是调制解调器)。
2 0x009 DSP重置(命令,内部或者自发)。此断开原因的错误代码是0x4009。在主机调制解调器内的DSP由控制处理器(CP)或信号处理器(SP)重置。如果从CP的邮件消息到SP没有确认, CP将重置DSP。如果收到内部不一致错误, SP将重置。
4,6 0x00A 非法加强代码字的收据。指定STEPUP码字的收据,当将造成值C2 (当前码字长度)超出N1 (最大码字长度:经过协商的)和为仅V.44和V.42bis是有效。
4,6 0x00B 一个非法V.42bis代码字的收据。指定代码字的收据,在任何时间,等于对C1 (下空词典条目)并且为V.42bis是有效。(代码字= C1的收据是非法在V.42bis,但是法律在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非法加强字符的收据。这指示将造成值C5加强控制代码的收据(序数大小)超过八。这为仅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指定的值停止听到载波期限极大(在载波损失以后的挂断延迟)。这能含义通话路径是离开或客户端停止传送。如果2层协议(V.42和V.42bis)有效,是异常的发现这样断开。此断开原因在EC协商时有时发生(在数据模式前)。即1层顺利地协商(造成载波信号检测),并且断开出现,当尝试设立2层协议时(V.42和V.42bis)。在连接发生前,常见原因是中止呼叫的用户。偶然发生拨号,中止开始和客户端应用时间由于采取太长以至于不能连接(例如,多次重试在1层协商时)。CSR的此种故障计数。当客户端突然丢弃载波时,载波丢失的情况能也发生在正常数据模式期间。常见原因是非协商的或非法断开连接在客户端调制解调器部分(即客户端调制解调器丢弃载波信号)。这能发生,如果链路突然丢弃(即网络错误),客户端调制解调器的电源是被关闭的断开连接呼叫。这能也发生在不实现在一DTR丢弃的1层和2层清除协议的更加便宜的客户端调制解调器。对于很大数量的客户端调制解调器,这认为正常断开。当客户端调制解调器执行非法断开连接时,竞争状态存在0xA103、0xA100和0xDF06之间。如果在主机调制解调器内的DSP检测载波损失, 0xA100赢取和指示作为断开原因。如果DSP不检测载波损失并且再培训,直到点击寄存器S40限制,则0xA103赢取。如果网络检测呼叫被断开了并且发信号路由器断开连接,则0xDF06赢取。当主机调制解调器在数据模式时,此断开原因不计数CSR。
3 0x101 这发生,当信号处理器(SP)是在答复音(ABT)检测相位,当呼叫失败发生时。
3 0x102 在调制解调器系列期间的呼叫失败由于不兼容的调制或坏线路。在呼叫setup(0x6102)期间,此断开原因发生。这可能是预示的尝试协商一个不支持的调制例如传统罗克韦尔所有权modulation(K56Plus, V.FC,等等)。或许其他可能的原因是DSP疏忽训练由于严重线路损伤,脉冲噪声,中断的培训,不兼容的调制参数和适当地选择1层标准的无法。CSR的此种断开计数。
4,5 0x103 许多连续再训练或速度转变。再培训限制用寄存器S40指定。在呼叫建立和数据模式(0x6103、0x8103和0xA103)期间,此断开原因发生。在呼叫的进度期间,使呼叫无效的许多再培训发生,因为数据速率是很差至于是无用的。可能的情况是例如的地方客户端调制解调器不完成清除协议(telco在连接中间切断了呼叫),并且MICA尝试通过发出恢复呼叫再培训。一旦再培训限制达到(再培训限制可以被修改使用S40寄存器), MICA断开呼叫并且报告此断开原因。在一些情况(信道化T1/el)下此种断开可能认为正常稳定断开。二者择一,这可能是非法断开连接的结果由于MICA不能恢复的可能的线路错误。因此,因为呼叫已经建立,此种断开不计数往CSR。此断开原因在EC协商时也发生,当客户端调制解调器是非常激进的与初始连接速率时,并且不能维持呼叫(如观察用旧有USRobotics客户端调制解调器)。此种断开计数CSR。当客户端调制解调器执行非法断开连接时,竞争状态存在0xA103、0xA100和0xDF06之间。如果数字信号信号处理器(DSP)在主机调制解调器内检测载波损失, 0xA100赢取和指示作为断开原因。如果DSP不检测载波损失并且再培训,直到点击寄存器S40限制,则0xA103赢取。如果网络检测呼叫被断开了并且发信号路由器断开连接,则0xDF06赢取。当主机调制解调器在数据模式时,此断开原因不计数CSR。
3 0x104 检测应答信号Tone(ABT)的结尾问题。协商失败或过多的噪声在V.34培训期间。主机调制解调器回答并且派出V.8bis和调整的2100Hz答案应答音(ABTs)在连接顺序期间,与反相,但是遇到过多的噪声。寻找在路径的错误从呼叫调制解调器到在一或二个方向的应答调制解调器。相似的行为出现,当有在公共交换电话网(PSTN)的延迟超出一秒钟并且造成调制解调器无法培训回波取消器的拨号的。其他可能的原因是:
  • 实际发射功率级别不正确,并且音没有由远端然后处理。
  • 在V.34培训期间,有在相位III和IV的许多过多的噪声。
  • 有操作员错误。
  • 有网络干扰在V.34培训期间(某人拾起分机)。
CSR的此种断开计数。
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 接收与一个坏参数(PARAM1)的LR帧。已接收MNP Link Request (LR)帧有一坏或意外的PARAM1。关于参考V.42规格的PARAM1的更多信息。
3 0x203 接收一不兼容LR (链路请求)帧。在呼叫建立(0x6203)期间,此断开原因发生。已接收MNP LR帧与EC的主机调制解调器设置是不兼容的。
4,5 0x204 许多连续重传。在呼叫建立和数据模式(0x8204、0xA204和0x6204)期间,此断开原因发生。此断开原因可以由在线路的噪声造成。例如,主机调制解调器传达数据给客户端调制解调器,但是在线路的噪声造成数据由客户端不正确地(或不)接收。过多的噪声可能所以导致过多的重发。客户端调制解调器可能也断开,不用认识到此的MICA调制解调器。因此主机调制解调器连续重新传输,无需知道客户端调制解调器不再存在。有时,当呼叫在错误压缩(EC)协议连接(Link access procedure for modems (LAPM)或Microcom网络协议(MNP))MICA无法传输帧到客户端调制解调器。客户端调制解调器不能确认MICA的初始传输,然后不能回应到S19 (错误修正重发限制)投票(默认是12),因此MICA断开呼叫。当客户端失败减速传动时,一个原因可以是载波在充分地降低的传输路径。另一个原因可能是一问题用客户端的EC引擎(和在Winmodem系统将发生,如果Windows停止响应)。
6,7 0x205 休眠超时,发送的MNP链路断开。此断开原因发生在数据模式期间(0xC205和0xE205)。主机调制解调器发送客户端调制解调器指示LD的帧休眠超时出现。
4,5 0x206 EC协议错误。此断开原因发生在数据模式期间(0x8206和0xA206)。这是一般全捕捉协议错误。它表明LAPM或MNP EC协议错误发生。
3 0x210 没有EC回退协议联机。此断开原因在呼叫建立(0x6210)发生。错误改正协商不是成功的。因为没有错误修正回退协议联机,呼叫终止。S寄存器S25 (链路协议fallback)确定可用的回退协议。选项是异步帧、同步帧或者断开(挂起)。
3 0x211 从未已接收交换标识(XID)帧在协商时。在呼叫建立(0x6211)期间,此断开原因发生。这意味着主机调制解调器在错误改正协商时未曾接收XID帧。客户端调制解调器可能不支持在V.42内的LAPM。
3 0x212 已接收XID帧与本地设置是不兼容的。此断开原因在呼叫建立(0x6212)发生。已接收XID帧与主机调制解调器设置是不兼容的。例如,客户端调制解调器可能指示MNP5,而主机调制解调器指示仅V.42和V.42bis。
3,4,5 0x220 已接收断开(DISC)帧。这是正常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 未知PHS互联网接入标准控制帧标识符(CFI)。控制帧接收与其类的未知或未生效的ID。注意连续和用户帧未生效,并且没有已知通知帧。
3,4 0x233 PIAFS失败的通信协商。在初始同步以后,通信参数Req/Ack帧交换。任一参数是不可接受的,或者发起者检测NAK (否定应答)答复。

注意: 为了便于测试MICA能只运行作为客户端/发起者

3,4 0x234 失败的PIAFS ARQ协商。在再同步以后, ARQ请求(Req) /Acknowledgment (Ack)帧交换。任一参数是不可接受的,或者发起者检测Nak答复。

注意: 为了便于测试MICA能只运行作为客户端/发起者

3,4 0x235 PHS互联网接入标准控制检测的传输协议问题。发起者接收Ack/ID、中集集团和顺序没有匹配原始Req/Ntf的Nak/Rsp。

注意: 为了便于测试MICA能只运行作为客户端或发起者

3,4 0x236 此断开原因不再指示DataLinkRelease请求帧的收据。它当前指示断开,不用以前生成的断开原因。这意味着MICA断开一呼叫,但是发现原因未被张贴。
3,4 0x237 PHS互联网接入标准同步接收等待计时器(T001)超时。此计时器启动,当同步请求帧发送时,并且终止,当同步接收帧检测时。此错误只将出现,当MICA端口操作作为客户端或发起者,在测试期间,仅发生。默认值是15秒。
3,4 0x238 T002超时的PIAFS位置同步接受-传送计时器。此计时器开始,当同步接收帧发送时,铺沙它终止,当同步接收(冲突案件)或控制帧检测。此错误只将出现,当MICA端口操作作为服务器(应答模式),是正常操作模式。默认值是15秒。
3,4 0x239 T003超时的PHS互联网接入标准同步请求等待计时器。此计时器启动,当连续FCS错误检测时,并且终止,当有效同步请求帧检测时。此错误只将发生在MICA端口操作作为服务器(应答模式),是正常操作模式。默认值是15秒。
3,4 0x23A T101超时的PIAFS计时器:控制帧确认等待计时器。开始,当控制帧请求或通知发送时,终止,当帧被确认时。此错误只将出现,当MICA端口操作作为客户端或发起者,在测试(十秒)期间,仅发生。
3,4 0x23B PIAFS :已接收FBI (ACK顺序#)超出协调的范围或者已接收FBI=0用非空的数据帧。
3,4 0x23C PIAFS :已接收FFI (MSG顺序#)超出协调的范围或者FFI=0。
3,4 0x23D PIAFS :经过协商的数据窗口比RTF (往返时延)值是较少。此错误由端口件不再张贴,并且应该从未看到。
3,4 0x23E PIAFS :消息的数据长度字段太大。应该是0-73。
3,4 0x23F PIAFS内部错误:SREJ呼叫返回错误代码。
3,4 0x240 PIAFS一般协议错误。这是没有一相关的断开原因的错误的全捕捉。
3,4 0x241 PIAFS :失败的协议协商。协议(例如,数据传输协议修复的速度, DTP变速Type)不是可接受对两个站点。不可接受的协议是DTP变速Type3或者实时协议。
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)。
已接收Bad MNP或LAPM protocol命令从合作伙伴(类3)
4.5 0x3xx EC检测的坏指令编码。received unknown命令在最后两个位。MNP LD或LAP-M帧拒绝(FRMR)帧在答复发送。
LAPM合作伙伴指示MICA协议错误(中集集团4)
4,5 0x4xx LAP-M FRMR帧的客户端表示的EC情况。位映射原因在最后两个位。
4,5 0x401 LAPM :对等体报告坏命令。主机调制解调器接收从客户端调制解调器的一FRMR帧。已接收FRMR帧表明客户端调制解调器接收从包含一坏命令的主机调制解调器的一个错误修正帧。
4,5 0x403 LAPM :对等体报告数据域没有允许也不是不正确的长度(U帧)。主机调制解调器接收从客户端调制解调器的一FRMR帧。已接收FRMR帧表明客户端调制解调器接收从包含数据域没有允许或包含有一个不正确的长度的主机调制解调器的一个错误修正帧(U帧)一数据域。
4,5 0x404 LAPM :对等体报告数据域长度比N401 (在V.42指定的最大信息域长度)极大,但是有好帧校验Sequence(FCS)。NextPort调制解调器接收从客户端调制解调器的一FRMR帧。已接收FRMR帧表明客户端调制解调器接收从包含一数据域长度比八位位组最大极大可以输入信息字段的NextPort的一个错误修正帧(N401) I帧、SREJ帧、XID帧、UI帧或者测试帧。帧校验序列是好。
4,5 0x408 LAPM :对等体报告坏接收序号或N (R)。主机调制解调器接收从客户端调制解调器的一FRMR帧。已接收FRMR帧表明客户端调制解调器接收从包含一坏接收序号的主机调制解调器的一个错误修正帧。
MNP合作伙伴指示断开或MICA协议错误(中集集团5)
4,5 0x5xx MNP LD帧的客户端表示的EC情况。Reason字段在最后两个位
3 0x501 MNP :对等体从未已接收LR帧。主机调制解调器接收从客户端调制解调器的一LD帧。已接收LD帧表明客户端调制解调器未曾接收从主机调制解调器的一个链路请求。
3 0x502 MNP :对等体报告LR帧有坏参数#1。主机调制解调器接收从客户端调制解调器的一LD帧。已接收LD帧表明客户端调制解调器接收从包含一坏的主机调制解调器的链路请求帧(即意外的) PARAM1。关于参考V.42规格的PARAM1的更多信息。
3 0x503 MNP :对等体报告LR帧与其配置是不兼容的。主机调制解调器接收从客户端调制解调器的一LD帧。已接收LD帧表明客户端调制解调器接收从与客户端调制解调器是不兼容的主机调制解调器的LR帧, s配置。
4,5 0x504 MNP :对等体报告许多连续的EC重新传输。主机调制解调器接收从客户端调制解调器的一LD帧。已接收LD帧表明客户端调制解调器接收许多连续重传。
4,5 0x505 MNP :超时的对等体报告不活动计时器。主机调制解调器接收从客户端调制解调器的一LD帧。已接收LD帧表明客户端调制解调器?s主机(DTE) hasn ?t通过数据到在时期的客户端调制解调器。
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数据链路版本(PDLR)与原因xx (请参阅下面详细的值)。
3,4 0x61x PIAFS数据链路版本的(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 -在语音呼叫期间。…其他其他奇怪组未定义的类奇怪对一些客户端设备。
Host/IOS请求的断开(中集集团31)
6,7 0x1fxx 主机开始断开。值是0x1F00和Sessionstop命令value的一个总和。这是另一台主机终止原因。主机原因在低价位字节指示xx。
3,6,7 0x1f00 不是某个特定主机发起的断开。值是0x1F00和Sessionstop命令value的一个总和。这是全捕捉IOS开始断开原因。它使用所有非标准断开。例如,这能是决定调制解调器管理软件的结果终止呼叫。一个可能解释是更高级别的验证故障RADIUS、TACACS,或者发出一DTR丢弃的另一应用程序对主机调制解调器。当主机调制解调器在数据模式,此种断开不会计数往CSR。
3 0x1f01 呼叫号码忙碌。断开出现,因为主机表明呼叫号码忙碌。
3 0x1f02 呼叫号码没有应答。断开出现,因为主机表明呼叫号码没有应答。
3,6,7 0x1f03 丢弃的虚拟DTR。此状态从当前使用调制解调器的输入输出端口转向器反射。因为主机丢弃了虚拟DTR线路,断开出现。此一般的断开原因由Cisco IOS软件启动。可能的原因是空闲超时, PPP接收的LCP TERMREQ,认证失败, Telnet挂机,等等。要确定暂停的原因,请检查RADIUS断开原因从modem call-record terse命令或从验证、授权和统计(AAA)。
6,7 0x1f04 ATH (挂断)命令由本地主机检测。
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),然后客户端调制解调器将发送我们,在去挂机前,因而生成断开原因0x220的LAPM DISC (或MNP LD)而不是0x1f06。所以网络指示断开,在这种情况下,是很可能预示的一个不快乐的客户端调制解调器,由于某种原因决定的一个可能不再持续载波。
3 0x1f07 NAS终止SS7/COT操作。断开出现,因为NAS终止SS7/COT (连续性测试)操作。
3 0x1f08 SS7/COT操作由路由器终止由于T8/T24超时。
-- 0x1fff 未经请求的。终止。当收到一个未经请求的终止的消息时,主机发送此断开原因。

断开原因:类型

断开原因:当呼叫断开实际上发生,类型描述。他们可以分类到两种主要类型:在呼叫建立期间和在数据模式(稳定状态)期间。下表如断开原因所示指定最普通的断开原因类型和他们的值。

断开类型 断开类型(十六进制) 说明
0 0x0… (未使用)
1 0x2… (未使用)
2 0x4… 其他情况。
3 0x6… 在呼叫建立期间发生的情况。
4 0x8… 在数据模式。Rx (主机的线路)数据冲洗OK。在数据模式发生的断开情况。MICA尝试提供所有接收的数据到主机(IOS)。对于一些断开(例如, PIAFS),这是使用的唯一的数据模式类型;征兆没有由数据冲洗方向制成。
5 0xA… 在数据模式。不好Rx (主机的线路)的数据冲洗。在数据模式发生的断开情况。MICA尝试提供所有接收的数据到主机(IOS)。用老式MICA编码,此类型与以上的类型4是等同的。虽然IOS显示这样断开和不好,问题实际上未发生。
6 0xC… 在数据模式。TX (对线路的主机)数据冲洗OK。在数据模式发生的断开情况。MICA尝试传达缓冲的主机(IOS)数据给对方调制解调器。
7 0xE… 在数据模式。不好TX (对线路的主机)的数据冲洗。在数据模式发生的断开情况。MICA尝试传达缓冲的主机(IOS)数据给对方调制解调器。用老式MICA编码,此类型与以上的类型6是等同的。虽然IOS显示这样断开和不好,问题实际上未发生。


相关信息


Document ID: 5135