文檔ID:21662

已更新:2008年2月15日

下載PDF

列印

意見回饋

相關產品

- QoS 封包標記

- H.323

目錄

簡介

必要條件

需求

採用元件

慣例

背景資訊

H.323

視訊會議流量的特徵描述

容量規劃

範例案例

確定每個呼叫的頻寬消耗

H.323音訊

H.323視訊

分類

選擇花式排隊機制

模型/優先順序方案

語音和影片是否應該共用LLQ?

CAC

流量調節

與H.323終端互通

示例配置

相關資訊

相關思科支援社群討論

簡介

H.323是IP網路中多媒體會議具有全球接受度的標準。本文討論用於在具有相對低速鏈路的企業WAN上為H.323視訊會議實施服務品質(QoS)的工具。

必要條件

需求

本文檔的讀者應瞭解以下主題：

- 符合H.323標準的系統的元件。元件包括但不限於終端、網關、網守、多點控制器(MC)、多點處理器(MP)和多點控制單元(MCU)。 請參閱白皮書：在思科網路中部署H.323應用以瞭解詳細資訊。

- Cisco H.323視訊會議解決方案，包括MCU和閘道器，以及多媒體會議管理員(MCM)閘道管理員和代理。請參閱本文檔的「相關資訊」部分，獲取思科視訊會議解決方案相關資訊的連結。

- H.323區域設計。H.323端點組出現在區域中，這是類似於域名系統(DNS)的管理便利。 每個區域都有一個管理所有端點的網守。

- 撥號計畫。請參閱第5章：Cisco AVVID解決方案、IP電話的撥號方案架構和配置：Cisco CallManager版本3.0(5)瞭解更多資訊。

- 呼叫准入控制(CAC)技術，包括通過資源預留協定(RSVP)發出資源需求信令。

採用元件

本文件所述內容不限於特定軟體和硬體版本。

慣例

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

背景資訊

目前，大多數網路支援以下一種或多種影片流量型別：

影片型別

流量特徵

視訊會議

即時、雙向、小型組頻寬：每個使用者的一個或多個流

影片點播

單向、點對點（拉模型）頻寬：每個使用者一個流

廣播影片（已計畫）

單向、一對多（推送模式）頻寬：一個流到無限使用者（IP組播）

同時，許多企業會檢查現有而且通常是單獨的資料、語音和影片網路基礎架構，以確定在IP基礎架構中將這些網路融合在一起的最有效方法。在這些融合網路中，QoS在網路中的任何潛在擁塞點都是強制性的。QoS確保延遲和丟棄敏感流量、即時影片和語音可以暢通無阻地通過（相對於允許丟棄的資料應用）。尤其是，QoS在廣域網邊緣路由器上至關重要。在那裡，數百兆位潛在流量匯聚成千位或低兆位/秒範圍內的低速鏈路。

H.323

許多IP視訊會議應用都使用H.323協定套件。國際電信聯盟(ITU)H.323定義了IP多媒體的國際標準。ITU於1996年批准了H.323標準的第一版。目前的版本是4。許多應用程式現在通常部署基於LAN的H.323影片系統。例如，Microsoft NetMeeting利用H.323進行視訊會議和共用合作。

以前，以H.320為基礎的視訊會議系統很常見。每個系統都有自己的公共交換電話網(PSTN)連線。如本節中圖左側所示，現在您可以使用影片網關在融合的H.323網路和傳統影片網路之間進行通訊。右圖顯示如何使用影片終端介面卡在H.323網路中無縫連結各個H.320終端。

視訊會議流量的特徵描述

與語音不同，影片具有非常高且極其可變的資料包速率，其平均最大傳輸單位(MTU)要高得多。 下圖顯示了視訊會議流量的典型資料包大小細分：

視訊會議流量流包括兩種型別的幀，如圖所示：

「I」幀是影片的完整示例。「P」和「B」幀使用經由運動向量和預測演算法的量化。

容量規劃

在網路中放置影片流量之前，請確保所有必要應用均有足夠的頻寬。首先，計算每個主要應用（例如語音、影片和資料）的最小頻寬要求。總和表示任何特定鏈路的最低頻寬要求。此數量消耗的頻寬不應超過該鏈路上總可用頻寬的75%。此75%規則假定開銷流量需要一些頻寬。開銷流量的示例包括路由協定更新和第2層keepalive以及其他應用，如電子郵件和HTTP流量。語音和影片流量佔用的鏈路容量不超過33%。以下範例案例說明融合網路上的容量規劃。

範例案例

