IPCC トラブルシューティング ガイド

ダウンロード オプション

  • PDF     (342.0 KB)
    Adobe Reader を使ってさまざまなデバイスで表示
  • ePub     (92.9 KB)
    iPhone、iPad、Android、ソニーの Reader、または Windows Phone 上で、さまざまなアプリを使って表示
  • Mobi (Kindle)     (129.2 KB)
    Kindle デバイスで、または Kindle アプリを使って複数のデバイスで表示
Updated: 2006 年 1 月 9 日

偏向のない言語

この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。

翻訳について

シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版（リンクからアクセス可能）もあわせて参照することを推奨します。

目次

はじめに
前提条件
要件
使用するコンポーネント
表記法
現象およびトラブルシューティング操作
Cisco IPCC PIM はアクティブ行きません
JGW プロセスはアクティブ行きません
ディレクトリ問題（、ディレクトリ パスワード実行コンフィギュレーション、）
エージェントはログインできません
エージェントはコールをすることができません
エージェントは行くことができません ---- Not Ready、Busy、またはOtherの場合
エージェントは準備ができている行くことができません
エージェントはログアウトできません
エージェントは電話でアクティブ コールかエージェントがTalkingであること、コールがないことを示します
コールはアラートの後ですぐにクリアするか、または確立しました
ポスト ルーティングははたらきません
ルーティングスクリプトはエージェントが利用可能になるときコールを削除しません
すべてのエージェントおよびキュー ポートが使用中である時聞かれる Ring No Answer
任意の転送は矛盾した結果を得ます
交替ははたらきません
会議される 側は他のパーティの会議できません
予想に反してログアウトされるエージェント ステーション
エージェントはエージェントデスク設定の設定によって動作しません
コンサルト転送失敗
VRU への変換ルートははたらきません
ルート要求は「ルート スクリプトの VRU ノードへの変換ルート」に到達しません
ルータログの変換ルート時間出口
VRU PIM ログはトランクグループで見つけられない DNIS を X 示します
ICM 設定をチェックして下さい
解決して下さい Cisco IP IVR - ICM インターフェイス
変換ルートは失敗します
スクリプトはエラー メッセージを再生しませんし、再生しません
JTAPI ステータスは部分的なサービスを示します
IP IVR の ICM ステータスは部分的なステータスを表示します
コールがルータから削除されるとき聞かれるプロンプトをどもって下さい
IVR サービス統計情報を解決して下さい
サービス統計情報か終了コール詳細レコードは作成されません
VRU は接続される、要求に応じて並べられないようにすべてのコールを報告します
コールは間違った サービスに対して数えられるか、または In Service レポートを現われません
Cisco CallManager を解決して下さい
Cisco CallManager のためのトレースをつけて下さい
Cisco CallManager IP アドレスを変更して下さい
デバッグツール
Procmon
OPCtest
rttest
rtsetting.exe
rtrtrace.exe
dumplog
vrutrace
コール トレーサー
jtprefs
パフォーマンス モニタ
ログ ファイル
Cisco ICM ログ ファイル
Cisco CallManager ログ ファイル
IP IVR ログ ファイル
有用なプロファイルデータ
エージェントの数
使用されるゲートウェイ
コンポーネントのソフトウェアバージョン
IVR 型
プラットフォーム
関連情報

はじめに

このドキュメントでは、Internet Protocol Contact Center（IPCC）のトラブルシューティングについて、ペリフェラル ゲートウェイ（PG）および Cisco Intelligent Contact Management（ICM）に焦点を当てて説明します。 このドキュメントでは、Cisco CallManager と Cisco Global Directory に関連した一般的な問題について言及する場合もありますが、これらのコンポーネントを詳細に説明するものではありません。 PG で認識される問題の原因を特定するために、症状と解決方法を重視した内容となっています。  問題はソフトウェアか設定に関連できます。

前提条件

要件

次の項目に関する知識が推奨されます。

  • Cisco ICM PG の問題を解決しサポートする方法

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づくものです。

  • Cisco ICM バージョン 4.6.2

本書の情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。 稼働中のネットワークで作業を行う場合、コマンドの影響について十分に理解したうえで作業してください。

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

現象およびトラブルシューティング操作

IPCC のための PG ログを検知 して下さい。 Peripheral Interface Manager （PIM）、Open Peripheral Controller （OPC）、または Computer Telephony Interface （CTI）サーバログの詳細不明のエラーを見るとき、問題のよりよいテキストの記述のための JTapi Gateway （GW）ログに直接行って下さい。 JTAPI インターフェイスは通常事柄がサードパーティの要求でうまくいかないとき例外を提供します。 これらの例外はエラー コード無しでストリング説明だけ提供します。 その結果、PIM/OPC/CTI サーバログ 詳細不明のエラーとして多くのエラー。

Cisco IPCC PIM はアクティブ行きません

有効に ならない PIM

PIM ログのプロシージャがあるように確認して下さい。 PIM ログがない場合、周辺装置を確かめるチェックは Cisco ICM 設定で有効に なります。 時々、周辺装置は追加されますが、周辺装置を有効に する必要があります。

> 周辺装置 『Edit』 を選択 し、Enabled チェックボックスをチェックして下さい。

PIM 再起動

PIM プロセス再起動が、PIM ログオンをの Cisco CallManager PG 表示すれば ログ ファイルが OPCHeartbeatTimeout のエラーを示す場合、このレジストリ 設定を修正して下さい。 変更を行なうのに regedt32 を使用して下さい。

10.に eagtpim 動的データの下でレジストリの OPCHeartbeatTimeout を修正して下さい。 パスはここにあります:

HKEY_LOCAL_MACHINE\SOFTWARE\GeoTel\ICR\<cust_inst>\<PG_inst>\PG\CurrentVersion\
PIMS\<pim_inst>\EAGENTData\Dynamic

注: このキーはスペース制限による 2 つの行にここに現われます。

PIM Log ウィンドウの IDLE 状態の PIM

PIM プロセスが IDLE 状態にある場合、これらのチェックを実行して下さい:

  • PIM ログをチェックして下さい。 「一度アクティブになるように」、少なくとも試みます分見て下さい。

  • PIM が非アクティブである場合、OPC ログをチェックするのに Dumplog ユーティリティを使用して下さい。 OPC プロセスがルータから設定を受け取るかどうか見るために opctest 実行して下さい。

  • OPC プロセスがルータから設定を受け取らない場合、pgagent ログを調べるのに Dumplog ユーティリティを使用して下さい。 pgagent プロセスは Central Controller にアクティブパスがなければなりません。 pgagent アクティブパスを持ちませんでしたり、ページ設定のネットワーク 接続および DMP 設定をチェックします。 ルータで、ccagent ログを調べるのに Dumplog ユーティリティを使用して下さい。 PG デバイス（DMP システム ID）がルータのデバイスとして有効に なるかどうか確かめて下さい。

  • ルータコンフィギュレーションまたは DMP レジストリの下でレジストリの設定によって PG を有効に して下さい。

  • Command ウィンドウでは、ルータと PG 間のネットワーク 接続を確認する tracert コマンドを使用して下さい。

    注: DNS と DHCP 間に矛盾がある場合もあります。

  • ルータのための IP アドレスが c:\winnt\system32\drivers\etc ディレクトリのホスト ファイルにあるかどうか確かめて下さい。

  • PG > Setup で設定される論理的なコントローラ ID が Configure > ICM の PG 論理的なインターフェイス コントローラ用の ID と一致するかどうか確認して下さい。 PG > Setup の周辺装置のために設定される周辺装置 ID が Configure > ICM の周辺装置のための ID と一致するようにして下さい。

  • 設定を一致するために設定される ICM を修正して下さい。

JGW プロセスはアクティブ行きません

Microsoft Java Virtual Machine （JVM; Java バーチャルマシン）の不正確なバージョンはインストールされています

  • コマンド プロンプトに行き、jview を入力し、『Enter』 を押して下さい。 インストール済み Java バージョンの情報は現われます:

    Microsoft (R) Command-line Loader for Java version 5.00.3190

  • この出力を見ないか、またはバージョンが 3190 より早ければ、Microsoft JVM の正しいバージョンをインストールして下さい。 msjavx86.exe を実行して下さい。 このファイルは設定の間に ICR \ビンディレクトリにインストールされています。

Java クラスパスは不正確です

  • コマンド プロンプトから、ICR \ビンディレクトリに行き、jtapigw を入力し、『Enter』 を押して下さい。  これと同じような応答は現われます:

    18:43:17 Fail: Node Manager Required Arguments missing.
18:43:17 Trace: at com/cisco/icr/ems.EMSFailMessage (ems.java:164)
18:43:17 Trace: at com/cisco/icr/NodeManager.setStartupArgs
 (NodeManager.java:27)
18:43:17 Trace: at MainWorkerThread.mainImplementation
 (MainWorkerThread.java:41)
