コラボレーション : Cisco Unified Contact Center Enterprise

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

2004 年 1 月 6 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2006 年 1 月 9 日) | フィードバック

目次

概要
前提条件
     要件
     使用するコンポーネント
     表記法
症状とトラブルシューティングの手順
     Cisco IPCC PIM がアクティブにならない
     JGW プロセスがアクティブにならない
     ディレクトリの問題(設定、動作しない場合、ディレクトリのパスワード)
     エージェントがログインできない
     エージェントがコールを発信できない
     エージェントが Not Ready、Busy、または Other にならない
     エージェントが Ready 状態にならない
     エージェントがログアウトできない
     エージェントにアクティブなコールが表示されるか、エージェントが Talking 状態であるが、電話にコールが存在しない
     アラートの直後または確立の直後にコールがクリアされる
     ポスト ルーティングが動作していない
     エージェントが応対可能状態になった時点でルーティング スクリプトがコールをデキューしない
     すべてのエージェントおよびキューイング ポートがビシー状態である時、Ring No Answer が聞こえる
     任意転送の結果に一貫性がない
     Alternate が機能しない
     会議に参加したパーティが別のパーティに参加できない
     エージェント ステーションが突然ログアウトする
     エージェントが Agent Desk Settings の設定通りに動作しない
     打診転送に失敗する
VRU へのトランスレーション ルートが機能しない
     ルート要求が、ルーティング スクリプトで「VRU ノードへのトランスレーション ルート」に到達しない
     トランスレーション ルートがルータのログでタイムアウトになっている
     VRU PIM のログに、トランク グループ X で DNIS が見つからなかったことが示されている
     ICM の設定の確認
Cisco IP IVR - ICM インターフェイスのトラブルシューティング
     トランスレーション ルートに障害が発生する
     スクリプトが再生されないか、エラー メッセージが再生される
     JTAPI のステータスで、サービスが一部しか機能していないことが表示されている
     IP IVR の ICM ステータスで、サービスが一部しか機能していないことが表示されている
     コールがルータからデキューされる際に、プロンプトの雑音が聞こえる
IVR サービス統計のトラブルシューティング
     サービスの統計または終了コールの詳細レコードが生成されない
     VRU ですべてのコールが Connected と報告され、Desired とはキューイングされない
     コールが不正なサービスに対してカウントされているか、サービス レポートに表示されていない
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 のタイプ
     プラットフォーム
関連するシスコ サポート コミュニティ ディスカッション
関連情報

概要

この文書では、Peripheral Gateway(PG)および Cisco Intelligent Contact Management(ICM)を中心として、Internet Protocol Contact Center(IPCC)のトラブルシューティングについて説明します。 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 Setup でペリフェラルが有効であることを確認します。 ペリフェラルがすでに追加されていても、有効にする必要のある場合があります。

Edit > Peripheral と選択し、Enabled チェックボックスをチェックします。

PIM が再起動中である

PIM プロセスが再起動中である場合は、Dumplog ユーティリティを使用して、Cisco CallManager PG で PIM のログを表示します。 ログ ファイルに OPCHeartbeatTimeout に関するエラーが示されている場合は、次のレジストリ設定を修正する必要があります。 この変更を行うには regedt32 を使用します。

eagtpim ダイナミック データのレジストリの OPCHeartbeatTimeout を 10 に修正します。レジストリは次のとおりです。

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

注: 上記のキーは、スペースの制限上 2 行で表示されています。

PIM Log ウィンドウで PIM がアイドル状態になっている

PIM プロセスがアイドル状態である場合は、次の情報を確認します。

  • PIM のログを確認します。 少なくとも 1 分に一度は「Attempt to Activate」が存在します。

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

  • OPC プロセスがルータから設定を受信していない場合は、Dumplog ユーティリティを使用して pgagent ログを表示します。 pgagent プロセスは、Central Controller へのアクティブなパスを保持します。 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 Virtual Machine(JVM; Java バーチャル マシン)がインストールされています。

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

    Microsoft (R) Command-line Loader for Java version 5.00.3190
  • このような出力が表示されない場合、またはバージョンが 3190 よりも古い場合は、msjavx86.exe を実行して、適切なバージョンの Microsoft JVM をインストールします。 このファイルは、セットアップ中に icr\bin ディレクトリにインストールされます。

Java classpath が正しくない

  • コマンド プロンプトから 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 classpath を確認します。  Registry Editor を使用して、SOFTWARE\Microsoft\Java VM キーの値 Classpath を調べます。  キーは次のように設定する必要があります。

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

