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

ダウンロード オプション

  • PDF     (662.9 KB)
    Adobe Reader を使ってさまざまなデバイスで表示
Updated: 2006 年 1 月 9 日
Document ID:23843

偏向のない言語

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

翻訳について

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

内容

はじめに
前提条件
要件
使用するコンポーネント
表記法
現象およびトラブルシューティング アクション
Cisco IPCC PIM がアクティブにならない
JGW プロセスがアクティブにならない
ディレクトリの問題（設定、動作しない、ディレクトリ パスワード）
エージェントがログインできない
エージェントが発信できない
エージェントが移動できない – 受信不可、ビジー、またはその他
エージェントが [Ready] 状態に移行できない
エージェントがログアウトできない
エージェントが [Active Call] または [Agent Talking] を表示するが、実際には通話がない
コールがアラート直後または接続確立直後にクリアされる
ポスト ルーティングが機能しない
エージェントが利用可能になってもルーティング スクリプトがコールをデキューしない
すべてのエージェントおよびキューイング ポートがビジー状態のときに Ring No Answer が聞こえる
任意の転送が矛盾した結果をもたらす
代替が機能しない
電話会議への参加を許可されたパーティが、ほかのパーティを電話会議に呼べない
エージェント ステーションが突然ログアウトする
エージェントがエージェント デスク設定のとおりに動作しない
打診転送が失敗する
VRU へのトランスレーション ルートが機能しない
ルート要求がルーティング スクリプトの「Translation Route to VRU」ノードに到達しない
ルータ ログにトランスレーション ルートのタイムアウトが記録される
VRU PIM ログがトランク グループ X に DNIS が見つからないことを示す
ICM 設定のチェック
Cisco IP IVR - ICM インターフェイスのトラブルシューティング
トランスレーション ルートの失敗
スクリプトがエラーメッセージを再生しない、または再生する
JTAPI ステータスが PARTIAL_SERVICE 状態
IP IVR の ICM ステータスが部分的なステータスを示す
コールがルータからデキューされるとき音声ガイダンスが断続して聞こえる
IVR サービス統計情報のトラブルシューティング
サービス統計情報または終了コール詳細レコードが作成されない
すべてのコールが要求どおりキューされずに接続されたことを VRU が報告する
コールが間違ったサービスに対してカウントされる、またはコールがサービス レポートに記録されない
Cisco CallManager のトラブルシューティング
Cisco CallManager のトレースをオンにする
Cisco CallManager の IP アドレスを変更する
デバッグツール
Procmon
OPCTest
rttest
rtsetting.exe
rtrtrace.exe
dumplog
vrutrace
Call Tracer
jtprefs
Performance Monitor
ログ ファイル
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

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。

表記法

表記法の詳細については、『シスコ テクニカル ティップスの表記法』を参照してください。

現象およびトラブルシューティング アクション

PG ログの IPCC の部分を見ます。ペリフェラル インターフェイス マネージャ（PIM）、オープン ペリフェラル コントローラ（OPC）またはコンピュータ テレフォニー インターフェイス（CTI）サーバのログで不特定エラーが表示されたら、問題についての詳しい説明を得るために JTAPI Gateway（GW）のログを直接確認します。JTAPI インターフェイスには、サードパーティのリクエストで問題が生じた例外の記録が残されます。これらの例外はエラー コードなしの文字列の説明でのみ提供されます。その結果、PIM/OPC/CTI サーバは多くのエラーを不特定のエラーとしてログに残します。

Cisco IPCC PIM がアクティブにならない

PIM が有効化されていない

PIM ログがあることを確認します。PIM ログがなければ、Cisco ICM Setup でこのペリフェラルが有効になっているかどうかをチェックします。ペリフェラルが追加されたとき、ペリフェラルを有効化する必要が生ずる場合があります。

[Edit] > [Peripheral] を選択し、[Enabled] チェックボックスをオンにします。

PIM が再起動する

PIMプロセスが再起動したら、dumplogユーティリティを使用してCisco CallManager PGでPIMログを表示します。ログ ファイルに OPCHeartbeatTimeout エラーがある場合、以下のレジストリ設定を変更します。変更には regedt32 を使用します。

eagtpim dynamic data の下のレジストリ OPCHeartbeatTimeout の値を 10 に変更します。パスは次のとおりです。

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

注：スペースの制約上、このキーは2行で表示されています。

PIM ログ ウィンドウで PIM がアイドル状態

PIM プロセスがアイドル状態の場合、次のチェックを実行します。

  • PIM ログのチェック。「Attempt to Activate」が少なくとも毎分 1 回は表示されているはずです。

  • PIM がアクティブでない場合は、OPC ログを確認するために dumplog ユーティリティを使用します。opctest を実行して、OPC プロセスがルータから設定を受信しているかどうかを確認します。

  • OPC プロセスがルータから設定を受信していなければ、dumplog ユーティリティを使用して pgagent ログを表示します。pgagent プロセスは、セントラル コントローラに対するアクティブ パスを持っている必要があります。pgagent がアクティブ パスを持っていない場合は、ネットワーク接続と、PG セットアップの DMP 設定を確認します。ルータで、dumplog ユーティリティを使用して ccagent ログを表示します。ルータでデバイスとして PG デバイス（DMP システム ID）が有効になっているかどうかを確認します。

  • セットアップまたは DMP レジストリ設定を用いて、PG をルータ設定で有効化します。

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

    注：DNSとDHCPの間に不一致がある可能性があります。

  • ルータの IP アドレスが c:\winnt\system32\drivers\etc ディレクトリのホスト ファイルにあるかどうかを確認します。

  • [PG] > [Setup] で設定した [Logical Controller ID] が、[Configure] > [ICM] で設定した [PG Logical Interface Controller] の [ID] と一致するかどうかを確認します。 [PG] > [Setup] でペリフェラル用に設定した [Peripheral ID] が、[Configure] > [ICM] でペリフェラル用に設定した [ID] と一致するかどうかを確認します。

  • 一致するように ICM 設定を変更します。

JGW プロセスがアクティブにならない

誤ったバージョンの Microsoft Java 仮想マシン（JVM）がインストールされている

  • コマンド プロンプトを開き、jview と入力して Enter を押します。 インストールされている Java のバージョン情報が表示されます。

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

  • この出力が表示されない場合、または 3190 よりも前のバージョンの場合、正しいバージョンの Microsoft JVM をインストールします。msjavx86.exe を実行します。このファイルはセットアップ時に icr\bin ディレクトリにインストールされます。

Java クラスパスが正しくない

  • コマンドプロンプトから、icr\binディレクトリに移動し、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 のクラスパスをチェックします。  レジストリ エディタを使用して、SOFTWARE\Microsoft\Java VM キーの下にある Classpath 値を確認します。  キーを次のように設定します。

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

