コラボレーション エンドポイント : Cisco Unified IP Phone 7900 シリーズ

トラブルシューティングのための79xx ステータス情報の使用

2016 年 10 月 28 日 - 機械翻訳について
その他のバージョン: PDFpdf | 英語版 (2015 年 8 月 22 日) | フィードバック


目次


概要

このドキュメントでは、問題をトラブルシューティングするためにすべての Cisco 79xx IP Phone のディスプレイに表示されるステータス情報について説明します。 この情報を使用して、進行中のコールに使用されているコーデックの種類を特定できます。 また、進行中のコールのパフォーマンス特性に関するリアルタイム情報が提供されます。

はじめに

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

前提条件

このドキュメントに関する固有の要件はありません。

使用するコンポーネント

このドキュメントは、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。 対象のネットワークが実稼働中である場合には、どのような作業についても、その潜在的な影響について確実に理解しておく必要があります。

ディスプレイ

電話で情報(i)ボタンで Cisco IP Phone 79xx ディスプレイが進行中のコールの情報を表示するのにトラブルシューティングを行うのに利用することができます。 この機能をアクティブにするためにアクティブ コールの間にこのボタンを二度押して下さい。

/image/gif/paws/7415/telecaster-trouble_8.gif

「」このようにボタンな /image/gif/paws/7415/telecaster-trouble_9.gif

このメニューは次の情報を提供します:

  • RxType/TxType —現在現在のアクティブな音声メッセージ交換で利用されるコーデック。

  • RxSize/TxSize —コーデックのペイロードのサイズ、この場合音声/パケットの 20 ミリ秒。

    79xx MGCP IP 電話 サポートだけ 10-40 ミリ秒のペイロードサイズ。

  • RxCount/TxCount —送信される/受信されるパケットの量。

  • AvgJtr —平均ジッターは最後の 16 の RTP パケットで観察される推定平均ジッターです(平均機能はちょうど簡単な低域 フィルタです)。

  • MaxJtr —最大ジッタは RTP レシーブ ストリームのライフの間に見られる最大ジッタです。 これがコールのライフの間ない、しかしストリームのためにことを覚えていて下さい。 人を保留にする場合、ストリームはなくなり、およびそれ故に新しい値ここに再起動する必要があります。

  • RxDisc —パケットの数はこの Cisco IP Phone 79xx の受信を廃棄しました。

  • RxLost —この Cisco IP Phone 79xx で受信着かなかったパケットの数。

トラブルシューティングのために集中するべき事柄:

  • RxType/TxType はどんなコーデックがこの IP Phone とその他のデバイス間のメッセージ交換のために使用されているか述べています。 かどうかそれら両側で一致する参照して下さい。 それらが一致する場合、その他のデバイスがコーデック メッセージ交換を処理できるか、またはサービスを処理するためにトランスコーダが設置されていることを確認して下さい。

  • 音声 の サンプルのサイズは両方のデバイスで一致する必要があります。 これは RxSize/TxSize フィールドにあります。

  • RxCount/TxCount は破棄された パケット、1 つの方法音声問題および Voice Activity Detection (VAD)を解決するために役立ちます。

ジッター

音声世界では、ジッタはネットワークのパケットの内側ギャップに関連しています。 理想的には、音声パケットは一定した(余りに長く)遅延と同期で受信する必要があります。 残念ながら、ほとんどのネットワークは音声パケットを非同期的に渡します。 すなわち、音声パケット間の時間に変動があります。 これはジッタと言われます。 音声パケット(ジッタ)間の時間が受信側デバイスの再生バッファを越えて変わる場合、被呼加入者は音声 ストリームのギャップを聞きます。

理想的な世界では、音声が含まれているパケットのストリームはインター パケット ギャップの同量のエンド デバイス(被呼加入者)できっかり到達します。 これは 0 のジッタ 値という結果に終ります。 現実 の 世界では、音声パケット間のギャップはパケットからシーケンスのジッタをもたらすパケットに変わることができます。

