音声 : 音声品質

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

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

目次

概要
前提条件
      要件
      使用するコンポーネント
      表記法
パケット音声ネットワークのジッタ
ジッタの重大度の判断
ジッタが発生する原因
      カプセル化に関する注意事項
      フレームリレー環境のジッタ
      結論
関連するシスコ サポート コミュニティ ディスカッション
関連情報

概要

この文書では、ジッタについて説明し、ジッタの測定方法と補正方法を説明します。

前提条件

要件

この文書の読者は次の項目に関する知識が必要です。

  • Cisco IOS(R) の音声設定の基礎知識

  • Quality of Service(QoS)の基礎知識

使用するコンポーネント

この文書の情報は、Cisco IOS 音声ゲートウェイとルータに適用できます。

この文書の情報は、特定のラボ環境にあるデバイスに基づいて作成されています。この文書で使用するすべてのデバイスは、クリアな状態(デフォルト)から設定作業を始めています。対象のネットワークが実稼動中である場合には、すべてのコマンドによる潜在的な影響について確実に理解しておく必要があります。

表記法

文書表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

パケット音声ネットワークのジッタ

ジッタは、受信パケットの遅延のばらつきと定義されています。送信側では、均等に間隔を空けたパケットの連続的なストリームとしてパケットが送信されます。ネットワークの輻輳、不適切なキューイング、または設定エラーのために、この安定したストリームが乱れたり、各パケット間の遅延が一定にはならずにばらつく場合があります。

次の図は、パケットの安定したストリームがどのように処理されるかを示しています。

18902_Fg1.gif

Voice over IP(VoIP)の Real-Time Protocol(RTP)音声ストリームをルータが受信する際にジッタがある場合は、それを補正する必要があります。この機能は、再生遅延バッファというメカニズムで処理されます。再生遅延バッファでは、これらのパケットをバッファ処理し、安定したストリームとして Digital Signal Processor(DSP; デジタル信号プロセッサ)に再生して、アナログ音声ストリームに再変換されるようにします。再生遅延バッファはジッタ解消バッファと呼ばれることもあります。

次の図はジッタの処理方法を示しています。

18902_Fg2.gif

ジッタが大きすぎるために、このバッファの範囲を超えてパケットが受信される場合は、範囲を超えたパケットが廃棄されるので音声が途切れて聞こえます。損失が 1 パケット程度であれば、正しい音声と考えられるデータが DSP で挿入されるので問題なく聞こえます。損失したパケットを DSP で補正できる範囲をジッタが超えると、聞こえる音声に問題が発生します。

次の図は過度のジッタの処理方法を示しています。

18902_Fg3.gif

ジッタの重大度の判断

過度のジッタが発生していることは、Cisco IOS で次のステップを実行すれば確認できます。

  1. コールが確立してアクティブ状態になり、ジッタが疑われる場合は、関連するゲートウェイの 1 つに Telnet で接続します。

  2. Telnet セッションを介してコンソール メッセージを表示できるように端末モニタを有効にします。

    注:コンソール ポートに接続している場合、このステップは不要です。

  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 VOICE VP_ERROR STATISTICS*** のセクションに注目してください。

    このセクションには、注意する必要のあるパラメータがいくつかあります。特に、Buf Overflow Discard (ms) に表示されている数字には注意が必要です。この数字は、再生遅延バッファの範囲を超えた(廃棄された)パケットの数を示しています。ある程度の値が表示されていても、値が継続的に増加していない限り問題はありません。通常は、コールが最初に開始されたときにはある程度のオーバーフローが発生しますが、show voice call X/X/X コマンドを繰り返し実行したときにこの値が増加することはありません。この数字は、過度のジッタを直接示しています。

    デフォルトでは、発生しているジッタの量に応じて(ある程度まで)動的に調節される適応モードで、このバッファは運用されています。ジッタ解消バッファの動的な動作のデフォルトを変更する場合は、playout-delay コマンドで設定してください。このバッファは固定モードに設定することもできます。そのようにすれば、ジッタに関する問題の一部を解決できる場合があります。詳細は、『Voice over IP の再生遅延の拡張機能』を参照してください。

ジッタが発生する原因

一般に、ジッタは IP ネットワークの輻輳が原因で発生します。輻輳は、ルータ インターフェイスで発生する場合もあれば、回線のプロビジョニングが正しく行われていない場合にプロバイダーや通信事業者のネットワークで発生する場合もあります。

カプセル化に関する注意事項

回線の中でもルータ インターフェイスは直接制御できる場所なので、ルータインターフェイスでジッタを探し始めるのが最も簡単で最善の方法です。ジッタの原因を追求する方法は、ジッタが発生しているリンクのタイプとカプセル化によって大きく異なります。一般に、ATM 回線には固定セルレートが使用されているので、正しく設定されていればジッタは発生しません。そのため、遅延は非常に一定しています。ATM 環境でジッタが見られる場合は、ATM の設定を調べる必要があります。ATM が正しく動作している(廃棄されたセルがない)場合は、ジッタは問題にならないと考えられます。Point-to-Point Protocol(PPP; ポイントツーポイント プロトコル)のカプセル化でジッタが発生するのは、ほとんどの場合、シリアル化の遅延が原因です。この問題は、PPP リンクの『QOS を実装した PPP リンク上での VoIP(LLQ / IP RTP プライオリティ、LFI、cRTP)』で簡単に対応できます。PPP では、本質的に PPP のエンドポイント同士が、間にスイッチのネットワークを介さずに相互に直接会話します。これにより、ネットワーク管理者は関連するすべてのインターフェイスを制御できます。

