Calls incorrectly handled when using multiple ring groups

[[email protected]]

I think I've found a bug in the 15.5 build of 3cx. We often use ring groups to catch unanswered calls and this has always worked in the past but now we're getting some very strange behavior in the full 15.5 release.

Example config:
* Call comes into extension 1234
* Call is unanswered for 12 seconds and is forwarded to ring group 9001
* If call is unanswered by RG 9001 for 12 seconds go to extension 1234 voicemail

This has worked since we first started using 3CX (v14)

Currently what happens is:
* Call comes into extension 1234
* If call is unanswered for 12 seconds, forward to ring group 9001
* All lines on RG9001 ring for a split second and then *one* of the extensions in the ring group show as connected on the "current calls" window and that extension shows as active. This is despite no one having answered that call and the phone of the extension in question showing no activity at all. The calling party hears ringback until the "ghost" connection happens and then it's just dead audio (but connected).

This is a huge issue for us. I've tried recreating ring groups and restarting services/servers and it works consistently whenever you forward to a ring group. Inbound DIDs that route directly to a ring group work correctly until they are forwarded to a different ring group and then they have the same behavior.

 

[SECOIT GmbH]

Is it always the same extension that "answers" the call? If so, can you remove it from the ring group and see if the issue persists with the other extensions in the group?

 

[[email protected]]

It appears to always "answer" the call with the same extension (per ring group). I tried your suggestion and it just grabbed a different number from the ring group to "answer" however.

 

[leejor]

What type (make/model) of "sets" are you using? All the same, or a mix of types? Just wondering if there is a set option that is causing the "answer".

 

[[email protected]]

All are Yealink T48G although we are on a few firmware versions. Again, this config has run for quite a while over different versions of 3CX, this seems just to have started with the latest (full) 15.5 release.

 

[SECOIT GmbH]

ooh... just tried to reproduce it out of curiosity.
Do you feel better when I tell you most of my officially supported phones don't work at all in Ring Groups?
I hardly ever use Ring Groups so I haven't noticed before. Will need to dig a bit deeper...

 

[[email protected]]

Did you get the same behavior? We leverage ring groups extensively because we came from a "shared lines" environment (Cisco) and our users still wish they had shared lines. :'(

 

[SECOIT GmbH]

Not the same behaviour that you described unfortunatly.
Mine won't answer and they won't even ring. On my Debian 3CX 15.5 most of my phones behave if they were not existing in the group.
All of them work fine in Call Queues though.

 

[leejor]

Did you check this option? http://support.yealink.com/faq/faqInfo?id=537

 

[[email protected]]

Auto answer is disabled on all phones. Ring groups work correctly if they are the first link in the chain as well (we have several DIDs that hit a ring group first before being escalated to a larger ring group).

 

[leejor]

For 3CX to "see" an answer, it must be receiving a SIP message back from that set. So... some combination of events/options seems to be incorrectly triggering that.

 

[[email protected]]

Wouldn't the handset show the call as answered if that were the case?

 

[SECOIT GmbH]

Hey Chris,
Sorry for the confusion, I found the error in the meantime which in fact was caused by a rather tall human sitting at my PC all day.

Anyway, to your issue, I set up the exact same scenario (only using different numbers) but it works exactly as extended. I can't reproduce the error. All working fine here.

 

[[email protected]]

Well it looks like I found a fix, but it's stupid. I have to go into each existing ring group and remove one extension. Save. Go into the same ring group and add that extension back in. Save. Then calls proceed normally as expected. Definitely seems like some kind of a bug or a change in how the internal database treats ring groups with the latest version. Hopefully this helps someone else who experiences the same issue.

 

[[email protected]]

Actually that fixes SOME ring groups... Others are still having the problem. This makes no sense...

 

[[email protected]]

OK, I've actually tracked it down now. It's related to the iOS 3CX client...

*If* a user in a ring group that is forwarded to, has the iOS 3CX client installed on their iPhone, the system THINKS that they have connected to the call when it hits the ring group. This is the case even if their iPhone still shows the "swipe to accept" screen (which does not go away).

Here's the thread in the iOS forum:
https://www.3cx.com/community/threads/ring-group-fails-with-extension-using-iphone-client.49347/