注：ドライブ文字とWindowsシステムディレクトリは異なる場合があり、クラスの後とc:\icr...の前の文字は、セミコロン、ピリオド、およびセミコロンです。

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

  • コマンドプロンプトから、icr\binディレクトリに移動し、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(http://<callmanager name>/main.asp)からPGにファイルをインストールできます。ファイルの場所は [application] タブから確認できます。

JTAPI GW ログで、JTAPI バージョンと互換性がないと記録される

  • Cisco CallManager PG に JTAPI 4.1 サービス パック（SP）4 とホットフィックス 50 未満の組み合わせがインストールされている場合、アップグレードする必要があります。

  • PG をアップグレードするために [ICM] > [Setup] を実行した場合、\icr\bin\icrjavalib.zip というファイルの日時が更新されたかどうかを確認します。ファイルの日時は bldXXXXX.version ファイルの日時とほぼ同じで、差は一日程度です。

注意： ファイルが使用中の場合、Setupを実行しても、このファイルを更新できません。この状況はインターネット ブラウザを開いているときに生じる可能性があります。ブラウザで zip ファイルを開くと、ブラウザは zip ファイルをクラス パスのディレクトリとして扱うからです。この問題を回避するために、Setup の実行前にすべてのブラウザ セッションを閉じてください。  Setup がファイルを更新できない場合はメッセージが表示され、ファイルを更新するために PC を再起動するよう指示されます。その場合は再起動する必要があります。

JTAPIGW が Cisco CallManager に接続できない

  • PIM は JTAPI Gateway（JTAPIGW）と通信し、JTAPIGW は Cisco CallManager と通信します。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] を再度実行し、[Edit Peripheral] ダイアログから名前を変更します。

getProvider() 呼び出しのトレースには使用されたログイン名も表示されます。 トレースにパスワードは示されないことに注意してください。 ログイン名とパスワードは、管理者が [ICM] > [Setup] で入力したものが使用されます。 これらは、ディレクトリで設定された有効なユーザ名とパスワードと一致し、Cisco User Preferences Web ページでそれぞれのエージェント デバイスやルート ポイントの制御権限を付与されている必要があります。 [ICM] > [Setup] で名前とパスワードが正しく設定されていることを確認します。 有効なエージェント デバイスおよびルート ポイントのみに対する制御アクセス許可が与えられるようにディレクトリ内のユーザを設定します。

JGW ログで不明なホストと記録される

JTAPI GW プロセスが Cisco CallManager のアドレスを解決できません。[Setup] の [PIM] ダイアログボックスのサービス パラメータに、Cisco CallManager のホスト名または IP アドレスを設定します。Cisco CallManager のホスト名の設定が正しければ、Cisco CallManager に ping できることを確認します。できない場合は、ホスト名の代わりに Cisco CallManager の IP アドレスを使用します。

JGW ログで無効なパスワードまたはユーザと記録される

JTAPI GW はユーザ名とパスワードでグローバルディレクトリへログインします。[Setup] の [PIM] ダイアログボックスで指定するユーザ名とパスワードは、Cisco CallManager Administration Web ページの [ccmadmin] > [User] > [Global Directory] で設定するユーザ名とパスワードと一致する必要があります。

ユーザが存在しなければ、新しいユーザを追加します。ページ下部の、[CTI Enabled] チェックボックスがオンになっていることを確認します。

グローバルディレクトリのユーザ ページの CTI チェックボックスがオンになっていない

Cisco CallManager グローバルディレクトリ ユーザ ページのチェックボックスを使用して、PIM または IP IVR のユーザの CTI 権限を有効または無効に設定できます。PIM/JTAPI GW をアクティブにするには、このチェックボックスをオンにして更新します。このチェックボックスは、2 つの CTI デバイスが Cisco CallManager に接続して問題を引き起こすことがないようにします（デフォルトの制限は 400 です）。

Cisco CallManager サービスが実行されない

  • Cisco CallManager バージョン 3 では、このサービスは「Cisco CallManager」としてサービス コントロールに表示されます。 サービスを起動します。

  • 通常、Cisco CallManager サービスが異常終了した場合には再起動するように設定されています。しかし、フェールオーバーのシナリオでのデバイスの移行に伴う潜在的な問題に対応するため、これをオフに設定できます。

  • イベント ログを見て、Cisco CallManager サービスが再起動しているかどうか確認します。適切な CPU の使用に関連した問題を検知して、システムが再起動することがあります。その際にシステムは、「slow SDL timer thread」というエラーまたは警告をイベント ログに報告します。 このタイプのエラーが生じると、Cisco CallManager は再起動します。このバージョンの Cisco CallManager は通常の優先順位で動作しているので、同じシステムの他のアプリケーションからコール シグナルによる干渉を受ける可能性があります。

  • 物理メモリが少ない場合やシステムで他のタイミングに関する問題が発生した場合、Cisco CallManager は、10 分間のタイムアウト後に初期化できずに再起動した、というエラーを報告します。Cisco CallManager Database Layer（DBL）の DCOM コンポーネントサービスの中に、初期化で問題が発生したサービスがあります。この問題の解決のため、[component services] - [DCOM components] からこの DBL DCOM サービスを停止し再起動します。

    注：これは、Cisco CallManagerのようなシステムサービスとは異なります。

    Cisco Technical Assistance Center（TAC）でケースを開きます。 根本的なタイミング問題を解決しない限り、次にシステムを再起動するときも問題が生じる可能性があります。

ディレクトリの問題（設定、動作しない、ディレクトリ パスワード）

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

  • ディレクトリ サービスが起動し、正しく動作していることを確認します。  デフォルトでは、Cisco CallManager マシンのサービス コントロールの DC Directory Server です。マシンを起動してみてください。問題が発生する可能性があります。

  • システムがメモリやディスクの領域不足になると、ディレクトリ サービスは一時停止状態になります。エラーは Microsoft Windows 2000 のイベント ログに表示されます。リソースの問題を解決し、ディレクトリ サービスを必要に応じて再起動します。

Cisco CallManager の Web ユーザ ページが機能しない

シスコのグローバルディレクトリのユーザ Web ページで、実際にユーザの表示と設定ができるかどうか、また、コントロール デバイスにアクセス許可を割り当てることができるかどうかを確認します。JTAPIGW と Web ページは、ユーザやアクセス許可へアクセスするために Cisco CallManager を使ってディレクトリ サーバにアクセスします。JTAPIGW の問題がディレクトリ サーバに起因する場合は、ユーザ Web ページでも問題が発生します。考えられる原因は、ディレクトリ サーバが実行されていない、ディレクトリが正しく設定されていない、あるいはまったく設定されていないことです。

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

Cisco CallManager 3.0.5 以降を使用するには、ディレクトリ サーバをインストールする必要があります。AVVID DC Directory は Spirian インストール CD に含まれているデフォルトです。ディレクトリ サーバをインストールした後、Cisco CallManager のインストールによりディレクトリが設定されます。

JTAPIGW が Cisco CallManager にログインして JTAPI を使用するためには、このインストールが正しく実行され、ディレクトリ サーバが起動して適切に動作している必要があります。

DC Directory Service と Cisco CallManager の両方が正しく動作していることを確認します。

Cisco CallManager をインストールする際にディレクトリ マネージャ パスワードのプロンプトが表示されたら、「ciscocisco」と入力します。それ以外を入力した場合、DC Directory Software (Add/Remove) を削除して、再インストールする必要が生じる場合があります。削除中に、削除できないファイルがあるというメッセージが表示された場合、手動で現在の c:\dcdsrvr ディレクトリを削除するか名前を変更します。

ディレクトリ サーバをインストールしたが動作しない

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

ディレクトリ サーバがインストールされ稼働しているが、DCD Admin ツールでログインできない

システムのスタート メニューから DC Directory Admin を開始します。ユーザの Directory Manager にパスワード「ciscocisco」（デフォルト）、または管理者によって設定されたパスワードを指定してログインします。ユーザが設定されていないことを示すエラーが表示されたら、DCDSrvr\bin ディレクトリ内にある Cisco AVVID コンフィギュレーション ファイルのいずれかを実行します。これがプライマリの Cisco CallManager、つまりパブリッシャなら、DOS プロンプトから avvid_cfg.cmd を実行します。セカンダリの Cisco CallManager なら、コマンド プロンプトから avvid_scfg.cmd を実行します。

