音声 : 音声品質

トラブルシューティング:QoS 不規則断続音声問題

2015 年 11 月 26 日 - 機械翻訳について
その他のバージョン: PDFpdf | ライター翻訳版 (2002 年 10 月 30 日) | 英語版 (2015 年 8 月 22 日) | フィードバック


目次

VAD

概要

パケット音声が実際に標準の公衆電話交換網(PSTN)電話サービスと置き換わるには、パケット音声の受信品質が基本電話サービスの品質と同等のものになることが必要です。 これは常に高品質の音声伝送が必要となることを意味します。 他のリアルタイム アプリケーションと同じように、パケット音声も高帯域幅を使用し、遅延の影響を受けやすい性質があります。 伝送された音声が受話者にとって明瞭になる(不規則に変化したり、途切れたりしない)ためには、音声パケットの廃棄、過度の遅延、または遅延の変動(ジッターとも呼ばれる)が起こらないようにする必要があります。 このドキュメントは、不規則断続音声問題のトラブルシューティングに役立つ、Quality of Service(QOS)のさまざまな考慮事項について説明しています。 不規則断続音声問題の主な原因は音声パケットの損失と遅延にあります。

前提条件

要件

このドキュメントの読者は、次の項目を知っている必要があります。

  • パケット音声(VoIP、Voice over Frame Relay (VoFR)または要件による Voice over ATM (VoATM))の基本設定。

  • 音声の優先順位付け、断片化、各種コーデック、およびコーデックの帯域幅要件についての基本的な理解

使用するコンポーネント

この文書に記載されている情報はすべての Cisco 音声 ゲートウェイにソフトウェア および ハードウェア バージョンを加えます。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。 対象のネットワークが実稼働中である場合には、どのような作業についても、その潜在的な影響について確実に理解しておく必要があります。

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

音声が不規則に断続する原因

不規則断続音声品質の原因は、ネットワーク内での音声パケットの遅延変動または損失にあります。 音声パケットが宛先に到達する際に遅延が生じると、宛先ゲートウェイはリアルタイムの情報を失います。 このイベントでは、宛先ゲートウェイは抜けていたパケットのコンテンツが可能性のあるである場合もあるもの予測する必要があります。 予測は送信された音声と同じ特性を持っていない受け取った 音声の原因となります。 これはそれがロボットに鳴る受け取った 音声の原因となります。 音声パケットの遅延が受信側ゲートウェイの予測機能を超えた場合、ゲートウェイはリアルタイムのギャップを空のままにします。 受電端でそのギャップをいっぱいにすることを何もによって伝送されたスピーチの一部分は失われます。 これは途切れた音声という結果に終ります。 途切れた音声問題の多数は音声パケットが非常に遅れないことの確認によって解決され、(それよりもっと、可変的に遅らせられない)。 時々、Voice Activity Detection (VAD)は音声メッセージ交換にフロント エンド クリッピングを追加します。 これはとぎれとぎれの(または切られる)音声のもう一つの原因です。

この資料のさまざまなセクションは途切れた音声の例を最小に する方法を示します。 これらの対策の効果をあげるには、音声ネットワークで発生するジッタが最小限にとどまることを保証する必要があります。

帯域幅要件

ジッタを最小に するための手段を適用することを考える前にリアルタイム音声トラフィックをサポートするために十分なネットワーク帯域幅を提供して下さい。 たとえばパケット廃棄されるので、80 キロビット/秒 G.711 VOIPコール(64 キロビット/秒 ペイロード + 16 キロビット/秒 ヘッダ)は低い(20%である)の少なくとも 16 キロビット/秒が 64 キロビット毎秒リンクを鳴ります。 帯域幅の要求は圧縮に使用するコーデックに基づいて変わります。 コーデックが変わると、ペイロードとヘッダーの要件も変わります。 VAD の使用方法はまた帯域幅の要求に影響を与えます。 Real Time Protocol(RTP)ヘッダー圧縮(cRTP)を使用する場合は、帯域幅要件がさらに低くなります。

たとえば、cRTP が付いている G.729 コーデック(デフォルト 20バイト ペイロード)を使用して音声コールに必要な帯域幅がこれのようです:

  • 音声ペイロードは + (RTP ヘッダ + User Datagram Protocol (UDP; ユーザ データグラム プロトコル) ヘッダ + IP ヘッダー) +Layer 2 ヘッダを圧縮しました

=

  • 20 バイトは + (12 バイト + 8 バイト + 20 バイト) + 4 バイトを圧縮しました

