音声 : 音声品質

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

2002 年 10 月 30 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2006 年 2 月 2 日) | フィードバック

目次


概要

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

前提条件

この文書を読む方は以下について熟知していることを前提としています。

  • パケット音声の基本設定(要件に応じて Voice over IP(VoIP)、Voice over Frame Relay(VoFR)、または Voice over ATM(VoATM)の設定)
  • 音声の優先順位付け、断片化、各種コーデック、およびコーデックの帯域幅要件についての基本的な理解

ハードウェアとソフトウェアのバージョン

この文書の情報は、すべての Cisco 音声ゲートウェイ ソフトウェアとハードウェアのバージョンを対象としています。

不規則断続音声の原因

不規則断続音声品質の原因は、ネットワーク内での音声パケットの遅延変動または損失にあります。音声パケットが宛先に到達する際に遅延が生じると、宛先ゲートウェイはリアルタイムの情報を失います。この場合、宛先ゲートウェイは未到達のパケットの内容を予測する必要があります。予測が行われると、送信された音声と異なる特性を持つ音声が受信されることになるので、受信された音声は機械的な音になります。音声パケットの遅延が受信側ゲートウェイの予測機能を超えた場合、ゲートウェイはリアルタイムのギャップを空のままにします。受信端末にそのギャップを埋めるものが何もなければ、伝送された音声の一部が失われ、結果的に不規則断続音声が生じます。不規則断続音声問題の多くは、音声パケットの遅延があまり大きくならないようにすること(それ以上に遅延が変動しないようにすること)で解決できます。Voice Activity Detection(VAD)のために音声会話の先頭部分が欠落することがありますが、これは不規則断続音声(または音声の欠落)のもう 1 つの原因です。

以降の項では、不規則断続音声の発生を最小限に抑えるための方法について説明します。これらの対策の効果をあげるには、音声ネットワークで発生するジッタが最小限にとどまることを保証する必要があります。

帯域幅要件

ジッタを最小化する対策の実施を検討する前に、まずリアルタイム音声トラフィックをサポートできるだけの十分なネットワーク帯域幅を用意する必要があります。たとえば、80 kbps の G.711 VoIP コール(64 kbps のペイロード + 16 kbps のヘッダー)は、64 kbps リンク上では十分な音声品質が得られません。これは少なくともパケットの 16 kbps(20 %)が廃棄されるためです。帯域幅要件は、圧縮に使用するコーデックによって異なります。コーデックが変わると、ペイロードとヘッダーの要件も変わります。VAD の使用も帯域幅要件に影響を与えます。Real Time Protocol(RTP)ヘッダー圧縮(cRTP)を使用する場合は、帯域幅要件がさらに低くなります。

たとえば、G729 コーデック(デフォルトで 20 バイトのペイロード)と cRTP を使用した音声コールに必要となる帯域幅は次のとおりです。

音声ペイロード + 圧縮された(RTP ヘッダー + User Datagram Protocol(UDP)ヘッダー + IP ヘッダー)+ レイヤ 2(L2)ヘッダー

=

20 バイト + 圧縮された(12 バイト + 8 バイト + 20 バイト) + 4 バイト

=

28 バイト(ヘッダー圧縮によって IP RTP ヘッダーは最大でも 4 バイトに圧縮されるため)
この結果、8 kbps コーデック レートで必要な帯域幅は 11.2 kbps となります(1 秒あたり 50 パケット)。

詳細については、「Voice over IP - コール単位の帯域幅の使用量」を参照してください。

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

