Ring groups not working correctly after upgrading modules

After I ran fwconsole ma upgradeall, my ring groups stopped working properly.
I have a ring group set up with 4 extensions and strategy “firstnotonphone”.

What should happen is that the first available extension should ring for the set “Ring Time”, if there is no answer on that extension, the call should be routed to “Destination if no answer”.

After upgrading all modules, the ring group tries the first extension for the “Ring Time”, then the second, then the third, then the fourth, and then if no one answers, it routes to “Destination if no answer”.

I backed up the config off this server, and loaded it on a FreePBX server that hasn’t been updated for about a month and the ring group works as expected.

Both servers show Asterisk version 11.23.1. The difference in the ringgroups module is 13.0.21 -> 13.0.22.1.

Does anyone have any ideas how I can get this working correctly again?

You can rollback ringgroups. Keep in mind that ringgroups doesnt manage the dialing Core does. So I think you have a problem with Core.

Yup, just figured that out. I upgraded the only the ringgroups module on the older server and it still works fine. Then I did an upgradeall and it broke. I see a few new logs messages print out after the upgrade during the ring group processing. Is there anywhere I can search the source entire source base for the log messages?

These are the new log lines:
dialparties.agi: CW Ignore is: TRUE
dialparties.agi: CF Ignore is:
dialparties.agi: CW IN_USE/BUSY is: 1

Thanks!

the file you are looking for is clearly marked “dialparties.agi”. You don’t need to search anything

As far as I am aware what you say is broken is the correct way it’s suppose to function.

The problem with what you are saying is that multiple people said firstnotonphone was broken so we fixed it they agreed it was fixed. Now you are saying it’s broken. So either your functionality doesnt match up with theirs or vice-versa.

For more information see here: http://issues.freepbx.org/browse/FREEPBX-13726

Just took a look at: FREEPBX-13726.

I agree with what the reporter is describing how it should work. However, that is not what I’m seeing in core 13.0.118.6.

According to the documentation:
firstnotonphone: ring only the first channel which is not offhook - ignore CW

The new code changes in 13.0.118.1 are causing the ring group to ring all extensions in the list sequentially. With firstnotonphone set, it should only ring the first extension that is not busy. If that extension does not answer, it should then redirect to the failover destination. It should not try to ring other extensions in the ring group.

It looks like this is the change that stopped it from working:

Without that change, it still works correctly (according to the request in FREEPBX-13726) by ringing the first available extension.

I’m not sure why those lines were commented out. The previous logic makes sense to me:
Previous logic:

If the first extension rings and there is no answer:
    if(RingGroupMethod == firstavailable || RingGroupMethod == firstnotonphone) && DialStatus != BUSY)
    {
        HuntMembers = 0;
    }
        HuntMembers = HuntMembers - 1;
...

New logic:
If the first extension rings and there is no answer:

HuntMembers = HuntMembers - 1;
...

Logs before change:

  == Spawn extension (from-internal, 100, 1) exited non-zero on 'SIP/101-0000005b'
-- SIP/101-0000005b Internal Gosub(func-apply-sipheaders,s,1) complete GOSUB_RETVAL=
-- Called SIP/101
-- SIP/101-0000005b is ringing
-- Nobody picked up in 15000 ms
-- Executing [[email protected]:49] GotoIf("SIP/851-0000005a", "0?ANSWER,1") in new stack
-- Executing [[email protected]:50] Set("SIP/851-0000005a", "HuntLoop=1") in new stack
-- Executing [[email protected]:51] GotoIf("SIP/851-0000005a", "0?a46") in new stack
-- Executing [[email protected]:52] Set("SIP/851-0000005a", "HuntMembers=0") in new stack
-- Executing [[email protected]:53] Set("SIP/851-0000005a", "HuntMembers=-1") in new stack
-- Executing [[email protected]:54] Goto("SIP/851-0000005a", "s,a22") in new stack
-- Goto (macro-dial,s,27)
-- Executing [[email protected]:27] GotoIf("SIP/851-0000005a", "0?a30") in new stack
-- Executing [[email protected]:28] NoOp("SIP/851-0000005a", "Returning as there are no members left in the hunt group to ring") in new stack

Logs after change:

  == Spawn extension (from-internal, 100, 1) exited non-zero on 'SIP/101-00000363'