これはすでに設定されているというエラーが表示される場合は、すでにユーザが存在しています。エラーがなければ、正常に動作し始めるはずです。戻って ccmadmin でグローバルディレクトリのユーザ ページからのアクセスを確認します。

注：ディレクトリにシステムリソースが少なくなると、DC Directoryは一時停止モードになります。

エージェントがログインできない

この例では、デバイス ターゲットのサンプル ICM 設定を使用します。

サンプル デバイス ターゲット  
Enterprise Name Agent9782755100
Global Address Agent9782755100
ConfigParm /devtype CiscoPhone /dn 9782755100

次の例はエージェントのサンプル ICM 設定です。

サンプル エージェント  
周辺装置 CCMPG_PIM1
Peripheral Number 1234
Password XXX

PG の [ICM] > [Setup] を実行する際、エージェント内線番号の長さに「4」を指定します。 したがってこの設定例では、サンプル デバイスの内線番号は /dn パラメータの最後の ４ 桁（この例では 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 の「status」コマンドを使用して、IPCC PIM および CTI サーバが PIM_ACTIVE 状態と CTI_ACTIVE 状態として示されることを確認します。PIM および CTI のサーバ ログ ウィンドウのタイトル バーでもプロセスの状態がわかります。

CTI クライアントから接続できない

CTI サーバに接続するための設定を確認します。デスクトップ ソフト フォンの設定は .ini ファイル（通常 c:\program files\geotel\cti desktop\cticonfig.ini）にあります。 確認する設定は次のとおりです。

  • PeripheralID：この値は、[Configure] > [ICM] で設定する IPCC ペリフェラルのペリフェラル ID と一致する必要があります。

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

  • SideBHost：この値は、CTIサーバのサイドBのホスト名またはIPアドレスである必要があります。CTIサーバがシンプレックスの場合、このフィールドは空白にしておきます。

  • SideAPort：この値は、CTI サーバのサイド A で接続をリッスンするポートと一致する必要があります。これは、CTI サーバの ICM Setup で指定した値です。CTI サーバはタイトル バーにこのポートを表示し、CTI サーバの起動時にこの値をログに記録します。クライアントが CTI サーバに ping を実行できるかどうかを確認します。

エージェントが ACD にログインする必要があるというエラーを、CTI クライアントが受け取る

PG/CTIサーバの\icr\binディレクトリにあるsetup.exeを実行します。CTI ゲートウェイのコンポーネントを選択します。Agent Login Requiredチェックボックスにチェックマークが付いていないことを確認する。このチェックボックスの選択は、IPCC またはサードパーティのコントロール アプリケーションでは有効ではありません。このチェックボックスの目的は、他の ACD エージェントのアプリケーションをモニタすることです。

PIM ログに以下のいずれかのログインエラーが記録される

PIM に procmon を使用して、「trace tp*」（大文字/小文字の区別あり）を実行しサードパーティのトレースを有効にします。 これでログイン要求が表示されます。パラメータが正しいことを確認します。インストルメントは「Device=」としてトレースされます。 この値は、/dn 文字列（デバイス ターゲットの configparam）と一致する必要があります。エージェント ID は「AgentID=」としてトレースされます。 この値は Configure/ICM のエージェント ペリフェラル番号と一致する必要があります。

  • INVALID_PASSWORD

    パスワードが正しいことを確認します（パスワードは、クリア テキストとしてトレースできません）。 パスワードが正しくない場合、ログは INVALID_PASSWORD_SPECIFIED エラーを示します。

  • INVALID_OBJECT

    デバイス ターゲットの設定パラメータに無効なデバイス タイプが含まれることを示します。このエラーは、ここで示すようにキーワード間にスペースを入れて表示されます。

    /devtype CiscoPhone /dn 9782755100

  • INVALID_DEVICE_TARGET

    デバイス ターゲット内の何かが無効であることを示し、おそらく設定パラメータ フィールドのどれかに問題があります。dumplog ユーティリティで PIM が最後に再起動したときの PIM ログを参照してください。ログにより、デバイス ターゲット設定文字列が無効なときの、デバイス ターゲットとログ エラーを検証します。

JGW ログにログイン エラーが示される

ログイン試行に関係するエラーがないか JGW ログをチェックします。PIM に procmon を使用して、「trace *TP*」（大文字/小文字の区別あり）を実行しサードパーティのトレースを有効にします。 行「MsgAddCallObserver: Addr: XXXX」を探します。ここで、XXXXはログインしようとしている内線番号です。この内線番号は、PG ユーザが制御アクセス許可を与えられたデバイスの、有効な Cisco CallManager の内線番号である必要があります。この内線番号は Cisco CallManager が認識している電話機の正しい番号である必要があります。言い換えると、この内線番号は、該当する電話機に到達するために同じ Cisco CallManager の別の電話からダイヤルする番号です。

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

JGW ログに、プロバイダーのドメインにデバイスがないという例外が示された場合、電話機は JTAPI GW のログイン ユーザに関連付けられていません。相手方のグローバルディレクトリのユーザ デバイス関連リストで、内線番号が正しいことを確認します。また、デバイスの回線番号が 2 度登録されていないことを確認します。共有ライン アピアランスは、IPCC がサポートしていない Cisco CallManager の機能です。同じ回線を持つ 2 つの電話機で、意図せずに共有ライン アピアランスを設定してしまう可能性があります。1 つの回線番号を変更すると他方も変更され、PG は適切なデバイスにログインできません。この問題を解決するには、両方の回線を削除し、それを Cisco CallManager に追加します。

INVALID_SKILL_GROUP_SPECIFIED

ログインするためには、エージェントを 1 つ以上のスキル グループのメンバー（スキル グループ メンバー）として Configure/ICM で設定する必要があります。

エージェントがすでに別の電話機にログインしている

エージェント（エージェント ペリフェラル番号で識別）が、別のデバイス ターゲットにすでにログインしていないかどうかを確認します。これを確認する 1 つの方法は、Monitor ICR を開始し、該当するエージェントについて Free from Agent レポートを実行することです。エージェントがログイン中であれば、エージェントがログインしているデバイス ターゲットのネットワーク ターゲット ID が表示されます。エージェント データが awdb に表示されるのは、この AW にペリフェラルのエージェント データを送信するように ICM を設定したときだけです。

  • また、isqlw で awdb の Agent_Real_Time テーブルに対してこれをクエリすることもできます。最初に、エージェントのスキル ターゲットを検索します（たとえば、select * from Agent where PeripheralID = XXX and PeripheralNumber = YYY）。 次にエージェントがログインしているかどうかを確認します（たとえば、select * from Agent_Real_Time where SkillTargetID = XXX）。

  • また、PIM に procmon で接続し、dagent <agent peripheral number> を実行して確認することもできます。

デバイス ターゲットにログイン済み

デバイス ターゲットに（インストルメント指定）にすでにログインしている別のエージェントがないことを確認します。

  • これを確認する一つの方法は、awdb の Agent_Real_Time テーブルに対して isqlw を実行することです。まず、該当するデバイス ターゲットのネットワーク ターゲット ID を検索します。たとえば、select * from Device_Target where ConfigParam like ‘%1003%’。次に、デバイス ターゲットがログインしているかどうかを確認します。たとえば、select * from Agent_Real_Time where NetworkTargetID = XXX。

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

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