音声の優先順位付けには 2 つの重要な部分があります。1 つは対象音声トラフィックの分類とマーキング、もう 1 つはマーキングされた対象音声トラフィックの優先順位付けです。次の 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 フィールドをベースとする相対的な優先順位を使用し、中間システムによってトラフィックを制御する新しいモデルです。DiffServ は RFC 2474cisco.com 以外のサイトへ移動 および RFC 2475cisco.com 以外のサイトへ移動 で定義されており、DiffServ の標準は、RFC 791cisco.com 以外のサイトへ移動 に記述されているパケット優先順位の定義についての本来の仕様に代わるものです。DiffServ では、優先順位を記録する IP パケットのビットを再配置することで、定義できる優先順位のレベルの数が増やされています。DiffServ のアーキテクチャでは、DiffServ フィールドを定義しています。これは IP V4 にある TOS バイトに代わるフィールドで、パケットの分類の他、メータリング、マーキング、シェーピング、ポリシングなどのトラフィック調整機能についての Per-Hop Behavior(PHB)を決定します。この他にも、RFC 2597cisco.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 = 即時 = 優先順位 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 優先順位ビットのマーキングを行います。次の設定は 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 バイトの上位 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(R) ソフトウェア リリース 12.2(2)T 以降でサポートされています。Cisco IOS 12.2T では IP 優先順位は使用できなくなっていますが、同じことが 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
上の例では、Access Control List(ACL; アクセス コントロール リスト)100 と一致するすべてのトラフィックが「class voip」として分類され、IP 優先順位 5、つまり IP TOS バイトの上位 3 ビットが 101 に設定されます。ACL 100 は VoIP で使用される一般的な UDP ポートと一致します。同様に、ACL 101 は H.323 シグナリング トラフィック(Transmission Control Protocol(TCP; 伝送制御プロトコル)ポート 1720)と一致します。他のトラフィックはすべて IP 優先順位 0 に設定されます。ポリシーの名前は「mqc」で、Ethernet 0/0 の着信トラフィックに適用されます。

優先順位付け

ネットワーク内のすべてのホップに(ポート/アドレス情報または TOS バイトによって)VoIP パケットを分類および識別できる能力が設定されると、これらのホップは各 VoIP パケットに対して必要な QOS を提供できるようになります。ここで、大きなデータ パケットによって音声データの伝送が阻害されないようにするため、特別な設定手法を用いたプライオリティ キューイングを実装できます。これは通常、輻輳が発生する可能性が高い低速 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 ポートと一致し、access-list 101 は H.323 シグナリング トラフィック(TCP ポート 1720)と一致します。class data1 は Web トラフィック(TCP ポート 80。ACL 102 を参照)と一致し、64 kbps が保証されます。class data2 は Telnet トラフィック(TCP ポート 23。ACL 103 を参照)と一致し、32 kbps が保証されます。デフォルト クラスは、未分類のフローに残りの帯域幅が公平に配分されるように設定されています。ポリシーの名前は「llq」で、Serial1/0 の発信トラフィックに適用されます。Serial1/0 の総帯域幅は 256 kbps です。

注:デフォルトでは、すべてのクラスの保証帯域幅と優先帯域幅の合計はインターフェイス帯域幅の 75 % よりも小さくする必要があります。このパーセンテージを変更するには、max-reserved bandwidth interface コマンドを発行します。

次の表は、それぞれの利点と制限事項による各種ソフトウェア キューイング メカニズムの比較を示しています。

ソフトウェア キューイング メカニズム
説明
利点
制限事項
先入れ先出し(FIFO)
パケットがキューに入るときの順序とキューから出て行くときの順序がまったく同じです。
設定が単純で、高速に動作する。

優先順位サービスまたは帯域幅保証を提供できない1

