I am new to VitalPBX and trying to implement as many configurations as I can from previous PBX’s I’ve used into Vital, to see how well I can consolidate services. This particular issue was something that worked for me on 3CX with this particular client I migrated recently.
My current issue I would like some assistance with is the polling for phone availability in queues. I would like to have it so that if I’m on a call and another call comes in on a queue that I am logged in to, I can hang up and immediately have Vital acknowledge my extension is available again and start ringing me.
For Example; I receive a call on my Reception queue, and answer it on my phone (Ext101). Another call comes in on the queue, but the other users for that queue are not available. I can tell that Ext102 and Ext103 are receiving a call due to the BLF keys on my phone, but am not interrupted during my active call. Once I finish or redirect the call, I hang up the phone and the still-active pending call immediately comes through on my phone ready for me to answer.
Currently, I can only mimic the experience with low Member Ring Time and Retry Time on a longer Queue Ring Time, to have the phone system retry every member between ringtone cycles. This is not a valid solution as some clients have older staff who might not answer in time, or be thrown off by the pulsing-screen experienced with this setup.
I can also give them the desired access to incoming calls by enabling calls to busy extensions in Queues, or by making it a Ring Group, but this is also not a valid solution. The tone that plays during incoming calls is undesirable for reception staff or call centre personnel who need to focus on their current call and consistently have a higher call volume.
I believe this has to do with how Vital checks phone status and pushes out calls, as it only re-pings the phone to check status each time the Member Ring Time expires. I am also aware of configuring Pickup on the BLF keys for each phone, and I do have that configured, but that is more of a band-aid fix that doesn’t restore the functionality my Clients and I desire.
If someone could please advise on how to implement this properly, or how to make this a feature request, I would greatly appreciate it.
Remove call waiting from the member extensions in your queue and keep Enable Ring Busy Agents toggled on. The system should allow your member extension to pickup the call as soon as its not busy without having to wait for the member timeout to expire of that ring cycle.
Another (custom) solution would be to create the below dialplan in a custom file (i.e. /etc/asterisk/vitalpbx/extensions__90-custom.conf).
[queue-call-to-agents]
exten => _[1-9].,1,Noop(Custom queue call context)
same => n,GotoIf($[!"${QUEUE_NUMBER}"=~"803|802"]?end)
same => n,Set(COS=${DB(${TENANT}/extensions/${EXTEN}/context)})
same => n,WaitForCondition(#,#["#{EXTENSION_STATE(${EXTEN}@${COS})}"="NOT_INUSE"],,1)
same => n(end),GoSub(s,1(${EXTEN}))
Dialplan Breakdown
The context queue-call-to-agents is the default context for queue calls, I’m not sure if there’s an option to override that, but I couldn’t find one.
The extension pattern _[1-9]. will match any extension number (2 or more digits), and since it’s more specific than the one used in Vital’s dialplan, calls will be routed to this dialplan.
The GotoIf statement is there so you can specify which queues this custom dialplan applies to (in our example queues 802 and 803). Remove it if you want it to apply to all queues.
The WaitForCondition statement will check the dialed extensions EXTENSION_STATE every 1 second, and only continue when the extension is in the NOT_INUSE state.
The reason you might want to use this over disabling Call Waiting on the extension, is because this will still allow the agent to receive direct (non-queue) calls while they’re on the phone.
The downside with both solutions (and in general with enabling Ring Busy Agents) is that it’ll mess up your queue reports, as it will log a RINGNOANSWER event on the agent.
@hlev Thank you for the suggestion, However that doesn’t seem to work for me. Rather than allowing it to ring without notifying the extension, it seems that the extension “Call Waiting” setting overwrites the “Ring Busy Agents” setting to completely disallow the call. Both Extensions have the setting disabled under advanced, as per the image.
See below for configuration confirmation:
@EINM Thank you for explaining the custom context in such detail! I’m still a novice with Asterisk so I greatly appreciate the extrapolation, however I’d like to confirm some things before I add or try to implement the file as I am a little nervous about the possible repercussions.
To check if I understand custom config correctly:
Would I implement this via the Custom Contexts menu, with Extension set as 90 (As per /extensions__**90**-custom.conf) and the Context set as queue-call-to-agents as per the custom file.
Would I set the destination as Terminate Call | Hangup such that after the queue is over it ends, or would this need to be set up to go to the desired queue as the destination? If the latter, how would I go about this for tenants, as the custom contexts menu is not present under PBX>Applications for any of the Tenant systems?
My last nervous consideration is to confirm that saving this as suggested would not overwrite or immediately implement it over any of my other systems or change the way call flow works for queue’s for my Main system or other Tenants inadvertently.
@Nathaniel Something is not set properly in your queue if you are experiencing the system “disallowing” the call like you mention.
Can you check your cdr of the test calls to see exactly how its logging you queue retries. Here is the cdr for mine
External Call, dialed in at 11:49:49. Queue 13499 has members 1342 and 1343, as you can see at the time when the call reached the queue both extensions are busy, the cdr is clearly loggin a retry attempt to those extensions every 2 seconds, which is my retry value set in the queue. I hangup extension 1343 and at 11:49:57 the calls properly rings the extension and I am able to pickup the call. Both 1342 and 1343, have call waiting deactived like I mentioned in my original reply.
Member ring time is set quite high for this test, but as you can see in the cdr image above, the system is not waiting for the member ring time to expire to check the extension status, its using the retry value to check the member extension status in order to send calls to them again because we have the ring busy agents enabled.
No, you don’t need to create any custom context, you’ll need to connect to the PBX using SSH and create a file named extensions__90-custom.conf in the /etc/asterisk/vitalpbx directory, and paste the dialplan there.
You’ll need to create the dialplan for each tenant you need this feature on (they can all be in the same file).
Note: For tenants, you have to add the tenant prefix to the context name (i.e. T2_queue-call-to-agents for tenant 2), to find the tenant prefix run the following command from the console, replacing TENANT_PATH with the actual tenant path (can be found in the GUI) asterisk -x"database showkey prefix" | grep TENANT_PATH
Since the context name is tenant specific, it’ll only apply to the tenant who’s prefix you added to the context name.
As an overall guideline to help establish when each step occured, I left about a 10second window between each action performed for the test. For the first call “C”, I let it ring for 10.
“C” Ringing for 10 | Answered on 408 | 409 was marked as NoAns. | wait 10sec
“N” Call Started | 408 responded Busy | 409 started ringing | wait 10sec
“C” Call Terminated | 408 didn’t poll over the 10 sec | 409 ringing for 10sec | wait 10sec
“N” Ringing for 20 | 408 still not ringing | 409 ringing for 20 Sec | wait 10sec
“N” Ringing for 30 | 408 re-polled, started ringing | 409 re-polled, started ringing | wait 20sec
“N” Ringing for 50 | Answered on 408
As per example, 408 did not rejoin the poll for at least 20 seconds despite the 2 second retry timer, which is not the UX I am after. I’m not sure why this is still occurring if you are suggesting that it should be immediate, but that is what I experienced.
@EINM Thank you very much! I was intending to implement the file in the same way, but my misunderstanding was that for it to take effect I had to create a custom context and configure it via that.
I have tested this on our test system and observed the CDR on our clients’ system and the Call flow is functioning as requested. Once again, thank you for explaining the process and functions, it was very helpful to learn.
Asterisk will by default look for dialplan in /etc/asterisk/extensions.conf, and if you look in that file on any VitalPBX deployment, you’ll see that they include all files named extensions__*.conf located in the vitalpbx subdirectory.
The 90-custom is just a personal preference, you can put anything between the double underscore and the .conf, as long as it doesn’t match any of Vital’s file names
A quick note for anyone who looks back to this in the future that might be experiencing some trouble.
I have noticed after rolling out the custom config file to a client that it did not take effect initially - after my initial puzzlement I enabled “Ring Busy Agents” on the queue and the custom config worked as expected.