これは匹敵します:

  • ヘッダー圧縮が最大 4 バイトに IP RTPヘッダーを減らすので、28 バイト。 この結果、8 kbps コーデック レートで必要な帯域幅は 11.2 kbps となります(1 秒あたり 50 パケット)。

詳細については、『VoIP - コール単位の帯域幅の使用量』を参照してください。

音声トラフィックの優先順位

音声の優先順位付けには 2 つの重要な部分があります。 第 1 はで関連 音声トラフィックを分類し、マークします。 第 2 はマーク付き関連 音声トラフィックに優先順位をつけています。 ここの 2 つのサブセクションは論議し、分類にさまざまなアプローチを、優先順位をつける音声マークします。

分類とマーキング

VOIPパケットのための帯域幅を保証するために、ネットワークデバイスはそのすべての IP トラフィックのパケットを識別それを通るフローできる必要があります。 ネットワーク デバイスは VoIP パケットを識別するために、IP ヘッダー内の送信元および宛先 IP アドレス、または UDP ヘッダー内の送信元および宛先 UDP ポート番号を使用します。 この識別およびグループ化プロセスは分類と呼ばれます。 それは QoS を提供するための基礎です。

パケット分類は集中的なプロセッサである場合もあります。 従って、分類は可能な限り ネットワークのエッジの方にされた同様に遠い必要があります。 それでもすべてのホップがパケットの処理について決定を下す必要があるため、ネットワークのコアではより単純で効率的な分類方法を使用する必要があります。 この単純な分類方法は、IP ヘッダーの Type of Service(TOS; サービス タイプ)バイトをマーキングまたは設定することで実現されています。 TOS バイトの上位 3 ビットのことを IP 優先順位ビットと呼びます。 現在ほとんどのアプリケーションおよびベンダーが、これら 3 ビットの設定と認識をサポートしています。 また、マーキング機能の発展により、TOS バイトの上位 6 ビット(Differentiated Services Code Point(DSCP)と呼ばれる)も使用可能になっています。 詳細については、Request for Comments(RFC; コメント要求)を参照してください。

Differentiated Services(DiffServ; 差別化サービス)とは、TOS フィールドをベースとする相対的な優先順位を使用し、中間システムによってトラフィックを制御する新しいモデルです。 RFC 2474RFC 2475 で定義されているように、DiffServ 規格により、RFC 791 で説明されているパケット優先度を定義する元の仕様が置き換えられます。leavingcisco.com leavingcisco.com leavingcisco.com DiffServ では、優先順位を記録する IP パケットのビットを再配置することで、定義できる優先順位のレベルの数が増やされています。 DiffServ アーキテクチャは DiffServ フィールドを定義します。 それはパケット分類についての Per-Hop Behavior (PHB)デシジョンおよびメータリング、マーキング、シェーピングおよびポリシングのようなトラフィック調節機能を作るために IP V4 の TOS バイトを置き換えます。 以前に述べられた RFC に加えて、RFC 2597 はleavingcisco.com Assured Forwarding (AF)クラスを定義します。 これは DSCP フィールドの内訳です。 DSCP の詳細については、『DSCP による QOS ポリシーの実装』を参照してください。

TOS バイト- P2 P1 P0 T3 T2 T1 T0 CU

IP 優先順位: 3 ビット(P2-P0)、TOS: 4 ビット(T3-T0)、CU: 1 ビット

DiffServ フィールド- DS5 DS4 DS3 DS2 DS1 DS0 ECN ECN

DSCP: 6 ビット(DS5-DS0)、ECN: 2 ビット

XXX00000 ビット 0、1、2(DS5、DS4、DS3)は、優先順位ビットです。内容は次のとおりです。

  • 111 = ネットワーク制御 = 優位 7

  • 110 = インターネットワーク コントロール = 優位 6

  • 101 = CRITIC/ECP = 優位 5

  • 100 = フラッシュオーバーライド = 優位 4

  • 011 = フラッシュする = 優位 3

  • 010 = Immediate = Precedence 2

  • 001 = Priority = Precedence 1

  • 000 = Routine = Precedence 0

000XXX00 ビット 3、4、5(DS2、DS1、DS0)は、遅延、スループット、および信頼性を表すビットです。

  • ビット 3 = 遅延[D] (0 = 標準; 1 = 下位)

  • ビット 4 = スループット[T] (0 = 標準; 1 = 高)

  • ビット 5 = 信頼性[R] (0 = 標準; 1 = 高)

