對VoIP呼叫進行故障排除和調試
目錄
簡介
本文檔介紹對VoIP網路進行故障排除和調試的基本技術和命令。
必要條件
需求
思科建議您瞭解以下主題：
-
VoIP配置
-
語音Qos
-
VoIP網路的設計和部署
採用元件
本文件所述內容不限於特定軟體和硬體版本。但是，顯示的輸出基於Cisco IOS®軟體版本12.3(8)。
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。
慣例
如需文件慣例的詳細資訊，請參閱思科技術提示慣例。
背景資訊
本文件說明進行 VoIP 網路疑難排解和偵錯時，所使用的基本技巧和指令。下列步驟概略說明了思科路由器中的語音通話流程與電話架構，以及逐步進行 VoIP 疑難排解的作法：
註：本文檔並未解釋Cisco VoIP網關和網守中使用的Cisco IOS架構的每個方面。相反，它旨在顯示可以使用哪些命令以及命令輸出中的哪些欄位可能最有價值。
注意：調試Cisco IOS需要佔用大量處理器。使用本文檔中列出的調試時請務必小心。如需詳細資訊，請參閱有關Debug指令的重要資訊。
需要在日誌中啟用時間戳的情況下運行調試。在啟用模式下使用命令service timestamps debug datetime msecservice timestampslog datetime msec啟用時間戳。時間戳有助於確定狀態更改之間的時間間隔。
網路中的呼叫流
在開始任何VoIP故障排除或調試之前，需要考慮的一個重要因素是：VoIP呼叫由三個呼叫段組成。這些呼叫段包括源普通舊式電話系統(POTS)、VoIP和目的地POTS。如下圖所示。故障排除和調試需要首先分別關注每個支路，然後關注整個VoIP呼叫。
路由器呼叫流
以下定義說明了路由器呼叫流程圖中顯示的主要元件的功能：
呼叫控制API(應用程式程式設計介面) — 三個客戶端使用呼叫控制API。這三種客戶端是CLI、簡單網路管理協定(SNMP)代理和會話應用程式。呼叫控制API（也稱為CCAPI）的主要功能包括：
-
確定呼叫段（例如，哪個撥號對等體？它來自何處？）。
-
決定哪個會話應用程式接聽呼叫（例如，由誰處理呼叫？）。
-
呼叫資料包處理程式。
-
將呼叫段會議在一起。
-
開始記錄呼叫統計資訊。
Session Application and Dial Plan Mapper — 會話應用程式使用Dial Plan Mapper將號碼對映到撥號對等體（本地POTS或遠端VoIP）。撥號方案對映器使用撥號對等體表查詢活動的撥號對等體。
電話和VoIP服務提供商介面(SPI) — 電話SPI與POTS（模擬：fxs、fxo、e&m數字：isdn、qsig、e&m等）撥號對等體通訊。VoIP SPI是VoIP對等體的特定介面。電話/DSP驅動程式向電話SPI提供服務，而VoIP SPI依賴於會話協定。
電話介面架構
此圖顯示了思科路由器電話構建塊的架構以及它們如何相互互動。
此清單介紹了主圖元件的功能和定義：
-
呼叫控制應用程式設計介面(CCAPI) — 用於建立、終止和橋接呼叫段的軟體實體。
-
語音電話服務供應商(VTSP) — 一個Cisco IOS流程，為來自呼叫控制API的請求提供服務，並將適當的請求提交給數位訊號處理器(DSP)或VPM。
-
語音處理器模組(VPM) - VPM負責橋接和協調電話連線埠訊號狀態機(SSM)、DSP資源管理器和VTSP之間的訊號處理過程。
-
DSP資源管理器 — DSPRM提供介面，VTSP可通過這些介面向DSP傳送和接收消息。
-
Packet Handler — 資料包處理程式在DSP和對等呼叫段之間轉發資料包。
-
Call Peer - Call Peer是相反的呼叫段。這可以是另一個電話語音連線(POTS)、VoFR、VoATM或VoIP連線。
驗證數位和類比訊號（POTS通話腿）
驗證數字和模擬信令的目標是：
-
確定收到正確的掛機和摘機模擬或數字信令。
-
確定在路由器和交換機（CO或PBX）上配置了正確的E&M、FXO和FXS信令。
-
驗證DSP是否處於數字收集模式。
以下各節中概述的命令可用於驗證信令。
show controllers T1 / E1（數字）
show controllers t1 [slot/port] — 首先使用此命令。它顯示路由器和交換機（CO或PBX）之間的數字T1連線是開啟還是關閉，以及它是否正常工作。此命令的輸出如下所示：
router# show controllers T1 1/0 T1 1/0 is up. Applique type is Channelized T1 Cablelength is short 133 No alarms detected. Framing is ESF, Line Code is B8ZS, Clock Source is Line Primary. Data in current interval (6 seconds elapsed): 0 Line Code Violations, 0 Path Code Violations 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs |
如果使用E1，請使用show controllers e1 命令。如需詳細資訊，請參閱：
show voice port
show voice portslot-number/port — 使用此命令可顯示連線埠狀態以及思科語音介面卡(VIC)的語音連線埠上設定的引數。與所有Cisco IOS命令一樣，預設設定不會顯示在show running-config中，但會在此命令中顯示。
以下是E&M語音埠的輸出示例：
router# show voice port 1/0:1 recEive and transMit Slot is 1, Sub-unit is 0, Port is 1 Type of VoicePort is E&M Operation State is DORMANT Administrative State is UP No Interface Down Failure Description is not set Noise Regeneration is enabled Non Linear Processing is enabled Music On Hold Threshold is Set to -38 dBm In Gain is Set to 0 dB Out Attenuation is Set to 0 dB Echo Cancellation is enabled Echo Cancel Coverage is set to 16 ms Connection Mode is normal Connection Number is not set Initial Time Out is set to 10 s Interdigit Time Out is set to 10 s Call-Disconnect Time Out is set to 60 s Region Tone is set for US Voice card specific Info Follows: Out Attenuation is Set to 0 dB Echo Cancellation is enabled Echo Cancel Coverage is set to 16 ms Connection Mode is normal (could be trunk or plar) Connection Number is not set Initial Time Out is set to 10 s Interdigit Time Out is set to 10 s Call-Disconnect Time Out is set to 60 s Region Tone is set for US Voice card specific Info Follows: Signal Type is wink-start Operation Type is 2-wire E&M Type is 1 Dial Type is dtmf In Seizure is inactive Out Seizure is inactive Digit Duration Timing is set to 100 ms InterDigit Duration Timing is set to 100 ms Pulse Rate Timing is set to 10 pulses/second InterDigit Pulse Duration Timing is set to 500 ms Clear Wait Duration Timing is set to 400 ms Wink Wait Duration Timing is set to 200 ms Wink Duration Timing is set to 200 ms Delay Start Timing is set to 300 ms Delay Duration Timing is set to 2000 ms Dial Pulse Min. Delay is set to 140 ms |
debug vpm（語音處理器模組）
以下命令用於調試VPM電話介面：
-
debug vpm signal — 此命令用於收集信令事件的調試資訊，可用於解決向PBX傳送信令的問題。
-
debug vpm spi — 此命令跟蹤語音埠模組服務提供商介面(SPI)與呼叫控制API的介面方式。此debug命令會顯示有關如何處理每個網路指示和應用程式要求的資訊。
-
debug vpm dsp — 此命令顯示從VPM上的DSP到路由器的消息，如果您懷疑VPM無法正常工作，此命令非常有用。這是一種檢查VPM是否響應掛機指示和評估來自介面的信令消息的時機的簡單方法。
-
debug vpm all — 此EXEC命令啟用所有debug vpm命令：debug vpm spi、debug vpm signal和debug vpm dsp。
-
debug vpm port — 使用此命令將調試輸出限製為特定埠。例如，以下輸出僅為連線埠1/0/0顯示debug vpm dspmessages:
debug vpm dsp debug vpm port 1/0/0
debug vpm signalCommand的輸出示例
maui-voip-austin#debug vpm signal !--- FXS port 1/0/0 goes from the "on-hook" to "off-hook" !--- state. htsp_process_event: [1/0/0, 1.2 , 36] fxsls_onhook_offhook htsp_setup_ind *Mar 10 16:08:55.958: htsp_process_event: [1/0/0, 1.3 , 8] !--- Sends ringing alert to the called phone. *Mar 10 16:09:02.410: htsp_process_event: [1/0/0, 1.3 , 10] htsp_alert_notify *Mar 10 16:09:03.378: htsp_process_event: [1/0/0, 1.3 , 11] !--- End of phone call, port goes "on-hook". *Mar 10 16:09:11.966: htsp_process_event: [1/0/0, 1.3 , 6] *Mar 10 16:09:17.218: htsp_process_event: [1/0/0, 1.3 , 28] fxsls_offhook_onhook *Mar 10 16:09:17.370: htsp_process_event: [1/0/0, 1.3 , 41] fxsls_offhook_timer *Mar 10 16:09:17.382: htsp_process_event: [1/0/0, 1.2 , 7] fxsls_onhook_release |
如果掛機和掛機沒有正確發出訊號，請檢查以下專案：
-
驗證佈線是否正確。
-
驗證路由器和交換機（CO或PBX）是否都已正確接地。
-
驗證連線的兩端是否具有等效的信令配置。不匹配的配置可能會導致不完整或單向信令。
有關E&M故障排除的詳細資訊，請參閱瞭解和故障排除模擬E&M介面型別和佈線安排。
debug vpm spiCommand的輸出示例
maui-voip-austin#debug vpm spi Voice Port Module Session debugging is enabled !--- The DSP is put into digit collection mode. *Mar 10 16:48:55.710: dsp_digit_collect_on: [1/0/0] packet_len=20 channel_id=128 packet_id=35 min_inter_delay=290 max_inter_delay=3200 mim_make_time=18 max_make _time=75 min_brake_time=18 max_brake_time=75 |
驗證接收和傳送的數字（POTS呼叫段）
驗證掛機和摘機信令並且工作正常後，驗證語音埠（數字或模擬）上收到或傳送了正確的數字是否正確。如果傳送或接收的數字不完整或不正確，則撥號對等體不匹配或交換機（CO或PBX）無法振鈴正確的工作站。可用於驗證接收/傳送的數字的一些命令包括：
-
show dialplan number — 此命令用於顯示當撥打特定電話號碼時到達哪個撥號對等體。
-
debug vtsp session — 此命令顯示有關如何處理每個網路指示和應用請求、信令指示以及DSP控制消息的資訊。
-
debug vtsp dsp — 早於Cisco IOS軟體版本12.3，此命令顯示語音埠接收的數字。但是在Cisco IOS軟體版本12.3和更新版本中，debug命令的輸出不再顯示數字。debug hpi detail 和debug pinotification 的組合可用於檢視傳入的數字。
-
debug vtsp all — 此命令啟用以下debug voice telephony service provider(VTSP)命令：debug vtsp session、debug vtsp error 、debug vtsp dsp。
show dialplan number
show dialplan number <digit_string> — 此命令顯示由數字字串匹配的撥號對等體。如果可以匹配多個撥號對等體，則這些撥號對等體都會按匹配順序顯示。
註：對於長度可變的撥號對等體，您需要使用電話號碼結尾的#號，以便匹配以T結尾的目標模式。
此命令的輸出如下所示：
maui-voip-austin#show dialplan number 5000
Dial string terminator: #
Macro Exp.: 5000
VoiceOverIpPeer2
information type = voice,
tag = 2, destination-pattern = `5000',
answer-address = `', preference=0,
group = 2, Admin state is up, Operation
state is up,
incoming called-number = `',
connections/maximum = 0/unlimited,
application associated:
type = voip, session-target =
`ipv4:192.168.10.2',
technology prefix:
ip precedence = 5, UDP checksum =
disabled, session-protocol = cisco,
req-qos = best-effort,
acc-qos = best-effort,
dtmf-relay = cisco-rtp,
fax-rate = voice,
payload size = 20 bytes
codec = g729r8,
payload size = 20 bytes,
Expect factor = 10, Icpif = 30,
signaling-type = cas,
VAD = enabled, Poor QOV Trap = disabled,
Connect Time = 25630, Charged Units = 0,
Successful Calls = 25, Failed Calls = 0,
Accepted Calls = 25, Refused Calls = 0,
Last Disconnect Cause is "10 ",
Last Disconnect Text is "normal call
clearing.",
Last Setup Time = 84427934.
Matched: 5000 Digits: 4
Target: ipv4:192.168.10.2
|
debug vtsp session
debug vtsp session 命令顯示有關路由器如何根據來自信令堆疊的信令指示和來自應用程式的請求與DSP進行互動的資訊。此debug命令顯示有關如何處理每個網路指示和應用請求的資訊、信令指示以及DSP控制消息。
maui-voip-austin#debug vtsp session Voice telephony call control session debugging is on !--- Output is suppressed. |
如果確定數字沒有正確傳送或接收，則可能有必要使用數字捕獲器（測試工具）或T1測試儀來驗證數字是否以正確的頻率和定時間隔傳送。如果為交換器（CO或PBX）錯誤傳送這些值，則可能需要調整路由器或交換器（CO或PBX）上的某些值，以便它們匹配和互操作。這些通常是數字持續時間和數字間持續時間的值。檢查數字是否正確傳送的另一個專案是交換機（CO或PBX）中可新增或刪除數字的任何號碼轉換表。
驗證端到端VoIP訊號傳送(VOIP Call-Leg)
確認語音埠信令工作正常且收到正確數字後，轉到VoIP呼叫控制故障排除和調試。以下因素解釋了為什麼呼叫控制調試會成為一項複雜的工作：
-
Cisco VoIP網關使用H.323信令來完成呼叫。H.323由呼叫協商和呼叫建立三層組成：H.225、H.245和H.323。這些協定結合使用TCP和UDP來建立和建立呼叫。
-
端到端VoIP調試顯示許多Cisco IOS狀態機。任何狀態機出現問題都可能導致呼叫失敗。
-
端到端VoIP調試可以非常詳細並建立大量調試輸出。
debug voip ccapi inout
調試端到端VoIP呼叫的主要命令是debug voip ccapi inout。呼叫調試的輸出顯示在此輸出中。
!--- Action: A VoIP call is originated through the |
如果呼叫失敗並且原因似乎出現在呼叫設定的VoIP部分，則可能需要檢視呼叫設定的H.225或H.245 TCP部分，而不僅僅是H.323設定的UDP部分。可用於調試H.225或H.245呼叫設定的命令包括：
-
debug ip tcp transactions 和debug ip tcp packet — 這些命令檢查H.225和H.245協商的TCP部分。它們返回IP地址、TCP埠和TCP連線的狀態。
-
debug cch323 h225 — 此命令檢查呼叫協商的H.225部分，並根據處理的事件，跟蹤H.225狀態機的狀態轉換。將此視為三部分H.323呼叫設定的第1層部分。
-
debug cch323 h245 — 此命令檢查呼叫協商的H.245部分，並根據處理的事件，跟蹤H.245狀態機的狀態轉換。將此視為三部分H.323呼叫設定的第2層部分。
瞭解VoIP服務品質(QoS)問題
當VoIP呼叫正確建立時，下一步是驗證語音品質是否良好。雖然本檔案未涉及QoS疑難排解，但需要考慮以下准則才能達到良好的語音品質：
-
瞭解VoIP呼叫在每個編解碼器上消耗多少頻寬。這包括第2層和IP/UDP/RTP報頭。如需詳細資訊，請參閱修改語音通話的頻寬消耗計算。
-
瞭解呼叫經過的IP網路的特性。例如，幀中繼網路在CIR時的頻寬與CIR以上（或突發量）的頻寬相差很大，在幀中繼網雲中，資料包可能會被丟棄或排隊。確保儘可能控制和消除延遲和抖動。單向傳輸延遲不得超過150毫秒（根據G.114建議）。
-
使用排隊技術來識別和優先處理VoIP流量。
-
透過低速連結傳輸VoIP時，請使用第2層封包分段技術，例如點對點連結上支援連結分段和交錯(LFI)的MLPPP，或訊框中繼連結上的FRF.12。由於可以將VoIP資料包交織到鏈路上，因此對較大資料包進行分段可以減少傳輸VoIP流量的抖動和延遲。
-
嘗試使用不同的編解碼器，嘗試啟用和禁用VAD的呼叫，將問題縮小到DSP（而不是IP網路）。
使用VoIP時，在排除QoS問題時需要注意的主要事項是丟包以及可能導致延遲和抖動的網路瓶頸。
尋找：
-
interface drops
-
緩衝區丟棄
-
介面擁塞
-
鏈路擁塞
需要檢查VoIP呼叫路徑中的每個介面。此外，還可以消除丟棄和擁塞。此外，往返延遲需要儘可能減少。VoIP端點之間的ping會指示連結的來回延遲。儘可能的往返延遲不能超過300毫秒。如果延遲必須超過此值，則需要採取措施確保此延遲為恆定，以便不引入抖動或可變延遲。
還必須進行驗證，以確保Cisco IOS排隊機制將VoIP資料包放在正確的隊列中。Cisco IOS命令(例如show queue interface 或show priority )有助於驗證佇列。
VoIP的原因代碼和調試值的詳細資訊
當您讀取debug和debug中的關聯值時，請使用這些表。
Q.931呼叫斷開原因（debug voip ccapi inout的cause_codes）
| 呼叫斷開原因值（十六進位制） | 含義和數字（以十進位制表示） |
|---|---|
| CC_CAUSE_UANUM = 0x1 | 未分配的號碼。(1) |
| CC_CAUSE_NO_ROUTE = 0x3 | 沒有通往目的地的路由。(3) |
| CC_CAUSE_NORM = 0x10 | 正常呼叫清除。(16) |
| CC_CAUSE_BUSY = 0x11 | 使用者忙。(17) |
| CC_CAUSE_NORS = 0x12 | 無使用者響應。(18) |
| CC_CAUSE_NOAN = 0x13 | 無使用者應答。(19) |
| CC_CAUSE_REJECT = 0x15 | 呼叫被拒絕。(21) |
| CC_CAUSE_INVALID_NUMBER = 0x1C | 無效號碼。(28) |
| CC_CAUSE_UNSP = 0x1F | 正常，未指定。(31) |
| CC_CAUSE_NO_CIRCUIT = 0x22 | 沒有電路。(34) |
| CC_CAUSE_NO_REQ_CIRCUIT = 0x2C | 沒有請求的電路。(44) |
| CC_CAUSE_NO_RESOURCE = 0x2F | 無資源。(47)1 |
| CC_CAUSE_NOSV = 0x3F | 服務或選項不可用，或未指定。(63) |
1此問題可能是由於H323設定中的編解碼器不匹配引起的，因此第一個故障排除步驟是對VoIP撥號對等體進行硬編碼以使用正確的編解碼器。
編解碼器協商值（來自debug voip ccapi inout）
有關編解碼器的詳細資訊，請參閱瞭解編解碼器：複雜性、硬體支援、MOS和協商。
| 交涉值 | 含義 |
|---|---|
| codec=0x00000001 | G711 ULAW 64K PCM |
| codec=0x00000002 | G711 ALAW 64K PCM |
| codec=0x00000004 | G729 |
| codec=0x00000004 | G729IETF |
| codec=0x00000008 | G729a |
| codec=0x00000010 | G726r16 |
| codec=0x00000020 | G726r24 |
| codec=0x00000040 | G726r32 |
| codec=0x00000080 | G728 |
| codec=0x00000100 | G723r63 |
| codec=0x00000200 | G723r53 |
| codec=0x00000400 | GSMFR |
| codec=0x00000800 | G729b |
| codec=0x00001000 | G729ab |
| codec=0x00002000 | G723ar63 |
| codec=0x00004000 | G723ar53 |
| codec=0x00008000 | CLEAR_CHANNEL |
音調型別
| 音調型別 | 含義 |
|---|---|
| CC_TONE_RINGBACK 0x1 | 鈴聲 |
| CC_TONE_FAX 0x2 | 傳真音 |
| CC_TONE_BUSY 0x4 | 忙音 |
| CC_TONE_DIALTONE 0x8 | 撥號音 |
| CC_TONE_OOS 0x10 | 停止服務音 |
| CC_TONE_ADDR_ACK 0x20 | 地址確認音 |
| CC_TONE_DISCONNECT 0x40 | 斷開連線音 |
| CC_TONE_OFF_HOOK_NOTICE 0x80 | 表示電話處於摘機狀態的音 |
| CC_TONE_OFF_HOOK_ALERT 0x100 | CC_TONE_OFF_HOOK_NOTICE的更緊急版本 |
| CC_TONE_CUSTOM 0x200 | 自定義音調 — 在指定自定義音調時使用 |
| CC_TONE_NULL 0x0 | 空音 |
FAX-Rate和VAD功能值
| 值 | 含義 |
|---|---|
| CC_CAP_FAX_NONE 0x1 | 傳真禁用或不可用 |
| CC_CAP_FAX_VOICE 0x2 | 語音呼叫 |
| CC_CAP_FAX_144 0x4 | 一萬四千四百波特 |
| CC_CAP_FAX_96 0x8 | 9,600波特 |
| CC_CAP_FAX_72 0x10 | 7,200波特 |
| CC_CAP_FAX_48 0x20 | 4,800波特 |
| CC_CAP_FAX_24 0x40 | 2,400波特 |
| CC_CAP_VAD_OFF 0x1 | VAD已禁用 |
| CC_CAP_VAD_ON 0x2 | 已啟用VAD |
相關資訊
修訂記錄
| 修訂 | 發佈日期 | 意見 |
|---|---|---|
2.0 |
20-Apr-2023 |
更新格式。已更正CCW警報。重新認證。 |
1.0 |
11-Dec-2001 |
初始版本 |
意見