Hi,
I am trying to resolve an issue where calls are not being answered from a queue when the agent has acdAutoAnswer set to true. I can see the pending session log statement come in but it never answers.
When that pending session comes in, if autoAnswer is true, then we will automatically signal the server to proceed with sending a session. When that session comes in, we consult autoConnectSessions before we actually connect the session. That is provided in the config and should default to true so if you're not overriding that you should be fine there.
The next possibility is a race condition between multiple clients. If you are running purecloud or other instances of the webrtc-sdk, another client may be trying to answer that call.
Hi,
Thanks for coming back to me.
There is a chance that we have multiple clients but we the call is never answered by the original agent who is ringing and is then moved onto another agent on the queue. Would you expect the client that is racing to receive the call?
Just to clarify this is an intermittent issue, most of the time the agent is auto answered.
The next possibility is a race condition between multiple clients. If you are running purecloud or other instances of the webrtc-sdk, another client may be trying to answer that call.
@Darren_West As a side note, we've addressed the race condition issue, and it will be available in a future version of the SDK. If you are not using multiple clients then it won't be an issue.
What I meant was would you expect one of the other clients to be answered as the user is on auto answer because this does not happen. The calls goes back on the queue.
All clients for a given user would ring, and one of them should answer. If none of the clients for a given user answer, then it is likely you have encountered the race condition mentioned earlier.
As mentioned, the race condition has been fixed, but has not yet been released pending some other things that need to be implemented in the SDK as well.