000000XX ビット 6、7: ECN

これら二つのセクションは分類 および マーキングが行われる 2 つの方法を論議します。

音声ダイヤルピアによるパケットの分類とマーキング

Cisco VOIPゲートウェイによって、通常音声 ダイヤル ピアを VOIPパケットを分類し、IP 優先順位 ビットをマークするのに使用します。 この設定は IP 優先順位 ビットをマークする方法を示します:

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

上述の例では、一致するどの VOIPコールでも dial-peer voice 100 voip コマンド IP 優先順位 5.と設定 される 音声ペイロード パケットすべてがあります。 これは IP TOS バイトの 3 つの最上位ビットが 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

上述の例では、一致するどの VOIPコールでも dial-peer voice 100 voip コマンド Expedited Forwarding (EF) ビット 構成 101110 と設定 されるメディア ペイロード パケット(音声パケット)すべてがあります。 すべてのシグナリング パケットは AF ビット 構成 011010 と設定 されます。

注: ip qos dscp コマンドは Cisco IOS 以来サポートされますか。 ソフトウェア リリース 12.2(2)T。 IP 優先順位は Cisco IOS ソフトウェア リリース 12.2T.でもはや利用できません ただし、同じは ip qos dscp コマンドによって実現します。 IP 優先順位 5 (101) IP DSCP 101000 へのマップ。 詳細は、「QoS のための DSCP による VoIP シグナリングとメディアの分類」を参照してください。

モジュラ QOS CLI によるパケットの分類とマーキング

分類およびマーキングには、モジュラ QOS CLI を使用することが推奨されます。 これはポリシーから分類を分けるテンプレート ベース の 設定方法です。 これは複数の QoS 機能が複数のクラスのために同時に設定されるようにします。 さまざまなマッチ基準に基づいて各クラスかに起こるどんな必要性判別するトラフィックおよび policy-map コマンドを分類する class-map コマンドを使用して下さい。 service-policy コマンドの発行によってインターフェイスの着信/発信 トラフィックにポリシーを適用して下さい。 この設定例はパケットを分類したり示すのに Modular 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

Access Control List (ACL) 100 と一致するこの設定例では、どのトラフィックでも「クラス voip」および IP 優先順位 5.のセットとして分類されます。 これは IP TOS バイトの 3 つの最上位ビットが 101 に設定 されることを意味します。 ACL 100 は VoIP で使用される一般的な UDP ポートと一致します。 同様に、ACL 101 は H.323 シグナリング トラフィック(Transmission Control Protocol(TCP; 伝送制御プロトコル)ポート 1720)と一致します。 他のトラフィックはすべて IP 優先順位 0 と設定 されます。 ポリシーは「mqc」と呼ばれます。 それはイーサネット 0/0 の着信トラフィックに適用されます。

優先順位付け

ネットワークの各ホップが VOIPパケットを分類し、識別(によるポート/アドレス情報または TOS バイト)できた後、それらのホップは必須 QoS をそして各 VOIPパケットに与えます。 その時、プライオリティ キューイングを大きいデータパケットが音声データ データ伝送によって干渉しないことを確かめるために提供する特別な手法を設定して下さい。 輻輳の高い 可能性があるより遅い 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

一致するこの例では、どのトラフィックでも「クラス voip」として ACL 100 分類されます(意味音声トラフィック)。 それは高優先順位 32 キロビット/秒まで与えられます。 ACL 100 は VoIP で使用される一般的な UDP ポートと一致します。 Access-list 101 は H.323 シグナリングトラフィック(1720) TCPポートと一致します。 クラスdata1 一致 Webトラフィック(アクセス リスト 102)および保証に見られるように TCPポート 80 64 キロビット/秒。 クラスdata2 は Telnetトラフィック(ACL 103 に見られるように TCPポート 23)および保証と 32 キロビット/秒一致します。 デフォルト クラスは、未分類のフローに残りの帯域幅が公平に配分されるように設定されています。 ポリシーは「llq」と呼ばれます。 それは 256 キロビット/秒の全帯域幅がある Serial1/0 のアウトゴーイングトラフィックに適用されます。

注: デフォルトで、すべてのクラスのための総保証された 帯域幅および優先順位 帯域幅はインターフェイス 帯域幅の 75%より小さい必要があります。 max-reserved bandwidth interface コマンドの発行によってこのパーセントを修正して下さい。