均等化キューイング(WFQ)
複数のキューにキューイングするハッシング アルゴリズム。一度に処理するパケットの個数を指定するために重みを使用します。IP 優先順位と DSCP の値を設定することで重みを定義します。
設定が単純。2 Mbps より低速のリンクではデフォルト。
優先順位サービスまたは帯域幅保証を提供できない1
カスタム キューイング(CQ)
トラフィックは、設定可能なキュー制限を使用して複数のキューに分類されます。キュー制限は、平均パケット サイズ、Maximum Transmission Unit(MTU; 最大伝送ユニット)、および割り当てられる帯域幅のパーセンテージに基づいて算出されます。キュー制限(バイト数)がキューごとにデキューされるので、帯域幅が統計的に割り当てられます。
数年間は使用可能で、各キューに対して概算の帯域割り当てが可能。
優先順位サービスを提供できない。帯域幅保証は概算で、キューの数に制限がある。設定が比較的難しい1
プライオリティ キューイング(PQ)
トラフィックは、高、中、通常、低の各プライオリティ キューに分類されます。高優先順位トラフィックが最初に処理され、続いて中、通常、低優先順位トラフィックの順に処理されます。
数年間は使用可能で、優先順位サービスを提供できる。
優先順位の高いトラフィックのために、優先順位の低いキューが帯域幅不足に陥る可能性がある。帯域幅保証を提供できない2
Class-Based Weighted Fair Queuing(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
  1. 音声には適していない。
  2. 音声用に保証されている帯域幅が必要。
  3. 遅延を解決する必要がある。
  4. 音声には支障ない。

シリアル化遅延

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

シリアル化遅延は音声パケットにとって最悪の形のジッタをもたらすおそれがあります。音声パケットが低速リンクで 1500 バイトのデータ パケットの処理を待つ場合、これは非常に大きな遅延につながります。データ パケットが 80 バイトであれば、次の例に示すようにシリアル化遅延は大きく異なります。

64 kbps リンクでのシリアル化遅延、1500 バイト パケットの場合 = 1500*8/64000 = 187.5 ミリ秒

64 kbps リンクでのシリアル化遅延、80 バイト パケットの場合 = 80*8/64000 = 10 ミリ秒

このように、64 kbps リンクで 1 個の 1500 バイト パケットの処理待ち状態に置かれた場合、この音声パケットは送信されるまでに最大で 187.5 ミリ秒待たなければなりません。一方、もう 1 つの音声パケットは、宛先ゲートウェイでわずか 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 に対して)断片化の値を設定します。たとえば、3 つの PVC があり、それぞれの保証帯域幅が 512 kbps、128 kbps、および 256kbps の場合は、3 つの PVC すべてに対して 160 バイトの断片化サイズを設定します(最も低速の PVC は 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 サイズよりも大きい場合は、断片化は必要ありません。たとえば、MTU が 1500 バイトの T1 リンクの場合、断片化サイズは 1920 バイトとなるため、断片化は不要です。パケットの断片化サイズは必ず VoIP パケット サイズよりも大きくなるようにしてください。また、VoIP パケットは断片化しないでください。VoIP パケットを断片化すると、コール設定が何度も行われることになり、品質上の問題が発生します。

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

リンク断片化およびインターリービング(LFI)メカニズム
説明
利点
制限事項
WFQ を使用した MTU 断片化
MTU サイズまたは IP MTU サイズを変更するインターフェイス レベルのコマンド。大きな IP パケットを指定の MTU サイズに断片化する場合に使用します。WFQ を使用して各断片の間にリアルタイム パケットがインターリーブされます。
設定が単純。
断片の再構成が受信側アプリケーションだけで行われるため、ネットワークの使用効率が悪い。断片化を適切に処理できるのが、Don't Fragment(DF)ビットが設定されていない IP パケットに限られる。プロセッサの負荷が非常に高い。推奨されない。
マルチリンク ポイントツーポイント プロトコル(MLPPP)LFI
ポイントツーポイント シリアル リンク上でまず MLPPP を設定し、次に断片化サイズをミリ秒で設定します。さらに、マルチリンク インターフェイスでインターリービングも有効にします。
パケットはリンクの一方の端で断片化され、もう一方の端で再構成される。複数のリンクを組み合せて、1 つの大きな仮想パイプとして使用することが可能。
PPP 用に設定されたリンクのみで使用可能。Cisco IOS リリース 12.1(5)T では、PPP over Frame Relay または PPP over ATM 用のソリューションもサポートされている。
フレームリレー断片化(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 の機能を設定するために、music-threshold コマンドと voice vad-time コマンドという 2 つのパラメータがあります。

music-threshold

VAD がいつアクティブになるかを制御する初期しきい値が決定されます。これを制御するには、次の例のように、voice-port で music-threshold <threshold_value> コマンドを定義します。設定可能な範囲は -70〜-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 を使用した 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 を使用した VoIP over PPP リンク」を参照してください。
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_num>」の項を参照)。

ジッタ バッファの詳細については、「パケット音声ネットワークでのジッタについて(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
上の出力から、テレフォニー区間で受信されたもの(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 ミリ秒で、無音補正廃棄は 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 となっていますが、これは予期した時間よりも早くパケットが到達したことを意味します。下の出力からわかるように、早期パケットの増加に対応するため、最低水準点が 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 での再生遅延機能の強化」を参照してください。

 

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

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


関連情報

関連トピック

その他の文書


Document ID: 20371