通話詳細記録の概要

この章では、Cisco Unified Communications Manager システムが生成する通話詳細記録 (CDR) の形式とロジックについて説明します。この情報は、請求記録の生成やネットワーク分析などの後処理アクティビティに使用できます。

システムをインストールすると、システムはデフォルトで CDR を有効にしますが、通話管理レコード (CMR) はデフォルトで無効のままになります。 CDR または CMR は、システムの動作中にいつでも有効または無効にできます。変更を有効にするために Unified Communications Manager を再起動する必要はありません。システムはすべての変更に対して数秒以内に応答します。システムは CMR または診断データを CDR データとは別に別々に扱います。

CDR 管理

CDR Management（CDRM）は、バックグラウンドで動作するアプリケーションで、次の機能をサポートしています。

Unified Communications Manager サーバーまたはノードから CDR/CMR ファイルを収集し、CDR レポジトリサーバーまたはノードに送信します。
CAR を設定するサーバーで CDR/CMR ファイルを収集し、維持します。
CDR レポジトリノードまたは CDR サーバーで CDR/CMR ファイルを管理します。
サードパーティのアプリケーションが、必要に応じて SOAP インターフェイスを介して CDR/CMR ファイルを取得できるようにします。
ファイル名検索のオンデマンド要求を受け入れます。
クラスター内の個々のノードから CDR レポジトリノードまたはノードに CDR/CMR ファイルをプッシュします。
FTP/SFTP 経由で CDR/CMR ファイルを最大 3 台の顧客の請求サーバーに送信します。
CAR を設定したサーバー、または CDR レポジトリサーバーもしくはノード上で、CDR/CMR ファイルのディスク使用率を監視します。
正常に配信された CDR/CMR ファイルを定期的に削除します。フラットファイルの保存に使用されるストレージの容量を設定することができます。事前に定義されたストレージの制限があります。ストレージ制限を超える場合、CDR リポジトリマネージャは古いファイルを削除して、事前に設定された最低水位線までディスク使用量を減らします。後処理アプリケーションは、バッファされた履歴データを後で取得して、紛失、破損、欠落データを再取得できます。 CDRM 機能はフラットファイル形式を認識しないため、ファイルのコンテンツを変更することはありません。

Note

CDRM 機能は CDR ファイルと CMR ファイルを同じように扱います。

CDRM は、CDR Agent と CDR Repository Manager の 2 つのデフォルトサービスと、アクティベートサービスである CDR onDemand サービスから構成されます。

CDR エージェント

CDRM 機能の一部として、 Unified Communications Manager がインストールされたサーバーまたはノード上の常駐コンポーネントは CDR エージェントとして動作します。 Unified Communications Manager と CDR エージェントの両方が実行されているサーバーで、 Unified Communications Manager は CDRをカンマ区切り値（CSV）形式の CDR フラットファイルに書き込みます。特殊な制御文字 ("_") で、通話処理モジュールがファイル名の前に付加することで、ファイルが転送できないことを示します。この制御文字が存在しない場合、システムはファイルが転送可能であると想定し、CDR エージェントが指定された CDR レポジトリノードにそれらのファイルを SFTP で転送します。転送に成功すると、システムはファイルのローカルコピーを削除します。

CDRM 機能では信頼性が最優先されます。 CDR は重要な財務データを構成するため、この機能の目標は、CDR が失われないことを保証することです。 Unified Communications Manager は継続的に CDR をフラットファイルに書き込み、既存のフラットファイルを閉じたり、新しいフラットファイルを開いたりします。書き込まれるレコードの数は、通話のタイプと、通話の終了、通話の転送、通話のリダイレクト、通話の分割、通話への参加など、通話中に発生する大きな変更によって異なります。

Note

Linux プラットフォームでは、Unified Communications Manager が生成した CDR/CMR フラットファイルが CDR エージェントによって収集され、SFTP 経由でこれらのファイルがパブリッシャに送信されます。 Windows 版は SFTP をサポートしていません。 Windows プラットフォームでは、CDR エージェントはサブスクライバディスクから共有パブリッシャディスクにファイルを直接コピーします。

CDR Repository Manager

Unified Communications Manager サーバーまたはクラスタ内では、CDR レポジトリマネージャの 1 つのインスタンスが CDR レポジトリサーバーまたはノード上で実行されます。 Unified Communications Manager ノードから受信した CDR ファイルを管理し、FTP/SFTP 経由で指定された顧客/サードパーティ請求サーバーに定期的にファイルを送信します。

