[macro-confirm] issues!

I truly am going mad about this! We are using Follow Me to call our cell phones, and we are running into a issue (Albeit, minor) that is driving me up the wall. When we answer our phone, we used to get a message that says: press 1 to answer the call, 2 to do something else. There would also be a message eventually that said you missed the call (incoming-call-1-accept-2-decline.sln, incoming-call-no-longer-avail.sln). However, these no longer played. So, the next step in my mind was to create custom audio files, and assign those. Unfortunately, that hasn’t worked either. I have tested this extensively to make sure there is nothing wrong with those files by creating a test module that looks like this:

exten => 66,1,Answer
;exten => 66,n,Background(to-call-this-number)
exten => 66,n(start),Background(incoming-call-1-accept-2-decline,m,${CHANNEL(language)},macro-confirm)
exten => 66,n,Read(INPUT,1,4)

and it works perfect with no issues. Now, if I compare the debug from outgoing call (Using VoicePulse) to my cell, and try calling this test “billstest” extension from my (Again using VoicePulse), the logs are identical, but outgoing doesn’t work. Here is an example:

-- SIP/voicepulse-primary-00000002 answered Local/19785551212@from-internal-046b;2
-- Local/19785551212@from-internal-046b;1 answered Local/RG-400-19785551212#@from-internal-5933;2
-- Executing [s@macro-confirm:1] Set("Local/19785551212@from-internal-046b;1", "LOOPCOUNT=0") in new stack
-- Executing [s@macro-confirm:2] Set("Local/19785551212@from-internal-046b;1", "__MACRO_RESULT=ABORT") in new stack
-- Executing [s@macro-confirm:3] Set("Local/19785551212@from-internal-046b;1", "MSG1=custom/IncomingCall") in new stack
-- Executing [s@macro-confirm:4] BackGround("Local/19785551212@from-internal-046b;1", "custom/IncomingCall,m,en,macro-confirm") in new stack
-- <Local/19785551212@from-internal-046b;1> Playing 'custom/IncomingCall.slin' (language 'en')

Looks like it should play! and it does when I use my custom extension above. ARGH!! Any thoughts or ideas? The only difference I see is that one is an incoming call versus an outgoing call (The outgoing being the one that doesn’t work). I may seem like I know what I am talking about, but believe me, I’m not… I have just a lot of time into this.

Here is what I got:

  • FreePBX
  • Follow Me
  • Ubuntu 10.04.1 LTS

Please help so I can sleep at night.

Bill Bushong

It appears that the SIP Settings module creates a sip.conf file that doesn’t have a “dtmfmode=auto” setting or a dtmfmode at all. As soon as i added it manually (through the gui) and reloaded, all is working.

Perhaps the asterisk bug is not related, perhaps a missing default sip.conf entry is the problem. Not sure if that is a bug or a feature request, but does appear to be freepbx related for now. Perhaps the previous issue with prior version was experiencing the same issue. Upgrading the version of asterisk might have put the default setting back in there?

FWIW, the SIP provider I use is Vitelity, I saw some posts about DTMF issues with Vitelity. When I got ready to submit a trouble ticket to them for assistance, their website advised to check for “dtmfmode=auto” is sip.conf.

Hopefully something can be done to keep someone else from going through unnecessary trouble :slight_smile:

the setting should be configured in the trunk configuration for the specific provider. Try taking it out of the the general settings and adding it to their configuration and see if that fixes your issue.

Well this is a little bit of a ‘shot in the dark’ but…

can you try to add a call to Progress() just prior to the Background application?


include => macro-confirm-custom
exten => s,1,Set(LOOPCOUNT=0)
exten => s,n,Set(__MACRO_RESULT=ABORT)
exten => s,n,Set(MSG1=${IF($["${ARG1}${ALT_CONFIRM_MSG}"=""]?incoming-call-1-accept-2-decline:${IF($[${LEN(${ALT_CONFIRM_MSG})}>0]?${ALT_CONFIRM_MSG}:${ARG1})})})

exten => s,n,Progress() ; <==== TRY ADDING THIS

exten => s,n(start),Background(${MSG1},m,${CHANNEL(language)},macro-confirm)
exten => s,n,Read(INPUT,,1,,,4)

‘snippet’ where I pressed DTMF key, but system shows that I didn’t.

For what it is worth, i also in the meantime found what appears to possibly be a related bug report with Asterisk. I can’t tell for sure if this is related, however.


It addresses not receiving DTMF via the “Local” channel. I believe the basis were that a latest patch may have added a silence suppressor that might have broken it. While it’s great to know that, I’m not that sure about how to “roll back” from that granular of a patch.