注: ドライブ文字と Windows のシステム ディレクトリは上記とは異なり、「classes」と「c:\icr…」に挟まれた部分にある文字は、セミコロン、ピリオド、セミコロンとなる場合があります。

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

  • コマンド プロンプトから 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 を実行した際に上記のようなメッセージが表示された場合は、PG に Cisco JTAPI クライアントがインストールされていることを確認します。 c:\winnt\java\lib にファイル CiscoJtapiVersion.class があるかを確認します。

  • このファイルが存在しない場合は、Cisco CallManager(http://<callmanager name>/main.asp)から PG にこのファイルをインストールできます。 ファイルは、このページの application タブからアクセスできます。

JTAPI GW のログに、互換性のない JTAPI バージョンの記録がある

  • ホット フィックスが 50 未満である JTAPI 4.1 サービス パック(SP)4 だけが Cisco CallManager PG にインストールしてある場合は、アップグレードを行う必要があります。

  • ICM > Setup を実行して PG をアップグレードした直後である場合は、ファイル \icr\bin\icrjavalib.zip の日付/時刻が、更新された日付を示していることを確認します(bldXXXXX.version ファイルの日付/時刻とほぼ同じ(差は約 1 日)である必要があります)。

注: Setup を実行した際にこのファイルが使用中である場合は、Setup はこのファイルを更新できません。 これは、zip ファイルはクラス パスのディレクトリとして扱われるため、インターネット ブラウザが開いていると、zip がそのブラウザにより開かれる場合に起こることがあります。 これを避けるには、Setup を実行する前にすべてのブラウザ セッションを閉じます。  Setup がファイルを更新できない場合は、リブートしてファイルを更新するよう通知するメッセージが表示されます。 必ずリブートしてください。

JTAPIGW が Cisco CallManager に接続できない

  • PIM は JTAPI Gateway(JTAPIGW)と通信し、JTAPIGW は Cisco CallManager と通信します。 PIM がアクティブになる際には、PIM は JTAPI を介して Cisco CallManager との通信を初期化するよう JTAPIGW に通知します。

  • 次のように、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()

    注: 上記の例は、スペースの制限上 2 行で表示されています。

トレースが正しく返されたことが確認できない場合は、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 のアドレスを解決できません。 セットアップの PIM ダイアログのサービス パラメータは、Cisco CallManager のホスト名または IP アドレスを使用して設定する必要があります。 Cisco CallManager 用の正しいホスト名を使用して設定されている場合は、Cisco CallManager に ping を発行できることを確認します。 そうでない場合は、ホスト名の代わりに、Cisco CallManager の IP アドレスを使用します。

JGW のログに不正なパスワードまたはユーザが示されている

JTAPI GW は、ユーザ名とパスワードを使用して Global Directory にログインします。 セットアップの PIM ダイアログのユーザ名とパスワードは、ccmadmin > User > Global Directory の Cisco CallManager admin Web ページにあるグローバル ディレクトリで設定されているユーザのユーザ名とパスワードと一致する必要があります。

ユーザが存在しない場合は、新しいユーザを追加します。 必ず、ページの最下部の CTI Enabled チェックボックスをチェックします。

Global Directory User ページで CTI チェックボックスが有効でない

Cisco CallManager global directory user ページには、PIM または IP IVR ユーザに関する CTI の特権を有効/無効にできるチェックボックスが存在します。 PIM/JTAPI GW がアクティブになるためには、このチェックボックスをチェックして更新する必要があります。 このチェックボックスは、(問題の原因になる可能性がある)2 つの CTI デバイスが Cisco CallManager に接続するのを防止します(デフォルトの制限は 400 です)。

Cisco CallManager サービスが動作していない

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

  • 通常、Cisco CallManager サービスは、異常終了した場合に再起動するよう設定されていますが、フェールオーバーのシナリオにおけるデバイスのマイグレーションに関して発生しうる問題のため、「off」に設定されている場合があります。

  • イベント ログを調べ、Cisco CallManager サービスが再起動しているかどうかを確認します。 システムは、十分な CPU 使用の確保に関する問題を特定した場合に、再起動することがあります。 システムはイベント ログで、「slow SDL timer thread」を示すエラーや警告を報告します。 このタイプのエラーが発生すると、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 User ページが機能していない

Cisco Global Directory user Web ページで、ユーザの確認と設定、およびコントロール デバイスへの権限の割り当てが実際に行えることを確認します。 JTAPIGW と Web ページは、両方とも Cisco CallManager を使用してディレクトリ サーバにアクセスし、ユーザと権限にアクセスします。 JTAPIGW の問題の原因がディレクトリ サーバの問題である場合は、ユーザ Web ページにも問題があると考えられます。 理由としては、ディレクトリ サーバが動作していないか、ディレクトリが正しく設定されていないことが考えられます。

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

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

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

DC ディレクトリ サービスと Cisco CallManager が両方とも動作していることを確認します。

Cisco CallManager をインストールする際に、ディレクトリ管理者のパスワードを入力するプロンプトが表示されたら、「ciscocisco」と入力する必要があります。 これ以外の情報を入力した場合は、(追加と削除)DC Directory Software を削除し、再インストールする必要がある場合があります。 削除で一部のファイルが削除できなかったことが通知された場合は、手動で既存の c:\dcdsrvr ディレクトリの削除や名前の変更を行います。

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

コントロール パネルで、サービスが起動できないことを確認します。 次に、Properties フィールドで、サービスに対して管理者が設定されていて、ログインとパスワードが正しいことを確認します。

ディレクトリ サーバはインストールされ動作しているが、DCD Admin ツールを使用してログインできない。

システムの Start メニューから DC Directory Admin を起動します。 パスワード「ciscocisco」(デフォルト)または管理者が設定したパスワードで、ユーザの Directory Manager を使用して、ログインします。 ユーザが設定されてないことを示すエラーが表示された場合は、DCDSrvr\bin ディレクトリの Cisco AVVID 設定ファイルのいずれかを実行します。 これがプライマリの Cisco CallManager、つまり Publisher である場合は、DOS プロンプトから avvid_cfg.cmd を実行します。 セカンダリの Cisco CallManager である場合は、コマンド プロンプトから avvid_scfg.cmd を実行します。

これがすでに設定されていることを示すエラーが発生した場合は、そのユーザは実際に存在しています。 エラーが発生しない場合は、正常に起動し動作します。 ccmadmin の Global Directory User ページに戻り、ここから権限を確認します。

注: DC Directory は、システム リソースが低下していると判断した場合 pause モードになります。

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

次の例では、デバイス ターゲット用の ICM の設定例を使用しています。

デバイス ターゲットの例

 

企業名

Agent9782755100

グローバル アドレス

Agent9782755100

ConfigParm

/devtype CiscoPhone /dn 9782755100

次の例では、エージェント用の ICM の設定例を示しています。

エージェントの例

 

ペリフェラル

CCMPG_PIM1

ペリフェラル番号

1234

パスワード

XXX

PG に対して ICM > Setup を実行した場合、エージェントの番号の長さ「4」が指定されます。 そのため設定例では、サンプル デバイスの番号は、/dn パラメータの最後の 4 桁(たとえば「5100」)になります。

CTITest を使用してログインを試行します。

ソフト フォンを使用してエージェントでログインする際にトラブルが発生した場合は、ctitest を介して同じ操作を試行すると有用な場合があります。 サンプル エージェントをサンプル デバイス ターゲットにログインさせるために使用できる ctitest コマンドのサンプル リストがあります。 このコマンドのリストでは、CTI サーバは、マシン CTIServerA のポート 42027 に対してリスニング状態であることが前提になっています。 また、デバイスは、「ICM peripheral 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 Server log ウィンドウのタイトル バーにも、プロセスの状態が表示されます。

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 -- A 側の CTI サーバが接続をリッスンするポートと一致する必要があります。 これは、CTI サーバの ICM セットアップで指定されています。 CTI サーバではタイトル バーにこのポートが表示され、起動時にそのポートをログ記録します。 クライアントが CTI サーバに ping を発行できることを確認します。

CTI クライアントに、エージェントが ACD にログインする必要があることを示すエラーが発生する

PG/CTI サーバの \icr\bin ディレクトリにある setup.exe を実行します。 CTI Gateway コンポーネントを選択します。 Agent Login Required チェックボックスのチェックがはずされていることを確認します。 このチェックボックスの選択は、IPCC またはサードパーティの制御アプリケーションには適用されません。 チェックボックスの目的は、その他の ACD エージェントのアプリケーションを監視することです。

PIM のログに、次のログイン エラーのいずれかが示されている

PIM に対して procmon を使用し、「trace tp*」(大文字小文字の区別あり)を実行して、サードパーティのトレースをオンにします。 これにより、要求されているログが表示されます。 パラメータが正しいことを確認します。 装置は「Device=」としてトレースされます。 これは、デバイス ターゲット configparam/dn 文字列と一致する必要があります。 エージェント 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 がログインに使用するユーザと関連付けられていません。 Global Directory のユーザ デバイス アソシエーション リストの遠端側の番号が正しいことを確認します。 また、デバイスの回線番号が二度登録されていないことも確認します。 共用ライン アピアランスは、IPCC ではサポートされていない Cisco CallManager の機能です。 2 台の電話で同じ回線を使用するよう設定することで、誤って共用ライン アピアランスをセットアップしようとしてしまう場合があります。 1 つの回線番号を変更するともう一方が変更されます。また、PG には正しいデバイスにログインする際にトラブルが生じます。 この問題を解決するには、両方の回線を削除し、それらを Cisco CallManager に追加します。

INVALID_SKILL_GROUP_SPECIFIED

ログインするには、少なくとも 1 つのスキル グループのメンバーとしてエージェントを Configure/ICM で設定する必要があります(Skill Group Member)。

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

(エージェント ペリフェラル番号により指定される)エージェントが、すでに別のデバイス ターゲットにログインしていないことを確認します。 これを確認する 1 つの方法としては、問題のエージェントに対して Monitor ICR を実行し、Agent report を実行します。 エージェントがログインしている場合は、これにより、エージェントがログインしているデバイス ターゲットのネットワーク ターゲット ID が表示されます。 ペリフェラルに関するエージェント データをこの AW に送信するように ICM が設定されている場合は、エージェント データは awdb だけに存在します。

  • awdb の Agent_Real_Time テーブルに対して、isqlw でこの情報を照会することもできます。 まず、エージェントのスキル ターゲットを検索します(たとえば、PeripheralID = XXX であり PeripheralNumber = YYY であるエージェントから * を選択します)。 続いて、エージェントがログインしているかどうかを確認します(たとえば、SkillTargetID = XXX である Agent_Real_Time から * を選択します)。

  • また、PIM に procmon を接続し、dagent <エージェント ペリフェラル番号> を実行することで、これを確認することもできます。

デバイス ターゲットがすでにログインしている

(装置により指定される)デバイス ターゲットに、まだ別のエージェントがログインしていないことを確認します。

  • 確認する 1 つの方法としては、awdb の Agent_Real_Time テーブルに対して isqlw を実行します。 まず、問題のデバイス ターゲットのネットワーク ターゲット ID を検索します(例、SQL query command で select * from Device_Target where ConfigParam like ‘%1003%’を実行)。 続いて、デバイス ターゲットがログインしているかどうかを確認します(たとえば、NetworkTargetID = XXX である Agent_Real_Time から * を選択します)。

  • また、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 Event Viewer アプリケーション ログを調べ、DC ディレクトリまたは Metalink からのエラーを確認します。 インポートのエラーが発生している場合は、c:\dcdsrvr\bin から avvid_recfg を実行します。

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

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

電話をチェックし、電源が入っているか、Cisco CallManager に登録されているか、およびエージェント制御なしで電話からコールの送受信ができるかを確認します。

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

エージェントが Ready 状態にない

エージェントはログイン済みであり、応対可能状態ではないことを確認します。  エージェントが応対可能ではない場合、エージェントはコールを発信できません。 コールを発信するには、まず Not Ready をクリックします。

Agent Desk Settings が正しくない

特定の番号をダイヤルした場合にだけエラーが発生する場合は、物理的な電話からそれらの番号を調べ、正しくダイヤルできることを確認します。 ICM ダイヤル番号計画を設定済みである場合は、ダイヤルする番号がダイヤル番号計画のワイルドカードのいずれかと一致することを確認します。 続いて、Agent Desk Settings により、そのエージェントは、ダイヤル番号計画のエントリにより特定されるタイプの番号をダイヤルできることを確認します(国際電話など)。

PIM のダイヤル番号計画がアクセスをブロックする

各 PIM に対して設定されているダイヤル番号計画の設定が正しくないか、エージェントがある特定の番号をコールできないように正しく設定されている可能性があります。 PIM のログのエラーには、権限のエラーが示されます。 ダイヤル番号計画を使用してエージェント間のコールを行う場合、エージェントとデバイスの番号を重複させることはできません。

エージェントが短いコールを行った場合、新しくコールを行うには待機する必要がある

エージェントがコールを行う場合や、コールがエージェントにルーティングされる場合は、ルータによりエージェントは応対可能ではなくなります。 このメカニズムにより、PIM がコールの受信を報告する前に、ルータは別のコールをエージェントにルーティングできます。 一部のネットワークでは、実際にコールをルーティングするのに数秒間かかります。 ルータは、エージェントの状態に基づいてタイマーをキャンセルすることはありません。

ルーティング クライアントから PIM にコールをルーティングするのに要する実際の時間が比較的短い場合、ルータの設定可能な時間は変更可能です。 いずれかのルータの DOS コマンド ウィンドウで、rtsetting.exe を使用します。 Extrapolation > Agent と選択して調べます。 デフォルト設定は 10 秒です。 値が短すぎる場合、ルータは、すでにコールを受信するプロセスにあるエージェントに対してコールをルーティングする場合があります。 これにより、PIM がコールをドロップします。

PIM のデフォルトのタイムアウトは 7 秒です。 この値は regedt32 を使用すると修正できます。 次のパスに、キー「AgentReserveTimout」を追加します。

注: このキーは、バージョン 4.1.5 のセットアップ中に追加されます。

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

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

元のイベントが処理される前に、ルータが PIM に新しいコール前イベントを送信しないようにするため、PIM の数値はルータの外挿タイマーよりも常に数秒低い値にする必要があります。 PIM で問題が生じるのはこのためです。

PIM がタイムアウトした後にコールが到着した場合、そのコールは非 ACD コールとみなされ、コンテキスト変数、サービス、またはスキル グループの情報は、コールに割り当てられません。

エージェントが Not Ready、Busy、または Other にならない

「アクティブ」状態のエージェント

エージェントがコール中に Not Ready、Busy、または Other をクリックした場合、そのエージェントの状態はすぐには変化しません。 これは意図的なものです。 そのエージェントはコールが完了するまで、Talking または Held の状態のままになります。 押されるボタンに応じて、エージェントは Not Ready、Work Ready、または Work Not Ready に移行します。 コール終了後エージェントがただちに Available に移行した場合は、Agent Desk Settings を調べ、Available After Incoming または Available After Outgoing が設定されているかどうかを確認します。 これらの設定は、コール中にエージェントがボタンを使用して実行するタスクよりも優先されます。

移行を妨げる Agent Desk Settings

Configure ICM で Agent Desk Settings を調べ、Idle Reason Required がチェックされているかどうかを確認します。 チェックされている場合は、そのエージェントは原因コードを提供することなく「Not Ready」になることはできません。 Configure ICM のエージェントのデスク設定と一致するよう Desktop_Settings.cfg を修正するか、Configure ICM のエージェントのデスク設定を変更します。

エージェントに割り当てられているエージェントのデスク設定が存在しない場合は、そのエージェントはログインし Ready 状態になることはできますが、not_ready になることやログアウトすることはできません。 解決策としては、エージェント アプリケーションを閉じ、エージェントのデスク設定を割り当て、再度ログインします。

Not Ready 状態になるにはエージェントは待機する必要がある

エージェントがコールを行う場合や、コールがエージェントにルーティングされる場合は、ルータによりエージェントは応対可能ではなくなります。 このメカニズムにより、PIM がコールの受信を報告する前に、ルータは別のコールをエージェントにルーティングできます。 一部のネットワークでは、実際にコールをルーティングするのに数秒かかる場合があります。 ルータは、エージェントの状態に基づいてタイマーをキャンセルすることはありません。

ルーティング クライアントから PIM にコールをルーティングするのに要する実際の時間が比較的短い場合、ルータの設定可能な時間は変更可能です。 いずれかのルータの DOS コマンド ウィンドウで、rtsetting.exe を使用します。 Extrapolation > Agent と選択して調べます。 デフォルト設定は 10 秒です。 値が短すぎる場合、ルータは、すでにコールを受信するプロセスにあるエージェントに対してコールをルーティングする場合があります。 これにより、PIM がコールをドロップします。

エージェントが Ready 状態にならない

PRIVILEGE_VIOLATION_ON_SPECIFIED_DEVICE

要求されているログおよび Ready 要求のデータ間で不一致が存在します。 装置、エージェント ID、またはペリフェラル番号が一致しない可能性があります。 procmon を使用して CTI サーバのトレースをオンにして、regset で 0xf8 に設定して、適切なトレースを確認します。 これは、サードパーティ(TP)トレースがオンである場合は、OPC または PIM のログ記録でも表示可能です。

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

エージェントの現在の状態によりコールを発信できない

エージェントが Work Ready、Work Not Ready、または Available 状態である場合は、エージェントはログアウトする前にまず「Not Ready」状態になる必要があります。 Configure ICM のエージェントのデスク設定と一致するよう Desktop_Settings.cfg を修正するか、Configure ICM のエージェントのデスク設定を変更します。

状態変更を妨げる Agent Desk Settings

エージェントが Not Ready 状態であるにもかかわらずログアウトできない場合は、Configure ICM で Agent Desk Settings を調べ、Logout Reason Required がチェックされているかどうかを確認します。

エージェントにアクティブなコールが表示されるか、エージェントが Talking 状態であるが、電話にコールが存在しない

エージェントのログアウトと再ログインを試みる

物理的にはもはや存在しないコールがソフト フォンに表示される場合、エージェントの状態は「Talking」または「Hold」に固定され、エージェントはログアウトできません。 これは、JTAPI または PIM のソフトウェア上の不具合によるものである場合があります。 この状態をクリアするには、release ボタンが有効になっている場合、まずソフト フォンからのコールのクリアを試みます。 この操作でも正常に動作しない場合は、エージェントのログアウトを試みます。 logout ボタンでも正常に動作しない場合は、ソフト フォンを終了し、再起動します。 この状態が継続する場合は、ソフト フォンを終了し、Task Manager を実行し、kill 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 ツールを使用して、コールがスクリプトに到達し、スクリプトが正常に動作していることを確認します。 Script Editor を実行してスクリプトを監視します。 ルータ、OPC、および PIM のログを調べて、問題がないか確認します。 大部分のルーティングのエラーは無条件にトレースされます。

ペリフェラルのルーティング クライアントに対して「Use DN Label Map」がチェックされている

Configure ICM の各ルーティング クライアントに関しては、「Use DN/Label Map」という設定があります。 この設定が「Yes」に設定されている場合は、ダイヤル番号と可能なターゲット ラベルの各組み合わせに対して、「Dialed Number Label」エントリを設定する必要があります。 この設定は PG ルーティング クライアントに対しては有用でないため、「No」に設定する必要があります。

ルーティング対象のデバイス ターゲットに対してラベルが設定されていない

ルーティング クライアントでラベルが設定されていることを確認します。 各ルーティング クライアントでラベルが同じである場合であっても、各ルーティング クライアントでラベルを設定する必要があります。

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

ポスト ルーティングを使用するためには、Cisco CallManager で「CTI Route Point」を設定し、必要なディレクトリ番号を持つルート ポイントに回線を割り当てる必要があります(「5000」など)。 ポスト ルーティングへのエージェント コールの場合は、ダイヤル番号計画を使用します。 CTI Desktop バージョン 4.1.9 では、Cisco CallManager の CTI ルート ポイントへのエージェント ダイヤルを使用すると、IPCC ソフト フォンを混乱させます。

CTI ルート ポイント用のデバイスが、PG ユーザにより制御されるデバイスのリストに存在しない

グローバル ディレクトリの Cisco CallManager user web ページで、CTI ルート ポイント デバイスを、PG ユーザ用の「Associated Devices」のリストに追加する必要があります。 新規デバイスを作成する場合は、まず回線を追加してから、デバイスをユーザの「Associated Devices」リストに追加します。 すでにユーザのデバイス リストにある既存のデバイスにさらに回線を追加する場合、JGW に新しい回線を認識させるには、JGW を再起動する必要があります。 ただし、新規デバイスを追加し、それに回線を追加してから、デバイスをユーザのデバイス リストに追加する場合は、JGW は新規デバイスを認識します(約 30 秒以内)。

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

ダイヤル番号を調べ、ペリフェラルのルーティング クライアントに対してその番号が設定されていることを確認します。 「trace *ROUTE*」(大文字と小文字の区別あり)のように、JGW に対して procmon を実行して、トレースをオンにします。 JGW のログを調べ、ダイヤル番号に関連するエラーを確認します。 JGW の起動時には、JGW は、ダイヤル番号に対してルート コールを再度登録しようとすることが確認できます。 そのダイヤル番号へのコールが行われる際には、ゲートウェイにより受信される「RouteEvent」が確認できます。

ダイヤル番号とともに、スクリプトに対してコール タイプが適切に作成およびマッピングされていることを確認します。

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

ICM ダイヤル番号を設定し、CTI ルート ポイントをセットアップし、それをユーザ デバイス リストに追加していても、番号をダイヤルした際にルート要求を受信できない場合は、JGW を再起動する(または PG をサイクルする)必要がある場合があります。 これを行う必要があるのは、JGW でトレースをオンにし(trace *ROUTE*)、プロバイダーにアドレスがないことを通知するエラーが表示された場合だけです。 通常、JGW は再起動を行うことなく、ユーザ デバイス リストに追加された新しい CTI ルート ポイントを認識できます。 また、既存の CTI ルート ポイントに回線が追加された場合は、再起動を行わないと、JGW はそれらを認識しません。 既存のデバイスに新しい回線を追加する代わりに、各ダイヤル番号の新しい CTI ルート ポイントを追加することで、再起動を回避できます。

注: この場合は、PIM の winnt\java\lib ディレクトリにある JTAPI.ini ファイルで 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 を使用)。 これを変更することでベース スキル グループへのキューイングに、ほぼ予想通りの動作をさせることができます。 この種類のキューイングが行われた場合は、セカンダリ スキルよりもプライマリが優先されることはありません。

  • 明示的に、キュー ノードのプライマリ/セカンダリのスキル セットに対してキューイングを行います。

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