ファイルが CDR Repository サーバーまたはノードに到達すると、CDR Repository Manager がそれを検出します。システムは、ファイル作成時にファイル名に付加された UTC タイムスタンプで示される日付専用のディレクトリにファイルを保存します。

CDRM 設定で外部の請求サーバーが指定されている場合、CAR または対応する請求サーバーが有効になっている場合、システムは対応する CAR および請求サーバーの各フォルダに空のファイルを作成します。 CDR エージェントは、CallManager サーバーまたはノードで呼処理コンポーネントによって生成された新しい CDR/CMR ファイルを監視します。 CDR リポジトリノードにファイルを送信し、ファイルがプッシュされた後でローカルコピーを削除します。 CDR リポジトリマネージャのファイル送信コンポーネントがこれらの空のファイルを検出し、指定された方法で送信先にファイルを送信します。配信に成功すると、システムは配信先ディレクトリ中の空のファイルを削除します。

各 Unified Communications Manager は、1 時間につき毎分 1 つの CDR ファイルと 1 つの CMR ファイルを生成できます。プロビジョニングを通じて、CDR リポジトリで CDR ファイルのストレージに使用される最大ディスク容量を設定できます。

CDR リポジトリマネージャのファイルマネージャコンポーネントは 1 時間ごとに実行されます。ファイルマネージャが実行されると、設定された保存期間外の日付のファイルが削除されます。また、ディスク使用率が最高水準点を超えていないかどうかもチェックします。その場合、システムは処理済みの CDR ファイルを最低水位標に達するまで古いファイルから削除していきます。ただし、削除される CDR ファイルが指定された課金サーバーに正常に送信されなかった場合、システムは CDR レポジトリにファイルを残し、通知またはアラームを生成します。システムは、設定されたメンテナンス期間中に、CDR onDemand サービスの CDR ファイルへのアクセスを拒否するフラグファイルを作成します。メンテナンス期間が終了すると、システムはフラグファイルを削除します。

CDR オンデマンドサービス

CDR onDemand サービスは、CDR リポジトリサーバーまたはノード上で動作する、SOAP/HTTPS ベースのサービスです。これは、ユーザーが指定した時間間隔 (最大 1 時間) に基づいて CDR ファイル名リストの SOAP 要求を受信し、要求で指定された継続時間内のすべてのリストを返します。

CDR onDemand サービスはまた、SFTP API を通じて、特定の CDR ファイルを指定された接続先に配信する要求を処理することもできます。すべての SFTP 接続では、各セッションのセットアップでユーザー ID とパスワード情報が必要です。ファイルが送信されるたびに個別の SFTP セッションがセットアップされ、ファイルが送信されるとセッションが閉じられます。システムはリポジトリ内の CDR ファイルにアクセスする必要があるため、CDR リポジトリノードで CDR onDemand サービスをアクティベートできます。システムはメンテナンス期間中のサービスを禁止します。 CDR onDemand サービスの詳細については、『 Cisco Unified Communications Manager 開発者ガイド』を参照してください。

Cisco Unified Communications Manager リリース 12.x 以降のリリースでは、CDR onDemand サービスはデフォルトでは有効になっていません。 CDR onDemand Service を有効にする場合、このサービスを手動でアクティブにする必要があります。 CDR onDemand Service をアクティブにするには、/usr/local/cm/bin/soapservicecontrol2.shCDRonDemandServiceCDRonDemanddeploy8443 コマンドを実行します。

CDR データベースのバックアップと復元

Cisco Unified Communications Manager DRS に、CAR および CDR 災害復旧サービス（DRS）が統合されていることを確認してください。

詳細については、『Cisco Unified Communications Manager アドミニストレーションガイド』を参照してください。

レコードの処理

Unified Communications Manager は、CDR と CMR の 2 つの異なるタイプのコール情報レコードを生成します。 CDR レコードには通話に関する情報が保存されます。 CMR レコードには、コールの音声ストリームの品質に関する情報が格納されます。 CDR レコードは、GlobalCallID callManagerId および GlobalCallID Called の 2 つの GlobalCallID カラムで CMR レコードと関連付けられます。通話シナリオによっては、各 CDR に複数の CMR が存在する場合があります。

