Cisco Unified Communications Manager CDR Analysis and Reporting アドミニストレーション ガイド Release 6.1(1)

CDR 管理

CDR Management（CDRM; CDR 管理）機能とは、次の各機能をサポートするバックグラウンド アプリケーションのことです。

• Cisco Unified Communications Manager ノードから CDR リポジトリ ノードに CDR/CMR ファイルを収集する。

• CDR リポジトリ ノード上の CDR/CMR ファイルを保守する。

• サードパーティ製のアプリケーションが SOAP インターフェイスを介して CDR/CMR ファイルをオンデマンドで取得できるようにする。

• ファイル名検索のオンデマンド要求を受け入れる。

• クラスタ内の個々のノードから CDR リポジトリ ノードに CDR/CMR ファイルをプッシュする。

• CDR リポジトリ ノードから最大 3 台のカスタマー課金サーバに CDR/CMR ファイルを送信する。

• CDR リポジトリ ノード上の CDR/CMR ファイルのディスク使用量を監視する。

• 正常に送信された CDR/CMR ファイルを定期的に削除する。フラット ファイルの保存に使用するストレージの量を設定できます。後処理アプリケーションは、バッファリングされた履歴データを後で取得して、喪失データ、破損データ、または欠落データを再取得できます。CDRM 機能は、フラット ファイル形式を認識しないため、ファイルの内容を操作しません。

CDRM は、2 つのデフォルト サービス（CDR Agent と CDR Repository Manager）および 1 つのアクティブ サービス（CDR onDemand Service）で構成されています。

CDR Agent

CDRM 機能の一部として、Cisco Unified Communications Manager クラスタ内の各ノード上の常駐コンポーネントが CDR Agent として機能します。Cisco Unified Communications Manager と CDR Agent の両方が動作しているノード上では、Cisco Unified Communications Manager によって CDR が CDR フラット ファイル（CSV 形式）に書き込まれます。このとき、コール処理モジュールによって特殊な制御文字（"_"）がファイル名の前に付けられ、このファイルが転送に使用できないことを示します。この制御文字が付いていない場合、このファイルは転送に使用できると見なされ、指定された CDR リポジトリ ノードに送信されます。正常に転送されると、このファイルのローカル コピーは削除されます。

CDRM 機能では、信頼性が最優先されます。CDR は非常に重要な財務データを含むため、この機能の目的は CDR が一切失われないようにすることです。クラスタ内の Cisco Unified Communications Manager ノードは、CDR のフラット ファイルへの書き込み、既存のフラット ファイルのクローズ、新しいフラット ファイルのオープンを継続的に行っています。書き込まれるレコードの数は、コール タイプやコール中に発生する重大な変化（コールの終了、転送、リダイレクト、分割、結合など）によって異なります。

CDR Repository Manager

Cisco Unified Communications Manager クラスタ内部で、CDR Repository Manager の 1 つのインスタンスが CDR リポジトリ ノード上で動作します。Cisco Unified Communications Manager ノードから受信された CDR ファイルを管理し、指定されたカスタマー/サードパーティの課金サーバに CDR ファイルを定期的に送信します。

CDR ファイルが CDR リポジトリ ノードに到達すると、CDR Repository Manager がこれを検出します。CDR ファイルは、このファイルの作成時にファイル名に挿入された UTC タイムスタンプで示される日付別のディレクトリにアーカイブされます。

CDRM 設定で外部の課金サーバが指定されている場合、ファイルへのソフト リンクが宛先別のディレクトリに作成されます。CDR Repository Manager のファイル送信コンポーネントがこのソフト リンクを検出すると、指定された方法で宛先にファイルを送信します。正常に送信されると、宛先別ディレクトリのソフト リンクは削除されます。

各 Cisco Unified Communications Manager ノードは、最大 1 時間にわたって毎分 1 つの CDR ファイルと 1 つの CMR ファイルを生成できます。プロビジョニングを介して CDR Repository ノードに CDR ファイルを保存するための最大ディスク容量を設定できます。CDR Repository Manager のファイル マネージャ コンポーネントは、1 時間ごとに動作します。ファイル マネージャが動作すると、設定された保存期間を超える日付を持つファイルが削除されます。また、ディスク使用量が最高水準点を超えていないかどうかもチェックされます。最高水準点を超えている場合、処理済みの CDR ファイルは、最低水準点に達するまで古いものから順に削除されます。ただし、削除対象の CDR ファイルが指定された課金サーバに正常に送信されていない場合、そのファイルは CDR リポジトリに残され、通知またはアラームが生成されます。設定されたメンテナンス ウィンドウが表示されている間にフラグ ファイルが作成され、CDR onDemand Service による CDR ファイルへのアクセスが拒否されます。このフラグ ファイルは、メンテナンス ウィンドウが終了すると削除されます。

CDR Repository Manager およびカスタマー課金サーバを設定するための詳細な手順については、『 Cisco Unified Communications Manager Serviceability アドミニストレーション ガイド 』の「CDR Repository Manager の設定」の項を参照してください。

CDR onDemand Service

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

また CDR onDemand Service は、特定の CDR ファイルを指定された宛先に（s）FTP 経由で送信する要求も処理できます。システムは、リポジトリの CDR ファイルにアクセスする必要がある場合、CDR リポジトリ ノード上で CDR onDemand Service をアクティブにすることができます。メンテナンス ウィンドウが表示されている間は、サービスを使用できません。CDR onDemand Service の詳細については、『Cisco Unified Communications Manager Developers Guide for Release 6.1(1)』を参照してください。

コール情報レコードのタイプ

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

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