フレームリレー環境のジッタ

フレームリレー環境のジッタを発見するには、次の 3 つのパラメータに注意を払う必要があります。

この設定を行うための設定例および情報は、『QOS(フラグメンテーション、トラフィック シェーピング、LLQ / IP RTP プライオリティ)を使用した 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 が設定されている場合には、これらの値が増えることはありません。これらの値が増加している場合で、回線の実際の CIR と照合している場合は、フレーム プロバイダーのネットワーク設定に正しくない部分があります。

このような場合の一例として、CIR がゼロの回線を購入しているのにバースト値が設定されている場合があります。一部のプロバイダーでは、CIR がゼロの Permanent Virtual Circuit(PVC; 相手先固定接続)を販売しています。このような回線は、データ用には問題ありませんが、音声品質に問題が発生します。CIR がゼロの回線のコマンド出力を見ると、DE または FECN のパケット数が入力パケット数と等しくなっています。さらに一歩進んで考えると、通信事業者が 128 kbps になるようにプロビジョニングした PVC がある場合に、ルータの CIR が 512 kbps に設定されていると、これらのカウンタが(ゆっくりと)増加します。表示されているのは、ルータ インターフェイスに着信するパケットだけで、このレートは PVC の反対側にあるルータに設定されたトラフィック シェーピング パラメータで制御されていることに注意してください。逆に、こちらは、ローカル側に設定するトラフィック シェーピング パラメータで、もう一方のルータへの入力を制御しています。

通信事業者によりプロビジョニングされている PVC の CIR を超えた設定をしないことが非常に重要です。この CIR より低く設定しても問題は起こりません。ところが、この CIR より高く設定すると、輻輳が発生します。

このように輻輳が発生するのは、フレーム スイッチの特定の PVC に設定された CIR により、そのスイッチで(その PVC に)トラフィックが渡されるレートが決定されるからです。実際に受信するデータ レートがフレーム スイッチに設定された CIR を超えている場合は、CIR を超過したフレームをバッファ処理して、バッファ処理したパケットを転送するキャパシティが使用可能になるまで保持しておく必要があります。バッファ処理されたパケットには、DE ビットまたは FECN ビットがフレーム スイッチによって設定されます。

常にそうなのですが、インターフェイスの統計情報を詳しく調べ、廃棄やエラーを探して、すべての機能が物理層で正しく動作していることも確認する必要があります。これには、show interface コマンドを使用してください。

この状態が発生するとジッタに影響する理由は、一部のパケットでフレーム ネットワークでのバッファ処理が必要になり、リモート ルータに到達するための遅延が長くなるためです。ただし、輻輳がなければ、通常の遅延時間で到達します。その結果、リモート ルータで受信されるパケット間のデルタ時間にばらつきが生じることになります。そのため、ジッタが発生します。

フラグメンテーション

フラグメンテーションは、ジッタよりもシリアル化の遅延と深い関係があります。ただし、特定の条件下では、ジッタを発生させる可能性があります。パケット化された音声を扱う場合は、フレーム リレーのマップ クラスにフラグメンテーションを常に設定する必要があります。このパラメータを設定すると、インターフェイスに 2 つの効果があります。最初の効果として、指定したサイズより大きなすべてのパケットがフラグメンテーションされます。2 番目の効果は、最初の効果ほど目立ちませんが、同じくらい重要です。フラグメンテーションが設定されたインターフェイスを観察すると、このコマンドの効果がわかります。フラグメンテーションを指定しない場合の show interface x コマンドの出力には、First In First Out(FIFO; 先入れ先だし)のキューイング方式が使用されていることが表示されます。フレーム リレー マップ クラスにフラグメンテーションを適用すると、このコマンドの出力にはキューイング方式がデュアル FIFO と表示されます。このようにして、音声トラフィックに使用されるプライオリティ キューがインターフェイスに作成されます。『QOS(フラグメンテーション、トラフィック シェーピング、LLQ / IP RTP プライオリティ)を使用した VoIP over Frame Relay』の「フラグメンテーション」のセクションで推奨されている値をフラグメンテーションの値として設定することを強くお勧めします。推奨値を使用してもジッタの問題が発生する場合は、音声品質が受け入れられるレベルになるまで、1 段階ずつフラグメンテーションの値を低くしてください。

キューイング

このタイプの環境の VoIP トラフィックに使用するために一般に受け入れられているキューイング方式は、次の 2 つです。

これらの方式のどちらかを使用してください。両方は設定しないでください。キューイング処理がマニュアルに従って正しく行われている場合は、キューイングは正しく動作しており、問題は他の箇所にあると結論できます。キューイングによって発生する遅延は比較的小さいので、キューイングは一般的にジッタの原因とはなりません。ただし、VoIP パケットが正しくキューイングされておらず、同じ回線をデータ用にも使用している場合は、ジッタが発生する可能性があります。

結論

ジッタとは、音声パケットのパケット遅延のばらつきのことです。ある程度のジッタは、ルータ内の DSP で補正できますが、過度のジッタには対応できません。その結果、音声品質が劣化します。あるパケットでは回線のどこかでキューイングや遅延が発生していながら、それ以外のパケットではキューイングや遅延が発生していないことが、ジッタの原因です。これにより、遅延にばらつきが生じます。ジッタは、ルータの設定ミスおよび通信事業者またはプロバイダーによる PVC の設定ミスの両方で発生する場合があります。


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

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


関連情報


Document ID: 18902