Unified Communications Manager が発信または着信すると、システムは通話の終了時に CDR レコードを生成します。システムは CDR をフラットファイル (テキストファイル) に書き込みます。 Unified Communications Manager 内では、呼制御プロセスによって CDR レコードが生成されます。システムは、特定の通話に対して重要な変更（通話の終了、通話の転送、通話のリダイレクト、通話の分割、通話への参加など）が発生すると、レコードを書き込みます。

CDR レコードが有効な場合、通話制御は各通話に対して 1 つ以上の CDR レコードを生成します。システムはこれらのレコードを EnvProcessCdr に送信し、そこでレコードがフラットファイルに書き込まれます。書き込まれるレコードの数は、通話のタイプと通話シナリオによって異なります。診断が有効になっている場合、デバイスは通話ごとに CMR レコードを生成します。システムは、コールに含まれる IP 電話ごと、または Media Gateway Control Protocol (MGCP) ゲートウェイごとに、1 つの CMR レコードを書き込みます。システムはまた、これらのレコードを EnvProcessCdr に送信し、そこでレコードがフラットファイルに書き込まれます。

Unified Communications Manager は、CDR および CMR レコードを生成しますが、レコードの後処理は行いません。システムはレコードをカンマ区切りのフラットファイルに書き込み、定期的に CDR レポジトリに渡します。 CDR および CMR ファイルは、フラットファイル内の特定のファイル名形式を表しています。

ファイル名の形式

次の例は、ファイル名の完全な形式を示しています：tag_clusterId_NodeId_datetime_seqNumber

tag：ファイルのタイプを CDR または CMR のいずれかで示します。
clusterId— Unified Communications Manager データベースが存在するクラスタまたはサーバーを指定します。
nodeId：ノードを識別します
datetime—yyyymmddhhmm 形式の UTC 時間
seqnumber—シーケンス番号

ファイル名の 2 つの例を次に示します。

cdr_Cluster1_01_200404021658_1
cmr_Cluster1_02_200404061011_6125

フラットファイル形式

CDR および CMR フラットファイルの形式は次のとおりです。

1 行目：コンマ区切りのフィールド名リスト
2 行目：コンマ区切りのフィールドタイプリスト
3 行目：コンマ区切りのデータ
4 行目：コンマ区切りのデータ

フラットファイルの例を次に示します。

Line1-"cdrRecordType","globalCallID_callManagerId","globalCallID_callId","origLegCallIdentifier",...
Line2-INTEGER,INTEGER,INTEGER,INTEGER,...
Line3-1,1,388289,17586046,...
Line4-1,1,388293,17586054,...

Note

ゼロ持続時間の CDR ログコールフラグの値が True の場合、システムはすべての通話をフラットファイルに書き込みます。詳細については、本ガイドの CDR サービスパラメータの設定セクションを参照してください。

通話情報のレコードタイプ

Unified Communications Manager は、通話詳細レコード（CDR）と通話管理レコード（CMR、通話診断レコードとも呼ばれます）の 2 つの異なるタイプの通話情報レコードを生成します。 CDR は、通話のエンドポイントおよびその他の通話制御/ルーティングに関する情報を保存します。 CMR には、通話のストリーミング音声の品質に関する診断情報が含まれています。 CDR ごとに複数の CMR が存在できます。

CMR は Cisco Unified IP Phone 、Cisco 7960 シリーズの電話、および Media Gateway Control Protocol (MGCP) ゲートウェイに対応しています。これらのエンドポイントの 1 つが通話に含まれる場合、通話が終了した後に CMR レコードが生成されます。通話中の各エンドポイントが個別の CMR レコードを生成します。通話に通話診断をサポートしていないエンドポイントが含まれる場合、そのエンドポイントのレコードは生成されません。 Cisco7960 電話から H.323 ゲートウェイへの通話は、1 つの CMR レコードを生成します（Cisco 7960 電話から）。

CDR は 2 つの globalCallID カラムで CMR に関連します。

globalCallID_callManagerId
globalCallId_callId

Call Diagnostics サービスパラメータが True に設定されている場合、システムは各コールに対して最大 2 つの CMR を生成します。電話会議、通話転送、転送された通話、ゲートウェイ経由の通話など、通話の各タイプでは、通話の終了時に ASCII ファイルに書き込まれる一連のレコードが生成されます。完了したコールと失敗したコールだけが CDR と CMR を生成します。 Unified Communications Manager は CDR または CMR に対して後処理を行いません。

グローバルコール識別子

