I am looking for clarity of the events that the CTI OS gives while performing the following scenario:
Agent 1 and Agent 2 are logged in.
Agent 1 is in Not Ready state and Agent 2 is in a Ready State.
Agent 1 makes a call to Agent 2.
Agent 1 gets the following events:
The OnCallDelievered event is usually received by both the parties on a call. While this CallStatus value in this event for the Calling party is INITIATE, the CallStatus value in this event for the Called party is ALERTING.
In an almost similar scenario where:
Agent 1 is Logged in
Agent 1 is in a Not Ready state.
Agent 1 makes a call to an extension, in which there is no agent logged in.
Agent 1 gets the following events:
The OnCallDelivered event is not received by Agent 1, even though the extension to which the call was made is ringing. This event is supposed to be received by both the parties. Since there is no agent logged into the extension, I understand it as a matter of factly that there will be no events. But I do not understand why Agent 1 is not receiving this event.
This is CTI OS monitoring so. If the agent1 made a call to an non agent logged extension the oncalldelivered event will not be received. This is because the extension is not monitored or CTI OS has no intrest as no agent is logged on that xtn.
I understand that CTI OS will have no interest in the extension where agent is not logged in. But to take my explanation a little further where the extension answers the call, the agent 1 knows that the extension has answered the call because the CTI OS sends out an OnCallExtablished event. If what your are saying is to considered, then the CTI OS should not know whether the call on that extension has been answered or rejected. Nevertheless, the Agent 1 knows about these, except whenthe call is riniging on the extension.
this happens because by logging in on the extension you acquire JTAPI monitoring if you are on IPCC or third party control if on a TDM environment on that extension and the information is returned back to the agent, otherwise no event is returned from the JTAPI layer.
There might be a workaround in enabling the JTAPI.INI for network events as per this tech note:
I hope you were suggesting to the AllowNetworkEventsAfterOffered parameter in the JTAPI.ini file. I will surely give this oprion a try. However, I am writing a 3rd party call control application and my interface is solely with the ICM via CTI OS. I find it hard to understand why JTAPI related parameters needs to changed or modified and how is it related to the call control that I am doing via CTI OS.
when acquiring third party control the application will receive the events from the monitored objects/devices/agents via the path PIM->OPC->CTISVR->CTIOS hence why I was suggesting to modify the param you just mentioned, there is another issue though, sometimes the events are generated by the other party in a two party call, like in this case, so it is the called party reporting back the event back to CTIOS and not the ACD(in your case IPCC), as the ACD will report only the call established event.
This is the way it works when you build CTI integration, you need to check on the events you receive from the different layers and parties, I would refer you to the SDK Guide for more details.
As I am sure you might be aware, there is a Dev Support Program that helps with this sort of integrations for a limited fee and are extremely competent and responsive.
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...