Ring Group - Prioritized Hunt not working

[Glenn_Coltek]

We have a Azure hosted 3CX PBX running Version 18.0 update 2 (Build 307)

I have setup a Ring Group with 5 extensions
The Ring Strategy is set to Prioritized hunt.

The problem is that the calls coming in to that group are always going to the one extension and not distributing to the other extensions.
I have tried moving the order of the extensions around but it is having no effect

What can i do to resolve this?

 

[leejor]

How long is the ring time, for each member?

 

[Glenn_Coltek]

They are set to 10 seconds ring time

 

[Saqqara]

Check the following rules for each status - make sure 'Accept calls from ring groups'



Does one of the extension have forward to mobile, if so remove this setting


Check the activity log to see call flow

 

[Glenn_Coltek]

i have checked on all the extensions in the group and all are set as that

 

[NickD_3CX]

If you call the 803 Ring Group from another Extension, what happens? Again only 1 extension of the 5 rings?

 

[leejor]

Are the sets behind an SBC, or using STUN?

Have you looked at the Activity Log, to see if here are any clues, as to what might be happening if/when the call attempts to proceed to the next extension?

 

[bevans]

Hi there peeps,

using 3cx for over 12 months with no issues and like the product. Since upgrading to V18 I have found ring groups no longer work properly. They do not ring correctly on hunt and also do not send the call to the nominated voicemail extension once the elapsed time has been reached.

The ring groups worked perfectly on the v16 release.

How do I raise a defect or critical issue with 3cx for this problem.

 

[NickD_3CX]

Hi there peeps,

using 3cx for over 12 months with no issues and like the product. Since upgrading to V18 I have found ring groups no longer work properly. They do not ring correctly on hunt and also do not send the call to the nominated voicemail extension once the elapsed time has been reached.

The ring groups worked perfectly on the v16 release.

How do I raise a defect or critical issue with 3cx for this problem.

Hi!

So far there have been no proven issues found with Ring Group polling, as far as I remember it has always come down to some settings or configuration.

Raising a bug requires troubleshooting from the 3CX Support Department, and that can be reached via a 3CX Partner. If you have a Partner from whom you got the system from, I would suggest talking with them. If not, you can find a Partner via the link I provided.

What we can do here in the forum, is maybe help if there is some misconfiguration. Could you explain in a bit more detail how exactly you have it set up and what isn't working?

Also provide the information mentioned here:
https://www.3cx.com/community/threads/information-to-provide-when-requesting-help.67558/

Also ensure that you get the same "wrong" behavior when calling into your Ring Group from another Extension, not only from an External Number.

 

[bevans]

Thank you for your reply. It is interesting there haven't been any reported issues so I have got to thinking. There have been zero changes to any configuration of ring groups between V16 and V18 meaning the configuration running on V18 is the same as V16. Allow me to review the documentation on the links but no change.

 

[bevans]

Thank you for your reply. It is interesting there haven't been any reported issues so I have got to thinking. There have been zero changes to any configuration of ring groups between V16 and V18 meaning the configuration running on V18 is the same as V16. Allow me to review the documentation on the links but no change.

Further, I changed the ring type to RingAll on the ring group and viola it works fine. Only an issue with Hunt.

 

[NickD_3CX]

Further, I changed the ring type to RingAll on the ring group and viola it works fine. Only an issue with Hunt.

This is an interesting piece of information, but we would still need all the other info that I mentioned to get a better idea of what is going on.
If you are OK with switching to "Ring All" of course, I suppose that does solves the issue for you.

 

[NickEmpireComm]

This is an interesting piece of information, but we would still need all the other info that I mentioned to get a better idea of what is going on.
If you are OK with switching to "Ring All" of course, I suppose that does solves the issue for you.

I have a customer of ours experiencing a similar issue, but it started on V16 and upgrading to V18 (required to get support now) made no change.

If the first user is on the phone, or DND the call follows the prioritised hunt without issue. However If the 1st user doesn't answer the call and it overflows to the next user in line and they answer the call, it drops. The call logs show "no answer" as the call result and there is nothing in the event/activity logs that indicate a problem.

All users are using Yealink desktop phones and are behind an SBC

 

[NickEmpireComm]

I have a customer of ours experiencing a similar issue, but it started on V16 and upgrading to V18 (required to get support now) made no change.

If the first user is on the phone, or DND the call follows the prioritised hunt without issue. However If the 1st user doesn't answer the call and it overflows to the next user in line and they answer the call, it drops. The call logs show "no answer" as the call result and there is nothing in the event/activity logs that indicate a problem.

All users are using Yealink desktop phones and are behind an SBC

I actually may have solved this, at least for myself.

Not only do we provide a hosted 3CX service (we host it ourselves) but we are also the VoIP SIP Trunk provider. Our inbound dialer time out to the 3CX instance was too short and thus causing the call to "drop" after 20 seconds.

I made a change to increase the timer to allow for 15 second rings per user (7 in total). This resolved the issue and allows the call to roll over to the following users.

I suggest consulting with your service provider to ensure they are allowing enough rings on the inbound call for the call to be able to hunt through all the users before reaching its final destination.