Unified Communications Manager は、Cisco Unified IP 電話がフックオフされるたび、またはゲートウェイからのコールが受信されるたびに、グローバル通話識別子（GlobalCallID_callId）を割り当てます。 GlobalCallID_callId は、Unified Communications Manager サーバーでシーケンシャルに割り当てられ、クラスタ内の他の通話サーバーで実行されている通話とは独立しています。 Unified Communications Manager は、1,000 回目の呼び出しごとに GlobalCallID_callId の値をディスクファイルに書き込みます。 Unified Communications Manager が何らかの理由で再起動すると、1000 番目の番号が次の GlobalCallID_callId に割り当てられます。

例えば、発信が成功すると、CDR の GlobalCallID_callId 値は 1001 を指定します。次の発信では、GlobalCallID_callId 値は 1002 を指定します。以下同様になります。 Unified Communications Manager が再起動されると、CDR の次の通話用の値として 2001 が割り当てられます。その数値は、Unified Communications Manager が再び再起動するまで連続します。次の再起動では、GlobalCallID_callId の値は 3001 になります。

Note

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 フラットファイルから完全に欠落している場合があります。最初の CDR レコードに GlobalCallID_callId = 1 があり、2 番目の CDR に GlobalCallID_callId = 3 がある場合、GlobalCallID_callId = 2 の CDR が欠落しているという意味ではありません。 GlobalCallID_callId = 2 は CDR を生成するための基準を満たしていません。 CDR の生成が失敗する原因として、最初と 3 番目のコールは成功したものの、2 番目のコールが完了しなかった場合や、GlobalCallID_callId = 2が電話会議の一部であった場合があります。電話会議の各コールレッグには、電話会議 GlobalCallID_callId で上書きされる GlobalCallID_callId が割り当てられます。元の GlobalCallID_callId は CDR フラットファイルに表示されない場合があります。

GlobalCallID_callId フィールドが CDR レコードにない場合、CAR はその特定のレコードに対してエラーを生成します。詳細は、このガイドの CDR エラーレポートを参照してください。

Note

Unified Communications Manager リリース 5.x 以降の場合、GlobalCallId CDR フィールドの値は、Unified Communications Manager 再起動後も保持されます。リリース 4.x 以前のリリースでは、GlobalCallId フィールドは時間ベースですが、このフィールドはトラフィックが多い状況で再使用されます。この動作のため、顧客の請求アプリケーションで問題が発生する可能性があり、また CAR が CMR と CDR を相関させ、電話会議の CDR を相関させる能力に問題が発生する可能性があります。リリース 5.x 以降のリリースでは、GlobalCallId の再設計により、少なくとも数日間、フィールドが一意の値を保持するようになります。現在は、最後に使用された globalCallId_callId の値が定期的にディスクに書き込まれるようになります（コールの x 回ごと）。この値は Unified Communications Manager の再起動後に取得され、新しい globalCallId_callId 値はこの番号プラス x で始まります。

番号変換

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

例えば、多くの会社が "911" からの発信を "9-911" に変換するため、緊急時に発信者が外線に接続する必要がありません。この場合、ユーザーが "911" をダイヤルしても、CDRには "9911" が含まれます。

Note

ゲートウェイは、桁がゲートウェイを通して実際に出力される前に、番号にさらに変更を加えることができます。 CDR はこれらの変更を反映しません。

パーティションと番号

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

[パーティション（Partition）] フィールドは、コールがゲートウェイを経由して入力されるときは空のままです。通話がゲートウェイを経由して発信する場合、[パーティション] フィールドには、ゲートウェイが属するパーティションが表示されます。

ダイヤルプランで発信者がスピードダイヤル用の # キーを使用することが許可されている場合、# キーは使用時にデータベースに記録されます。例えば、着信者番号フィールドには "902087569174# のような値が含まれます。"

[パーティ番号（Party Number）] フィールドには、従来の発信側/着信側の番号の代わりに、SIP URI が含まれる場合があります。

CDR は次の表に示すパーティション/内線番号を使用します。

