Cisco Unified Communications Manager CDR Analysis and Reporting アドミニストレーション ガイド for Cisco Unified Communications Manager Release 6.0(1)
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年5月29日
章のタイトル： Cisco 呼詳細レコードについて
- Personal Assistant ダイレクト コール
- メディア ポートに入ってコールを転送する Personal Assistant インターセプタ
- 直接送信先に入る Personal Assistant インターセプタ
- 複数の送信先に入る Personal Assistant インターセプタ
- 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 会議
- 通常のコール（IP Phone と IP Phone）
- 放棄呼
- 話し中のコールまたは送信先が不正なコール（失敗したコール）
- 自動転送されたコール
- コール ピックアップ
- コール ピックアップ
- 転送されたコール
- 会議コール
- セキュア Meet-Me 会議
- アドホック会議のリンク
- コール パーク
- 優先コール（MLPP）
- 迷惑呼
- 即時転送（ボイスメール宛）
- 割込み
- C割込
- ビデオ コール
- FAC（Forced Authorization Code）
- クライアント証明書コード（CMC）
- セキュリティ保護されたコール
- DTMF 方式
- RSVP
- リダイレクト（3xx）コール
- Replaces コール
- Refer コール
- モニタリングする側のコール
- 録音する側のコール
- AAC コールおよび iLBC コール
- モビリティ
- インターコム コール
Cisco 呼詳細レコードについて
この章では、Cisco Unified Communications Manager Release 6.0(1)（および、それ以降）のシステムで生成される呼詳細レコード（CDR）と呼管理レコード（CMR）の形式とロジックについて説明します。これらの情報は、課金レコードの生成やネットワーク分析などの後処理アクティビティに使用できます。この章では、CDR/CMR ファイルにアクセスする方法およびこれらのファイルのフィールドを解釈する方法について説明します。
システムをインストールした時点では、CDR および CMR はデフォルトで無効になっています。システムが稼働中であれば、いつでも CDR または CMR を有効または無効にできます。変更内容を有効にするために Cisco Unified Communications Manager を再起動する必要はありません。システムは、数秒以内にすべての変更内容に対応します。CMR または診断データは、CDR データとは切り離して有効にされます。
•
「CDR 処理」
• 「Cisco Unified Communications Manager CDR の概要」
• 「CDR 内の Cisco Personal Assistant データの解釈」
• 「関連項目」
• 「関連資料」
CDR 処理
Cisco Unified Communications Manager では、CDR および CMR という 2 種類のコール情報レコードが生成されます。CDR レコードには、コールに関する情報が格納されます。CMR レコードには、コールの音声ストリームの品質に関する情報が格納されます。CDR レコードは、Global CallID callManagerId および GlobalCallID Called という 2 つの GlobalCallID カラムによって CMR に関連付けられます。コール シナリオに応じて、1 つの CDR に対して複数の CMR が存在する場合があります。
Cisco Unified Communications Manager がコールを発信または受信すると、そのコールの終了時に CDR レコードが生成されます。CDR はフラット ファイル（テキスト ファイル）に書き込まれます。Cisco Unified Communications Manager 内部で、コール制御プロセスによって CDR レコードが生成されます。あるコールに重大な変化（コールの終了、転送、リダイレクト、分割、結合など）が発生すると、レコードが書き込まれます。
CDR レコードが有効になっている場合、コール制御によりコールごとに 1 つまたは複数の CDR レコードが生成されます。これらのレコードは EnvProcessCdr に送信され、フラット ファイルに書き込まれます。書き込まれるレコードの数は、コールのタイプやコール シナリオによって異なります。診断が有効になっている場合、デバイスによりコールごとに CMR レコードが生成されます。コールに関係する IP Phone ごと、または Media Gateway Control Protocol（MGCP; メディア ゲートウェイ コントロール プロトコル）ゲートウェイごとに、1 つの CMR レコードが書き込まれます。これらのレコードは EnvProcessCdr にも送信され、フラット ファイルに書き込まれます。
Cisco Unified Communications Manager は CDR レコードおよび CMR レコードを生成しますが、これらのレコードに対する後処理は実行しません。これらのレコードはカンマ区切り形式のフラット ファイルに書き込まれ、定期的に CDR リポジトリに渡されます。CDR ファイルおよび CMR ファイルは、フラット ファイル内で固有のファイル名の形式で表されます。
次の例は、ファイル名の完全な形式を示します。
tag_clusterId_nodeId_datetime_seqNumber
• tag：ファイルのタイプ（CDR または CMR のいずれか）を識別します。
• datetime：UTC 時間（yyyymmddhhmm 形式）。
• cdr_Cluster1_01_200404021658_1
• cmr_Cluster1_02_200404061011_6125
CDR および CMR のフラット ファイルの形式は次のとおりです。
（注） CDR Log Calls With Zero Duration Flag パラメータの値が True の場合、すべてのコールがフラット ファイルに書き込まれます。このパラメータの詳細については、「CDR のサービス パラメータの設定」を参照してください。
Cisco Unified Communications Manager CDR の概要
次の各項では、Cisco Unified Communications Manager で CDR が生成および管理される仕組みについて簡単に説明します。
• 「CDR 管理」
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.0(1)』を参照してください。
コール情報レコードのタイプ
Cisco Unified Communications Manager では、呼詳細レコード（CDR）および呼管理レコード（CMR）という 2 種類のコール情報レコードが生成されます。CDR には、コールのエンドポイントやその他のコール制御/ルーティングに関する情報が格納されます。CMR には、コールの音声ストリームやビデオ ストリームの品質に関する診断情報が格納されます。CDR ごとに複数の CMR が存在することが可能です。
CDR は、次の 2 つの globalCallID カラムによって CMR に関連付けられます。
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）を割り当てます。
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 ビットの符号なし整数によってすべての値を示します。この符号なし整数の値は、単一の整数としてデータベースから表示されます。このフィールドは、Linux オペレーティング システムから取得された time_t value を指定します。
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 つのパーティ間でコールが成功すると、このコールは CDR に記録されます。各 CDR にはすべてのフィールドが含まれていますが、一部のフィールドが使用されていないことがあります。フィールドが使用されていない場合は、CDR 定義テーブルのデフォルト値を参照してください。補足サービスがコールに関係している場合、追加の CDR が書き込まれることがあります。
1 つのコールには、CDR に加えて、エンドポイントごとに 1 つの CMR を生成できます。IP Phone を使用している 2 つのパーティ間でコールが成功すると、2 つの CMR（発信者用に 1 つ、コールの宛先用に 1 つ）が書き込まれます。
この項では、システム内の異なるコール タイプ用に書き込まれる CDR について説明します。
• 「放棄呼」
• 「短時間コール」
• 「会議コール」
• 「迷惑呼」
• 「モビリティ」
• 「インターコム」
成功したオンネット コール
2 台の Cisco Unified IP Phone 間でコールが成功すると、コールの終了時に 1 つの CDR が生成されます。
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|
放棄呼
接続時間ゼロのコールのロギングは、オプションのアクションです。接続時間がゼロのコールのロギングが有効になっている場合、次のアクションが発生します。
• コールが放棄された場合（電話機をいったんオフフックにしてから再びオンフックにした場合など）、各フィールドにはデータは格納されない。この場合、originalCalledPartyNumber、finalCalledPartyNumber、これらに関連付けられているパーティション、destIpAddr、および dateTimeConnect フィールドはすべて空白のままです。接続されていないコールはすべて、接続時間が 0 秒になります。コールが放棄された場合、原因コードには 0 が格納されます。
• ユーザが電話番号をダイヤルし、接続前にそのコールを放棄した場合、FirstDest フィールドと FinalDest フィールドおよびこれらに関連するパーティションには、電話番号とそのコールが拡張されるはずだったパーティションが格納されます。DestIp フィールドは空白のままで、接続時間は 0 秒になります。
• A：内線 2001 がいったんオフフック状態になってからオンフック状態になった（CdrLogCallsWithZeroDurationFlag は True に設定されている）。
• B：内線 2001 が 2309 に電話したが、応答がある前に 2001 が電話を切った（放棄した）。
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|
話し中のコールまたは送信先が不正なコール
このようなコールは通常のコールとしてログに記録され、該当するフィールドにデータが格納されます。Calling または Called Party Cause フィールドには、なぜコールが接続されなかったかを示す原因コードが格納され、Called Party IP および Date/Time Connect フィールドは空白のままです。接続時間ゼロのコールはログに記録されなくても、失敗したコールはすべてログに記録されます（CdrLogCallsWithZeroDurationFlag は True または False に設定され、接続時間はゼロ、
DateTimeConnect の値もゼロ）。
• A：PSTN 番号へのコール、相手が話し中（原因 17 = ユーザが話し中）。
• B：PSTN 番号へのコール、番号が存在しない（原因 1 = 番号が使用不可）。
• C：PSTN トランクに異常があるため、PSTN へのコールが失敗（原因 38 = ネットワークの異常）。
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|
短時間コール
CdrLogCallsWithZeroDurationFlag に True が設定され、接続時間が 1 秒未満の短時間コールは、CDR では接続時間はゼロと表示されます。コールの実際の接続時間を示す DateTimeConnect フィールドでは、このようなコールを失敗したコールとは区別しています。失敗したコール（接続されなかった）では、この値はゼロになります。
次の表には、接続時間が 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 フィールドには、コールを自動転送またはリダイレクトした最後の電話機の電話番号およびパーティションが格納されます。
• 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 は、ピックアップ、グループ ピックアップ、および他のピックアップというすべてのピックアップ タイプで同じに見えます。
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 は、自動ピックアップ、自動グループ ピックアップ、および他の自動ピックアップというすべての自動ピックアップ タイプで同じに見えます。
1. PSTN から内線 2001 にコールが着信します。2001 および 2002 は同じピックアップ グループに属しています。
2. 内線 2002 が、2001 で呼出音が鳴っているコールをピックアップします。
3. コールは PSTN 発信者と内線 2002 の間で自動接続されます。
転送されたコール
コール転送は非常に複雑なため、1 つの CDR だけでコール転送に必要なすべてのデータを示すことはできません。コールが転送されるたびに、Cisco Unified Communications Manager はそのコールの CDR を終了して新しい CDR を開始します。
次に示すように、転送されたコールには複数の CDR がログに記録されます。
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 つのコールに結合することができます。
次の例は、すべてを網羅しているわけではありませんが、上記のような環境で生成されるレコードを示しています。この例は、転送されたコールに対してどのようなレコードが生成されるかを理解するのに役立ちます。
A が B にコールし、A は B を C に転送します。この場合、次の 3 つのコールがログに記録されます。
コールがブラインド転送だった場合、A から C へのコールの接続時間はゼロ秒になります。コールが打診転送だった場合、すべてのコールの接続時間はゼロ以外になります。Original Called Party フィールドおよび Call Party Number フィールドの値は、同じになります。
A が B にコールし、B は A を C に転送します。この場合、次の 3 つのコールがログに記録されます。
コールがブラインド転送だった場合、B から C へのコールの接続時間はゼロ秒になります。コールが打診転送だった場合、すべてのコールの接続時間はゼロ以外になります。Original Called Party フィールドおよび Call Party Number フィールドの値は、同じになります。
A が B にコールし、B が A を C にブラインド転送します。C が 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 に反映されない料金が課せられます。
• 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 の間のコールが反映されます。
• 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 が存在します。
発信レッグ ID および着信レッグ ID を調べて、セットアップ コールを適切なコール レッグに関連付けることができます。
会議ブリッジ デバイスは、Cisco Unified Communications Manager にとって特別な意味があります。会議ブリッジへのコールは、会議ブリッジ デバイスへのコールとして表示されます。「b0019901001」という形式の特殊な番号は、会議ブリッジ ポートを示します。実際の方向に関係なく、すべてのコールが会議ブリッジへの方向で表示されます。セットアップ コールの CDR を調べることで、各コールの元の方向を判断できます。
会議に接続されているコール レッグでは、次の各フィールドに、それぞれ対応する値が格納されます。
• finalCalledPartyNumber：会議ブリッジ「b0019901001」を表します。
• origCalledPartyRedirectOnBehalfOf：会議（4）が設定されます。
• lastRedirectRedirectOnBehalfOf：会議（4）が設定されます。
• joinOnBehalfOf：会議（4）が設定されます。
最初に発信されたコールおよびパーティを会議に参加させるために使用されたすべてのセットアップ コールには、次の各フィールドに、それぞれ対応する値が格納されます。
• origCallTerminationOnBehalfOf：会議（4）が設定されます。
• destCallTerminationOnBehalfOf：会議（4）が設定されます。
• 60 秒後、ユーザ 2001 が Cisco Unified IP Phone の「会議」キーを押し、PSTN 番号「3071111」にダイヤルします。
• 3071111 が応答して 20 秒間通話し、その後 2001 が会議キーを押して会議を終了します。
• 各コール レッグは、会議ブリッジへのコールとして表示されます。コールの実際の方向に関係なく、会議ブリッジへのコールとして表示されます。
• 3071111 が電話を切り、2001 と 2309 が会議に残ります。この会議には 2 つのパーティだけが残ったため、会議機能により両者は直接結合され、さらに 55 秒間通話します。
Meet-Me 会議
Meet-me 会議は、あらかじめ決められた時刻に、複数のパーティが個々に会議ブリッジにダイヤルすることで発生します。
Cisco Secure Conference 機能では、既存の callSecuredStatus フィールドを使用して、コールが満たしている最も高いセキュリティ ステータスを表示します。Meet-me 会議では、会議への参加を試みたものの Meet-me 会議のセキュリティ レベルに達していないコールは、終了原因 = 58（ベアラ機能は現在使用できません）で切断されます。
次の表には、以下のシナリオの CDR の例が含まれています。5001 はダイヤルイン番号を表します。会議ブリッジ デバイスは Cisco Unified Communications Manager にとって特別な意味があり、会議ブリッジへのコールは自動転送されたコールとして表示されます。つまり、ユーザ A があらかじめ決められた番号（5001）に電話すると、そのコールは会議ブリッジ ポートに自動転送されます。会議ブリッジ ポートは、「b0019901001」という形式の特殊な番号で表示されます。
• ユーザ A（2001）は、電話番号 5001 を使用して Meet-me 会議ブリッジにコールします。
• ユーザ B（2002）は、電話番号 5001 を使用して Meet-me 会議ブリッジにコールします。
• ユーザ C（2003）は、電話番号 5001 を使用して Meet-me 会議ブリッジにコールします。
|
|
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|---|---|
アドホック会議のリンク
高度なアドホック会議リンク機能では、アドホック会議を個々の参加者のように別のアドホック会議に追加することによって、複数のアドホック会議を互いにリンクすることができます。また、個々の参加者をアドホック会議に追加するために使用できる方法で、アドホック会議を別のアドホック会議に追加することもできます。
高度なアドホック会議リンク機能によって生成される CDR には、OrigConversationId と呼ばれるフィールドがあります。このフィールドは、リンクされた会議に関係する会議ブリッジに関連しています。CDR の Comment フィールドには、ConfRequestorDN タグおよび ConfRequestorDeviceName タグが追加されます。これらのタグは、会議の司会者以外の参加者による参加者の追加/削除を示します。
• 線形：参加している会議に直接リンクできるアドホック会議は 2 つだけです。
• 非線形：3 つ以上のアドホック会議を別の会議に直接リンクできます。このタイプのリンクは、会議リソースに悪影響を与える可能性があるため、デフォルトでは許可されていません。
次の表には、以下のシナリオの 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 が生成されます。
|
|
CallID-callid |
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|
優先コール（MLPP）
優先コールは、優先レベル フィールドが CDR に設定されること以外は、他のコールと同様に行われます。また、より高い優先レベルのコールが他のコールより優先されると、原因コードはプリエンプションの原因を示します。
次の表には、以下のシナリオの CDR の例が含まれています。
• ユーザ A（2001）が優先パターン（優先レベル 2）にダイヤルして別の IP Phone にコールします。
• ユーザ A（2001）が優先パターン（優先レベル 3）にダイヤルして別の IP Phone にコールします。
• ユーザ A がより高い優先レベルのコールを別のネットワークから受信します（優先レベル 1）。
• より高い優先レベルのコールが最初のコールより優先されます。
|
|
|
|
|
|
|
|
|
迷惑呼
コールが迷惑呼として識別された場合（ボタン押下）、ローカル ネットワーク（Cisco Unified Communications Manager）によってコールにフラグが設定されます。Comment フィールドに迷惑呼のフラグが設定されます。
次の表には、迷惑呼のマークが付けられたカスタマー コールの CDR の例が含まれています。
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|
Conference Drop Any Party
Conference Drop Any Party 機能は、新しい原因コード以外は他のコールと同じに見えるコールを終了します。原因コードは、この機能によって終了したコールを示します。
Conference Drop Any Party の CDR の例
次の表には、会議に接続され、この機能によって廃棄されたコールの CDR の例が含まれています。
|
|
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|
即時転送（ボイスメール宛）
即時転送コールの CDR は、 origCalledPartyRedirectOnBehalfOf フィールドおよび lastRedirectRedirectOnBehalfOf フィールドに値が設定されること以外は、自動転送されたコールと同様に生成されます。
ビデオ コール
次の表には、以下のシナリオのビデオ コールの CDR の例が含まれています。
• 発呼側 51234 が着信側 57890 にコールします。
|
VideoCap_ Codec |
VideoCap_Bandwidth |
VideoCap_Resolution |
|
|
|---|---|---|---|---|
コール モニタリングおよびコール録音
コール モニタリングおよびコール録音の CDR は、既存の CDR のフィールドを使用して生成されます。
モニタリングと録音では、モニタリングする側のコールおよび録音する側のコールのメディアは単方向です。単方向メディアの CDR では、コールの一方に対するメディア フィールドは空白のままです。
コール モニタリングの CDR の destConversationID フィールドは、モニタリングされる側のコールの CDR のエージェント コール レッグ ID と一致し、コール モニタリングの CDR とモニタリングされる側のコールの CDR が関連付けられます。
2 つのコール録音の CDR の origConversationID フィールドは、録音する側のコールの CDR のエージェント コール レッグ ID と一致し、コール録音の CDR と録音される側のコールの CDR が関連付けられます。
次の表には、以下のシナリオのコール モニタリングの CDR の例が含まれています。
• 例 A：カスタマー 9728134987 がエージェント 30000 にコールし、エージェントが応答します。スーパーバイザ 40003 がこのコールをモニタリングします。モニタリングする側のコールの destConversationID は、モニタリングされる側のコールの destLegCallIdentifier と一致します。
• 例 B：エージェント 30000 がカスタマー 9728134987 にコールし、カスタマーが応答します。スーパーバイザ 40003 がこのコールをモニタリングします。モニタリングする側のコールの destConversationID は、モニタリングされる側のコールの origLegCallIdentifier と一致します。
|
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|---|---|---|---|---|---|
次の表には、以下のシナリオで、録音する側のコールの 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 の例が含まれています。
|
|
|
|
|---|---|---|
次の表には、iLBC コーデックを使用するコールの CDR の例が含まれています。
|
|
|
|
|---|---|---|
モビリティ
• Interactive Voice Response（IVR; 自動音声応答）
モビリティ機能を使用するコールごとに、標準 CDR が生成されます。モビリティ機能によってコールが分割、リダイレクトまたは結合されると、対応する OnBehalfOf コードは、モビリティ機能に指定されている新しい値を示します。CAR ローダは、次の OnBehalfOf フィールドをチェックします。
• origCallTerminationOnBehalfOf
• destCallTerminationOnBehalfOf
• origCalledPartyRedirectOnBehalfOf
• lastRedirectRedirectOnBehalfOf
上記のいずれかの OnBehalfOf コードにモビリティ コード 24 が設定されている場合、CAR ローダによって決まる CDR のモビリティ コール タイプは、モビリティ機能に割り当てられている 4 つの redirectResource コード（Hand-In（コード 303）、Hand-Out（コード 319）、Cell Pickup（コード 335）、および IVR（コード 399））になります。
デュアルモード フォンの企業固定電話番号が 22285、携帯電話番号が 9728324124 とします。次の表には、以下のシナリオでデュアルモード フォンを使用するモビリティ コールの CDR の例が含まれています。
• 例 A：モビリティ Follow Me：22202 が 22285 にコールし、22285 と 9728324124 の両方で呼び出し音が鳴ります。携帯電話がこのコールに応答します。80 秒間の通話が行われます。
• 例 B：モビリティ HandIn：コールが携帯電話に着信します。39 秒間の通話が行われ、デュアルモード フォンが企業ネットワークに接続され、このコールは携帯電話ネットワークから企業ネットワークに切り替えられます。さらに 15 秒間の通話が続きます。
• 例 C：モビリティ HandOut：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 パーティション フィールドが必要です。
電話機 20000 で、以下のシナリオのインターコムが開始されます。
• 例 A：ウィスパー インターコム：設定済みのインターコム パーティションに「intercom」が指定されています。
• 例 B：トークバック インターコム：電話機 20000 がインターコム ボタンを押します。20001 がトークバックを開始して 20000 と通話します。設定済みのインターコム パーティションは「intercom」を示します。
|
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|---|
転送時の元の発呼側
この機能は、Cisco Unity または Cisco Unity Connection が発信したコール転送の打診コールの発呼側番号を変更するものです。打診コールの CDR には、Cisco Unity または Cisco Unity Connection ポートが転送先にコールしたのではなく、元の発信者が転送先にコールしたことが示されます。
この機能は、Cisco Unified Communications Manager のサービス パラメータで設定する必要があります。詳細については、「CDR のサービス パラメータの設定」を参照してください。
4001 が 4002 にコールします。4002 はこのコールを 4003 に転送します。この場合、次の 3 つの CDR が生成されます。
• 転送するパーティ（4002）と最終転送先（4003）間の打診コール
• 転送されたパーティ（4001）から転送先（4003）間のコール
|
|
|
|
|---|---|---|
（注） CDR に originalCallingParty フィールドはありません。
CDR 内の Cisco Personal Assistant データの解釈
Cisco Personal Assistant アプリケーションは、着信コールを選択的に処理し、発信コールを支援します。この項では、Personal Assistant の概要を説明し、CDR のシナリオ例を使用して Personal Assistant のコール タイプについて説明します。
Personal Assistant には、次の機能があります。
• ルールベースのコール ルーティング ：Personal Assistant は、ユーザが定めたルールに基づいて着信コールの自動転送や選別を行います。Personal Assistant は、発信者 ID、日時、またはユーザ カレンダー（勤務時間、会議スケジュール、休暇、休業日など）に基づくユーザ会議ステータスに応じて着信コールを処理できます。また、Personal Assistant は選択的にコールを他の電話番号に転送できます。
このため、Personal Assistant は、ユーザが定めるルールに基づいて着信コールをデスクの電話、携帯電話、自宅の電話、またはその他の電話機に転送できます。着信コールは電子メール ベースのページも生成できます。
• 音声対応ディレクトリ ダイヤリング ：Personal Assistant では、相手の名前を発声することによって電話番号をダイヤルできます。Personal Assistant は、企業ディレクトリまたは個人アドレス帳から相手の電話番号を取得します。
• 音声対応ボイスメールの閲覧 ：ユーザは、ボイス コマンドを使用してボイスメール メッセージの閲覧、受信、および削除ができます。
• 音声対応シンプル アドホック会議 ：ユーザは、目的の参加者との会議コールを設定するように Personal Assistant に指示することにより、会議を開始できます。
Personal Assistant には、次のコール タイプがあります。
• 「Personal Assistant ダイレクト コール」
• 「メディア ポートに入ってコールを転送する Personal Assistant インターセプタ」
• 「直接送信先に入る Personal Assistant インターセプタ」
• 「複数の送信先に入る Personal Assistant インターセプタ」
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 はメディア ポートです。
メディア ポートに入ってコールを転送する Personal Assistant インターセプタ
このシナリオは、打診なしの転送および自動転送されたコールと同様の動作をします。「打診なしの転送」および 「自動転送またはリダイレクトされたコール」の項を参照してください。
メディア ポートに入ってコールを転送する Personal Assistant インターセプタの例
次の表には、以下のシナリオの CDR の例が含まれています。
• Personal Assistant インターセプタ（21XX）がこのコールをピックアップし、メディア ポート（2002）にリダイレクトします。
• Personal Assistant はルール（設定されている場合）に従ってこのコールを処理し、送信先（2105）にコールします。この送信先にルールは設定されていません。
直接送信先に入る Personal Assistant インターセプタ
送信先（ルールなし）に直接入る Personal Assistant の CDR の例
次の表には、以下のシナリオの CDR の例が含まれています。
• Personal Assistant インターセプタ（21XX）がこのコールをピックアップし、ルール（設定されている場合）に従って処理し、送信先（2105）にリダイレクトします。
送信先（ルールあり）に直接入って異なる送信先にコールを自動転送する Personal Assistant の CDR の例
次の表には、以下のシナリオの CDR の例が含まれています。
• 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 番目の送信先になります。
Personal Assistant 会議
Personal Assistant 会議は、アドホック会議コール タイプと同様に機能します。詳細については、「会議コール」を参照してください。
次の表には、以下のシナリオの CDR の例が含まれています。
• ユーザ A が Personal Assistant ルート ポイント（2000）にコールして「conference User B (2105) and User C (2110)」と発声します。
• Personal Assistant は、ユーザ B と C をユーザ A の会議に追加します。
|
|
LegCall Identifier |
|
|
|
|
|---|---|---|---|---|---|
|
Party Number |
|
|
|
|
|---|---|---|---|---|
コール シナリオ
2 つのパーティ間の通常のコールは、1 つの CDR に記録されます。各 CDR には、前のシナリオで示されたすべてのフィールドが含まれていますが、一部のフィールドが使用されていない場合があります。フィールドが使用されていない場合、ASCII 文字列のフィールドは空白、数字のフィールドは「0」のままです。補足サービスがコールに参加している場合、追加の CDR が書き込まれることがあります。
CDR に加えて、エンドポイントごとに 1 つの CMR が生成されます。IP Phone を使用している 2 つのパーティ間の通常のコールでは、2 つの CMR（発信者用に 1 つ、コールの宛先用に 1 つ）が書き込まれます。
この項では、さまざまなコール タイプに対して書き込まれるレコードについて説明します。コールごとのすべてのレコードおよび重要なフィールドを要約した表に示しているので、見やすくまた比較しやすくなっています。
• 「通常のコール（IP Phone と IP Phone）」
• 「放棄呼」
• 「話し中のコールまたは送信先が不正なコール（失敗したコール）」
• 「会議コール」
• 「迷惑呼」
• 「割込み」
• 「C割込」
• 「FAC（Forced Authorization Code）」
• 「RSVP」
• 「モビリティ」
通常のコール（IP Phone と IP Phone）
通常のコールでは、コールごとに 3 つのレコード（エンドポイントごとに 1 つの CDR と 2 つの CMR）がログに記録されます。CDR では、「originalCalledPartyNumber」フィールドに「finalCalledPartyNumber」フィールドと同じ電話番号が格納されます。
2 台の Cisco Unified IP Phone 間でコールが成功すると、コールの終了時に 1 つの CDR が生成されます。
• 発信者が 60 秒のコールを終了します。発呼側が電話を切ったため、orig_CauseValue には 16（通常の切断）が設定されます。
|
|
|
• 着信側が 60 秒のコールを切断します。着信側が電話を切ったため、dest_CauseValue には 16（通常の切断）が設定されます。
|
|
|
放棄呼
接続時間ゼロのコールのロギングは、オプションです。通常、このようなレコードは記録されません。接続時間ゼロのコールのロギングが有効になっている場合、すべてのコールで CDR が生成されます。
コールが放棄された場合（電話をいったんオフフックにしてから再びオンフックにした場合など）、各フィールドにはデータは格納されません。この場合、 originalCalledPartyNumber 、
finalCalledPartyNumber 、これらに関連付けられているパーティション、 destIpAddr 、および
dateTimeConnect の各フィールドは空白のままです。接続されなかったコールの 接続時間 は、ゼロ秒になります。コールが放棄されると、原因コードには「0」が設定されます。
ユーザが電話番号をダイヤルし、接続前にそのコールを放棄した場合、origCalledPartyNumber フィールドと finalcalledPartyNumber フィールドおよびこれらに関連するパーティションには、電話番号とそのコールが拡張されるはずだったパーティションが格納されます。 destIPAddress フィールドは空白のままで、 duration にはゼロが設定されます。
• 内線 2001 がいったんオフフック状態になってから、オンフック状態になりました。
|
|
|
• 内線 2001 が 2309 に電話したが、応答がある前に 2001 が電話を切りました（放棄しました）。
|
|
|
話し中のコールまたは送信先が不正なコール（失敗したコール）
このようなコールは、該当フィールドにデータが格納された通常のコールとして記録されます。Calling または Called Party Cause フィールドには、なぜコールが接続されなかったかを示す原因コードが格納され、Called Party IP および Date/Time Connect フィールドは空白のままです。接続時間ゼロのコールが記録されない場合でも、失敗したコールは記録されます。
• PSTN 番号へのコール、パーティが話し中です（原因 17 = ユーザが話し中）。
|
|
|
• PSTN 番号へのコール、番号が存在しません（原因 1 = 番号が使用不可）。
|
|
|
• PSTN トランクに異常があるため、PSTN へのコールが失敗します（原因 38 = ネットワークの異常）。
|
|
|
自動転送されたコール
コール転送では、自動転送されたコールに対してリダイレクト コール プリミティブが使用されます。リダイレクト コール プリミティブを使用する機能では、CDR は同じになります。次のリストは、自動転送されたコールの重要な CDR フィールドの一部を示しています。
• originalCalledPartyNumber には、元の着信側の番号が格納されます。
• finalCalledPartyNumber は、コールに応答した番号を示します。
• lastRedirectDn フィールドは、最後にリダイレクトを実行した番号を示します。
• origCalledPartyRedirectReason は、最初にコールがリダイレクトされた原因を示します。コール転送の場合、このフィールドに格納される値（ 話中転送 =1、無応答時転送 =2、すべてのコールの転送 =15 ）。
• lastRedirectRedirectReason は、最後にコールがリダイレクトされた原因を示します。コール転送の場合、このフィールドに格納される値（ 話中転送 =1、無応答時転送 =2、すべてのコールの転送 =15 ）。
• origCalledPartyRedirectOnBehalfOf フィールドは、最初のリダイレクトでコールをリダイレクトした機能を示します。コール転送の場合、このフィールドは 5（自動転送）を示します。
• lastRedirectRedirectOnBehalfOf フィールドは、最後のリダイレクトでコールをリダイレクトした機能を示します。コール転送の場合、このフィールドは 5（自動転送）を示します。
• CFA の例 ：PSTN から内線 2001 にコールが着信し、このコールは 2309 に自動転送され（CFA）、そこで応答されます。このコールの接続時間は 2 分です。
|
|
|
• 複数のホップ CFA および CFNA の例 ：PSTN から内線 1000 にコールが着信し、このコールは 2000 に自動転送され（CFA）、その後ボイスメール（6000）に自動転送（CFNA）され、そこでメッセージが残されます。
|
|
|
• 複数のホップ CFNA および CFB の例 ：PSTN から内線 4444 にコールが着信し、このコールは 5555 に自動転送され（CFNA）、その後 6666 に自動転送され（CFB）、そこでコールの応答があり、30 秒間の通話が行われます。
|
|
|
コール ピックアップ
Cisco Unified Communications Manager には、次の 2 つのタイプのコール ピックアップがあります。
• 「ピックアップ」
ピックアップ
PSTN から内線 2000、2001、および 2002（同じピックアップ グループ）にコールが着信します。内線 2002 が、2001 で呼出音が鳴っているコールをピックアップします。内線 2002 が、このコールに応答し、このコールにより PSTN 発信者と内線 2002 が接続されます。
|
|
|
自動ピックアップ
自動ピックアップは、自動応答するコール ピックアップと同様に動作します。最後の応答ソフトキーを押す必要はありません。コールは自動的に接続されます。自動ピックアップでは、2 つの CDR が生成されます。これらの CDR の Call ID は同じになります。
• 最初の CDR は、元のコール用に生成されます。この CDR の origTerminationOnBehalfOf フィールドおよび destTerminationOnBehalfOf フィールドの値は、16（ピックアップ）になります。これは、コールがピックアップ機能のために終了したことを示します。
• 2 番目の CDR は、ピックアップされた後の最後のコール用です。この CDR の lastRedirectOnBehalfOf フィールドおよび joinOnBehalfOf フィールドの値は、16（ピックアップ）になります。これは、コールがピックアップ機能のために結合したことを示します。 lastRedirectReason には、リダイレクト原因 5（ピックアップ）が格納されます。
自動ピックアップの CDR は、自動ピックアップ、自動グループ ピックアップ、および他の自動ピックアップというすべての自動ピックアップ タイプで同じに見えます。
• 自動ピックアップの例 ：PSTN から内線 2001 にコールが着信します。2001 および 2002 は同じピックアップ グループに属しています。2002 が、2001 で呼出音が鳴っているコールをピックアップします。このコールは、PSTN 発信者と 2002 を自動的に接続します。2 分間の通話が行われます。
|
|
|
|
コール ピックアップ
レガシー コール ピックアップ コールは、自動転送されたコールと非常によく似た動作をします。レガシー コール ピックアップでは、コール転送と同様にリダイレクト コール制御プリミティブが使用されます。次のリストは、レガシー コール ピックアップ コールの重要な CDR フィールドを示しています。
• originalCallPartyNumber には、元の着信側の番号が格納されます。
• finalCalledPartyNumber は、コールをピックアップしたパーティの番号を示します。
• lastRedirectDn フィールドは、コールがピックアップされたときに呼び出していた番号を示します。
• origCalledPartyRedirectReason は、最初にコールがリダイレクトされた原因を示します。コール ピックアップ コールの場合、このフィールドに格納される値（ コール ピックアップ = 5 ）。
• lastRedirectRedirectReason は、最後にコールがリダイレクトされた原因を示します。コール ピックアップの場合、このフィールドに格納される値（ コール ピックアップ = 5 ）。
• origCalledPartyRedirectOnBehalfOf フィールドは、最初のリダイレクトでコールをリダイレクトした機能を示します。コール ピックアップの場合、このフィールドに格納される値（ ピックアップ = 16 ）。
• lastRedirectRedirectOnBehalfOf フィールドは、最後のリダイレクトでコールをリダイレクトした機能を示します。コール ピックアップの場合、このフィールドに格納される値（ ピックアップ = 16 ）。
PSTN から内線 2001 にコールが着信します。2001 および 2002 は同じピックアップ グループに属しています。2002 が、2001 で呼出音が鳴っているコールをピックアップします。2002 はこのコールに応答し、このコールは PSTN 発信者と 2002 を接続します。2 分間の通話が行われます。
|
|
|
転送されたコール
コールが転送されると、複数の CDR が生成されます。元のコール用に 1 つ、打診コール用に 1 つ、転送された最後のコール用に 1 つの CDR がそれぞれ生成されます。
元のコールの場合、 origCause_value および destCause_value には、コールが分割されたことを示す値（分割 = 393216）がセットされます。 origCallTerminationOnBehalfOf および destCallTerminationOnBehalfOf フィールドには、このコールが転送に関係したことを示す値（転送 = 10）がセットされます。
打診コールの場合、 origCause_value および destCause_value には、コールが分割されたことを示す値（分割 = 393216）がセットされます。 origCallTerminationOnBehalfOf および destCallTerminationOnBehalfOf フィールドには、このコールが転送に関係したことを示す値（転送 = 10）がセットされます。
転送された最後のコールの場合、 joinOnBehalfOf フィールドには、このコールが転送の結果発生したことを示す値（転送 = 10）がセットされます。
次の例は、すべてを網羅しているわけではありませんが、上記のような環境で生成されるレコードを示しています。この例は、転送されたコールに対してどのようなレコードが生成されるかを理解するのに役立ちます。
• 発呼側からのブラインド転送 ：内線 2001 から PSTN 番号へのコールで、通話時間は 120 秒です。2001 が 2002 へのブラインド転送を開始します。 CDR 1 （元のコール）は、内線 2001 から PSTN 番号へのコールで、通話時間 120 秒を示します。 CDR 2 （打診コール）は 2001 から内線 2002 へのコールを示します。 CDR 3 は転送された最後のコールで、2001 は転送を完了し、コールから抜け、PSTN と 2002 間のコールを残します。
|
|
|
|
|
• 発呼側からの打診転送 ：内線 2001 から PSTN 番号へのコールで、通話時間は 60 秒です。2001 が 2002 への打診転送を開始し、転送が完了するまで 10 秒間の通話を行います。転送された最後のコールの通話時間は 360 秒です。 CDR 1 （元のコール）は、内線 2001 から PSTN 番号へのコールを示し、通話時間は 60 秒です。 CDR 2 （打診コール）は、2001 から内線 2002 へのコールを示し、通話時間は 10 秒です。 CDR 3 は転送された最後のコールで、2001 は転送を完了し、コールから抜け、PSTN と 2002 間のコールを残します。
|
|
|
|
|
• 着信側からのブラインド転送 ：50000 から 50001 へのコールで、通話時間は 120 秒です。50001 が 50002 へのブラインド転送を開始します。 CDR 1 （元のコール）は、内線 50001 から 50002 へのコールを示し、通話時間は 120 秒です。 CDR 2 （打診コール）は 50001 から内線 50002 へのコールを示します。 CDR 3 は転送された最後のコールで、50001 は転送を完了し、コールから抜け、50000 と 50002 間のコールを残します。
|
|
|
|
|
• 着信側からの打診転送 ：50000 から 50001 へのコールで、通話時間は 120 秒です。50000 は 50002 へのブラインド転送を開始します。 CDR 1 （元のコール）は、内線 50000 から 50001 へのコールを示し、通話時間は 120 秒です。 CDR 2 （打診コール）は 50000 から内線 50002 へのコールを示します。 CDR 3 は転送された最後のコールで、50000 は転送を完了し、コールから抜け、50001 と 50002 間のコールを残します。
|
|
|
|
|
会議コール
会議の一部であるコールには、ログに記録される複数のレコードがあります。生成される CDR レコードの数は、会議に参加するパーティの数によって異なります。会議に参加する各パーティに 1 つの CDR、最初に発信されたコールに 1 つの CDR、他のパーティを会議に参加させるために使用した各セットアップ コールに 1 つの CDR、および会議内で接続されている最後の 2 つのパーティに 1 つの CDR がそれぞれ存在します。このため、3 つのパーティからなるアドホック会議では、元のコールに 1 つの CDR、会議に接続されたパーティに 3 つの CDR、各セットアップ コールに 1 つの CDR、および会議での最後の 2 つのパーティに 1 つの CDR、合計 6 つの CDR が存在します。発信レッグ ID および着信レッグ ID を調べて、セットアップ コールを適切なコール レッグに関連付けることができます。
会議ブリッジ デバイスは Cisco Unified Communications Manager に対して特別な意味があり、会議ブリッジへのコールは会議ブリッジ デバイスへのコールとして表示されます。「b0019901001」という形式の特殊な番号は、会議ブリッジ ポートを示します。すべてのコールは、実際の方向に関係なく、会議ブリッジへのコールとして表示されます。ただし、セットアップ コールの CDR を調べることによって、各コールの元の方向を判断できます。
会議の司会者情報は、CDR の Comment フィールドに表示されます。この情報の形式は次のとおりです。
Comment フィールド = "ConfControllerDn=1000;ConfControllerDeviceName=SEP0003"
• 会議の司会者の DN とデバイス名により、会議の司会者が一意に特定されます。シェアド ラインの場合、デバイス名が必要です。
• コールが複数の会議コールに関係している場合、Comment フィールドには、複数の会議司会者情報が格納されています。会議が 2 つのパーティだけになり、どちらか一方のパーティが別の会議を開始すると、このような状況が発生することがあります。このような場合、Comment フィールドの最後の会議司会者情報によって会議の司会者が特定されます。
会議に接続されているコール レッグには、次のフィールド情報があります。
• finalCalledPartyNumber フィールドには、会議ブリッジ番号「b0019901001」が格納されます。
• origCalledPtyRedirectOnBehalfOf フィールドには、会議を示す 4 がセットされます。
– lastRedirectRedirectOnBehalfOf フィールドには、会議を示す 4 がセットされます。
– joinOnBehalfOf フィールドには、会議を示す 4 がセットされます。
– Comment フィールドで、会議の司会者が特定されます。
– destConversationID フィールドは、会議のすべてのメンバで同一です。このフィールドを使用して、会議コールのメンバを特定できます。
最初に発信されたコールおよびパーティを会議に参加させるために使用されたすべてのセットアップ コールには、次の特性があります。
• origCallTerminationOnBehalfOf フィールドには、会議を示す 4 がセットされます。
• destCallTerminationOnBehalfOf フィールドには、会議を示す 4 がセットされます。
2001 が「会議」ソフトキーを押して 3071111 にダイヤルします。
307111 が応答して 20 秒間通話し、その後 2001 が会議ソフトキーを押して会議を終了します。
3071111 が電話を切り、2001 と 2309 が会議に残ります。この会議には 2 つのパーティだけが残ったため、会議機能により両者は直接結合され、さらに 55 秒間通話します。
（注） 各会議コール レッグは、会議ブリッジへの発信コールとして表示されます。コールは、コールの実際の方向に関係なく、会議ブリッジへのコールとして表示されます。
|
|
|
|
|
|
|
|
セキュア Meet-Me 会議
次の例は、セキュア Meet-Me 会議の CDR を示しています。35010 がセキュア Meet-Me 会議にコールしますが、35010 は非セキュアな電話機です。35010 が Meet-Me 会議の最低セキュリティ レベルを満たしていないため、このコールは原因コード 58（Meet-Me 会議の最低セキュリティ レベルが満たされていない）で切断されます。
|
|
|
アドホック会議のリンク
アドホック会議リンク機能では、会議の環境に応じてさまざまな CDR が生成されます。次のシナリオは、さまざまな CDR の一部を示しています。
参加による会議リンク
ブリッジ間のコールの方向は、Carol の 2 つのコールのうち、どちらがプライマリであるかによって異なります。プライマリ コールはそのままで、セカンダリ コールは会議にリダイレクトされます。
Alice が Bob にコールし、Bob が Carol を会議に参加させます（会議 1）。Dave が Carol にコールし、Ed を会議に参加させます（会議 2）。2 つの異なる会議が作成されます。Carol は両方の会議に参加しています。この時点で、CDR1、CDR2、CDR3、および CDR4 が生成されます。
Carol が 2 つの会議に結合されます。この時点で CDR5 が生成されます。
残りのパーティが電話を切ると、パーティが退席した順に残りの CDR が生成されます。
転送または直接転送による会議リンク
Alice が Bob にコールし、Bob が Carol を会議に参加させます（会議 1）。Dave が Carol にコールし、Ed を会議に参加させます（会議 2）。2 つの別々の会議が作成され、Carol は両方の会議に参加しています。この時点で、CDR1、CDR2、CDR3、および CDR4 が生成されます。
Carol は、最初の会議へのコールで直接転送（DirTrfr）ソフトキーを押します。Alice と Bob が会議 1 に、Dave と Ed は会議 2 にいます。残りのパーティが電話を切ると、パーティが会議を退席した順に残りの CDR が生成されます。
（注） ブリッジ間のコールの方向は、Carol の 2 つのコールのうち、どちらがプライマリ コールであるかによって異なります。プライマリ コール側が、転送されたコールの発呼側になります。
リンクされた会議からのパーティの削除
CDR は、パーティが会議を退席した順に生成されます。残りのパーティが 2 つだけになると、この 2 つのパーティは直接結合されます。
Alice が Bob にコールし、Bob が Carol を会議に参加させます（会議 1）。Dave が Carol にコールし、Ed を会議に参加させます（会議 2）。2 つの別々の会議が作成され、Carol は両方の会議に参加しています。この時点で、CDR1、CDR2、CDR3、および CDR4 が生成されます。
Carol は、最初の会議へのコールで直接転送（DirTrfr）ソフトキーを押します。Alice と Bob は会議 1 に、Dave と Ed は会議 2 にいます。会議 1 と会議 2 は同時に転送されます。Carol が電話を切り、会議 1 には 2 つのパーティだけが残ります。
会議には 2 つのパーティだけが残っているため、Bob と会議リンクはともに結合されます。この時点で、CDR7、CDR8、および CDR9 が生成されます。Bob は会議 1 の司会者であるため、Bob と会議 2 の間のコールでは Bob が発呼側になります。残りのパーティが電話を切ると、パーティが会議を退席した順に残りの CDR が生成されます。
（注） Bob が司会者ではなく、Bob が会議 1 に参加する前にチェーニングが発生した場合、Bob と会議 2 の間のコールは、CDR に示されている方向と反対方向に生成されます。
会議の最後の 2 つのパーティ間のコールの方向は、だれが会議に最も長くいたかによって異なります。会議に最も長くいたパーティが発呼側になります。
リンクされた会議からのパーティ（司会者）の削除
CDR は、パーティが会議を退席した順に生成されます。残りのパーティが 2 つだけになると、この 2 つのパーティは直接結合されます。
Alice が Bob にコールし、Bob が Carol を会議に参加させます（会議 1）。Dave が Carol にコールし、Ed を会議に参加させます（会議 2）。2 つの別々の会議が作成され、Carol は両方の会議に参加しています。この時点で、CDR1、CDR2、CDR3、および CDR4 が生成されます。
Carol は、最初の会議へのコールで直接転送（DirTrfr）ソフトキーを押します。Alice と Bob は会議 1 に、Dave と Ed は会議 2 にいます。会議 1 と会議 2 は同時に転送されます。Bob が電話を切り、2 つのパーティだけが会議 1 に接続されています。
会議 1 には 2 つのパーティだけが残っているため、Alice と会議リンクは直接結合されます。この時点で、CDR7、CDR8、および CDR9 が生成されます。Alice の方が会議に長くいるため、Alice と会議 2 の間のコールでは Alice が発呼側になります。残りのパーティが電話を切ると、パーティが会議を退席した順に残りの CDR が生成されます。
（注） 会議の最後の 2 つのパーティ間のコールの方向は、だれが会議に最も長くいたかによって異なります。会議に最も長くいたパーティが発呼側になります。
リンクされた会議の削除
Alice が Bob にコールし、Bob が Carol を会議に参加させます（会議 1）。Dave が Carol にコールし、Ed を会議に参加させます（会議 2）。2 つの別々の会議が作成され、Carol は両方の会議に参加しています。この時点で、CDR1、CDR2、CDR3、および CDR4 が生成されます。
Carol は、最初の会議へのコールで 直接転送 （DirTrfr）ソフトキーを押します。Alice と Bob は会議 1 に、Dave と Ed は会議 2 にいます。会議 1 と会議 2 は同時に転送されます。
Bob が参加者ソフトキーを押すと、Alice、Bob、および会議リンク「Conference」がリストに表示されます。Bob は「Conference」を選択し、 削除 ソフトキーを押します。この時点で、CDR7、CDR8、および CDR9 が生成されます。会議リンクが削除され、2 つのパーティが会議に残っています。
残りの 2 つのパーティは結合されます。会議 1 では Alice と Bob が、会議 2 では Dave と Ed が結合されます。残りのパーティが電話を切ると、パーティが退席した順に残りの CDR が生成されます。
|
|
|
|
|
コール パーク
コール パークでは、2 つの CDR（パークされる元のコール用とピックアップまたは復帰されるコール用）が生成されます。これらの CDR の globalCallID_callId は同じになります。この項では、次の CDR の例を取り上げます。
コール パーク ピックアップ
コールがパークされると、そのコールは分割されます。元のコールで CDR が生成されます。この CDR の origTerminationOnBehalfOf および destTerminationOnBehalfOf フィールドには、コール パークを示す 3 がセットされます。
パークされているコールを取得すると、ユーザはオフフック状態になり、パーク コードを入力します。このコールは、パークされているコールと結合されます。ユーザ ピックアップがパークされているコールと結合されるため、このユーザはコールの発信元として扱われ、パークされているユーザは送信先として扱われます。つまり、コールの callingPartyNumber にはこのコールをピックアップしているユーザの電話番号が格納され、 originalCalledNumber および finalCalledNumber にはパークされているユーザの電話番号が格納されます。 lastRedirectDn には、コールをピックアップするために使用されたパーク コードが格納されます。 lastRedirectRedirectReason には、コール パーク ピックアップを示す 8 が格納されます。 lastRedirectRedirectOnBehalfOf には、コール パークを示す 3 が格納されます。
50003 が 50002 にコールし、50002 がパーク ソフトキーを押します。50001 はパーク コード（44444）にダイヤルし、パークされているコールをピックアップします。
|
|
|
|
コール パーク予約
コールがパークされていても、ピックアップされなかった場合は、コール パーク予約タイマーが切れ、そのコールは着信側にリダイレクトされます。この場合、2 つの CDR が生成されます。最初の CDR はコール パーク ピックアップのシナリオと同様ですが、2 番目の CDR は多少異なります。コール ピックアップ予約タイマーが切れると、コールは着信側にリダイレクトされます。
コールがパークされると、そのコールは分割されます。この処理によって、元のコールに対する CDR が生成されます。この CDR の origTerminationOnBehalfOf および destTerminationOnBehalfOf フィールドには、コール パークを示す 3 がセットされます（コール パーク ピックアップのシナリオと同じ）。
コール パーク予約タイマーが切れると、コールは着信側にリダイレクトされます。
origCalledPartyRedirectOnBehalfOf および lastRedirectRedirectOnBehalfOf フィールドにはコール パークを示す 3 がセットされます。 origCalledPartyRedirectReason フィールドにはコール パークを示す 7 が、 lastRedirectRedirectReason フィールドにはコール パークを示す 11 がセットされます。
• コール パーク予約の例 ：50003 が 50002 にコールし、50002 がパーク ソフトキーを押します。パークされているコールはピックアップされず、50002 に戻され、50002 が応答します。
|
|
コールの CDR |
|
優先コール（MLPP）
優先コールは、基本的にはすべてのコール（通常のコール、自動転送されたコールなど）と同じです。CDR の優先レベル フィールドに値がセットされていると、他のコールとの違いが生じます。また、より高い優先レベルのコールが他のコールより優先されると、原因コードはプリエンプションを示します。
• 優先パターン（優先レベル 2）にダイヤルして別の IP Phone にコールします。
|
|
|
• 別のネットワーク（優先レベル 1）からの優先コールを受信します。
|
|
|
|
|
|
|
迷惑呼
コールが迷惑呼として識別された場合（ボタン押下）、ローカル ネットワーク（CCM）によってコールにフラグが設定されます。迷惑呼にフラグを設定するために、「Comment」フィールドが使用されます。
|
|
|
即時転送（ボイスメール宛）
即時転送（IDivert）は、次の 3 つのコール状態で起動できます。
• IDivert 機能は、着信コールの呼び出し中に起動できます。呼び出しに対する CDR はコール転送の場合とよく似ていますが、 origCalledPartyRedirectOnBehalfOf および lastRedirectRedirectOnBehalfOf は、即時転送を示す 14 になります。
• IDivert 機能は、コールの接続中または保留中に起動できます。これらのシナリオでは、2 つの CDR が生成されます。これら 2 つの CDR の globalCallID_CallId フィールドは同じになります。最初の CDR は元の接続に適用され、2 番目の CDR はボイス メッセージング システムにリダイレクトされたコールに適用されます。最初のコールの origTerminationOnBehalfOf および destTerminationOnBehalfOf フィールドには、即時転送を示す 14 がセットされます。
• ボイス メッセージング システムにリダイレクトされたコールの origCalledPartyRedirectOnBehalfOf および lastRedirectRedirectOnBehalfOf には、即時転送を示す 14 がセットされます。
• 警告中の IDivert ：40003 が 40001 にコールし、40001 の呼び出し中に 40001 が IDivert ボタンを押し、コールがボイス メッセージング システム（40000）に転送されます。
（注） コールが警告状態で IDivert によってリダイレクトされた場合、生成される CDR は 1 つだけです。
|
|
|
• 接続中の IDivert ：40003 が 40001 にコールし、40001 がこのコールに応答します。40001 は発信者をボイス メッセージング システムに転送することにし、IDivert ソフトキーを押します。40003 はボイス メッセージング システム（40000）に転送されます。
このコールはリダイレクトの前に接続されていたため、2 つの CDR（1 つは元の接続コール用、もう 1 つはボイス メッセージング システムに転送されたコール用）が生成されます。
|
|
|
|
割込み
シェアド ラインが割込み機能を使用している場合、 origCalledPartyNumber 、 finalCalledPartyNumber および lastRedirectDn は会議ブリッジ番号「b00...」を示します。リダイレクトおよび結合の OnBehalfOf フィールドの値は割込みを示す 15 に、リダイレクト原因フィールドは割込みを示す 114 になります。
• 割込みの例 1 ：40003 が 40001 にコールし、40001 が応答します。別の電話機上のシェアド ライン 40001 が割込みソフトキーを押します。すべてのパーティが会議に参加し、その後、40003 が電話を切ります。
（注） どちらの CDR も同じ globalCallID_callId を持ち、conversationID フィールドは割り込みされたコールの CI（コール ID）にリンクしています。
|
|
|
|
• 割込みの例 2 ：40003 が 40001 にコールし、40001 が応答します。別の電話機上のシェアド ライン 40001 が割込みソフトキーを押します。すべてのパーティが会議に参加し、その後、40001 が電話を切ります。
（注） どちらの CDR も同じ globalCallID_callId を持ち、conversationID フィールドは割り込みされたコールの CI（コール ID）にリンクしています。
|
|
|
|
|
• 割込みの例 3 ：40003 が 40001 にコールし、40001 が応答します。別の電話機上のシェアド ライン 40001 が割込みソフトキーを押します。すべてのパーティが会議に参加し、その後、40001（別のシェアド ラインで別の電話機）が割込みソフトキーを押します。40003 が最初に電話を切ります。
（注） すべての CDR が同じ globalCallID_callId を持ち、conversationID フィールドは割り込みされたコールの CI（コール ID）にリンクしています。
|
|
|
|
|
C割込
C割込機能は、会議機能と非常によく似ています。シェアド ラインが C割込機能を使用している場合、 origCalledPartyNumber、finalCalledPartyNumber および lastRedirectDn は、会議ブリッジ番号「b00...」を示します。リダイレクトおよび結合の OnBehalfOf フィールドの値は会議を示す 4 に、 リダイレクト原因 フィールドは会議を示す 98 になります。
• C割込の例 ：40003 が 40001 にコールし、40001 が応答し、別の電話機上の 40001（シェアド ライン）が C割込ボタンを押します。
|
|
|
|
|
|
|
ビデオ コール
• 例 ：発呼側 51234 が着信側 57890 にコールします。次の例では、100 = H.261、187962284 = 172.19.52.11、288625580 = 172.19.52.17、320 = 320K、および 2 = QCIF とします。
|
|
|
FAC（Forced Authorization Code）
FAC 機能が起動すると、認証の説明、認証レベル、および認証コードの値が CDR に書き込まれます。
• authCodeDescription フィールドには、認証コードの説明が格納されます。
• authorizationLevel フィールドには、認証コードに関連付けられている認証レベルが格納されます。
• authorizationCodeValue フィールドには、認証コードが格納されます。
（注） authorizationCodeValue フィールドが CDR に表示されるのは、Display FAC in CDR サービス パラメータが True に設定されている場合だけです。このパラメータのデフォルト値は False です。「CDR のサービス パラメータの設定」を参照してください。
45000 が 9728134987 にコールします。ユーザは認証コードを要求され、12345 を入力します。FAC コード 12345 はレベル 1、名前は Legal1 と設定されています。発信者はこのコールに応答し、2 分間の通話を行います。Display FAC in CDR サービス パラメータは True に設定されています。
|
|
|
クライアント証明書コード（CMC）
CMC 機能が起動すると、クライアント証明書コードが CDR に書き込まれます。 clientMatterCode フィールドには、発信者が入力したクライアント証明書コードが格納されます。
• 10000 が 2142364624 にコールします。ユーザはクライアント証明書コードを要求され、11111 を入力します。発信者はコールに応答し、10 分間の通話を行います。
|
|
|
セキュリティ保護されたコール
このフィールドは、コールのセキュリティ ステータスを示します。コール中に達成した最も高いセキュリティ レベルが格納されます。たとえば、コールが最初はセキュリティ保護されておらず、後でセキュリティ保護されるようになった場合、コールの別の部分のステータス値が異なっていても、CDR には 1（セキュリティ保護あり）が格納されます。 callSecuredStatus フィールドは、コールのセキュリティ ステータスを示します。
• 暗号化コールの例 ：20000 と 20001 間のコールが暗号化されます。5 分間の通話が行われます。
|
|
|
• 認証されたコールの例 ：20000 と 20001 が認証されます（暗号化はされていません）。10 分間の通話が行われます。
|
|
|
DTMF 方式
これらのフィールドは、コールに使用される DTMF 方式を示します。
• 初期設定なしの例 ：このコール中に使用される DTMF 方式は初期設定なし/ベスト エフォートです。このコールは 1 分間接続された状態になります。
|
|
|
• 優先 OOB の例 ：このコール中に使用される DTMF 方式は優先 OOB です。このコールは 1 分間接続された状態になります。
|
|
|
RSVP
これらのフィールドは、コールの RSVP 予約のステータスを示します。Cisco Unified Communications Manager RSVP CDR ステータス フィールドの値は連結され、コールの最後の 32 個のステータス値が保持されます。
たとえば、コールが「オプション」ポリシーで確立され、最初の RSVP 予約が成功し、その後帯域幅予約が失敗し、コールの途中で数回の再試行後に帯域幅予約が成功した場合、このコールは RSVP 予約が成功した状態で終了します。この CDR では、特定のストリームに対する Unified Communication RSVP 予約ステータスとして、「2:5:2:5:2:5:2」（success:lost_bw:success:lost_bw:success:lost_bw:success）という文字列が表示されます。
• コールが「オプション」ポリシーで確立され、最初の RSVP 予約が成功します。5 分間の通話が行われます。
|
|
|
• コールが「オプション」ポリシーで確立され、最初の RSVP 予約が成功し、その後帯域幅予約が失敗しましたが、再試行後に成功します。1 分間の通話が行われます。
|
|
|
リダイレクト（3xx）コール
次の例は、リダイレクト機能（3xx）に適用される CDR を示しています。
コールがリダイレクト機能（3xx）によってリダイレクトされると、 origCalledPartyRedirectOnBehalfOf および lastRedirectRedirectOnBehalfOf フィールドには、Unified CM リダイレクトを示す 19 がセットされます。 origCalledPartyRedirectReason および lastRedirectRedirectReason には、リダイレクトを示す 162 がセットされます。
• リダイレクトの例 ：SIP 電話機 10010（Cisco Unified Communications Manager に登録済み）上のアクティブな CFA で、CFA 送信先は 10000 です。35010 が、10000 への CFA である 10010 にコールします。このコールは 10010 から 10000 にリダイレクトされます。10000 が、このコールに応答し、1 分間の通話が行われます。
|
|
|
Replaces コール
次の例は、さまざまな Replaces コールの CDR を示しています。
• Invite with Replaces ：SIP 電話機 35010 が SIP 電話機 35020 にコールします。35010 で転送ボタンが押され、コールが SCCP 電話機 3000 に発信されます。3000 がコールに応答し、その後 SIP 電話機 35010 が転送を完了します。転送された最後のコールが、35020 と 3000 の間で発生します。
（注） 転送が完了すると、Invite with Replaces が Cisco Unified Communications Manager に送信されます。
|
|
|
|
• Refer with Replaces ：SIP 電話機 35010 が SCCP 3000 にコールし、35010 で転送ボタンが押され、コールが SCCP 電話機 3001 に発信されます。3001 がコールに応答し、その後 SIP 電話機 35010 が転送を完了します。転送された最後のコールが、3000 と 3001 の間で発生します。
（注） 転送が完了すると、Refer with Replaces が Cisco Unified Communications Manager に送信されます。
|
|
|
|
|
Refer コール
「Replaces コール」で、Refer with Replaces の例を参照してください。
モニタリングする側のコール
次の例は、モニタリングする側のコールの CDR を示しています。
• モニタリングの例 1 ：カスタマー（9728134987）がエージェント（30000）にコールし、エージェントが応答します。スーパーバイザ（40003）がこのコールをモニタリングします。モニタリングする側のコールの destConversationID は、モニタリングされる側のコールの destLegCallIdentifier と一致します。
|
|
|
|
• モニタリングの例 2 ：エージェント（30000）がカスタマー（9728134987）にコールし、カスタマーが応答します。スーパーバイザ（40003）がこのコールをモニタリングします。モニタリングする側のコールの destConversationID は、モニタリングされる側のコールの origLegCallIdentifier と一致します。
|
|
|
|
録音する側のコール
• 録音する側のコールの例 1 ：カスタマー（9728134987）がエージェント（30000）にコールし、エージェントが応答します。録音機能により、録音デバイスへの 2 つの録音する側のコールが作成され、その結果 2 つの CDR（1 つはエージェント ボイス用、もう 1 つはカスタマー ボイス用）が追加されます。録音する側の CDR の origConversationID は、録音される側のコールの destLegCallIdentifier と一致します。この例では、カスタマーが電話を切ります。
|
|
|
|
|
• 録音する側のコールの例 2 ：エージェント（30000）がカスタマー（9728134987）にコールし、カスタマーが応答します。録音機能により、録音デバイスへの 2 つの録音する側のコールが作成され、その結果 2 つの CDR（1 つはエージェント ボイス用、もう 1 つはカスタマー ボイス用）が追加されます。録音する側の CDR の origConversationID は、録音される側のコールの origLegCallIdentifier と一致します。この例では、エージェントが電話を切ります。
|
|
|
|
|
AAC コールおよび iLBC コール
次の例は、AAC コールおよび iLBC コールの CDR を示しています。
• 次の例は、AAC コーデックを使用するコールに適用されます。
|
|
|
• 次の例は、iLBC コーデックを使用するコールに適用されます。
|
|
|
モビリティ
• モビリティ Follow Me の例 ：企業固定電話番号 22285 と携帯電話番号 9728324124 を持つデュアルモード フォンがあります。22202 が 22285 にコールし、22285 と 9728324124 の両方で呼び出し音が鳴ります。携帯電話がこのコールに応答します。この Follow Me コールに対して 1 つの CDR が生成されます。80 秒間の通話が行われます。
|
|
|
• モビリティ HandIn の例 ：企業固定電話番号 22285 と携帯電話番号 9728324124 を持つデュアルモード フォンが、携帯電話 9728324214 へのコールを確立します。39 秒間の通話の後、デュアルモード フォンが企業ネットワークに接続され、このコールは携帯電話ネットワークから企業ネットワークに切り替えられます。さらに 15 秒間の通話が続行します。
|
|
|
|
• モビリティ HandOut の例 ：企業固定電話番号 22285 と携帯電話番号 9728324124 を持つデュアルモード フォンがあります。handout 番号（H 番号）は 555123 です。コールが企業固定電話番号 22285 に着信します。21 秒間の通話の後、デュアルモード フォンは企業ネットワークから切り離されて携帯電話ネットワークに着信します。このコールは企業ネットワークから携帯電話ネットワーク（9728324124）に切り替えられます。さらに 39 秒間の通話が続行します。
|
|
|
|
|
• モビリティ コール ピックアップの例 ：企業固定電話番号 22285 と携帯電話番号 9728324124 を持つデュアルモード フォンが、企業固定電話番号 22285 へのコールを確立します。40 秒間の通話の後、コール ピックアップが起動します。このコールは企業固定電話から携帯電話に切り替えられます。さらに 111 秒間の通話が続行します。
|
|
|
|
|
• モビリティ IVR の例 ：コールが文字列（DID#RemoteDest#TargetNum#）とともに Cisco Unified Communications Manager に着信します。このコールは TargetNum にリダイレクトされます。9728131234 が IVR にコールし、データが収集されます。転送先に 812345 が指定され、このコールは 812345 にリダイレクトされます。コールは 60 秒間接続されます。
|
|
|
インターコム コール
• ウィスパー インターコムの例 ：電話機 20000 がインターコムを起動します。設定済みのインターコム パーティション名は「Intercom」を示します。
|
|
|
• トークバック インターコムの例 ：電話機 20000 がインターコム ボタンを押します。20001 でトークバックを開始して 20000 に発話します。設定済みのインターコム パーティション名は「intercom」を示します。
|
|
|
CDR フィールドの説明
表10-4 は、現在の CDR のすべてのフィールドを CDR に表示される順序で定義しています。
|
|
|
|
|---|---|---|
一意の Cisco Unified Communications Manager ID を示します。 グローバル コール ID は、2 つのフィールド（globalCallID_callId および globalCallID_callManagerId）で構成されます。 |
||
各コールに割り当てられた一意のコール ID の値を示します。この ID は、各コール サーバ上で別個に割り当てられます。コールが開始すると、連続的に値が選択されます。コールが成功しても失敗しても、各コールに値が割り当てられます。Cisco Unified Communications Manager が再起動すると、この値は 1 にリセットされます。 グローバル コール ID は、2 つのフィールド（globalCallID_callId および globalCallID_callManagerId）で構成されます。 |
||
コールの発信レッグを示します。この値は、クラスタ内で一意であることに注意してください。複数のサブコール、したがって複数の CDR（コール転送時と同様）間でコールの同じレッグが存続する場合、この値は一定になります。 |
||
ユーザがオフフック状態にした日時、または着信コールの H.323 セットアップ メッセージを受信した日時を示します。時間は UTC として格納されます。 |
||
ゲートウェイで発信されたコールの場合、このフィールドは、コールが発信された T1、PRI、または BRI トランクの B チャネル番号を示すか、FXS または FXO トランクに対するゼロの値を示します。 H.323 ゲートウェイの場合、スパン番号が不明のため、このフィールドには発信者のコール レッグ ID が格納されます。 |
||
コール シグナリングを発信したデバイスの IP アドレスを示します。 Cisco Unified IP Phone の場合、このフィールドは電話機のアドレスを示します。 PSTN コールの場合、このフィールドは H.323 ゲートウェイのアドレスを示します。 クラスタ間コールの場合、このフィールドはリモート Cisco Unified Communications Manager のアドレスを示します。 「IP アドレス」に IP アドレスの形式が記載されています。 |
||
| Cisco Unified IP Phone で発信されたコールの場合、このフィールドは使用された回線の番号を示します。 着信 H.323 コールの場合、このフィールドは、セットアップ メッセージの Calling Party Number フィールドで受信された値を示します。このフィールドは、Cisco Unified Communications Manager に到達する前に発呼側番号に対して行われた変換（ゲートウェイにおける変換など）を反映しています。 サーバ コールで、Cisco Unified Communications Manager が発呼側の存在しないハーフ コールを発信した場合、このフィールドは空白のままのことがあります。 |
||
ISDN シグナリング リンク経由で受信された切断原因の場合、ISDN 解放メッセージに示される Location フィールドを示します。「コール終了原因コード」に、Q.850 ごとの有効な値を示しています。 Cisco Unified Communications Manager の内部で作成された切断原因の場合、この値はゼロになります。 |
||
発信側で切断されたコールの場合、このフィールドには切断の原因が反映されます。 Cisco Unified Communications Manager は、現在 Q.850 コードおよび Cisco Unified Communications Manager 定義の一部のコードを使用しています。「コール終了原因コード」に、これらのコードを示しています。一部の非標準原因コードが、本リリースで変更されました。 終端側で切断されたコールの場合、このフィールドはゼロを示します。 Q.850 に記載されている標準値に加えて、ある機能（転送/会議）によってコールが分割されると、CDR が終了し、このフィールドには 393216 がセットされます。これは、このフィールド独自の値です。 |
||
MLPP の場合、各コール レッグに優先レベルが含まれます。このフィールドは、元のレッグの優先レベルを示します。 |
||
コール用のメディアを発信したデバイスの IP アドレスを示します。 Cisco Unified IP Phone の場合、このフィールドは電話機のアドレスを示します。 PSTN コールの場合、このフィールドは H.323 ゲートウェイのアドレスを示します。 クラスタ間コールの場合、このフィールドはリモート電話機のアドレスを示します。 「IP アドレス」に IP アドレスの形式が記載されています。 |
||
| 発信者がメディアの送信に使用するコーデックのタイプを示します。 現在、Cisco Unified Communications Manager は、ペイロード機能の値として 0、1 ～ 16、18 ～ 20、25、32、33、81 ～ 86 を使用しています。「コーデック タイプ」に、有効な値を示しています。 |
||
発信側から送信されたパケットごとのデータのミリ秒数を示します。通常、このフィールドには G.729 または G.711 コーデックに対して 10、20、または 30 がセットされますが、ゼロ以外の任意の値がセットされることもあります。 |
||
このフィールドは、現在のリリースの Cisco Unified Communications Manager では使用していません。 |
||
origVideoTransportAddress_IP フィールドに関連付けられているビデオ RTP ポートを示します。 |
||
| 1：コールの設定時または機能の起動時の RSVP Reservation Failure 状態 2：コールの設定時または機能の起動時の RSVP Reservation Success 状態 3：コールの設定時または機能の起動時の RSVP Reservation No Response（RSVP Agent）状態 4：RSVP Mid Call Failure Preempted 状態（コールの設定後に優先処理が行われた） 5：RSVP Mid Call Failure Lost Bandwidth 状態（MLPP 優先処理以外のすべてのコール中機能を含む） |
||
| 1：コールの設定時または機能の起動時の RSVP Reservation Failure 状態 2：コールの設定時または機能の起動時の RSVP Reservation Success 状態 3：コールの設定時または機能の起動時の RSVP Reservation No Response（RSVP Agent）状態 4：RSVP MID Call Failure Preempted 状態（コールの設定後に優先処理が行われた） 5：RSVP MID Call Failure Lost Bandwidth 状態（MLPP 優先処理以外のすべてのコール中機能を含む） |
||
コールの終端レッグを示します。この値は、クラスタ内で一意のままです。複数のサブコール、したがって複数の CDR（コール転送時と同様）間でコールの同じレッグが存続する場合、この値は一定になります。 |
||
ゲートウェイで受信されたコールの場合、このフィールドは、コールが受信された T1、PRI、または BRI トランクの B チャネル番号を示すか、FXS または FXO トランクに対するゼロの値を示します。 H.323 ゲートウェイの場合、スパン番号が不明のため、このフィールドには接続先のコール レッグ ID が格納されます。 |
||
コール シグナリングを終端したデバイスの IP アドレスを示します。 Cisco Unified IP Phone の場合、このフィールドは電話機のアドレスを示します。 PSTN コールの場合、このフィールドは H.323 ゲートウェイのアドレスを示します。 クラスタ間コールの場合、このフィールドはリモート Cisco Unified Communications Manager のアドレスを示します。 「IP アドレス」に IP アドレスの形式が記載されています。 |
||
コール転送の前に、表示されていた元のコールの番号を示します。変換ルールが設定されている場合、この番号には、変換が行われた後に着信番号が反映されます。 |
||
応答があるまで、またはリングアウトするまで、最後に表示されたコールの番号を示します。自動転送が発生しなかった場合、この数字は originalCalledPartyNumber と同じになります。 会議ブリッジへのコールの場合、このフィールドには会議ブリッジの実際の ID（「b0019901001」などの英数字文字列）が格納されます。 |
||
ISDN シグナリング リンク経由で受信された切断原因の場合、ISDN 解放メッセージはこのロケーション フィールドを示します。「コール終了原因コード」に、Q.850 ごとの有効な値を示しています。一部の非標準原因コードが、本リリースで変更されました。 Cisco Unified Communications Manager が内部で作成する切断原因の場合、この値はゼロになります。 |
||
着信側が切断したコールの場合、このフィールドには切断の原因が反映されます。「コール終了原因コード」に、Q.850 ごとの有効な値を示しています。一部の非標準原因コードが、本リリースで変更されました。 発信側が切断したコールの場合、このフィールドはゼロのままです。 Q.850 に記載されている標準値に加えて、ある機能（転送/会議）によってコールが分割されると、CDR が終了し、このフィールドには 393216 がセットされます。これは、このフィールド独自の値です。 |
||
コール用のメディアを終端したデバイスの IP アドレスを示します。 Cisco Unified IP Phone の場合、このフィールドは電話機のアドレスを示します。 PSTN コールの場合、このフィールドは H.323 ゲートウェイのアドレスを示します。 クラスタ間コールの場合、このフィールドはリモート電話機のアドレスを示します。 「IP アドレス」に IP アドレスの形式が記載されています。 |
||
| 終端側がメディアの送信に使用するコーデックのタイプを示します。 現在、Cisco Unified Communications Manager は、ペイロード機能の値として 0、1 ～ 16、18 ～ 20、25、32、33、81 ～ 86 を使用しています。「コーデック タイプ」に、有効な値を示しています。 |
||
コールの終端側から送信されたパケットごとのデータのミリ秒数を示します。通常、このフィールドには G.729 または G.711 コーデックに対して 10、20、または 30 がセットされますが、ゼロ以外の任意の値がセットされることもあります。 |
||
このフィールドは、現在のリリースの Cisco Unified Communications Manager では使用していません。 |
||
destVideoTransportAddress_IP フィールドに関連付けられているビデオ RTP ポートを示します。 |
||
| 1：コールの設定時または機能の起動時の RSVP Reservation Failure 状態 2：コールの設定時または機能の起動時の RSVP Reservation Success 状態 3：コールの設定時または機能の起動時の RSVP Reservation No Response（RSVP Agent）状態 4：RSVP Mid Call Failure Preempted 状態（コールの設定後に優先処理が行われた） 5：RSVP Mid Call Failure Lost Bandwidth 状態（MLPP 優先処理以外のすべてのコール中機能を含む） |
||
| 1：コールの設定時または機能の起動時の RSVP Reservation Failure 状態 2：コールの設定時または機能の起動時の RSVP Reservation Success 状態 3：コールの設定時または機能の起動時の RSVP Reservation No Response（RSVP Agent）状態 4：RSVP Mid Call Failure Preempted 状態（コールの設定後に優先処理が行われた） 5：RSVP Mid Call Failure Lost Bandwidth 状態（MLPP 優先処理以外のすべてのコール中機能を含む） |
||
コールが接続された日付および時刻を示します。時間は UTC として格納されます。コールへの応答がなかった場合、この値はゼロになります。 |
||
コールが切断された日付および時刻を示します。コールが接続されなかった場合でも、このフィールドはセットされます。時間は UTC として格納されます。 |
||
最大 25 文字の数字列を示します。番号または SIP URL の数字列です。 自動転送されたコールの場合、このフィールドは、コールが最終送信先に到達する以前の最後のホップの直前の電話番号を示します。発生したホップが 1 つだけの場合、この番号は OriginalCalledPartyNumber と一致します。 自動転送されなかったコールの場合、このフィールドの値は OriginalCalledPartyNumber および FinalCalledPartyNumber と一致します。 会議ブリッジへのコールの場合、このフィールドには会議ブリッジの実際の ID（「b0019901001」などの英数字文字列）が格納されます。 |
||
データベースが各行を一意に識別するために内部で使用するテキスト文字列を示します。このテキスト文字列は、コール自体に対して意味はありません。 |
||
OriginalCalledPartyNumber フィールドに関連付けられているパーティション名を一意に示します。これは、Cisco Unified Communications Manager が、異なるパーティションにある同じ内線番号を持つ複数の Cisco Unified IP Phone をサポートしているためです。 H.323 ゲートウェイ経由で発信されたコールの場合、このフィールドは、そのゲートウェイを示すルート パターンに関連付けられているパーティション名を一意に示します。 |
||
CallingPartyNumber フィールドに関連付けられているパーティション名を一意に示します。これは、Cisco Unified Communications Manager が、異なるパーティションにある同じ内線番号を持つ複数の Cisco Unified IP Phone をサポートしているためです。 |
||
FinalCalledPartyNumber フィールドに関連付けられているパーティション名を一意に示します。これは、Cisco Unified Communications Manager が、異なるパーティションにある同じ内線番号を持つ複数の Cisco Unified IP Phone をサポートしているためです。 H.323 ゲートウェイ経由で発信されたコールの場合、このフィールドは、そのゲートウェイを示すルート パターンに関連付けられているパーティション名を一意に示します。 |
||
LastRedirectDn フィールドに関連付けられているパーティション名を一意に示します。これは、Cisco Unified Communications Manager が、異なるパーティションにある同じ内線番号を持つ複数の Cisco Unified IP Phone をサポートしているためです。 H.323 ゲートウェイ経由で発信されたコールの場合、このフィールドは、そのゲートウェイを示すルート パターンに関連付けられているパーティション名を示します。 デフォルト：空白の文字列 “”。最後のリダイレクト側にパーティションが存在しなかった場合、またはコールがリダイレクトされなかった場合、このフィールドは空白のままです。 |
||
Connect Time と Disconnect Time の差を示します。このフィールドは、コールが接続されていた時間を秒単位で示します。コールが接続されなかった場合、または接続時間が 1 秒未満の場合、このフィールドはゼロのままです。 |
||
| たとえば、コールの発信者が電話を切った場合、OnBehalfOf code は「12」（デバイス）を示します。コールが転送のために終了した場合、OnBehalfOf コードは「10」（転送）を示します。 コードのリストについては、「OnBehalfof コード」を参照してください。本リリースで新しい OnBehalfOf コードが追加されました。 |
||
| たとえば、コールの発信者が電話を切った場合、OnBehalfOf code は「12」（デバイス）を示します。コールが転送のために終了した場合、OnBehalfOf コードは「10」（転送）を示します。 コードのリストについては、「OnBehalfof コード」を参照してください。本リリースで新しい OnBehalfOf コードが追加されました。 |
||
| たとえば、元の着信側が会議のためにリダイレクトされた場合、OnBehalfOf コードは「4」になります。 コードのリストについては、「OnBehalfof コード」を参照してください。本リリースで新しい OnBehalfOf コードが追加されました。 |
||
最後のリダイレクト側のリダイレクト原因を示すコードが格納されます。 たとえば、最後のリダイレクト側が会議のためにリダイレクトされた場合、OnBehalfOf コードは「4」になります。 コードのリストについては、「OnBehalfof コード」を参照してください。本リリースで新しい OnBehalfOf コードが追加されました。 |
||
| コードの完全なリストについては、「リダイレクト原因コード」を参照してください。本リリースで、新しいリダイレクト原因値が追加されました。 |
||
| コードの完全なリストについては、「リダイレクト原因コード」を参照してください。本リリースで、新しいリダイレクト原因値が追加されました。 |
||
会議コールのパーティを識別するために使用される一意識別子を示します。 会議チェーニング シナリオの場合、origConversationID および destConversationID フィールドは、どの会議がチェーニングされたかを示します。 |
||
Cisco Unified Communications Manager のクラスタを示す一意の ID。 このフィールドはインストール時に生成されるもので、Cisco Unified Communications Manager では使用しません。この一意のキーは、globalCallId_ClusterId + globalCallId_CMId + globalCallId_CallId の各フィールドで構成されています。 |
||
| たとえば、転送のために結合が発生した場合、OnBehalfOf コードには「10」が格納されます。 コードのリストについては、「OnBehalfof コード」を参照してください。本リリースで新しい OnBehalfOf コードが追加されました。 |
||
コールが拡張される前に、ユーザはクライアント証明書コードを入力します。このコードは、アカウントまたは課金コードをコールに割り当てるために使用できます。 |
||
| 1：OOB（SIPTrunk の背後にあるエンドポイントが OOB をサポートしている場合、それを使用する） 2：2833（SIPTrunk の背後にあるエンドポイントが RFC2833 をサポートしている場合、それを使用する） 3：OOB と 2833（SIPTrunk の背後にあるエンドポイントが KPML と RFC2833 の両方をサポートできる場合、それらを使用する） |
||
| 0：DTMF なし（一致する任意の DTMF を使用する） |
||
コール中に達成した最も高いセキュリティ ステータス。たとえば、コールが最初はセキュリティ保護されておらず、後でセキュリティ保護されるようになった場合、コールの別の部分のステータス値が異なっていても、CDR には 1（セキュリティ保護あり）が格納されます。 |
||
コールの発信レッグに関連付けられている会議 ID を示します。ほとんどの場合、このフィールドの値は 0 になります。 会議チェーニング シナリオの場合、origConversationID および destConversationID フィールドは、どの会議がチェーニングされたかを示します。 |
||
CMR のフィールドの説明（診断）
表10-5 は、CMR のフィールド、値の範囲、およびフィールドの説明を CMR に表示される順に示しています。
|
|
|
|
|---|---|---|
一意の Cisco Unified Communications Manager ID を示します。 このフィールドは、グローバル コール ID の一方の構成要素です。グローバル コール ID は、次のフィールドで構成されます。 |
||
各コールに割り当てられた一意のコール ID の値を示します。この ID は、各コール サーバ上で別個に割り当てられます。コールが開始すると、連続的に値が選択されます。成功か失敗かに関係なく、各コールは値を割り当てられます。 このフィールドは、グローバル コール ID の一方の構成要素です。グローバル コール ID は、次の 2 つのフィールドで構成されます。 |
||
このレコードを生成した Cisco Unified Communications Manager クラスタ内のノードを示します。 |
||
デバイスがオンフック状態になったおおよその時刻を示します。Cisco Unified Communications Manager は、電話機が診断情報の要求に応答した時刻を記録します。 |
||
この接続で送信を開始してから、デバイスが送信した Routing Table Protocol（RTP）データ パケットの合計数を示します。接続が「受信専用」モードに設定されていた場合、この値はゼロのままです。 |
||
この接続で送信を開始してから、デバイスが RTP データ パケットで送信したペイロード オクテット（ヘッダーおよびパディングを除く）の合計数を示します。接続が「受信専用」モードに設定されていた場合、この値はゼロのままです。 |
||
この接続で受信を開始してから、デバイスが受信した RTP データ パケットの合計数を示します。マルチキャスト コールの場合、この値には異なるソースから受信したパケットも含まれます。接続が「送信専用」モードに設定されていた場合、この値はゼロのままです。 |
||
この接続で受信を開始してから、デバイスが RTP データ パケットで受信したペイロード オクテット（ヘッダーおよびパディングを除く）の合計数を示します。マルチキャスト コールの場合、この値には異なるソースから受信したパケットも含まれます。接続が「送信専用」モードに設定されていた場合、この値はゼロのままです。 |
||
受信を開始してから損失した RTP データ パケットの合計数を示します。この値は予測されるパケット数を示すもので、実際に受信したパケット数よりも少なくなります。受信したパケット数には、遅延または重複したパケットが含まれます。このため、遅延したパケットは損失に含まれず、また重複するパケットが存在する場合、損失がマイナスになることがあります。予測されるパケット数は、受信した最後のシーケンス番号を拡張したものを表します。次に定義されるように、受信した最初のシーケンス番号より小さくなります。接続が「送信専用」モードに設定されていた場合、この値はゼロのままです。詳細については、RFC 1889 を参照してください。 |
||
RTP データ パケットの到着間隔時間の統計的分散の推定値を示します。この値は、ミリ秒単位で測定され、符号なし整数として表されます。到着間隔ジッタ J は、受信者のパケットを送信者のパケットと比較し、その差分 D の平均偏差（平滑化した絶対値）を示します。RFC 1889 には、詳細な計算アルゴリズムが記載されています。接続が「送信専用」モードに設定されていた場合、この値はゼロのままです。 |
||
ネットワーク遅延の推定値をミリ秒単位で示します。この値は、RTP Control Protocol（RTCP）メッセージに示される NTP タイムスタンプと受信者の NTP タイムスタンプとの差の平均値を示すもので、これらのメッセージの受信時に測定されます。Cisco Unified Communications Manager は、すべての推定値を合計し、受信した RTCP メッセージ数で割ることによって平均値を計算します。詳細については、RFC 1889 を参照してください。 |
||
データベースが各行を一意に識別するために内部で使用するテキスト文字列を示します。このテキスト文字列は、コール自体に対して意味はありません。 |
||
複数の Cisco Unified Communications Manager のクラスタを特定する一意の ID を示します。 このフィールドはインストール時に生成されますが、Cisco Unified Communications Manager では、 |
||
このフィールドには、音声品質メトリックの変数が格納されます。このフィールドは、複数の音声品質メトリックをセミコロンで区切った文字列からなります。 fieldName=value;fieldName=value.precision 次の例は音声品質データを示していますが、名前は異なる場合があります。 "MLQK=4.5000;MLQKav=4.5000;MLQKmn=4.5000;MLQKmx=4.5000;MLQKvr=0.95;CCR=0.0000;ICR=0.0000;ICRmx=0.0000;CS=0;SCS=0”
（注） K ファクタ データの完全なリストについては、表10-6「Cisco Unified Communications Manager CMR に保存される K ファクタ データ」を参照してください。 |
CMR の K ファクタ データ
K ファクタ（ITU 標準 P.VTQ で定義されているエンドポイント平均オピニオン スコア（MOS）推定アルゴリズム）は、一般的な推定法則として機能し、特定の減衰パターンに対する Perceptual Evaluation of Speech Quality（PESQ）実装の平均値を推定するために使用されます。
MOS は、適切に計画されたリスニング試験の結果に対応しています。ITU 標準 P.862.1 で定義されているとおりに、すべての MOS 試験で 5 ポイント PESQ スケールが使用されています。ITU 標準 P.862.1 では、PESQ について、狭帯域電話ネットワークおよび音声コーデックのエンドツーエンド音声品質を評価するための客観的な方法であると説明しています。
MOS 推定値は、フレーム損失密度に反比例することに注意してください。受信側でフレームの損失または廃棄が増えるにつれて、明瞭度が低下します。このようなフレームの損失または廃棄を「秘匿」といいます。秘匿統計では、障害が発生したネットワークにおけるパケット（フレーム）損失とその音声品質への影響を測定します。
K ファクタは、ビット落ちなどのパケット損失や震音によって発生する歪みのためにユーザが感じる不快感について、重み付き平均の推定値を示すものです。エコーなど遅延に関連する障害の影響は、推定値に含まれません。K ファクタは、会話品質（MOS-CQO）ではなくリスニング品質（MOS-LQO）を示し、ユーザが感じる不快感の平均を 1（音声品質が悪い）から 5（音声品質が非常に良い）までの測定値で提供します。
K ファクタは、多数の音声データベースの音声サンプルで調整および改良されています。これらの音声データベースでは、調整用の文章や P.862.1 値に関連するネットワーク条件はそれぞれ 8 秒間に設定されています。したがって、より正確なスコアを求めるために、8 秒間のアクティブな音声ごとに K ファクタ推定値が生成されます。
K ファクタおよびその他の MOS 推定値は、あくまでも二次的統計または派生統計と考えてください。これらの値は、問題が深刻化して初めてネットワーク オペレータに警告を出すためです。主要な統計は、パケット数や秘匿秒数カウンタになります。これらの値は、MOS を通じてネットワーク障害を目や耳で自覚する前に、ネットワーク オペレータに警告を出すためです。
表10-6 は、Cisco Unified Communications Manager CMR に保存される K ファクタ データを示しています。
コーデック タイプ
表10-7 は、コーデック フィールドに表示される圧縮およびペイロードのタイプを示しています。
|
|
|
|---|---|
コール終了原因コード
次の各表は、CDR の原因フィールドに表示されるコール終了原因コードを示しています。
|
|
|
|---|---|
リダイレクト原因コード
表10-10 は、レコードに表示される有効なリダイレクト原因コードを示しています。
|
|
|
|
|
|
|
|
|
OnBehalfof コード
表10-11 は、CDR レコードに表示される有効な OnBehalfof コードを示しています。
|
|
|
|---|---|
関連項目
• 「CDR Analysis and Reporting の概要」
関連資料
次の各資料には、CDR に関連する追加情報が記載されています。
• Cisco Unified Communications Manager Serviceability アドミニストレーション ガイド
フィードバック