18:43:17 Trace: at MainWorkerThread.run (MainWorkerThread.java:19)

  • また、このメッセージが現れます:

    Java.lang.NoClassDefFoundError: com/cisco/icr/GWThreadGroup

  • jtapigw を実行するとき第 2 メッセージが表示されたら、Java クラスパスをチェックして下さい。  レジストリ エディタを Microsoft \ Java VM ソフトウェア\キーの下で値クラスパスを検知 するのに使用して下さい。  このようなキーを設定 して下さい:

    C:\WINNT\java\classes;.;c:\icr\bin\icrjavalib.zip

注: c:\icr が…次のとおりである前にドライブ文字および Windows システム 登録簿はクラスの後でおよび文字異なり、: セミコロン、期間およびセミコロン。

PG でインストールされない Cisco JTAPI クライアント

  • コマンド プロンプトから、ICR \ビンディレクトリに行き、jtapigw を入力し、『Enter』 を押して下さい。  これと同じような応答は現われます:

    18:43:17 Fail: Node Manager Required Arguments missing.
18:43:17 Trace: at com/cisco/icr/ems.EMSFailMessage (ems.java:164)
18:43:17 Trace: at com/cisco/icr/NodeManager.setStartupArgs (NodeManager.java:27)
18:43:17 Trace: at MainWorkerThread.mainImplementation (MainWorkerThread.java:41)
18:43:17 Trace: at MainWorkerThread.run (MainWorkerThread.java:19)

  • 上の代りに、このメッセージを次のように表示できます:

    Java.lang.NoClassDefFoundError

  • jtapigw を実行するとき第 2 メッセージのように何かを見たら、Cisco JTAPI クライアントが PG でインストールされていることを確認して下さい。 c:\winnt\java\lib の下でファイル CiscoJtapiVersion.class があるように確認して下さい。

  • このファイルがない場合、Cisco CallManager から PG でファイルをインストールできます; http:// <callmanager name>/main.asp。 Application タブの下でファイルを見つけることができます。

JTAPI GW ログは対応しない JTAPI バージョンについて問題があることを示します

  • Cisco CallManager PG であらゆる熱い修正との JTAPI 4.1 Service Pack （SP）だけ 4 より少なくより 50 インストールした場合、アップグレードする必要があります。

  • PG をアップグレードするためにちょうど ICM > Setup を実行する場合ファイル\ ICR \ビン\ icrjavalib.zip の日付/時間が更新済日付を表示することを確認して下さい。 日付は日以内程でファイルの日付/時間、およそ同じである必要があります。

注: 設定はファイルが使用中のときセットアップの実行場合このファイルをアップデートできません。 この状況はブラウザが zip を開く場合、ブラウザがクラス パスのためのディレクトリとして ZIP ファイルを扱うので開いているインターネット ブラウザーがある場合発生する場合があります。 この問題を回避するために、すべてのブラウザー セッションを前にセットアップの実行閉じて下さい。  設定がファイルをアップデートできない場合メッセージによってが現れ、ファイルをアップデートするために PC をリブートするように指示します。 リブートして下さい。

JTAPIGW は Cisco CallManager に接続できません

  • PIM は JTapi Gateway （JTAPIGW）と通信し、JTAPIGW は Cisco CallManager と通信します。 PIM がアクティブ行くことを試みると同時に PIM は JTAPIGW を JTAPI によって Cisco CallManager の通信を初期化するように告げます。

  • JTAPIGW によっては PIM からの接続を許可し、getProvider() が接触することをたとえば、示すメッセージが表示されて下さい:

    13:16:47 pg2A-jgw1 Trace:Calling getProvider () 172.24.79.128; 
  login=PGUser;passwd=<***edited***>
13:16:52 pg2A-jgw1 Trace: Returned successfully from getProvider()

    注: この例はスペース制限による複数行に現われます。

正常に戻るトレースを見ない場合 getProvider() にコールの後で他のエラーを表示できます。  getProvider() へのトレースは JTAPI を初期化するのに使用されるパラメータを表示します。  最初のパラメータは Cisco CallManager マシンの IP ホスト名または IP アドレスのサービス名です。  この例では、IP アドレスは使用されます。  名前が使用される場合、PG はホスト ファイルか DNS によって名前を変換できる必要があります。  名前かアドレスを ping できることを確かめて下さい。  サービス名を変更し、ICM > Setup を再実行し、編集周辺装置ダイアログの名前を変更する必要があれば。

getProvider() へのコールのトレースはまた使用されるログイン名を表記します。 トレースがパスワードを示さないことに注意して下さい。 管理者が ICM > Setup の下で入力するものをからログイン名およびパスワードは奪取 されます。 これらはディレクトリで設定され、エージェント デバイスおよびルート ポイントのそれぞれを制御する機能を持つために Cisco User Preferences Web ページで管理される有効なユーザおよびパスワードを一致する必要があります。 名前およびパスワードが ICM > Setup で正しいことをチェックして下さい。 ディレクトリのユーザを有効なエージェント デバイスおよびルート ポイントだけ制御する権限を持つために設定して下さい。

JGW ログは不明な ホストを示します

JTAPI GW プロセスは Cisco CallManager のアドレスを解決できません。 Cisco CallManager ホスト名か IP アドレスで設定の PIM ダイアログ ボックスのサービスパラメータを設定して下さい。 Cisco CallManager のためのホスト名設定が正しい場合、Cisco CallManager を ping できることを確かめて下さい。 そうでなかったら、ホスト名の代りに Cisco CallManager の IP アドレスを、使用して下さい。

JGW ログは無効なパスワードかユーザを示します

JTAPI GW はユーザ名 および パスワードのグローバル なディレクトリに記録 します。 設定の PIM ダイアログ ボックスのユーザ名 および パスワードは ccmadmin > User > Global Directory の下で Cisco CallManager admin Webページのグローバル なディレクトリのユーザ設定のためのユーザ名 および パスワードとマッチする必要があります。

ユーザが存在 しない場合、新しいユーザを追加して下さい。 ページの一番下に CTI Enabled チェックボックスをチェックすることを確かめて下さい。

グローバル なディレクトリ ユーザページで有効に ならない CTI チェックボックス

Cisco CallManager グローバル なディレクトリ ユーザページのチェックボックスは PIM または IP IVR ユーザ向けの CTI 特権を有効に するか、または無効に することができます。 PIM/JTAPI GW のために行くためにアクティブこのチェックボックスをチェックし、アップデートして下さい。 このチェックボックスは 2 つの CTI デバイスが問題を引き起こす場合がある Cisco CallManager に接続されることができないようにします（デフォルトの限界は 400）あります。

Cisco CallManagerサービスは動作しません

  • on Cisco CallManagerのバージョン 3 は「Cisco CallManager」として、このサービス稼働中制御を示します。 サービスを開始して下さい。

  • Cisco CallManagerサービスは再起動するためにそれが異常に終了する、フェールオーバー シナリオのデバイスの移行で潜在的な問題のための「Off」にこれを設定できます場合普通設定 されます。

  • Cisco CallManagerサービスが再起動するかどうかイベント ログを確認して下さい。 システムは時々システムが十分な CPU 使用における問題点を明らかにする場合再起動します。 「遅い SDL タイマー スレッド」を示すイベント ログのシステム Reports エラーか警告。 エラーのこの型によって、Cisco CallManager は再起動します。 Cisco CallManager のこのバージョンは通常優先順位でコール場合とシステムで干渉できる動作するそう他のアプリケーションを実行します。

  • 物理メモリがより少しのかまたはシステムが他のタイミング問題に出会うとき、Cisco CallManager は示すエラーを思い付くことができます 10 分タイムアウトの後で初期化し、再起動できなかったことを。 初期化する問題がある Cisco CallManagerデータベース層（DBL）のための DCOM コンポーネント サービスがあります。 コンポーネント サービスによってこの DBL DCOM サービスを– DCOM コンポーネント停止し、この問題を解決し始めて下さい。

    注: これは Cisco CallManager のようなシステム サービスと同じではないです。

    Cisco Technical Assistance Center （TAC）とのケースをオープンして下さい。 これは根本的なタイミング問題を解決しなければシステムを再始動する時次におそらく問題である場合もあります。

ディレクトリ問題（、ディレクトリ パスワード実行コンフィギュレーション、）

ディレクトリ サービスが実行されない

  • ディレクトリー・サービスがアップ、きちんと動作することを確認して下さい。  デフォルトで、これは Cisco CallManager マシンの DC Directory Server 稼働中制御です。 マシンを始動することを試みて下さい。 エラーに出会うことができます。

  • ディレクトリー・サービスは休止した状態にシステムがメモリかディスク領域を使い果たす場合入ることができます。 エラーは Microsoft Windows 2000 イベント ログに現われます。 リソース問題を解決し、ディレクトリー・サービスを、必要ならば再開して下さい。

Cisco CallManager Web ユーザ ページははたらきません