• globalCallID_callManagerId

• globalCallId_callId

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

この項では、次のトピックを取り上げます。

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

• 「番号変換」

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

• 「タイムスタンプ」

• 「コール終了原因コード」

グローバル コール ID

Cisco Unified Communications Manager は、Cisco Unified IP Phone がオフフック状態になるたびに、またはコールがゲートウェイ経由で受信されるたびに、グローバル コール ID（GlobalCallID）を割り当てます。

CDR テーブル（ 表10-1 ）は、コールの終了時に CDR に書き込まれる CDR を、書き込まれる順に示しています。アクティブ コールの GlobalCallID は、CDR テーブルには表示されません。その他のグローバル ID も、CDR テーブルに表示されないことがあります。たとえば、会議コールの各コール レッグには GlobalCallID が割り当てられますが、これは会議の GlobalCallID に上書きされます。この場合、元の GlobalCallID は CDR に表示されません。

この CDR テーブルに GlobalCallID 3 のエントリが含まれていないのは、このレコードが取得されたときに、そのコールがアクティブだったためです。この表では、GlobalCallID 5 は GlobalCallId 4 よりも先に表示されているのは、GlobalCallID 5 コールが GlobalCallID 4 コールよりも先に終了したためです。

番号変換

Cisco Unified Communications Manager は、ユーザがダイヤルした番号を変換できます。変換された番号（実際にダイヤルされた番号とは異なる）は、CDR に表示されます。

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

（注） 番号が実際にゲートウェイ経由で出力される前に、ゲートウェイでさらに番号を修正することができます。CDR は、このような修正を反映しません。

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

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

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

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

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

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

タイムスタンプ

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

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

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

コール終了原因コード

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

表10-8 に、ITU 仕様 Q.850 ごとのコール終了原因コードを示します。オンネット コール レッグの場合、Cisco Unified Communications Manager によってコール終了原因コードの値が決まります。オフネット コール レッグの場合、終端スイッチによってコール終了原因コードの値が決まります。

IP アドレス

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

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

たとえば、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 のデバイス タイプに関する情報を取得する必要があることがあります。これは、Device テーブル内のデバイスや CDR に記録されている IP アドレス間の相互関係が直接的なものではないためです。

成功したオンネット コール

2 台の Cisco Unified IP Phone 間でコールが成功すると、コールの終了時に 1 つの CDR が生成されます。

成功したオンネット コールの CDR の例

次の表には、2 つの例が含まれています。

• A：発信者が切断する 60 秒のコール

• B：着信側が切断する 60 秒のコール

放棄呼

接続時間ゼロのコールのロギングは、オプションのアクションです。接続時間がゼロのコールのロギングが有効になっている場合、次のアクションが発生します。

• すべてのコールで CDR が生成される。

• コールが放棄された場合（電話機を一旦オフフックにしてから再びオンフックにした場合など）、各フィールドにはデータは格納されない。この場合、originalCalledPartyNumber、finalCalledPartyNumber、これらに関連付けられているパーティション、destIpAddr、および dateTimeConnect フィールドはすべて空白のままです。接続されていないコールはすべて、接続時間が 0 秒になります。コールが放棄された場合、原因コードには 0 が格納されます。

• ユーザが電話番号をダイヤルし、接続前にそのコールを放棄した場合、FirstDest フィールドと FinalDest フィールドおよびこれらに関連するパーティションには、電話番号とそのコールが拡張されるはずだったパーティションが格納されます。DestIp フィールドは空白のままで、接続時間は 0 秒になります。

放棄呼の CDR の例

次の表には、2 つの例が含まれています。

• A：内線 2001 が一旦オフフック状態になってからオンフック状態になった（CdrLogCallsWithZeroDurationFlag は True に設定されている）。

• B：内線 2001 が 2309 に電話したが、応答がある前に 2001 が電話を切った（放棄した）。

話し中のコールまたは送信先が不正なコール

このようなコールは通常のコールとしてログに記録され、該当するフィールドにデータが格納されます。Calling または Called Party Cause フィールドには、なぜコールが接続されなかったかを示す原因コードが格納され、Called Party IP および Date/Time Connect フィールドは空白のままです。接続時間ゼロのコールはログに記録されなくても、失敗したコールはすべてログに記録されます（CdrLogCallsWithZeroDurationFlag は True または False に設定され、接続時間はゼロ、
DateTimeConnect の値もゼロ）。

話し中のコールまたは送信先が不正なコールの CDR の例

次の表には、3 つの例が含まれています。

• A：PSTN 番号へのコール、相手が話し中（原因 17 = ユーザが話し中）。

• B：PSTN 番号へのコール、番号が存在しない（原因 1 = 番号が使用不可）。

• C：PSTN トランクに異常があるため、PSTN へのコールが失敗（原因 38 = ネットワークの異常）。

短時間コール

CdrLogCallsWithZeroDurationFlag に True が設定され、接続時間が 1 秒未満の短時間コールは、CDR では接続時間はゼロと表示されます。コールの実際の接続時間を示す DateTimeConnect フィールドでは、このようなコールを失敗したコールとは区別しています。失敗したコール（接続されなかった）では、この値はゼロになります。

短時間コールの CDR の例

次の表には、接続時間が 1 秒未満で着信側が切断した、成功したオンネット コールの例が含まれています。

自動転送またはリダイレクトされたコール

自動転送されたコールに対して 1 つの CDR が生成され、Calling Party、Original Called Number、Last Redirecting Number、Final Called Number、および関連パーティションが表示されます。コールが 3 回以上自動転送された場合、中間の自動転送パーティは CDR に書き込まれません。

