了解封包語音網路中的抖動（Cisco IOS平台）
簡介
本文檔介紹抖動，以及如何測量和補償抖動。
必要條件
需求
本文檔的讀者應瞭解以下主題：
-
基本Cisco IOS®語音配置
-
對服務品質(QoS)有基礎認識
採用元件
本檔案中的資訊適用於Cisco IOS語音閘道器和路由器。
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路正在作用，請確保您已瞭解任何指令可能造成的影響。
慣例
如需文件慣例的詳細資訊，請參閱思科技術提示慣例。
封包語音網路中的抖動
抖動被定義為接收分組延遲的變化。在傳送端，分組以連續流形式傳送，並且分組均勻地間隔開。由於網路擁塞、排隊不正確或配置錯誤，此穩定流可能會成塊，或者每個資料包之間的延遲可能會有所不同，而不是保持不變。
此圖說明了如何處理穩定的資料包流。
路由器收到用於IP語音(VoIP)的即時協定(RTP)音訊流時，必須補償遇到的抖動。處理此功能的機制是播放延遲緩衝區。播放延遲緩衝器必須緩衝這些資料包，然後在穩定的流中播放這些資料包到數位訊號處理器(DSP)，以轉換回模擬音訊流。播放延遲緩衝區有時也稱為去抖動緩衝區。
此圖說明如何處理抖動。
如果抖動非常大，導致接收超出此緩衝器範圍的資料包，則會丟棄超出範圍的資料包，並在音訊中聽到丟棄。對於小到一個資料包的丟失，DSP會插入它認為音訊應該有的內容，並且不存在可聽的問題。當抖動超過DSP彌補丟失的資料包的能力時，會聽到音訊問題。
此圖說明如何處理過度抖動。
確定抖動的嚴重性
完成這些步驟，可以通過Cisco IOS確認是否存在過度抖動。
-
一旦呼叫啟動並處於活動狀態，並且懷疑有抖動，Telnet會連線到其中一個相關的網關。
-
啟用Terminal Monitor以便可以通過Telnet會話檢視控制檯消息。
注意：如果您已連線到控制檯埠，則無需執行此步驟。
-
輸入show voice call summary命令。將顯示類似以下的輸出：
PORT CODEC VAD VTSP STATE VPM STATE ============ ======== === ==================== ====================== 1/0/0 - - - FXSLS_ONHOOK 1/0/1 g729r8 y S_CONNECT FXSLS_CONNECT
選擇遇到抖動的呼叫。在本例中，它是1/0/1。
-
要檢視此特定呼叫，請輸入show voice call命令。
在本例中，它是show voice call 1/0/1。提供的輸出來自處理呼叫的DSP，如下所示：
1/0/1 vtsp level 0 state = S_CONNECT vpm level 1 state = FXSLS_CONNECT vpm level 0 state = S_UP MS-2621-3B# ***DSP VOICE VP_DELAY STATISTICS*** Clk Offset(ms): 0, Rx Delay Est(ms): 50 Rx Delay Lo Water Mark(ms): 50, Rx Delay Hi Water Mark(ms): 7 ***DSP VOICE VP_ERROR STATISTICS*** Predict Conceal(ms): 0, Interpolate Conceal(ms): 0 Silence Conceal(ms): 0, Retroact Mem Update(ms): 0 Buf Overflow Discard(ms): 0, Talkspurt Endpoint Detect Err: 0 ***DSP VOICE RX STATISTICS*** Rx Vox/Fax Pkts: 1187, Rx Signal Pkts: 0, Rx Comfort Pkts: 0 Rx Dur(ms): 150200, Rx Vox Dur(ms): 23740, Rx Fax Dur(ms): 0 Rx Non-seq Pkts: 0, Rx Bad Hdr Pkts: 0 Rx Early Pkts: 0, Rx Late Pkts: 0 ***DSP VOICE TX STATISTICS*** Tx Vox/Fax Pkts: 7129, Tx Sig Pkts: 0, Tx Comfort Pkts: 0 Tx Dur(ms): 150200, Tx Vox Dur(ms): 14259, Tx Fax Dur(ms): 0 ***DSP VOICE ERROR STATISTICS*** Rx Pkt Drops(Invalid Header): 0, Tx Pkt Drops(HPI SAM Overflow): 0 ***DSP LEVELS*** TDM Bus Levels(dBm0): Rx -54.5 from PBX/Phone, Tx -64.7 to PBX/Phone TDM ACOM Levels(dBm0): +2.0, TDM ERL Level(dBm0): +9.9 TDM Bgd Levels(dBm0): -49.4, with activity being voice -
檢視輸出中的***DSP VOICE VP_ERROR STATISTICS***部分。
在本節中，有幾個引數要檢視。主要之一是可見的Buf Overflow Discard(ms)數。這會計算超出播放延遲緩衝區（已丟棄）範圍的封包。 只要它不持續增加，它可能具有一定價值。第一次發起呼叫時通常會出現一些溢位，但是重複show voice call X/X/X命令時，該值不應增加。此數字直接表示抖動過多。
預設情況下，此緩衝區在自適應模式下運行，在此模式下它會動態調整到存在的抖動量（最多為一點）。 配置playout-delay命令以更改去抖動緩衝區的動態行為的預設值。也可以在固定模式下設定此緩衝區。這可以修復抖動的一些問題。如需詳細資訊，請參閱IP語音的播放延遲增強功能。
什麼會導致抖動？
抖動通常是由於IP網路中的擁塞引起的。如果電路未正確調配，則會在路由器介面或提供商或運營商網路中出現擁塞。
封裝注意事項
最容易也最好地開始尋找抖動的地方是在路由器介面，因為您可以直接控制電路的這一部分。追蹤抖動來源的方式在很大程度上取決於發生抖動的鏈路的封裝和型別。通常，由於涉及恆定信元速率，ATM電路在正確配置時不會遇到抖動。這樣可提供非常一致的延遲。如果在ATM環境中出現抖動，則必須檢查ATM配置。當ATM正常工作時（沒有丟棄的信元），可以預期抖動不是問題。在點對點通訊協定(PPP)封裝中，抖動幾乎總是由於序列化延遲所致。這可以通過PPP鏈路上的鏈路分段和交錯輕鬆進行管理。PPP的性質意味著PPP終端直接彼此通訊，彼此之間沒有交換機網路。這樣，網路管理員就可以控制所涉及的所有介面。
幀中繼環境中的抖動
要發現幀中繼環境中的抖動，需要處理三個引數：
有關配置示例和配置此配置的相關資訊，請參閱具有服務品質的VoIP over Frame Relay。
流量調節
您需要確保將離開路由器的流量整形為運營商提供的實際承諾資訊速率(CIR)。通過檢視幀中繼統計資訊並檢查運營商來檢驗這一點。首先要瞭解的是幀中繼統計資訊。使用show frame-relay pvc xx命令，其中xx是資料鏈路連線識別符號(DLCI)編號。您應該會收到類似以下的輸出：
PVC Statistics for interface Serial0/1 (Frame Relay DTE) DLCI = 16, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/1.1 input pkts 103611 output pkts 120054 in bytes 9909818 out bytes 10962348 dropped pkts 0 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 0 out DE pkts 0 out bcast pkts 1366 out bcast bytes 448048 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec pvc create time 22:45:57, last time pvc status changed 22:45:57 Queueing strategy: weighted fair Current fair queue configuration: Discard Dynamic Reserved threshold queue count queue count 64 16 0 Output queue size 0/max total 600/drops 18303 fragment type end-to-end fragment size 1600 cir 20000 bc 1000 be 0 limit 125 interval 50 mincir 20000 byte increment 125 BECN response no IF_CONG no frags 103356 bytes 9807006 frags delayed 67241 bytes delayed 7127120 shaping active traffic shaping drops 18303
請參閱show frame-relay pvc說明，獲取所有欄位的完整說明。
尋找什麼
在命令輸出中，您應該關注的是顯示幀網路是否發生擁塞的值。這些值是前向顯式擁塞通知(FECN)、後向顯式擁塞通知(BECN)和丟棄合格引數(DE)。您應該只考慮輸入封包，因為Cisco不會傳送其中任何一個封包。您可能會看到其中的一個或多個值遞增。這取決於提供商使用的幀交換機的型別和配置。一般來說，如果您有幀中繼流量調節，並且配置為與電路相同的CIR，則這些值永遠不會增加。如果您確實看到這些值遞增，而且您與電路的真實CIR匹配，則幀提供商網路中的某些內容未正確配置。
一個很好的例子是，如果您購買了零CIR電路，但有一個突發值。某些提供商銷售零CIR永久虛擬電路(PVC)。 這對資料沒有影響，但會導致語音品質問題。如果檢視零CIR電路的命令輸出，則DE或FECN資料包的數量等於輸入資料包的數量。更進一步，如果運營商調配的PVC為128 kbs，並且路由器的CIR設定為512 kbs，您會看到這些計數增加（速度較慢）。 請記住，您只會檢視進入路由器介面的資料包，而且此速率由PVC另一端路由器上配置的流量整形引數控制。反之，您可以控制輸入到另一台路由器的內容，透過該路由器在本地終端上設定流量整形引數。
對於運營商調配的PVC，請勿超過CIR，這一點非常重要。您可以低於此CIR而不會出現問題。但是，如果超出該值，您將看到擁塞。
您能夠以這種方式看到擁塞的原因在於，為訊框交換器上特定PVC設定的CIR會指定流量通過該交換器（針對該PVC）的速率。 當幀交換機上配置的CIR超出其接收的實際資料速率時，它必須緩衝超過CIR的幀，直到有容量可用於轉發緩衝的資料包。任何緩衝的資料包都會獲得幀交換機設定的DE位或FECN位。
與往常一樣，您還需要仔細檢查介面統計資訊，並查詢丟棄或錯誤，以確保所有資訊在物理層都正常運行。為此，請使用show interface命令。
這與抖動的關係在於，如果發生這種情況，並且某些資料包需要在幀網路中緩衝，它們到遠端路由器的延遲會更長。但是，如果沒有擁塞，它們會在您通常預期的延遲時間內通過。這會導致遠端路由器上接收的封包之間的增量時間不同。這就是抖動。
分段
分段與序列化延遲的關係比與抖動的關係更大。但是，在某些情況下，它可能是抖動的原因。當執行資料包化語音時，應始終在幀中繼對映類中配置分段。此引數的配置對介面有兩個影響。第一個效果是大於指定大小的所有資料包都會進行分段。第二種效應不那麼明顯，但同樣重要。如果您檢視已設定分段的介面，可以看到此指令的影響。如果沒有分段，show interface x命令的輸出中顯示的排隊策略顯示正在使用先進先出(FIFO)隊列。將分段應用到幀中繼對映類後，此命令的輸出將隊列策略顯示為雙FIFO。這會建立用於介面上的語音流量的優先順序隊列。強烈建議將該分段值設定為採用QoS的VoIP over Frame Relay文檔的分段部分中建議的值。如果按照建議的值仍遇到抖動問題，請逐一降低分段值，直到語音品質變得可以接受。
佇列
對於此類環境中的VoIP流量，有兩種公認的排隊方法：
應該使用其中一種方法，但不應同時配置這兩種方法。如果根據說明檔案排隊操作看起來正確，則可以斷定排隊操作工作正常，問題出在其他地方。排隊通常不是抖動的原因，因為由排隊產生的延遲變化相對較小。但是，如果VoIP資料包未正確排隊，並且同一電路上有資料，則可能會導致抖動。
結論
抖動是語音資料包的資料包等待時間的變化。路由器中的DSP可以彌補某些抖動，但可以通過過度抖動來克服。這會導致語音品質較差。抖動的原因是一封封包在電路中的某個地方排隊或延遲，而這裡沒有其他封包的延遲或佇列。這會導致延遲的變化。抖動可能是由路由器配置錯誤以及運營商或提供商的PVC配置錯誤造成的。
意見