簡介
本文說明如何在IP語音(VoIP)環境中排除與網路相關的音訊問題。
需求
思科建議您瞭解以下主題:
- Qos
- VoIP網路
- SPAN(交換器連線埠分析器)
- Wireshark
採用元件
本文中的資訊係根據以下軟體和硬體版本:
- Catalyst 9200
- Catalyst 9300
- Catalyst 9400
- Catalyst 9500
- Catalyst 9600
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除(預設)的組態來啟動。如果您的網路運作中,請確保您瞭解任何指令可能造成的影響。
背景資訊
在VoIP基礎架構中,音訊品質可能受到網路相關問題的影響,這些問題包括:
- 語音或斷斷續續的音訊存在斷斷續續的間隙。
- 單向音訊。
- 不是隔離給單個使用者,而是隔離給具有共同特徵(例如共用同一個VLAN或共用同一接入交換機)的一組使用者。
為了排除與網路相關的問題,語音資料包的源到目的地之間必須有一個清晰的拓撲。問題的診斷可以從網路中交換或路由語音資料包的任何點開始,但建議從接入層開始排除故障並轉到路由層。
網路圖表
![Network Diagram](/c/dam/en/us/support/docs/switches/catalyst-9300-series-switches/220655-troubleshoot-network-related-audio-issue-00.png)
在路徑中選擇一個捕獲點。它可以是A(最接近一個IP電話)、B(路由之前)、C(最接近目的地)。
SPAN擷取通常是在兩個方向(TX和RX)擷取,以識別對話的兩端,並從擷取各自的音訊,以及其他變數(例如抖動、或封包遺失)以進行進一步分析。
確定擷取點後,在交換器上設定SPAN組態。
Switch(config)#monitor session 1 source interface Gig1/0/1 both
Switch(config)#monitor session 1 destination interface Gig1/0/6 encapsulation replicate
Switch#show monitor session all
Session 1
---------
Type : Local Session
Source Ports :
Both : Gi1/0/1
Destination Ports : Gi1/0/6
Encapsulation : Replicate
Ingress : Disabled
發起測試呼叫,以捕獲來自使用Wireshark的PC/筆記型電腦中選定捕獲點的音訊流。
捕獲分析
1.開啟使用Wireshark捕獲的資料包並導航到Statistics > Conversations。根據相關裝置的IP地址(IP電話源和目標)查詢音訊對話。
![RTP Conversations](/c/dam/en/us/support/docs/switches/catalyst-9300-series-switches/220655-troubleshoot-network-related-audio-issue-01.png)
2.通常,音訊流由UDP協定承載,並且大多數時候未以適當的格式進行解碼,Wireshark無法提取嵌入其中的音訊。然後,下一步是將UDP流解碼成音訊格式,預設情況下使用RTP。按一下右鍵流的任何資料包,然後按一下Decode as。
![RTP Decode](/c/dam/en/us/support/docs/switches/catalyst-9300-series-switches/220655-troubleshoot-network-related-audio-issue-02.png)
3.查詢Current列並選擇RTP。按一下「OK」(確定)。
![RTP Decode 2](/c/dam/en/us/support/docs/switches/catalyst-9300-series-switches/220655-troubleshoot-network-related-audio-issue-03.png)
Wireshark將整個UDP流解碼為RTP,現在我們可以分析內容。
![RTP Stream](/c/dam/en/us/support/docs/switches/catalyst-9300-series-switches/220655-troubleshoot-network-related-audio-issue-04.png)
注意:RTP Player能夠播放已安裝外掛支援的任何編解碼器。RTP Player支援的編解碼器取決於您正在使用的Wireshark版本。官方版本包含由Wireshark開發人員維護的所有外掛,但是自定義/分發版本不包括這些編解碼器中的一些。要檢查您的Wireshark安裝的編解碼器外掛,請執行以下操作:開啟Help>關於Wireshark。選擇「外掛」頁籤。在「Filter by type」選單中,選擇「Codec」。
4.檢查RTP統計資訊,檢視音訊流中是否存在任何抖動或丟失。要檢視分析,請導航到Telephony > RTP > RTP Stream Analysis。
![RTP Stream Analysis](/c/dam/en/us/support/docs/switches/catalyst-9300-series-switches/220655-troubleshoot-network-related-audio-issue-05.png)
![RTP Stream Analysis 2](/c/dam/en/us/support/docs/switches/catalyst-9300-series-switches/220655-troubleshoot-network-related-audio-issue-06.png)
抖動:通過網路傳送語音資料包的時延。這通常是由網路擁塞或路由變化引起的。此測量值必須小於30ms。
丟失:未作為音訊流的一部分接收的資料包。丟包率不得超過1%。
5.在電話> RTP > RTP流中轉換來自此流的音訊波
![RTP Play Streams](/c/dam/en/us/support/docs/switches/catalyst-9300-series-switches/220655-troubleshoot-network-related-audio-issue-07.png)
6.選擇要將其轉換為音訊的流,然後按一下播放流。
![RTP Play Streams 2](/c/dam/en/us/support/docs/switches/catalyst-9300-series-switches/220655-troubleshoot-network-related-audio-issue-08.png)
必須顯示音訊波,並且播放按鈕可用於收聽音訊資料。聽到音訊有助於識別流是否存在語音波動或單向音訊問題。
![Audio Wave](/c/dam/en/us/support/docs/switches/catalyst-9300-series-switches/220655-troubleshoot-network-related-audio-issue-09.png)
7.按一下匯出>檔案同步音訊,將流匯出到副檔名為.wav的音訊檔案中。
![Audio Export](/c/dam/en/us/support/docs/switches/catalyst-9300-series-switches/220655-troubleshoot-network-related-audio-issue-10.png)
疑難排解
使用SPAN功能通過Wireshark收集和分析捕獲後,我們就會瞭解問題是否與抖動、封包丟失或單向音訊有關。如果在資料包捕獲中發現任何問題,下一步是檢查捕獲的裝置,查詢可能會影響RTP音訊流的常見問題。
斷斷續續的音訊
頻寬不足、抖動和/或丟包可能是音訊捕獲中聽到語音中斷或失真的常見原因。
1.檢查捕獲上的抖動是否大於30毫秒。如果是,則表示接收資料包時存在時間延遲,這可能是由於QoS策略或路由問題造成的。
2.檢驗捕獲時丟失的資料包是否大於1%。如果此值很高,則需要查詢音訊流路徑上的資料包丟包。
3.檢查路徑中涉及的輸入和輸出介面上是否有捨棄專案。
Switch#show interface Gi1/0/1 | inc drops
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
0 unknown protocol drops
Switch#show interfaces Gi1/0/1 counters errors Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards Gi1/0/1 0 0 0 0 0 0 Port Single-Col Multi-Col Late-Col Excess-Col Carri-Sen Runts Gi1/0/1 0 0 0 0 0 0
驗證介面上沒有遞增的輸入/輸出捨棄或其他遞增錯誤。
4.檢查路徑中涉及的介面上的QoS出口策略。確保您的流量在優先順序隊列中對映/分類,並且此隊列中沒有丟棄。
Switch#show platform hardware fed switch 1 qos queue stats interface Gi1/0/1
----------------------------------------------------------------------------------------------
AQM Global counters
GlobalHardLimit: 3976 | GlobalHardBufCount: 0
GlobalSoftLimit: 15872 | GlobalSoftBufCount: 0
----------------------------------------------------------------------------------------------
High Watermark Soft Buffers: Port Monitor Disabled
----------------------------------------------------------------------------------------------
Asic:0 Core:1 DATA Port:0 Hardware Enqueue Counters
----------------------------------------------------------------------------------------------
Q Buffers Enqueue-TH0 Enqueue-TH1 Enqueue-TH2 Qpolicer
(Count) (Bytes) (Bytes) (Bytes) (Bytes)
-- ------- -------------------- -------------------- -------------------- --------------------
0 0 0 707354 2529238 0 <<< Priority Q
1 0 0 0 1858516 0
2 0 0 0 0 0
3 0 0 0 0 0
4 0 0 0 0 0
5 0 0 0 0 0
6 0 0 0 0 0
7 0 0 0 0 0
Asic:0 Core:1 DATA Port:0 Hardware Drop Counters
--------------------------------------------------------------------------------------------------------------------------------
Q Drop-TH0 Drop-TH1 Drop-TH2 SBufDrop QebDrop QpolicerDrop
(Bytes) (Bytes) (Bytes) (Bytes) (Bytes) (Bytes)
-- -------------------- -------------------- -------------------- -------------------- -------------------- --------------------
0 0 0 0 0 0 0 <<< Priority Q Drops
1 0 0 0 0 0 0
2 0 0 0 0 0 0
3 0 0 0 0 0 0
4 0 0 0 0 0 0
5 0 0 0 0 0 0
6 0 0 0 0 0 0
7 0 0 0 0 0 0
注意:如果存在丟棄,請確保使用DSCP加速轉發(EF)標籤正確分析語音流量,並確認沒有其他惡意流錯誤地標籤了EF位,因此導致優先順序隊列擁塞。
單向音訊
當電話呼叫建立時,只有一方接收音訊。此問題的常見原因與連通性問題、路由問題或NAT/防火牆問題有關。
1.對目標子網或目標網關執行ping操作以確認存在雙向可達性。
Switch#ping 192.168.1.150
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.150, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
2.執行從源子網到目標子網的traceroute,反之亦然。這有助於檢查路徑中的跳數以及它是否對稱。
Switch#traceroute 192.168.1.150
Type escape sequence to abort.
Tracing the route to 192.168.1.150
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.2.12 2 msec * 1 msec
2 192.168.1.12 2 msec * 1 msec
3 192.168.1.150 2 msec 2 msec 1 msec
3.檢查每個子網的網關裝置是否具有最佳路由,並且沒有可能會影響通訊的非對稱路徑。
提示:常見的單向音訊問題與防火牆規則或NAT問題上的ACL配置錯誤有關。建議驗證這些事物是否可能影響音訊流流。
4.在最後一台裝置上進行資料包捕獲,在該裝置上看到音訊流量指向故障方向。這有助於隔離哪台路徑中的裝置丟失了音訊流。這一點非常重要,因為可以通過NAT或防火牆裝置允許ping流量,但是可以阻止或無法正確轉換特定音訊流量。
相關資訊