一個站點的鏈路容量為1.544 Mbps，包含兩個影片終端，每個終端支援的最大資料速率為256 kbps。雖然兩個影片呼叫的速率等於512 kbps，但是要考慮開銷，請將該呼叫的資料速率增加20%。20%是一個保守的百分比，可確保在大多數環境中進行適當的容量規劃。您可以在一開始為開銷新增額外20%，然後根據監控結果上調或下調該值。

為優先順序隊列調配足夠的頻寬，以使兩個影片終端能夠同時通過WAN進行活動呼叫，而不會造成優先順序隊列溢位。在此示例場景中，如果新增第三個影片終端，則需要實施某種形式的CAC。

確定每個呼叫的頻寬消耗

在容量規劃中，需要瞭解的最關鍵概念之一就是您每次呼叫使用的頻寬量。本節列出每個編碼器 — 解碼器（編解碼器）使用的頻寬。如需詳細資訊，請參閱透過IP傳輸的語音 — 每次呼叫的頻寬消耗。

H.323音訊

音訊訊號包含數位化、壓縮的聲音（通常是語音）。H.323支援成熟的ITU標準音訊編解碼演算法。支援的演算法包括：

- G.711 - 3.1千赫茲(kHz),48、56和64 kbps（普通電話）

- G.722 - 7 kHz（48、56和64 kbps）

- G.728 - 3.1 kHz(16 kbps)

- G.723 - 5.3和6.3 kbps模式

選擇正確的編解碼器反映了語音品質、位元率、計算功率和訊號延遲之間的權衡。

H.323視訊

根據H.323標準，H.323終端的影片功能是可選的。但是，當您實現H.323終端時，終端必須支援H.261編解碼器，並且可選支援H.263標準。

- H.261 — 用於視聽服務的影片編解碼器，倍數為64 kbps。符合H.261標準的裝置可對初始幀進行完全編碼。然後，裝置僅對初始幀和後續幀之間的差異進行編碼，以實現最小的分組傳輸。可選的運動補償改善了影象品質。

- H.263 — 影片普通舊式電話服務(POTS)的影片編解碼器。 H.263標準是H.261標準的向後相容更新。H.263使用半畫素運動估計技術顯著提高了影象品質，這是一項要求。增強功能還來自預測的幀和哈夫曼碼表，它最佳化了低位元率傳輸。H.263標準定義了五種標準圖片格式，如文檔白皮書中的表1:在思科網路中部署H.323應用。

分類

為了向影片流量提供適當的QoS保證，網路裝置需要能夠識別此類流量。

QoS的區分服務(DiffServ)模型使用DiffServ代碼點(DSCP)值將流量分為多個類。DiffServ定義以下兩組DSCP值：

- Expedited Forwarding(EF) — 提供單個DSCP值(101110)，為標籤的資料包提供來自網路的最高級別服務。思科透過低延遲佇列(LLQ)實作EF服務。 一般來說，EF會保持高優先順序隊列非常小，以便控制延遲並防止低優先順序流量的耗竭。因此，如果隊列已滿，資料包可能會丟棄。通常，EF最適合VoIP。

- Assured Forwarding(AF) — 提供四個類，每個類具有三個丟棄優先順序級別。

有關DSCP的詳細資訊，請參閱使用DSCP實施服務品質策略。

通常，思科設計手冊建議影片採用AF41(DSCP值100010)。如果您在IP視訊會議應用中對影片流的音訊部分進行更好的處理，則沒有任何優勢。因此，在視訊會議中，使用AF41作為語音和影片媒體的DSCP值。

在第2層，可以使用IEEE 802.1p欄位中的3個服務類(CoS)位，該欄位是IEEE 802.1Q標籤的一部分。

目前，尚無標準能描述哪一個值最適合IP視訊會議。但是，思科通常建議對多服務網路採用此標籤方案：

流量型別

第2層CoS

第3層IP優先順序

第3層DSCP

語音RTP^1

5

5

EF

語音控制

3

3

AF31

視訊會議

4

4

AF41

串流視訊(IP/TV)

1

1

AF13

資料

0-2

0-2

0-AF23

1 RTP =即時傳輸協定

此表為流影片和視訊會議分配單獨的分類和標籤值。流影片具有更好的緩衝資料流和處理延遲和抖動的能力。因此，影片流需要不同的QoS級別。

此外，您還可以分離視訊會議流的控制部分和資料部分。要分離這兩個部分流，請使用AF31標籤控制元件，使用AF41標籤資料。但是，此設計不是最佳設計。並非所有終端都允許您以不同方式標籤承載和控制流量，思科代理會使用一個值標籤所有視訊會議流量。此外，相對於影片呼叫位元率，控制業務位元率可以忽略不計。

