[asterisk-dev] =h extension not considered within a macro for_Asterisk...

[Alec Davis]

Thanks for the patch on http://bugs.digium.com/view.php?id=14757 which will
hopefully clear up the MYSQL leaked connections.

Re: 'entirely consistant':
There are 2 parties to a call, either one can hangup at any stage, whether
the call succeeds or not.
It may be consistant if only considered from the 'called' party's point of
view.

I guess we'll have to agree to differ.

Alec

-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Tilghman Lesher
Sent: Wednesday, 8 April 2009 05:30 p.m.
To: Asterisk Developers Mailing List
Subject: Re:
[asterisk-dev]=?ansi_x3.4-1968?q?h_extension_not_considered_with?==?ansi_x3.
4-1968?q?in_a_macro=09for_Asterisk_1=2E6=2E0=2E6_and_lat?==?ansi_x3.4-1968?q
?er?=

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

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev