Cisco Unified Communications Manager 呼詳細レコード アドミニストレーション ガイド リリース 8.6(1)

呼情報レコードのタイプ

---

この章では、Cisco Unified Communications Manager で生成される 2 種類の呼情報レコードについて説明します。

Cisco Unified Communications Manager では、呼詳細レコード（CDR）および呼管理レコード（CMR、診断レコードとも呼ばれる）という 2 種類の呼情報レコードが生成されます。CDR には、コールのエンドポイントやその他のコール制御/ルーティングに関する情報が格納されます。CMR には、コールの音声ストリームの品質に関する診断情報が格納されます。各 CDR に複数の CMR が存在することが可能です。

CMR は、Cisco Unified IP Phone、Cisco 7960 シリーズの電話機、およびメディア ゲートウェイ コントロール プロトコル（MGCP）ゲートウェイでサポートされています。コールにこれらのエンドポイントのいずれかが含まれている場合は、コール終了後に CMR レコードが生成されます。コールの各エンドポイントは個別の CMR レコードを生成します。コール診断をサポートしていないエンドポイントがコールに含まれる場合、そのエンドポイント用のレコードは生成されません。Cisco 7960 電話機から H.323 ゲートウェイへのコールでは、（Cisco 7960 電話機から）CMR レコードが 1 つ生成されます。

CDR は、次の 2 つの globalCallID カラムによって CMR に関連付けられます。

• globalCallID_callManagerId

• globalCallId_callId

Call Diagnostics サービス パラメータが True に設定されている場合、コールごとに最大 2 つの CMR が生成されます。コールのタイプ（電話会議、コール転送、転送されたコール、ゲートウェイ経由のコールなど）ごとに、レコード セットが生成され、コールの終了時に ASCII ファイルに書き込まれます。コールが完了または失敗した場合にのみ CDR および CMR が生成されます。Cisco Unified Communications Manager は、CDR または CMR に対する後処理は実行しません。

この章は次のトピックで構成されています。

• 「グローバル コール ID」

• 「番号変換」

• 「パーティションおよび番号」

• 「タイムスタンプ」

• 「コール クリア原因」

• 「IP アドレス」

• 「関連項目」

• 「関連資料」

グローバル コール ID

Cisco Unified Communications Manager は、Cisco Unified IP Phone がオフフックになるたびに、またはコールがゲートウェイから受信されるたびに、グローバル コール ID（GlobalCallID_callId）を割り当てます。GlobalCallID_callId は、クラスタ内の他のコール サーバで実行されるコールとは無関係に、Cisco Unified Communications Manager サーバ上で連続的に割り当てられます。Cisco Unified Communications Manager は 1,000 コールごとに GlobalCallID_callId 値をディスク ファイルに書き込みます。Cisco Unified Communications Manager が何らかの理由で再起動された場合、次の GlobalCallID_callId には次の 1000 番目の数が割り当てられます。

たとえば、コールが成功した場合、CDR 内の GlobalCallID_callId 値は 1001 になります。次のコールの GlobalCallID_callId 値は 1002 になり、以下同様に指定されます。Cisco Unified Communications Manager が再起動された場合、CDR 内の次のコールの値には 2001 が割り当てられます。Cisco Unified Communications Manager がもう一度再起動されるまで、そこから連番が続きます。次に再起動されると、GlobalCallID_callId 値は 3001 になります。

（注） GlobalCallID_callId に割り当てられる最大値は、24 ビットに制限されます。この制限が生じた場合、GlobalCallID_callId 値は 1 にリセットされます。

CDR ファイル内の GlobalCallID_callId は、CDR フラット ファイル内では順番でない可能性があります。GlobalCallID_callId = 1 のコールが GlobalCallID_callId = 2 のコールよりも長く続いた場合、GlobalCallId_callId = 2 用の CDR レコードは、GlobalCallId_callId = 1 の前に書き込まれます。CDR フラット ファイルから GlobalCallID_callId が完全になくなる場合もあります。1 番目の CDR レコードに GlobalCallID_callId = 1 があり、2 番目の CDR に GlobalCallID_callId = 3 がある場合、これは GlobalCallID_callId = 2 の CDR が存在しないことを意味するわけではありません。GlobalCallID_callId = 2 が CDR の生成条件を満たさなかったことになります。1 番目と 3 番目のコールが成功したのに対して 2 番目のコールが完了しなかったために、CDR が生成されなかった可能性があります。または、GlobalCallID_callId = 2 が電話会議の一部である可能性があります。電話会議の各コール レッグには GlobalCallID_callId が割り当てられますが、これは会議の GlobalCallID_callId で上書きされます。元の GlobalCallID_callId は CDR フラット ファイルに現れません。

CDR レコードから [GlobalCallID_callId] フィールドがなくなっている場合、CAR は、その特定のレコードに対するエラーを生成します。CDR エラーの詳細については、『 CDR Analysis and Reporting Administration Guide 』の「Configuring CDR Error Reports」の章を参照してください。