この表はそれぞれ利点 および 制限と異なるソフトウェア キューイング機構を比較します。

ソフトウェア キューイング メカニズム 説明 利点 制限事項
先入れ先出し(FIFO) パケットがキューに入るときの順序とキューから出て行くときの順序がまったく同じです。 設定が単純で、高速に動作する。 優先順位サービスまたは帯域幅保証を提供できない1。
均等化キューイング(WFQ) 複数のキューにキューイングするハッシング アルゴリズム。一度に処理するパケットの個数を指定するために重みを使用します。 IP 優先順位と DSCP の値を設定することで重みを定義します。 設定が簡単。 2 Mbps より低速のリンクではデフォルト。 優先順位サービスまたは帯域幅保証を提供できない1。
カスタム キューイング(CQ) トラフィックは、設定可能なキュー制限を使用して複数のキューに分類されます。 キュー制限は、平均パケット サイズ、Maximum Transmission Unit(MTU; 最大伝送ユニット)、および割り当てられる帯域幅のパーセンテージに基づいて算出されます。 キュー制限は各キューのために(バイトの総計で)削除されます。 従ってそれは割り当てられた帯域幅を統計的に提供します。 ずっと数年の間利用可能です。 それは異なるキューのためのおおよそ帯域割り当てを可能にします。 優先サービスは可能性のあるではないです。 帯域幅保証はおおよそです。 キューの限られた数があります。 設定が比較的難しい1。
プライオリティ キューイング(PQ) トラフィックは高く、中間、正常に、および低い優先順位キュー分類されます。 高優先順位トラフィックが最初に処理され、続いて中、通常、低優先順位トラフィックの順に処理されます。 ずっと数年の間利用可能です。 それは優先サービスを提供します。 高優先順位トラフィックは帯域幅の低優先順位キューを飢えさせます。 帯域幅保証は possible.2 ではないです
Class-Based Weighted Fair Queuing(CBWFQ) トラフィックの分類にはモジュラ QOS CLI が使用されます。 分類されたトラフィックは、予約帯域幅キューまたはデフォルトの未予約キューに置かれます。 スケジューラは重みに基づいてキューを処理するため、帯域幅保証が満たされます。 プライオリティ キューがない点以外は LLQ と同じ。 設定は単純で、帯域幅保証を提供できる。 優先サービスは possible.3 ではないです
プライオリティ キュー均等化キューイング(PQ-WFQ)(IP RTP プライオリティとも呼ばれる) 1 つのインターフェイス コマンドを使用して、指定範囲内の偶数ポート番号を宛先とするすべての UDP パケットに優先順位サービスを提供します。 コマンドが 1 つだけで設定が単純。 RTP パケットに優先順位サービスを提供できる。 他のトラフィックはすべて WFQ で処理される。 Real-Time Conferencing Protocol(RTCP)トラフィックは優先順位付けされない。 帯域幅保証を提供できない4。
LLQ(旧称 Priority Queue Class-Based Weighted Fair Queuing(PQCBWFQ)) トラフィックの分類にはモジュラ QOS CLI が使用され、プライオリティ キューも設定できます。 分類されたトラフィックは、プライオリティ キュー、予約帯域幅キュー、またはデフォルトの未予約キューに置かれます。 スケジューラは重みに基づいてキューを処理するため、優先順位トラフィックが最初に送信され(輻輳時にはポリシングされた一定のレートに制限される)、帯域幅保証が満たされます。 設定が簡単。 複数のクラスのトラフィックに優先順位を提供し、優先帯域幅の利用率に上限を設けることが可能。 また、帯域幅が保証されたクラスとデフォルト クラスを設定できる。 優先順位の複数のレベルをまだ提供するメカニズムは同じプライオリティキューを通してすべての優先順位トラフィック 送信 されません。 別々のプライオリティクラスは輻輳の間に別々の上部優先順位 帯域幅境界がある場合があります。 ただし、アプリケーション間のプライオリティキューの共有は可能性としては jitter.4 を導入できます

  1. 音声のために適しなかった。

  2. 音声のために保証される帯域幅を必要とします。

  3. 処理されたである必要レイテンシー。

  4. 音声のために十分。

シリアル化遅延

キューイングが推奨ではたらいて、も音声トラフィックに優先順位をつける、プライオリティキューが空である別のクラスからのパケットが保守される時があり。 保証された 帯域幅クラスからのパケットは設定されたウエイトに基づいていました保守する必要があります。 これらのパケットが保守されている間優先順位 音声パケットが出力キューで着けば、音声パケットは送信 される前にかなりの時間を待つ場合があります。 音声パケットが大きなデータ パケットの処理を待たなければならないときに、シリアル化遅延が発生します。