-- <Local/66665554443333@from-internal-5200;1> Playing 'custom/mybiz-acceptsupport.slin' (language 'en')
-- Executing [s@macro-confirm:5] Progress("Local/66665554443333@from-internal-5200;1", "") in new stack
-- Executing [s@macro-confirm:6] Read("Local/66665554443333@from-internal-5200;1", "INPUT,,1,,,4") in new stack
-- Accepting a maximum of 1 digits.
-- User entered nothing.
-- Executing [s@macro-confirm:7] GotoIf("Local/66665554443333@from-internal-5200;1", "0?,1:t,1") in new stack
-- Goto (macro-confirm,t,1)

I too am experiencing this identical problem but I am on asterisk 1.8

I posted another thread because i thought it was a bug with ringgroups-
I’m running freepbx 2.8.1 and asterisk

what I have noticed is that there is something that isn’t quite right when running a macro on an outbound call until the macro exits. It’s almost like it hasn’t fully answered.

in macro-confirm i bypassed the “read” statement and the rest of the macro ran fine. For what it is worth, Authenticate also seems to have this same issue.

It appears through testing that the Read() and Authenticate() commands both suffer from the same problem.

If i simply do an “exten => s,n Set(INPUT=1)” in place of either of the sets below, it completes (without user input)

exten => s,n,Authenticate(1,1,${MSG1})
exten => s,n Set(INPUT=1)


exten => s,n,Read(INPUT,1,4)

It’s like it is in one way audio mode until the macro exits after this part

exten => 1,n,Set(__MACRO_RESULT=)
exten => 1,n(exitopt1),MacroExit()

I don’t know what would cause that. I’m hoping someone on here knows more about how to make a patch or a workaround for this.

I upgraded to Asterisk, and the problem is gone WOO HOO!!! I can sleep!!

Thank you for your time.

Bill B.

I have tried a few more things…

  1. I changed dialplan to use playback instead of background:
    exten => s,n,Playback(pm-invalid-option)
    exten => s,n,NoOp(${PLAYBACKSTATUS})

Oddly, it never got passed the playback command… it just sat there for quite a while until finally dying after a lot of seconds:

-- Executing [s@macro-confirm:6] Playback("Local/9788040052@from-internal-7961;1", "pm-invalid-option,noanswer") in new stack
-- <Local/9788040052@from-internal-7961;1> Playing 'pm-invalid-option.gsm' (language 'en')

li234-226*CLI> SEVERAL SECONDS LATER! (20-25)
– Executing [h@macro-dialout-trunk:1] Macro(“Local/9788040052@from-internal-7961;2”, “hangupcall,”) in new stack
– Executing [s@macro-hangupcall:1] GotoIf(“Local/9788040052@from-internal-7961;2”, “1?skiprg”) in new stack

Ok… so that didn’t work :frowning:

So I tried this instead:
exten => s,n,Playtones(!950/330,!1400/330,!1800/330,0)
exten => s,n,Wait(5)
exten => s,n,StopPlaytones

And that works!!! Go figure! Any ideas?

Ok… so I finally got the time to run this test… I did a packet capture, and quite frankly, I don’t know what I’m looking for. I saw a bunch of SIP packets during that time, but how can I know if they were audio or just silence, or what?


do a raw capture with no length limitations on the packet length.

once you dod that, load it up in wireshark which should recognize the SIP packets and once you identify one of your RTP packets as such, will recognize the stream and it’s association with the SIP call.

What you are ultimately looking for is to seen if inside the firewall it appears to be acting normally, and thus is the firewall blocking either the stream from outside into Asterisk or the stream from Asterisk to the outside (wince you would see that stream, but if not hearing it on the far end it would imply that the firewall blocked it.

Ok… I’m on it. Just so you know, this is actually a hosted linode, with no firewall or iptable configured (yet!)… but I’ll give anything a shot…

Thanks again,


try setting up a call confirm macro to an internal extension.

You do this by putting a ‘#’ at the end of the extension number so it is treated as an external number and the call confirm macro is triggered.

Now test it with that extension and see if you still have issues. I’m suggesting this so as to remove any potential firewall related problems that could be involved. If it works now, I’d start looking at the firewall side of things and/or possible SIP changes you may have made in that department.

Taking some pcap traces could help as well to see what is going on and if audio is actually flowing out.

Ok… I did the first half of what you said… I setup the follow me on ext 400 to also ring 402#. I then registered my x-lite client to 402. I called in, choose extension 400, and got the same thing… silence. I pressed 1 and was joined to the call. I will have to do the second half of this tomorrow as I really do need to sleep tonight.

Thanks, and great stuff!!

Let me know if I can try anything else why I am at it.

Bill Bushong