Cisco グローバル なディレクトリ ユーザ Webページが実際に表示し、ユーザを設定し、制御装置に権限を割り当てることができるかどうか確かめて下さい。 JTAPIGW および Webページは両方ユーザおよび権限にアクセスするためにディレクトリ サーバにアクセスするのに Cisco CallManager を使用します。 JTAPIGW における問題がディレクトリ サーバの問題が原因である場合、ユーザ Webページはまた問題がある場合があります。 考えられる原因はまったくディレクトリ サーバが動作しないかまたはディレクトリが正しく設定されないことです。

インストールされないディレクトリ サーバ

Cisco CallManager 3.0.5 および以降を使用するために、ディレクトリ サーバをインストールして下さい。 AVVID DC Directory は Spirian インストール CD で利用可能のデフォルトです。 ディレクトリ サーバをインストールした後、Cisco CallManager のインストールはディレクトリを設定します。

このインストールを正しく行って下さい JTAPIGW が Cisco CallManager に記録 し、JTAPI を使用することができるようにディレクトリ サーバはアップであり、きちんと動作する必要があります。

Cisco DC Directory サービスおよび CallManager が両方きちんと動作することを確かめて下さい。

Cisco CallManager をインストールするとき、ディレクトリ マネージャ パスワード プロンプトが表示されるとき「ciscocisco」を入力して下さい。 何か他のもの入力する場合、DC Directory ソフトウェアを（追加して下さい/取除いて下さい）取除き、再インストールしなければならないことができます。 いくつかのファイルは取除くことができないことを削除プロセスが告げれば手動で c:\dcdsrvr 現在のディレクトリを取除くか、または名前を変更して下さい。

ディレクトリ サーバはインストールしましたが、動作しません

サービスが開始できないことを確認するためにコントロール パネルをチェックして下さい。 次に管理者が設定され、ログインおよびパスワードが Properties フィールドのサービスのために正しいかどうか、確かめて下さい。

ディレクトリ サーバは実行インストールした、が、DCD 管理ツールとのログインできません

システム Start メニューからの DC Directory Admin を開始して下さい。 またはどんなパスワードを admin が設定したパスワード「ciscocisco」でユーザ ディレクトリ マネージャとのログイン（デフォルト）。 ユーザは設定されないことを示すエラーを受け取ったら、DCDSrvr \ビンディレクトリの Cisco AVVID コンフィギュレーション ファイルの 1 つを実行して下さい。 これが Cisco プライマリ CallManager である場合、パブリッシャは DOS プロンプトから、avvid_cfg.cmd を実行します。 これが Cisco セカンダリ CallManager である場合、コマンド プロンプトから avvid_scfg.cmd を実行して下さい。

エラーは示すこれ既に設定されている見れば、ユーザは存在 します。 No エラーがある場合、事柄は今きちんとはたらき始める必要があります。 戻り、ccmadmin のグローバル なディレクトリ ユーザページからアクセスをチェックして下さい。

注: DC Directory は一時停止モードにディレクトリがシステム リソースで低い場合入ります。

エージェントはログインできません

この例はデバイス ターゲットのためにサンプル ICM 設定を使用します:

デバイス ターゲット サンプル  
エンタープライズ名前 Agent9782755100
グローバル アドレス Agent9782755100
ConfigParm /devtype CiscoPhone /dn 9782755100

次の例エージェントのためにサンプル ICM 設定を使用します:

エージェント サンプル  
周辺装置 CCMPG_PIM1
周辺装置数 1234
Password ?

PG のための ICM > Setup を実行するとき、"4" のエージェントの拡張の長さを規定 します。 このように、設定 例で、サンプルデバイスのための拡張は /dn パラメータの最後の 4 ディジットです（たとえば、"5100"）。

CTITest のログインに試みて下さい。

ソフトフォンによってエージェントを記録できない場合 ctitest によって同じオペレーションを試みて下さい。 サンプルデバイス ターゲットにログインにサンプル エージェントを使用できる ctitest コマンドのサンプル リストはここにあります。 コマンドのこのリストは CTI サーバがマシン CTIServerA のポート 42027 で受信すると仮定します。 このリストはまたデバイスが ICM 周辺装置 5000 として表される周辺装置のための拡張であると仮定します。

config /hostA CTIServerA
config /portA 42067
config /service CLIENT_EVENTS+CLIENT_CONTROL
agent /periph 5001 /inst 9782755100
open
login 1234 XXX /inst 9782755100

PIM および CTI サーバは OPC で非アクティブです

opctest 「ステータス」コマンドを使用し、IPCC PIM を確認すれば CTI サーバは PIM_ACTIVE および CTI_ACTIVE 状態で示します。 PIM および CTI サーバ Log ウィンドウのタイトルバーはまたプロセス状態を示します。

CTI クライアントは接続できません

CTI サーバに接続するために設定をチェックして下さい。 デスクトップ ソフトフォンに関しては、設定は .ini ファイル（通常 c:\program files\geotel\cti デスクトップ\ cticonfig.ini）にあります。 チェックするべき設定は下記のものを含んでいます:

  • PeripheralID —この値は Configure > ICM の IPCC 周辺装置のための周辺装置 ID を一致する必要があります。

  • SideAHost —この値は CTI サーバ側 A.の IP ホスト名またはアドレスである必要があります。

  • SideBHost —この値は CTI サーバ側 B.の IP ホスト名またはアドレスである必要があります。  CTI サーバがシンプレックスである場合、このフィールドは空白を残すことができます。

  • SideAPort —この値は Side A の CTI サーバが接続を聞き取るポートを一致する必要があります。 この値は CTI サーバのために設定される ICM で規定 されます。 CTI サーバはタイトルバーで CTI サーバが開始するときこのポートを示し、この値を記録 します。 クライアントが CTI サーバを ping できるかどうか確かめて下さい。

CTI クライアント Gets エラーはエージェントが ACD に記録 される必要があることを示します

PG/CTI サーバの\ ICR \ビンディレクトリに常駐する setup.exe を実行して下さい。 CTI ゲートウェイ コンポーネントを選択して下さい。 AgentLogin がチェックボックスをチェックを外される必要としたかどうか確かめて下さい。 このチェックボックス選択は IPCC またはサードパーティ コントロール アプリケーションのための適用されないです。 このチェックボックスの目的は他の ACD エージェント アプリケーションを監視することです。

PIM ログはこれらの Login エラーの 1 つを示します

PIM に procmon を使用すれば「サードパーティ トレーシングをトレースして下さい（大文字/小文字の区別がある）つけるために tp*」を。 これは Login 要求を示す必要があります。 パラメータが正しいかどうか確かめて下さい。 インストルメントは「Device=」としてトレースされます。 この値はデバイス ターゲット configparam の /dn ストリングを一致する必要があります。 エージェント ID は「AgentID=」としてトレースされます。 この値は Configure/ICM のエージェントのペリフェラル番号を一致する必要があります。

  • INVALID_PASSWORD

    パスワードが正しいことを確かめて下さい（パスワードはクリアテキストとしてトレースされないかもしれません）。 パスワードが不正確ならログは INVALID_PASSWORD_SPECIFIED エラーを示す必要があります。

  • INVALID_OBJECT

    デバイス ターゲットのコンフィギュレーションパラメータが無効な装置タイプが含まれていることを示します。 このエラーはキーワード間の領域とこれのように現われます:

    /devtype CiscoPhone /dn 9782755100

  • INVALID_DEVICE_TARGET

    デバイス ターゲットの何かが Configuration Parameters フィールドで無効、多分何かであることを示します。 Dumplog ユーティリティによって、PIM が再起動した前回のための PIM ログを調べて下さい。 ログはデバイス ターゲット 設定 ストリングが無効なときデバイス ターゲットおよび Log エラーを検証します。

JGW ログは Log In エラーを示します

ログイン試行に生じるあらゆるエラーがあるかどうか jgw ログを点検して下さい。 PIM に procmon を使用すれば「サードパーティ トレーシングをトレースして下さい（大文字/小文字の区別がある）つけるために *TP*」を。 行を、「MsgAddCallObserver 探して下さい: アドレス: がログインに試みる拡張であるところ」。 この拡張は PG ユーザが制御する権限を持っているデバイスの有効な Cisco CallManager 拡張である必要があります。 拡張は Cisco CallManager が確認すると同時に電話のためのディジットの正しい数である必要があります。 すなわち、拡張は疑わしい電話に達するために Cisco 同じ CallManager の別の電話からダイヤルする数である必要があります。

プロバイダ ドメインのデバイスない

jgw ログが例外を示す場合、デバイスはプロバイダ ドメインにないことを示す、電話は JTAPI が GW ログオンするユーザと対応づけられません。 グローバル なディレクトリ ユーザデバイス アソシエーション リストのずっと側面の拡張が正しいことを確かめて下さい。 またデバイス行番号が二度登録されていないようにして下さい。 共用ライン アピアランスは IPCC がサポートしない Cisco CallManagerの機能です。 不注意に同じ行を備えている 2 台の電話との共用ライン アピアランスを設定することを試みることができます。 1 つの行番号を変更する場合、他は変更し、PG は正しいデバイスにログインできません。 この問題を解決するために、両方の行を削除し、Cisco CallManager に追加して下さい。