コール転送は、複数の条件（常時、話し中、および応答なし）で発生します。コールが自動転送される条件は、CDR に書き込まれません。

自動転送されたコールの CDR は、originalCalledPartyNumber フィールドおよび
originalCalledPartyNumberPartition フィールド以外は、通常のコールの CDR と同じになります。これらのフィールドには、コールの発信者が最初にダイヤルした送信先の電話番号およびパーティションが格納されます。コールが自動転送された場合、finalCalledPartyNumber フィールドと
finalCalledPartyNumberPartition フィールドの値は異なり、コールの最終送信先の電話番号およびパーティションが格納されます。

また、コールが自動転送されると、lastRedirectDn フィールドおよび lastRedirectDnPartition フィールドには、コールを自動転送またはリダイレクトした最後の電話機の電話番号およびパーティションが格納されます。

自動転送またはリダイレクトされたコールの CDR の例

次の表には、2 つの例が含まれています。

• A：PSTN から内線 2001 へのコールが 2309 に自動転送され、そこでコールが応答されます。

• B：PSTN から内線 2001 へのコールが 2309 に自動転送され、さらにボイス メッセージング システムに自動転送されます。

ピックアップ コール

Cisco Unified Communications Manager には、ピックアップおよび自動ピックアップの 2 つのピックアップ モードがあります。次の各項で、これらのコールについて説明します。

• 「ピックアップ」

• 「自動ピックアップ」

ピックアップ

ピックアップ コールは、自動転送されたコールと同様に動作します。ピックアップ コールの CDR は、originalCalledPartyNumber フィールドおよび originalCalledPartyNumberPartition フィールド以外は、通常のコールの CDR と同じになります。これらのフィールドには、コールの発信者が最初にダイヤルした送信先の電話番号およびパーティションが格納されます。

コールがピックアップされた場合、finalCalledPartyNumber フィールドおよび
finalCalledpartyNumberPartition フィールドの値は異なり、コールをピックアップした電話機の電話番号およびパーティションが格納されます。また、コールがピックアップされると、lastRedirectDn フィールドおよび lastRedirectDnPartition フィールドには、コールをリダイレクトした最後の電話機の電話番号およびパーティションが格納されます。

origTermination、destTermination、lastRedirect、および Join OnBehalfOf フィールドには 16（ピックアップ）およびリダイレクト原因フィールドには 5（ピックアップ）が格納されます。

ピックアップの CDR は、ピックアップ、グループ ピックアップ、および他のピックアップというすべてのピックアップ タイプで同じに見えます。

ピックアップ コールの CDR の例

1. PSTN から内線 2000、2001、および 2002（同じピックアップ グループ）にコールが着信します。

2. 内線 2002 が、2001 で呼出音が鳴っているコールをピックアップします。

3. 内線 2002 が、このコールに応答し、このコールは PSTN 発信者と内線 2002 の間で接続されます。

自動ピックアップ

自動ピックアップは、自動応答するコール ピックアップと同様に動作します。コールは自動接続されるため、最後の応答ソフトキーを押す必要はありません。自動ピックアップには 2 つの CDR が生成され、これらの Call ID は同じになります。

最初の CDR は元のコール用に生成されます。この CDR の origTerminationOnBehalfOf フィールドおよび destTerminationOnBehalfOf フィールドは 16（ピックアップ）になります。これは、このコールがピックアップ機能のために終了したことを示します。

2 番目の CDR は、ピックアップされた後の最後のコール用です。この CDR の lastRedirectOnBehalfOf フィールドおよび joinOnBehalfOf フィールドには 16（ピックアップ）が設定されます。これは、このコールがピックアップ機能のために結合したことを示します。lastRedirectReason には、リダイレクト原因 5（ピックアップ）が格納されます。

自動ピックアップの CDR は、自動ピックアップ、自動グループ ピックアップ、および他の自動ピックアップというすべての自動ピックアップ タイプで同じに見えます。

自動ピックアップの CDR の例

1. PSTN から内線 2001 にコールが着信します。2001 および 2002 は同じピックアップ グループに属しています。

2. 内線 2002 が、2001 で呼出音が鳴っているコールをピックアップします。

3. コールは PSTN 発信者と内線 2002 の間で自動接続されます。

転送されたコール

コール転送は非常に複雑なため、1 つの CDR だけでコール転送に必要なすべてのデータを示すことはできません。コールが転送されるたびに、Cisco Unified Communications Manager はそのコールの CDR を終了して新しい CDR を開始します。

次に示すように、転送されたコールには複数の CDR がログに記録されます。

1. パーティ A からパーティ B への元のコール。

2. 転送する側（パーティ A または B）から転送先（パーティ C）へのコール。

3. 転送される側（パーティ A または B）から転送先（パーティ C）へのコール。

最初の CDR は、最初に発信されたコールを表します。2 番目の CDR は、転送の開始に使用されるセットアップ コール（打診/通知）を表します。3 番目の CDR は、転送されたコール自体を表します。最初の 2 つの CDR の origCause_value および destCause_value には、スプリット（126）が設定されます。

また、origCallTerminationOnBehalfOf フィールドおよび destCallTerminationOnBehalfOf フィールドには転送（10）が設定され、これらのコールが転送に関係したことを示します。コールの転送されたレッグの joinOnBehalfOf フィールドには転送（10）が設定され、このコールが転送の結果であることを示します。このため、転送のすべてのレッグを 1 つのコールに結合することができます。

転送されたコールの CDR の例