問題のデバイス ターゲット、およびこのルーティング クライアントがルーティング先にできるその他すべてのターゲットに対して、ラベルを設定します。 この作業をより効率的に行う方法としては、Configure ICR を使用するよりも、AW bulk configuration ツールを使用します。

すべてのエージェントおよびキューイング ポートがビシー状態である時、Ring No Answer が聞こえる

ルータのログの確認

  • ルーティングのエラーは無条件にトレースされます。

  • Call Tracer ツールを使用すると、ルート パスをテストできます。

  • rtrtrace を使用してルート要求のトレースをオンにして、ルータのログを調べ、ルート ポイントへのコール時のエラーを確認します。

  • 必要なすべてのラベルが設定されていることを確認します。 ルーティング スクリプトの対象が IPCC/EA エージェントである場合は、対象である各デバイス ターゲットに対して設定されているラベルが必要です。 各デバイス ターゲットには、コールの送信を試行できる各ルーティング クライアントに対して設定されているラベルが必要です。 そのため、ネットワークから応対可能状態のエージェントに直接、コールがプレルーティングされている場合は、ネットワーク ルーティング クライアントには、関連付けられているデバイス ターゲット用のラベルが必要です。 コールがまず VRU でキューイングされてからエージェントに配送される場合は、VRU ルーティング クライアントには、関連付けられているデバイス ターゲット用のラベルが必要です。

