1.4.25 Queue Agent Status incorrect on outbound calls

Hi All,

Having an issue upgrading from 1.4.20 to 1.4.25 (and 26 apparently). On inbound queue calls, “show queues” correctly shows agents as “in use” when they take the call. However, if the agent makes an outbound call the agent status incorrectly says that they are available, and thus receive inbound calls even if ringinuse is set to no.

This is true even for internal calls to a parking space. Say for instance an agent takes a call and then parks the caller to do a little research. Research done, he now picks the caller back up off of park. He now shows as “Available” and will receive inbound queue calls.

1.4.20 does not seem to have the same issue, but 1.4.25 and 1.4.26 do. I have crawled digiums bug site to no avail, so Im wondering if anyone else is having this issue. Cant seem to think of a setting that would control this behavior, but am more than willing to accept that it might be something I have done wrong here.

Any suggestions ?


Do you mean chan_agent agents. If so you must be using AgentCalbackLogin, which is deprecated.

The preferred solution may not help, though, as device states don’t propagate through local channels, at least not for 1.4.x.

There have been quite a few issues raised on the issue tracker about monitoring device states in queues, however, I think your problem may be that you have not set proper call limits on the real phone behind the ageint.

Hi David,

Thanks for the quick reply! We actually abandoned AgentCallbackLogin about two years ago. All agents are now dynamic and use AddQueueMember to login from the dialplan, or the equivilant through the Manager Interface.

I did a little more looking, and found a couple of bug reports on bugs.digium.com. Issues # 12970 and 13481 seem to be relevant to what we are experiencing. It seems that this issue is present with both static and dynamic agents. I looks like the issue first cropped up in 1.4.21, which is why we were not experiencing it with 1.4.20. They have tried to backport the state_interface behavior from version 1.6 as of 1.4.23, but for some reason we are still experiencing the issue.