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

概要

この文書は、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 つのツールです。 これらのトピックは、当社のウェブサイトに掲載されている別のドキュメントで説明されています。

前提条件

要件

このドキュメントの読者は次のトピックについての専門知識を有している必要があります。

• Cisco Voice ManagerおよびTelemate

使用するコンポーネント

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

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

表記法

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

音声品質の概要

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

• ボイス品質の測定
• ITU G.113 の概要

ボイス品質の測定

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：全体的なラウドネス評価が最適でないために生じる障害や、回線ノイズが高い場合の障害。

• Iq:PCMタイプの量子化歪みに起因する障害。

• Idte：送話者のエコーが原因の障害。

• Idd：一方向の長い送信時間（遅延）が原因で生じる音声通信の問題。

• Ie：特殊な機器、特に波形以外の低ビットレートコーデックによって発生する障害。

Cisco IOSソフトウェアがItotを計算すると、IoとIqは無視でき、Idteは0に設定されます。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
0	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を計算する際には、人間の期待因子AでItotを減少する方法を考慮します。

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、Iq = 0、Idte = 0;Idd = 3;Ie = 7。Itot = 10となります。

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

Icpif = Itot - A = 10 - 5 = 5

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

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

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

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

• 制限
• ゲートウェイの設定
• CVM および Telemate のアーキテクチャ
• 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

コールがItot値20で完了すると仮定します。ゲートウェイは、この数値から期待係数5を引き、Icpif値15を与えます。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 の数	0
				合計	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 では混乱が生じ、レポートの意味が制限されます。

関連情報

• ユニファイドコミュニケーション製品のサポート
• Cisco IP Telephony のトラブルシューティング
• テクニカル サポートとドキュメント – Cisco Systems