Agent can't Unpause after AutoPause if Queue caller is waiting

FreePBX Applications / Modules
1

I’ve set up Queues and have assigned static agents. AutoPause is selected for the Queue, and “AutoPause on Unavailable” is set to YES

In testing, I’ve found the following behavior:
• An agent that has been AutoPaused after not answering a Queue call cannot UnPause while a caller is waiting in the queue with no other message playing to them.
• When (star)46*EXT is entered (via a programmed BLF or via keypad) the UnPause message plays on the Agent’s extension, the BLF button goes from Red to Green, then, it immediately goes back to Red and the agent is paused again. (we are using Grandstream phones, but this behavior should be easy to duplicate on a Sangoma or other mfg’s phone by programming a BLF enabled button)

If any announcement is playing to the caller in the queue, such as
• “Your call is first in line” or,
• an IVR announcement offering the caller choices for VM, Operator, etc.,
… then, only during this period can the agent successfully use the programmed BLF to UnPause and then take the waiting call. (unfortunately, the Agent can’t hear what is going on in the Queue to know when the caller is hearing an announcement)

There is something interfering with the ability for agents to UnPause after being AutoPaused while there is a caller in queue AND there is no announcement playing to that caller. (such as Announce Position, or, an IVR menu announcement)

I’ve tried disabling MOH for the Queue, but the result is the same regardless of this setting. Still, cannot UnPause the agent unless an Announcement is interrupting the Queue Callers idle time in queue.

This should be easily duplicated by:
• setting up a queue,
• set a Static or Dynamic agent,
• set AutoPause to either of the YES options in Queues/Timing & Agent Options
• set Announce Position to YES in Queues/Caller Announcements and set the repeat timing for 30 seconds or so
• program a BLF on the agent’s phone for 47EXT to toggle Pause and monitor Pause status
• program the IVR for a number to reach the queue

Then,
• verify the agent is not paused,
• place a call into the queue and let the agent’s extension ring until it is paused
• let the Announce Position message play to the caller and then go into idle hold mode in queue
• try to UnPause the agent from their phone using the programmed BLF button, or by entering 46EXT on the key pad.

If yours works the same as mine, this will be unsuccessful

Then,
• wait for the Announce Position message to play, then try to unpause the agent while that message plays.

If yours works the same, this will result in successfully UnPausing the agent and the caller in queue ringing through to that agent’s extension.

Our version is:
PBX Firmware: 12.7.5-1902-3.sng7
PBX Service Pack: 1.0.0.0

Anyone else have or have solved this issue?

1 Like
2

Not saying it is, but it sounds like a bug.

Which version of Asterisk are you using?
Which version of queues are you using?

Can you post a call log?

3

Asterisk version 13.22.0

Can’t figure out where to look for Queue Module verson

I’ll have to look into how to make a call log

4

I have seen similar behavior, but when troubleshooting, the queue was never busy and I couldn’t figure it out.

Management decided to simply turn off the auto pause.

But what I suspected happening was that the agent was actually unpaused to the queue while still on the call to perform the unpause.

Thus the queue was pausing the agent again as they were unavailable.

I was testing with Yealink phones.

5

The weird part is how Unpause works as long as the Caller waiting in Queue is being played an announcement. The Agent Unpause is successful and the agent can now have the call ring their phone.

If they try to unpause during a time when the caller waiting is not being played an announcement, IVR or something other than default MOH/Ringing or whatever is set to run during idle time, the unpause cycles all the way through to Paused.

I’ve submitted a Bug Report as well.

6

Not really weird. Because while the caller is listening to the announcement, nothing is trying to be transferred in the short time that the agent is being marked available.

7

Then, it is only weird to me for expecting it to work correctly.

8

I didn’t say anything about it working correctly. I said it is not weird based on the current process.

Technically, when the caller is listening to a message, they are not available for immediate connection to an agent.

I never tested this in detail to know how Asterisk/FreePBX has chosen to work the logic for this process. It is entirely logical that until something sees the available agent and then interrupts the current announcement and sends the call back to the agent that the agent will sit there waiting.

This would hold true for a normal agent coming of a call just as much as an agent trying to come off pause.

How is that not correct?

Now what you are describing is an action that should work how you would expect. Likely, it in fact does, as I pointed out. The agent is 100% being unpaused, but then autopaused again immediately as they are unavailable when the system is trying to send a call to them.

I’m confident it is simply a matter of timing needing changed in the dialplan.

9

Still seems weird, to me, for any queue system to behave like this.

Consider my use of the term an observational opinion on my part rather than any complex technical application derived from dissecting one’s understanding of the intricacies of Asterisk. :wink:

10

I worked with Walter on the bug report. After providing everything asked for to determine the cause, eventually I received this:

" I’m being told that the best way to continue this is to open a support ticket, which is better to be done from your end, through: http://portal.sangoma.com/ (choose support). If that doesn’t work, https://support.sangoma.com/ is another way. There are some details you’ll need to provide to get the support ticket created, such as this system’s deployment id. Just be sure to reference this ticket.
Thanks,
-walter "

My response:

" I would think that the Autopause behavior being different between when the queue caller is on hold/idle and when they are being played an announcement would isolate this to the PBX/Asterisk parameters being different for each of those scenarios.

How ever it is being handled when the announcement is playing lets the *46 toggle remain in effect. When an announcement is not playing it seems to detect the agent as still being unavailable immediately after being unpaused and Autopause then Pauses the agent prior to making an attempt to ring the unpaused phone.