儘可能靠近源執行分類。第三方影片合作夥伴VCON、PictureTel和Polycom可以設定IP優先順序位。如果您的H.323終端未設定任何標頭值，您可以在網路中的以下點標籤封包：

- 第3層交換機埠

有關詳細資訊，請參閱配置QoS。

- Cisco IOS?使用類別型標籤的路由器

如需詳細資訊，請參閱設定類別型封包標籤。

- 使用Cisco MCM功能的Cisco IOS路由器

- 在遠端WAN路由器上運行的H.323網守/代理

選擇花式排隊機制

Cisco IOS軟體現在包含多個佇列機制。這些機制可滿足進入網路的流量型別以及流量流經的廣域媒體的需求。在園區或WAN中，當網路中出現潛在擁塞點時，必須應用適當的排隊技術。該隊列確保延遲和丟棄敏感流量（例如語音和即時影片）能夠暢通無阻地通過（相對於允許丟棄的資料應用程式）。在WAN邊緣路由器上，中斷是典型現象。在那裡，數百兆位潛在流量匯聚成千位或低兆位/秒範圍內的低速鏈路。

使用模組化QoS命令列介面(CLI)(MQC)的命令配置較新的隊列方法。 使用MQC，使用bandwidth命令指定最小頻寬保證。使用priority命令指定對介面級別隊列的嚴格優先順序出隊。bandwidth命令實施基於類的加權公平隊列(CBWFQ)，而priority命令實施LLQ。有關詳細資訊，請參閱比較QoS服務策略的頻寬和優先順序命令。

模型/優先順序方案

思科建議在多服務網路上使用此模型或優先順序方案：

資料鏈路型別

最低Cisco IOS軟體版本

分類

優先排序

LFI^1

流量調節

串列線路

Cisco IOS軟體版本12.0(7)T

語音的DSCP = EF;DSCP = AF41用於所有視訊會議流量；DSCP = AF31用於語音控制流量；其他流量類別具有唯一的分類。

含CBWFQ的LLQ

MLP^2

—

框架轉送

Cisco IOS軟體版本12.1(2)T

語音的DSCP = EF;影片的DSCP = AF41;DSCP = AF31用於語音控制流量；其他流量類別具有唯一的分類。

含CBWFQ的LLQ

FRF.12

將流量整形為CIR^3。

ATM

Cisco IOS軟體版本12.1(5)T

語音的DSCP = EF;影片的DSCP = AF41;DSCP = AF31用於語音控制流量；其他流量類別具有唯一的分類。

含CBWFQ的LLQ

使用ATM的MLP

將流量整形到有保證的頻寬部分。

ATM和框架轉送

Cisco IOS軟體版本12.1(5)T

語音的DSCP = EF;影片的DSCP = AF41;DSCP = AF31用於語音控制流量；其他流量類別具有唯一的分類。

含CBWFQ的LLQ

使用ATM和訊框中繼的MLP

將流量整形到最慢鏈路上的頻寬保證部分。

1 LFI =連結分割和交錯

2 MLP =多鏈路PPP

3 CIR =承諾資訊速率

此清單說明模式/優先順序方案的一些要點。

- 語音進入具有優先順序隊列(PQ)功能的隊列並接收48 kbps的頻寬。此隊列的入口標準是EF的DSCP值或IP優先順序值5。如果存在介面擁塞，超過48 kbps的流量將丟棄。因此，請使用准入控制機制確保流量不會超過此值。

- 視訊會議流量進入具有PQ功能的隊列，並接收呼叫資料速率的頻寬加上20%。此隊列的入口標準是DSCP值AF41或IP優先順序值4。如果存在介面擁塞，超過呼叫資料速率的流量將丟棄。因此，與語音的情況一樣，必須使用准入控制機制確保流量不會超過該值。使用Proxy進行佇列存取，尤其是如果尚未在每個交換器連線埠上設定信任。對於在僅包含少數幾個影片終端的小型站點進行的隊列訪問，請根據影片終端IP地址使用訪問控制清單(ACL)。使用ACL可以防止惡意使用者使用IP優先順序4標籤流量。此標籤會繞過網守或CAC，並影響PQ中的所有影片。

注意：單向影片流量（如IP/TV）應通過bandwidth命令使用CBWFQ。延遲容差更高。

- WAN鏈路的擁塞會完全導致語音控制信令協定的耗盡。在這種情況下，IP電話無法通過IP WAN完成呼叫。語音控制協定流量（如H.323和Skinny Client Control Protocol）要求其自己的基於類的加權公平隊列，該隊列的最小可配置頻寬等於DSCP值AF31。此DSCP值與IP優先順序值3相關。