Cisco CallManager の Web ページで、[User]/[Global Directory] を選択し、PG が使用しているユーザ ID を検索します。 [Associated Devices] をチェックして、そのユーザにデバイス制御アクセス許可が与えられていることを確認してください。

  • ユーザ ページでデバイスが（オンでもオフでも）見つからない場合、Cisco CallManager がデバイス情報を保存しているデータベースと、ディレクトリ サーバで保存しているデバイスとユーザ プロファイルの間で同期の問題が生じているかもしれません。 ディレクトリ サーバ（DC Directory Server）が動作しているかどうかを確認します。

  • Windows NT イベント ビューアのアプリケーション ログをチェックし、DC Directory またはメタリンクでエラーが生じていないか探します。インポート エラーが生じていたら、c:\dcdsrvr\bin から avvid_recfg を実行します。

  • Cisco CallManager マシンに Microsoft Java 仮想マシン（JVM）がインストールされていることを確認します。これをテストするには、コマンド プロンプトから jview と入力します。Cisco CallManager 2.4 の場合は、JVM を手動でインストールする必要があります。Cisco CallManager 3 の場合はプラットフォームが Windows 2000 で、JVM のインストールは自動です。

電話デバイスがアクティブではない

電話機の電源が入っていること、Cisco CallManager に登録されていること、エージェント制御なしで電話機からコールの受発信ができることを確認します。

エージェントが発信できない

エージェントが [Not Ready] 状態

エージェントがログインしており、[Available] 状態でないことを確認します。  エージェントが [Available] 状態でなければ、コールを発信できません。コールを発信するには、まず [Not Ready] をクリックします。

誤ったエージェント デスク設定

特定の番号をダイヤルしたときにのみエラーが生じるなら、物理的な電話機からその番号に正常にダイヤルできることを確認します。ICM ダイヤル番号計画を設定しているなら、かけている番号がダイヤル番号計画のワイルドカードのどれかと一致するかどうかを確認します。そのエージェントのエージェント デスク設定が、ダイヤル番号計画のエントリで指定しているタイプの番号（たとえば、国際電話）にダイヤルする許可を持っているかどうかを確認します。

PIM のダイヤル番号計画でアクセスをブロックしている

各 PIM 用に設定されたダイヤル番号計画によって、あるエージェントが特定の番号に通話できないように、意図的にまたは意図せずに設定されています。PIM ログは権限エラーを示しているはずです。ダイヤル番号計画がエージェント間通話で利用されている場合、エージェント番号とデバイス番号は重複できません。

短いコールの後、エージェントは次のコールまで待機が求められる

エージェントがコールを発信する、またはコールがエージェントにルーティングされると、ルータはエージェントを使用不可にします。このメカニズムにより、コールが着信したことを PIM が知らせる前に、ルータは別のコールをエージェントにルーティングできます。ネットワークによっては、実際にコールをルーティングするために数秒かかります。ルータはエージェントの状態に基づいてタイマーをキャンセルすることはしません。

それで、ルーティング クライアントから PIM へのルーティングにかかる時間が比較的短ければ、ルータの設定期間を変更することができます。ルータのうちの 1 台の DOS コマンド ウィンドウで、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 コールとみなされ、コンテキスト変数、サービス、またはスキル グループの情報はいずれもコールに割り当てられません。

エージェントが移動できない – 受信不可、ビジー、またはその他

エージェントが [Active] 状態

エージェントが通話中に、[Not Ready]、[Busy]、[Other] などをクリックしてもエージェントの状態はすぐには変化しません。これは意図的な動作です。コールが完了するまで、エージェントは [Talk] または [Held] 状態のままです。押されたボタンに応じて、エージェントの状態は [Not Ready]、[Work Ready]、または [Work Not Ready] に遷移します。コール終了後にすぐに [Available] に遷移するなら、そのエージェントのエージェント デスク設定が [Available After Incoming] または [Available After Outgoing] になっていないかどうか確認してください。これらの設定は、エージェントが通話中にボタンで実行するタスクを上書きします。

エージェント デスク設定が遷移を阻害している

Configure ICM からそのエージェントのエージェント デスク設定をチェックし、[Idle Reason Required] がオンになっているかどうかを確認します。チェックボックスをオンにしている場合、エージェントは理由コードなしでは [Not Ready] 状態に移行できません。Desktop_Settings.cfg の内容を Configure ICM のエージェント デスク設定に合わせて変更するか、逆に Configure ICM のエージェント デスク設定を変更します。

エージェント デスク設定が割り当てられていないエージェントは、ログインして [Ready] に移行できますが、[Not Ready] には移行できずログアウトもできません。これを解決するには、エージェント アプリケーションを閉じて、エージェント デスク設定を割り当て、再度ログインします。

エージェントが [Not Ready] に移行するのに待機が求められる

エージェントがコールを発信する、またはコールがエージェントにルーティングされると、ルータはエージェントを使用不可にします。この機能により、コールが着信したことを PIM が知らせる前に、ルータが別のコールをエージェントにルーティングできます。ネットワークによっては、実際にコールをルーティングするために数秒かかります。ルータはエージェントの状態に基づいてタイマーをキャンセルすることはしません。

それで、ルーティング クライアントから PIM へのルーティングにかかる時間が比較的短ければ、ルータの設定期間を変更することができます。ルータのうちの 1 台の DOS コマンド ウィンドウで、rtsetting.exe を使用します。[Extrapolation] > [Agent] を確認します。デフォルトは 10 秒です。値が短すぎる場合、ルータはコールを受信しようとしているエージェントにコールをルーティングします。これにより、PIM がコールをドロップします。

エージェントが [Ready] 状態に移行できない

PRIVILEGE_VIOLATION_ON_SPECIFIED_DEVICE

ログイン要求と準備要求のデータに不整合があります。おそらく、インストルメント、エージェント ID、ペリフェラル番号が一致していません。CTIサーバトレースをprocmonで有効にし、regsetで0xf8を指定して適切なトレースを設定します。サードパーティ（TP）のトレースがオンの場合は、OPC ログまたは PIM ログでも確認できます。

エージェントがログアウトできない

エージェントの現在の状態がコールを妨げている

エージェントが [Work Ready]、[Work Not Ready]、[Available] 状態であれば、ログアウト前にまず [Not Ready] 状態に移行する必要があります。Desktop_Settings.cfg の内容を Configure ICM のエージェント デスク設定に合わせて変更するか、逆に Configure ICM のエージェント デスク設定を変更します。

エージェント デスク設定が状態の移行を妨げている

エージェントが [Not Ready] 状態にもかかわらずログアウトできないなら、Configure ICM からそのエージェントのエージェント デスク設定をチェックし、[Logout Reason Required] がオンになっているかどうかを確認します。

エージェントが [Active Call] または [Agent Talking] を表示するが、実際には通話がない

エージェントのログアウトと再ログイン

物理的にすでに存在していない通話をソフト フォンが表示する場合、[Talking] または [Hold] 状態から抜け出せなくなることがあり、エージェントがログアウトできません。これは、JTAPI または PIM のソフトウェア バグが原因である可能性があります。この状態を解消するために、ソフト フォンのリリース ボタンが有効になっているなら、まずコールをクリアしてください。これができなければ、エージェントのログアウトを試してみてください。ログアウト ボタンが動作しないなら、ソフト フォンを終了し、再起動します。この状態が続く場合は、ソフトフォンを終了し、タスクマネージャを実行します。次に、geodcs.exeおよびcommon～1.exeに強制終了を実行し、ソフトフォンを再起動します。これらのプロセスはエージェントの誤った状態を記憶したまま実行を続けていることがあります。