INVALID_SKILL_GROUP_SPECIFIED

ログインは少なくとも 1 つのスキル グループ（スキル グループ メンバー）のメンバーで Configure/ICM で、エージェント設定する必要があります。

既に別の電話にログオンされるエージェント

エージェントが別のデバイス ターゲットに（エージェントのペリフェラル番号が）表すようにまだ記録 されて いないことを確かめて下さい。 これをチェックする 1 つの方法はモニタ ICR を実行し、疑わしいエージェントのためのエージェント レポートからの自由の実行することです。 エージェントがログオンされる場合、これはエージェントがログオンされるデバイス ターゲットのネットワーク ターゲット ID を示します。 エージェントデータは awdb にこの AW に周辺装置のためのエージェントデータを送るために ICM を設定したときだけ現われます。

  • また awdb の Agent_Real_Time 表に対して isqlw でこれのために問い合わせる可能性があります。 最初に、エージェントのためのスキル ターゲットを見つけて下さい（たとえば、エージェントから PeripheralID = XXX および PeripheralNumber = YYY 『*』 を選択 しなさい）。 それからエージェントがログオンされるかどうか、チェック（たとえば、Agent_Real_Time から SkillTargetID = XXX 『*』 を選択 しなさい）。

  • PIM に procmon に接続し、dagent <agent 周辺装置 number> を実行するときまたこれがあるように確認できます。

既にログオンされるデバイス ターゲット

デバイス ターゲットに（インストルメントが）規定 するようにまだログオンされる別のエージェントがあっていない確かめて下さい。

  • これをチェックする 1 つの方法は awdb の Agent_Real_Time 表に対して isqlw を実行することです。 最初に、デバイス ターゲットのためのネットワーク ターゲット ID を疑わしい見つけて下さい。 たとえば、ConfigParam が「%1003%」を好む Device_Target から『*』 を選択 して下さい。 デバイス ターゲットがログオンされるかどうかこの場合、参照して下さい。 たとえば、Agent_Real_Time から NetworkTargetID = XXX 『*』 を選択 しなさい。

  • PIM に procmon に接続し、デバイス ターゲットをダンプするときまたこれがあるように確認できます。 デバイス ターゲットをダンプする 2 つの方法があります。 DDT コマンドはネットワーク ターゲット ID をように入力 奪取 し、デバイス ターゲットをダンプする。 deadt コマンドはデバイス ターゲット 設定からの /dn ストリングをように入力 奪取 し、デバイス ターゲットをダンプする。 たとえば、デバイス ターゲット /dn ストリングが /dn 9782755100 なら、deadt 9782755100 としてデバイス ターゲットをダンプします。

PG ユーザと関連付けられないデバイス

行き、見つけます PG が使用する USERID を『User』 を選択 し、/グローバル なディレクトリ、は Cisco CallManager Web ページに。 「関連付け、デバイス」をユーザはデバイスを制御する権限があることを確かめますチェックして下さい。

  • ユーザページのデバイスを（またはチェックを外されるチェックされる）発見できなければ（デバイスを保存し、ユーザ プロファイルを保存する）データベース間の同期に問題がある場合もあり、（Cisco CallManager がデバイスを保存するかところで）ディレクトリ サーバ。 ディレクトリ サーバ（DC Directory Server がことを）動作したらかどうか確認して下さい。

  • Windows NT イベント ビューアー アプリケーションログをチェックし、DC Directory または metalink からのエラーを探して下さい。 Import エラーが発生する場合、c:\dcdsrvr\bin から avvid_recfg を実行して下さい。

  • Microsoft が Cisco CallManager マシンで Java Virtual Machine （JVM; Java バーチャルマシン）インストールされていることを確かめて下さい。 これをテストするために、コマンド プロンプトからの jview を入力して下さい。 Cisco CallManager 2.4 に関しては、JVM を手動でインストールして下さい。 Cisco CallManager 3 に関しては、プラットフォームは Windows 2000 および JVM インストールです自動です。

非アクティブな電話デバイス

電話が、Cisco CallManager と登録されられて、エージェント制御なしで電話からコールをし、受信することできる動力を与えられるかどうか確認すれば。

エージェントはコールをすることができません

ない READY 状態のエージェント

エージェントが利用可能な状態でないログオンされることを確かめれば。  エージェントが利用できない場合、エージェントはコールをすることができません。 コールをするために、第 1 は準備ができなかったクリックします。

不正確なエージェントデスク設定

ある特定の数にダイヤルするときだけエラーがあったら、正常にダイヤルインできることを物理的 な電話からのそれらの数をチェックして下さい。 ICM によってダイヤルされる番号計画を設定する場合、数がダイヤルされた番号計画のワイルドカードの一致 1 にダイヤルするかどうか確認して下さい。 それからダイヤルされた番号計画エントリが識別する数の種類にダイヤルするエージェント割り当てについてはかどうかエージェントデスク設定 エージェント確認して下さい（たとえば、国際）。

PIM のダイヤルされた番号計画はアクセスをブロックします

各 PIM のために設定されるダイヤルされた番号計画は不正確に設定されるか、または正しく設定することができますいくつかにエージェントが呼出すことを防ぐために。 PIM ログのエラーは権限エラーを示す必要があります。 エージェントおよびデバイスのための数はエージェント コールにエージェントを作るのにダイヤルされた番号計画が使用されているときオーバーラップできません。

エージェントは短い コールを、待つなります新しいコールをするために作ります

ルータはエージェントがコールをするか、またはコールがエージェントにルーティングされるときエージェントを使用不可能にします。 このメカニズムは PIM がコールを着いた報告する前にルータがエージェントに別のコールをルーティングするようにします。 いくつかのネットワークは実際にコールをルーティングするために数秒かかります。 ルータはエージェントの状態に基づいてタイマーを取り消しません。

ルーティングクライアントから PIM にコールをルーティングするためにかけられる実時間が比較的短い場合、ルータの設定可能な時間を変更できます。 DOS Command ウィンドウのルータの 1 人で、rtsetting.exe を使用して下さい。 Extrapolation > Agent の下で検知 して下さい。 デフォルト設定は 10 秒です。 値が余りに短い場合、ルータはコールを受信することを約あるエージェントにコールをルーティングします。 これにより PIM はコールを廃棄します。

PIM のタイムアウトの既定値は 7 秒です。 regedt32 コマンドでこの値を修正できます。 このパスの「AgentReserveTimout」キーを追加して下さい:

HKEY_LOCAL_MACHINE\SOFTWARE\GeoTel\ICR\<cust_inst>\<pg_inst>\PG\CurrentVersion\
  PIMS\<pim_inst>\EAGENTData\Dynamic\

注: このキーはバージョン 4.1.5 設定に追加されます。

注: このキーはスペース制限による 2 つの行にここに現われます。

PIM 数はオリジナル イベントが処理される前に数秒ルータが PIM に新しいプリコール イベントを送信 することを防ぐべきルータ外挿タイマーより常により少しである必要があります。 これは PIM で問題を引き起こします。

コールが PIM 時間以降に到着する場合、コールは非 ACD コールとみなされ、コンテキスト変数、サービス、またはスキル グループ ヒントのどれもコールに割り当てられません。

エージェントは行くことができません ---- Not Ready、Busy、またはOtherの場合

"Active" 状態のエージェント

エージェントがコールにあり、準備ができなかった、使用中、または他をクリックすれば、エージェントの状態はすぐに変更しません。 これは計画的です。 エージェントはコールの完了までの話か保持された状態を維持します。 エージェントは用意しないか、準備ができたはたらかせるか、またはボタンが押される準備ができなかったはたらかせるために移行しました。 、コール端の後で、エージェントが利用可能にすぐに移行したら、発信の後で着信か利用可能設定 された後エージェントがあるようにエージェントデスク設定を確認し、もし可能であれば見て下さい。 これらの設定はエージェントがコールの間にボタンによって行うタスクを無効にします。

エージェントデスク設定は遷移を防ぎます

エージェントデスク設定を設定 ICM のエージェントがあるように確認し、必要なアイドル状態の原因がチェックされるかどうか参照して下さい。 チェックボックスがチェックされる場合、エージェントは理由コードなしでない READY 状態に入ることができません。 設定 ICM のエージェントデスク設定を一致するために Desktop_Settings.cfg を修正するかまたは設定 ICM のエージェントデスク設定を変更して下さい。

エージェントに割り当てられるエージェントデスク設定がない場合エージェントはログインにでき、が準備ができている行きます、エージェントは not_ready またはログアウトに行けません。 解決はエージェント アプリケーションを閉じることエージェントデスク設定およびログインを再度割り当てます。

エージェントは準備ができていない行くために待たなければなりません

ルータはエージェントがコールをするか、またはコールがエージェントにルーティングされるときエージェントを使用不可能にします。 このメカニズムは受け取られるようにルータが報告しますコールを PIM の前にエージェントに別のコールをルーティングするようにします。 いくつかのネットワークは実際にコールをルーティングするために数秒かかります。 ルータはエージェントの状態に基づいてタイマーを取り消しません。

