Alert-Info Header (FreePBX 12.0.62 + Asterisk 13.2)


I did recently install Freepbx and everything works fine except distintive rings.
In the Incoming Gui pannel the Alert Field is filled with alert-external, the phone has the same setting but nothing happen.
I checked the ip packet with WireShark but I cannot see any header with the Alert-Info.
Any idea? Is it because Asterisk 13 use the new PJSIP instead of chan_sip?

Thank you


Yes its because I am sure we did not add support for that in PJSIP with FreePBX. Open a feature request. Please note Asterisk 13 with FreePBX is not considered production ready.

Hello Tony

I did report this in the Freepbx IRC. Andrew has opened a ticket: FREEPBX-8860 see

I have already made the changes at the macro-dial-one in extensions_additional.conf as he suggested but unfornuately the situation is not changed.

Tracing the comunication I still not see any header containing the Alert-Info

Note I am not a programmer…
Reading here and there I read that a Pre-Dial Handlers has to be created. Is it correct???

I see also that a great part of the Dialing is handled by dialparties.agi in which I see those raws:

$alertinfo = get_var( $AGI, “ALERT_INFO” );
if ($alertinfo) {
debug(“Setting Alert-Info: $alertinfo”, 4);

Thank you


Any Help on this topic… please

I have changed macro-dial-one as shown below but nothing happen:

exten => s,n(skiptrace),Set(D_OPTIONS=${IF($["${NODEST}"!="" & ${REGEX("(M[(]auto-blkvm[)])" ${ARG2})} != 1]?${ARG2}M(auto-blkvm):${ARG2})})
exten => s,n,ExecIf($["${ALERT_INFO}"!=""]?SIPAddHeader(Alert-Info: ${ALERT_INFO}))
exten => s,n,ExecIf($["${SIPADDHEADER}"!=""]?SIPAddHeader(${SIPADDHEADER}))
exten => s,n,ExecIf($["${MOHCLASS}"!=""]?Set(CHANNEL(musicclass)=${MOHCLASS}))
exten => s,n,GosubIf($["${QUEUEWAIT}"!=""]?qwait,1())

exten => s,n(skiptrace),Set(D_OPTIONS=${IF($["${NODEST}"!="" & ${REGEX("(M[(]auto-blkvm[)])" ${ARG2})} != 1]?${ARG2}M(auto-blkvm):${ARG2})})
exten => s,n,ExecIf($["${ALERT_INFO}"!=""]?SIPAddHeader(Alert-Info: ${ALERT_INFO}))
exten => s,n,ExecIf($["${SIPADDHEADER}"!=""]?SIPAddHeader(${SIPADDHEADER}))
exten => s,n,ExecIf($["${ALERT_INFO}"!=""]?Set(PJSIP_HEADER(add,Alert-Info)=${ALERT_INFO}))
exten => s,n,ExecIf($["${MOHCLASS}"!=""]?Set(CHANNEL(musicclass)=${MOHCLASS}))
exten => s,n,GosubIf($["${QUEUEWAIT}"!=""]?qwait,1())

hello… I am going forward in understanding the dial plan logic… and what I understood is dialparties does pass the calling to macro-dial.
have you got any suggest how to modify macro dial in the way it creates the header and send the alert-info as expected???

I’m affected by this as well. I also tried modifying extensions_additional.conf as mentioned in the bug submission, but it had no effect. Andrew mentions that both macro-dial-one and macro-dial contexts need to be modified. I only see the macro-dial context in the extensions.conf file, and it has nothing (that I can figure out) that is related to setting alert-info within the SIP header.

I also saw a reference to SIPAddHeader Alert-Info in the ext-local-confirm context in extensions_additional.conf, and tried changing that line to match Andrew’s changes in the bug report, Specifically, I changed it to:

exten => _LC-.,1,ExecIf($["${ALERT_INFO}"!=""]?Set(PJSIP_HEADER(add,Alert-Info)=${ALERT_INFO}))

but neither that, nor changing the entry in the macro-dial-one context had any impact on the problem.

In the full Asterisk log, I’m getting these three messages in regards to the alert-info:

[2015-04-27 14:53:57] VERBOSE[34880][C-00000008] pbx.c: Executing [[email protected]:7] Set("PJSIP/SipProvider pjSIP-0000000d", "QAINFO=http://pbx.hostname.domain:84/ringtones/operator.wav;info=ring1") in new stack
[2015-04-27 14:53:57] VERBOSE[34880][C-00000008] pbx.c: Executing [[email protected]:9] ExecIf("PJSIP/SipProvider pjSIP-0000000d", "1?Set(__ALERT_INFO=http://pbx.hostname.domain:84/ringtones/operator.wav;info=ring1)") in new stack
[2015-04-27 14:53:57] VERBOSE[34988][C-00000008] pbx.c: Executing [[email protected]:31] ExecIf("Local/[email protected];2", "1?SIPAddHeader(Alert-Info: http://pbx.hostname.domain:84/ringtones/operator.wav;info=ring1)") in new stack

All three of the entries are unchanged based on making the change to the extensions_additional.conf file.

It’s somewhat academic to change it in the extensions_additional.conf file, because that is re-generated each time the server is reloaded. Still, it would give me confidence that if I made the change and it worked, at least it would just be a matter of time until the module is updated in FreePBX.

Replies in this forum seem to have dropped off significantly since Sangoma acquired FreePBX, and I’m hoping that’s just a temporary trend while they go through the corporate reorganization. Still, if anyone from FreePBX has any suggestions on what to try, they would be most welcome.

Since their is a ticket opened already its been assigned out and put on deck as you can see at It is working its way through the tracker system. Everyone has been really focused on FreePBX 13 and trying to get out loose ends finalized so we can get into Beta and we have closed 140 tickets in the last 60 days which is way above normal.

Asterisk 13 issues always take a seat behind everything else since 13 is considered experimental and lots of hidden ghost that have to be worked through.

Thank you for the reply. This is very much what I was hoping to hear, and I’m looking forward to the “EXPERIMENTAL” tag being removed from Asterisk 13. I suspected that any workaround involving manually editing (or an incrontab script to edit any changed file) would be a sloppy workaround at best, and fixing the code (which I am, admittedly, incapable of doing) is really the way to fix it.

Keep up the great work!