パケット音声ネットワークでのジッタについて（Cisco IOS プラットフォーム）

パケット音声ネットワークでのジッタについて（Cisco IOS プラ
ットフォーム）
目次
概要
前提条件
要件
使用するコンポーネント
表記法
パケットボイスネットワークのジッタ
ジッタの重大度を判別して下さい
ジッタの原因
カプセル化の際の考慮事項
フレームリレー環境のジッタ
結論
関連情報
概要
この文書では、ジッタについて説明し、ジッタの測定方法と補正方法を説明します。
前提条件
要件
このドキュメントの読者は次のトピックについて理解している必要があります。
Cisco 基本的な IOS 音声コンフィギュレーション
サービス品質（QoS）の基本的な知識
使用するコンポーネント
この文書の情報は、Cisco IOS 音声ゲートウェイとルータに適用できます。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべ
てのデバイスは、クリアな（デフォルト）設定で作業を開始しています。ネットワークが稼働中の場合は、コマンドが及ぼす潜
在的な影響を十分に理解しておく必要があります。
表記法
ドキュメント表記の詳細は、『シスコテクニカルティップスの表記法』を参照してください。
パケットボイスネットワークのジッタ
ジッターは、受信パケットの遅延の変動として定義されます。送信側では、パケットはパケット間隔が均一な連続ストリームと
して送信されます。ネットワークの輻輳、不適切なキューイング、または設定エラーが原因で、この安定したストリームにむら
が生じたり、各パケットの遅延が一定ではなくばらつきが生じたりすることがあります。
次の図は、パケットの安定したストリームがどのように処理されるかを示しています。
Voice over IP（VoIP）の Real-Time Protocol（RTP）音声ストリームをルータが受信する際にジッタがある場合は、それを補正
する必要があります。この機能は、再生遅延バッファというメカニズムで処理されます。再生遅延バッファでは、これらのパケ
ットをバッファ処理し、安定したストリームとして Digital Signal Processor（DSP; デジタル信号プロセッサ）に再生して、ア
ナログ音声ストリームに再変換されるようにします。再生遅延バッファはジッタ解消バッファと呼ばれることもあります。
次の図はジッタの処理方法を示しています。
パケットをこのバッファの範囲外で受信しますほどジッタが大きければ範囲外パケットは廃棄され、ドロップアウトはオーディオ
で聞かれます。 1 パケット小さい損失に関しては DSP はオーディオはあるはずで、問題は聞こえないことを考えるものを挿入し
ます。損失したパケットを DSP で補正できる範囲をジッタが超えると、聞こえる音声に問題が発生します。
次の図は過度のジッタの処理方法を示しています。
ジッタの重大度を判別して下さい
過度のジッタが発生していることは、Cisco IOS で次のステップを実行すれば確認できます。
1. コールが確立してアクティブ状態になり、ジッタが疑われる場合は、関連するゲートウェイの 1 つに Telnet で接続しま
す。
2. Telnetセッションを通してコンソールメッセージを見られます Terminal monitor が可能にして下さい。
注：コンソールポートに接続している場合、このステップは不要です。
3. show voice call summary コマンドを入力して下さい。次のような出力が表示されます。
PORT
CODEC
VAD VTSP STATE
VPM STATE
============ ======== === ==================== ======================
1/0/0
- FXSLS_ONHOOK
1/0/1
g729r8
y S_CONNECT
FXSLS_CONNECT
ジッタが発生しているコールを選択します。この例では、それは 1/0/1 です。
4. この特定のコールを表示するために show voice call コマンドを入力します。
この例では、それは show voice call 1/0/1 です。コールを処理する DSP からの出力が次のように表示されます。
1/0/1 vtsp level 0 state = S_CONNECT
vpm level 1 state = FXSLS_CONNECT
vpm level 0 state = S_UP
MS-2621-3B#
***DSP VOICE VP_DELAY STATISTICS***
Clk Offset(ms): 0, Rx Delay Est(ms): 50
Rx Delay Lo Water Mark(ms): 50, Rx Delay Hi Water Mark(ms): 7
***DSP VOICE VP_ERROR STATISTICS***
Predict Conceal(ms): 0, Interpolate Conceal(ms): 0
Silence Conceal(ms): 0, Retroact Mem Update(ms): 0
Buf Overflow Discard(ms): 0, Talkspurt Endpoint Detect Err: 0
***DSP VOICE RX STATISTICS***
Rx Vox/Fax Pkts: 1187, Rx Signal Pkts: 0, Rx Comfort Pkts: 0
Rx Dur(ms): 150200, Rx Vox Dur(ms): 23740, Rx Fax Dur(ms): 0
Rx Non-seq Pkts: 0, Rx Bad Hdr Pkts: 0
Rx Early Pkts: 0, Rx Late Pkts: 0
***DSP VOICE TX STATISTICS***
Tx Vox/Fax Pkts: 7129, Tx Sig Pkts: 0, Tx Comfort Pkts: 0
Tx Dur(ms): 150200, Tx Vox Dur(ms): 14259, Tx Fax Dur(ms): 0
***DSP VOICE ERROR STATISTICS***
Rx Pkt Drops(Invalid Header): 0, Tx Pkt Drops(HPI SAM Overflow): 0
***DSP LEVELS***
TDM Bus Levels(dBm0): Rx -54.5 from PBX/Phone, Tx -64.7 to PBX/Phone
TDM ACOM Levels(dBm0): +2.0, TDM ERL Level(dBm0): +9.9
TDM Bgd Levels(dBm0): -49.4, with activity being voice
5. 出力の*** DSP 音声 VP_ERROR 統計情報***セクションを表示して下さい。
このセクションには、注意する必要のあるパラメータがいくつかあります。主要な 1 つはバッファオーバーフロー廃棄
（ms）の数です見られる。この数字は、再生遅延バッファの範囲を超えた（廃棄された）パケットの数を示しています。
ある程度の値が表示されていても、値が継続的に増加していない限り問題はありません。 show voice call x/x/x コマンド
が繰り返されるときコールが最初に開始されるが、この値は増加するべきではありませんときいくつかのオーバーフローを
得ることは正常です。この数字は、過度のジッタを直接示しています。
デフォルトで、このバッファはジッタ提供の量に動的に調節する適応性があるモードで動作します（ある程度までは）。デ
ジッタバッファの動的挙動のためのデフォルトを変更する playout-delay コマンドを設定して下さい。このバッファは固
定モードに設定することもできます。そのようにすれば、ジッタに関する問題の一部を解決できる場合があります。詳細
については、Voice over IP のためのプレイアウト遅延機能拡張を参照して下さい。
ジッタの原因
ジッタは IPネットワークで輻輳によって普通は引き起こされます。輻輳は、ルータインターフェイスで発生する場合もあれ
ば、回線のプロビジョニングが正しく行われていない場合にプロバイダーや通信事業者のネットワークで発生する場合もありま
す。
カプセル化の際の考慮事項
回線の中でもルータインターフェイスは直接制御できる場所なので、ルータインターフェイスでジッタを探し始めるのが最も簡
単で最善の方法です。どのように見つけ出すかジッタのもとはジッタが起こるリンクのカプセル化および型によって非常に決ま
ります。一般に、ATM 回線には固定セルレートが使用されているので、正しく設定されていればジッタは発生しません。そのた
め、遅延は非常に一定しています。ジッタが ATM 環境で見られる場合、ATM 設定のチェックは必要です。 ATM が正しく動作し
ている（廃棄されたセルがない）場合は、ジッタは問題にならないと考えられます。 In Point-to-Point Protocol （PPP）カプ
セル化は、ジッタシリアライゼーションの遅延がほとんど常に原因です。この問題は、PPP リンクの『QOS を実装した PPP
リンク上での VoIP（LLQ / IP RTP プライオリティ、LFI、cRTP）』で簡単に対応できます。 PPP では、本質的に PPP のエンド
ポイント同士が、間にスイッチのネットワークを介さずに相互に直接会話します。これにより、ネットワーク管理者は関連する
すべてのインターフェイスを制御できます。
フレームリレー環境のジッタ
フレームリレー環境のジッタを発見するには、次の 3 つのパラメータに注意を払う必要があります。
トラフィックシェーピング
フラグメンテーション
キューイング
これの設定への設定例および関連情報に関しては、Quality of Service の VoIP over Frame Relay を参照して下さい。
トラフィックシェーピング
ルータから出て行くトラフィックが、通信事業者が提供する実際の Committed Information Rate（CIR; 認定情報レート）にシェ
ーピングされていることを確認する必要があります。この確認は、フレームリレー統計情報を見て、通信事業者と確認すること
によって行ってください。まず最初に、フレームリレー統計情報を見ます。 show frame-relay pvc xx コマンドを使用します。
xx には Data-link Connection Identifier（DLCI; データリンク接続識別子）の番号を指定します。次のような出力を受信しま
す。
PVC Statistics for interface Serial0/1 (Frame Relay DTE)
DLCI = 16, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/1.1
input pkts 103611
output pkts 120054
in bytes 9909818
out bytes 10962348
dropped pkts 0
in FECN pkts 0
in BECN pkts 0
out FECN pkts 0
out BECN pkts 0
in DE pkts 0
out DE pkts 0
out bcast pkts 1366
out bcast bytes 448048
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 22:45:57, last time pvc status changed 22:45:57
Queueing strategy: weighted fair
Current fair queue configuration:
Discard Dynamic Reserved
threshold queue count queue count
64
16 0
Output queue size 0/max total 600/drops 18303
fragment type end-to-end fragment size 1600
cir 20000 bc 1000 be 0 limit 125 interval 50
mincir 20000 byte increment 125 BECN response no IF_CONG no
frags 103356 bytes 9807006 frags delayed 67241 bytes delayed 7127120
shaping active
traffic shaping drops 18303
すべてのフィールドの詳細な説明は、show frame-relay pvc の説明を参照してください。
探査対象
このコマンドの出力では、フレームネットワークで輻輳が発生したかどうかを示す値に注意してください。具体的には、
Forward Explicit Congestion Notification（FECN; 順方向明示的輻輳通知）、Backward Explicit Congestion
Notification（BECN; 逆方向明示的輻輳通知）および Discard Eligible（DE; 廃棄適性）の各パラメータに注意します。入力パ
ケットはシスコが送信するパケットではないので、入力パケットだけに注意する必要があります。これらの値のうち 1 つかそれ
以上が増加している場合があります。この現象は、プロバイダーが使用するフレームスイッチのタイプと設定によって異なりま
す。大まかに言えば回線が、決してこれらの値増分を見るべきではないとフレームリレートラフィックシェーピングがあれ
ば、同じ CIR のために設定され。これらの値は増分し、回線の true CIR を一致することを見れば、フレームプロバイダーの
ネットワークの何かは正しく設定されません。
このような場合の一例として、CIR がゼロの回線を購入しているのにバースト値が設定されている場合があります。一部のプロ
バイダーでは、CIR がゼロの Permanent Virtual Circuit（PVC; 相手先固定接続）を販売しています。このような回線は、デー
タ用には問題ありませんが、音声品質に問題が発生します。ゼロ CIR 回線からのコマンド出力を検知する場合、DE または
FECN パケットの数はインプットパケットの数に匹敵します。さらに一歩進んで考えると、通信事業者が 128 kbps になるように
プロビジョニングした PVC がある場合に、ルータの CIR が 512 kbps に設定されていると、これらのカウンタが（ゆっくりと）
増加します。表示されているのは、ルータインターフェイスに着信するパケットだけで、このレートは PVC の反対側にあるル
ータに設定されたトラフィックシェーピングパラメータで制御されていることに注意してください。逆に入力されるものがト
ラフィック形成パラメータがローカルエンドで設定される他のルータに、制御します。
キャリアによって提供される PVC のための CIR を超過しないことは非常に重要ことです。この CIR より低く設定しても問題は
起こりません。ただし、それを超過すれば、輻輳が表示されます。
このように輻輳が発生するのは、フレームスイッチの特定の PVC に設定された CIR により、そのスイッチで（その PVC に）ト
ラフィックが渡されるレートが決定されるからです。実際に受信するデータレートがフレームスイッチに設定された CIR を超
えている場合は、CIR を超過したフレームをバッファ処理して、バッファ処理したパケットを転送するキャパシティが使用可能に
なるまで保持しておく必要があります。どのパケットでもフレームスイッチによってバッファリングされる DE ビットが設定か
FECN ビットが設定を得ます。
すべてが物理層で正しく機能することを常にとして、またインターフェイス統計情報を綿密に調べ、確かめるためにドロップかエ
ラーを探したいと思います。これには、show interface コマンドを使用してください。
これがジッタにどのように関連しているかこれが発生する、いくつかのパケットはリモートルータへの到達で持っていますより長
いレイテンシーをフレームネットワークでバッファリングされる必要があります場合であり。ただし、輻輳がないとき、それら
は普通期待する待ち時間に通過します。その結果、リモートルータで受信されるパケット間のデルタ時間にばらつきが生じる
ことになります。それ故に、ジッタ。
フラグメンテーション
フラグメンテーションはジッタとのよりシリアライゼーションの遅延と多くを関連付けます。ただし、特定の条件下で、それ
はジッタの原因である場合もあります。フラグメンテーションはフレームリレーマップクラスでパケット化された音声をした場
合常に設定する必要があります。このパラメータを設定すると、インターフェイスに 2 つの効果があります。最初の効果は規
定されるサイズより大きいすべてのパケットがフラグメント化することです。 2 番目の効果は、最初の効果ほど目立ちません
が、同じくらい重要です。フラグメンテーションが設定されるインターフェイスを検知すれば、このコマンドの効果を表示でき
ます。フラグメンテーションなしで、show interface x コマンドの出力で示されているキューイング戦略は First In First
Out （FIFO）キューイングが使用中であることを示します。フラグメンテーションがフレームリレーマップクラスに適用されれ
ば、このコマンドの出力はデュアル FIFO としてキューイング戦略を示したものです。このようにして、音声トラフィックに使
用されるプライオリティキューがインターフェイスに作成されます。フラグメンテーション値が QoS 資料の VoIP over Frame
Relay の Fragmentation セクションで助言される値に設定されることが強く推奨されます。推奨値でそれでもジッタに関する
問題に直面する場合、音声品質が受諾可能になるまでフラグメンテーション値をひとつずつ下げて下さい。
キューイング
このタイプの環境の VoIP トラフィックに使用するために一般に受け入れられているキューイング方式は、次の 2 つです。
IP RTP プライオリティキューイング
低遅延キューイング
これらの方式のどちらかを使用してください。両方は設定しないでください。キューイングオペレーションがドキュメントに従
って正しく検知する場合、作業きちんとおよび問題並べることが他の所であることを結論を出すことができます。キューイング
によって発生する遅延は比較的小さいので、キューイングは一般的にジッタの原因とはなりません。ただし、VOIPパケットがき
ちんとキューイングされないし、同じ回線にデータがあれば、ジッタは生じる場合があります。
結論
ジッタは音声パケットのためのパケット遅延の変化です。ある程度のジッタは、ルータ内の DSP で補正できますが、過度のジッ
タには対応できません。その結果、音声品質が劣化します。あるパケットでは回線のどこかでキューイングや遅延が発生してい
ながら、それ以外のパケットではキューイングや遅延が発生していないことが、ジッタの原因です。これにより、遅延にばらつ
きが生じます。ジッタはルータの誤設定とキャリアによる PVC ミスコンフィギュレーションによってかプロバイダ引き起こされ
る場合があります。
関連情報
Troubleshooting Cisco IP Telephony
トラブルシューティングテクニカルノーツ
1992 - 2014 Cisco Systems, Inc. All rights reserved.
Updated: 2014 年 12 月 24 日
http://www.cisco.com/cisco/web/support/JP/100/1002/1002622_jitter_packet_voice.html
Document ID: 18902

Download Report