ルート クライアントから PIM にコールをルーティングするためにかけられる実時間が比較的短い場合、ルータの設定可能な時間を変更できます。 DOS Command ウィンドウのルータの 1 人で、rtsetting.exe を使用して下さい。 Extrapolation > Agent の下で検知 して下さい。 デフォルトは 10 秒です。 値が余りに短い場合、ルータはコールを受信することを約あるエージェントにコールをルーティングします。 これにより PIM はコールを廃棄します。

エージェントは準備ができている行くことができません

PRIVILEGE_VIOLATION_ON_SPECIFIED_DEVICE

Login 要求および準備ができた要求のデータに不一致があります。 おそらく、インストルメント、エージェント ID、または周辺装置数は一致する。 適切なトレースを見るために procmon と CTI サーバ トレースおよび 0xf8 に一定 regset をつけて下さい。 サード パーティ（TP）トレースがオンになっている場合、また OPC か PIM で記録 しますこれを表示できます。

エージェントはログアウトできません

エージェント 現在のステートはコールをすることを防ぎます

エージェントが準備ができた作業にある場合エージェントがログアウトする前に、か利用可能な状態は準備ができなかったに準備ができなかった、作業エージェント最初に行く必要があります。 設定 ICM のエージェントデスク設定を一致するために Desktop_Settings.cfg を修正するかまたはエージェントデスク設定を設定します ICM を変更して下さい。

エージェントデスク設定はステートの変化を防ぎます

エージェントがない READY 状態にあり、それでもログアウトできない場合エージェントデスク設定を設定 ICM のエージェントがあるように確認し、必要なログアウト原因がチェックされるかどうか参照して下さい。

エージェントは電話でアクティブ コールかエージェントがTalkingであること、コールがないことを示します

およびログ エージェント

ソフトフォンがもはや物理的にないコールを示せば、エージェントの状態は話すことでスタックしていることができますまたは保持およびエージェントはログアウトできることではないです。 これは JTAPI または PIM のソフトウェアバグが原因である場合もあります。 Release ボタンが有効に なる場合条件をクリアするため、ソフトフォンからのコールをクリアする最初試み。 これがはたらかない場合、エージェントをログアウトするように試みて下さい。 Logout ボタンがはたらかない場合、終了し、ソフトフォンを再起動するため。 条件が持続する場合、ソフトフォンを終了して下さい、タスク マネージャを実行して下さい、キル geodcs.exe および common~1.exe を実行し、ソフトフォンを再起動して下さい。 これらのプロセスは無効なエージェントの状態を実行し、覚え続けることができます。

PIM の誤った記述のエージェント

procmon では、PIM でエージェントの状態をチェックして下さい。 エージェントデスクトップを再起動し、条件がないクリア、奪取できるより多くの手段があります。 CTI サーバおよび OPC は procmon のデバッグ インターフェイスとのコールをクリアするためにメカニズムをまたは opctest 提供します。 これは PIM ウィンドウ PG サービスか少なくとも終わりを循環させること他のオプションへわずかに希望する選択です。

コールはアラートの後ですぐにクリアするか、または確立しました

不正確なレジストリ 設定

regedt32 を使うと、これらのレジストリ 設定をチェックして下さい:

HKEY_LOCAL_MACHINE\SOFTWARE\GeoTel\ICR\<cust_inst>\<pg_inst>\PG\
  CurrentVersion\<pim_inst>\CallControl\MaxAlertingTimeAllowedForCall

および

HKEY_LOCAL_MACHINE\SOFTWARE\GeoTel\ICR\<cust_inst>\<pg_inst>\PG\
  CurrentVersion\<pim_inst>\CallControl\MaxConnectedTimeAllowedForCall

注: これらのレジストリキーはスペース制限による 2 つの行にここに現われます。

300 および 28800 にこれらの値をそれぞれ設定 して下さい。

ポスト ルーティングははたらきません

ルートをチェックし、スクリプトをルーティングして下さい

コールがスクリプトおよびスクリプト実行に正しく到達するかどうか確かめるのに AW 呼出しトレーサーツールを使用して下さい。 スクリプト エディタを実行し、スクリプトを監視して下さい。 問題のためのルータ、OPC および PIM ログを検知 して下さい。 ほとんどのルート エラーは無条件でトレースされます。

「周辺装置のルーティングクライアントに関してはチェックされる DN ラベル マップ」を使用して下さい

あります分類される設定 ICM の各ルーティングクライアントの設定が「使用 DN/Label マップ」。 この設定が Yes に行われればダイヤルされた数および可能性のある先のラベルの各組み合せのための"Dialed Number Label" エントリを設定する必要があります。 この設定は PG ルーティングクライアントで役立たないし、いいえ」に「設定 する必要があります。

ルートされたデバイスターゲットのために設定されるラベル無し

ルーティングクライアントで設定されるラベルを確認して下さい。 ラベルが各クライアントで同一でも各クライアントのラベルを設定して下さい。

CTI ルートポイントは設定されなかった on Cisco CallManager ではないです

ルーティングするポストを使用することは Cisco CallManager の「CTI ルートポイント」を設定し、ルート ポイントに望ましい電話番号によって行を割り当てる必要があります（たとえば、"5000"）。 エージェントに関しては使用しますダイヤルされた番号計画をルーティングを掲示するために呼出します。 Cisco CallManager CTI ルートポイントにダイヤルするエージェントは CTI デスクトップ バージョン 4.1.9 の IPCC ソフトフォンを混同します。

CTI ルートポイントのためのデバイスは PG ユーザが制御するデバイスのリストついていません

グローバル なディレクトリの下でリストに関連付けました Cisco CallManager ユーザ Webページの PG ユーザ向けのデバイス」を CTI ルートポイント デバイスをの「追加して下さい。 新しいデバイスを作成する場合、行を最初に追加し、次にユーザ「関連付けましたデバイス」リストにデバイスを追加して下さい。 ユーザデバイスリストで既に存在 して、JGW のための JGW を再起動することを新しい行を認識するために必要とするデバイスにより多くの行を追加すれば。 ただし新しいデバイスを追加したら、行をデバイスに追加し、次にユーザデバイスリストにデバイスを、JGW 新しいデバイスを認識こと必要があります追加して下さい（30 秒以内程で）。

ダイヤルされた数によって設定される on Cisco ICM 無し

数が周辺装置ルーティングクライアントのために設定されることをダイヤルされた数をチェックして下さい。 procmon を JGW に実行し、「トレース *ROUTE*」としてトレースをつけて下さい（大文字/小文字の区別がある）。 ダイヤルされた数に関係するエラーのためのチェック JGW ログ。 始動に、ダイヤルされた数のためのルート コールを登録する JGW 試み。 コールがダイヤルされた数になされるとき、ゲートウェイは「RouteEvent」を受け取ります。

ダイヤルされた数と共に、コール タイプがスクリプトに正しく作成され、マップされるかどうか確かめて下さい。

JGW の再始動が必要とならないことを確認して下さい

ICM によってダイヤルされる数を設定する場合、CTI ルートポイントを設定し、ユーザデバイスリストに追加しましたしかし数がダイヤルされるときまだルート要求を、JGW を再起動する必要がある場合もあります受け取りません（または PG を循環させるため）。 JGW （トレース *ROUTE*）のトレースをつけ、場合その時だけ再起動する必要がありますエラーがプロバイダにアドレスを示すない見ます。 通常、JGW は再起動する必要なしでユーザデバイスリストに追加される新しい CTI ルートポイントを認識できる必要があります。 また既に存在 して、JGW は再起動する必要なしではそれらを認識しないこと行が CTI ルートポイントに追加される場合。 既にあっているデバイスに新しい行の代りに再始動を各々のダイヤルされた数のための Add a New CTI Route Point 避けられます必要があります。

注: これは DeviceListPolling が PIM の winnt \ Java \ライブラリ ディレクトリの JTAPI.ini ファイルでつくことを仮定します。 DeviceListPolling が消える場合、DeviceListPolling をつけて下さい。 DeviceListPolling が消え、ユーザー一覧にデバイスを追加すれば場合、新しいデバイスを見るために PG のための PG か少なくとも JTAPI GW を循環させて下さい。

ルート ダイアログがあるように OPC ログを確認して下さい

コールがルート ポイントになされるとき「デバッグ /routing」をトレースするルートをつけ、エラーがあるかどうか OPC ログを点検するのに opctest 使用して下さい。 ルート要求が受け取られ、ラベルが戻ることを確認して下さい。 ルート要求は「CSTA_ROUTE_REQUEST」および「ICR_NEW_CALL_REQ」メッセージとして現われます。 戻されたラベルは「ICR_CONNECT」メッセージとして現われます。 IF エラーは、「ICR_DIALOG_FAIL " メッセージ instead of " ICR_CONNECT " メッセージを見る場合があります発生します。 この場合、エラーがあるかどうかルータログを点検して下さい。

ルート ダイアログがあるようにルータログを確認して下さい