伸縮性があるパケット バッファとして機能するこの問題に対処するために、79xx 電話は First In First Out (FIFO; 先入れ先出し) キューが含まれています。 それは一定したインター パケット ギャップのパケットを展開することによって一定した DSP に音声パケットのフローを保存することを試みます。 これは受諾可能な音声クオリティの確認を助けます。 79xx ジッタ バッファはジッタの 2 秒まで処理します。 ジッタはミリ秒で測定されます

着信音声ストリームのインター パケット ギャップが 0 ms と 2 s の間で変わる場合、79xx's FIFOバッファはこの変化を覆える、着信音声ストリームのギャップは被呼加入者によって検出する。 一方では、着信音声ストリームが 2 s 以上インター パケット ギャップを経験すれば、79xx's FIFOバッファは次の音声パケットを待っている間流出してしまいます。 この場合音声 ストリームのギャップは検出する。 これは後でより詳しく説明されます。

下記の例で各パケットにシーケンスでそれと次 の パケット間の遅延の同量が丁度あります。 この場合パケット(5 ms)間の一定した遅延値は 0 のジッタ 値という結果に終ります。

/image/gif/paws/7415/telecaster_trouble_1.gif

実質ネットワーク 状況でインターパケット遅延はまれに一定していません:

/image/gif/paws/7415/telecaster_trouble_2.gif

音声パケットのストリームがソースと宛先の間で存在 する スイッチおよびルータのバッファを通ると同時に、ギャップはパケットの間で挿入されます。 これらのギャップはソースと宛先間のルータおよびスイッチのロードが絶えず変更するので大小の差があります。

上記のダイアグラムで 5 から 14 から 10.にインター パケット ギャップ 範囲を表示する場合があります。 ネットワーク(IP 電話この場合)の端デバイスはパケットがリスナー(被呼加入者)に一定のレートで展開されるようにこれらのバリエーションを補正しなければなりません。 これは FIFOバッファが利用可能 な 音声パケットを展開するために常に備えていることを必要とします。

79xx's FIFOバッファのサイズは着信音声ストリームで経験されるジッタの量に基づいて異なります。 着信音声ストリームのジッタ 値が低い場合、79xx は着信音声ストリームのジッタ 値が高いときより小さい FIFOバッファをより使用します。 しかしそれは 79xx がに対処できるよりファースト可能性のある、ジッタ 値の変化率がのそれです。 この場合 79xx が FIFOバッファ サイズを調整する間、リスナー(被呼加入者)は音声 ストリームの簡潔なギャップを経験します。

Cisco IP Phone 79xx は FIFOバッファ サイズを急激に増加し、ゆっくり減少させます。

FIFOバッファのサイズは宛先によって送信 され、受け取った音声パケット間の遅延に対する直接的 な 効果をもたらします。 FIFOバッファがより大きくなると同時に、FIFOバッファからパケットを移動することの遅延は増加します。 このサブジェクトに関する詳細については遅延の次の セクションを参照して下さい。

次のダイアグラムは着信音声ストリームからジッタを取除く FIFOバッファを表示します。

telecaster_trouble_3.gif

経験すれば音声コール(排気切替器)のギャップは AvgJtr および MaxJtr 値をチェックします。 、たとえば、平均ジッター値が 5 ならおよび最大ジッタ値が 3000 なら、2 つの値間の変動が非常に高いので問題の可能性があります。 これが急に起こった場合、そこに償う 79xx's FIFOキューのための時間が十分ないかもしれません。 この動作の種類は大きいルーティングテーブルアップデートまたはバッチ ファイル転送のようなアクティビティの定期的な高い率があるネットワークにあることができます。 このような場合トラフィック負荷は非常に短いある一定の時間の低くか普通から強いおよび背部から再度行きます。

Cisco IP Phone 79xx は顕著な品質劣化なしで一般的に パケットロス 20%まで処理できます。

