音声とユニファイド コミュニケーション : Cisco Unified Communications Manager(CallManager)

Cisco Voice Manager(CVM)および Telemate を使用した音声品質の管理

2015 年 11 月 26 日 - 機械翻訳について
その他のバージョン: PDFpdf | ライター翻訳版 (2002 年 4 月 9 日) | 英語版 (2015 年 8 月 22 日) | フィードバック


目次


概要

この文書は、Cisco Voice Manager および Telemate を使用した VoIP ネットワークでのボイス品質の管理について説明しています。 内容はすべて実際の IP テレフォニー実装に基づいています。 この文書は製品の応用例を中心に説明しており、製品の使用については説明していません。 ここでは、読者がすでに CVM と Telemate について十分理解していて、必要な製品文書を参照済みであることを前提としています。 関連資料のリストについては、「関連情報」を参照してください。

大規模な VoIP ネットワークを管理する際は、ネットワークの音声品質を客観的に監視し、報告するツールが必要です。 ユーザからのフィードバックは主観的かつ不完全であるため、それだけに頼るのでは不十分です。 CVM は Telemate と連携してこの機能の一部を提供できます。 CVM は、IOS ゲートウェイによってコールごとに計算された Impairment/Calculated Impairment Planning Factor(Icpif)を使用して、ボイス品質を報告します。 ネットワーク管理者はこれを利用して、ボイス品質の悪いサイトを特定し、それらのサイトに適切に対処できます。

問題のあるサイトを特定した後、ネットワークの QoS に関して起こりうる問題についてトラブルシューティングを行うために、他のツールが必要になることがあります。 これらは、Internetwork Performance Monitor(IPM; インターネットワーク パフォーマンス モニタ)と Cisco Service Assurance Agent(CSAA; シスコ サービス保証エージェント)の 2 つのツールです。 これらのトピックは Webサイトで掲示される別の資料で説明されています。

前提条件

要件

このドキュメントの読者は次のトピックについて理解している必要があります。

  • Cisco Voice Manager および Telemate

使用するコンポーネント

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

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

表記法

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

音声品質の概要

次の各項ではボイス品質に関する事柄の概要について説明しています。

ボイス品質の測定

ITU 規格 G.113 はボイス品質の測定方法について規定しています。 この方法では、ボイスコールの品質を Icpif を計算することによって判定できることが明記されています。 IOS ベースのゲートウェイは、すべてのコールについて Icpif 値を計算し、それを CDR レコードの一部としてログに記録します。 また、IOS ベースのゲートウェイは、コールの Icpif 値が 前もって設定しておいた値を超えた場合に、SNMP を経由して Quality of Voice(QoV)トラップを送信できます。 このことは、ゲートウェイが組み込みのボイス品質測定機能を備えていることを意味します。 ユーザ側で必要な作業は、これらの測定結果を収集してデータを分析し、傾向を特定することだけです。

VoIP のボイス品質は主にネットワーク QoS の影響を受けます。 したがって、コール分析ではボイス品質の問題をサイト単位で特定することが中心になります。 ボイス品質の悪いコールが多数発生しているサイトを特定できれば、それらのサイトを通過するネットワーク パスの QoS の問題に注目できます。

ITU G.113 の概要

以降のセクションはただの簡潔な概要です; 詳細については G.113 規格を参照してください。

G.113 の基本的な考え方は、ボイスパスに沿って存在するすべての設備機器について障害要因を計算した後、それらを加算して障害合計を算出することです。 障害にはさまざまなタイプ(ノイズ、ディレイ、エコーなど)があり、ITU ではこれらを 5 つのカテゴリに分けています。 これらをすべて加算して障害合計 <SPAN style="FONT-STYLE: italic">Itot を算出します。

Itot = Io + Iq + Idte + Idd + Ie