PIM におけるエージェントの誤った状態

procmon を使って、PIM 内でのエージェントの状態を確認します。エージェント デスクトップを再起動しても問題が継続する場合、他にも方法があります。CTI サーバと OPC には、コールをクリアするメカニズムとして procmon や opctest のデバッグ インターフェイスがあります。これは PG サービスの再起動や、少なくとも PIM ウィンドウの終了を必要とする他のオプションに比べて、いくらか推奨されるオプションです。

コールがアラート直後または接続確立直後にクリアされる

レジストリ設定の誤り

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 Call Tracer ツールを使用して、コールがスクリプトに到達し、スクリプトが実行されているかどうかを確認できます。スクリプト エディタを実行し、スクリプトをモニタします。ルータ ログ、OPC ログ、PIM ログを参照して、問題がないかどうかを確認します。ほとんどのルーティング エラーは無条件でトレースされます。

ペリフェラルのルーティング クライアントで、[Use DN Label Map] がオンになっている

Configure ICM 内の各ルーティング クライアントの設定に、[Use DN/Label Map] という項目があります。 この設定が [Yes] の場合、[Dialed Number Label] というエントリに、各着信番号と考えられる宛先ラベルとの組み合わせを設定する必要があります。この設定は PG のルーティング クライアントでは通常使用しないので、[No] に設定します。

ルーテッド デバイス ターゲットに設定されたラベルがない

ルーティング クライアントで設定されたラベルを確認します。各クライアントに同一ラベルが割り当てられているとしても、クライアントごとにラベルを設定します。

CTI ルート ポイントが Cisco CallManager で設定されていない

ポスト ルーティングを利用するためには、Cisco CallManager で「CTI ルート ポイント」を設定し、そのルート ポイントに目的の電話番号（たとえば 5000）を付けて回線を割り当てる必要があります。 エージェント コールでポスト ルーティングを行うには、ダイヤル番号計画を使用します。エージェントが Cisco CallManager CTI ルート ポイントにダイヤルすると、CTI Desktop バージョン 4.1.9 の IPCC ソフト フォンで問題が生じます。

PG ユーザが制御するデバイスのリストに、CTI ルート ポイントのデバイスがない

Cisco CallManager ユーザ Web ページのグローバルディレクトリで、PG ユーザの [Associated Devices] リストに、CTI ルート ポイント デバイスを追加します。新しいデバイスを作成したら、まず回線を追加し、次にそのデバイスをユーザの [Associated Devices] リストに追加します。ユーザのデバイス リストの既存のデバイスに回線を追加した場合、JGW に新しい回線を認識させるため JGW を再起動する必要があります。一方、新しいデバイスを追加し、そのデバイスに回線を追加し、それからユーザのデバイス リストにデバイスを追加すると、JGW は新しいデバイスを（約 30 秒以内に）認識するはずです。

Cisco ICM で設定されたダイヤル番号がない

ダイヤル番号がペリフェラル ルーティング クライアント用に設定されていることを確認します。JGW に procmon を実行し、trace *ROUTE*（大文字/小文字の区別あり）としてトレースを有効にします。 ダイヤル番号に関連するエラーがないか JGW ログをチェックします。JGW はスタートアップ時に、ダイヤル番号のルーティング コールバックの登録を試みます。コールがダイヤル番号に発信されると、ゲートウェイは「RouteEvent」を受信します。

ダイヤル番号とともに、コール タイプが作成され、スクリプトに正しくマッピングされているかどうかを確認します。

JGW の再起動が必要でないことを確認する

ICM ダイヤル番号を設定し、CTI ルート ポイントを設定し、それをユーザのデバイス リストに追加しても、番号のダイヤル時にルート要求を受け取らない場合、JGW の再起動（または PG の再起動）が必要になる場合があります。 再起動が必要になるのは、JGW で（trace *ROUTE*）のトレースを有効にし、アドレスがプロバイダーにないことを示すエラーが表示された場合のみです。通常 JGW は、ユーザのデバイス リストに追加された新規の CTI ルート ポイントを再起動せず認識できるはずです。一方、既存の CTI ルート ポイントに回線が追加されると、JGW は再起動なしではそれらを認識しません。既存のデバイスに新しい回線を追加する代わりに、各ダイヤル番号に新規の CTI ルート ポイントを追加するなら再起動を回避できます。

注：ここでは、PIMのwinnt\java\libディレクトリにあるJTAPI.iniファイルでDeviceListPollingがオンになっていることを前提としています。DeviceListPolling がオフの場合は DeviceListPolling をオンにする必要があります。DeviceListPolling がオフのままでユーザ リストにデバイスを追加した場合は、新しいデバイスを表示するために、PG を再起動するか、少なくとも PG のための JTAPI GW を再起動する必要があります。

OPC ログでルーティング ダイアログを確認する

opctest を使用してルート トレース「debug /routing」をオンにして、ルート ポイントへの通話でエラーがないか OPC ログを確認します。ルート要求が受信され、ラベルが返ることを確認します。ルート要求は「CSTA_ROUTE_REQUEST」および「ICR_NEW_CALL_REQ」メッセージとして表示されます。返されたラベルは「ICR_CONNECT」メッセージとして表示されます。エラーが発生すると、「ICR_CONNECT」メッセージの代わりに「ICR_DIALOG_FAIL」メッセージ表示されます。このとき、エラーがないかルータ ログをチェックしてください。

ルータ ログでルーティング ダイアログを確認する

rtsetting.exe を使用してルート トレースを有効にし、ルート ポイントへのコールでエラーがないかルータ ログを確認します。

すべての必要なラベルが設定されていることを確認します。ルーティング スクリプトが IPCC/EA エージェントをターゲットにしているなら、それぞれの対象デバイス ターゲット用に設定されたポスト ルーティング クライアント ラベルが必要です。

エージェントが利用可能になってもルーティング スクリプトがコールをデキューしない

ルータ ログにエラーがないかどうかを確認します。エラーがない場合は次を確認します。

ルータログにエラーがない – キューノードがスキルグループベースのプライオリティにキューイングされる

キュー ノードがベースの優先度でキューされていると、エージェントが対応可能になっても何も起こりません。この問題には対応策が 2 つあります。

  • AutoLoginBase というルータのレジストリ設定があります（rtsetting.exe を使用します）。 この設定を変更して、ほぼ期待どおりにベース スキル グループにコールがキューされるようにします。このタイプのキューイングが行われると、プライマリ スキルはセカンダリ スキルに優先されません。

  • キュー ノードでプライマリとセカンダリの一方または両方のスキル セットに明示的にキューされるようにします。

ルータ ログに、ターゲットにラベルが設定されていないことが示される

該当するデバイス ターゲットを含め、ルーティング クライアントがルーティングできる他のすべてのターゲットにラベルを設定します。ICR の設定ではなく、AW のバルク設定ツールを使うとより効率的に設定できます。

すべてのエージェントおよびキューイング ポートがビジー状態のときに Ring No Answer が聞こえる