コールがルート ポイントになされるときトレースするルートをつけ、エラーがあるかどうかルータログを点検するのに rtsetting.exe を使用して下さい。

すべての必須 ラベルが設定されることを確かめて下さい。 ルート スクリプトが IPCC/EA エージェントを目標とする場合、各目標とされるデバイスターゲットのポスト ルーティングクライアントのために設定されるラベルを持たなければなりません。

ルーティングスクリプトはエージェントが利用可能になるときコールを削除しません

エラーがあるかどうかルータログを点検して下さい。 どれもなければ:

ルータログの No エラー ---- キュー ノードはスキル グループ ベース 優先順位に並べられます

キュー ノードが基本優先順位に並べられる場合、エージェントが利用可能になると何も起こりません。 この問題を解決する 2 オプションがあります:

  • AutoLoginBase （使用 rtsetting.exe）と呼ばれるルータ レジストリ 設定があります。 コールが基礎スキル グループ多かれ少なかれに予想通りはたらくために並べられるようにこの設定を変更して下さい。 このキューの種類が起こるときプリファレンスはセカンダリ スキルにプライマリへありません。

  • キュー ノードのプライマリおよび/またはセカンダリ スキル セットに明示的に並べて下さい。

ルータログはターゲットのために設定されないラベルを示します

疑わしいこのルーティングクライアントがルーティングできる他のすべてのターゲットおよびデバイス ターゲットのための設定 ラベル。 Configure ICR にこれをするより多くの効率的のための AW バルク コンフィギュレーション ツールを使用して下さい。

すべてのエージェントおよびキュー ポートが使用中である時聞かれる Ring No Answer

ルータログをチェックして下さい

  • ルート エラーは無条件でトレースする必要があります。

  • ルート パスをテストするのに呼出しトレーサーツールを使用できます。

  • コールがルート ポイントになされるときルート要求トレースをつけ、エラーがあるかどうかルータログを点検するのに rtrtrace を使用して下さい。

  • すべての必須 ラベルが設定されることを確かめて下さい。 ルート スクリプトが IPCC/EA エージェントを目標とする場合、各目標とされるデバイスターゲットのために設定されるラベルを持たなければなりません。 各デバイス ターゲットはコールを発信することを試みる各ルート クライアントのために設定されるラベルがなければなりません。 このようにコールが対応可能なエージェントにネットワークからプリルーティングされせば直接、ネットワーク ルーティングクライアントは関連するデバイス ターゲットのためのラベルがなければなりません。 コールが VRU で最初にキューに入り、次にエージェントに提供される場合、VRU ルーティングクライアントは関連するデバイス ターゲットのためのラベルがなければなりません。

DN Label Mapping が設定 ICM のルーティングクライアントで消えることを確かめて下さい

使用 DN/Label マップが設定 Manager/PG エクスプローラ内の Routing Client タブ チェックされないことを確かめて下さい。

PIM ログをチェックして下さい

  • PIM （trace precall、*call_event* をトレースするため）のトレースをつけ、ログをチェックするのに procmon を使用して下さい。 ルータからプリコール メッセージが現れます。 またエージェント拡張に「DevTgDevStr」セットをとの「DeliveredEvent」見ます。 コールが出て来ない場合、ラベルがルート クライアントのために正しいことを確認して下さい。

任意の転送は矛盾した結果を得ます

IPCC は Cisco CallManager が矛盾した結果を提供するのでコールを保留の状態で送信し、新しいコールをするためにオプションをサポートしません。 これは製品の機能強化とみなされ、将来のリリースのために考慮することができます。

交替ははたらきません

コンサルト コールが切り替えられたり/交互になったり/保持されたり/取得されるとき、Cisco CallManager は相談アソシエーションを壊します。 これはサポートされない任意の転送シナリオという結果に終ります。 エージェントは顧客に再接続し、相談し新しいの始めることができます。 IPCC ソフトフォンは解決される、しかしサードパーティベンダーは不平を言うことができますまで alternate ボタンを無効に します。

会議される 側は他のパーティの会議できません

会議発信側だけ会議により多くのパーティを追加できること Cisco CallManager に制限があります。 他のパーティは Cisco CallManager のより多くのパーティを追加できません。

予想に反してログアウトされるエージェント ステーション

エージェントデスク設定 Inactivity タイマー

エージェントデスク設定では、ない READY 状態のエージェントをログアウトする時間設定があります。 最大非アクティブ時間は 2 時間ですしかしより少しである時期を設定できます。 利用可能な状態のエージェントはが非アクティブ状態でログアウトされるべきではないです。 エージェントは用意しないこと準備ができたから Ring No Answer タイマーが切れる場合移行しました（また設定可能なエージェントデスク設定）。

CTI サーバ ハートビート時間

CTI サーバは設定されたハートビートひとときを過します。 帯域幅の問題のより古いコンピュータ、働きすぎる CTI サーバ、またはネットワークは根本的な原因である場合もあります。 CTI サーバ ログはログのエラーを報告する必要があります。

エージェントはエージェントデスク設定の設定によって動作しません

一致しなければエージェントがどのようにに処理されるかのエージェントデスク設定 Configure ICR （M）およびエージェントコンフィギュレーションファイルは両方なりません。

コンフィギュレーションパラメータの ICM の周辺装置設定に作業タイマーがあります。 自動作業可能状態 （auto-available）の 30秒遅延を設定 するためにパラメータように\ WORKTIMER 30 設定 して下さい。

デスクトップ コンフィギュレーション ファイルはに常駐します:

\program files\geotel\cti desktop\Desk_Settings.cfg

Desk_Settings.cfg と Configure ICR の着信の作業モードはデータにとの必須、必須設定 する必要があります（M）エージェントデスク設定。 データと必要とされて自動作業可能状態 （auto-available）のオプションを置き換えます。

コンサルト転送失敗

JTAPI GW ログを検知 し、コンサルト転送がなぜ失敗するか示すエラーがあるかどうか参照して下さい。 エージェントソフトウェア割り当てがコンサルト コールの保持したり/取得するまたは交互 操作かどうか確認して下さい。 どちらかのコールが開かれたり/取得されるとき、コールは Cisco CallManager によってもはや諮問、「任意」転送とみなされません。 Cisco CallManager に任意の転送に問題があります。 転送を再接続するか、または完了するためにユーザを時諮問コールで制限して下さい。

パーティにハングアップします相談して下さいしかし Call Appearance は消えません

会議が完了しないとき Cisco CallManager に現在相談するために始められる会議のための接続解除 イベントに問題があります。 エージェント電話で Call Appearance をクリアするコールを二回目切断して下さい。

VRU への変換ルートははたらきません

最初に、アクティブスクリプトを監視して下さい。 それからルーティングクライアントおよび VRU のルータ、OPC および PIM ログをチェックして下さい。 ほとんどのエラーは無条件でトレースされますが、何が起こるかの得ますまでよりよいピクチャをトレースを回すことができます。

変換ルート シーケンスはここにあります:

  • ルーティングクライアントはルータに新しい Call 要求をします。

  • ルータは IVR にコールを提供する必要があるラベルのルーティングクライアントに接続を戻します。

  • IVR は周辺装置ターゲットを調べる VRU PG 使用 RequestInstruction の上でそれから送信 する必要があります。

  • ルータは周辺装置変換ルートに要求手順の周辺装置ターゲットを目標としますそれを待っていますマッチさせます。

  • ルーティングスクリプトは顧客によって設計されているように実行スクリプトかキュー ノードと続きます。

失敗パスを見つけ出すためにアクティブスクリプトを監視して下さい。 エラーのためのルータ トレースを検知 して下さい。 ルート クライアントが最初のラベルを受け取るかどうか確認して下さい。 VRU がコールを受信するかどうか確かめて下さい。 VRU が VRU PIM または OPC レベルで要求手順の上で送信 するかどうか確かめて下さい。

ルート要求は「ルート スクリプトの VRU ノードへの変換ルート」に到達しません

スクリプトを監視し、要求が VRU ノードに変換ルートに到達するかどうか確かめて下さい。

最初に、ルート スクリプトで、選択される変換ルートの選定されたまたはルート SELECT ノードはサービス制御 VRU にルートを変換する十分ではないです。 VRU ノードへの変換ルートが必要となります。

2 番目に、モニタは変換へのコール gets がノードをルーティングすることを示す必要があります。 ここでは障害は変換ルートが判別することができないか、または RequestInstruction ルート要求 メッセージが IVR から届かなかったことを意味します。

ルータログの変換ルート時間出口

変換ルート タイムアウト エラーはルータが要求手順を受け取らないことを示します。 エラーのための OPC および VRU PIM をおよび RequestInstruction が着くかどうか見るために確認して下さい。

発生するものがのルータによりよい示す値のためのルータの rtrtrace ツールが付いているターンアップ「変換ルーティング」および「ネットワーク VRU トレーシング」。 VRU PG OPC では、opctest のターンアップ サービス 制御レポート。

VRU PIM ログはトランクグループで見つけられない DNIS を X 示します