障害はそれぞれ次のように定義されています(ITU の用語を使用しています)。

  • Io —最適でなく全面的な音の大きさ定格や高い回線雑音によって引き起こされる障害。

  • I.Q. —ゆがみを量子化する PCM 型によって引き起こされる障害。

  • Idte —送話者エコーによって引き起こされる障害。

  • Idd —長い片方向伝送時間(遅延)までに引き起こされる音声通信問題。

  • IE —特別な機器によって引き起こされる障害特に非波形 low-bit-rate コーデック。

Cisco IOS ソフトウェアは、Itot を計算するときに <SPAN style="FONT-STYLE: italic">Io と <SPAN style="FONT-STYLE: italic">Iq を省略可能なものとして無視し、<SPAN style="FONT-STYLE: italic">Idte を <SPAN style="FONT-WEIGHT: bold">0 に設定します。 <SPAN style="FONT-STYLE: italic">Idd の値は G.113 に記載されている次の表から求められます。

遅延 Idd
150 0
200 3
250 10
300 15
400 25
500 30
600 35
800 40

通常、Ie はコーデック タイプにのみ依存する固定値です。 次の表に示すように、G.113 では Cisco ゲートウェイによって通常使用されるコーデックに対応した値が規定されています。

コード Ie
G.711 0
G.729/G.729a 10

しかし、これらのコーデックはボイスをパケット化した環境で使用しているため、実際の障害はパケットの損失に依存します。 パケットの損失率が高くなるほど、障害の発生率も高くなります。 シスコ エンジニアリングでは PSQM(ITU P.861)を使用して、離散的なパケット損失レベルでのボイス品質を測定しています。 次の表は、特定のコーデックのパケット損失レベルに対するボイス歪み値を示したものです。

パケット損失(%) G.711 G.729/G.729a
0 0 10
1 8 15
2 12 20
3 18 25
4 22 30
5 26 34
6 28 38
7 30 40
8 32 42
9 34 44

予想されるとおり、G.729 の方が G.711 よりもパケット損失の影響を受けやすくなります。

ボイス品質は、最終的には人間の知覚と期待の問題になります。 携帯電話ユーザのサービス レベルは、固定回線ユーザのサービス レベルよりも低くなっています。 Icpif を計算するときはこの点を考慮し、Itot から人間の期待因子 A を差し引きます。 この式は次のようになります。

Icpif = Itot - A

G.113 では典型的なボイスネットワークにおける期待因子も提供されています。 次の表を参照してください。

ボイスネットワークのアクセス方式 期待因子 A
従来の固定回線 PSTN 0
ローカル エリア無線(コードレス電話) 5
ワイド エリア無線(携帯電話) 10
衛星 20

G.113 には、Icpif 値とボイス品質を対応付ける表も記載されています。 それは次 の テーブルで示されています:

ボイスネットワークのアクセス方式 期待因子 A
5 非常に良好
10 良好
20 適切
30 限定された状況で許容可
45 きわめて限定された状況で許容可
55 ユーザが強い不満を示す可能性が高い

コールに対して Icpif 値が 0 になると最適になります。 VoIP ネットワークではこの値を目標にしてください。

従来のボイスネットワークでは、設計者は障害合計値の見積もりを計算します。

たとえば、Io = 0; I.Q. = 0; Idte = 0; Idd = 3; IE = 7、Itot を = 10.与える。

ユーザがコードレス電話からネットワークにアクセスしている場合、差し引くことのできる最大期待因子は 5 となり、最終的な結果は次のようになります。

Icpif = Itot - A = 10 - 5 = 5

前の表によれば、この結果からユーザはボイス品質を非常に良好なものとして認識する可能性が高くなります。

この文書では、設計計画のためではなく、ボイス品質を監視するために Icpif 値を使用するソリューションについて説明しています。

CVM および Telemate を使用したボイス品質の管理

次の各項では CVM および Telemate を使用したボイス品質の管理方法について説明しています。

制限事項