Configure ICM で、ルーティング クライアントでは DN ラベル マッピングがオフになっていることを確認する

Configuration Manager/PG Explorer 内で、Routing Client タブでは Use DN/Label map がチェックされていないことを確認します。

PIM のログを確認します

  • procmon を使用して PIM でトレースをオンにして(trace precall、trace *call_event*)、ログを確認します。 ルータからプレコール メッセージが表示されていることが確認できます。 また、「DevTgDevStr」とともに「DeliveredEvent」がエージェントの番号に設定されていることも確認できます。 コールが表示されていない場合は、ラベルがルーティング クライアントに適切であることを確認します。

任意転送の結果に一貫性がない

Cisco CallManager で結果の一貫性が失われるため、IPCC ではコールを保留状態にして、新しいコールを行うことはサポートされていません。 この動作は、将来のリリースの、製品の機能拡張として検討されています。

Alternate が機能しない

コンサルト コールが Switch/Alternate/Hold/Retrieve された場合、Cisco CallManager はそのコンサルト アソシエーションを解除します。 続いて、サポート対象外である任意転送のシナリオになります。 エージェントはカスタマーに再接続し、新しいコンサルトを開始できます。 IPCC ソフト フォンではコンサルトが解決されるまで alternate ボタンが無効になりますが、サードパーティ ベンダーの場合は問題が生じることがあります。