要求手順は VRU PG のために設定されるトランクグループの 1 つのトランク グループのペリフェラル 番号にマップする有効なトランクグループを示す必要があります。 修正された場合トランク グループのペリフェラル 番号のアップデートを受信するために VRU PG を循環させて下さい。

ICM 設定をチェックして下さい

DN Label Mapping が IVR PG ルーティングクライアントで消えることを確かめて下さい。 IVR PG はネットワーク VRU 割り当てを必要とします。 ネットワーク VRU はタイプ 2 である必要があります。 IVR PG は割り当てられるネットワーク トランクグループおよびトランクグループがなければなりません。 トランクグループでネットワーク トランクグループを参照して下さい。

NIC/post ルーテイィング ページ周辺装置ターゲットの DNIS のそれぞれのためのラベルがなければなりません。 （変換ルートウィザードのルーティングクライアントの要求のための DNIS とラベルに同じをして下さい。 プレフィクスで選択しますプレフィクス = DNIS オプションをこれを設定できます。）

VRU ルーティングクライアントはエージェントが利用可能になるとルーティングするデバイス ターゲットのために設定されるラベルを必要とします。

解決して下さい Cisco IP IVR - ICM インターフェイス

この Cisco IP IVR セクション カバーは IP IVR および ICM 間の Configuration エラーを解決する方法をおよび IVR PG ポスト ルーティングおよび変換ルーティングのための設定におけるよくある問題が含まれています。 一般の IVR エラーに関する詳細については Cisco IP IVR トラブルシューティング ガイドを参照して下さい。

一般に、appadmin > エンジン > トレースファイル Webページの下で MIVR ログをチェックして下さい。

  • Cisco CallManager、IVR および ICM で設定される IVR CTI ポートおよび CTI ルートポイント。

  • IVR CTI ポートおよび CTI ルートポイントは Cisco CallManager グローバル なディレクトリの IVR ユーザと関連付けられます。

  • Service Control チェックボックスはチェックインされた IVR ICM 設定です。

  • IVR のスクリプトネームは ICM の定義一致ネットワーク VRU スクリプトネームのスクリプトを書きます。

  • IP IVR の VRU PG 一致 CTI ポートグループ数のトランクグループ数。

変換ルートは失敗します

解決するのに使用する他の操作すべてと共にまたこれらの事柄を IP IVR の解決を助けるように試みることができます。

  • MIVR ログをチェックして下さい。 このログは問題領域を一般に指すことができます。

  • ターンアップ on Cisco IP IVR への使用デバッグ設定は SS_TEL および LIB_ICM です。

  • IP IVR の jtprefs と IP IVR のための Jtapi ログを on Cisco 回して下さい。 デバッグツールを参照して下さい。 IP IVR エンジンを後停止した、トレースをつけ始めて下さい。

  • IP IVR JTAPI 変換ルート ポート グループの CTI ポートグループ数が ICM のトランクグループ 設定の周辺装置数と一致するかどうか確かめて下さい。

スクリプトはエラー メッセージを再生しませんし、再生しません

かどうか確かめるためにエンジントレース ファイルの下で IP IVR ログをチェックして下さい:

  • スクリプトを受け取られます実行して下さい。

  • IP IVR はスクリプトを見つけることができます。 リポジトリ 管理ツールが付いているアップロード スクリプト。

  • IP IVR はプロンプトを見つけることができます。 ユーザが定義するプロンプトは IP IVR に\ wfavvid \プロンプト\ユーザ\ en_us \に常駐します。

JTAPI ステータスは部分的なサービスを示します

これは一般に意味しますいくつかの IP IVR で設定される CTI ポートまたは CTI ルートポイントを Cisco CallManager の IP IVR ユーザと設定されなかったりおよび/または関連付けられたことを。

これはまたスクリプトがまたはリポジトリ マネージャにアップロードされるために正しく指名されないことを意味できます。

IP IVR の ICM ステータスは部分的なステータスを表示します

通常、この条件は一方または他の部分的な設定か組合わせを誤まられた設定を示します。

コールがルータから削除されるとき聞かれるプロンプトをどもって下さい

これは Configure ICR のネットワーク VRU スクリプト設定のほんのわずかのタイムアウトを割り当てる不適切に設定されたルーティングスクリプトです。

ICM インターフェイスのために IP IVR と利用可能であるいくつかのスクリプトは ICM ネットワーク スクリプト設定の長時間、既定の時刻をです 3 分非常に実行しますが。 スクリプト時および run script failure path が別の実行スクリプトをする場合、これらの実行スクリプトは IVR で基本的にキューイングされます。 スクリプトが削除されるとき、多くのスクリプトが互いに遊ぶのを聞きます。

IVR サービス統計情報を解決して下さい

IVR 統計情報は IPCC サービス レベル レポートにとって重要です。 従って、方法の情報は解決するここに含まれています。 ルータの外観、VRU の設定されたコールが並べられるように数えられる変更および接続されるの代りの VRU PG として。 コールがルーティングされるとき、答えられるように報告されます。 キューの顧客がコールを切断するとき、放棄されるように報告されます。 追加詳細については熱い修正 53 および 54 の readme.txt を参照して下さい。 ルータは示す特別なキュー イベントの下でどの状態コールがルータにであるか送信します。

VRU PIM に特別なレジストリ設定があります従って自発的に最小中断を確認するためにこの機能をつけて下さい。

1つ以上のエンタープライズ Peripheral レポートに VRU サービスおよび Cisco CallManager PG サービスを追加するとき企業サービス リアルタイムレポート 10 はこのデータの特別な使用を作ります。 企業サービス リアルタイムレポートは VRU PG および Cisco CallManager PG サービスが企業サービスで報告目的のためにグループ化されることを必要とします。

他の有用なキュー レポートはリアルタイムおよび史的記録のための新しいコール タイプ レポートであり、スキル グループ リアルタイム グリッドは今スキル グループに対してキューに入るコールを示します。

サービス統計情報か終了コール詳細レコードは作成されません

VRU PIM は CSTA イベントを生成しません。 VRU ページ設定の Service Control レポートをつけて下さい。 これは ServiceControlQueueReporting のレジストリキーにあります:

HKEY_LOCAL_MACHINE\SOFTWARE\GeoTel\ICR\<cust_inst>\<PG_inst>\PG\CurrentVersion\
  PIMS\<pim_inst>\VRUData\Config

注: このレジストリキーはスペース制限による 2 ラインにここに現われます。

VRU は接続される、要求に応じて並べられないようにすべてのコールを報告します

ServiceControlQueueReporting レジストリキーないペースのまたは設定 されない 1 に

VRU PIM のためのスタートアップログはない場合不平を言う必要があります。

ServiceControlQueueReporting キーを追加し、1 に値をの設定 して下さい:

HKEY_LOCAL_MACHINE\SOFTWARE\GeoTel\ICR\<cust_inst>\<PG_inst>\PG\CurrentVersion\
  PIMS\<pim_inst>\VRUData\Config

注: このキーはスペース制限による 2 つの行にここに現われます。

コールは間違った サービスに対して数えられるか、または In Service レポートを現われません

OPC ログは見つけられないサービス マッピングを示します

OPC ログはコールが間違った サービスに対して数えられるか、または In Service レポートを現われないときサービス マッピングがないことを示します。

問題を報告する Cisco ICM

Cisco ICM はデータ呼び出し型、サービスおよびスキル グループ表の容易な相関のために設計されていません。 数に各グループで一般にわずかに異なる意味があります。 コールのためのたった 1 つのサービスがあります、複数のエージェントが複雑である場合 2 人のスキル グループがある場合もあります。 redirect on no answer （RONA）機能は別の終了レコードの生成なしで多分別のポスト ルートを生成します。

エージェントスキルグループは、スキル グループ、サービス、コール タイプ数バランスをとりません

  • 症状： 扱われるコールか他の統計情報フィールドはサービス、コール タイプ、および/またはスキル グループ レポートの間で一致する。

  • 条件： コール タイプ、サービスおよびスキル グループは論理的なマップと互いに設定されますが、レポートはまだ完全に一致しません。

  • トラブルシューティング： コール音量が毎秒 1 つのコールより小さい場合、CSTA、PIM、エージェントおよびサード パーティ イベントに適切ように OPC、PIM および JTAPI GW のトレース設定を、つけて下さい。 手順に関してはこの資料のツール セクションを参照して下さい。

  • コールフローを文書化して下さい:

    • 最初のポスト ルートは Cisco CallManager PG か VRU PG にありますか。

    • 返事（FONA）で前方設定されないし、FONA は何にリダイレクトするために設定されますか。

    • デフォルト スキル グループは周辺装置第 0 で非ルーテッドおよび送信呼び出しからルーティングされたコールを分けるために設定されますか。

の 1 日これらの表からの履歴データを「『*』 を選択 します」文をつかんで下さい:

  • Peripheral_Half_Hour

  • Call_Type_Half_Hour

  • Service_Half_Hour

  • Skill_Group_Half_Hour

  • Termination_Call_Detail

  • Route_Call_Detail