ルータ ログの確認

  • ルーティング エラーは無条件でトレースされるはずです。

  • ルート パスをテストするためにコール トレーサー ツールを使用できます。

  • rtrtrace を使用してルート要求トレースを有効にし、ルート ポイントにコールが行われたときにエラーがないかルータ ログを確認します。

  • すべての必要なラベルが設定されていることを確認します。ルーティング スクリプトが IPCC/EA エージェントをターゲットにしているなら、それぞれの対象デバイス ターゲット用に設定されたラベルが必要です。各デバイス ターゲットでは、コールを送信しようとする各ルーティング クライアント用にラベルを設定する必要があります。そのため、応答可能なエージェントにネットワークからコールが直接事前ルーティングされると、ネットワーク ルーティング クライアントでは関連付けられたデバイス ターゲットのラベルが必要になります。コールが VRU で最初にキューされ次にエージェントに配信される場合、VRU のルーティング クライアントは関連付けられたデバイス ターゲットのラベルを持っていなければなりません。

Configure ICM の [Routing Client] で DN ラベルのマッピング設定がオフになっていることを確認する

Configuration Manager/PG Explorer の [Routing Client] タブで [Use DN/Label map] の設定がオフになっていることを確認します。

PIM ログをチェックする

  • PIM のトレースを有効にするため、trace precall, trace *call_event* として procmon を実行し、ログを確認します。プレコール メッセージがルータから表示されます。また、そのエージェントの内線番号に「DevTgDevStr」が設定された「DeliveredEvent」も確認できます。コールが表示されない場合は、ルーティング クライアントのラベルが正しいことを確認します。

任意の転送が矛盾した結果をもたらす

Cisco CallManager が矛盾した結果をもたらすため、IPCC はコールを保留にして新しいコールを発信するオプションをサポートしていません。これは製品の機能強化として今後のリリースで検討される可能性があります。

代替が機能しない

コンサルト コールが切り替え、代替、保留、あるいは取得されると、Cisco CallManager はコンサルティングの関連付けを切断します。これにより、サポートされていない任意の転送シナリオが発生します。エージェントは顧客に再接続し、新たなコンサルティングを開始できます。IPCC ソフト フォンでは問題が解決するまで代替ボタンを無効にしますが、サードパーティのベンダで苦情があるかもしれません。

電話会議への参加を許可されたパーティが、ほかのパーティを電話会議に呼べない

Cisco CallManager には制限があり、会議に参加者を追加できるのは会議の開催者だけです。Cisco CallManager では参加者が他の参加者を追加できません。

エージェント ステーションが突然ログアウトする

エージェント デスク設定の非アクティビティ タイマー

エージェント デスク設定には、[Not Ready] 状態にあるエージェントをログアウトする時間設定があります。最大非アクティブ時間は 2 時間ですが、短い時間も設定できます。[Available] 状態のエージェントが非アクティブ状態でログアウトさせることはありません。Ring No Answer タイマー（あるいはエージェント デスク設定）が満了すると、エージェントは [Ready] 状態から [Not Ready] 状態に遷移します。

CTI サーバのハートビートのタイムアウト

CTI サーバには設定されたハートビート タイムアウトがあります。古いコンピュータ、過負荷の CTI サーバ、帯域幅に問題のあるネットワークなどが根本原因の可能性があります。CTI サーバ ログにエラーが記録されているはずです。

エージェントがエージェント デスク設定のとおりに動作しない

Configure ICR（M）によるエージェント デスク設定と、エージェントの設定ファイルは、一致している必要があります。

ICM ペリフェラル設定のパラメータにワーク タイマーがあります。そのパラメータを \WORKTIMER 30 として、auto-available から 30 秒の遅延に設定します。

デスクトップ コンフィギュレーション ファイルは次の場所にあります。

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

Desk_Settings.cfg と ICR（M）エージェント デスク設定で、Incoming の work mode は Required with Data ではなく Required と設定する必要があります。Required with Data は auto-available オプションを上書きします。

打診転送が失敗する

JTAPI GW ログを見て、打診転送が失敗する理由を示すエラーがあるかどうかを確認します。エージェント ソフトウェアでコンサルト コールの保留、取得、代替の操作が可能かどうかを確認します。コールが保留または取得されると、そのコールはコンサルト コールとはみなされず、Cisco CallManager による「任意」の転送とみなされます。Cisco CallManager には任意の転送の問題があります。コンサルタティブ コールを再接続するユーザを制限するか、転送を完了します。

コンサルト ユーザが電話を切っても、コール アピアランスがオフにならない

電話会議で開始されたコンサルタティブ コールで、電話会議が完了しない状態での切断イベントに関して Cisco CallManager には現在問題があります。エージェントの電話のコール アピアランスをクリアするために、もう一度コールを切断してください。

VRU へのトランスレーション ルートが機能しない

まず、アクティブ スクリプトをモニタします。次に、ルーティング クライアントのルータ ログ、OPC ログ、PIM ログ、そして VRU をチェックします。ほとんどのエラーは無条件でトレースされますが、何が起きたかを知るためにトレースのレベルを上げることができます。

トランスレーション ルートのシーケンスは次のとおりです。

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

  • ルータはルーティング クライアントに、コールを IVR に配信するというラベルを付けて接続を返します。

  • IVR は、VRU PG がペリフェラル ターゲットを検索するために使用する RequestInstruction を送信する必要があります。

  • ルータは、リクエスト インストラクションのペリフェラル ターゲットと、自分が求めているトランスレーション ルートのペリフェラル ターゲットを比較します。

  • ルーティング スクリプトは、顧客が設計した実行スクリプトまたはキュー ノードを続行します。

アクティブ スクリプトをモニタして障害のパスを見つけます。ルータ トレースにエラーがないかどうかを確認します。ルーティング クライアントが最初のラベルを受信しているかどうかを確認します。VRU がコールを受信したかどうかを確認します。VRU が VRU PIM または OPC レベルでリクエスト インストラクションを送信するかどうかを確認します。

ルート要求がルーティング スクリプトの「Translation Route to VRU」ノードに到達しない

スクリプトをモニタし、リクエストが Translation Route to VRU ノードに到達しているかどうかを確認します。

最初に、サービス制御 VRU にルーティングを変換するには、ルーティング スクリプトで、トランスレーション ルートが選択された選択ノードまたはルート選択ノードがあるだけでは不十分です。Translation Route to VRU ノードが必要です。

次に、コールがトランスレーション ルート ノードに到達したことをモニタは表示している必要があります。ここで問題があるなら、トランスレーション ルートを決めることができなかったか、IVR が RequestInstruction ルート要求メッセージを受信していないことを意味します。

ルータ ログにトランスレーション ルートのタイムアウトが記録される

トランスレーション ルートのタイムアウト エラーは、ルータがリクエスト インストラクションを受信していないことを示しています。OPC および VRU PIM でのエラーを確かめ、RequestInstruction が到達しているかどうかを確認します。

ルータで何が起きているかをより詳しく知るために、ルータの rtrtrace ツールで「translation routing」と「network VRU tracing」を有効にします。VRU PG OPC では opctest を使って、サービス制御レポートを有効にします。

VRU PIM ログがトランク グループ X に DNIS が見つからないことを示す

Request Instruction は、VRU PG 用に設定されたトランク グループの中の 1 つのトランク グループ ペリフェラル番号にマッピングされる有効なトランク グループを示す必要があります。トランク グループ ペリフェラル番号が修正されたら、更新を受信するように VRU PG を再起動する必要があります。

ICM 設定のチェック

DN ラベルのマッピング設定が、IVR PG ルーティング クライアントでオフになっていることを確認する。IVR PG はネットワーク VRU 割り当てが必要です。ネットワーク VRU タイプは 2 である必要があります。IVR PG はネットワーク トランク グループと、指定されたトランク グループが必要です。トランク グループ内のネットワーク トランク グループを参照してください。

