疑難排解QoS斷斷續續的語音問題

下載選項

PDF (561.7 KB)
在多種裝置上使用 Adobe Reader 檢視

已更新: 2006 年 2 月 2 日

文件 ID:20371

無偏見用語

本產品的文件集力求使用無偏見用語。針對本文件集的目的，無偏見係定義為未根據年齡、身心障礙、性別、種族身分、民族身分、性別傾向、社會經濟地位及交織性表示歧視的用語。由於本產品軟體使用者介面中硬式編碼的語言、根據 RFP 文件使用的語言，或引用第三方產品的語言，因此本文件中可能會出現例外狀況。深入瞭解思科如何使用包容性用語。

關於此翻譯

思科已使用電腦和人工技術翻譯本文件，讓全世界的使用者能夠以自己的語言理解支援內容。請注意，即使是最佳機器翻譯，也不如專業譯者翻譯的內容準確。Cisco Systems, Inc. 對這些翻譯的準確度概不負責，並建議一律查看原始英文文件（提供連結）。

簡介

為了使分組語音成為標準公共交換電話網路(PSTN)電話服務的實際替代方案，收到的分組語音品質必須與基本電話服務的品質相當。這意味著始終保持高品質的語音傳輸。與其他即時應用一樣，Packet Voice具有寬頻寬和延遲敏感性。為了使語音傳輸對接收方來說是可理解的（不是波濤狀的），語音資料包不能被丟棄、過度延遲或遭受變化的延遲（也稱為抖動）。本檔案介紹各種服務品質(QoS)注意事項，協助排解斷續續的語音問題。斷斷續續的語音問題的主要原因是丟失和延遲的語音資料包。

必要條件

需求

本文檔的讀者應瞭解以下內容：