-- SIP/101-00000363 Internal Gosub(func-apply-sipheaders,s,1) complete GOSUB_RETVAL=
-- Called SIP/101
-- SIP/101-00000363 is ringing
-- Nobody picked up in 15000 ms
-- Executing [[email protected]:49] GotoIf("SIP/Flowroute-00000362", "0?ANSWER,1") in new stack
-- Executing [[email protected]:50] Set("SIP/Flowroute-00000362", "HuntLoop=1") in new stack
-- Executing [[email protected]:51] Set("SIP/Flowroute-00000362", "HuntMembers=3") in new stack
-- Executing [[email protected]:52] Goto("SIP/Flowroute-00000362", "s,a22") in new stack
-- Goto (macro-dial,s,27)
-- Executing [[email protected]:27] GotoIf("SIP/Flowroute-00000362", "1?a30") in new stack
-- Goto (macro-dial,s,30)
-- Executing [[email protected]:30] Set("SIP/Flowroute-00000362", "HuntMember=HuntMember1") in new stack
-- Executing [[email protected]:31] GotoIf("SIP/Flowroute-00000362", "1?a32:a35") in new stack
-- Goto (macro-dial,s,32)
-- Executing [[email protected]:32] Set("SIP/Flowroute-00000362", "CT_EXTEN=102") in new stack
-- Executing [[email protected]:33] Set("SIP/Flowroute-00000362", "EXTTOCALL=102") in new stack
-- Executing [[email protected]:34] Set("SIP/Flowroute-00000362", "DB(CALLTRACE/102)=+13154404665") in new stack
-- Executing [[email protected]:35] Goto("SIP/Flowroute-00000362", "s,huntstart") in new stack
-- Goto (macro-dial,s,44)
-- Executing [[email protected]:44] NoOp("SIP/Flowroute-00000362", "Hunt Dial Start") in new stack

Unfortunately for you it works. For others it doesn’t and this all depends on setup and devices being used. This is a problem with PJSIP devices and hint combinations with how extension state works. Undoing that commit will break things in a different way, especially if you are using PJSIP devices.

Most of the time changes are done for complex reasons and a vast array of changes or devices. Relying on extension_state no longer works properly in dialparties.agi

I am using Chan_SIP extensions. Can a setting be added somewhere in Advanced Settings to work around this? Can you check the extension type in dialparties.agi? Could this be a difference between Asterisk 11 and 13? I am using Asterisk 11 and the other user is using Asterisk 13.

It’s causing a ton of problems for a client of mine and I’m not sure what to do to get them working again. The change may have fixed some problems for some people but it also created a lot of problems for other people. There’s no way to tell who it’s hurting more.

I completely understand that changes are made for complex reasons, but that doesn’t mean that we shouldn’t try to find a solution that works for everyone. I am more than willing to help investigate, test, or even provide patches to get this working.

At this point, although it may work for some people, it seems like the functionality of firstnotonphone is broken.

Please let me know how we should proceed with trying to fix this for every use case.

Is there an easy way downgrade the core module as a temporary solution?

No. What about people who use PJSIP and Chan_SIP at the same time.

We already do this

No. I already stated the issue

Never said we weren’t providing a fix. In fact I reopened the old ticket

Use module rollback as originally stated here:

So checking if extension type is PJSIP, execute new logic and if Chan_SIP execute old logic won’t work?

Sorry, just realized that. I saw that the ticket was closed/dupe’d to the old one and I thought that was it. Thanks for re-opening.

I’d be more than happy to help find a solution to this if you guys need any help.

Thanks!

Not from initial testing.

The problem is that a PJSIP extension will report to extension_state that it’s online because of how the hint is generated even if the phone is offline. Then when using “firstnotonphone” the call will immediately die because it will call the offline extension. That is what has to be fixed.

in the file macro-dial.php in core/functions.inc

Replace this

//$ext->add($c,$s,'', new ext_gotoif('$[$[$["foo${RingGroupMethod}" != "foofirstavailable"] & $["foo${RingGroupMethod}" != "foofirstnotonphone"]] | $["foo${DialStatus}" = "fooBUSY"]]', 'a46'));
//$ext->add($c,$s,'', new ext_set('HuntMembers', (string) '0')); // String zeros.

with this

$ext->add($c,$s,'', new ext_gotoif('$[$["${RingGroupMethod}" = "firstavailable"] | $["${RingGroupMethod}" = "firstnotonphone"]] & $[$["${DIALSTATUS}" != "CHANUNAVAIL"] & $["${DIALSTATUS}" != "CONGESTION"]]', 'huntreset', 'a46'));
$ext->add($c,$s,'huntreset', new ext_set('HuntMembers', (string) '1')); // String zeros.

Then reload. Then check

1 Like

That works for Chan_SIP!!

Do you want me to load a box with Asterisk 13 and PJSIP extensions and test it out as well?

Thanks!

If you want. We all have limited time so I understand if you can’t. I will check it on PJSIP probably tomorrow if you dont get to it. I wrote the above lines blindly, eg without Asterisk in front of me :slight_smile:

Well, I’ve spent hours dealing with the client and hot patching their system to get them up and running again today, so a few more minutes won’t hurt :slight_smile:.

Just finished testing every configuration, here are the results:

Ring group strategy: firstnotonphone

Results (same for Asterisk 11 [Chan_SIP], Asterisk 13 [PJSIP], and Asterisk 13 [Chan_SIP]):
core-13.0.118.6:

  • If first extension is off-hook, routes call to second extension in ring group, if second extension does not answer, continues through sequentially ringing all extensions in group
  • If first extension is not off-hook but does not pick up, routes call to next extension in ring group, continues through sequentially ringing all extensions in group

core-13.0.118.6 (patched):

  • If first extension is off-hook, routes call to second extension in ring group, if second extension does not answer, routes call to failover destination
  • If first extension is not off-hook but does not pick up, routes call to failover destination

Changes look good to me.
Let me know if you need anything else.

2 Likes

Wow thanks! I will release a 13.0.118.10 into edge with these fixes and let you know.

Core v13.0.118.10 is now in edge

1 Like