パケット音声が実際に標準の公衆電話交換網（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）は、64 kbpsリンクでは低く聞こえます。これは、少なくとも16 kbps(20 %)のパケットが廃棄されるためです。帯域幅要件は、圧縮に使用されるコーデックによって異なります。コーデックが変わると、ペイロードとヘッダーの要件も変わります。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つ目は、マーキングされた対象の音声トラフィックに優先順位を付けることです。ここでは、音声の分類、マーキング、優先順位付けのさまざまなアプローチについて説明します。

分類およびマーキング

VoIPパケットの帯域幅を保証するには、ネットワークデバイスが、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フィールドを定義します。パケット分類およびトラフィック調整機能（計測、マーキング、シェーピング、ポリシングなど）に関するPer-Hop Behavior(PHB)決定を行うために、IP V4のToSバイトを置き換えます。前述の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 =評論家/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 Precedence 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コールのメディアペイロードパケット（音声パケット）はすべて緊急転送(EF)ビットパターン101110に設定されています。すべてのシグナリングパケットはAFビットパターン0111111101101111111111111111110

注：ip qos dscpコマンドは、Cisco IOS®ソフトウェアリリース12.2(2)T以降でサポートされています。IP Precedenceは、Cisco IOSソフトウェアリリース12.2Tでは使用できなくなりました。ただし、ip qos dscpコマンドでも同じことができます。IP 優先順位 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 Precedence 5に設定されます。つまり、IP ToSバイトの上位3ビットが101に設定されます。ACL 100は、VoIPでが使用1の使用使用共通UDP0同様に、ACL 101 は H.323 シグナリングトラフィック（Transmission Control Protocol（TCP; 伝送制御プロトコル）ポート 1720）と一致します。その他のトラフィックはすべてIP Precedence 0で設定されます。このポリシーは「mqc」と呼ばれます。 Ethernet 0/0の着信トラフィックに適用されます。

優先順位付け

ネットワーク内の各ホップが（ポート/アドレス情報またはToSバイトを介して）VoIPパケットを分類および識別した後、これらのホップは各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 ポートと一致します。アクセスリスト101は、H.323シグナリングトラフィック（TCPポート1720）と一致します。クラスdata1は、Webトラフィック（アクセスリスト102に示されているTCPポート80）と一致し、64 kbpsを保証します。クラスdata2はTelnetトラフィック（ACL 103で確認されるTCPポート23）と一致し、32 kbpsが保証されます。デフォルトクラスは、未分類のフローに残りの帯域幅が公平に配分されるように設定されています。ポリシーは「llq」と呼ばれます。これはSerial1/0上の発信トラフィックに適用され、総帯域幅は256 kbpsです。

注：デフォルトでは、すべてのクラスの保証帯域幅と優先帯域幅の合計は、インターフェイス帯域幅の75 %未満である必要があります。max-reserved bandwidth interfaceコマンドを発行して、この割合を変更します。

次の表は、さまざまなソフトウェアキューイングメカニズムとそれぞれの利点および制限事項を比較したものです。

ソフトウェアキューイングメカニズム	説明	利点	制限
先入れ先出し（FIFO）	パケットがキューに入るときの順序とキューから出て行くときの順序がまったく同じです。	設定が単純で、高速に動作する。	優先順位サービスまたは帯域幅保証を提供できない1。
均等化キューイング（WFQ）	複数のキューにキューイングするハッシングアルゴリズム。一度に処理するパケットの個数を指定するために重みを使用します。IP 優先順位と DSCP の値を設定することで重みを定義します。	設定が簡単。2 Mbps より低速のリンクではデフォルト。	優先順位サービスまたは帯域幅保証を提供できない1。
カスタムキューイング（CQ）	トラフィックは、設定可能なキュー制限を使用して複数のキューに分類されます。キュー制限は、平均パケットサイズ、Maximum Transmission Unit（MTU; 最大伝送ユニット）、および割り当てられる帯域幅のパーセンテージに基づいて算出されます。キュー制限（バイト数）は、各キューに対してデキューされます。したがって、割り当てられた帯域幅を統計的に提供します。	数年間利用できる。異なるキューに対してのおおよその帯域幅を割り当てることができます。	優先順位サービスは不可能です。帯域幅の保証は概算です。キューの数は限られています。設定が比較的難しい1。
プライオリティキューイング（PQ）	トラフィックは、高、中、通常、および低優先度のキューに分類されます。高優先順位トラフィックが最初に処理され、続いて中、通常、低優先順位トラフィックの順に処理されます。	数年間利用できる。プライオリティサービスを提供する	優先順位の高いトラフィックは、帯域幅の優先順位の低いキューを占有します。帯域幅保証は不可能です。²
Class-Based Weighted Fair Queuing（CBWFQ）	トラフィックの分類にはモジュラ QOS CLI が使用されます。分類されたトラフィックは、予約帯域幅キューまたはデフォルトの未予約キューに置かれます。スケジューラは重みに基づいてキューを処理するため、帯域幅保証が満たされます。	プライオリティキューがない点以外は LLQ と同じ。設定は単純で、帯域幅保証を提供できる。	優先サービスは不可能です。³
プライオリティキュー均等化キューイング（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 が使用され、プライオリティキューも設定できます。分類されたトラフィックは、プライオリティキュー、予約帯域幅キュー、またはデフォルトの未予約キューに置かれます。スケジューラは重みに基づいてキューを処理するため、優先順位トラフィックが最初に送信され（輻輳時にはポリシングされた一定のレートに制限される）、帯域幅保証が満たされます。	設定が簡単。複数のクラスのトラフィックに優先順位を提供し、優先帯域幅の利用率に上限を設けることが可能。また、帯域幅が保証されたクラスとデフォルトクラスを設定できる。	複数のレベルのプライオリティを提供するメカニズムは、まだ存在しません。すべてのプライオリティトラフィックは同じプライオリティキューを介して送信されます。プライオリティクラスを別々に設定すると、輻輳中に別々の優先度の帯域幅の上限を設定できます。ただし、アプリケーション間でプライオリティキューを共有すると、ジッタが発生する可能性があります。⁴

