[asterisk-dev] h extension not considered within a macro for Asterisk 1.6.0.6 and later

[Tilghman Lesher]

On Tuesday 07 April 2009 20:12:15 Alec Davis wrote:
> Now that the documentation has changed for app_macro, removing the
> reference to the 'h' extension.
>
> app_macro will execute the 'h' extension from within the macro context if
> the call was answered.
> It doesn't execute the 'h' extension if the caller hungup before the call
> was answered, which is where our problems started.
>
> Agreed, switching to GOSUB fixes this. But shouldn't MACRO be consistant,
> either never or always, but not sometimes, execute the 'h' extension?

I don't see how this is inconsistent.  The 'h' extension is run when the
extension hangs up.  If the extension was never answered, how can there be
a hangup?  I agree that it's not convenient for your use case, but it IS
entirely consistent.

> FYI:
> The offending MACRO 'application' was using a MYSQL stored Proc, with a
> MYSQL Fetch within a While loop, which didn't close MYSQL connections if
> the caller hungup before the call was answered.
>
> ...
> exten => s,n,MYSQL(Connect connid localhost pbxtable pbxuser pbxpassword)
> exten => s,n,MYSQL(Query resultid ${connid} call
> pbx_dial('${CALLERID(num)}','${dialing}'))
> exten => s,n,MYSQL(Fetch fetchid ${resultid} type devices busy timeout)
>
> exten => s,n,While($[${fetchid}==1])
> exten => s,n,NoOp(type=${type} devices=${devices} busy=${busy}
> timeout=${timeout})
> exten => s,n,Dial(${devices},${timeout},r)
> exten => s,n,GotoIf($["${DIALSTATUS}"!="BUSY"]?fetchnext)
> exten => s,n,ExitWhile()
> exten => s,n(fetchnext),MYSQL(Fetch fetchid ${resultid} type devices busy
> timeout)
> exten => s,n,EndWhile()
> ...
>
> exten => h,1,NoOp(== hangup dialstatus=${DIALSTATUS} ==)
> exten => h,n,MYSQL(Clear ${resultid})
> exten => h,n,MYSQL(Disconnect ${connid})

You could probably work around this by using func_odbc instead of the MYSQL
application.  Connections are always cleaned up, regardless of when a hangup
does or does not occur.

-- 
Tilghman