NIC/ポスト ルーティング PG はペリフェラル ターゲットの DNIS ごとにラベルを付ける必要があります（ラベルは、トランスレーション ルート ウィザードのルーティング クライアント リクエストの DNIS と同じにします。これはプレフィックスで設定できます。prefix = DNIS オプションを選択してください）。

VRU ルーティング クライアントは、エージェントが対応可能になったらルーティングを行うデバイス ターゲット用に設定されたラベルが必要です。

Cisco IP IVR - ICM インターフェイスのトラブルシューティング

この Cisco IP IVR セクションでは、IP IVR と ICM 間の設定エラーをトラブルシューティングする方法、および IVR PG のポスト ルーティングとトランスレーション ルーティングのセットアップの一般的な問題を記載しています。IVR の一般的なエラーの詳細については『Cisco IP IVR トラブルシューティングガイド』を参照してください。

一般に、[appadmin] > [Engine] > [Trace files] Web ページで MIVR ログをチェックします。

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

  • IVR CTI ポートおよび CTI ルート ポイントと、Cisco CallManager グローバルディレクトリの IVR ユーザとが関連付けられている。

  • IVR ICM 設定の [Service Control] チェックボックスがオンになっている。

  • IVR スクリプト定義中のスクリプト名が ICM のネットワーク VRU スクリプト名と一致する。

  • VRU PG のトランク グループ番号が IP IVR の CTI ポート グループ番号と一致する。

トランスレーション ルートの失敗

トラブルシューティングに使用する他のすべての動作に加えて、これらを IP IVR のトラブルシューティングに役立てることができます。

  • MIVR ログのチェック。このログは多くの場合、問題領域を指します。

  • Cisco IP IVR のデバッグ設定を有効にするのは SS_TEL と LIB_ICM です。

  • IP IVR で jtprefs を使い、IP IVR の Cisco JTAPI ログを有効化します。デバッグ ツールを参照してください。トレースを開始したら、IP IVR エンジンを停止して再起動します。

  • IP IVR JTAPI のトランスレーション ルート ポート グループの CTI ポート グループ番号が、ICM トランク グループ設定のペリフェラル番号と一致するかどうかを確認します。

スクリプトがエラーメッセージを再生しない、または再生する

エンジン トレース ファイルの IP IVR ログで次のことを確認してください。

  • 実行スクリプトが受信済み。

  • IP IVR はスクリプトを参照できる。Repository Admin Tool でスクリプトをアップロードする。

  • IP IVR は音声ガイダンスを見つけることができる。ユーザ定義音声ガイダンスは IP IVR の \wfavvid\prompts\user\en_us\ に存在します。

JTAPI ステータスが PARTIAL_SERVICE 状態

これは一般に、IP IVR に設定された CTI ポートまたは CTI ルート ポイントの一部が、Cisco CallManager で設定されていないか、IP IVR のユーザと関連付けられていないことを意味します。

また、スクリプトが Repository Manager にアップロードされていないか、ファイルが正しく指定されていないことを意味します。

IP IVR の ICM ステータスが部分的なステータスを示す

通常この状態は、どちらかの側の部分的な未設定や不適切な設定を示します。

コールがルータからデキューされるとき音声ガイダンスが断続して聞こえる

これはルーティング スクリプトの誤設定で、Configure ICR で設定するネットワーク VRU スクリプトに短すぎるタイムアウト時間が設定されていることによります。

IP IVR で ICM インターフェイスに使用するスクリプトの一部は実行に長時間かかりますが、ICM ネットワーク スクリプト設定のデフォルト タイムアウトは 3 分間です。スクリプトの実行でタイムアウトが生じ、実行スクリプトの障害パスが別の実行スクリプトを再生すると、基本的にこれらの実行スクリプトは IVR にキューイングされます。スクリプトがデキューされると、多くのスクリプトが同時に再生されるのが聞こえます。

IVR サービス統計情報のトラブルシューティング

IVR の統計情報は、IPCC のサービス レベル レポートにとって重要です。したがって、トラブルシューティング方法に関する情報のいくらかはここに含まれています。概要として、VRU で実行されたコールは接続ではなくキューイングと数えるのが、ルータと VRU PG の違いです。コールがルーティングされると、応答として報告されます。キューにある顧客が電話を切ると、放棄されたと報告されます。詳細については、ホット フィックス 53 と 54 の readme.txt を参照してください。ルータは、コールがルータ内でどのような状態であるかを、特別なキューのイベントで送信します。

VRU PIM には特別なレジストリ設定があるので、中断を最小限にするためにこの機能を手動で有効にしてください。

VRU サービスおよび Cisco CallManager PG サービスをどれかのエンタープライズ ペリフェラル レポートに追加する際、Enterprise Service Real Time Report 10 はこのデータを特別な仕方で参照します。Enterprise Service Real Time Report では、VRU PG と Cisco CallManager PG がレポート用に 1 つのエンタープライズ サービスとしてグループ化されている必要があります。

他の役に立つキュー レポートは、新しいリアルタイムおよび履歴レコードのコール タイプ レポート、スキル グループとキューイングされたコールの対応を示すスキル グループ リアルタイム グリッドです。

サービス統計情報または終了コール詳細レコードが作成されない

VRU PIM は CSTA イベントを生成しません。VRU PG の設定から Service Control Reporting を有効にします。これは次のキーの下の 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行で表示されています。

コールが間違ったサービスに対してカウントされる、またはコールがサービス レポートに記録されない

サービス マッピングが見つからないことを OPC ログが示す

コールが間違ったサービスに対してカウントされた場合や、コールがサービス レポートに現れない場合、OPC ログにサービス マッピングが見つからないことが示されます。

Cisco ICM レポートに関する問題

Cisco ICM はコール タイプ、サービス、スキル グループの各テーブルのデータの簡単な関連付けができるようには設計されていません。番号にはグループごとに若干異なる意味があります。複数のエージェントが関係する場合、1 つのコールに対して 1 つのサービスと 2 つのスキル グループが関係することがあります。無応答時リダイレクト（RONA）機能によるリダイレクトにより、終了レコードが生成されずに別のポスト ルートが生成されるでしょう。

エージェント スキル グループ、スキル グループ、サービス、コール タイプ数が合わない

  • 症状：処理コール数またはその他の統計フィールドが、サービス、コールタイプ、スキルグループレポートの間で一致しません。

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

  • トラブルシューティング：コール量が1秒あたり1コール未満の場合は、CSTA、PIM、AGENT、およびサードパーティのイベントに応じて、OPC、PIM、およびJTAPI GWでトレース設定をオンにします。詳細については、このドキュメントのツールの項を参照してください。

  • 次の点でコール フローのドキュメント化を行います。

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

    • 無応答時転送（FONA）が設定されているなら、FONA は何にリダイレクトするように設定されていますか。

    • デフォルトのスキル グループはペリフェラル番号 0 に設定され、ルーティングされたコールを非ルーティング コールとアウトバウンド コールから区別するように設定されていますか。

「select *」を使用して、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 のトレースを取得する際、Cisco CallManager Administration ページで [Services] > [Trace Flag] でフラグを有効にできます。0xCB05 は CTI エラーのトレースのために SDL に設定する適切なトレース フラグです。デバッグのためサービス パラメータに 0xCB05 を設定します。詳細については、『AVVID TACケース：トラブルシューティング情報の収集』を参照してください。トラブルシューティング ガイドを含む Cisco CallManager のオンライン ドキュメントを参照してください。