音声には適していません。
音声に保証された帯域幅が必要
遅延の対処が必要です。
音声に十分です。

シリアル化遅延

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

シリアル化遅延は音声パケットにとって最悪の形のジッタをもたらすおそれがあります。音声パケットが低速リンクで1500バイトの大きなデータパケットの後ろで待機する必要がある場合、これは大きな遅延に変換されます。データパケットが80バイトの場合、シリアル化遅延は大きく異なります（次の例を参照）。

1500バイトのパケットによる64 kbpsリンクでのシリアル化遅延= 1500*8/64000 = 187.5 ms。
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サイズより大きい場合、フラグメンテーションは必要ありません。たとえば、1500バイトのMTUを持つT1リンクの場合、フラグメントサイズは1920バイトです。したがって、フラグメンテーションは必要ありません。パケットの断片化サイズは必ず VoIP パケットサイズよりも大きくなるようにしてください。VoIPパケットをフラグメント化しないでください。VoIP パケットを断片化すると、コール設定が何度も行われることになり、品質上の問題が発生します。

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

リンク断片化およびインターリービング（LFI）メカニズム	説明	利点	制限
WFQ を使用した MTU 断片化	MTU サイズまたは IP MTU サイズを変更するインターフェイスレベルのコマンド。大きな IP パケットを指定の MTU サイズに断片化する場合に使用します。WFQ を使用して各断片の間にリアルタイムパケットがインターリーブされます。	設定が簡単。	フラグメントは、受信側アプリケーションによってのみ再構成されます。そのため、ネットワークの非効率的な使用が可能です。フラグメンテーションを適切に処理できるのは、フラグメント化不可(DF)ビットが設定されていないIPパケットだけです。プロセッサの負荷が非常に高い。推奨されない。
マルチリンクポイントツーポイントプロトコル（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ミリ秒待機してから送信を停止します。送信を再開すると、現在の音声と一緒に前の5ミリ秒の音声が含まれます。周辺雑音によって音声とバックグラウンドノイズの区別が妨げられる場合、VAD はコールに対して自動的に無効になります。ただし、帯域幅に問題がなければ、VADをオフにします。

VAD パラメータの調整

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

music-threshold

VADがいつアクティブになるかを制御する初期しきい値が決定されます。これは、次の例に示すように、音声ポートでmusic-threshold threshold_valueコマンドを定義することによって制御されます。この値の範囲は、-70 Decibels Per Milliwatt(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の設定の詳細については、『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 設定例

この例（設定の関連するセクションのみを含む）では、ポイントツーポイントフラクショナルT1コントローラ（12チャネル）に対してQoSを設定する必要があると仮定します。任意の時点で最大4つの同時音声コールが存在します。設定作業には、PPPカプセル化を使用してこのシリアルインターフェイスを設定し、マルチリンクグループの一部にし、マルチリンクインターフェイス（同じマルチリンクグループに属する）を作成し、マルチリンクインターフェイス上のすべてのQoSを設定します。VoIP over PPPの設定の詳細については、『Quality of Service（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 ～ 16 kbps)で最適に動作します。高ビットレートコーデック(32 ～ 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)に送信されていることがわかります。テレフォニーレッグ(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でゲートウェイに接続されている場合は、execレベルでterminal monitorコマンドを発行したことを確認します。

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

この出力では、Rx Delay Est(ms)の値は71です。これは現在のジッタバッファの値です。この結果、最高水準点と最低水準点の値が推定されます。最高水準点の標準的な初期値は 70 ミリ秒で、最低水準点の標準的な初期値は 60 ミリ秒です。初期値が設定されると、ゲートウェイは受信された早期パケットまたは遅延パケットの追跡を開始します。この出力からわかるように、予測補正ドロップは250ミリ秒に近く、無音補正は30ミリ秒です。無音補正は予測補正の最悪のケースであるため、予測補正の値は常に高くなります。予測補正廃棄が起こるたびに、バッファオーバーフロー廃棄も増えます。

バッファ廃棄が表示される場合は、必ずしも最高水準点の増加が表示されるとは限りません。最高水準点は、ジッタバッファの上限です。これは、傾向が観察された場合にのみ変化します。つまり、遅延パケットの継続的なフローがあるはずです。その結果、ジッタバッファが増加します。この出力には、このような傾向が存在します。したがって、ハイウォータマークが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.これは、パケットが予想される前に到着することを意味します。この出力からわかるように、Jitterバッファは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 での再生遅延機能の強化」を参照してください。