CPU Spike using macros

Very new to this, but I am trying to do a simple inbound to outbound call

The issue I’m having is this,… The caller comes into Asterisk, I ask them to record their name and enter the number they wish to call. I then Dial the number they entered with the M option and send the called person to that macro if they answer. The called person is asked a few questions for billing, and if they pass, I bridge the 2 calls. All this works fine until the calling person hangs up before the call is bridged. It sends my CPU to 99% and TOP shows its asterisk doing this.

It might be my Answer() or Hangup() or even my MacroExit() being in the wrong places, but why wont asterisk dump the call immediately upon the calling end hanging up? The CPU stays at 99% until the called end finally hangs up the call. Any help would be GREAT.

[Inc-call]
exten => _X.,1,Answer()
exten => _X.,n,Background(state-name|m)
exten => _X.,n,Read(userdest|enter|10|n|1|7)
exten => _X.,n,Record(/voicefiles/TEST/${userdest}:gsm|3|3|s)
exten => _X.,n,Dial(SIP/+1${userdest}@route-3||Cm()M(test-dial))
exten => _X.,n,Hangup()

exten => h,1,Hangup()

[macro-test-dial]

exten => s,1,Background(/voicefiles/TEST/${userdest}|m)
exten => s,n,Background(is-trying-to-call|m)
exten => s,n,Background(to-talk-to|m)
exten => s,n,Background(/voicefiles/TEST/${userdest}|m)
exten => s,n,Read(accdeny|and-accept|1|n|2|4)
exten => s,n,GotoIf($["${accdeny}" = “1”]?20:100)

exten => s,20,Background(invoice|m)
exten => s,n,MacroExit()

exten => s,100,Set(TIMEOUT(absolute)=1)
exten => s,n,MacroExit()

exten => h,1,MacroExit()

Whilst the macro is running, the caller will be connected to the autoservice process, which eats voice frames and lets control frames, like hangup, queue up. Only when control returns to Dial, will the AST_CONTROL_HANGUP frame be actioned. The bridge code also handles them, for established calls. Autoservice doesn’t know about the outgoing side of the call, and the macro is running on behalf of the called party.

Going 100% CPU generally means you have a deadlock situation, but one in which Asterisk is polling to gain the lock. See wiki.asterisk.org/wiki/display/ … rADeadlock for what to do with deadlocks.

Taking the above dial-plan, would there be a easier way to do what I’m trying to accomplish that wont have the issue with the autoservice not knowing about the outgoing call?

And thanks for the response as well. Gets me looking into different areas.