Logging verbose call data to 'full' log not working

Normally when I make a call from a FreePBX system, I see some log data like this in ‘full’:

[2018-05-12 09:32:28] VERBOSE[15768] pbx_variables.c: Setting global variable ‘SIPDOMAIN’ to ‘10.8.0.1’
[2018-05-12 09:32:28] VERBOSE[15768] netsock2.c: Using SIP RTP Audio TOS bits 184
[2018-05-12 09:32:28] VERBOSE[15768] netsock2.c: Using SIP RTP Audio TOS bits 184 in TCLASS field.
[2018-05-12 09:32:28] VERBOSE[15768] netsock2.c: Using SIP RTP Audio CoS mark 5
[2018-05-12 09:32:28] VERBOSE[30735][C-00000422] pbx.c: Executing [900@from-internal:1] Macro(“PJSIP/804-00000183”, “user-callerid,”) in new stack
[2018-05-12 09:32:28] VERBOSE[30735][C-00000422] pbx.c: Executing [s@macro-user-callerid:1] Set(“PJSIP/804-00000183”, “TOUCH_MONITOR=1526135548.27887”) in new stack
[2018-05-12 09:32:28] VERBOSE[30735][C-00000422] pbx.c: Executing [s@macro-user-callerid:2] Set(“PJSIP/804-00000183”, “AMPUSER=804”) in new stack
[2018-05-12 09:32:28] VERBOSE[30735][C-00000422] pbx.c: Executing [s@macro-user-callerid:3] GotoIf(“PJSIP/804-00000183”, “0?report”) in new stack
[2018-05-12 09:32:28] VERBOSE[30735][C-00000422] pbx.c: Executing [s@macro-user-callerid:4] ExecIf(“PJSIP/804-00000183”, “1?Set(REALCALLERIDNUM=804)”) in new stack

When i make a call in this particular FreePBX system, I get none of that. Verbose logging is turned on, but I see nothing on either the console or in the full log. I can see warnings, errors, security stuff, notices… but I think that’s it. In asterisk logfile settings everything is turned on for the full log.

How can I repair this?

asterisk conf files have these settings for channels (logger*.conf):
console => debug,dtmf,error,fax,notice,warning
errors => error,notice,warning
full => debug,dtmf,error,fax,notice,warning
fail2ban => notice,warning,security

After I looked at this file, I went back into log file settings, and ‘verbose’ was now set to off instead of on, so something got desync’d regarding the freepbx database and the config files; not sure what caused them to get back in sync. I’d been digging around at this for some hours off and on, trying to resolve an issue with an IAX2 trunk (getting cause code 50, but that’s not really relevant).

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