（注） Cisco Unified Communications Manager Release 5.x 以降のリリースでは、Cisco Unified Communications Manager が再起動されても GlobalCallId CDR フィールドの値は保持されます。Release 4.x 以前のリリースでは、GlobalCallId フィールドが時間ベースですが、このフィールドは、トラフィックが混雑した状況で再使用されます。この動作が原因で、お客様の課金アプリケーションに問題が生じたり、CMR と CDR の相関および電話会議と CDR の相関を行う CAR の機能に問題が発生することがあります。Release 5.x 以降のリリースでは、GlobalCallId が再設計されたため、このフィールドの一意の値が少なくとも特定の日数の間保持されます。前回使用された globalCallId_callId 値は、定期的に（x 回のコールごとに）ディスクに書き込まれるようになりました。この値は Cisco Unified Communications Manager の再起動後に取得され、新しい globalCallId_callId 値は、この数に x を足した値で始まります。

番号変換

Cisco Unified Communications Manager は、ユーザがダイヤルする数字の変換を実行できます。CDR には、実際にダイヤルされた数字ではなく、変換された番号が表示されます。

たとえば、多くの企業では、「911」のコールを「9-911」に変換しているので、発信者は緊急時に外線用の番号をダイヤルする必要はありません。このような場合は、ユーザが「911」をダイヤルしても CDR には「9911」が含まれます。

（注） ゲートウェイは、数字が実際にゲートウェイ経由で出力される前に、番号に対してさらに変更を実行できます。CDR には、これらの変更は反映されません。

パーティションおよび番号

CDR 内部では、パーティションが定義されている場合、内線番号とパーティションの組み合わせによって、参照される各電話機を識別します。パーティションが存在する場合、電話機を正確に識別するには、内線番号とパーティションの両方の値が必要になります。これは、内線番号が一意ではないことがあるためです。

コールがゲートウェイ経由で受信される際には、[Partition] フィールドは空白のままです。コールがゲートウェイ経由で発信される際には、[Partition] フィールドはそのゲートウェイが属するパーティションを示します。

ダイヤル プランによって発信者がスピード ダイヤルに # キーを使用できる場合、# キーを使用するとデータベースに記録されます。たとえば、[Called Party Number] フィールドには「902087569174#」のような値が格納されます。

[Party Number] フィールドには、従来の発呼側/着呼側番号の代わりに SIP URI を格納できます。

CDR が使用するパーティション/内線番号を 表 3-1 に示します。

タイムスタンプ

CDR 内のタイムスタンプは、協定世界時（UTC）で示されます。この値は、サマータイムによる変化に左右されません。

32 ビットの符号なし整数によってすべての値を表現します。この符号なし整数の値は、単一の整数としてデータベースから表示されます。このフィールドは、オペレーティング システムから取得された time_t 値を示します。

表 3-2 に、CDR に含まれる UTC タイムスタンプを示します。

コール クリア原因

CDR には、OrigCause および DestCause の 2 つのコール クリア原因コードがあります。発信側がコールを切断すると、OrigCause に値が入力されます。着信側がコールを切断するか、またはコールが拒否されると、DestCause に値が入力されます。値が入力されなかった場合、原因コードの値はゼロを示します。

表 6-2 に、ITU 仕様 Q.850 に準拠したコール クリア原因コード値を示します。オンネット コール レッグの場合は、Cisco Unified Communications Manager によって原因コードの値が決定されます。オフネット コール レッグの場合は、遠端のスイッチによって原因コードの値が決定されます。

IP アドレス

IP アドレスは、システムに符号なし整数として保存されます。CDR ファイルでは、IP アドレスは符号付き整数として表示されます。符号付き 10 進値を IP アドレスに変換するには、この値が実際には符号なしの数字であることを考慮して、まず 16 進数に変換します。この 32 ビットの 16 進値は、逆順の 4 バイトを表しています（Intel 標準）。IP アドレスを求めるには、バイトの順序を逆にして、各バイトを 10 進数に変換します。この結果の 4 バイトが、ドット付き 10進表記で示される IP アドレスの 4 バイトのフィールドになります。

（注） IP アドレスの下位バイトに最上位ビット セットが含まれている場合、ファイルには負数が表示されます。

たとえば、IP アドレス 192.168.18.188 は -1139627840 として表示されます。この IP アドレスを変換するには、次の手順を実行します。

ステップ 1 データベースの表示（-1139627840）を 16 進値に変換します。
16 進値は 0xBC12A8C0 になります。

ステップ 2 次に示すように、16 進数のバイトの順序を逆にします。
CO A8 12 BC

ステップ 3 次に示すように、この 4 バイトを 16 進数から 10 進数に変換します。
192 168 18 188

ステップ 4 IP アドレスはドット付き 10 進表記で表示されます。
192.168.18.188

CDR で作業を行うときに、CAR データベース内の他の表を読み込んで、各 CDR のデバイス タイプに関する情報を取得する必要があることがあります。これは、デバイス テーブル内のデバイスと CDR にリストされている IP アドレス間の相互関係が直接的なものではないためです。

関連項目

• 「Cisco 呼詳細レコードについて」

• 「CDR の処理方法」

• 「呼管理レコードについて」

関連資料

次のマニュアルには、CDR に関する詳細情報が記載されています。

• 『 CDR Analysis and Reporting Administration Guide 』

• 『Cisco Unified Serviceability Administration Guide 』