次の例は、すべてを網羅しているわけではありませんが、上記のような環境で生成されるレコードを示しています。この例は、転送されたコールに対してどのようなレコードが生成されるかを理解するのに役立ちます。

例 1

A が B にコールし、A は B を C に転送します。この場合、次の 3 つのコールがログに記録されます。

1. A から B へのコール

2. A から C へのコール

3. B から C へのコール

コールがブラインド転送だった場合、A から C へのコールの接続時間はゼロ秒になります。コールが打診転送だった場合、すべてのコールの接続時間はゼロ以外になります。Original Called Party フィールドおよび Call Party Number フィールドの値は、同じになります。

例 2

A が B にコールし、B は A を C に転送します。この場合、次の 3 つのコールがログに記録されます。

1. A から B へのコール

2. B から C へのコール

3. A から C へのコール

コールがブラインド転送だった場合、B から C へのコールの接続時間はゼロ秒になります。コールが打診転送だった場合、すべてのコールの接続時間はゼロ以外になります。Original Called Party フィールドおよび Call Party Number フィールドの値は、同じになります。

例 3

A が B にコールし、B が A を C にブラインド転送します。C が D に無応答時転送します。この場合、次のコールがログに記録されます。

1. A から B へのコール

2. B から C へのコール

3. A から D へのコール

コールがブラインド転送だったため、B から C へのコールの接続時間はゼロ秒になります。A から D へのコールの Original Called Party フィールドには「C」が、Called Party Number フィールドには「D」がセットされます。

打診なしの転送

打診なしのコール転送のプロセスには、3 つの CDR の作成が含まれます。最初の CDR には元の 2 つのパーティ（A と B）間のコールが、2 番目の CDR には転送するパーティ（A）と新しいパーティ（C）間の（接続時間ゼロの）コールが、3 番目の CDR には B と C との間のコールが反映されます。

コールが保留されている時間を反映する CDR はありません。コールが PSTN ゲートウェイを経由する場合、このコールの保留中、CDR に反映されない料金が課せられます。

打診なしの転送の CDR の例

次の表には、3 つの例が含まれています。

• A：内線 2001 から PSTN 番号へのコールで 120 秒間の通話を行います。

• B：内線 2001 が内線 2002 に打診なしの転送（接続時間ゼロ）を開始します。

• C：内線 2001 が転送を完了し、コールを切断し、他の 2 つのパーティ間のコールが残ります。

打診付きの転送

打診付きの転送は、中間コールの接続時間ゼロでないこと以外は、基本的に打診なしの転送と同じ動作をします。

打診なしの転送と同様に、Cisco Unified Communications Manager は 3 つの CDR を作成します。最初の CDR には元の 2 つのパーティ（A と B）間のコールが、2 番目の CDR には転送するパーティ（A）と新しいパーティ（C）間の打診コールが、3 番目の CDR には B と C の間のコールが反映されます。

打診付きの転送の CDR の例

次の表には、3 つの例が含まれています。

• A：内線 2001 から PSTN 番号へのコールで 120 秒間の通話を行います。

• B：内線 2001 が保留中の PSTN コールを発信して内線 2002 にコールし、30 秒間の通話を行います。

• C：内線 2001 が転送を完了し、コールを切断し、他の 2 つのパーティ間のコールが残ります。

会議コール

会議コールの CDR には、動作上重要な要素が 3 つあります。

1. 会議が 2 つのパーティだけになると、この 2 つのパーティは直接接続され、会議リソースは解放されます。この変化により、会議コールの最後の 2 つのパーティ間のコールに対して、追加の CDR が生成されます。

たとえば、4 人（Amy、Dustin、Spencer、Ethan）の人物が会議コールに接続されている場合、Ethan が電話を切ると、会議ブリッジ（Amy、Dustin、Spencer）に接続された会議コールには 3 人が残ります。Spencer が電話を切ると、会議コールには 2 人（Amy と Dustin）だけが残ります。システムは Amy と Dustin を直接結合し、会議リソースは解放されます。Amy と Dustin の直接結合により、会議の最後の 2 つのパーティ間に追加の CDR が作成されます。

2. システムは、会議の司会者情報を CDR の Comment フィールドに追加します。この情報により、会議の司会者が特定されます。このため、打診コールを調べてだれが会議の司会者であるかを判断する必要がなくなります。この情報の例を次に示します。

Comment フィールド = "ConfControllerDn=1000;ConfControllerDeviceName=SEP0003E333FEBD"

• 会議の司会者の DN とデバイス名により、会議の司会者が一意に特定されます。シェアドラインの場合、デバイス名が必要です。

• コールが複数の会議コールに関係している場合、Comment フィールドには、複数の会議司会者情報が格納されています。会議が 2 つのパーティだけになり、どちらか一方のパーティが別の会議を開始すると、このような状況が発生することがあります。このような場合、Comment フィールドの最後の会議の司会者情報によって会議の司会者が特定されます。

3. 参加者を追加したパーティ（リクエスタ パーティと呼ばれる）は、CDR の Comment フィールドに表示されます。リクエスタ情報のタグには、ConfRequestorDn および
ConfRequestorDeviceName が含まれます。参加者を削除するよう要求したパーティ（ドロップ リクエスタ）は、CDR の Comment フィールドに表示されます。ドロップ リクエスタ情報のタグには、DropConfRequestorDn および DropConRequestorDeviceName が含まれます。

会議の一部であるコールには、ログに記録される複数のレコードがあります。生成される CDR の数は、会議に参加するパーティの数によって異なります。会議に参加する各パーティに 1 つの CDR、最初に発信されたコールに 1 つの CDR、および他のパーティを会議に参加させるために使用した各セットアップ コールに 1 つの CDR がそれぞれ存在します。このため、3 つのパーティからなるアドホック会議では、次の 6 つの CDR が存在します。