会議に参加したパーティが別のパーティに参加できない

Cisco CallManager には、会議を開始したユーザだけが会議にパーティを追加できるという制限があります。 その他のパーティがパーティを追加することは、Cisco CallManager により禁止されています。

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

Agent Desk Settings の非アクティビティ タイマー

Agent Desk Settings には、Not Ready 状態のエージェントをログアウトさせる時間の設定が存在します。 非アクティビティ時間の最大値は 2 時間ですが、それよりも短く設定できます。 応対可能状態のエージェントは、非アクティビティ状態である間はログアウトしません。 Ring No Answer タイマーが時間切れになると、エージェントは Ready から Not Ready に移行します(設定可能なエージェントのデスク設定も同様)。

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

CTI サーバは、ハートビート タイムアウトが設定されています。 根本的な原因には、古いコンピュータ、オーバーワーク状態の CTI サーバ、帯域幅に問題があるネットワークが考えられます。 CTI サーバのログに、エラーが報告されます。

エージェントが Agent Desk Settings の設定通りに動作しない

Configure ICR(M) の Agent Desk Settings と、エージェントの設定ファイルの両者は、エージェントの取り扱い方法について一致する必要があります。

Configuration Parameters には、ICM のペリフェラル設定での work タイマーがあります。 このタイマーは次のように設定すると、auto-available に対して 30 秒の遅延が設定されます。