ここで提示しているソリューションには若干の制限事項がありますが、これ以外に使用できるスケーラブルなツールはないようです。 これまでにわかっている制限事項を次に示します。

  • ゲートウェイ経由のコールだけが品質管理の対象となります。 IPPhone から IPPhone へのコールは測定できません。 ゲートウェイはこれらのコールを監視できず、CallManager は現時点では G.113 をサポートしていません。

  • Icpif の計算ではパケット損失とディレイだけしか考慮されていません。 エコーは Icpif の計算には含まれていません。 したがって、Icpif の値が完全であるにもかかわらず、深刻なエコー障害が起きる場合があります。

  • ボイス品質は IPPhone からゲートウェイへの方向のみで測定されます。 パケットボイスネットワークでの <SPAN style="FONT-STYLE: italic">Icpif の値は 2 つの方向でおそらく非対称になります。 ゲートウェイから IPPhone への方向におけるネットワークの QoS の問題は、ゲートウェイで計算される <SPAN style="FONT-STYLE: italic">Icpif の値には反映されません。

  • ボイス品質の問題は、一般に WAN を経由する際の問題といえます。 ここで説明しているソリューションは集中化されたゲートウェイを持つ環境に最も適しています。これは、リモート サイトの IPPhone からのコールが WAN を経由してゲートウェイにアクセスしなければならないためです。 ゲートウェイが分散している場合(つまり、各リモート サイトがローカル ゲートウェイからサービスを供給されている場合)、ゲートウェイ コールのほとんどは WAN を経由しません。 WAN を経由する VoIP コールは主に IPPhoneから IPPhoneの場合であり、これらはゲートウェイからは監視できません。

ゲートウェイの設定

提示されているソリューションの一部として、すべてのゲートウェイを CDR 収集用に設定する必要があります。

dial-control-mib max-size <max-number-of-cdr>
dial-control-mib retain-timer 600

また、すべてのゲートウェイで QoV トラップ機能を有効にする必要があります。 この機能はデフォルトで無効になっています。

Calibra#show dial-peer voice 99 | include QOV|Icpif
Expect factor = 0, Icpif = 20,
VAD = enabled, Poor QOV Trap = disabled,

この機能は、次のコマンドを追加することによって、VoIP ダイヤルピア単位で有効になります。

dial-peer voice XYZ voip
snmp enable peer-trap poor-qov
icpif <threshold>
expect-factor 0

コールが確立すると、ゲートウェイはそのコールの障害合計(<SPAN style="FONT-STYLE: italic">Itot)を計算します。 次に、設定済みの期待因子を <SPAN style="FONT-STYLE: italic">Itot から差し引き、実際の <SPAN style="FONT-STYLE: italic">Icpif 値を求めます。 この数値が <SPAN style="FONT-STYLE: italic">Icpif のしきい値を超えると、QoV トラップが送られます。 ゲートウェイがコールの Icpif 値を計算するためには、少なくとも 10 秒のコール時間が必要になります。

例を見てみましょう。次のようなゲートウェイの設定を考えます。

dial-peer voice XYZ voip
icpif 10
expect-factor 5

コールが 20 という Itot 値と成立すると仮定して下さい。 ゲートウェイはこの数からそれから 15 の Icpif値を与える 5 の期待ファクタを引きます。 15 は 10 よりも大きいため、ゲートウェイは QoV SNMP トラップを生成します。

全体的に見ると、QoV トラップが CVM に送られるようにするため、QoV トラップを有効にすることも必要です。

snmp-server enable traps voice poor-qov
snmp-server host 10.x.x.x.x public<----- CVM station

ボイスゲートウェイはコールが確立または切断されるたびにリンクアップ/リンクダウンの SNMP トラップを生成することに注意してください。 このため、呼量の多いゲートウェイで膨大な数のトラップが発生する可能性があります。 これらのトラップは次のコマンドを追加して必ず無効にしてください。

interface serial1/0:15no snmp trap link-status

CVM および Telemate のアーキテクチャ