遅延

遅延はソースから宛先に移動するために音声パケット(か音声 ストリームを)奪取 する 時間数です。 ほとんどの場合遅延は音声 ストリーム(メッセージ交換)の間に異なります。 きちんと調整されたネットワークでは、言われましたことがコーリングパーティが話すおよび被呼加入者は聞きます時間間の最大遅延一般人がことができる何を検出するより少しはよりあります。 すなわち、メッセージ交換に目で見える遅延がありません-話されていたらすぐワードは聞かれます。

場合によってはネットワークを渡る遅延は人間耳によって探索可能であるレベルに増加します。 最悪 の 場合でメッセージ交換は各人がまだ受信されていない音声パケットことをによって割り込まれないで話すことができることを他の人が確認するようにそれらは話すことを停止したことを示さなければならないポイントに悪化します。 イーサネットについて詳しく知っていればこの動作をレイト コリジョンと呼出すかもしれません。

すべてのネットワークはソースからの宛先にパケットの伝達の遅延を課します。 ソースデバイスがパケットを送信 し、デスティネーションデバイスがそれを受け取る場合一定したインター パケット ギャップのネットワークにの < 1ms 時間以内に遅延が間の生じます。 低速シリアルリンクは伝送メディアにビットを直列化するためにかかる時間が理由で(64K 以下に) OC12 のような高速リンクよりより多くの遅延を作成します。

遅延のバリエーションは上記のジッタのセクションに記述されているように長いインター パケット ギャップの原因となる同じ状況によって引き起こされます。 しかし遅延の場合には原因は一般的に少数の音声パケットより長く持続します。 メッセージ交換の少数のパケットのためのインター パケット ギャップの増加を引き起こすかわりに、これらの問題は全体のメッセージ交換に影響を与えます。

Cisco IP Phone 79xx は遅延カウンターを提供しません。 遅延はネットワーク アナライザおよび他のネットワーク管理デバイスによって測定することができます。

マイナー な遅延問題はジッタができる程に音声クオリティにひどく影響を及ぼしません。 これは遅延と、話し言葉すべてが結局着くか一方ジッタにより全体の話し言葉が失われる場合がある音声 ストリームで中断を引き起こす場合があるという理由によります。 つまりジッタは定期講読されたネットワークのパケットロスに非常に類似したです-パケットはインターフェイス バッファ流れ、ドロップされます、つまり宛先で決して着かないことを意味します。

下記の図はジッタとの遅延の結合された効果を示します、手に手をとって行く。 パケットは一定のレートで送信されます。 IPネットワークは迅速に一貫してとしてパケットを転送しません、より大きく、いろいろなインター パケット ギャップという結果に終った。 さらに、第 4 パケットはネットワークにどこかにまだあります。

telecaster_trouble_6.gif

ネットワークの累積 遅延はルータがトラフィックを必要とするあらゆるメッセージ交換のもとと宛先間のパススルーを切り替えるか何かによって決まり。

IP 環境では、遅延を測定する 1 つの方法は traceroute ツールを使用することですがこれはルータ ホップのためにだけはたらきます。 さらに、traceroute をサポートするいくつかのホストはサービス拒絶 (DoS) 攻撃の間に助ける非常に低い CPU 優先順位でそれを実行します。 これはパケットは 1 ホップから別のものに行くために奪取 したこと時間に追加される CPU の方に課された遅延があることを意味します。 つまり- traceroute によって報告される数に多くの信頼を置かないで下さい。

ナノ秒にパケットおよび遅延メジャーの送ることができるサード パーティ ネットワーク 解析ツールがあります。 それらはそれらを設定する前にロード状態の下でネットワーク設計プロトタイプをテストするために非常に役立ちます。 堅牢な、うまく設計された調整された音声ネットワークは一貫した遅延 および ジッター問題がないはずであるそれは注目されるはずですしかし。


関連情報


Document ID: 7415