\WORKTIMER 30

デスクトップ設定ファイルは次の場所にあります。

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

Desk_Settings.cfg および Configure ICR(M) の Agent Desk Settings では、Incoming の work モードは Required に設定し、Required with Data には設定しないでください。 Required with Data は、auto-available オプションに取って代わります。

打診転送に失敗する

JTAPI GW のログを調べ、打診転送が失敗する原因が示されているエラーがないかを確認します。 エージェント ソフトウェアでコンサルト コールに対して Hold/Retrieve または Alternate 操作が許可されている場合は、これが原因である場合があります。 一方のコールが Hold/Retrieve されると、Cisco CallManager により、そのコールはもはやコンサルタティブではなく、「任意」転送と見なされます。 その Cisco CallManager には、任意転送に関する問題があります。 コンサルタティブ コール中には、ユーザによる転送の再接続または完了を制限することをお勧めします。

コンサルト中のパーティがハングアップするが、コール アピアランスが消えない

現時点の Cisco CallManager では、会議が終了していない時点での、会議によって開始されたコンサルトを切断するイベントの提供に問題があります。 もう一度コールを切断することで、エージェントの電話でコール アピアランスがクリアされます。

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

最初に、アクティブなスクリプトを監視します。 続いて、ルーティング クライアントおよび VRU のルータ、OPC、および PIM のログを調べます。 大部分のエラーは無条件にトレースされますが、トレースをオンにすると、何が発生しているかをより詳細に把握できます。

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

  • ルーティング クライアントがルータへの新しいコール要求を行う。

  • ルータは、そのコールを IVR に配送するラベルを使用して、ルーティング クライアントに接続を返す。

  • 続いて IVR は、ペリフェラル ターゲットの検索に VRU PG が使用する RequestInstruction を送出します。

  • ルータは、RequestInstruction のペリフェラル ターゲットと、その待機対象であるトランスレーション ルートのペリフェラル ターゲットを照合する。

  • ルーティング スクリプトは、カスタマーにより指定された実行スクリプトまたはキュー ノードを継続する。

初めに、アクティブなスクリプトを監視して、障害経路の場所を確認します。 ルータのトレースを調べ、エラーを確認します。 最初のラベルがルーティング クライアントに送信されているかどうかを確認します。 VRU がコールを受信していることを確認します。 VRU が、VRU PIM または OPC レベルで RequestInstruction を送出していることを確認します。

ルート要求が、ルーティング スクリプトで「VRU ノードへのトランスレーション ルート」に到達しない

スクリプトを監視し、要求が VRU ノードヘのトランスレーション ルートに到達していることを確認します。

まずルーティング スクリプトでは、トランスレーション ルートが選択されている select または route select ノードは、サービス コントロール VRU へのルートを変換するのに十分ではありません。 VRU ノードへのトランスレーション ルートが必要です。

次に、モニタでは、コールがトランスレーション ルート ノードに到達していることが表示されます。 ここで障害が発生していれば、トランスレーション ルートを決定できなかったか、IVR から RequestInstruction ルート要求メッセージが受信されなかったことを意味します。