• 元のコールに 1 つの CDR

• 会議に接続されているパーティに 3 つの CDR

• 各セットアップ コールに 1 つの CDR

• 会議の最後の 2 つのパーティに 1 つの CDR

発信レッグ ID および着信レッグ ID を調べて、セットアップ コールを適切なコール レッグに関連付けることができます。

会議ブリッジ デバイスは、Cisco Unified Communications Manager にとって特別な意味があります。会議ブリッジへのコールは、会議ブリッジ デバイスへのコールとして表示されます。「b0019901001」という形式の特殊な番号は、会議ブリッジ ポートを示します。実際の方向に関係なく、すべてのコールが会議ブリッジへの方向で表示されます。セットアップ コールの CDR を調べることで、各コールの元の方向を判断できます。

会議に接続されているコール レッグでは、次の各フィールドに、それぞれ対応する値が格納されます。

• finalCalledPartyNumber：会議ブリッジ「b0019901001」を表します。

• origCalledPartyRedirectOnBehalfOf：会議（4）が設定されます。

• lastRedirectRedirectOnBehalfOf：会議（4）が設定されます。

• joinOnBehalfOf：会議（4）が設定されます。

• comment：会議の司会者を特定します。

最初に発信されたコールおよびパーティを会議に参加させるために使用されたすべてのセットアップ コールには、次の各フィールドに、それぞれ対応する値が格納されます。

• origCallTerminationOnBehalfOf：会議（4）が設定されます。

• destCallTerminationOnBehalfOf：会議（4）が設定されます。

会議コールの CDR の例

次の表には、以下の例が含まれています。

• 2001 から 2309 へのコールです。

• 60 秒後、ユーザ 2001 が Cisco Unified IP Phone の「会議」キーを押し、PSTN 番号「3071111」にダイヤルします。

• 3071111 が応答して 20 秒間通話し、その後 2001 が会議キーを押して会議を終了します。

• 会議で 360 秒間の通話が行われます。

• 各コール レッグは、会議ブリッジへのコールとして表示されます。コールの実際の方向に関係なく、会議ブリッジへのコールとして表示されます。

• 3071111 が電話を切り、2001 と 2309 が会議に残ります。この会議には 2 つのパーティだけが残ったため、会議機能により両者は直接結合され、さらに 55 秒間通話します。

ミートミー会議

ミートミー会議は、あらかじめ決められた時刻に、複数のパーティが個々に会議ブリッジにダイヤルすることで発生します。

Cisco Secure Conference 機能では、既存の callSecuredStatus フィールドを使用して、コールが満たしている最も高いセキュリティ ステータスを表示します。ミートミー会議では、会議への参加を試みたもののミートミー会議のセキュリティ レベルに達していないコールは、終了原因 = 58（ベアラ機能は現在使用できません）で切断されます。

ミートミー会議の CDR の例

次の表には、以下のシナリオの CDR の例が含まれています。5001 はダイヤルイン番号を表します。会議ブリッジ デバイスは Cisco Unified Communications Manager にとって特別な意味があり、会議ブリッジへのコールは自動転送されたコールとして表示されます。つまり、ユーザ A があらかじめ決められた番号（5001）に電話すると、そのコールは会議ブリッジ ポートに自動転送されます。会議ブリッジ ポートは、「b0019901001」という形式の特殊な番号で表示されます。

• ユーザ A（2001）は、電話番号 5001 を使用してミートミー会議ブリッジにコールします。

• ユーザ B（2002）は、電話番号 5001 を使用してミートミー会議ブリッジにコールします。

• ユーザ C（2003）は、電話番号 5001 を使用してミートミー会議ブリッジにコールします。

アドホック会議のリンク

高度なアドホック会議リンク機能では、アドホック会議を個々の参加者のように別のアドホック会議に追加することによって、複数のアドホック会議を互いにリンクすることができます。また、個々の参加者をアドホック会議に追加するために使用できる方法で、アドホック会議を別のアドホック会議に追加することもできます。

高度なアドホック会議リンク機能によって生成される CDR には、OrigConversationId と呼ばれるフィールドがあります。このフィールドは、リンクされた会議に関係する会議ブリッジに関連しています。CDR の Comment フィールドには、ConfRequestorDN タグおよび ConfRequestorDeviceName タグが追加されます。これらのタグは、会議の司会者以外の参加者による参加者の追加/削除を示します。

会議リンクには、次の 2 つのタイプがあります。

• 線形：参加している会議に直接リンクできるアドホック会議は 2 つだけです。

• 非線形：3 つ以上のアドホック会議を別の会議に直接リンクできます。このタイプのリンクは、会議リソースに悪影響を与える可能性があるため、デフォルトでは許可されていません。

参加による線形アドホック会議リンクの CDR の例

次の表には、以下のシナリオの CDR の例が含まれています。

• Alice（1000）が Bob（1001）にコールします。これは元のコールです。

• Bob（1001）が Carol（1002）を会議に参加させます。これは打診コールです。

• Dave（1003）が Carol（1002）にコールします。これは元のコールです。

• Dave（1003）は Ed（1004）を会議に参加させます。これは打診コールです。

• 2 つの異なる会議が作成されます。Carol は両方の会議に参加しています。この時点で、CDR1、CDR2、CDR3、および CDR4 が生成されます。

• Carol（1002）は、会議ブリッジ（b002990122）を介して 2 つの会議に参加します。この時点で CDR5 が生成されます。

