Queue agent pause status from dial plan

I trying to implement a check agent pause feature in the dial plan.

Queue_member could work if I knew the Queue the agent was logged into, unfortunately most of the agent are dynamic agents and have multiple queues they can select from to log into.

DB was another thing to look at for /Queue/PersistentMembers/

The would appreciate any assistance on an alternative.

Interface names might follow a predictable pattern. In my setup the pattern is Local/<extension>@<context>, as I do some extra logic when dialing queue members, your might just be something like PJSIP/<endpoint name>.

If the pattern contains the members extension, you can construct it on the fly pretty easily.

But why would you check the agents pause status? What problem are you trying to solve? Perhaps there’s another way to archive your goal?

Thank you. I am leaving app_queue to deal with all the pause features with in a queue.

We have a contact center and when the agent pause in the Queues. Reception can still transfer calls to the agent direct extension. Agent then complain, they are receiving calls while on lunch for instance. Currently to get around it, the users are using the device DND functions and lately agent started abusing it.

I am trying to check pause status of an agent for Internal/Extension calls (In another gosub).

So if the agent is paused, their extension should be uncallable? Unusual setup. However, you COULD perhaps just add a prefix to the calls, then they are able to see the calls are not from the queue, but direct instead?

It’s also possible to setup a custom device state, that are synced to the agents queue status, when an agent call to login to the queue, you set their custom device as “INUSE” then when they go on pause you set it as “ONHOLD” and when they logout entirely, you set it to “IDLE”.

On a Snom phone with BLF keys setup for that device, you get a static light if the member is logged in, a blinking light if they are on pause, and no light if they are not logged in.

Some softphones can do the same.

With that the receptionist can just see the status, and avoid sending calls when paused.

Or you can give the queues a dialable extension, and have the member be in that queue. When they are on pause, and you send a call to their personal queue, the call will just wait, or move on, depending on your dialplan.

Thank you for the suggestions.

I can’t really do a prefix or variable as most cases agent pause using the AMI commands. If they pause using the dial plan it would have been a very simple fix.

I will do some more investigation. Currently thinking of using a AGI to call an AMI command to check the device status in a queue.
3de alternative is to capture the queue an agent is allocated too, allowing them to log on to the Queues and use that value in the dial plan to check the pause status.

I were thinking of a prefix in the caller ID presented to the called party, that would make it obvious what the source was. That, however, is only usable if the problem is the agent THINK the call is coming from the queue, despite being paused.

You could also use a custom device state mirroring the state of the extension in the queue. This will require you to update all the places you can pause and unpause yourself in the queue. You would use the DEVICE_STATE function to set and read the current state. This approach has the added benefit of allowing you to setup BLF buttons to display current state of a member.

This is, of course, under the assumption that NO user issues AMI commands directly, and that you have control of the middleware between the user and Asterisk. If you don’t have access to the middleware, you could use AMI events emitted when queue state is changed for an agent, to update the custom device.

But I still don’t understand what exactly you have to solve, having your pause status in the queue essentially work as a DND, makes no sense in most cases, and it might be easier to just make the users activate DND, and perhaps even do this instead of pausing.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.