Yes I have CRM integrated with CTI, the agent is not able to login from the CRM using the CTI integration. Thsi integration use JTAPI.
But using the CAD, the agent is able to login. I do not know why from the CAD is working and why from the CRM via the JTAPI does not work?
Does CAD use something else so it is able to login, while JTAPI use the CG1A and it is not able to login because of the error?
From the other side, I have a public network and private network on each IPCCE server of my solution, just before week I got a problem in private network due to the network switches, and it look like the error on the CG1A appears since that time, but I am not able to know why the private network effects on that process?
Just need to understand the nature of the work for CG1A ctisvr.
As I understand that CG1A ctisvr process is used for CTI clients that was created using the CTIOS SDK, while ctios server process is used for clients that need to login using the CAD (standalone, not SDK).
My error in the CG1A ctisvr process which is related to the CTIOS client created by the SDK and embeded in our CRM (ITS product).
The error was not existed before, it is new and appeared just after the network changes.
Well, I beleive it is related to network but I would like to unerstand why the error appears before even the client is trying to login? The error appears once the process lunched and started, so it look like the process is trying to do a kind of communication and it failed because of network issue. I can access the PG server that contains the CG1A stisvr using PC AnyWhere and I can ping it, because the public network icon is enabled and working fine, while the private network icon is not working (even if I enabled) and this status appeared after network change.
In other words, why CG1A ctisvr is using the private network? For what?
>As I understand that CG1A ctisvr process is used for CTI clients that was created using the CTIOS SDK, while ctios server process is used for clients that need to login using the CAD (standalone, not SDK).
The CTI server normalizes the event stream for all the PG types - so that a soft phone client of the CTI server can work on all supported switches: CUCM, Avaya, Nortel etc.
Before there was the CTI OS (CTI Object Server), there was just the CTI server. Some of the early clients just talked to the CTI Server, and some current implementations (like the AMC connector for SAP) still talk to the CTI server.
The CTI OS is a higher level abstraction of call control that sits above the CTI Server. The CTIOS client (Soft Phone) talks to this.
CAD also talks to the CTIOS, but this is a recent change (7.0) - CAD used to talk to the CTI Server.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...