• Dave（1003）は、会議ブリッジ（b002990122）を介して 2 つの会議に参加します。この時点で CDR6 が生成されます。

• Ed（1004）が会議を退席します。CDR7 が生成されます。

• Dave（b002990122）が会議を退席します。CDR8 が生成されます。

• Alice（1000）が会議を退席します。CDR9 が生成されます。

• Bob（1001）が会議を退席します。CDR10 が生成されます。

• Carol（1002）が会議を退席します。CDR11 が生成されます。

前の表の続きです。

優先コール（MLPP）

優先コールは、優先レベル フィールドが CDR に設定されること以外は、他のコールと同様に行われます。また、より高い優先レベルのコールが他のコールより優先されると、原因コードはプリエンプションの原因を示します。

優先コールの CDR の例

次の表には、以下のシナリオの CDR の例が含まれています。

• ユーザ A（2001）が優先パターン（優先レベル 2）にダイヤルして別の IP Phone にコールします。

• ユーザ A（2001）が優先パターン（優先レベル 3）にダイヤルして別の IP Phone にコールします。

• ユーザ A がより高い優先レベルのコールを別のネットワークから受信します（優先レベル 1）。

• より高い優先レベルのコールが最初のコールより優先されます。

迷惑呼

コールが迷惑呼として識別された場合（ボタン押下）、ローカル ネットワーク（Cisco Unified Communications Manager）によってコールにフラグが設定されます。Comment フィールドに迷惑呼のフラグが設定されます。

迷惑呼の CDR の例

次の表には、迷惑呼のマークが付けられたカスタマー コールの CDR の例が含まれています。

Conference Drop Any Party

Conference Drop Any Party 機能は、新しい原因コード以外は他のコールと同じに見えるコールを終了します。原因コードは、この機能によって終了したコールを示します。

Conference Drop Any Party の CDR の例

次の表には、会議に接続され、この機能によって廃棄されたコールの CDR の例が含まれています。

即時転送（ボイス メッセージング システム宛）

即時転送コールの CDR は、 origCalledPartyRedirectOnBehalfOf フィールドおよび lastRedirectRedirectOnBehalfOf フィールドに値が設定されること以外は、自動転送されたコールと同様に生成されます。

即時転送の CDR の例

次の表には、このシナリオの CDR の例が含まれています。

ビデオ コール

次の表には、以下のシナリオのビデオ コールの CDR の例が含まれています。

• 発呼側 51234 が着信側 57890 にコールします。

• 100 = H.261

• 187962284 = 172.19.52.11

• 288625580 = 172.19.52.17

• 320 - 320

ビデオ コールの CDR の例

• 2 = QCIF

コール モニタリングおよびコール録音

コール モニタリングおよびコール録音の CDR は、既存の CDR のフィールドを使用して生成されます。

モニタリングと録音では、モニタリングする側のコールおよび録音する側のコールのメディアは単方向です。単方向メディアの CDR では、コールの一方に対するメディア フィールドは空白のままです。

コール モニタリングの CDR の destConversationID フィールドは、モニタリングされる側のコールの CDR のエージェント コール レッグ ID と一致し、コール モニタリングの CDR とモニタリングされる側のコールの CDR が関連付けられます。

2 つのコール録音の CDR の origConversationID フィールドは、録音する側のコールの CDR のエージェント コール レッグ ID と一致し、コール録音の CDR と録音される側のコールの CDR が関連付けられます。

コール モニタリングの CDR の例

次の表には、以下のシナリオのコール モニタリングの CDR の例が含まれています。

• 例 A：カスタマー 9728134987 がエージェント 30000 にコールし、エージェントが応答します。スーパーバイザ 40003 がこのコールをモニタリングします。モニタリングする側のコールの destConversationID は、モニタリングされる側のコールの destLegCallIdentifier と一致します。

• 例 B：エージェント 30000 がカスタマー 9728134987 にコールし、カスタマーが応答します。スーパーバイザ 40003 がこのコールをモニタリングします。モニタリングする側のコールの destConversationID は、モニタリングされる側のコールの origLegCallIdentifier と一致します。

コール録音の CDR の例

次の表には、以下のシナリオで、録音する側のコールの CDR の例が含まれています。

• 例 A：カスタマー 9728134987 がエージェント 30000 にコールし、エージェントが応答します。録音機能により、録音デバイス宛に 2 つの録音する側のコールが作成されます。この処理によって、追加の CDR が 2 つ（1 つはエージェント音声用、もう 1 つはカスタマー音声用）作成されます。録音する側の CDR の origConversationID は、録音される側の CDR の
destLegCallIdentifier と一致します。この例では、カスタマーが電話を切ります。

• 例 B：エージェント 30000 がカスタマー 9728134987 にコールし、カスタマーが応答します。録音機能により、録音デバイス宛に 2 つの録音する側のコールが作成されます。この処理によって、追加の CDR が 2 つ（1 つはエージェント音声用、もう 1 つはカスタマー音声用）作成されます。録音する側の CDR の origConversationID は、録音される側の CDR の
origLegCallIdentifier と一致します。この例では、エージェントが電話を切ります。

AAC コールおよび iLBC コール

Advanced Audio Codec（AAC）とは、改良された音声忠実度を提供する帯域幅の音声コーデックを規定するものです。また、このコーデックは、ビット レートの低い以前のコーデックと同等またはそれ以上の音声品質を提供します。AAC には次の機能があります。

• AAC コールに対して、コーデックは Media_Payload_AAC 42 を指定する。

• maxFramesPerPacket は 1 を指定する。