封包語音(VoIP、透過框架轉送傳輸的語音(VoFR)或ATM語音(VoATM)的基本設定（視乎其需求而定）。
基本瞭解語音優先順序、分段、不同編解碼器及其頻寬要求。

採用元件

本檔案中的資訊適用於所有Cisco語音閘道器軟體和硬體版本。

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您在即時網路中工作，請確保在使用任何命令之前瞭解其潛在影響。

慣例

如需文件慣例的詳細資訊，請參閱思科技術提示慣例。

語音斷斷的原因

斷斷續續的語音品質是由網路中的語音資料包被可變延遲或丟失引起的。當語音資料包到達目的地時延遲時，目的地網關會丟失即時資訊。在這種情況下，目的地閘道必須預測遺漏封包的內容可能是什麼。該預測導致所接收的語音不具有與所傳送的語音相同的特性。這會產生一個聽上去很機械的聲音。如果語音資料包被延遲到超出接收網關的預測能力，則網關將即時間隙留空。由於接收端沒有東西可以填補這個空白，所以傳送語音的一部分就丟失了。這會導致語音不穩。確保語音資料包沒有非常延遲（並且不是可變延遲）可以解決許多斷斷續續的語音問題。有時，語音活動檢測(VAD)會將前端剪輯新增到語音對話中。這是導致聲音不穩（或剪斷）的另一個原因。

本文檔中的各個部分介紹了如何最小化斷斷續續的語音例項。大多數測量都需要確保在您的語音網路中引入最小抖動。

頻寬要求

在考慮應用任何措施來將抖動降至最低之前，請調配足夠的網路頻寬來支援即時語音流量。例如，一個80 kbps G.711 VoIP呼叫（64 kbps負載+ 16 kbps報頭）在64 kbps的鏈路上聽起來很差，因為至少丟棄了16 kbps的資料包（即20%）。頻寬要求因用於壓縮的編解碼器而異。不同的編解碼器有不同的負載和標頭要求。VAD的使用也影響頻寬需求。如果使用即時通訊協定(RTP)標頭壓縮(cRTP)，則可進一步降低頻寬需求。

例如，使用G.729編解碼器（預設20位元組負載）和cRTP進行語音呼叫所需的頻寬如下所示：

語音負載+壓縮(RTP報頭+使用者資料包協定(UDP)報頭+ IP報頭)+第2層報頭

這相當於：

20位元組+壓縮後（12位元組+ 8位元組+ 20位元組）+ 4位元組

這等於：

28位元組，因為標頭壓縮會將IP RTP標頭最多壓縮到4位元組。這樣以8 kbps的編解碼器速率（50資料包/秒）產生11.2 kbps。

如需詳細資訊，請參閱透過IP傳輸的語音 — 每次呼叫的頻寬消耗。

語音流量優先順序

確定語音優先順序有兩個重要組成部分。第一是分類並標籤感興趣的語音流量。第二是優先處理已標籤的有趣語音流量。這兩個小節討論對語音進行分類、標籤和優先排序的各種方法。

分類和標籤

為了保證VoIP資料包的頻寬，網路裝置必須能夠識別流經它的所有IP流量中的資料包。網路裝置使用IP報頭中的源IP地址和目的IP地址，或UDP報頭中的源UDP埠號和目的UDP埠號來標識VoIP資料包。這種識別和分組過程稱為分類。它是提供任何QoS的基礎。

封包分類可能是處理器密集型。因此，分類需要在儘可能靠近網路邊緣的地方進行。因為每一跳仍需要確定資料包應該接受的處理，所以您需要在網路核心中有一種更簡單、更有效的分類方法。這種更簡單的分類是通過在IP報頭中標籤或設定服務型別(ToS)位元組來實現的。ToS位元組的三個最高有效位稱為IP優先位。大多數應用程式和供應商目前都支援設定並識別這三個位。標籤正在不斷發展，以便可以使用ToS位元組的六個最高有效位，即差分服務代碼點(DSCP)。請參閱要求建議(RFC)。

區分服務(DiffServ)是一種新的模型，其中流量由具有相對優先順序的中間系統基於ToS欄位進行處理。在RFC 2474 和RFC 2475 中定義，DiffServ標準取代在RFC 791 中定義封包優先順序的原始規範。DiffServ通過重新分配IP資料包的位用於優先順序標籤，增加了可定義的優先順序級別的數量。DiffServ體系結構定義了DiffServ欄位。它取代IP V4中的ToS位元組，就封包分類和流量調節功能（例如計量、標籤、整形和管制）做出每躍點行為(PHB)決策。除了前面提到的RFC外，RFC 2597 還定義保證轉發(AF)類。這是DSCP欄位的細分。有關DSCP的詳細資訊，請參閱使用DSCP實施服務品質策略。

ToS位元組 — P2 P1 P0 T3 T2 T1 T0 CU

IP優先順序：3位(P2-P0),ToS:四位(T3-T0),CU:1位

DiffServ字段 — DS5 DS4 DS3 DS2 DS1 DS0 ECN ECN

DSCP:六位(DS5-DS0),ECN:兩位

XXX00000位0、1、2(DS5、DS4、DS3)是優先位，其中：

111 =網路控制=優先順序7
110 =網際網路控制=優先順序6
101 = CRITIC/ECP =優先順序5
100 =快閃記憶體覆蓋=優先順序4
011 =快閃記憶體=優先順序3
010 =立即=優先順序2
001 =優先順序=優先順序1
000 =常式=優先順序0

000XXX00位3、4、5(DS2、DS1、DS0)是延遲、吞吐量和可靠性位。

第3位元=延遲[D](0 =正常；1 =低)
第4位元=輸送量[T](0 =正常；1 =高)
第5位=可靠性[R](0 =正常；1 =高)

000000XX位元6、7:ECN

這兩個部分討論分類和標籤的兩個方式。

用於對封包進行分類和標籤的語音撥號對等體

使用Cisco VoIP網關，您通常使用語音撥號對等體對VoIP資料包進行分類並標籤IP優先順序位。此組態顯示如何標籤IP優先順序位元：

dial-peer voice 100 voip
destination-pattern 100
session target ipv4:10.10.10.2
ip precedence 5

在上方範例中，任何與dial-peer voice 100 voip指令相符的VoIP通話都會將其所有語音負載封包設定為IP優先順序5。這表示IP ToS位元組三個最重要的位元設定為101。

dial-peer voice 100 voip
destination-pattern 100
session target ipv4:10.10.10.2
ip qos dscp ef media
ip qos dscp af31 signaling

在上方範例中，任何與dial-peer voice 100 voip指令相符的VoIP通話都會將其所有媒體負載封包（語音封包）設定為加速轉送(EF)位元模式101110。所有訊號封包都設定為AF位元模式011010。

註：自Cisco IOS®軟體版本12.2(2)T起，就支援ip qos dscp命令。Cisco IOS軟體版本12.2T不再提供IP優先順序。但是，ip qos dscp命令也可以實現相同功能。IP優先順序5(101)對映到IP DSCP 101000。有關詳細資訊，請參閱使用DSCP對QoS的VoIP信令和媒體進行分類。

用於分類和標籤資料包的模組化QoS CLI

推薦使用的分類和標籤方法是模組化QoS CLI。這是一種基於模板的配置方法，它將分類與策略分開。這允許為多個類別一起配置多個QoS功能。使用class-map命令根據各種匹配條件對流量進行分類，使用policy-map命令確定每個類需要發生的情況。通過發出service-policy命令，將該策略應用於介面上的傳入或傳出流量。此配置示例說明如何使用模組化QoS CLI對資料包進行分類和標籤：

access-list 100 permit udp any any range 16384 32767
access-list 101 permit tcp any any eq 1720
!
class-map match-all voip
match access-group 100
class-map match-all control
match access-group 101
!
policy-map mqc
class voip
set ip precedence 5
class control
set ip precedence 5
class class-default
set ip precedence 0
!
interface Ethernet0/0
service-policy input mqc

在此配置示例中，與訪問控制清單(ACL)100匹配的所有流量都分類為「class voip」，並使用IP優先順序5進行設定。這意味著IP ToS位元組的三個最高位設定為101。ACL 100與VoIP使用的通用UDP埠匹配。類似地，ACL 101匹配H.323信令流量(傳輸控制協定(TCP)埠1720)。所有其他流量都使用IP優先順序0設定。該策略稱為「mqc」。它應用於Ethernet 0/0上的傳入流量。

優先排序

當網路中的每一跳都能夠分類和識別VoIP資料包（通過埠/地址資訊或通過ToS位元組）後，這些跳將為每個VoIP資料包提供所需的QoS。此時，配置特殊技術來提供優先順序隊列，以確保大的資料包不會干擾語音資料傳輸。在速度較慢的WAN鏈路上通常需要這種方法，因為這種鏈路有很高的擁塞可能性。一旦所有感興趣的流量根據其QoS要求被放入QoS類，通過智慧輸出排隊機制提供頻寬保證和優先順序服務。VoIP需要優先順序隊列。

附註： 使用任何有效為VoIP提供高優先順序的排隊機制。但是，建議使用低延遲佇列(LLQ)，因為它非常靈活且易於設定。

LLQ使用模組化QoS CLI配置方法為某些類提供優先順序，並為其他類提供保證的最小頻寬。在擁塞期間，優先順序隊列按配置的速率進行管制，以便優先順序流量不會用盡所有可用頻寬。（如果優先順序流量獨佔頻寬，則會阻止滿足其他類的頻寬保證。）如果正確預配LLQ，則進入優先順序隊列的流量決不能超過配置的速率。

LLQ還允許指定隊列深度，以確定當任何特定類隊列中有太多等待的資料包時，路由器需要丟棄資料包的時間。此外，還使用class-default命令來確定對未按已配置類別分類的所有流量的處理。class-default是使用fair-queue命令配置的。這意味著每個未分類流將獲得大約相等份額的剩餘頻寬。

此示例說明如何配置LLQ。如需詳細資訊，請參閱低延遲佇列:

access-list 100 permit udp any any range 16384 32000
access-list 101 permit tcp any any eq 1720
access-list 102 permit tcp any any eq 80
access-list 103 permit tcp any any eq 23
!
class-map match-all voip
match access-group 100
class-map match-all voip-control
natch access-group 101
class-map match-all data1
match access-group 102
class-map match-all data2
match access-group 103
!
policy-map llq
class voip
priority 32
class voip-control
bandwidth 8
class data1
bandwidth 64
class data2
bandwidth 32
class class-default
fair-queue
!
interface Serial1/0
bandwidth 256
service-policy output llq

在本例中，任何與ACL 100相匹配的流量都歸類為「class voip」（表示語音流量）。其優先順序最高32 kbps。ACL 100匹配VoIP使用的通用UDP埠。Access-list 101與H.323信令流量（TCP埠1720）匹配。 Class data1匹配Web流量（TCP埠80，如訪問清單102所示）並保證64 kbps。Class data2匹配Telnet流量（如ACL 103中看到的TCP埠23），並保證32 kbps。預設類配置為將剩餘頻寬的同等份額分配給未分類流。該策略稱為「llq」。它應用於Serial1/0上的傳出流量，該介面的總頻寬為256 kbps。

注意：預設情況下，所有類別的總保證頻寬和優先順序頻寬需要小於介面頻寬的75%。通過發出max-reserved bandwidth interface命令修改此百分比。

此表比較了不同的軟體排隊機制及其各自的優點和限制。

軟體佇列機制	說明	優勢	限制
先進先出(FIFO)	資料包到達和離開隊列的順序完全相同。	配置簡單，運行速度快。	無法提供優先順序服務或頻寬保證。¹
加權公平佇列(WFQ)	一種雜湊演算法，流到獨立的隊列中，使用權重來確定每次服務多少資料包。您可以通過設定IP優先順序和DSCP值來定義權重。	配置簡單。鏈路的預設值小於2 Mbps。	無法提供優先順序服務或頻寬保證。¹
自訂佇列(CQ)	流量被分類到多個隊列中，隊列限制可配置。隊列限制根據平均資料包大小、最大傳輸單元(MTU)和要分配的頻寬百分比來計算。每個隊列的隊列限制（以位元組為單位）已出隊。因此，它會以統計方式提供分配的頻寬。	已經存在幾年了。它允許為不同隊列分配近似頻寬。	不能提供優先順序服務。頻寬保證是近似的。隊列數量有限。組態相對困難。¹
優先順序佇列(PQ)	流量分為高、中、正常和低優先順序隊列。首先為高優先順序流量提供服務，然後為中優先順序、普通優先順序和低優先順序流量。	已經存在幾年了。它提供優先服務。	優先順序較高的流量會佔用優先順序較低的頻寬隊列。不能保證頻寬。²
類別式加權公平佇列(CBWFQ)	模組化QoS CLI用於對流量進行分類。分類流量被置於預留頻寬隊列或預設未預留隊列中。排程器根據權重為隊列提供服務，以便滿足頻寬保證。	與LLQ類似，不同之處在於沒有優先順序隊列。簡單的配置和提供頻寬保證的能力。	不能優先提供服務。³
優先順序佇列加權公平佇列(PQ-WFQ)（也稱為IP RTP優先順序）	單個介面命令用於為發往指定範圍內的偶數埠號的所有UDP資料包提供優先順序服務。	簡單，一個命令配置。為RTP資料包提供優先順序服務。	所有其他流量使用WFQ處理。即時會議通訊協定(RTCP)流量沒有優先順序。無保證頻寬能力。⁴
LLQ，以前稱為優先隊列類別型加權公平佇列(PQCBWFQ)	帶有優先順序隊列的模組化QoS CLI用於對流量進行分類。分類流量被置於優先順序隊列、預留頻寬隊列或預設未預留隊列中。排程器根據權重服務隊列，以便優先傳送優先順序流量（在擁塞期間達到某個策略規定的限制）並且滿足頻寬保證。	配置簡單。能夠為多類流量提供優先順序並為優先順序頻寬利用率提供上限。您還可以配置頻寬保證類和一個預設類。	尚無提供多個優先順序級別的機制，所有優先順序流量都通過同一個優先順序隊列傳送。在擁塞期間，單獨的優先順序類可以有單獨的上優先順序頻寬邊界。但是，應用程式之間共用優先順序隊列可能會引入抖動。⁴

不適合於語音。
需要保證語音的頻寬。
需要處理延遲。
足夠發聲了。

序列化延遲

即使隊列以最佳狀態工作並優先處理語音流量，有時優先順序隊列是空的，並且來自另一個類的包正在接受服務。必須根據已配置的權重為來自保證頻寬類的資料包提供服務。如果在為優先順序的語音資料包提供服務時它們到達輸出隊列，則語音資料包可以在傳送之前等待相當長的時間。當語音資料包必須等待較大的資料包時，它們會經歷序列化延遲。

序列化延遲可能為語音封包帶來最糟糕的抖動形式。如果語音資料包必須等待一個大到1500位元組的資料包，則在較慢的鏈路上，這將轉換為巨大的延遲。如果資料包為80位元組，序列化延遲將截然不同，如以下示例所示：

由於1500位元組封包= 1500*8/64000 = 187.5毫秒而導致64 kbps連結的序列化延遲。
由於80位元組封包= 80*8/64000 = 10毫秒，造成64 kbps連結的序列化延遲。

因此，如果語音資料包在64 kbps鏈路上被一個1500位元組資料包卡住，它可能必須等待最多187.5毫秒才能傳送。另一方面，另一個語音資料包在目的地網關處僅需要等待10毫秒。這會導致由於封包間延遲的差異而出現的巨大抖動。在始發網關上，通常每20毫秒傳送一次語音資料包。如果端到端延遲預算為150毫秒，並且要求嚴格的抖動，則超過180毫秒的間隔是無法接受的。

引入分段機制，確保一個傳輸單元的大小小於10毫秒。序列化延遲超過10 ms的任何資料包都需要被分段為10 ms的資料塊。10 ms chunk或fragment是10 ms內通過鏈路傳送的位元組數。使用鏈路速度計算大小，如以下示例所示：

分段大小=（0.01秒* 64,000 bps）/（8位/位元組）= 80位元組

通過64 kbps鏈路傳送80位元組資料包或片段需要10毫秒。

如果單個物理介面上有多個ATM或幀中繼永久虛擬電路(PVC)，請根據可用頻寬最低的PVC配置分段值（在所有PVC上）。例如，如果存在三個保證頻寬為512 kbps、128 kbps和256 kbps的PVC，則請為所有三個PVC配置片段大小為160位元組（最低速度為128 kbps，需要160位元組的片段大小）。對於不同的鏈路速度，建議使用以下值：

Link Speed (kbps)         Fragmentation Size (bytes) 
56                                  70 
64                                  80 
128                                 160 
256                                 320 
512                                 640 
768                                 960 
1024                                1280 
1536                                1920

注意：如果片段大小大於連結MTU大小，則無需分段。例如，對於具有1500位元組MTU的T1連結，片段大小為1920位元組。因此，不需要分段。資料包分段大小決不能低於VoIP資料包大小。請勿對VoIP資料包進行分段。分段這些資料包會導致許多呼叫建立和品質問題。

目前提供三種連結分割和交錯(interleaving)機制。有關在封包網路中引入的各種延遲的進一步說明，請參閱了解封包語音網路中的延遲。下表列出了它們的優點和限制：

連結分割和交錯(LFI)機制	說明	優勢	限制
使用WFQ的MTU分段	用於更改MTU大小或IP MTU大小的介面級別命令。用於將大型IP資料包分段為指定的MTU大小。LFI使用WFQ在片段之間插入即時封包。	配置簡單。	片段僅由接收應用程式重組。因此，網路的使用效率低下。只有未設定「不分段(DF)」位元的IP封包才能順利處理分段。處理器密集程度高。不推薦。
多重連結點對點通訊協定(MLPPP)LFI	在點對點串列鏈路上，必須首先配置MLPPP，然後必須以ms為單位設定分段大小。在多鏈路介面上也必須啟用交錯。	封包在連結的一端分段並在另一端重組。多個連線可以組合成大型虛擬管道。	僅適用於針對PPP配置的鏈路。Cisco IOS軟體版本12.1(5)T或更新版本也支援使用訊框中繼的PPP或使用ATM的PPP解決方案。
訊框中繼分段(FRF.12)	在訊框中繼PVC上，必須啟用frame-relay traffic-shaping命令，並在map-class下設定分段大小。	資料包在PVC的一端分段並在另一端重組。	僅在啟用frame-relay traffic-shaping命令的幀中繼PVC上可用。

VAD

正常的語音對話包括幾個安靜的時刻。典型的語音對話包括40%到50%的沈默。由於40%的語音呼叫都沒有通過網路，因此可以通過部署VAD節省一些頻寬。使用VAD，網關會查詢語音間隙。它用舒適噪音（背景噪音）替換這些間隙。因此，節省了頻寬量。不過，兩者之間還是存在取捨的。在編解碼器檢測到語音活動之前經過一小段時間（以毫秒為單位），之後是一段靜默期。該小時間導致接收語音的前端剪輯。為了避免在非常短的暫停期間啟用並補償剪輯，VAD在語音停止後等待大約200毫秒後停止傳輸。在重新開始傳輸時，它將前5毫秒的語音與當前語音一起包含在內。如果環境雜訊阻止呼叫區分語音和背景雜訊，則VAD會自動禁用呼叫自身。但是，如果頻寬不是問題，請關閉VAD。

調整VAD引數

有兩個引數決定了VAD的功能。以下是music-threshold和voice vad-time命令。

music — 閾值

決定初始閾值，該閾值控制VAD何時需要變為活動狀態。這可以通過在語音埠上定義music-thresholdthreshold_value命令來控制，如本例所示。其範圍從–70分貝每毫瓦(dBm)到–30 dBm。此值的預設值為–38 dBm。配置較低的值（接近–70 dBm）會導致VAD在較低的訊號強度下變為活動狀態（音量必須下降非常低，才會被視為靜音）。配置更高的值（接近–30 dBm）會導致VAD變為活動狀態，即使語音訊號強度略有下降。它驅使播放更頻繁地播放舒適噪音資料包。但是，這有時會導致音訊的輕微剪輯。

3640-6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
3640-6(config)#voice-port 3/0/0
3640-6(config-voiceport)#music-threshold ?
WORD Enter a number b/w (-70 to -30)
3640-6(config-voiceport)#music-threshold -50
3640-6(config-voiceport)#end
3640-6#
3640-6#show run | be voice-portvoice-port 3/0/0 music-threshold -50

語音影片時間

一旦VAD變為活動狀態，背景噪音和舒適噪音的組成部分就通過在全域性配置下配置voice vad-time timer_value 命令來控制，如本例所示。這是靜默檢測和抑制語音資料包傳輸的延遲時間（以毫秒為單位）。保持時間的預設值為250毫秒。這意味著在250毫秒內，舒適雜訊開始出現。此計時器的範圍為250毫秒至65536毫秒。如果為此配置高值，則舒適雜訊將在以後發揮作用（繼續播放背景雜訊）。如果將其配置為65536毫秒，則舒適雜訊將關閉。希望此計時器的值更高，以便更平滑地轉換背景雜訊和舒適雜訊。將voice vad-time命令配置為較高級別的缺點是，它不能實現預期的30%到35%的頻寬節省。

3640-6#
3640-6#
3640-6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
3640-6(config)#voice vad-time ?
<250-65536> milliseconds
3640-6(config)#voice vad-time 750
3640-6(config)#end
3640-6#
3640-6#
3640-6#
3640-6#show run | be vad-time voice vad-time 750

QoS的典型配置示例

設定VoIP呼叫的典型場景是通過幀中繼鏈路或PPP鏈路。以下是這些情況的組態範例。

VoIPoFR - QoS配置示例

在本示例中（僅包含配置的相關部分），假設幀中繼電路速度為256 kbps。PVC 100和PVC 200上的保證承諾資訊速率(CIR)分別為64 kbps和192 kbps。PVC 100用於傳輸資料和語音。PVC 200僅用於傳送資料。在任何給定時間最多同時存在四個語音呼叫。根據最低頻寬語音PVC（承載語音的PVC）的CIR在兩條PVC上配置分段。根據本文檔中的示例，這意味著分段大小是根據PVC 100的CIR（即64 kbps）決定的。如「序列化延遲」部分的表所示，對於64 kbps的鏈路，需要具有80位元組的分段大小。需要為PVC 200配置相同的分段大小。

有關透過訊框中繼設定VoIP的詳細資訊，請參閱具有服務品質（分段、流量調節、LLQ/IP RTP優先順序）的透過訊框中繼的VoIP。

3660-1#show run
Building configuration...
!
class-map match-any voip
match ip rtp 16384 16383
match ip dscp 26 46
class-map match-all voip-control
match access-group 101
!
!
policy-map VoIPoFR
class voip
priority 48
class voip-control
bandwidth 8
class class-default
fair-queue
!
voice call send-alert
voice rtp send-recv
!
!
interface Serial4/0:0
bandwidth 256
no ip address
encapsulation frame-relay
frame-relay traffic-shaping
!
interface Serial4/0:0.1 point-to-point
bandwidth 64
ip address 10.10.10.10 255.255.255.0
frame-relay ip rtp header-compression
frame-relay interface-dlci 100
 class voice
!
interface Serial4/0:0.2 point-to-point
bandwidth 192
ip address 20.20.20.20 255.255.255.0
frame-relay interface-dlci 200
class data
!
map-class frame-relay data
frame-relay fragment 80
frame-relay adaptive-shaping becn
frame-relay cir 256000
frame-relay bc 32000
frame-relay be 0
frame-relay mincir 192000
frame-relay fair-queue
!
map-class frame-relay voice
frame-relay fragment 80
no frame-relay adaptive-shaping
frame-relay cir 64000
frame-relay bc 640
frame-relay be 0
frame-relay mincir 64000
service-policy output VoIPoFR
!
!
access-list 101 permit tcp any any eq 1720
!
!
voice-port 3/1/0
!
voice-port 3/1/1
!
!
dial-peer voice 10 voip
incoming called-number .
destination-pattern 1408.......
session target ipv4:10.10.10.11
dtmf-relay h245-signal h245-alphanumeric
no vad
!
dial-peer voice 20 pots
destination-pattern 1234
port 3/1/0
!
dial-peer voice 21 pots
destination-pattern 5678
port 3/1/1

使用PPP的VoIP - QoS配置示例

在本例中（僅包含配置的相關部分），假設需要為點對點部分T1控制器（具有12個通道）配置QoS。在任何給定時間最多同時存在四個語音呼叫。配置任務包括使用PPP封裝配置此串列介面，使其成為多鏈路組的一部分，建立多鏈路介面（屬於同一多鏈路組），並在多鏈路介面上配置所有QoS。有關通過PPP配置VoIP的詳細資訊，請參閱具有服務品質（LLQ/IP RTP優先順序、LFI、cRTP）的PPP上的VoIP鏈路。

3660-1#show run
Building configuration...
!
class-map match-any voip
match ip rtp 16384 16383
match ip dscp 26 46
class-map match-all voip-control
match access-group 101
!
!
policy-map VoIPoPPP
class voip
priority 48
class voip-control
bandwidth 8
class class-default
fair-queue
!
voice call send-alert
voice rtp send-recv
!
!
interface Multilink7
bandwidth 768
ip address 10.10.10.10 255.255.255.0
ip tcp header-compression iphc-format
service-policy output VoIPoPPP
no cdp enable
ppp multilink
ppp multilink fragment-delay 10
ppp multilink interleave
multilink-group 7
ip rtp header-compression iphc-format
!
!
interface Serial4/0:0
bandwidth 768
no ip address
encapsulation ppp
no fair-queue
ppp multilink
multilink-group 7
!
!
access-list 101 permit tcp any any eq 1720
!
voice-port 3/1/0
!
voice-port 3/1/1
!
!
dial-peer voice 10 voip
incoming called-number .
destination-pattern 1408.......
session target ipv4:10.10.10.11
dtmf-relay h245-signal h245-alphanumeric
no vad
!
dial-peer voice 20 pots
destination-pattern 1234
port 3/1/0
!
dial-peer voice 21 pots
destination-pattern 5678
port 3/1/1
!

抖動和播放機制

網路中總是有一些不受控制的實體，它們會導致所接收的語音資料包中的進一步延遲和抖動。通過修改終端網關上的抖動緩衝區，可以解決語音網路中不受控制的抖動。

播放機制

抖動緩衝區是時間緩衝區。由終端網關提供，以使播放機制更加有效。以下是播放機制的功能圖：

當播放控制接收到語音資料包時，它會分析RTP時間戳。如果語音封包延遲超過抖動緩衝區的容納容量，則封包會被立即捨棄。如果封包在緩衝能力範圍內，則會將其置於抖動緩衝區中。此封包在抖動緩衝區中的位置取決於為該封包計算的RTP時間戳。如果沒有可用的語音資料包，播放控制會嘗試隱藏該資料包（預測丟失的資料包）。如果啟用VAD，則會播放舒適噪音。

播放控制的責任是處理丟失資料包、重複資料包、損壞的資料包和亂序資料包的事件。這些事件通過時間對準被抖動語音資料包、播放舒適噪音（如果配置了VAD）或甚至重新生成要向主機播放的雙音多頻(DTMF)音來處理。

通過預測隱藏或者通過靜默隱藏來實現語音包的隱藏。預測隱藏基於上一個資料包和下一個資料包（如果可用）。它適用於低位元率編解碼器（5 kbps到16 kbps）。高位元率編解碼器（32 kbps至64 kbps）的語音資料包丟失可能會導致糟糕的預測隱藏。預測隱藏在存在低延遲和不頻繁延遲或較少的資料包丟失時開始。過多的預測隱藏會導致機器人語音品質。靜默隱蔽是最糟糕的預測隱蔽形式。當沒有資訊可供預測時，它就會發揮作用。它只是一種背景掩飾。當存在較高的延遲和更多的資料包丟失時，它開始工作。過多的沈默掩蓋會導致語音品質不穩定。預測掩蓋效果較好，30秒後靜默掩蓋開始發揮作用。

抖動緩衝區

抖動緩衝器被高水位標籤和低水位標籤所限制。高水位線是資料包預期到達以進行按時播放的上限。在高水位線之後到達的資料包被標籤為延遲資料包或丟失資料包。低水位線是資料包預期到達以進行按時播放的最小時間。到達低水位線之前的資料包被視為早期資料包（仍然可以按時播放）。

如果終端網關繼續看到延遲資料包到達的增量，則會增加高水位線。在呼叫過程中，高位數的此值將保持不變。此值會增加至設定中定義的最大值。以類似的方式，終端網關觀察接收到的早期資料包的數量。如果這些資料包開始頻繁使用網關，則降低低水位標籤。此值在呼叫期間保持不變。抖動緩衝區的這種模式稱為「自適應模式」，其中終端網關根據流量模式調整其抖動緩衝區。另一種模式是「固定模式」。在固定模式中，低水位標籤和高水位標籤有一個初始值。此值基於估計的接收延遲(請參閱本文檔的show voice call <port-number>部分)。

有關抖動緩衝區的更多詳細資訊，請參閱瞭解資料包語音網路（Cisco IOS平台）中的抖動。

確定延遲和抖動

本節介紹如何識別網路中的抖動。

show call active voice

show call active voice brief 命令提供有關正在進行的對話的大量資訊。此輸出顯示從此命令中學習到的一些要點：

11E4 : 2170927hs.1 +600 pid:10 Answer 1000 active
dur 00:08:43 tx:26157/522967 rx:7044/139565
Tele 3/0/0:9: tx:151310/755/0ms g729r8 noise:-62 acom:0 i/0:-56/-48 dBm
11E4 : 2171198hs.1 +329 pid:20 Originate 2000 active
dur 00:08:43 tx:7044/139565 rx:26165/523127
IP 30.30.30.29:18682 rtt:51ms pl:148590/290ms lost:0/0/15 delay:65/60/132ms g729r8

從show call active voice brief命令輸出中，您會看到電話支路(rx:7044)上接收到的任何內容都會傳輸到IP支路(tx:7044)。轉送到電話線路(26157)的IP分支(26165)上收到的資料包也是如此。 IP線路上接收的封包數量與電話線路上傳輸封包數量的差異，是造成無法及時到達的延遲封包的原因。

show call active voice命令（不帶「brief」關鍵字）的輸出指向有關直接識別抖動的引數的更多詳細資訊。

GapFillWithSilence=850 ms
GapFillWithPrediction=9230 ms
GapFillWithInterpolation=0 ms
GapFillWithRedundancy=0 ms

show voice call <port-number>

show voice call port-number 命令提供有用的資訊。確保已在網關中進行控制，或者如果您已通過Telnet連線到網關，請確保已經從執行級別發出terminal monitor命令。

注意：此命令在AS5x00/AS5x50平台上不可用。

在此輸出中，Rx Delay Est(ms)的值是71。這是當前抖動緩衝區值。據此推匯出高水位線和低水位線的值。高水位線的平均初始值為70毫秒，而低水位線的平均初始值為60毫秒。設定初始值後，閘道會追蹤收到的任何早期封包或延遲封包。從這裡的輸出可以看出，預測隱藏丟棄接近250ms，而靜默隱藏為30ms。由於靜默掩蓋只是預測掩蓋的更壞情況，因此預測掩蓋總是有更高的值。對於每個預測隱藏丟棄，緩衝區溢位丟棄將會增加。

如果看到緩衝丟棄，則不一定意味著看到高水位線增加。高水位標籤是抖動緩衝區的上限。它僅在觀察到趨勢時才更改。換句話說，應該有連續的後期資料包流。這會增加抖動緩衝區。此處的輸出中顯示了此類趨勢。因此，高水位線從70毫秒增加到161毫秒。如果此值未更改（並且您仍然看到14個延遲資料包），則表明這些資料包是零星的延遲資料包，未形成趨勢。

在show call active voice命令的輸出中，留意丟失的資料包。對於每個丟失的資料包，您會看到兩個資料包順序錯誤。在Rx Non-Seq Pkts輸出中可看到這種情況。由於這不是一個正值，因此可以斷定也沒有任何丟包。

3640-6# ***DSP VOICE TX STATISTICS***
Tx Vox/Fax Pkts: 195, Tx Sig Pkts: 0, Tx Comfort Pkts: 10
Tx Dur(ms): 192070, Tx Vox Dur(ms): 388, Tx Fax Dur(ms): 0
***DSP VOICE RX STATISTICS***
Rx Vox/Fax Pkts: 9604, Rx Signal Pkts: 0, Rx Comfort Pkts: 0
Rx Dur(ms): 192070, Rx Vox Dur(ms): 191560, Rx Fax Dur(ms): 0
Rx Non-seq Pkts: 0, Rx Bad Hdr Pkts: 0
Rx Early Pkts: 0, Rx Late Pkts: 14
***DSP VOICE VP_DELAY STATISTICS***
Clk Offset(ms): 0, Rx Delay Est(ms): 71
Rx Delay Lo Water Mark(ms): 60, Rx Delay Hi Water Mark(ms): 161
***DSP VOICE VP_ERROR STATISTICS***
Predict Conceal(ms): 250, Interpolate Conceal(ms): 0
Silence Conceal(ms): 30, Retroact Mem Update(ms): 0
Buf Overflow Discard(ms): 500, Talkspurt Endpoint Detect Err: 0
***DSP LEVELS***
TDM Bus Levels(dBm0): Rx -49.9 from PBX/Phone, Tx -41.7 to PBX/Phone
TDM ACOM Levels(dBm0): +2.0, TDM ERL Level(dBm0): +11.1
TDM Bgd Levels(dBm0): -58.9, with activity being voice
***DSP VOICE ERROR STATISTICS***
Rx Pkt Drops(Invalid Header): 0, Tx Pkt Drops(HPI SAM Overflow): 0

觀察Tx Comfort Pkts和Rx Comfort Pkts。從示例輸出中可看出，連線到此路由器的電話大多保持安靜，因為您有許多Tx Comfort Pkts。同時，您沒有Rx Comfort Pkts，這意味著另一端持續說話。

將這裡的輸出與先前的命令輸出進行比較。Rx Late Pkts的數量增加（從14個增加到26個）。但是，高水位標籤值沒有增加。這表示這12個封包偶爾延遲。緩衝區溢位丟棄已增加到910毫秒。然而，由於未觀察到趨勢，高水位不會增加。

在此處的輸出中，有一個Rx Early Pkts:3.這表示封包到達時間比預期要早得多。從此處輸出中可看出，抖動緩衝器通過將低水位線從60降到51，已拉伸其自身以適應任何更早的資料包。

3640-6# ***DSP VOICE TX STATISTICS***
Tx Vox/Fax Pkts: 209, Tx Sig Pkts: 0, Tx Comfort Pkts: 11
Tx Dur(ms): 337420, Tx Vox Dur(ms): 416, Tx Fax Dur(ms): 0
***DSP VOICE RX STATISTICS***
Rx Vox/Fax Pkts: 16843, Rx Signal Pkts: 0, Rx Comfort Pkts: 1
Rx Dur(ms): 337420, Rx Vox Dur(ms): 335920, Rx Fax Dur(ms): 0
Rx Non-seq Pkts: 0, Rx Bad Hdr Pkts: 0
Rx Early Pkts: 3, Rx Late Pkts: 26
***DSP VOICE VP_DELAY STATISTICS***
Clk Offset(ms): 0, Rx Delay Est(ms): 72
Rx Delay Lo Water Mark(ms): 51, Rx Delay Hi Water Mark(ms): 161
***DSP VOICE VP_ERROR STATISTICS***
Predict Conceal(ms): 510, Interpolate Conceal(ms): 0
Silence Conceal(ms): 70, Retroact Mem Update(ms): 0
Buf Overflow Discard(ms): 910, Talkspurt Endpoint Detect Err: 0
***DSP LEVELS***
TDM Bus Levels(dBm0): Rx -51.5 from PBX/Phone, Tx -44.1 to PBX/Phone
TDM ACOM Levels(dBm0): +2.0, TDM ERL Level(dBm0): +11.9
TDM Bgd Levels(dBm0): -61.3, with activity being voice
***DSP VOICE ERROR STATISTICS***
Rx Pkt Drops(Invalid Header): 0, Tx Pkt Drops(HPI SAM Overflow): 0

在網關上配置抖動緩衝區

本文檔中介紹的QoS准則可解決語音品質波動或惡化的問題。播放延遲緩衝區的配置是網路中不正確的QoS實施的解決方法。僅將其用作停止間隙修復程式，或將其用作故障排除和縮小網路中引入的抖動問題的工具。

播放延遲模式

抖動緩衝器配置為固定模式或自適應模式。在自適應模式下，網關允許您配置抖動緩衝區的最小值、最大值和標稱值。抖動緩衝區期望資料包在標稱值範圍內到達。標稱值必須等於或大於最小值，且等於或小於最大值。緩衝區會擴展到配置的最大值。此值可擴展至1700毫秒。配置高最大值的一個問題是引入端到端延遲。選擇maximum playout-delay的值，使其不會在網路中引入不需要的延遲。以下輸出是針對自適應模式配置的抖動緩衝區的示例：

3640-6#
3640-6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
3640-6(config)#voice-port 3/0/0
3640-6(config-voiceport)#playout-delay mode adaptive
3640-6(config-voiceport)#playout-delay maximum 400
3640-6(config-voiceport)#playout-delay nominal 70
3640-6(config-voiceport)#playout-delay minimum low
3640-6(config-voiceport)#^Z
3640-6#
3640-6#
3640-6#show run | begin 3/0/0
voice-port 3/0/0
playout-delay maximum 400
playout-delay nominal 70
playout-delay minimum low
playout-delay mode adaptive
!

在固定模式下，網關會檢視已配置的標稱值。雖然它允許您為播放延遲配置最小值和最大值，但在為固定模式配置時忽略它。當處於固定模式時，高水位線值或低水位線值始終保持恆定。它基於標稱值和Rx延遲測試（毫秒）值。因此，在固定模式下，可能將值配置為200毫秒。但是，如果估計的接收延遲接近100毫秒，即表示呼叫的整個持續時間內的高水位線和低水位線被設定。

3640-6#
3640-6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
3640-6(config)#voice-port 3/0/0
3640-6(config-voiceport)#playout-delay mode fixed
3640-6(config-voiceport)#playout-delay nominal 70
3640-6(config-voiceport)#^Z
3640-6#
3640-6#
3640-6#show run | begin 3/0/0
voice-port 3/0/0
playout-delay mode fixed
playout-delay nominal 70
!

有關播放延遲配置的詳細資訊，請參閱IP語音的播放延遲增強功能。