Macro-record-enable exits early - not recording - reason ${AMPUSER} not set

Hi FreePBX Community,

I’m trying to work out why “Always On” for recording in/out from an extension is not working. I have followed the dialplan and it is because the 1st argument ${ARG1} is not defined (i.e. it is blank) - which exits.

-- Executing [[email protected]:1] NoOp("SIP/7888-00000006", "CUSTOM ALL ROUTES 0433331111") in new stack -- Executing [[email protected]:2] Set("SIP/7888-00000006", "MOHCLASS=default") in new stack -- Executing [[email protected]:3] Set("SIP/7888-00000006", "_NODEST=") in new stack -- Executing [[email protected]:4] Macro("SIP/7888-00000006", "record-enable,,OUT,") in new stack -- Executing [[email protected]:1] GotoIf("SIP/7888-00000006", "1?check") in new stack -- Goto (macro-record-enable,s,4) -- Executing [[email protected]:4] ExecIf("SIP/7888-00000006", "1?MacroExit()") in new stack

This is with FreePBX-2.9
For some reason, it used to work in v2.8

My 7888 extension has this in the asterisk database

/AMPUSER/7803/voicemail : default
/AMPUSER/7888/answermode : disabled
/AMPUSER/7888/cfringtimer : 0
/AMPUSER/7888/cidname : Softphone 7888
/AMPUSER/7888/cidnum : 7888
/AMPUSER/7888/concurrency_limit : 2
/AMPUSER/7888/device : 7888
/AMPUSER/7888/noanswer :
/AMPUSER/7888/outboundcid : 02XXXXXXXX
/AMPUSER/7888/password :
/AMPUSER/7888/queues/qnostate : usestate
/AMPUSER/7888/recording : out=Always|in=Always
/AMPUSER/7888/ringtimer : 0
/AMPUSER/7888/voicemail : default

I can happily give you more information - this happens on both 1.4 and 1.8 :frowning:

Cheers
Chris

Chris

FreePBX 2.9 is old and is not getting bug fixes anymore. Please test on 2.10 and if the problem still exist feel free to open a bug report.

Just a minor correction from Tony…

2.9 is still supported and does get bug fixes but only where we determine the bug fixes are critical since that is the release used by the more conservative people and we want to minimize changes.

In the case of call recording, it has been very problematic until we re-wrote it in 2.10 where it is MUCH more reliable and functional. As such, it is unlikely that we will make any fixes in this area to the 2.9 branch. Also … to my knowledge there was not any change between 2.8 and 2.9 in the recording code. If you have a comparison between 2.8 and 2.9 where it was working and is not anymore then we can have a closer look to see if a bug fix is warranted.

However, from looking at the above, the outbound dialplan looks like it is not standard so you must be using something custom or an old version of something like the custom context module or equivalent. It helps when you include the actual dialplan in a situation like that to see what it is trying to pass to the maco that is coming out blank. In that case, it would most likely be ${AMPUSER} which needs to have macro-user-callerid called to get it properly set or all sorts of other things will not work either. As such, it has nothing to do with call recording.

So … for future reference, add important information such as “I am using some sort of custom route.” Luckily there was a hint of that in the Noop above to go by :slight_smile:

As suggested, I removed the custom context stuff. FYI

;[outbound-allroutes-custom]
;exten = s,1,NoOp(CUSTOM s ALL ROUTES)
;exten = _X.,1,NoOp(CUSTOM ALL ROUTES ${EXTEN})

Going back to default dialplan, it executes the macro-user-callerid - which sets REALCALLERIDNUM and AMPUSER.
Without setting AMPUSER, record-enable exits.

So here’s a minor gotcha for custom dialplans.

-- Executing [[email protected]:1] Macro("SIP/7888-00000016", "user-callerid,LIMIT,") in new stack -- Executing [[email protected]:1] Set("SIP/7888-00000016", "AMPUSER=7888") in new stack -- Executing [[email protected]:2] GotoIf("SIP/7888-00000016", "0?report") in new stack -- Executing [[email protected]:3] ExecIf("SIP/7888-00000016", "1?Set(REALCALLERIDNUM=7888)") in new stack -- Executing [[email protected]:4] Set("SIP/7888-00000016", "AMPUSER=7888") in new stack -- Executing [[email protected]:5] Set("SIP/7888-00000016", "AMPUSERCIDNAME=Softphone 7888") in new stack -- Executing [[email protected]:6] GotoIf("SIP/7888-00000016", "0?report") in new stack -- Executing [[email protected]:7] Set("SIP/7888-00000016", "AMPUSERCID=7888") in new stack -- Executing [[email protected]:8] Set("SIP/7888-00000016", "CALLERID(all)="Softphone 7888" <7888>") in new stack -- Executing [[email protected]:9] GotoIf("SIP/7888-00000016", "0?limit") in new stack -- Executing [[email protected]:10] ExecIf("SIP/7888-00000016", "1?Set(GROUP(concurrency_limit)=7888)") in new stack -- Executing [[email protected]:11] GotoIf("SIP/7888-00000016", "1?continue") in new stack -- Goto (macro-user-callerid,s,24) -- Executing [[email protected]:24] Set("SIP/7888-00000016", "CALLERID(number)=7888") in new stack -- Executing [[email protected]:25] Set("SIP/7888-00000016", "CALLERID(name)=Softphone 7888") in new stack -- Executing [[email protected]:26] Set("SIP/7888-00000016", "CHANNEL(language)=en") in new stack -- Executing [[email protected]:2] Set("SIP/7888-00000016", "MOHCLASS=default") in new stack -- Executing [[email protected]:3] Set("SIP/7888-00000016", "_NODEST=") in new stack -- Executing [[email protected]:4] Macro("SIP/7888-00000016", "record-enable,7888,OUT,") in new stack -- Executing [[email protected]:1] GotoIf("SIP/7888-00000016", "1?check") in new stack -- Goto (macro-record-enable,s,4) -- Executing [[email protected]:4] ExecIf("SIP/7888-00000016", "0?MacroExit()") in new stack -- Executing [[email protected]:5] GotoIf("SIP/7888-00000016", "0?Group:OUT") in new stack -- Goto (macro-record-enable,s,14) -- Executing [[email protected]:14] GotoIf("SIP/7888-00000016", "0?IN") in new stack -- Executing [[email protected]:15] ExecIf("SIP/7888-00000016", "0?MacroExit()") in new stack -- Executing [[email protected]:16] Set("SIP/7888-00000016", "CALLFILENAME=OUT7888-20120420-110631-1334883991.22") in new stack

Cheers
Chris

Hi PL,

I hadn’t realised I had been experimenting with custom dialplans - happy to leave the NoOp in there all the time!

I appreciate how much time it cuts out of support for being notified about these things too :smiley:

Have a good weekend,
Chris