We have an application that starts a peripheral monitor on an Agent Instrument and logs on the Agent if necessary. We prompt for Agent ID, Password and Instrument, just like the Agent Desktop. We are using Protocol v13.
 
When we issue the SET_AGENT_STATE_REQ message with state AGENT_STATE_LOGIN, if the Agent wasn't logged on everything works perfectly. If however the Agent is already logged on (to this instrument), then we get back a CF_SPECIFIED_AGENT_ALREADY_SIGNED_ON error code. We get this same code back whether the password specified is correct or not.
 
According to the document "Cisco Unified Contact Center Express CTI Protocol Developer Guide, Release 8.0(1) September 2010.pdf", in the section "Agent Authentication Without Agent State Change", you can authenticate an agent without affecting state by sending a SET_AGENT_STATE_REQ message, passing in the state AGENT_STATE_LOGIN, the Agent ID and Password, an AgentExtension of "unknown" and a ForcedFlag value of 2.
 
Well, there is no AgentExtension field in this message. I tried all this with "unknown" in the AgentInstrument field, and that didn't work. I tried the actual instrument number in the AgentInstrument field, and all I get back, again, is the CF_SPECIFIED_AGENT_ALREADY_SIGNED_ON error, regardless of whether a valid password is passed or not.
 
No matter what the ForceFlag value is, 0, 1, or 2, the same result happens. The Agent is logged on if he was not, and the call returns CF_SPECIFIED_AGENT_ALREADY_SIGNED_ON if he was already logged on, regardless of password supplied.
 
How can I validate the agent credentials when the Agent is already logged on? Surely I don't have to cache the passwords myself.
 
Thanks for any help...

 
Thanks for replying so quickly!
 
 
No, I haven't tried that.
 
Current Logic is:
 
1) MONITOR_START_REQ
2) MONITOR_START_CONF -> SET_AGENT_STATE_REQ (AGENT_STATE_LOGIN)
    a) SET_AGENT_STATE_CONF -> QUERY_DEVICE_INFO_REQ
or
    b) FAILURE_CONF (CF_SPECIFIED_AGENT_ALREADY_SIGNED_ON) -> SET_AGENT_STATE_REQ  (AGENT_STATE_LOGIN, ForcedFlag = 2)
 
Infinite loop.
 
Are you saying to check the agent state so that if they're already logged on I shouldn't call SET_AGENT_STATE_REQ with AGENT_STATE_LOGIN? If so, how do I validate the credentials?
Or, are you saying that doing a QUERY_AGENT_STATE_REQ before the SET_AGENT_STATE_REQ will somehow fix the server to return the correct result?

 
That's great, but I also want to validate the password even though the agent is already logged on. We prompt for credentials and don't want anybody to be able to steal an already-logged-in agent session unless they are that agent. How do I do that?
 
The Cisco Agent Desktop can do this, but I imagine that's because it's a dedicated client app and is using OPEN_REQ as the one agent it wants to control. We're a web-based server app monitoring multiple agents over one connection to the CTI server.
 

 
The document  "Cisco Unified Contact Center Express CTI Protocol Developer Guide, Release 8.0(1) September 2010.pdf" (in the section "Agent Authentication Without Agent State Change", page 5-5) specifically says you can do this, but the parameters it specifies (e.g. AgentExtension, Reserved) are not present in the SET_AGENT_STATE_REQ message.
 
The Cisco Agent Desktop can do this. If I log on as a particular agent on one computer and then run the Agent Desktop on another computer, I can log in again as the same agent via Agent Desktop and if I don't specify the correct password it rejects the login.
 
Therefore it is possible to do this, but the documentation is wrong. Is there any way to find out the correct way to do this?

 
That was the first thing I had tried. I get back CF_SPECIFIED_AGENT_ALREADY_SIGNED_ON regardless of whether I pass the correct password or a bogus one. Is there something special I need to put in any other parameter? I'm passing the PeripheralID, AGENT_STATE_LOGIN, AWM_UNSPECIFIED, NumSkillGroups=0, EventReasonCode=0, ForcedFlag=2, AgentServiceReq=0, AgentInstrument/ID/Password.

Thanks for investigating.
 
Bummer that this functionality isn't available, especially since it's documented that it is.
 
The documentation should be corrected, at least.