Question on Call Waiting and putting a call on hold

Tags: #<Tag:0x00007f7029bc68d0>

(Rage X1) #1


I currently have my FreePBX setup with time conditions -> ring group

The issue here is, when the extensions in the ring group are engaged with other calls, the next incoming call is still channeled to the extensions as call waiting, and if they are not picked up, the 2nd incoming call will be channeled to the default announcement for when nobody picks up their call (based on default settings).

What I want to do is, say the extensions are engaged with other calls, I would like to put the next incoming caller on hold instead (and play an on-hold announcement, agents are busy, etc), and transmit the 2nd call to the extension once they end their first call.

Is the only way to do this via queues? Thank you.

(Itzik) #2

Queues allows you to set skip busy.

(Jason) #3

This is a textbook definition of call queueing - allowing agents to take call when available and “lining up” all other calls. When an agent becomes available, the next call in line will be directed to that agent. While calls are waiting, you can specify messages and on-hold music.

This will definitely be your best way to do what you are looking for, as based on your description, queues will do this “out of the box”.


Thank you for your response.

I’ve tried to set up call queuing but I’m encountering quite a lot of problems.

Basically what I want to do is to queue calls only when the extension is busy. However, there is the possibility that the person is not at the desk, and if say after ringing for 20s (not engaged), I want the call to be pushed to failover.

What happens here is that say the person is not at the desk, and after ringing for 20s, the caller gets put back into the queue, and after retry timing (2s here), it flutily rings the extension again, and repeats, apparently until the max wait time is up.

If I put the setting at “no retry”, what happens is that if the agent is engaged, the next caller is not even put into queue and goes straight to failover.

Is there a way to change this behaviour such that specifically when the person is not at the desk, say after ringing for 20s (not engaged), the call will be automatically pushed to failover instead of being pushed back into the queue?

(Itzik) #5

Set them up as dynamic agents, have them log off from the queue when they arw away and set Join Empty = No, Leave Empty = Yes.

(Rage X1) #6

Is there any way to do it without setting up dynamic agents? These aren’t dedicated call center staff and they will definitely forget to log in / log off on occasion, so I’d rather have it set up in a manner that does not require two manual interventions everyday.

(Jared Busch) #7

Don’t use a Queue. Use a ring group?

Or use a queue and enable auto pause of your agents.

Of course there is no built in auto unpause…

You can make a BLF on their phone that is red when they are paused. to let them know to unpause. But since you already say that they cannot log in and out…
You can get around that with a sledgehammer.
Cron a script to unpause at whatever interval you want.

set -e 

rasterisk -x "queue show ${1}" | grep paused | grep -o Local.*/n | while read -r member
    rasterisk -x "queue unpause member ${member} queue ${1}"

Assuming that is saved as call it with the queue number as a parameter.

./ 150

(Rage X1) #8

I am currently using a ring group, and as stated in my original post, the issue I am trying to address is incoming calls when my agent is already engaged on the line.

The queue system appears to be ideal but the implementation in the GUI does not seem to have a lot of nuance for specific situations. I don’t think I’m the only one looking for this particular type of functionality -> sending to queue only when agent is engaged -> if it rings the agent and times-out, don’t send back to queue but failover instead, seems logical and a common use-case

Thank you for sharing your solution that involves auto-pausing with the cron unpause. I’ve gone down the rabbit hole of such customizations before and I’m sure it will work nicely for now, but a couple of months from now some update may break something because of the custom code lol.