- 系統網路架構(SNA)流量進入指定頻寬為56 kbps的佇列。此類中的排隊操作是FIFO，最小頻寬分配為56 kbps。此類中超過56 kbps的流量進入預設隊列。此隊列的入口標準可以是TCP埠號、第3層地址、IP優先順序或DSCP。

所有剩餘流量都可以進入預設隊列。如果指定頻寬，則排隊操作為FIFO。或者，如果指定關鍵字fair，則操作為加權公平隊列(WFQ)。

此外，請勿在鏈路速度小於768 kbps的情況下舉行視訊會議。在低位速率鏈路上，使用壓縮RTP(cRTP)和LFI可以減少序列化和排隊延遲的影響。

請勿將cRTP用於IP視訊會議。此清單提供了cRTP的最佳實踐：

- 僅將cRTP與低位元率語音編解碼器（如G.729）配合使用。如果將G.711用作語音或視訊會議呼叫的音訊編解碼器，則使用cRTP實現的統計吞吐量增益並不足以值得使用cRTP。

- 僅當低位元率語音佔所提供負載的重要百分比時才使用cRTP。通常，僅當低位元率語音大於電路所承受負載的30%時，此功能才有益。

- cRTP會影響轉發效能。啟用此功能後監視CPU利用率。

語音和影片是否應該共用LLQ?

多服務QoS服務策略經常考慮是否將語音和視訊會議流量配置為優先順序類別。這種考慮是因為LLQ目前支援單個嚴格優先順序隊列，即使您配置了多個類來劃分優先順序。當您使用優先順序配置VoIP和影片類時，來自這兩個類的流量將進入單個隊列。因此，以下原因可能導致您選擇不將影片放在優先順序隊列中：

- 視訊資料包比語音資料包大得多。視訊資料包通常與最大鏈路MTU大小一樣大。使用EF標籤，視訊資料包可以進入與語音相同的優先順序隊列。如果小型VoIP資料包在大型視訊資料包之後或幾個此類資料包之後進入隊列，則VoIP資料包中的延遲會增加。延遲可能很大，並且會對VoIP應用程式的效能產生負面影響。

- 由於大多數EF隊列非常小，因此當您將其用於影片流量時，它們可能導致丟包。

思科已執行將影片置於優先順序隊列中的測試。這些測試的鏈路速度大於768 kbps，並且使用了正確的CAC以避免超訂用。思科發現，在優先順序隊列中放置影片不會顯著增加語音資料包的延遲。

通常，可以選擇這些模型之一。思科已測試這兩種型號：

- 優先順序隊列中的語音、影片和音訊並相應地調配

- 優先順序隊列中的語音，頻寬隊列中的影片和音訊

第三種方法是分離視訊會議的音訊元件。換句話說，將音訊元件放在優先順序隊列中，將影片元件放在頻寬隊列中。然而，影片編碼器的編碼延遲往往比語音編碼器長。因此，如果為視訊會議的音訊流賦予絕對優先順序，則音訊流會提前到達並保留，以實現唇音同步。因此，如果您將與視訊會議關聯的語音資料包放在隊列中，使其比視訊資料包接收的服務具有更好的服務，則沒有任何優勢。

如果選擇將影片和語音放在優先順序隊列中，請使用不同的DSCP值標籤流量型別。如果使用不同的DSCP值標籤流量型別，則您可以在QoS服務策略中使用不同的優先順序語句來控制影片。特別是，影片可能需要較大的突發引數。

CAC

流量的優先化只能解決通過IP影片的QoS調配的部分難題。完整的解決方案需要CAC。

為避免網路資源超額訂閱，必須使用CAC（即頻寬控制）。對於視訊會議，如果新終端超過可用頻寬，則為了保持現有影片流的品質，必須拒絕請求網路資源的影片終端。換句話說，CAC可以保護影片不受影片的影響。

一般來說，有三種適用於影片呼叫的CAC條款方案：

- 限制影片終端的數量。特別是在沒有H.323網守的遠端站點，只有一個方法可以控制特定鏈路（例如WAN）上影片頻寬的使用。在這種情況下，您需要在物理上限制遠端站點上的影片終端的數量。在優先順序隊列中調配足夠的頻寬，以支援特定站點上所有影片終端的最大資料速率。

注意：為影片終端的最大資料速率加20%調配優先順序隊列。額外的20%允許IP和傳輸開銷。