トランスレーション ルートがルータのログでタイムアウトになっている

トランスレーション ルートのタイムアウト エラーは、ルータで RequestInstruction が受信されていないことを示しています。 OPC および VRU PIM でエラーを調べ、RequestInstruction が受信されていることを確認します。

ルータで rtrtrace ツールを使用して「トランスレーション ルーティング」および「ネットワーク VRU トレース」をオンにすると、ルータで何が行われてるかを把握しやすくなります。 VRU PG OPC では、opctest を使用してサービス コントロールの報告をオンにします。

VRU PIM のログに、トランク グループ X で DNIS が見つからなかったことが示されている

Request Instruction には、VRU PG に対して設定されているトランク グループのいずれかで、トランク グループ ペリフェラル番号に対応する有効なトランク グループが示されます。 修正されている場合は、VRU PG をサイクルして、トランク グループ ペリフェラル番号の更新を受信する必要があります。

ICM の設定の確認

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

NIC/ポスト ルーティング PG には、ペリフェラル ターゲットの各 DNIS 用のラベルが必要です。 (トランスレーション ルート ウィザードで、これらのラベルを、要求側のルーティング クライアントの DNIS と同じものにします。 prefix = DNIS オプションを選択することで、プレフィクスでこれをセットアップすることもできます。)

VRU ルーティング クライアントには、エージェントが応対可能状態になった時点でルーティング クライアントのルーティング先であるデバイス ターゲットに対して設定されているラベルが必要です。

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

この Cisco IP IVR のトラブルシューティングの項では、IVR PG のポスト ルーティングとトランスレーション ルーティングのセットアップに関する一般的な問題を含む、IP IVR と ICM の間での設定エラーを扱います。 一般的な IVR のエラーの詳細については、「Cisco IP IVR トラブルシューティング ガイド」を参照してください。

通常は、Web 上で appadmin > Engine > Trace の 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 IPIVR(CRS)上の trace 設定で SS_TEL, LIB_ICM の debugging を有効にしてください。

  • IP IVR で jtprefs を使用して、IP IVR の Cisco Jtapi のログをオンにします。 デバッグ ツールを参照してください。 トレースをオンにした後で、IP IVR エンジンを停止し、起動します。

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

スクリプトが再生されないか、エラー メッセージが再生される

engine-trace ファイルの IP IVR のログを調べ、次の内容を確認します。

  • 受信された実行スクリプト。

  • IP IVR がスクリプトを検出できるか。 Repository Admin Tool を使用してスクリプトをアップロードする必要があります。

  • IP IVR がプロンプトを検出できるか。 ユーザ定義のプロンプトは、IP IVR の \wfavvid\prompts\ user\en_us\ に存在する必要があります。

JTAPI のステータスで、サービスが一部しか機能していないことが表示されている

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

また、スクリプトの名前が適切でないか、スクリプトが Repository Manager にアップロードされていないことを意味することもあります。

IP IVR の ICM ステータスで、サービスが一部しか機能していないことが表示されている

一般的に、設定が部分的にしか存在しないか、一方または他方で設定の不一致が存在することを意味します。

コールがルータからデキューされる際に、プロンプトの雑音が聞こえる

これは、Configure ICR のネットワーク VRU スクリプト設定で短すぎるタイムアウトが許可されている、設定の正しくないルーティング スクリプトです。

ICM インターフェイス用に IP IVR に付属するスクリプトの一部は非常に長い時間実行されますが、ICM ネットワーク スクリプト設定のデフォルトのタイムアウトは 3 分です。 スクリプトがタイムアウトになり、実行スクリプトの障害経路により別の実行スクリプトが再生された場合は、基本的にこれらの実行スクリプトは IVR でキューイングされます。 実行スクリプトがデキューされると、多くのスクリプトが相互に重なり合って再生されるのが聞こえます。

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

IVR の統計は IPCC のサービス レベルのレポートにとって重要であるため、ここで一部のトラブルシューティングを説明します。 VRU に着信したコールがある Router や VRU PG ではそれらのコールを着信ではなくキューされたものとしてカウントします。コールがルーティングされると、コールは応答済みと報告されます。 キューにあるカスタマーがコールを切断すると、コールは破棄済みと報告されます。 詳細については、ホット フィックス 53 および 54 の readme.txt を参照してください。 ルータは、ルータでコールがどの状態にあるかを示す、特別なキュー イベントを送信します。

VRU PIM には、追加された特別なレジストリ設定があるため、ほとんど中断が生じることがないように、この機能は自発的にオンになる必要があります。

ユーザが、1 つ以上のエンタープライズ ペリフェラル レポートに、VRU サービスおよび Cisco CallManager PG Service(いずれも複数可)を追加した場合に、Enterprise Service Real Time Report 10 はこのデータを特別に使用します。 報告を行う目的のため、VRU PG および Cisco CallManager PG Service は、エンタープライズ サービスでグループ化されることが必要になります。

その他の有用なキュー レポートには、リアルタイムおよび履歴レコードに関する新しいコール タイプのレポートがあります。また、スキル グループのリアルタイム グリッドでは、スキル グループに対してキューイングされたコールが表示されます。

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

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 ですべてのコールが Connected と報告され、Desired とはキューイングされない

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 は、データ Call Type、Service、および Skill Group テーブルとの関連付けが簡単になるようには設計されていません。 通常、番号は各グループにおいてわずかに異なる意味を持ちます。 1 つのコールには 1 つのサービスしか存在しませんが、複数のエージェントが関与する場合は、2 つのスキル グループが存在可能です。 Redirect On No Answer(RONA)機能は、別の終了レコードを生成することなく、別のポスト ルートを生成することがあります。