CVM と Telemate は互いにまったく別のアプリケーションです。 CVM はその名前が示すようにシスコが開発した製品です。 一方、Telemate はシスコが CVM にバンドルして販売しているサードパーティ製品です。

CVM はさまざまな機能を実行します。 ここでは次の 2 つの機能を利用します。

  • SNMP によるゲートウェイからの Call Detail Record(CDR; コール詳細レコード)の収集

  • ゲートウェイからの Quality of Voice(QoV)SNMP トラップの受信

これらの情報を収集した後、CVM はデータを整形し、簡単なファイル共有を経由して Telemate に渡します。 続いて Telemate はこのデータを処理し、Microsoft SQL データベースに格納します。 最終的に、Icpif 値を含む個々の詳細を収めたセルのリストからなるデータベースができます。 この後、データベースに対して QoV レポートなどの各種レポートを実行できます。

ここでは「Packet Voice Calls with Quality of Service Traps」という Telemate の QoV レポートに注目します。 このレポートには、ゲートウェイが QoV トラップを生成したすべてのコールが列挙されます。 個々 の コールに興味がありません; むしろ、音声クオリティの呼び出しの上記の平均パーセントがあるサイトの、もしあれば識別に興味があります。 そのため、Telemate においてコールをサイト別に分類できるようにする必要があります。 これについては、次の項で説明します。

Telemate ディレクトリ

各サイトの内線番号の情報を Telemate ディレクトリに設定することにより、Telemate を使用してコールをサイト別に分類できます。

Telemate ディレクトリは次の各レベルを持つ 5 層の階層です。

  • レベル 1 - 会社

  • レベル 2 - 部

  • レベル 3 - 課

  • レベル 4 - ユーザ

  • レベル 5 - 内線番号

複数の内線番号を 1 人のユーザに関連付けることができます。

QoV レポート内のコールごとに部名を付けて列挙することができれば理想的です。 そのようにすることで、部名を使用して対象のサイトを表すことができます。 これにより、コールを部/サイト別にソートできます。 しかし、内線番号はユーザにしか関連付けることができないため、これを実現するには多少手間のかかる方法を使用する必要があります。 基本的には、サイトごとにダミーのユーザを 1 つ作成し、そのユーザの名前をサイト名またはサイト コードにします。 そして、このダミー ユーザに対して、その特定のサイトにある内線番号をすべて割り当てます。 その後、コールをユーザ別にソートすることで、サイト別にソートしたことと同じ効果が得られます。

ここでは QoV レポートの作成を目的としているため、最上位の 3 つのディレクトリ階層レベルについては取り扱いません。

これらには任意の値を割り当てることができます。この実装では、200 のサイトに 45,000 の内線番号が割り当てられていますが、必ずしもこれらすべてが使用されていません。 そこで、ディレクトリに 200 のダミー ユーザを置き、ダミー ユーザごとに各自のサイトに対する一定範囲の内線番号を関連付けます。 ディレクトリの手動設定作業はまず不可能であるため、この作業を半自動的に実行します。これには、内線番号ごとに 1 行の CSV ファイルを作成した後、Telemate のインポート機能を使用してファイルをディレクトリにインポートします。 この CSV ファイル内の各行は次の形式になります。

Company,Division,Department,User,Extension

CSV ファイル自体の生成も Unix シェル スクリプトを実行することで半自動的に実行できます。 このスクリプトはシード ファイルを入力として受け取ります。 このシード ファイルには、サイトと、それに関連付けられた内線番号範囲を列挙します。 シード ファイル内の各行は次の形式になります。

site_name,extention_start,extension_end

シェル スクリプトそのものは非常に単純であり、次のような内容です。

#--------------------------- Telemate script start ------------------------

#!/bin/ksh
 
 for i in `cat ./$1`
 do (
   echo $i | awk 'BEGIN{FS=","}{for (j=($2+0);j<($3+0);++j) printf "Company,Division,Dept,%s,%s\n", $1,j}'
) done
#--------------------------- Telemate script end ------------------------