シリアル化遅延は音声パケットにとって最悪の形のジッタをもたらすおそれがあります。 音声パケットが 1500 バイトが、低速リンクで巨大な遅延に、これ変換すると大きいデータパケットの後ろで待たなければならなければ。 シリアライゼーション の 遅延はデータパケットが 80 バイトならこの例に示すように著しく異なります、:

  • 1500 バイト パケット = 1500*8/64000 による 64 キロビット毎秒リンクのシリアライゼーション の 遅延 = 187.5 ミリ秒

  • 80bytes パケット = 80*8/64000 による 64 キロビット毎秒リンクのシリアライゼーション の 遅延 = 10 ミリ秒

従って、音声パケットは可能性としては 64 キロビット毎秒リンクの単一 1500 バイト パケットの後ろでスタックしている得る場合送信 される前に 187.5 ms まで待たなければなりません。 一方では、別の音声パケットは宛先ゲートウェイで 10 ms だけ待たなければなりません。 これによってパケット間の遅延に差異が生じ、非常に大きなジッタが発生することになります。 発信ゲートウェイで、音声パケットは通常 20 ミリ秒毎に送信されます エンドツーエンドの遅延バジェットが 150 ミリ秒で、厳しいジッタ要件が必要とされる場合、180 ミリ秒を超えるギャップは許容されません。

1 つの通話単位のサイズは 10 ミリ秒より小さいことを確認するフラグメンテーションのメカニズムをもたらして下さい シリアル化遅延が 10 ミリ秒を超えるパケットはすべて、10 ミリ秒のチャンクに断片化します。 10 ms チャンクかフラグメントは氏がリンク速度/リンク スピードの使用によってサイズを計算する 10 のリンクにこの例に示すように、送信 される バイト数です:

  • 断片化サイズ = (0.01 秒 * 64,000 bps) / (8 ビット/バイト) = 80 バイト

80 バイトのパケットまたは断片を 64 kbps リンクで送信するには 10 ミリ秒かかります。

1 つの物理インターフェイス上に複数の ATM または フレームリレー Permanent Virtual Circuit(PVC; 相手先固定回線)がある場合は、使用可能な帯域幅が最も小さい PVC に基づいて(すべての PVC に対して)断片化の値を設定します。 たとえば 512 キロビット/秒の保証された 帯域幅がある 3 PVC があれば、128 キロビット/秒および 256 キロビット/秒は 160 バイトのフラグメントサイズで、そして 3 PVC をすべて設定します(160-byte フラグメントサイズを必要とする)低速は 128 キロビット/秒です。 これらの値は異なるリンク速度のために推奨されます:

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パケットをフラグメント化しないで下さい。 VoIP パケットを断片化すると、コール設定が何度も行われることになり、品質上の問題が発生します。

現在使用可能なリンク断片化およびインターリービング メカニズムは 3 種類あります。 パケット ネットワークで生じる各種遅延の詳しい説明については、「パケット音声ネットワークでの遅延について」を参照してください。 この表は利点 および 制限をリストしたものです:

リンク断片化およびインターリービング(LFI)メカニズム 説明 利点 制限事項
WFQ を使用した MTU 断片化 MTU サイズまたは IP MTU サイズを変更するインターフェイス レベルのコマンド。 大きな IP パケットを指定の MTU サイズに断片化する場合に使用します。 WFQ を使用して各断片の間にリアルタイム パケットがインターリーブされます。 設定が簡単。 フラグメントは受信側アプリケーションによってだけ再構成行います。 従って、ネットワークの非能率的な使用。 の IP パケットだけ(設定 されない DF)ビットをフラグメンテーションをうまく処理できますフラグメント化しません。 プロセッサの負荷が非常に高い。 推奨されない。
マルチリンク ポイントツーポイント プロトコル(MLPPP)LFI ポイントツーポイントシリアルリンクで、MLPPP は最初に設定する必要がありますそしてフラグメンテーションサイズはインターリービングがまたマルチリンクインターフェイスで有効に する必要がある氏で設定 する必要があります。 パケットはリンクの一方の端で断片化され、もう一方の端で再構成される。 複数のリンクを組み合せて、1 つの大きな仮想パイプとして使用することが可能。 PPP 用に設定されたリンクのみで使用可能。 PPP over Frame Relay のためのソリューションか PPP over ATM はまた Cisco IOS ソフトウェア リリース 12.1(5)T またはそれ以降でサポートされます。
フレームリレー断片化(FRF.12) フレームリレー PVC 上で frame-relay traffic-shaping コマンドを有効にし、map-class のもとで断片化サイズを設定します。 パケットは PVC の一方の端で断片化され、もう一方の端で再構成される。 frame-relay traffic-shaping コマンドが有効になっているフレームリレー PVC のみで使用可能。