- 使用閘道管理員CAC為每個會話設定區域間和區域內呼叫的頻寬限制。您可以將閘道管理員CAC與代理合併，代理向優先隊列提供單一存取點。這種單一接入點可防止未經授權的影片流超訂用優先順序隊列。您必須向網守註冊影片終端才能訪問Proxy。網守配置允許本地區域之外的最大影片頻寬。此最大頻寬需要與優先順序隊列的頻寬調配匹配，以確保適當的隊列功能。這些准則僅適用於中心輻射型環境。網守使用直接模式，不允許中間網守從鏈路中扣除頻寬。

- 實施您已啟用RSVP的終端。終端使用RSVP消息描述流量配置檔案並請求必要的服務。沿端到端路徑的RSVP感知網路裝置讀取這些RSVP消息，並決定是否允許保留請求。裝置通過另一個RSVP消息將其決策傳遞給端點。端點及其應用隨後決定是通過中斷會議還是通過減少要求來適應可用的網路條件。

H.323版本4標準的附錄II概述了RSVP的使用方法。主要內容如下：

- 當您發出呼叫時，端點會向網守傳達端點保留資源的能力。然後，網守指示終端資源預留嘗試是否可取。

- 在H.245階段，端點指示它們是否可以發出資源預留訊號。根據此資訊，端點決定是否繼續呼叫。

- RSVP保留消息的傳送可以在邏輯通道被開啟後發生，但可以在對資料包使用邏輯通道之前發生。

流量調節

將幀中繼用於WAN連線帶來了另一個QoS要求。具體而言，當高速中央站點饋送一個或多個低速遠端站點時，該中央站點可能會超出遠端站點的物理頻寬和CIR頻寬。為防止向遠端站點傳送過多頻寬，請在中心站點路由器上實施流量調節。有關幀中繼流量整形的詳細資訊，請參閱以下資源：

- 在7200路由器和較低平台上配置幀中繼流量調節

- 使用訊框中繼的VoIP與服務品質（分段、流量調節、LLQ/IP RTP優先順序）

與H.323終端互通

H.323視訊會議網路通常包含五個功能元件：

- 影片終端

- 網守

- 閘道

- MCU

- 代理

思科提供除影片終端以外的所有元件的產品解決方案。證據表明，Cisco H.323產品可與第三方H.323終端互操作。

在一些情況下，這些終端提供QoS工具來確保影片業務面對不可預測的資料流時的延遲和丟失引數的滿意度。例如，Polycom Viewstation會跟蹤呼叫建立後的所有視訊資料包。Polycom Viewstation報告平均延遲以及丟失的影片或音訊資料包數。此工具還支援可讀輸出的調試。這些調試有助於指示通過影片輸出分析無法檢測的問題來源。有關詳細資訊，請參閱如何為Polycom影片裝置配置IP影片文檔。

示例配置

此示例配置演示如何將LLQ應用於通過WAN鏈路的視訊會議流量：

示例配置

Sample Configuration

class-map Video-Conf

match access-group 102

class-map Streaming-Video

match access-group 103

!

policy-map QoS-Policy

class Video-Conf

priority 450 30000

class Streaming-Video

bandwidth 150

class class-default

fair-queue

!

! -- Video-Conf Traffic

access-list 102 permit ip any any dscp cs4

access-list 102 permit ip any any dscp af41

!

! -- Streaming Traffic

access-list 103 permit ip any any dscp cs1

access-list 103 permit ip any any dscp af13

建立QoS策略對映後，使用service-policy命令應用該策略。應用策略的介面型別決定命令的應用位置。以下是一些範例：

介面型別

組態範例

租用線路

line interface multilink1

service-policy output QoS-Policy

ATM PVC^1

interface atm 1/0.1 point

pvc 1/50

service-policy output QoS-Policy

訊框中繼VC^2

map-class frame-relay vcofr

frame cir 128000

frame mincir 64000

frame bc 1000

frame frag 160

service-policy output QoS-policy

註：在具有分散式QoS的Cisco 7500系列上，使用DTS^3命令。請參閱在Cisco 7500系列上使用分散式QoS的訊框中繼流量調節。

1 PVC =永久虛電路

2 VC =虛電路

3 DTS =分散式流量調節

相關資訊

- ITU H.323標準版

- 適用於H.323 VoIP閘道的通話許可控制

- Internetworking技術概述：服務品質網路

- QoS支援頁面

- 技術支援 - Cisco Systems

這份檔案是否有所幫助？ 是否

感謝您的反饋。

開啟支援問題單 (需有思科服務合約。)

相關思科支援社群討論

思科支援社群是一個論壇，供您提出和回答問題、分享建議並與同行合作。

請參閱思科技術提示慣例以瞭解有關本文中所用慣例的資訊。

已更新：2008年2月15日

文檔ID:21662