Macro-user-callerid is broken. Does not preserve accountcode

We are using FreePBX Distro 13.0.193 with all the latest updates and we are getting an error in
Macro-user-callerid when passing along the extension accountcode.

[2018-01-23 03:31:13] VERBOSE[22245][C-0002b192] pbx.c: Executing [[email protected]:15] NoOp(“Local/[email protected];2”, “Macro Depth is 1”) in new stack

[2018-01-23 03:31:13] VERBOSE[22245][C-0002b192] pbx.c: Executing [[email protected]:16] GotoIf(“Local/[email protected];2”, “1?report2:macroerror”) in new stack

…[2018-01-23 03:31:13] VERBOSE[22245][C-0002b192] pbx.c: Executing [[email protected]:3] ExecIf(“Local/[email protected];2”, “0 ?Set(CDR(accountcode)=)”) in new stack

As you can see above the accountcode is not passed along in the 01/23/2018 log but in the past
the log for the SAME sequence of events was as follows below:

[2018-01-16 10:29:55] VERBOSE[23398][C-000280ff] pbx.c: Executing [[email protected]:15] GotoIf(“Local/[email protected];2”, “1?continue”) in new stack

[2018-01-16 10:29:55] VERBOSE[23398][C-000280ff] pbx_builtins.c: Goto (macro-user-callerid,s,29)

… [2018-01-16 10:29:55] VERBOSE[23398][C-000280ff] pbx.c: Executing [[email protected]:3] ExecIf(“Local/[email protected];2”, “1 ?Set(CDR(accountcode)=xxxxxxxxxxxx)”) in new stack

This has always been the case. You need to install the module “Preserve Accountcode”

This module preservers the first callee’s account code, that has an accountcode, that it encounters. This preserved accoutcode will be used to set the CDR(accountcode) for any outbound calls that result from any type of redirected call (CF, VmX, Follow-Me, etc.). The account code for each user is pulled out of their associated device settings, which means this is only supported in extension mode and would have to be updated for deviceanduser mode, requiring a new accountcode field to be defined for the user on the extension/user screen.

“Preserve Accountcode” is installed and enabled and was always installed and enabled. Nothing has changed on our side since 01/16/2018. Only difference is the module update we did on 01/19.
I can PM you the full call flow log for both dates. (about 100 lines)

The core module has not changed in this specific area you list in a long time.

You can always rollback core. If it works after a rollback let us know

(macro-user-callerid was last modified September 14th 2017. https://github.com/FreePBX/core/blob/release/13.0/functions.inc/macro-user-callerid.php)

We didn’t update modules for about 3 months so issue could have been introduced a while ago. What about the “report2:macroerror” in my third paragraph?

You’ve taken out several key parts of the dialplan. I am not going to attempt to debug what limited results you have given.

What you should do is this (in asterisk):

PBX A:

dialplan show macro-user-callerid

PBX B

dialplan show macro-user-callerid

Also you can rollback like I originally stated. Also it’s going to “report2” (1?report2:macroerror)

It’s the same PBX with an old log and a new log so dialplan show macro-user-callerid won’t help but I will attempt the rollback. Can you point to a link with instructions?

Go to module admin, click “check online”. Go to core. Look in the previous tab. Select version. Roll back.

Also “macro-user-callerid” does not set “accountcode”

I won’t pretend to understand the syntax of the Macro but it looks to me like line 16 is skipping to report2 (line 18) and the accountcode lookup is in line 17.

[report]       15. Noop(Macro Depth is ${MACRO_DEPTH})       [pbx_config]
                   16. GotoIf($["${MACRO_DEPTH}" = "" | ${MACRO_DEPTH} < 6 ]?report2:macroerror) [pbx_config]
                    17. ExecIf($["${CALLEE_ACCOUNCODE}" = ""]?Set(__CALLEE_ACCOUNCODE=${DB(AMPUSER/${IF($["${MACRO_CONTEXT}"="macro-exten-vm"]?${ARG2}:${MACRO_EXTEN})}/accountcode)})) [pbx_config]
[report2]      18. GotoIf($[ "${ARG1}" = "SKIPTTL" | "${ARG1}" = "LIMIT" ]?continue) [pbx_config]

Then this would be an issue with the account code preserve module not macro-user-callerid.

When was that changed last? There are no dates in the changelog or rollback info.

Core was changed/modified there back in September. Account Code Preserve splices into the dialplan there in a strange way, however the error is not so much in Core as it is in Account Code Preserve and how it’s splicing. So in September.

A bug should be opened up against account code preserve

OK. I’ll do that later. Can I rollback Preserve Account Code to resolve this for now or would I have to rollback both core and preserve Account Code? Also how dangerous is this with a live system?

You’d have to roll back core to 13.0.120.13

https://issues.freepbx.org/browse/FREEPBX-16708

13.0.120.13 is not available for rollback . 16 or 10 ?

13.0.120.20
13.0.120.18
13.0.120.17
13.0.120.16
13.0.120.10

You’d have to choose 10

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.