Cisco CallManager を解決して下さい

Cisco CallManager のトレースを収集するとき、Services > Trace Flags の下で Cisco CallManager Admin ページからのフラグを回すことができます。 0xCB05 は CTI エラーの SDL トレーシングのために設定されるよい Trace フラグです。 サービスパラメータの下で 0xCB05 をデバッグするために設定 して下さい。 AVVID TAC ケースを参照して下さい: 詳細についてはトラブルシューティング情報の収集。 トラブルシューティングガイドを含む Cisco CallManager オンライン ドキュメントを、参照して下さい。

Cisco CallManager のためのトレースをつけて下さい

Cisco CallManager のためのトレースをつける方法の情報に関しては Cisco テクニカル サポートのための設定 Cisco CallManagerトレースを参照して下さい。

Cisco CallManager IP アドレスを変更して下さい

Cisco CallManager IP アドレスの変更を参照し、サーバ名を変更して下さい。

  1. セットアップの実行 on Cisco CallManager PG および Cisco CallManager PIM のための変更 JTAPI サービス。 拡張 モビリティ、および/または電話サービスがあれば。

  2. CRA エンジンを停止して下さい。

  3. CRA -エンジン 設定の下で IP アドレスを変更して下さい。

  4. JTAPI の下で IP を変更して下さい。

  5. サーバの DC Directory サービスを停止して下さい。

  6. ディレクトリ設定の IP アドレスを変更して下さい。

  7. Cisco CallManager で- System > Server の下で IP アドレスを変更して下さい。

  8. System > Enterprise Parameters の下で URL の IP アドレスを変更して下さい。

  9. Features > Phone Services の下ですべての URL の IP アドレスを変更して下さい。

  10. 変更サーバのIPアドレス-ネットワーク Properties。

  11. 新しい IP アドレスに DHCP オプション 150 を変更して下さい。

  12. DC Directory のホテル プロファイルの IP を、Cisco CallManager > System Profile > hoteling 変更して下さい。

  13. SQL Enterprise Manager を開きます。

  14. 差込式表の URL の IP アドレスを変更して下さい。

コンフィギュレーション変更をバックアップするため:

  1. stiBackup 設定を参照して下さい。

  2. すべての適切なタブの下でサーバ IP アドレスを変更して下さい。

デバッグツール

Procmon

Procmon は PIM および JTAPI GW プロセスをデバッグするのに使用できるコマンド・ライン ツールです。

  • 使用方法： procmon <customer name> <node> プロセス。

    • Procmon IPCC pg1a pim1

    • Procmon IPCC pg1a jgw1

    • Procmon IPCC cg1a ctisvr

プロセスのそれぞれのいくつかの有用なトレース設定はここにあります:

  • JTAPI GW （使用 procmon）

    • JT_TPREQUESTS をトレースして下さい（サードパーティの要求トレースをつけます）

    • JT_JTAPI_EVENT_USED をトレースして下さい（JTAPI イベントのためのトレースを PG 使用つけます）

    • JT_PIM_EVENT をトレースして下さい（PIM に送られるイベント メッセージのためのトレースをつけます）

    • JT_ROUTE_MESSAGE をトレースして下さい（ルーティングクライアント トレースをつけます）

    • トレースして下さい JT_LOW* （根本的な JTAPI および CTI 層に基づくトレース）を

  • PIM （使用 procmon）

    • tp* をトレースして下さい（サードパーティの要求トレースをつけます）

    • trace precall （プリコール イベント トレースをつけます）

    • *event トレース（エージェントおよび呼出しイベント トレースをつけます）

    • トレース csta* （CSTA 呼出しイベント トレースをつけます）

  • CTI サーバ（使用 procmon）

    • regset EMSTraceMask 0xf8 （ラップすること本当らしい有用な CTI サーバ トレースをつけます）

OPCtest

Opctest は PG の OPC プロセスをデバッグするコマンド・ライン ツールです。

  • 使用方法： /cust <customer name> /node opctest <node>

    • opctest /cust IPCC /node pg1a

  • 有用な設定

    • デバッグ /agent （エージェント イベント トレースをつけます）

    • デバッグ /routing （イベント トレースをルーティングすることを回します）

    • デバッグ /cstacer （csta イベント トレースをつけます）

    • デバッグ /tpmsg （サードパーティ コール 要求トレースをつけます）

rttest

Rttest は ICM のルータプロセスをデバッグするコマンド・ライン インターフェイス ツールです。 GUI バージョンについては rtrtrace を参照して下さい。

  • 使用方法： rttest /cust IPCC

rtsetting.exe

ルータ レジストリ 設定を変更する GUI ツール。

  • デフォルトに戻って設定を行うオプションがあります。

rtrtrace.exe

ICM のさまざまなルータ トレースをつける GUI ツール。

  • IPCC のために有用な設定は特に次のとおりです:

    • –削除する問題のための…キューイング。

    • Service Control – VRU インターフェイスにおける問題のための…。

    • 変換ルーティング–変換ルートにおける問題のための…。

dumplog

テキストファイルへのダンプ Cisco ICM バイナリファイル。 プロセス ログファイル ディレクトリにディレクトリを変更して下さい。

  • OPC、PIM および JtapiGW プロセス ログ ファイルはに ICR \ <customer_name> \ <node> \ログファイル\常駐します。

  • PG、>cdlog <cust> <node> を入力するところで cdlog と呼ばれるバッチファイルがあります。

  • 使用方法： dumplog プロセス名

    • Dumplog/」（異なる dumplog オプションのヘルプのために）

    • Dumplog jgw1

    • Dumplog pim1

    • Dumplog OPC

vrutrace

VRU PG キャプチャ ファイルを表示するツール。 dumplog への類似したをはたらかせます。

コール トレーサー

ルーティングスクリプトをデバッグするのに使用できる Cisco ICM ツール。  AW の AW メニュー 項目のこのツールを見つけることができます。

jtprefs

これは IP IVR の JTAPI クライアントのための JTAPI トレースをつけるツールです。 IPCC PG の JTAPI トレースは procmon インターフェイスと制御されます。 このツールはプログラム ファイル\ CiscoJtapiTools に\常駐します。

パフォーマンス モニタ

Cisco CallManager、Cisco IP IVR および ICM のためのリアルタイムデータを示す Microsoft Windows 2000 管理ツール。 、登録されているデバイス進行中のコールおよびプロセス CPU稼働率を表示できます。 Start > Programs > Administrative Tools の下でこのツールを見つけることができます。

ログ ファイル

Cisco ICM ログ ファイル

Cisco ICM ログ ファイルはに\ ICR \ <cust> \ <node> \ログファイル常駐します。 ここでは、顧客はカスタマ インスタンス名およびノード参照 pg1a、ルータのための RA、cg1a、等々参照します。 ログ ファイルを表示するのに dumplog を使用して下さい。

注: vrutrace のようなトレース ツールが付いているビュー イベント キャプチャ ファイルできます。 これらのファイルは異なるディレクトリにあります。

Cisco CallManager ログ ファイル

Cisco CallManager ログ ファイルはトレース ディレクトリと普通に\プログラム ファイル\ cisco \ ccm \トレースの常駐します:

  • Ccm - CallManager SDI ログ。

  • Dbl -データベース レイヤ ログ。

  • Sdl -呼出し シグナリング ログ。

  • Tftp - TFTPサーバのためのログ。

トレース設定の下で Cisco CallManager Admin ページからのこれらのファイルのトレース設定を修正できます。 Cisco CallManager のサービスパラメータの下で SDL トレース設定を修正できます。

IP IVR ログ ファイル

IP IVR ログファイルはに\プログラム ファイル\ wfavvid 常駐します。 またエンジントレース ファイルの下で AppAdminページからの IPIVR ログ・ファイルを表示できます。

jtprefs.exe と JTAPI イベントをつけ、IP IVR エンジンを再起動するとき Cisco JTAPI クライアント ログを調べることができます。

有用なプロファイルデータ

ケースをオープンするためにデータを収集するときログ ファイルに加えてこのセクションに、リストされているデータを収集して下さい。

エージェントの数

設定されるエージェントの数とは何か。

使用されるゲートウェイ

何ゲートウェイが設定されますか。

コンポーネントのソフトウェアバージョン

Cisco CallManager、JTAPI クライアント、ICM、ゲートウェイ IOS バージョンおよび IP IVR。

  • Help > About > 詳細の下で Cisco CallManager admin Webページの Cisco CallManagerバージョンを見つけることができます。

  • JTAPI クライアントバージョンを見つけるため、単に Cisco CallManager PG のディレクトリ\ winnt \ Java \ライブラリのコマンド プロンプトの型 jview CiscoJtapiVersion。

  • また IP IVR バージョンを見つけることができます。

IVR 型

どのような IVR が使用中ですか。

プラットフォーム

物理メモリの使用中/CPU/および量はどのようなプラットフォームであるか。

関連情報

このドキュメントは役に立ちましたか?

Feedbackフィードバック

シスコに問い合わせ

このドキュメントは次の製品に対応しています