Table 1. CDR のパーティション/内線番号
電話番号	説明
callingPartyNumber	この通話を発信しました。転送されたコールの場合、転送された側が発信側になります。
originalCalledPartyNumber	この番号は、桁変換が行われた後に、最初の着信側を指定します。
finalCalledPartyNumber	転送された通話の場合、この番号が最後に着信した通話者を示します。転送以外の通話の場合、このフィールドには元の着信側が表示されます。
lastRedirectDn	転送されたコールの場合、このフィールドはコールをリダイレクトする最後の当事者を示します。非転送通話の場合、このフィールドには、通話を転送 (転送や電話会議など) した最後の当事者が表示されます。
callingPartyNumberPartition	この番号は、CallingPartyNumber フィールドに関連付けられたパーティション名を識別します。 Unified Communications Manager は同じ内線を持つ複数のパーティションの Cisco Unified IP Phone をサポートするため、このフィールドで一意に識別されます。ゲートウェイ経由で発信するコールの場合、このフィールドは空白のままです。
originalCalledPartyNumberPartition	この番号は、OriginalCalledPartyNumber フィールドに関連付けられたパーティション名を識別します。 Unified Communications Manager は同じ内線を持つ複数のパーティションの Cisco Unified IP Phone をサポートするため、このフィールドで一意に識別されます。ゲートウェイ経由で発信するコールの場合、このフィールドはゲートウェイをポイントするルートパターンに関連付けられたパーティション名を指定します。
finalCalledPartyNumberPartition	この番号は、FinalCalledPartyNumber フィールドに関連付けられたパーティション名を識別します。 Unified Communications Manager は同じ内線を持つ複数のパーティションの Cisco Unified IP Phone をサポートするため、このフィールドで一意に識別されます。ゲートウェイ経由で発信するコールの場合、このフィールドはゲートウェイをポイントするルートパターンに関連付けられたパーティション名を指定します。
lastRedirectDnPartition	この番号は、LastRedirectDn フィールドに関連するパーティション名を識別します。 Unified Communications Manager は同じ内線を持つ複数のパーティションの Cisco Unified IP Phone をサポートするため、このフィールドで一意に識別されます。ゲートウェイ経由で発信するコールの場合、このフィールドはゲートウェイをポイントするルートパターンに関連付けられたパーティション名を指定します。
outpulsedCallingPartyNumber	デバイスから送出される発番号。
outpulsedCalledPartyNumber	デバイスから送出される着信側番号。

タイムスタンプ

CDR 内のタイムスタンプは協定世界時 (UTC) で表示されます。この値は、夏時間の変更とは無関係に維持されます。

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

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

Table 2. CDR の UTC タイムスタンプ
フィールド	形式	説明
dateTimeOrigination	UTC	発信コールの場合、このフィールドはデバイスがオフフックになる時間を示します。着信コールの場合、このフィールドはセットアップメッセージを受信した時間を示します。このフィールドは常に入力されます。
接続日時	UTC	このフィールドは、デバイスが接続される時間を示します。通話がつながらない場合、このフィールドには 0 が表示されます。
dateTimeDisconnect	UTC	このフィールドは、通話が切断される時間を表示します。このフィールドは、通話がつながらない場合でも設定されます。時刻は UTC で保存されます。このフィールドは常に入力されます。

コールクリアリングの原因

CDR には、OrigCause と DestCause の 2 つのコールクリアリング原因コードが含まれています。発信側が通話を解放すると、OrigCause が入力されます。終了する側がコールを終了するか、コールが拒否されると、終了原因が入力されます。入力されていない場合、原因コードの値は 0 を示します。

「通話終了原因コード」に、ITU 仕様 Q.850 に基づいてコールクリア原因コード値を示します。オンネットコールレッグの場合、 Unified Communications Manager が原因コードの値を特定します。オフネットコールレッグの場合、遠端スイッチが原因コード値を判別します。

署名付き 10 進数値を IP アドレスに変換する

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

Note

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

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

Procedure

Step 1	データベース表示 ((-1139627840) を 16 進数値に変換します。 16 進数の値は 0xBC12A8C0 と同じです。
Step 2	次に示すように、16 進数バイトの順序を逆にします。 CO A8 12 BC
Step 3	次に示すように、4 バイトを 16 進数から 10 進数に変換します。 192 168 18 188
Step 4	IP アドレスはドット付き 10 進法で表示されます。 192.168.18.188

What to do next

CDR を使用する場合、各 CDR のデバイスタイプに関する情報を取得するために、CAR データベース内の他のテーブルを読み取る必要がある場合があります。デバイステーブル内のデバイスと CDR にリストされている IP アドレス間の相関関係は単純ではないためです。

Cisco Unified Communications Manager コールレポートおよび課金アドミニストレーションガイド、リリース 14 および SU

偏向のない言語

翻訳について

Book Title