Currently, we are invoking the cstaSetAgentState method in order to set various states for our agents (i.e. lunch, break, etc). I have debugged our code to ensure we are sending the correct reason code (e.g. lunch=4), however, it appears from our Call Management System, we are sending a 7. We do not have access to TSPY and was hoping if anyone had run into this issue. I am assuming this may have something to do with the private data created from call to AttV6SetAgentState. The private data is then used for cstaSetAgentState. I am not sure what I am missing. If anyone can provide suggestions, that would be greatly appreciated.

There are a couple of things that you can try which will help you to pin down the problem.

1. Follow the instructions in the Devconnect Product FAQ "What is the procedure for enabling and accessing the AE Services logs for TSAPI (trace, tracing, g3trace, csta_trace)?". It is in the "FAQ: AE Services TSAPI -> General" section. When you then call cstaSetAgentState(), you can see the actual message received by AE Services in the csta file.

2. Assuming AE Services is getting the correct reason code, you can perform a getAgentState() to check if the Communication Manager is reflecting the change. You can use the TSAPI Exerciser for this. If you do not have the TSAPI Exerciser, download the DMCC .Net SDK and use the DMCC Dashboard.

Don't forget that, if you cstaSetAgentState() during a call, you will have to set the pending flag to true and the reason code will not take effect until the call ends.

Also, make sure that there is no other application which also sets the reason code.

Martin