スクリプト自体の名前を「make_dir」とし、シード ファイルの名前を「seedfile.csv」とすると、次のコマンドを Unix プロンプトで実行することで telemate_dir.csv という CSV インポート ファイルが作成されます。

unix$ make_dir seedfile.csv > telemate_dir.csv

次に、出力ファイル telemate_dir.csv を Telemate にインポートします。 この方法の詳しい手順については、Telemate の文書を参照してください。

レポート作成

Telemate レポートを実行するときは、出力先を選択できます。 大きなレポートでは、ファイルを CSV 形式で生成することをお勧めします。 そうすれば、レポートを Excel で操作できます。次にレポートの例を示します。

コール時間 ダイヤル番号 場所 日付 時刻 サイト 内線番号
0:00:57 3-573-7783 10.200.16.33 10/05/2000 4:49:45PM BLM 37569
0:00:57 3-573-7783 10.200.16.33 10/05/2000 4:49:45PM BLM 37569
0:00:38 3-577-2958 10.200.16.33 10/05/2000 4:28:28PM BLM 37576
0:00:38 3-577-2958 10.200.16.33 10/05/2000 4:28:28PM BLM 37576
0:00:52 3-577-2985 10.200.16.33 10/05/2000 9:26:33PM BLM 37593
0:01:19 3-577-1770 10.200.16.33 10/05/2000 7:26:05PM BMC 34270
0:00:23 3-577-1770 10.200.16.33 10/05/2000 8:08:27PM BMC 34270
0:00:23 3-577-1770 10.200.16.33 10/05/2000 8:08:27PM BMC 34270
0:00:11 4-566-5302 10.132.16.33 10/05/2000 7:05:33PM COR 42791
0:00:32 4-567-0417 10.132.16.33 10/05/2000 5:29:51PM COR 42805
0:00:32 4-567-0417 10.132.16.33 10/05/2000 5:29:51PM COR 42805
0:00:36 4-232-8545 10.132.16.33 10/05/2000 5:42:07PM COR 42823
0:00:36 4-232-8545 10.132.16.33 10/05/2000 5:42:07PM COR 42823
0:00:39 4-472-5011 10.132.16.33 10/05/2000 5:59:23PM COR 46578
0:00:39 4-472-5011 10.132.16.33 10/05/2000 5:59:23PM COR 46578
0:00:28 4-236-7687 10.132.16.33 10/05/2000 7:17:51PM COR 46578
0:00:17 6-867-9766 10.132.16.35 10/05/2000 4:08:02PM GIS 64197
0:00:17 6-867-9766 10.132.16.35 10/05/2000 4:08:02PM GIS 64197
0:00:30 6-868-6889 10.132.16.35 10/05/2000 6:15:48PM GIS 68549
0:00:30 6-868-6889 10.132.16.35 10/05/2000 6:15:48PM GIS 68549
0:01:26 6-876-5223 10.132.16.35 10/05/2000 7:10:23PM HAH 68369
0:01:26 6-876-5223 10.132.16.35 10/05/2000 7:10:23PM HAH 68369
0:00:52 6-876-2223 10.132.16.35 10/05/2000 5:37:58PM HAH 68397
0:01:05 4-477-5402 10.132.16.33 10/05/2000 4:23:20PM JVL 47162
0:00:24 4-478-8848 10.132.16.33 10/05/2000 7:07:09PM JVL 47168
0:00:24 4-478-8848 10.132.16.33 10/05/2000 7:07:09PM JVL 47168
0:00:44 4-387-1333 10.132.16.33 10/05/2000 7:49:16PM KIB 49252
0:00:44 4-387-1333 10.132.16.33 10/05/2000 7:49:16PM KIB 49252
0:01:14 4-389-4299 10.132.16.33 10/05/2000 4:07:10PM KIB 49254
0:01:14 4-389-4299 10.132.16.33 10/05/2000 4:07:10PM KIB 49254
0:00:29 4-387-1337 10.132.16.33 10/05/2000 4:06:45PM KIB 49256
0:00:29 4-387-1337 10.132.16.33 10/05/2000 4:06:45PM KIB 49256
0:00:41 4-384-9269 10.132.16.33 10/05/2000 4:09:38PM KIB 49261
0:00:41 4-384-9269 10.132.16.33 10/05/2000 4:09:38PM KIB 49261
0:00:41 4-384-9269 10.132.16.33 10/05/2000 4:09:38PM KIB 49261
0:00:17 4-387-1344 10.132.16.33 10/05/2000 4:33:04PM KIB 49263
0:00:17 4-387-1344 10.132.16.33 10/05/2000 4:33:04PM KIB 49263
0:00:31 6-367-5103 10.132.16.35 10/05/2000 8:44:46PM LEV 64233
0:00:31 6-367-5103 10.132.16.35 10/05/2000 8:44:46PM LEV 64233
0:00:30 6-368-9088 10.132.16.35 10/05/2000 4:11:06PM LEV 64247
0:00:30 6-368-9088 10.132.16.35 10/05/2000 4:11:06PM LEV 64247
0:00:38 4-570-2450 10.132.16.33 10/05/2000 4:08:26PM LHT 43636
0:00:38 4-570-2450 10.132.16.33 10/05/2000 4:08:26PM LHT 43636

