Cisco Unified Communications Manager 呼詳細レコード アドミニストレーション ガイド リリース 9.0(1)
呼情報レコードのタイプ
呼情報レコードのタイプ
発行日;2013/07/24   |   ドキュメントご利用ガイド   |   ダウンロード ;   この章 pdf   ,   ドキュメント全体 pdf    |   フィードバック

呼情報レコードのタイプ

この章では、Cisco Unified Communications Manager によって作成される呼詳細レコード(CDR)および呼管理レコード(CMR、呼診断レコードとも呼ばれる)という 2 種類の呼情報レコードについて説明します。

呼情報レコードのタイプ

Cisco Unified Communications Manager では、呼詳細レコード(CDR)および呼管理レコード(CMR、診断レコードとも呼ばれる)という 2 種類の呼情報レコードが生成されます。 CDR には、コールのエンドポイントやその他のコール制御/ルーティングに関する情報が格納されます。 CMR には、コールの音声ストリームの品質に関する診断情報が格納されます。 1 つの 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

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 の前に書き込まれます。 GlobalCallID_callIds は CDR フラット ファイルから完全に欠落する場合があります。 1 番目の CDR レコードの GlobalCallID_callId が 1 で、2 番目の CDR の GlobalCallID_callId が 3 である場合でも、GlobalCallID_callId が 2 の CDR が欠落していることを意味するわけではありません。 値が 2 の GlobalCallID_callId は、CDR を生成するための基準に一致していませんでした。 1 番目と 3 番目のコールが正常であるものの、2 番目のコールがまだ完了していない場合、あるいは値が 2 の GlobalCallID_callId が会議コールに参加している場合には、CDR の生成に失敗することがあります。 会議コールの各コール レッグには、会議の 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 では次の表に示すパーティション/内線番号を使用します。

表 1 CDR 内のパーティション/内線番号

電話番号

説明

callingPartyNumber

コールを発信した通話者です。 転送コールの場合は、転送された通話者が発信者になります。

originalCalledPartyNumber

この番号は、番号変換が実行された後に元の着信者を指します。

finalCalledPartyNumber

転送されたコールの場合、この番号はコールを受信した最後の通話者を指します。

転送されていないコールの場合、このフィールドは元の着信者を示します。

lastRedirectDn

転送されたコールの場合、このフィールドはコールをリダイレクトする最後の通話者を指します。

転送されていないコールの場合、このフィールドはコールをリダイレクト(転送または会議)する最後の通話者を指します。

callingPartyNumberPartition

この番号は、[callingPartyNumber] フィールドに関連付けられているパーティション名を示します。 Cisco Unified Communications Manager では別のパーティションにあって同じ内線番号を持つ複数の Cisco Unified IP Phone をサポートしているため、このフィールドはこの番号を一意に識別します。

ゲートウェイ経由で着信するコールの場合、このフィールドは空白のままになります。

originalCalledPartyNumberPartition

この番号は、[originalCalledPartyNumber] フィールドに関連付けられているパーティション名を示します。 Cisco Unified Communications Manager では別のパーティションにあって同じ内線番号を持つ複数の Cisco Unified IP Phone をサポートしているため、このフィールドはこの番号を一意に識別します。

ゲートウェイ経由で発信するコールの場合、このフィールドは、そのゲートウェイを指すルート パターンに関連付けられているパーティション名を示します。

finalCalledPartyNumberPartition

この番号は、[finalCalledPartyNumber] フィールドに関連付けられているパーティション名を示します。 Cisco Unified Communications Manager では別のパーティションにあって同じ内線番号を持つ複数の Cisco Unified IP Phone をサポートしているため、このフィールドはこの番号を一意に識別します。

ゲートウェイ経由で発信するコールの場合、このフィールドは、そのゲートウェイを指すルート パターンに関連付けられているパーティション名を示します。

lastRedirectDnPartition

この番号は、[lastRedirectDn] フィールドに関連付けられているパーティション名を示します。 Cisco Unified Communications Manager では別のパーティションにあって同じ内線番号を持つ複数の Cisco Unified IP Phone をサポートしているため、このフィールドはこの番号を一意に識別します。

ゲートウェイ経由で発信するコールの場合、このフィールドは、そのゲートウェイを指すルート パターンに関連付けられているパーティション名を示します。

outpulsedCallingPartyNumber

デバイスからアウトパルスされた発信者番号です。

outpulsedCalledPartyNumber

デバイスからアウトパルスされた着信者番号です。

タイムスタンプ

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

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

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

表 2 CDR の UTC タイムスタンプ

フィールド

Format

説明

dateTimeOrigination

UTC

発信コールの場合、このフィールドはデバイスがオフフックになった時刻を示します。

着信コールの場合、このフィールドは SETUP メッセージが受信された時刻を示します。

このフィールドには常に値が入力されます。

dateTimeConnect

UTC

このフィールドは、デバイスが接続された時刻を示します。

コールが接続されなかった場合、このフィールドはゼロを示します。

dateTimeDisconnect

UTC

このフィールドは、コールが切断された時刻を示します。 コールが接続されなかった場合でも、このフィールドは設定されます。 時刻は UTC として保存されます。

このフィールドには常に値が入力されます。

コール クリア原因

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

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

符号付き 10 進数値を 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 アドレス間の相互関係が直接的なものではないためです。