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
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您在即時網路中工作，請確保在使用任何命令之前瞭解其潛在影響。
慣例
如需文件慣例的詳細資訊，請參閱思科技術提示慣例。
確定數據機狀態
使用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)中。 在每次呼叫終止期間，NAS會將MCR傳送到系統日誌伺服器。數據機呼叫記錄在Cisco IOS軟體版本11.3AA和12.0T中引入，並使用modem call-record命令啟用（在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數據機斷開原因表。
*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接收所有操作已關閉的驗證時，從終止狀態進入空閒狀態。 |
| CALL_SETUP(#5) | 在該狀態下，數據機訊號處理器準備接收和產生T1、多頻(MF)、雙音多頻(DTMF)、R1、R2和呼叫過程訊號。數據機一直處於CALL_SETUP狀態，直到從主機收到LINK_TERMINATE、SOFTWARE_RESET或INITIATE_LINK消息。 |
| 連線(#10) | 只有在收到要啟動的主機命令後，才從CALL_SETUP(#5)狀態輸入CONNECT狀態。在應答模式中，數據機會話已啟動活動，但尚未開始產生應答音。在Originate模式下，數據機會話已啟動活動，但尚未檢測到回聲音。 |
| 鏈路(#15) | 只有在檢測到回應要求音（發起）或回應要求音（應答）發起時，才會從CONNECT狀態進入LINK狀態。 在應答模式下，數據機會話向線路傳送回聲音。在Originate模式下，數據機會話檢測到所需的最小（可配置的）回聲音。這表示有遠端同儕節點。 |
| QC(#16) | 如果啟用QC，則從LINK或V.8 bis Exchange狀態輸入快速連線(QC)，並在收到QCA序列（發起模式）或傳送QCA序列（應答模式）時輸入。 |
| 培訓(#20) | 在此狀態下，數據機會話協商鏈路期間使用的物理調制標準（如配置）。TRAINUP狀態僅在以下情況下從LINK狀態輸入：
|
| EC_NEGOTIATING(#25) | 在此狀態下，數據機會話協商要在鏈路期間使用的糾錯和資料壓縮協定。當設定與兩個資料機一致時（兩個資料機功能和組態的交集），就會達到成功的交涉。如果交叉點為空，數據機將斷開連線或啟動非錯誤連線的會話。成功完成物理調制同步後，從TRAINUP狀態進入EC_NEGOTIATING狀態。 |
| STEADY_STATE(#30) | 在此狀態下，數據機會話能夠在鏈路上傳遞資料。從EC_NEGOTIATING狀態進入STEADY_STATE狀態：
|
| 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狀態是從任何狀態輸入的：
|
| ON HOLD(#55) | 數據機會話處於保持狀態，並且鏈路上沒有資料傳遞。在收到資料機插撥(MoH)請求消息(MHReq)時，會從穩態進入On Hold狀態。 如果數據機保持啟用(註冊S62)，數據機應傳送保持數據機確認(MHack)序列以授予請求，並在檢測到靜默或RT時傳送應答音(ANSam)。如果檢測到On Hold狀態下呼叫選單(CM)訊號(V.8)或Quick Connect Acknowledge-QCA(QC — 註冊S63)序列，數據機應退出On Hold狀態並分別按照V.8或QC(註冊S63)建議響應啟動序列。如果在定義的保持等待時間值之後未檢測到任何啟動序列，數據機將退出保持狀態並斷開連線。如果數據機處於保持狀態被禁用，數據機應傳送MHnack。如果在傳輸MHnack後檢測到MHcda，數據機應斷開連線。如果在傳輸MHnack後檢測到MHfrr，數據機應傳送迴音調並準備從遠端數據機檢測CM(V.8)或QCA(QC — 註冊S63)序列。有關保持數據機功能的詳細資訊，請參閱ITU-T V.92規範 。 註：MICA狀態#55前為VOICE狀態，現在已從portware 2.9.1.0及更高版本中刪除。 |
| V.8bis EXCHANGE(#71) | 僅當檢測到CRe（發起模式）或CRe（應答模式）時，才會從CONNECT狀態進入此狀態。 應答模式：數據機會話正在向線路傳送能力請求自動應答(CRe)。Originate Mode:數據機會話檢測到功能請求自動應答(CRe)。 這表示有遠端同儕節點。 |
| RANGING(#72) | 開始往返延遲估計(RTDEd)時，從LINK或QC(註冊器S63)狀態輸入RANGING。 此狀態僅適用於標準V.32及更高版本。 |
| RANGING SHORT(#73) | 在啟動往返延遲估計 — 數字數據機(RTDEd)時，從QC(註冊器S63)輸入RANGING SHORT |
| 高畫質#74列 | HD訓練（半雙工訓練）在介面卡過濾器訓練開始時從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 | 尚未斷開連線。如果Portware載入後立即或在呼叫過程中，在穩定狀態之前查詢斷開原因，您會看到此代碼。 |
| 一般斷開原因（類0） | ||
| 2 | 0x001 | Cisco IOS由於某種原因突然終止了呼叫 — 例如，因為第1層在包含該呼叫的物理跨度上關閉。 |
| 2 | 0x002 | 糾錯(EC)層終止。 |
| 2 | 0x003 | Microcom網路協定5(MNP5)解壓縮任務在資料流中收到非法令牌。此斷開原因在資料模式(0x3003)期間發生。 數據機或合作夥伴執行解壓/壓縮或糾錯時可能存在邏輯錯誤。（也可能發生偶然的線路命中或RAM記憶體錯誤。） |
| 2,4,6 | 0x004 | V.42bis或V.44解壓縮任務在資料流中收到非法令牌。此斷開原因可能會在資料模式(0x4004)期間發生。 數據機或合作夥伴執行解壓/壓縮或糾錯時可能存在邏輯錯誤。（也可能發生偶然的線路命中或RAM記憶體錯誤。） 對於V.44，此代碼由診斷連結資訊欄位索引119（八位元組資訊欄位用作調試工具）進行補充。 |
| 2 | 0x005 | MICA軟體錯誤。此斷開原因的錯誤代碼為0x4005。出現MICA軟體錯誤，表示協處理器狀態變數錯誤。 |
| 6 | 0x006 | 本地數據機檢測到ATH命令。此斷開原因在資料模式（0xC006和0xE006）期間發生。 本地數據機(MICA)檢測到ATH（掛機）命令。 例如，在從IOS撥出期間，在連線呼叫後，IOS DTE介面通過傳輸帶內ATH命令來清除該呼叫。 |
| 3 | 0x007 | AT dial命令已中止。AT dial命令已被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中指定的值（載波丟失後的掛機延遲）的期間內停止聽到載波。 這可能表示通話路徑已離開或客戶端停止傳輸。如果第2層協定（V.42和/或V.42bis）生效，則出現這種斷開連線將異常。此斷開原因有時發生在EC協商期間（在資料模式之前）。 即，已成功協商第I層（導致載波訊號檢測），並且在嘗試建立第II層協定（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等）。 其他可能的原因包括DSP由於嚴重的線路損傷、脈衝雜訊、中斷訓練、不相容的調制引數以及無法正確選擇第I層標準而無法進行訓練。此型別的斷開計數針對CSR。 |
| 4,5 | 0x103 | 太多的連續再培訓或換班。通過暫存器S40指定了重新訓練限制。在呼叫建立和資料模式（0x6103、0x8103和0xA103）期間，會出現此斷開原因。 在呼叫過程中，發生了太多的重新訓練，導致呼叫無效，因為資料速率太差以至於無用。可能的情況是客戶端數據機無法完成清除協定（例如，電信公司中斷了連線中的呼叫），並且MICA嘗試通過發出重新訓練來恢復呼叫。一旦達到重新訓練限制(使用S40暫存器可更改重新訓練限制),MICA將丟棄呼叫並報告此斷開原因。在某些情況下（通道化T1/E1），這種型別的斷開可視為正常的穩態斷開。或者，這可能只是由於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 | 收到包含錯誤引數(PARAM1)的LR幀。 收到的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停止響應，在Winmodem系統上會發生這種情況）。 |
| 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 | 已收到斷開連線（磁碟）幀。這是正常的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通訊協商失敗。在初始同步之後，交換通訊引數請求/確認幀。引數不可接受，或者發起方檢測到NAK（否定確認）響應。 注意：MICA只能作為客戶端/啟動程式運行以進行測試 |
| 3,4 | 0x234 | PIAFS ARQ協商失敗。在重新同步之後，交換ARQ請求（請求）/確認(Ack)幀。引數不可接受，或者發起方檢測到不正確的響應。 注意：MICA只能作為客戶端/啟動程式運行以進行測試 |
| 3,4 | 0x235 | 檢測到PIAFS控制傳輸協定問題。發起方收到的Ack/Nak/Rsp的ID、類和序列與原始請求/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埠作為客戶端或啟動器運行時，才會發生此錯誤，這僅在測試期間（十秒）發生。 |
| 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內部錯誤：事件處理程式中存在未知事件。switch語句進入預設情況。 |
| 3,4 | 0x244 | 在PIAFS 2.1 speedshift期間發生訊號處理器(SP)響應超時。Mica的CP在200毫秒內沒有看到速度變化響應。 |
| 3,4 | 0x245 | Mica的CP在CP/SP共用控制結構中看到不一致的控制資訊。具體地，資料緩衝器具有在資料緩衝器邊界(0-63)之外的頭或尾偏移。 |
| 從合作夥伴處收到錯誤的MNP或LAPM協定命令（3類） | ||
| 4.5 | 0x3xx | EC檢測到錯誤的命令代碼。收到的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中指定的最大資訊欄位長度），但具有良好幀校驗序列(FCS)。 NextPort數據機從客戶端數據機接收到FRMR幀。所接收的FRMR幀指示客戶端數據機從NextPort接收到糾錯幀，該糾錯幀包含的資料欄位長度大於I幀的資訊欄位(N401)中可攜帶的最大八位數、SREJ幀、XID幀、UI幀或TEST幀。幀校驗序列良好。 |
| 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收到帶有原因xx的PIAFS DataLinkRelease(PDLR)（請參閱下面的詳細值）。 |
| 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掛斷等。要確定掛斷的原因，請通過modem call-record terse命令或身份驗證、授權和記帳(AAA)檢查Radius斷開原因。 |
| 6,7 | 0x1f04 | 本地主機檢測到ATH（掛機）命令。 |
| 3 | 0x1f05 | 無法訪問電信網路。已斷開連線，因為主機無法訪問網路(ISDN)。 |
| 3,4,5 , | 0x1f06 | 網路指示斷開連線。這可以在資料模式之前或期間發生。0x1f06斷開意味著IOS從電路網路收到一個電路掛起訊號（即Q.931斷開或CAS掛機訊號），然後當IOS指示MICA掛機時，IOS將此訊號傳送給MICA。如果MICA達到資料模式且未交涉EC通訊協定（LAPM或MNP4），則可能是正常結束通話狀態。當Windows 95或98 Dial Up Networking(DUN)使用者在培訓期間和呼叫達到穩定狀態之前按一下「取消」時，也會產生此原因。此外，如果客戶端突然拔下電話線/關閉數據機，則此斷開原因將被視為正常。但是，如果連線已協商EC（LAPM或MNP4），因此在資料模式下，則此斷開原因可能由髒斷開連線（即不是正常呼叫終止的斷開連線）生成。 這是因為如果使用者端DTE（在資料模式下）以有序的方式(使用DTR drop或+++/ATH)斷開呼叫，則使用者端資料機會在掛機之前給我們傳送一個LAPM磁碟（或MNP LD），從而產生斷開原因0x220而不是0x1f06。因此網路指示的斷開可能表示使用者端資料機不正常，而這個使用者端資料機決定它由於某種原因不能再維持電信公司。 |
| 3 | 0x1f07 | NAS終止了SS7/COT操作。由於NAS已終止SS7/COT（連續性測試）操作，因此出現斷開連線。 |
| 3 | 0x1f08 | 由於T8/T24超時，路由器終止了SS7/COT操作。 |
| - | 0x1fff | 未經請求的。正在終止。主機收到未經請求的終止消息時傳送此斷開連線原因。 |
斷開連線原因：型別
斷開連線原因：型別描述實際發生呼叫斷開連線的時間。它們可以分為兩種主要型別：在呼叫建立期間和資料模式（穩態）期間。 下表指定了斷開連線原因中所示的最常見斷開連線原因型別及其值。
| 斷開型別 | 斷開型別（十六進位制） | 說明 |
|---|---|---|
| 0 | 0x0... | （未使用） |
| 1 | 0x2... | （未使用） |
| 2 | 0x4... | 其他情況。 |
| 3 | 0x6... | 呼叫建立過程中發生的情況。 |
| 4 | 0x8... | 在資料模式下。Rx（線路到主機）資料刷新正常。在資料模式下發生斷開連線情況。MICA嘗試將任何接收的資料傳送到主機(IOS)。 對於某些斷開連線（例如PIAFS），這是唯一使用的資料模式型別；沒有資料刷新方向的指示。 |
| 5 | 0xA... | 在資料模式下。Rx（線路到主機）資料刷新不正常。在資料模式下發生斷開連線情況。MICA嘗試將任何接收的資料傳送到主機(IOS)。 在舊版MICA代碼中，此型別等效於上述型別4。儘管IOS將此類斷開顯示為「not OK（不正常）」 ，但實際上未出現問題。 |
| 6 | 0xC... | 在資料模式下。TX（主機到線路）資料刷新正常。在資料模式下發生斷開連線情況。MICA嘗試將緩衝主機(IOS)資料傳輸至夥伴資料機。 |
| 7 | 0xE... | 在資料模式下。TX（主機到線路）資料刷新不正常。在資料模式下發生斷開連線情況。MICA嘗試將緩衝主機(IOS)資料傳輸至夥伴資料機。在舊版MICA代碼中，此型別等效於上述型別6。儘管IOS將此類斷開顯示為「not OK（不正常）」 ，但實際上未出現問題。 |
意見