Cisco CallManager のトレースをオンにする

Cisco CallManager のトレースをオンにする方法の詳細については、『シスコ テクニカル サポートに提出する Cisco CallManager トレースの設定方法』を参照してください。

Cisco CallManager の IP アドレスを変更する

「Cisco CallManager の IP アドレスの変更」を参照してサーバ名を変更します。

  1. Cisco CallManager PG のセットアップを実行して、Cisco CallManager PIM 用の JTAPI サービスを変更します。エクステンション モビリティか電話サービスがある場合。

  2. CRA エンジンを停止します。

  3. CRA の [Engine Configuration] で IP アドレスを変更します。

  4. [JTAPI] で IP を変更します。

  5. サーバの DC Directory Service を停止します。

  6. ディレクトリ設定の IP アドレスを変更します。

  7. Cisco CallManager の [System] > [Server] で IP アドレスを変更します。

  8. [System] > [Enterprise Parameters] にある URL の IP アドレスを変更します。

  9. [Features] > [Phone Services] にある URL の IP アドレスを変更します。

  10. [Network Properties] にある [Server IP Address] を変更します。

  11. [DHCP Option 150] を新しい IP アドレスに変更します。

  12. [Cisco CallManager] > [System Profile] > [Hoteling] から DC Directory 内のホテル プロファイルの IP を変更します。

  13. SQL Enterprise Manager を開きます。

  14. プラグイン テーブル内の URL の IP アドレスを変更します。

設定変更をバックアップするために以下を行います。

  1. stiBackup の設定を開きます。

  2. 該当するすべてのタブで、サーバの IP アドレスを変更します。

デバッグツール

Procmon

procmon は PIM および JTAPI GW プロセスをデバッグするのに役立つコマンド ライン ツールです。

  • 使用法： procmon <customer name> <node> process.

    • Procmon ipcc pg1a pim1

    • Procmon ipcc pg1a jgw1

    • Procmon ipcc cg1a ctisvr

プロセスごとに便利なトレース設定を次に示します。

  • JTAPI GW（procmon を使用）

    • trace JT_TPREQUESTS（サードパーティの要求をトレースします）

    • trace JT_JTAPI_EVENT_USED（PG が使用する JTAPI イベントをトレースします）

    • trace JT_PIM_EVENT（PIM に送信されるイベント メッセージをトレースします）

    • trace JT_ROUTE_MESSAGE（クライアント ルーティングをトレースします）

    • trace JT_LOW*（JTAPI と CTI レイヤに基づくトレースをします）

  • PIM（procmon を使用）

    • trace  tp*（サードパーティの要求をトレースします）

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

    • trace *event（エージェントやコール イベントをトレースします）

    • trace csta*（CSTA コール イベントをトレースします）

  • CTI サーバ（procmon を使用）

    • regset EMSTraceMask 0xf8（有用な CTI サーバトレースを有効にし、おそらくラップ アラウンドができます）

OPCTest

opctest は PG の OPC プロセスをデバッグするのに役立つコマンド ライン ツールです。

  • 使用法： opctest /cust <顧客名> /node <ノード>

    • opctest /cust ipcc /node pg1a

  • 有用な設定

    • debug /agent（エージェントのイベントをトレースします）

    • debug /routing（ルーティング イベントをトレースします）

    • debug /cstacer（csta のイベントをトレースします）

    • debug /tpmsg（サードパーティ コール要求をトレースします）

rttest

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

  • 使用法： rttest /cust ipcc

rtsetting.exe

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

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

rtrtrace.exe

ICM でさまざまなルータ トレースを起動する GUI ツールです。

  • IPCC では以下の設定が特に便利です。

    • [Queuing]：問題のデキューイング用。

    • [Service Control]：VRU インターフェイスの問題用。

    • [Translation Routing]：トランスレーション ルーティングの問題用。

dumplog

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

  • OPC、PIM と JtapiGW プロセス ログ ファイルは icr\<customer_name>\<node>\logfiles\ にあります。

  • PG には cdlog というバッチ ファイルがあり >cdlog <cust> <node> と入力することで実行できます。

  • 使用法： dumplogプロセス名

    • Dumplog /"（dumplog オプションのヘルプの表示）

    • Dumplog jgw1

    • Dumplog pim1

    • Dumplog opc

vrutrace

VRU PG のキャプチャ ファイルを表示するツール。dumplog と似た機能です。

Call Tracer

ルーティング スクリプトのデバッグに役立つ Cisco ICM ツール。  このツールは AW の [AW] メニュー項目にあります。

jtprefs

これは IP IVR の JTAPI クライアントの JTAPI トレースをオンにするツールです。IPCC PG での JTAPI トレースは procmon インターフェイスで制御されます。このツールは program files\CiscoJtapiTools\ にあります。

Performance Monitor

Cisco CallManager、Cisco IP IVR、ICM のリアルタイム データを示す Microsoft Windows 2000 の管理ツールです。進行中のコール、登録済みデバイス、プロセスの CPU 使用率を表示できます。このツールは [Start] > [Programs] > [Administrative Tools] にあります。

ログ ファイル

Cisco ICM ログ ファイル

Cisco ICM ログ ファイルは \icr\<cust>\<node>\logfiles にあります。ここで、customer は顧客インスタンス名を、node は pg1a、ra はルータ、cg1a などを表します。ログ ファイルを表示するには、dumplog を使用します。

注：イベントキャプチャファイルは、vrutraceなどのトレースツールを使用して表示できます。これらのファイルは別のディレクトリにあります。

Cisco CallManager ログ ファイル

Cisco CallManager のトレース ログ ファイルは通常 \program files\cisco\ccm\trace に以下のトレースディレクトリと共に置かれます。

  • Ccm：CallManager SDI ログ。

  • Dbl：データベース層のログ。

  • Sdl：コール シグナリングのログ。

  • Tftp：TFTP サーバのログ。

Cisco CallManager Administration ページの [trace settings] から、これらのファイルのトレース設定を変更できます。Cisco CallManager のサービス パラメータから SDL トレース設定を変更できます。

IP IVR ログ ファイル

IP IVR ログファイルは \program files\wfavvid にあります。また、[appadmin] ページの [engine-trace files] から IPIVR のログ ファイルを表示することもできます。

jtprefs.exe で JTAPI イベントをオンにして IP IVR エンジンを再起動すると、Cisco JTAPI Client ログを表示できます。

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

ケースを開くためのデータを集めるときは、ログ ファイルの取得に加えてこのセクションに列挙されているデータを集めます。

エージェント数

設定されているエージェントの数はいくつか。

使用されるゲートウェイ

設定されているゲートウェイの数はいくつか。

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

Cisco CallManager、JTAPI Client、ICM、Gateway IOS バージョンと IP IVR。

  • Cisco CallManager Administration Web ページの [Help] > [About] > [Details] で Cisco CallManager のバージョン番号を確認できます。

  • JTAPI Client のバージョンを確認するには、Cisco CallManager PG のコマンド プロンプトから \winnt\java\lib ディレクトリで jview CiscoJtapiVersion と入力します。

  • また、IP IVR バージョンも確認できます。

IVR タイプ

どのタイプの IVR を現在使用しているか。

プラットフォーム

使用しているプラットフォームのタイプ/CPU/物理メモリ量。

関連情報

更新履歴

改定 発行日 コメント
1.0
21-May-2002
初版

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

Feedbackフィードバック

シスコに問い合わせ

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