Hardphones keep on ringing after update to V20

[Beuningen IT]

One of our customers is complaining that their Yealink (T53) hardphones keep on ringing, that is, when they're on the phone already, even after they cancel the incoming call since they upgraded to V20. How can I stop this behaviour? Accepting multiple calls is turned on and has to be kept on. How can I stop the incoming calls from the queue?

 

[TheodorosG_3CX]

Under your Queue configuration is the below option enabled?

 

[Beuningen IT]

No, that's option is turned off.

 

[TheodorosG_3CX]

Is this a Queue call or Ring Group call?

 

[Beuningen IT]

This is a queue call.

 

[JohnS_3CX]

Are you using STUN for your phones or are they all LAN/SBC?

 

[Beuningen IT]

Everything is in two different LAN’s (connected via site-to-site), no SBC’s.

 

[JohnS_3CX]

Describe the entire call flow, what path the call goes through until it reaches the queue, and where the destinations of the queue go when not answered.

Also check whether the same user is part of another queue or calls of another queue end up forwarded to this one.

 

[Beuningen IT]

Incoming call goes through a digital receptionist. Caller has four options to chose, all of them go to a call queue (801, 802, 803 and 804). All queues have a strategy of "ring all". If the queue doesn't get answered within 3600 seconds (highly unlikely) the call will end. However, all users (agents in the queue) are configured to forward unanswered calls after 30 seconds to their respective queue.

 

[JohnS_3CX]

However, all users (agents in the queue) are configured to forward unanswered calls after 30 seconds to their respective queue.

This is generally not a good idea, but we have tested it and in our case this is not happening when "Target agents already on a call" is turned off (the loop is blocked). Might be worth enabling the option, saving, and disabling it again just to confirm that the setting is applied.

But if this doesn't work, I suspect we are missing some information here. You will have to look a bit further whether other queues are also targeting the agent or if you are causing a loop elsewhere perhaps.

 

[SteveITS]

Yealink (T53) hardphones keep on ringing, that is, when they're on the phone already, even after they cancel the incoming call

How are they cancelling the call, on the Yealink or in another client?

 

[PhoneMan123]

Another thing to check under Advanced -> Parameters is SIP_FORKED_ID_BUSY.
"Available options 0 and 1. If set to 0, when one of the sip forked entities sends a busy signal, all invites to all participants are canceled at once. If set to 1, each participant must send a busy respectively. Other SiP Forked devices remain on target"

 

[Beuningen IT]

How are they cancelling the call, on the Yealink or in another client?

On the Yealink phone.

Another thing to check under Advanced -> Parameters is SIP_FORKED_ID_BUSY.
"Available options 0 and 1. If set to 0, when one of the sip forked entities sends a busy signal, all invites to all participants are canceled at once. If set to 1, each participant must send a busy respectively. Other SiP Forked devices remain on target"

I've changed that option which sometimes seem to work, but not always!

 

[Beuningen IT]

Alright, so a few things changed. Customer stated that the issues are also rising while they're using the PWA-app (webclient). I've added two videos (where I blurred out the phonenumbers) below so that you guys might understand a bit more what the actual issue is.

Sometimes they press once on "reject", sometimes two times, three, sometimes as much as seven or eight times. During that time, people are unable to initiate a new call.

 

[SteveITS]

Is it on phones/clients on both sites? Smells like a connectivity/routing/firewall issue to me.

 

[JohnS_3CX]

In the example they are not on a call, then a call comes in, they reject it, and it comes back again.

It's perfectly normal for a queue to call you again as soon as you reject a call, that is the intended behavior.

So long as you are still logged in and idle, you will be polled until all the queue is empty.

So I'm not very clear on what the issue is at the moment, if at all.

 

[Beuningen IT]

Is it on phones/clients on both sites? Smells like a connectivity/routing/firewall issue to me.

The problem is indeed on both sites (coincidentally both videos are from both sites). Sites are connected through IPsec via the UniFi UXG Pro firewalls/routers.

In the example they are not on a call, then a call comes in, they reject it, and it comes back again.

It's perfectly normal for a queue to call you again as soon as you reject a call, that is the intended behavior.

So long as you are still logged in and idle, you will be polled until all the queue is empty.

So I'm not very clear on what the issue is at the moment, if at all.

That's correct. I must have made an error in my first post. It's not only with queue calls. In the second video I literally called the employee through on his own DID. The question is, why do they have to cancel randomly between 2 and 10 times?

 

[JohnS_3CX]

That's correct. I must have made an error in my first post. It's not only with queue calls. In the second video I literally called the employee through on his own DID. The question is, why do they have to cancel randomly between 2 and 10 times?

I can only speculate here but it appears like a loop. You might have to look at full logs to understand this or open a case with support.

The best thing to do is capture on the PBX and see if it indeed fired 10 calls at you, and capture on the phone to see that it also received 10 calls. Just to confirm what you see is indeed real before you go down a UniFi ALG rabbit hole.

 

[Beuningen IT]

Thanks John, I've raised a ticket at 3CX support. I'll keep this topic updated in case anyone else has this issue as well in the (near) future.