• Internet Low Bit Rate Codec（iLBC）は、フレームが損失するロスの大きいネットワークにおける音声品質の劣化に対応する。iLBC コールに対して、コーデックは Media_Payload_ILBC = 86 を指定する。

AAC コールおよび iLBC コールの CDR には、オーディオ帯域幅のフィールドが追加されます。

帯域幅のフィールドには、次の表に基づいて値が格納されます。

AAC コールの CDR の例

次の表には、AAC コーデックを使用するコールの CDR の例が含まれています。

発呼側 51234 が着信側 57890 にコールします。

iLBC コールの CDR の例

次の表には、iLBC コーデックを使用するコールの CDR の例が含まれています。

発呼側 51234 が着信側 57890 にコールします。

モビリティ

システムでは、次のモビリティ機能がサポートされています。

• Hand-In

• Hand-Out

• Cell Pickup

• Interactive Voice Response（IVR; 自動音声応答）

モビリティ機能を使用するコールごとに、標準 CDR が生成されます。モビリティ機能によってコールが分割、リダイレクトまたは結合されると、対応する OnBehalfOf コードは、モビリティ機能に指定されている新しい値を示します。CAR ローダは、次の OnBehalfOf フィールドをチェックします。

• origCallTerminationOnBehalfOf

• destCallTerminationOnBehalfOf

• origCalledPartyRedirectOnBehalfOf

• lastRedirectRedirectOnBehalfOf

• joinOnBehalfOf

上記のいずれかの OnBehalfOf コードにモビリティ コード 24 が設定されている場合、CDR のモビリティ コール タイプは、CAR ローダによって決まります。モビリティ機能には、4 つの redirectResource コード（Hand-In（コード 303）、Hand-Out（コード 319）、Cell Pickup（コード 335）、および IVR（コード 399））が割り当てられます。

モビリティの CDR の例

デュアルモード フォンの企業固定電話番号が 22285、携帯電話番号が 9728324124 とします。次の表には、以下のシナリオでデュアルモード フォンを使用するモビリティ コールの CDR の例が含まれています。

• 例 A：モビリティ Follow Me：22202 が 22285 にコールし、22285 と 9728324124 の両方で呼出音が鳴ります。携帯電話がこのコールに応答します。80 秒間の通話が行われます。

• 例 B：モビリティ Hand-In：コールが携帯電話に着信します。39 秒間の通話が行われ、デュアルモード フォンが企業ネットワークに接続され、このコールは携帯電話ネットワークから企業ネットワークに切り替えられます。さらに 15 秒間の通話が続きます。

• 例 C：モビリティ Hand-Out：Handout 番号（H 番号）に 555123 が指定されています。企業固定電話番号 22285 にコールが着信します。21 秒間の通話の後、デュアルモード フォンが企業ネットワークから切り離され、携帯電話ネットワークに接続されます。このコールは企業ネットワークから携帯電話ネットワーク（9728324124）に切り替えられます。さらに 39 秒間の通話が続きます。

• 例 D：モビリティ Cell Pickup：22285 へのコールが確立されます。40 秒間の通話の後、Cell Pickup が開始されます。このコールは企業固定電話から携帯電話に切り替えられます。さらに 111 秒間の通話が続きます。

• 例 E：モビリティ IVR：コールが文字列（DID#RemoteDest#TargetNum#）とともに Cisco Unified Communications Manager に着信します。このコールは TargetNum にリダイレクトされます。9728131234 が IVR にコールし、データが収集されます。転送先に 812345 が指定され、このコールは 812345 にリダイレクトされます。コールは 60 秒間接続されます。

インターコム

インターコム機能は、単方向の音声を提供します。このため、CDR にも単方向の音声が反映されます。トークバック インターコムでは双方向の音声があるため、CDR にも双方向の音声が反映されます。

インターコム機能には、パーティション（インターコム パーティション）、およびインターコム コールの識別に使用される既存の CDR パーティション フィールドが必要です。

インターコムの CDR の例

電話機 20000 で、以下のシナリオのインターコムが開始されます。

• 例 A：ウィスパー インターコム：設定済みのインターコム パーティションに「intercom」が指定されています。

• 例 B：トークバック インターコム：電話機 20000 がインターコム ボタンを押します。20001 がトークバックを開始して 20000 と通話します。設定済みのインターコム パーティションは「intercom」を示します。

転送時の元の発呼側

この機能は、Cisco Unity または Cisco Unity Connection が発信したコール転送の打診コールの発呼側番号を変更するものです。打診コールの CDR には、Cisco Unity または Cisco Unity Connection ポートが転送先にコールしたのではなく、元の発信者が転送先にコールしたことが示されます。

この機能は、Cisco Unified Communications Manager のサービス パラメータで設定する必要があります。詳細については、「CDR のサービス パラメータの設定」を参照してください。

転送時の元の発呼側の CDR の例

4001 が 4002 にコールします。4002 はこのコールを 4003 に転送します。この場合、次の 3 つの CDR が生成されます。

• 元のパーティ間のコール（4001 から 4002）

• 転送するパーティ（4002）と最終転送先（4003）間の打診コール

• 転送されたパーティ（4001）から転送先（4003）間のコール

（注） CDR に originalCallingParty フィールドはありません。

Personal Assistant ダイレクト コール

Personal Assistant ダイレクト コールは、打診なしの転送コール タイプと同様に機能します。「打診なしの転送」を参照してください。

Personal Assistant ダイレクト コールの CDR の例

次の表には、以下のシナリオの CDR の例が含まれています。

• ユーザ A（2101）が Personal Assistant ルート ポイント（2000）にコールし、「call User B」と発声します。