エージェント スキル グループ、スキル グループ、サービス、コール タイプ番号のバランスがとれていない

  • 症状:処理されるコール、またはその他の統計フィールドが、サービス、コール タイプ、スキル グループ レポート間で一致しない。

  • 状態:コール タイプ、サービス、およびスキル グループが、互いに論理マッピングを使用してセットアップされているにもかかわらず、レポートが正確に一致しない。

  • トラブルシューティング操作:コール ボリュームが 1 コール/秒未満である場合は、CSTA、PIM、AGENT およびサードパーティのイベントに対して適切であるように、OPC、PIM、および JTAPI GW でトレース設定をオンにします。 方法の詳細は、この文書の「ツール」の項を参照してください。

  • 次のように、コール フローを文書化します。

    • 最初のポスト ルートは、Cisco CallManager PG または VRU PG 上に存在するか?

    • Forward On No Answer(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 Admin ページから、Services > Trace Flags と選択してフラグをチューニングできます。 CTI エラーの SDL トレースの場合は、0xCB05 が正しいトレース フラグの設定です。 デバッグ目的のために、サービス パラメータでこの設定を行います。 詳細については、「AVVID トラブルシューティング ガイド」を参照してください。 また、トラブルシューティングのガイドを含む、Cisco CallManager のオンライン文書を参照してください。

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

Cisco CallManager でトレースを収集する際には、Cisco CallManager Admin からフラグをチューニングできます。 Cisco CallManager の CTI データに関するトレースをキャプチャするには、次の手順を行います。

  1. Cisco CallManager のログ記録を設定するため、Admin ページのプルダウン メニューから Service を選択します。

  2. Trace を選択します。

  3. 左側で IP アドレスを選択します。

  4. 設定されているサービスのリストで Cisco CallManager を選択します。

  5. Trace On ボックスをチェックします。

  6. Show Time および Show Date をチェックします。

  7. Detailed レベルを選択します。

  8. SDL のログ記録を設定するため、Admin ページのプルダウン メニューから Service を選択します。

  9. Service Parameters を選択します。

  10. Cisco CallManager の IP アドレスを選択します。

  11. Configured Services のリストから Cisco CallManager を選択します。

  12. Configured Services リスト ボックスで SdlTraceDataFlags を選択し、それを 0x110 に設定します。

  13. SdlTraceTypeFlags を選択し、それを 0xCB15 に設定します。

  14. SdlTraceFlag を選択し、それを TRUE に設定します。

  15. Update を選択します。

設定をチェックし、それらが想定通りであることを確認します。 Cisco CallManager 3.1 以降の場合は、CTI Manager に対して同じ設定を設定します。 必要に応じて、Cisco CallManager で CTI Manager サービスを再起動します。 Cisco CallManager を再起動する必要はありません。 詳細については、「AVVID トラブルシューティング ガイド」を参照してください。

Cisco CallManager の IP アドレスの変更

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

  1. Cisco CallManager PG でセットアップを実行し、Cisco CallManager PIM の JTAPI サービスを変更します。 Extension Mobility/電話サービスを使用する場合は、次の操作を行います。

  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 で サーバーの IP アドレスを変更します。

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

  12. Cisco CallManager > System Profile > Hoteling と選択し、DC ディレクトリにある Hoteling プロファイルの IP を変更します。

  13. SQL Enterprise Manager を開きます。

  14. PlugIn テーブルで URL の IP アドレスを変更します。

設定変更をバックアップするには、次の手順で行います。

  1. stiBackup 設定を開きます。

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

デバッグ ツール

Procmon

procmon は、PIM および JTAPI GW プロセスのデバッグに使用するコマンド行ツールです。

  • 使用法: procmon <カスタマー名> <ノード> process。

    • Procmon ipcc pg1a pim1

    • Procmon ipcc pg1a jgw1

    • Procmon ipcc cg1a ctisvr

各プロセス用の有用なトレースの設定を次に示します。

  • JTAPI GWprocmon を使用)

    • 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 のバイナリ ファイルをテキスト ファイルにダンプします。 ディレクトリをプロセス logfiles ディレクトリに変更します。

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

  • PG には、「>cdlog <カスタマー名> <ノード>」の形式で入力する、cdlog と呼ばれるバッチ ファイルがあります。

  • 使用法: 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\ にあります。

パフォーマンス モニタ

Cisco CallManager、Cisco IP IVR、および ICM のリアルタイム データを表示する、Microsoft Windows 2000 の管理ツールです。 進行中のコール、登録済みデバイス、およびプロセスの CPU 使用率を表示できます。 Start > Programs > Administrative Tools と選択した場所にあります。

ログ ファイル

Cisco ICM のログ ファイル

Cisco ICM のログ ファイルは \icr\<cust>\<node>\logfiles にあります。 カスタマーがカスタマーのインスタンス名を参照し、ノードが pg1a、ルータの ra、cg1a などを参照する場所です。 これらは、上記の dumplog を使用すると表示できます。

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

Cisco CallManager のログ ファイル

通常、Cisco CallManager のログ ファイルは \program files\cisco\ccm\trace にあり、次のトレース ディレクトリが付属しています。

  • Ccm - CallManager SDI のログ。

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

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

  • Tftp - tftp サーバのログ。

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

IP IVR のログ ファイル

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

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

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

サービス リクエストをオープンするためのデータを収集する際には、ログ ファイル以外にも、次のデータが有用です。

エージェントの数

設定されているエージェントの数は?

使用されているゲートウェイ

設定されているゲートウェイの数は?

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

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

  • Cisco CallManager のバージョンは、Cisco CallManager Admin Web ページで、Help > About > Details の順に選択すると表示されます。

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

  • IP IVR のバージョンも調べることができます。Cisco CRS Admin Web ページで、Help > About > Details の順に選択すると表示されます。

IVR のタイプ

使用されている IVR のタイプは?

プラットフォーム

使用されているプラットフォームの種類/CPU/および物理メモリの量。


関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報


Document ID: 23843