This sounds like there is an unaccounted for state in the code that processes the *46 function when a caller is in queue and no message is playing. It is detecting the extension as busy while the Pause toggle is completing when it should be waiting for that process to complete before it tries to ring the agent. There is a buffer period missing from the code that would allow the Pause Deactivated notification to complete before Autopause checks the extension availability.

Is there a specific setting that you are aware of where this disparity could be accounted for in configuration? If not, I doubt that Support will be able to help. "

… crickets

Nothing in the correspondence indicated opening the support ticket would be a no-expense proposition for me. I am left thinking that if they can’t find the bug, Sangoma’s fall back position is to get some support money from the customer before giving up completely.

The fact that there are a number of similar issues with Queue AutoPause functionality recorded by requests for help in the Community speaks to how this is a real problem. These go unanswered/unresolved in the Community, then, are locked so others affected by the same problem cannot post up further examples.

From what I’ve found while searching the community for answers, and then submitting a bug report, has led me to believe that Sangoma staff have no incentive to make the Queues AutoPause work as it should.

This is unfortunate. Particularly when their Support option is pricy enough to justify simply purchasing another PBX from a competitor for the cost of a few hours of Sangoma Support. Then, take the time to configure it in order to replace the PBXact with the buggy software. Hopefully, with a product that isn’t as buggy (though likely still built on Asterisk).

I’ll eventually take some time to work through the code and see if I can figure out what the difference is between how AutoPause is handled when a Queue caller is idle vs when they are being played an announcement. This difference is where the problem lies and a conscientious programmer would be looking there to find the answer. Instead, Sangoma policy seems to be to instruct their bug chaser to give up and send the customer to the paid support channel. Sounds like taking two steps back to me.

11

This seems to be spot on.

Whatever part of the code that prevents the agent from being available to take the queue call while the message is playing should also be applied to prevent the agent being available to take a call while the Pause Deactivated Toggle is in process. Thus preventing AutoPause undoing the *46 Toggle.

If I figure it out I’ll post the solution here, unless they lock the thread before then.

1 Like
12

You absolutely did not understand what I posted.

13

Thanks for going into such detail about what, specifically, it is that I wrote which you feel may be mistaken.

Snide comments are useless without something included that might help with the problem you identified in how your attempt at communication failed.

When you attempt to communicate and realize that the communication failed, you are the only one who can remedy it by trying to communicate the idea in a different way.

Or, you can blame the other person for your failed communication.

A poor craftsman always blames their tools.

2 Likes
14

I am seeing this issue too with a PBXact deployment.

15

None of this has anything to do with the process of the agent being available or not available while the announcement is playing to the caller.

It has, as I stated, everything to do with the fact that the pause toggle process is making the agent available to Asteirsk while the agent is still on a call (the call they are using to mark themselves available). So because they are on a call after being marked available, the queue process is automatically marking them unavailable again and pausing them.

This has nothing to do with the announcement. That is a red herring. The only reason it “works” during that time frame is because the queue process is not actively attempting to send a call to the person that is trying to mark themselves available during the few seconds that they are on the “unpause” call.

Here is the dial plan for the toggle, it resides in /etc/asterisk/extensions_additional.conf btw. You can clearly see that the dialplan is

  1. updating the Asterisk DB state to available/unavailable
  2. playing a message “pause” and “de-activated” or “activate”
  3. returning to where it was called or hanging up the call

The problem would likely go away for most users if the functions in items 1 and 2 were reversed.

[app-queue-pause-toggle]
include => app-queue-pause-toggle-custom
exten => s,1(start),Answer
exten => s,n,Wait(1)
exten => s,n,Macro(user-callerid,)
exten => s,n,Set(QUEUEUSER=${IF($[${LEN(${ARG2})}>0]?${ARG2}:${AMPUSER})})
exten => s,n,Set(MEMBR=Local/${QUEUEUSER}@from-queue/n)
exten => s,n,Set(PAUSE_STATE=${QUEUE_MEMBER(${ARG1},paused,${MEMBR})})
exten => s,n,Set(QUEUE_MEMBER(${ARG1},paused,${MEMBR})=${IF($[${PAUSE_STATE}]?0:1)})
exten => s,n,Playback(dictate/pause&${IF($[${PAUSE_STATE}]?de-activated:activated)})
exten => s,n,ExecIf($[${ARG2}]?Return())
exten => s,n,Macro(hangupcall,)

;--== end of [app-queue-pause-toggle] ==--;
16

Just want to raise a simple point here. The QUEUE_MEMBER function has no direct relation with a Queue. As in it is not going into the Queue or executing the Queue() application. It’s just setting/reading the member’s status/details.

So the Queue is not going to see this as an active call and think “I need to pause this member now” because the call completed. The Queue isn’t dealing with the call, its just a call into Asterisk like calling voicemail or any other feature code that does something (like DND toggle).

17

That function is not a call, but that function is initiated during a call. Thus the agent is becoming available while on a call that is not a queue call.

18

So you’re saying that I, as the member, call *46 to toggle myself from Paused to Available and during that 5 seconds I got a call from the Queue because it immediately sees me as available and then because I’m on a that call dialing *46 I am considered a “No Answer” and thus get paused again, creating a vicious cycle?

19

That is what I am saying. Also why it doesn’t trigger when the caller is hearing the announcement. Because the queue process is slower to interrupt the announcement and send the call.

20

Ahh, I generally just solve this by not calling agents that are IN_USE/BUSY. Then I’m not messing around with these types of races or callers being sent out to ring agents that are on the phone and then get pushed back into the queue.