トラブルシューティング：QoS 不規則断続音声問題
内容
はじめに
パケット音声が実際に標準の公衆電話交換網（PSTN）電話サービスと置き換わるには、パケット音声の受信品質が基本電話サービスの品質と同等のものになることが必要です。つまり、常に高品質の音声伝送が必要となります。他のリアルタイム アプリケーションと同様に、パケット音声も広帯域幅を使用し、遅延の影響を受けやすい性質があります。伝送された音声が受話者にとって明瞭になる（不規則に変化したり、途切れたりしない）ためには、音声パケットの廃棄、過度の遅延、または遅延の変動（ジッターとも呼ばれる）が起こらないようにする必要があります。 このドキュメントでは、断続的な音声の問題のトラブルシューティングに役立つ、Quality of Service（QOS）のさまざまな考慮事項について説明します。断続的な音声の問題の主な原因は、音声パケットの損失と遅延にあります。
前提条件
要件
このドキュメントの読者は、次の項目を知っている必要があります。
-
パケット音声(VoIP、Voice over Frame Relay(VoFR)、またはVoice over ATM(VoATM)の基本設定（要件による）
-
音声の優先順位付け、断片化、各種コーデック、およびコーデックの帯域幅要件についての基本的な理解
使用するコンポーネント
このドキュメントの情報は、すべてのCisco音声ゲートウェイのソフトウェアとハードウェアのバージョンに適用されます。
このマニュアルの情報は、特定のラボ環境に置かれたデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、使用前にその潜在的な影響について確実に理解しておく必要があります。
表記法
表記法の詳細については、『シスコ テクニカル ティップスの表記法』を参照してください。
音声が不規則に断続する原因
不規則断続音声品質の原因は、ネットワーク内での音声パケットの遅延変動または損失にあります。音声パケットが宛先に到達する際に遅延が生じると、宛先ゲートウェイはリアルタイムの情報を失います。この場合、宛先ゲートウェイは、失われたパケットの内容を予測する必要があります。この予測により、受信した音声は送信した音声と同じ特性を持たなくなります。これにより、ロボットのような音声が受信されます。音声パケットの遅延が受信側ゲートウェイの予測機能を超えた場合、ゲートウェイはリアルタイムのギャップを空のままにします。受信側でギャップを埋めるものが何もない場合、送信される音声の一部が失われます。その結果、音声が途切れるようになります。不規則断続音声問題の多くは、音声パケットの遅延をあまり取らない（それ以上に可変遅延を取らない）ようにすることで解決します。 音声アクティビティ検出(VAD)によって、音声会話にフロントエンドクリッピングが追加されることがあります。これは、途切れる（または途切れる）音声のもう1つの原因です。
このドキュメントのさまざまなセクションでは、不規則断続音声の発生を最小限に抑える方法について説明します。これらの対策の効果をあげるには、音声ネットワークで発生するジッタが最小限にとどまることを保証する必要があります。
帯域幅要件
ジッタを最小化するための対策を検討する前に、リアルタイム音声トラフィックをサポートするのに十分なネットワーク帯域幅をプロビジョニングします。たとえば、80 kbpsのG.711 VoIPコール（64 kbpsペイロード+ 16 kbpsヘッダー）では、少なくとも16 kbps(20 %)のパケットが廃棄されるため、64 kbpsリンク上では音質が悪くなります。帯域幅要件は、圧縮に使用されるコーデックによって異なります。コーデックが変わると、ペイロードとヘッダーの要件も変わります。VADの使用も帯域幅要件に影響します。Real Time Protocol（RTP）ヘッダー圧縮（cRTP）を使用する場合は、帯域幅要件がさらに低くなります。
たとえば、cRTPでG.729コーデック（デフォルトの20バイトペイロード）を使用する音声コールに必要な帯域幅は、次のようになります。
-
音声ペイロード+圧縮(RTPヘッダー+ユーザデータグラムプロトコル(UDP)ヘッダー+ IPヘッダー)+レイヤ2ヘッダー
=
-
20バイト+圧縮（12バイト+ 8バイト+ 20バイト）+ 4バイト
これは次のようになります。
-
ヘッダー圧縮により、IP RTPヘッダーが最大4バイトに減らされるため、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 2474 と RFC 2475 で定義されているように、DiffServ 規格により、RFC 791 で説明されているパケット優先度を定義する元の仕様が置き換えられます。
DiffServ では、優先順位を記録する IP パケットのビットを再配置することで、定義できる優先順位のレベルの数が増やされています。DiffServのアーキテクチャでは、DiffServフィールドを定義しています。これはIP V4のToSバイトに代わるもので、パケットの分類と、メータリング、マーキング、シェーピング、ポリシングなどのトラフィック調整機能に関するPer-Hop Behavior(PHB)を決定します。前述のRFCに加えて、RFC 2597では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 =即時=優先順位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
この2つのセクションでは、分類とマーキングを行う2つの方法について説明します。
音声ダイヤルピアによるパケットの分類とマーキング
Cisco VoIPゲートウェイでは、通常、音声ダイヤルピアを使用してVoIPパケットを分類し、IP Precedenceビットをマーキングします。次の設定は、IP Precedenceビットをマーキングする方法を示しています。
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バイトの上位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
上記の例では、dial-peer voice 100 voipコマンドに一致するVoIPコールについて、そのすべてのメディアペイロードパケット（音声パケット）にExpedited Forwarding（EF；緊急転送）のビットパターン101110が設定されています。すべてのシグナリングパケットはAFビットパターン011010で設定されます。
注：ip qos dscpコマンドは、Cisco IOS®ソフトウェアリリース12.2(2)Tからサポートされています。IP Precedenceは、Cisco IOSソフトウェアリリース12.2Tでは使用できなくなりました。ただし、ip qos dscpコマンドを使用しても同じ結果が得られます。IP precedence 5(101)はIP DSCP 101000にマッピングされます。詳細は、「QoS のための DSCP による 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バイトの上位3ビットが101に設定されることを意味します。ACL 100 は VoIP で使用される一般的な UDP ポートと一致します。同様に、ACL 101 は H.323 シグナリング トラフィック（Transmission Control Protocol（TCP; 伝送制御プロトコル）ポート 1720）と一致します。 その他のトラフィックはすべて、IP Precedence 0で設定されます。このポリシーは「mqc」と呼ばれます。 Ethernet 0/0の着信トラフィックに適用される
優先順位付け
ネットワーク内のすべてのホップが（ポート/アドレス情報またはToSバイトを通じて）VoIPパケットを分類および識別できるようになると、これらのホップは必要なQoSを各VoIPパケットに提供します。その時点で、大きなデータパケットが音声データ伝送に干渉しないように、プライオリティキューイングを提供する特別な手法を設定します。これは通常、輻輳の可能性が高い、低速のWANリンクで必要となります。すべての対象トラフィックがQoS要件に基づいてQoSクラスに分類されたら、インテリジェントな出力キューイングメカニズムを通じて帯域幅保証と優先順位サービスを提供します。プライオリティ キューは VoIP にとっては必須です。
注：VoIPに高い優先順位を効果的に与える任意のキューイングメカニズムを使用してください。ただし、柔軟で設定が簡単なLow Latency Queuing（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 ポートと一致します。アクセスリスト101は、H.323シグナリングトラフィック（TCPポート1720）を照合します。 クラスdata1はWebトラフィック（アクセスリスト102に示されているTCPポート80）と一致し、64 kbpsを保証します。クラスdata2はTelnetトラフィック（ACL 103に示されているTCPポート23）に一致し、32 kbpsを保証します。デフォルト クラスは、未分類のフローに残りの帯域幅が公平に配分されるように設定されています。このポリシーは「llq」と呼ばれます。 これは、合計帯域幅が256 kbpsのSerial1/0の発信トラフィックに適用されます。
注：デフォルトでは、すべてのクラスの保証帯域幅と優先帯域幅の合計は、インターフェイス帯域幅の75 %未満である必要があります。このパーセンテージを変更するには、max-reserved bandwidth interfaceコマンドを発行します。
次の表では、さまざまなソフトウェアキューイングメカニズムとそれぞれの利点と制限を比較しています。
| ソフトウェア キューイング メカニズム | 説明 | 利点 | 制限事項 |
|---|---|---|---|
| 先入れ先出し（FIFO） | パケットがキューに入るときの順序とキューから出て行くときの順序がまったく同じです。 | 設定が単純で、高速に動作する。 | 優先順位サービスまたは帯域幅保証を提供できない1。 |
| 均等化キューイング（WFQ） | 複数のキューにキューイングするハッシング アルゴリズム。一度に処理するパケットの個数を指定するために重みを使用します。IP 優先順位と DSCP の値を設定することで重みを定義します。 | 設定が簡単。2 Mbps より低速のリンクではデフォルト。 | 優先順位サービスまたは帯域幅保証を提供できない1。 |
| カスタム キューイング（CQ） | トラフィックは、設定可能なキュー制限を使用して複数のキューに分類されます。キュー制限は、平均パケット サイズ、Maximum Transmission Unit（MTU; 最大伝送ユニット）、および割り当てられる帯域幅のパーセンテージに基づいて算出されます。キュー制限（バイト数）は、各キューに対してデキューされます。そのため、割り当てられた帯域幅が統計的に提供されます。 | 数年間は利用可能です。異なるキューに対して概算の帯域幅を割り当てることができます。 | 優先サービスは実行できません。帯域幅保証は概算です。キューの数には制限があります。設定が比較的難しい1。 |
| プライオリティ キューイング（PQ） | トラフィックは、高、中、通常、および低のプライオリティキューに分類されます。高優先順位トラフィックが最初に処理され、続いて中、通常、低優先順位トラフィックの順に処理されます。 | 数年間は利用可能です。優先サービスを提供する | 優先順位の高いトラフィックは、優先順位の低いキューの帯域幅を使い果たします。帯域幅の保証はありません。2 |
| クラスベース重み付け均等化キューイング（CBWFQ） | トラフィックの分類にはモジュラ QOS CLI が使用されます。分類されたトラフィックは、予約帯域幅キューまたはデフォルトの未予約キューに置かれます。スケジューラは重みに基づいてキューを処理するため、帯域幅保証が満たされます。 | プライオリティ キューがない点以外は LLQ と同じ。設定は単純で、帯域幅保証を提供できる。 | 優先サービスは実行できません。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 が使用され、プライオリティ キューも設定できます。分類されたトラフィックは、プライオリティ キュー、予約帯域幅キュー、またはデフォルトの未予約キューに置かれます。スケジューラは重みに基づいてキューを処理するため、優先順位トラフィックが最初に送信され（輻輳時にはポリシングされた一定のレートに制限される）、帯域幅保証が満たされます。 | 設定が簡単。複数のクラスのトラフィックに優先順位を提供し、優先帯域幅の利用率に上限を設けることが可能。また、帯域幅が保証されたクラスとデフォルト クラスを設定できる。 | 複数レベルのプライオリティを提供するメカニズムはまだなく、すべてのプライオリティトラフィックは同じプライオリティキューを介して送信されます。輻輳時には、プライオリティクラスごとに異なる優先帯域幅の上限を設定できます。ただし、アプリケーション間でプライオリティキューを共有すると、ジッタが発生する可能性があります。4 |
-
音声には適していません。
-
音声用に保証された帯域幅が必要です。
-
遅延に対処する必要があります。
-
音声には十分です。
シリアル化遅延
キューイングが最適に動作し、音声トラフィックを優先する場合でも、プライオリティキューが空になり、別のクラスからのパケットが処理されることがあります。保証された帯域幅クラスからのパケットは、設定された重みに基づいて処理される必要があります。優先順位の高い音声パケットが処理されている間にこれらのパケットが出力キューに到着すると、音声パケットは送信前にかなりの時間待機する可能性があります。音声パケットが大きなデータ パケットの処理を待たなければならないときに、シリアル化遅延が発生します。
シリアル化遅延は音声パケットにとって最悪の形のジッタをもたらすおそれがあります。音声パケットが低速リンク上の1500バイトのデータパケットの後ろで待機する必要がある場合、これは非常に大きな遅延につながります。データパケットが80バイトの場合、次の例に示すように、シリアル化遅延は大きく異なります。
-
64 kbpsリンクでのシリアル化遅延（1500バイトのパケットによる）= 1500*8/64000 = 187.5ミリ秒
-
80バイトのパケットによる64 kbpsリンクでのシリアル化遅延= 80*8/64000 = 10ミリ秒。
したがって、64 kbpsリンク上で単一の1500バイトパケットの後に音声パケットがスタックした場合、音声パケットは送信前に最大187.5ミリ秒待機する必要がある可能性があります。一方、別の音声パケットは、宛先ゲートウェイで10ミリ秒だけ待機する必要があります。これによってパケット間の遅延に差異が生じ、非常に大きなジッタが発生することになります。発信元ゲートウェイでは、通常、音声パケットは20ミリ秒ごとに送信されます。エンドツーエンドの遅延バジェットが 150 ミリ秒で、厳しいジッタ要件が必要とされる場合、180 ミリ秒を超えるギャップは許容されません。
1つの伝送ユニットのサイズが10ミリ秒未満になるようにフラグメンテーションのメカニズムを導入する。シリアル化遅延が 10 ミリ秒を超えるパケットはすべて、10 ミリ秒のチャンクに断片化します。10ミリ秒のチャンク（断片）とは、リンク経由で10ミリ秒で送信されるバイト数です。次の例に示すように、リンク速度を使用してサイズを計算します。
-
断片化サイズ = (0.01 秒 * 64,000 bps) / (8 ビット/バイト) = 80 バイト
80 バイトのパケットまたは断片を 64 kbps リンクで送信するには 10 ミリ秒かかります。
1 つの物理インターフェイス上に複数の ATM または フレームリレー Permanent Virtual Circuit（PVC; 相手先固定回線）がある場合は、使用可能な帯域幅が最も小さい PVC に基づいて（すべての PVC に対して）断片化の値を設定します。たとえば、保証帯域幅が512 kbps、128 kbps、および256 kbpsの3つのPVCがある場合、3つすべてのPVCのフラグメントサイズを160バイトに設定します（最低の速度は、160バイトのフラグメントサイズを必要とする128 kbps）。 リンク速度が異なる場合は、次の値が推奨されます。
Link Speed (kbps) Fragmentation Size (bytes) 56 70 64 80 128 160 256 320 512 640 768 960 1024 1280 1536 1920
注：フラグメントサイズがリンクMTUサイズよりも大きい場合は、フラグメンテーションは不要です。たとえば、MTUが1500バイトのT1リンクの場合、フラグメントサイズは1920バイトです。したがって、フラグメンテーションは必要ありません。パケットの断片化サイズは必ず VoIP パケット サイズよりも大きくなるようにしてください。VoIPパケットをフラグメント化しないでください。VoIP パケットを断片化すると、コール設定が何度も行われることになり、品質上の問題が発生します。
現在使用可能なリンク断片化およびインターリービング メカニズムは 3 種類あります。パケット ネットワークで生じる各種遅延の詳しい説明については、「パケット音声ネットワークでの遅延について」を参照してください。次の表に、それぞれの利点と制限事項を示します。
| リンク断片化およびインターリービング（LFI）メカニズム | 説明 | 利点 | 制限事項 |
|---|---|---|---|
| WFQ を使用した MTU 断片化 | MTU サイズまたは IP MTU サイズを変更するインターフェイス レベルのコマンド。大きな IP パケットを指定の MTU サイズに断片化する場合に使用します。WFQ を使用して各断片の間にリアルタイム パケットがインターリーブされます。 | 設定が簡単。 | フラグメントは、受信側アプリケーションによってのみ再構成されます。したがって、ネットワークの非効率的な使用です。フラグメント化を適切に処理できるのは、Do not Fragment(DF)ビットが設定されていないIPパケットだけです。プロセッサの負荷が非常に高い。推奨されない。 |
| マルチリンク ポイントツーポイント プロトコル（MLPPP）LFI | ポイントツーポイントシリアルリンクでは、最初にMLPPPを設定し、次にフラグメンテーションサイズをms単位で設定する必要があります。さらに、マルチリンク インターフェイスでインターリービングも有効にします。 | パケットはリンクの一方の端で断片化され、もう一方の端で再構成される。複数のリンクを組み合せて、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ミリ秒待機します。伝送を再開すると、現在の音声とともに直前の5ミリ秒の音声が含まれます。周辺雑音によって音声とバックグラウンド ノイズの区別が妨げられる場合、VAD はコールに対して自動的に無効になります。ただし、帯域幅に問題がない場合は、VADをオフにします。
VAD パラメータの調整
VADの機能を決定するパラメータは2つあります。music-thresholdコマンドとvoice vad-timeコマンドがあります。
music-threshold
VADがいつアクティブになる必要があるかを決定する初期しきい値が決定されます。これを制御するには、この例に示すように、音声ポートにmusic-threshold threshold_value コマンドを定義します。この値の範囲は–70 dBm(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
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 kbpsであると仮定しています。保証される Committed Information Rate（CIR; 認定情報レート）は、PVC 100 では 64 kbps、PVC 200 では 192 kbps です。PVC 100は、データと音声の両方の伝送に使用されます。PVC 200はデータ伝送にのみ使用されます。同時に最大4つの音声コールが存在します。両方のPVCで、最も低い帯域幅の音声PVC（音声を伝送するPVC）のCIRに基づいてフラグメンテーションを設定します。 このドキュメントの例から判断すると、フラグメンテーションサイズはPVC 100のCIR(64 kbps)に基づいて決定されます。 「シリアル化遅延」セクションの表に示されているように、64 kbpsリンクの場合、80バイトのフラグメンテーションサイズが必要です。PVC 200 にも同じ断片化サイズを設定する必要があります。
VoIP over Frame Relayの設定の詳細については、『QoS（フラグメンテーション、トラフィックシェーピング、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 設定例
この例（設定の関連セクションのみを含む）では、ポイントツーポイントフラクショナルT1コントローラ（12チャネルを持つ）にQoSを設定する必要があると仮定しています。 同時に最大4つの音声コールが存在します。設定作業には、シリアルインターフェイスでのPPPカプセル化の設定、マルチリンクグループへのシリアルインターフェイスの追加、（同じマルチリンクグループに属する）マルチリンクインターフェイスの作成、マルチリンクインターフェイス上での全QoSの設定が含まれます。VoIP over PPPの設定の詳細については、『QoS（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が設定されている場合）、またはホストに対して再生されるDual Tone MultiFrequency(DTMF)トーンの再生成によって処理されます。
音声パケットの補正方法には、予測補正と無音補正があります。予測補正は前のパケットと次のパケット（使用可能な場合）に基づいて行われます。 低ビットレートコーデック(5 kbps ～ 16 kbps)で最適に動作します。 高ビットレートコーデック(32 kbps ～ 64 kbps)の音声パケットが失われると、予測補正が不十分になる可能性があります。予測補正は、遅延が少なく頻度が低い場合、またはパケット損失の数が少ない場合に開始されます。予測補正がなされ過ぎると、機械的な音声品質になる可能性があります。無音補正は予測補正の最悪の形です。これは予測に使用できる情報がない場合に行われます。無音補正は単なる背景の隠蔽に過ぎません。遅延が大きく、パケット損失の数が多い場合に開始されます。無音補正が多すぎると、音声の品質が不安定になります。予測補正は 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レッグで受信されたパケットの数とテレフォニーレッグで送信されたパケットの数の違いは、時間内に到着しない遅延パケットによるものです。
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接続している場合は、execレベルでterminal monitorコマンドを発行したことを確認してください。
注：このコマンドはAS5x00/AS5x50プラットフォームでは使用できません。
この出力では、Rx Delay Est(ms)の値は71です。これは現在のジッタバッファ値です。最高水準点と最低水準点の値がこれによって推定されます。最高水準点の標準的な初期値は 70 ミリ秒で、最低水準点の標準的な初期値は 60 ミリ秒です。初期値が設定されると、ゲートウェイは受信された早期パケットまたは遅延パケットの追跡を開始します。次の出力からわかるように、予測補正廃棄はほぼ250 msで、無音補正は30 msです。無音補正は予測補正の最悪のシナリオであるため、予測補正の値は常に高くなります。予測補正廃棄が起こるたびに、バッファ オーバーフロー廃棄も増えます。
「buffer discard」が表示された場合、必ずしも最高水準点の上昇を意味しているわけではありません。最高水準点はジッタバッファの上限です。これは、傾向が観察された場合にのみ変更されます。つまり、遅延パケットの継続的なフローが存在する必要があります。その結果、ジッタバッファが増加します。次の出力では、そのような傾向が見られます。したがって、最高水準点は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 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ミリ秒まで延長できます。最大値を高い値に設定した場合の問題として、エンドツーエンド遅延の発生があります。再生遅延の最大値は、ネットワークに不要な遅延が発生しない範囲で選択してください。次の出力は、適応モードに設定されたジッタバッファの例です。
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 Delay Est (ms) 値に基づきます。したがって、固定モードでは、値を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 !
再生遅延設定の詳細については、「Voice over IP での再生遅延機能の強化」を参照してください。
関連情報
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
1.0 |
22-Feb-2002 |
初版 |
フィードバック