Excel の「小計」機能を使用し、ユーザ/サイト当たりの不良コール数を数えます。 そして、小計計算を半自動化する Excel マクロを作成します。 詳細は次の例を参照してください。

コール時間 ダイヤル番号 場所 日付 時刻 サイト 内線番号
        BLM の数 5  
        BMC の数 3  
        COR の数 8  
        GIS の数 4  
        HAH の数 3  
        JVL の数 3  
        KIB の数 11  
        LEV の数 4  
        LHT の数 2  
        合計 43  

<SPAN style="FONT-WEIGHT: bold">サイト欄には、そのサイトを経由した不良コールの数が示されます。 レポートの<SPAN style="FONT-WEIGHT: bold">場所欄は VoIP コールレグの相手側の IP アドレスで、ゲートウェイの CDR レコードから取得されます。 CallManager (CCM)環境では、シグナリングおよびメディア エンドポイントは 2 個別の IP アドレスです。 リストされている IP アドレスは信号 エンドポイント(すなわち、CallManager)です。 CDR レコードにシグナリング エンド ポイントではなくメディア IP アドレスを記録できるようにするために、DDTS(CSCds23283)が発行されています。 この方法を使用すれば、不良コールをサブネット別にソートできます。 通常、サブネットはサイトごとに複数存在するため、この方法の方がより詳しい情報が得られます。 これらのサブネットの一部だけしか QoV の問題がない場合、どのサブネットに問題があるのかを特定できます。

「Packet Voice Calls with Quality of Service Traps」レポートが 1 日に 1 回、自動的に実行されるように、Telemate スケジューラを設定することをお勧めします。 完成したレポートは、選ばれた運営スタッフに電子メールで送信できます。 これらのスタッフ メンバーは過去 24 時間について QoV の監査を実行します。 レポートは少なくとも 1 か月の間アーカイブ保存し、その間実行されたネットワーク変更と QoV の劣化とを相互に関連付けできるようにします。

注: CallManager 環境で運用しているゲートウェイでレポート作成を適切に実行するためには、Telemate バージョン 4.7 以降が必要です。 それよりも前のバージョンの Telemate では、ローカルの内線番号が常にゲートウェイの POTS 側にあると見なされます。 CallManager 環境では、ローカルの内線番号(IPPhone)はゲートウェイの VoIP 側にあります。 その結果、4.7 よりも前のバージョンの Telemate では混乱が生じ、レポートの意味が制限されます。

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

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


関連情報


Document ID: 13940