VAD

普通の音声会話にはいくつかの無音期間があります。 典型的な音声メッセージ交換は 40 から 50 パーセントの無音状態で構成されています。 音声コールの 40 % の間はネットワーク上を音声がまったく通過していないため、VAD を導入することで帯域幅をかなり節約できます。 VAD を使って、ゲートウェイ外観スピーチのギャップのために。 それはコンフォート ノイズ(バックグラウンドノイズ)とそれらのギャップを取り替えます。 従って、帯域幅の量は保存されます。 しかし、VAD には二律背反的な問題があります。 コーデックが無音の期間までに続かれるスピーチ アクティビティを検出する前に、少ない時間が(ミリ秒の順で)あります。 この短い時間が原因で、受信した音声の先頭部分で欠落が起こります。 アクティベーションを非常に短い一時停止の間に避け、クリッピングを補正するために、VAD は伝達を停止する前にスピーチが停止した後およそ 200 ms を待っています。 伝達を再起動した上で、現在のスピーチと共にスピーチの前の 5 ms が含まれています。 周辺雑音によって音声とバックグラウンド ノイズの区別が妨げられる場合、VAD はコールに対して自動的に無効になります。 ただし帯域幅が問題でなかったら、VAD を消して下さい。

VAD パラメータの調整

VAD の機能を定める 2 つのパラメータがあります。 これらは music-threshold および voice vad-time コマンドです。

music-threshold

支配する VAD がアクティブになる必要があるとき最初 の しきい値は決定されます。 これはこの例に示すように音声ポートの music-threshold threshold_value コマンドの定義によって、制御されます。 これのための範囲はミリワット(dBm)毎に -70 デシベルから -30 dBm にです。 これのデフォルト値は -38 dBm です。 低い値(-70 dBm 付近)に設定すると、かなり低い信号強度で VAD がアクティブになります(音量が相当低くならない限り、無音とは見なされません)。 高い値を設定することは音声 信号強度の小さいドロップするのためにアクティブになる VAD という結果に(-30 dBm に近い方に)終ります。 それはより頻繁にコンフォートノイズパケットをするために再生を駆動します。 ただし、これは時々オーディオのマイナーなクリッピングの原因となります。

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

voice vad-time

VAD がアクティブになれば、バックグラウンドノイズおよびコンフォート ノイズのコンポーネントはこの例に示すようにグローバルコンフィギュレーションの下の voice vad-time timer_value コマンドの設定によって、制御されます。 これは、無音を検出してから、音声パケットの送信を抑制するまでの遅延時間(ミリ秒)です。 このホールドオーバー時間のデフォルト値は 250 ミリ秒です。 これは 250 ミリ秒以内に、コンフォート ノイズが始まることを意味します。 "のタイマーの有効範囲は 250~65,536 ミリ秒です。" 高い 値がこれのために設定される場合、コンフォート ノイズは大いにあとで始まります(バックグラウンドノイズはされ続けます)。 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 キロビット/秒であることが(設定の関連セクションだけ含まれている)ではこの例、仮定されます。 保証される Committed Information Rate(CIR; 認定情報レート)は、PVC 100 では 64 kbps、PVC 200 では 192 kbps です。 PVC 100 がデータおよび音声を両方伝送するのに使用されています。 PVC 200 がデータしか伝送しないのに使用されています。 最大いつでも存在 する 4 つの同時音声コール。 最も低い帯域幅音声 PVC の CIR に基づいて両方の PVC のフラグメンテーションを設定して下さい(PVC 運送音声)。 この資料の例に基づいて、それはフラグメンテーションサイズが(64 キロビット/秒である)に基づいて PVC 100's CIR 決定されることを意味します。 Serialization Delay セクションの表に示すように、64 キロビット毎秒リンクのために、80 バイトのフラグメンテーションサイズが必要となります。 PVC 200 にも同じ断片化サイズを設定する必要があります。

