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

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

2015 年 11 月 25 日 - 機械翻訳について
その他のバージョン: PDFpdf | ライター翻訳版 (2004 年 1 月 6 日) | 英語版 (2015 年 8 月 22 日) | フィードバック


目次


概要

このドキュメントでは、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 Unified 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 を有効に して下さい。

  • コマンド ウィンドウで、ルータと 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 プロセスはアクティブ行きません

マイクロソフト の Java バーチャルマシン(JVM)の適切でないバージョンはインストールされています

  • コマンド プロンプトに行き、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 Unified CallManager から PG でファイルをインストールできます; http:// <callmanager name>/main.asp。 Application タブの下でファイルを見つけることができます。

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

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

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

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

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

  • PIM は JTapi Gateway (JTAPIGW)と通信し、JTAPIGW は Cisco Unified CallManager と通信します。 PIM がアクティブ行くことを試みると同時に PIM は JTAPIGW を JTAPI によって Cisco Unified 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 Unified CallManager マシンの IPホスト名前または IP アドレスのサービス名です。か。 この例では、IP アドレスは使用されます。か。 名前が使用される場合、PG はホストファイルか DNS によって名前を変換できる必要があります。か。 名前かアドレスを ping できることを確かめて下さい。か。 サービス名を変更し、ICM > Setup を再実行し、編集周辺装置ダイアログの名前を変更する必要があれば。

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

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

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

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

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

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

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

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

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

  • Cisco CallManagerバージョン 3 で、このサービスは「Cisco Unified CallManager」として稼働中制御を示します。 サービスを起動します。

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

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

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

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

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

ディレクトリ問題(設定、実行、ディレクトリパスワード)

ディレクトリ サービスは動作しません

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

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

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

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

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

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

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

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

Cisco Unified 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 Unified 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 Unified CallManager 拡張である必要があります。 拡張は Cisco Unified CallManager が確認すると同時に電話のためのディジットの正しい数である必要があります。 すなわち、拡張は疑わしい電話に達するために同じ Cisco Unified CallManager の別の電話からダイヤルする数である必要があります。

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

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

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

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

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

電話が、Cisco Unified CallManager によって登録されられて、エージェント制御なしで電話から呼び出しを作り、受信することできる動力を与えられるかどうか確認すれば。

エージェントはコールをすることができない

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

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

不適切なエージェント デスクの設定

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

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

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

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

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

ルーティングクライアントから PIM に呼び出しをルーティングするためにかけられる実時間が比較的短い場合、ルータの設定可能な時間を変更できます。 DOSコマンド ウィンドウのルータの 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 状態に入ることができません。 エージェントデスク設定を一致するために Desktop_Settings.cfg を設定するか ICM を、または変更しますエージェントデスク設定を設定します ICM を修正して下さい。

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

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

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

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

エージェントは準備状態に入れない

PRIVILEGE_VIOLATION_ON_SPECIFIED_DEVICE

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

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

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

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

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

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

エージェントはActive Call または Agent 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 ルートポイントは Cisco Unified CallManager で設定されません

ポストルーティングを使用するために Cisco Unified CallManager の「CTI ルートポイント」を設定し、ルート ポイントに望ましいディレクトリ番号によって行を割り当てて下さい(たとえば、"5000")。 エージェントに関してはポストルーティングに、使用しますダイヤル番号計画を呼出します。 Cisco Unified CallManager CTI ルートポイントにダイヤルするエージェントは CTI デスクトップ版 4.1.9 の IPCC ソフトフォンを混同します。

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

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

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

alternateが機能しない

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

コンファレンスへの参加を許可されたパーティーはほかのパーティーにコンファレンスできない

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

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

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

エージェントデスク設定では、ない 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 Unified CallManager によってもはや諮問、「任意」転送とみなされません。 Cisco Unified CallManager に任意 の 転送に問題があります。 転送を再接続するか、または完了するためにユーザを時諮問コールで制限して下さい。

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

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

VRU への変換ルートが機能しない

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

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

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

  • ルータは 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 ログがトランクグループ XにDNISが見つからないことを示す

要求手順は 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 間の設定 エラーを解決する方法をと IVR PG ポストルーティングおよび変換ルーティングのためのセットアップにおけるよくある問題が含まれています。 一般の IVR エラーに関する詳細については Cisco IP IVR トラブルシューティングガイドを参照して下さい。

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

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

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

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

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

  • IP IVR の VRU PG 一致 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 はスクリプトを見つけることができます。 リポジトリ 管理ツールが付いているアップロード スクリプト。

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

JTAPI ステータスが PARTIAL_SERVICE 状態である場合

これは一般に意味しますいくつかの IP IVR で設定される CTI ポートまたは CTI ルートポイントを Cisco Unified 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 Unified CallManager PG サービスを追加するときエンタープライズサービス リアルタイム レポート 10 はこのデータの特別な使用を作ります。 エンタープライズサービス リアルタイム レポートは VRU PG および Cisco Unified CallManager PG サービスが企業 サービスで報告目的のためにグループ化されることを必要とします。

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

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

VRU PIM は CSTA イベントを生成しません。 VRU ページ設定のサービス 制御レポートをつけて下さい。 これは 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)機能は別の終了レコードの生成なしで多分別のポスト ルートを生成します。

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

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

  • [Condition]: コール タイプは、サービス、まだスキル グループは論理的なマップと互いに設定されが、レポート完全に一致しません。

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

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

    • 最初のポスト ルートは Cisco Unified 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 Unified CallManager を解決して下さい

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  12. DC Directory のホテル プロファイルの IP を、Cisco Unified 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 のために有用な設定は特に次のとおりです:

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

    • サービス 制御– 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 Unified 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 Unified CallManager ログファイル

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

  • Ccm - CallManager SDI ログ。

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

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

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

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

IP IVR ログファイル

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

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

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

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

エージェントの数

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

使用されるゲートウェイ

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

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

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

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

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

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

IVR タイプ

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

プラットフォーム

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

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

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


関連情報


Document ID: 23843