Not returning to h extension from external hangups

Running FreeBPX version 2.8.1.4 including Asterisk 1.8.8.0. Here’s the problem:
When external caller hangs up, Asterisk goes to [macro-hangupcall] context in extensions_additional.conf and returns to the h extension at the end of that context, but does not process the h extension statements properly in my dialplan context.

If the call was from an internal extension this problem does not occur because the macro isn’t invoked. Here are the log files:

Internal:
– <SIP/123-00000023> Playing ‘custom/9_goodbye.slin’ (language ‘en’)
– Executing [s@record_greeting:99] Hangup(“SIP/123-00000023”, “”) in new stack
== Spawn extension (record_greeting, s, 99) exited non-zero on 'SIP/123-000000
– Executing [h@record_greeting:1] MYSQL(“SIP/123-00000023”, "Clear ") in new stack
– Executing [h@record_greeting:2] MYSQL(“SIP/123-00000023”, "Disconnect ")
– Executing [h@record_greeting:3] System(“SIP/123-00000023”, "rm /var/lib/a

External:
– <SIP/voipms-00000022> Playing ‘custom/9_goodbye.slin’ (language ‘en’)
– Auto fallthrough, channel ‘SIP/voipms-00000022’ status is ‘UNKNOWN’
– Executing [h@dcc_greeting:1] Macro(“SIP/voipms-00000022”, “hangupcall,”) in new stack
<comment: SEEMS TO INTERCEPT THE H,1, IN MY DIALPLAN AND SUBSTITUTE [MACRO-HANGUPCALL]>
– Executing [s@macro-hangupcall:1] GotoIf(“SIP/voipms-00000022”, “1?skiprg”) in new stack
– Goto (macro-hangupcall,s,4)
– Executing [s@macro-hangupcall:4] GotoIf(“SIP/voipms-00000022”, “1?skipblkvm”) in new stack
– Goto (macro-hangupcall,s,7)
– Executing [s@macro-hangupcall:7] GotoIf(“SIP/voipms-00000022”, “1?theend”) in new stack
– Goto (macro-hangupcall,s,9)
– Executing [s@macro-hangupcall:9] Hangup(“SIP/voipms-00000022”, “”) in new stack
== Spawn extension (macro-hangupcall, s, 9) exited non-zero on ‘SIP/voipms-00000022’ in macro ‘hangupcall’
<comment: SEEMS TO ATTEMPT TO BOUNCE BACK TO MY DIALPLAN’S H,1 BUT IT DOESN’T FINISH. WHY NOT?>
== Spawn extension (record_greeting, h, 1) exited non-zero on ‘SIP/voipms-00000022’

Any thoughts? Is this a FreePBX bug?

The FreePBX’s generated dialplan is funky at times.
Check freepbx.org/trac/ticket/5379