• このコールがユーザ B（2105）に転送されます。この場合、ユーザ B はルールを設定していません。

（注） 次の例では、2000 は Personal Assistant に到達するためのメイン Personal Assistant ルート ポイント、21XX は Personal Assistant インターセプタ ルート ポイント、および 2001 ～ 2004 はメディア ポートです。

いずれの場合も、2101 が発信番号になります。

メディア ポートに入ってコールを転送する Personal Assistant インターセプタ

このシナリオは、打診なしの転送および自動転送されたコールと同様の動作をします。「打診なしの転送」および 「自動転送またはリダイレクトされたコール」の項を参照してください。

メディア ポートに入ってコールを転送する Personal Assistant インターセプタの例

次の表には、以下のシナリオの CDR の例が含まれています。

• ユーザ A（2101）が 2105 にダイヤルします。

• Personal Assistant インターセプタ（21XX）がこのコールをピックアップし、メディア ポート（2002）にリダイレクトします。

• Personal Assistant はルール（設定されている場合）に従ってこのコールを処理し、送信先（2105）にコールします。この送信先にルールは設定されていません。

直接送信先に入る Personal Assistant インターセプタ

このシナリオでは、ルールありとルールなしの 2 つのケースが考えられます。

送信先（ルールなし）に直接入る Personal Assistant の CDR の例

次の表には、以下のシナリオの CDR の例が含まれています。

• ユーザ A（2101）が 2105 にダイヤルします。

• Personal Assistant インターセプタ（21XX）がこのコールをピックアップし、ルール（設定されている場合）に従って処理し、送信先（2105）にリダイレクトします。

送信先（ルールあり）に直接入って異なる送信先にコールを自動転送する Personal Assistant の CDR の例

次の表には、以下のシナリオの CDR の例が含まれています。

• ユーザ A（2101）が 2105 にダイヤルします。

• Personal Assistant インターセプタ（21XX）がこのコールをピック アップし、ルールに従って処理します。

• 次に Personal Assistant インターセプタはこのコールを最終送信先（2110）にリダイレクトします。この場合、2105 はコールを内線 2110 に自動転送するルールを設定しています。

複数の送信先に入る Personal Assistant インターセプタ

このシナリオには、複数の異なるケースが考えられます。いずれのケースでも、ユーザ B（2105）は内線 2110 または 2120 に到達するルールを設定しています。発信者が Personal Assistant ルータ ポイント（2000）にコールして「call User B」と発声した場合（ダイレクトのケース）、または発信者がユーザ B（2105）に直接ダイヤルした場合（代行受信のケース）、このルールが有効になります。

複数の送信先に入る Personal Assistant インターセプタの CDR の例

次の各項では、ケースごとに例を説明しています。各表には、これらのシナリオのそれぞれの CDR の例が含まれています。

• 「Personal Assistant ダイレクトでの複数の送信先 2110 および 2120（最初の送信先でコールが受信されるケース）」

• 「Personal Assistant ダイレクトでの複数の送信先 2110 および 2120（2 番目の送信先でコールが受信されるケース）」

• 「Personal Assistant ダイレクトでの複数の送信先 2110 および 2120（3 番目の送信先でコールが受信されるケース）」

• 「Personal Assistant 代行受信での複数の送信先 2110 および 2120（最初の送信先でコールが受信されるケース）」

• 「Personal Assistant 代行受信での複数の送信先 2110 および 2120（2 番目の送信先でコールが受信されるケース）」

• 「Personal Assistant 代行受信での複数の送信先 2110 および 2120（3 番目の送信先でコールが受信されるケース）」

Personal Assistant ダイレクトでの複数の送信先 2110 および 2120（最初の送信先でコールが受信されるケース）

• ユーザ A が Personal Assistant にコールし、「call User B」と発声します。

• ユーザ B が内線 2110 でこのコールに応答します。

Personal Assistant ダイレクトでの複数の送信先 2110 および 2120（2 番目の送信先でコールが受信されるケース）

• ユーザ A が Personal Assistant にコールし、「call User B」と発声します。

• ユーザ B が内線 2120 でこのコールに応答します。

Personal Assistant ダイレクトでの複数の送信先 2110 および 2120（3 番目の送信先でコールが受信されるケース）

• ユーザ A が Personal Assistant にコールし、「call User B」と発声します。

• ユーザ B は内線 2110 でも 2120 でも応答しません。

• Personal Assistant がこのコールを元の送信先（2105）に転送すると、ユーザ B はこの内線で応答します。

（注） このケースでは、2105（元の送信先）は、3 番目の送信先になります。

Personal Assistant 代行受信での複数の送信先 2110 および 2120（最初の送信先でコールが受信されるケース）

• ユーザ A が Personal Assistant にコールし、「call User B」と発声します。

• ユーザ B が内線 2110 でこのコールに応答します。

Personal Assistant 代行受信での複数の送信先 2110 および 2120（2 番目の送信先でコールが受信されるケース）

• ユーザ A が Personal Assistant にコールし、「call User B」と発声します。

• ユーザ B が内線 2120 でこのコールに応答します。

Personal Assistant 代行受信での複数の送信先 2110 および 2120（3 番目の送信先でコールが受信されるケース）

• ユーザ A が Personal Assistant にコールし、「call User B」と発声します。

• ユーザ B は内線 2110 でも 2120 でも応答しません。

• Personal Assistant がこのコールを元の送信先（2105）に転送すると、ユーザ B は応答します。

（注） このケースでは、2110（元の送信先）は、3 番目の送信先になります。