« Back to Cisco JTAPI Questions

Agent ready/not ready

Combination View Flat View Tree View
Threads [ Previous | Next ]
I have got UCCX instance configured to queue and distribute calls to common number to some number of agents in the call center.
As long as they use Cisco Agent Desktop which allows to mark an agent as busy/ready everything works ok.
We however have our custom application integrated with CCM using cisco JTAPI client (7.0.(1.1000)-1).
I'm trying to find a way to mark Agent (and thus the associated telephone number) as busy using JTAPI.
 
We have found that manipulating the state of the Agent object is the way to go. The problem is that we failed to obtain the object.
 
1. The Terminal implementations fails to cast to AgentTerminal (eclipse search tells that in the included jar no object actually implements it)
2. The CallCenter provider can be obtained javax.telephony.JtapiPeerFactory but methods throw not implemented exception.
 
Does it mean that Cisco JTAPI doesn't support the Agent side.
Is there some other way to controll agent state.

javax.telephony.callcenter package is not implemented/supported in Cisco JTAPI.

The provider returned by getProvider() is javax.telephony.Provider.



When a call is active on a address/terminal, application should logically treat the user/agent using the phone to be busy.



From: Cisco Developer Community Forums [mailto:cdicuser@developer.cisco.com]
Sent: Tuesday, June 30, 2009 3:19 AM
To: cdicuser@developer.cisco.com
Subject: New Message from Dominik Smogor in Cisco JTAPI (JTAPI) - Cisco JTAPI Questions: Agent ready/not ready



Dominik Smogor has created a new message in the forum "Cisco JTAPI Questions":
--------------------------------------------------------------
I have got UCCX instance configured to queue and distribute calls to common number to some number of agents in the call center.
As long as they use Cisco Agent Desktop which allows to mark an agent as busy/ready everything works ok.
We however have our custom application integrated with CCM using cisco JTAPI client (7.0.(1.1000)-1).
I'm trying to find a way to mark Agent (and thus the associated telephone number) as busy using JTAPI.

We have found that manipulating the state of the Agent object is the way to go. The problem is that we failed to obtain the object.

1. The Terminal implementations fails to cast to AgentTerminal (eclipse search tells that in the included jar no object actually implements it)
2. The CallCenter provider can be obtained javax.telephony.JtapiPeerFactory but methods throw not implemented exception.

Does it mean that Cisco JTAPI doesn't support the Agent side.
Is there some other way to controll agent state.
--
To respond to this post, please click the following link:
<http://developer.cisco.com/web/jtapi/forums/-/message_boards/message/1460998>
or simply reply to this email.

That's correct, Cisco JTAPI doesn't support/implement AgentTerminal. We
only support RoutingPackage ( RouteSession/RouteCallBack ) in
javax.telephony.CallCenter package. thx.



________________________________

From: Cisco Developer Community Forums
[mailto:cdicuser@developer.cisco.com]
Sent: Tuesday, June 30, 2009 3:19 AM
To: cdicuser@developer.cisco.com
Subject: New Message from Dominik Smogor in Cisco JTAPI (JTAPI) - Cisco
JTAPI Questions: Agent ready/not ready


Dominik Smogor has created a new message in the forum "Cisco JTAPI
Questions":
--------------------------------------------------------------
I have got UCCX instance configured to queue and distribute calls to
common number to some number of agents in the call center.
As long as they use Cisco Agent Desktop which allows to mark an agent as
busy/ready everything works ok.
We however have our custom application integrated with CCM using cisco
JTAPI client (7.0.(1.1000)-1).
I'm trying to find a way to mark Agent (and thus the associated
telephone number) as busy using JTAPI.

We have found that manipulating the state of the Agent object is the way
to go. The problem is that we failed to obtain the object.

1. The Terminal implementations fails to cast to AgentTerminal (eclipse
search tells that in the included jar no object actually implements it)
2. The CallCenter provider can be obtained
javax.telephony.JtapiPeerFactory but methods throw not implemented
exception.

Does it mean that Cisco JTAPI doesn't support the Agent side.
Is there some other way to controll agent state.
--
To respond to this post, please click the following link:
<http://developer.cisco.com/web/jtapi/forums/-/message_boards/message/14
60998>
or simply reply to this email.

Given what the previous posters said (I really hope one day we'll have a complete JTAPI 1.4 spec implementation from Cisco), there are alternatives you can look at. I'm not sure, but perhaps you can do something in a CRS script.. if so you could write a http trigger and use it to change the agent state.
 
If not, here's what we're already using productively: You can call the agent xml application from your own application with the proper parameters... sniff the connection between a phone and the CUCCX and note how status changes look like.. then replicate those http GET operations in your own application (and parse the result to catch any errors that might occur). We wrote our own agent application based on that principle (plus a http trigger to get the agent state which is shown as an CiscoIPPhoneStatus object on screen so agents always know their state even when they don't have the agent app on screen).
 
I also quickly looked at what the JSP pages (agent application on the phone) actually do, but I suspect that stuff only works on the server itself, and I feel very of using something unsupported and in a setup (you'd have to put your own application on Tomcat or put another Tomcat instance on the server - TAC will balk at both).. so we went the wrapper route.

Automation of the contact center stuff is certainly possible, via the IPCC CTIOS gateway APIs: http://developer.cisco.com/web/ctios/home
 
This interface should provide the ability to effect agent changes (ready/not-ready) among a host of other things, including (abstracted) call-control commands.