VoIP over Frame Relay の設定についての更に詳しい情報については、Quality of Service (フラグメンテーション、トラフィック シェーピング、LLQ/IP RTP プライオリティ)の VoIP over Frame Relay を参照して下さい。

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

VoIP Over PPP - QOS 設定例

QoS が設定される 12 のチャネルを備えている)用のポイントツーポイント フラクショナルT1 コントローラ(必要があることが(設定の関連セクションだけ含まれている)ではこの例、仮定されます。 最大いつでも存在 する 4 つの同時音声コール。 コンフィギュレーション タスクは PPP カプセル化を使ったこのシリアルインターフェイスを設定し、それに一部をマルチリンク グループのし、(同じマルチリンク グループに属する)マルチリンクインターフェイス作成し、マルチリンクインターフェイスですべての QoS を設定することを含みます。 PPP 上の VoIP の設定についての更に詳しい情報については、QoS を実装した PPP リンク上での VoIP (LLQ/IP RTP プライオリティ、LFI、cRTP)を参照して下さい。

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
!

ジッタと再生メカニズム

受け取った 音声パケットの一層の遅延 および ジッタの方に貢献するネットワークにいくつかの自由なエンティティが常にあります。 終端ゲートウェイのジッタ バッファの修正によって制御されないジッタは音声ネットワークで解決されます。

再生メカニズム

ジッタ バッファは時間バッファです。 終端ゲートウェイによって再生 メカニズムをより有効にさせることを提供します。 これは再生 メカニズムの機能図です:

/image/gif/paws/20371/troubleshoot_qos_voice1.gif

再生コントロールは音声パケットを受信すると、RTP タイムスタンプを分析します。 音声パケットの遅延がジッタ バッファの収容力を超えている場合、そのパケットは即座に廃棄されます。 パケットがバッファリング機能の範囲内にある場合、そのパケットはジッタ バッファに格納されます。 ジッタ バッファ内でのパケットの位置は、そのパケットについて算出された RTP タイムスタンプによって決まります。 イベントでは利用可能 な 音声パケットが、プレイアウト制御それを隠すことを試みますありません(抜けていたパケットを予測します)。 VAD が有効に なる場合、コンフォート ノイズはされます。

再生コントロールの役割は、損失パケット、重複パケット、破損パケット、および順序外パケットの発生時にそれらのパケットを処理することです。 これらのイベントは小刻みに動かされた音声パケットを一直線に並べる時間までに処理されコンフォート ノイズ(VAD が設定されれば)、また更にホストに展開されるべき再生 Dual Tone Multifrequency (DTMF)トーンを再生します。

音声パケットの補正方法には、予測補正と無音補正があります。 予測補正は前のパケットと次のパケット(使用可能な場合)に基づいて行われます。 それは低いビットレート コーデック(5 キロビット/秒から 16 キロビット/秒)の推奨をはたらかせます。 高いビットレート コーデック(32 キロビット/秒から 64 キロビット/秒)のための音声パケットの損失は悪い予測隠蔽という結果に可能性としては終る場合があります。 予測隠蔽はパケットロスの低く、まれな遅延または少し数があると開始します。 予測補正がなされ過ぎると、機械的な音声品質になる可能性があります。 無音補正は予測補正の最悪の形です。 これは予測に使用できる情報がない場合に行われます。 無音補正は単なる背景の隠蔽に過ぎません。 それはパケットロスの高い遅延およびより多くの数があると開始します。 たくさんの無音隠蔽は途切れがちな音声品質の原因となります。 予測補正は 30 ミリ秒まで有効で、それ以上になると無音補正が作動します。

ジッタ バッファ

ジッタ バッファは最高水準点と最低水準点によって範囲が定められています。 最高水準点とは、音声を時間どおりに再生するためにパケットの到達が予期される時間範囲の上限です。 最高水準点を過ぎてから到達したパケットは、遅延パケットまたは損失パケットとしてマークされます。 最低水準点とは、音声を時間どおりに再生するためにパケットの到達が予期される時間範囲の下限です。 低ウォーターマークが早いパケット(それみなされる前に着くパケットはまだ時間通りに展開することができます)と。

終端ゲートウェイが到達故なパケットの増分を見続ける場合最高 水準点を増加します。 最高 水準点のこの値はコールの期間全体変わりません。 これは設定で定義される最大まで増加します。 同じような方法で、終端ゲートウェイは受信される早いパケットの数を監視します。 これらのパケットがゲートウェイに度々行き始める場合低ウォーターマークを減らします。 この値はコールの期間全体変わりません。 ジッタ バッファのこのモードは「適応性があるモードと終端ゲートウェイはトラフィックパターンに基づいてジッタ バッファを適応させますところで言われます」。 その他に「固定モード」があります。 固定 モードでは、低ウォーターマークおよび最高 水準点の 1 つの初期値があります。 この値は推定受信遅延に基づいています(この資料の 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 送信されます)に。 同じはテレフォニー レグに転送される IP レグで受信されるパケットにあてはまます(26165) (26157)。 IP レグで vs テレフォニー レグで送信される時間にそれを作らない遅いパケットにパケットの数受け取ったパケットの数の違いは貢献されます。

show call active voice コマンドのこの出力(「簡潔な」キーワードなしで)、直接ジッタを識別するパラメータについての更に詳しい情報へのポイント。

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

show voice call <port-number>

show voice call port-number コマンドは有用な情報を提供します。 ゲートウェイでコンソール接続を行われることを確かめて下さいまたはゲートウェイに Telneted、exec レベルからの terminal monitor コマンドを発行するために確かめて下さい。

注: このコマンドは AS5x00/AS5x50 プラットフォームでは使用できません。

この出力では、Rx 遅延米国東部標準時刻(ms)の値は 71 です。 これは現在のジッタ バッファ値です。 最高 水準点および低ウォーターマークの値はこれで推論されます。 最高水準点の標準的な初期値は 70 ミリ秒で、最低水準点の標準的な初期値は 60 ミリ秒です。 初期値が設定されると、ゲートウェイは受信された早期パケットまたは遅延パケットの追跡を開始します。 出力でここに見られるように、予測隠蔽ドロップは無音隠蔽は 30 ミリ秒であるが、250 ms に密接です 無音隠蔽が予測隠蔽のただのより悪いケースのシナリオであるので予測隠蔽の高い値が常にあります。 予測補正廃棄が起こるたびに、バッファ オーバーフロー廃棄も増えます。

バッファ 廃棄を見る場合、最高 水準点の増加を見ることを必ずしも意味します。 最高 水準点はジッタ バッファの上限です。 それは傾向が観察されるときだけ変更します。 すなわち、連続的 な フロー故なパケットがあるはずです。 これはジッタ バッファの増加という結果に終ります。 ここの出力では、そのような傾向はあります。 従って、最高 水準点は 70 ミリ秒から 161 ミリ秒まで増加します。 それでも 14 の遅いパケットを見る場合変更されなければこの値が(、そして)、これらが傾向を形成しない散発的遅いパケット、であることを意味します。

show call active voice コマンドの出力から、失われたパケットのために検知 して下さい。 各失われたパケットに関しては、順序が狂ってある 2 つのパケットを見ます。 これは 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 多くの慰め Pkts があるのでこのルータに接続される電話が大抵沈黙を保つことが完了されます。 同時に、Rx ゼロ慰め Pkts があります、つまりもう一方の端が絶えず話すことを意味します。

前のコマンド 出力と出力をここに比較して下さい。 Rx 遅い Pkts の増加数があります(14 から 26)への。 ただし、最高水準点の値に増分がありません。 これは 12 のパケットが散発的に遅れることを示します。 バッファ オーバーフロー の 廃棄は 910 ミリ秒まで高められます。 ただし、観察される傾向がないので最高 水準点は増加しません。

ここの出力では、Rx 早い 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 までミリ秒を拡張できます。 最大値を高い値に設定した場合の問題として、エンドツーエンド遅延の発生があります。 再生遅延の最大値は、ネットワークに不要な遅延が発生しない範囲で選択してください。 この出力は適応性があるモードのために設定されるジッタ バッファの例です:

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
!

固定モードでは、ゲートウェイは設定された公称値を参照します。 それは playout-delay のための最小および最大値を設定することを可能にするが固定 モードのために設定されたとき無視されます。 固定 モードで、最高水準点の値か低ウォーターマーク値は一定している常に残ります。 その値は公称値と Rx Delay Est (ms) 値に基づきます。 従って固定 モードの下で、200 ミリ秒で値を設定することは可能性のあるです。 ただし、推定受信遅延が最高 水準点および低ウォーターマークがコールの全体の期間の間に設定 されるものである 100 ms に密接である場合。

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
!

再生遅延設定の詳細については、「Voice over IP での再生遅延機能の強化」を参照してください。

関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報


Document ID: 20371