[asterisk-dev] Real-time call control for Dial app

[Kaloyan Kovachev]

On Sun, 8 Jul 2007 13:48:41 +0100 (BST), Grey Man wrote
> >----- Original Message ----
> >From: Kaloyan Kovachev <kkovachev at varna.net>
> >To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
> >Sent: Friday, 6 July, 2007 7:46:08 AM
> >Subject: Re: [asterisk-dev] Real-time call control for Dial app
> >
> >Hi,
>  >it is not necessary that the variables are global - you may set the variable
> >per channel just before the Dial command and even to clear the value of the
> >global variable by setting a blank channel variable. This makes it easy to
> >have 'default rule' and to still be able to customize specific call.
>  >Also because the global/channel variable is parsed at each run, you may even
> >have other variables included - like the RAND() function in
> >http://bugs.digium.com/file_download.php?file_id=13198&type=bug
> 
> Hi,
> 
> In doing some further testing of the recheck/call control patch a warning is
popping up about a blocked thread.
> 
Hi,
 Haven’t tested with AGI, but SQL query may also take longer than a second or
two and that’s why i am using separate ‘call control’ thread – not to
interrupt the audio. Also there are no any locks in the thread during the
execution of the application.
I have tested (some time ago) not returning from the application for a long
time (with simple sleep 100 application) and there where no ‘blocking’
messages, so probably there is something in the script itself (or in the way
FastAGI works, which i am not common with), which is causing the lock.

P.S.
 I'we got similar messages while trying to play the warning sounds from inside
the control thread

> channel.c:1608 ast_waitfor_nandfds: Thread xxx Blocking 'SIP/xx-xxx',
already blocked by thread xxx in procedure ast_waitfor_nandfds
> 
> This message occurs while the recheck application is executing. In my case
it's a FastAGI application and can sometimes take up to 1 second to return.
The longer the application return takes the more of the messages will appear.
It does not appear to cause any major problems that I can see and I have
checked that the audio is still getting passed so the blocked thread does not
appear to be the one executing ast_generic_bridge.
> 
> As yet I haven't been able to determine what the thread that is generating
the above message is doing and whether or not it's related to the original
bridge or is from a thread generated when the recheck application is called.
I'm not very familiar with the threads that are created for a bridged channel
though. The only consequence I have seen so far is when the recehck
application fails to return at all, an example would be a FastAGI application
that hangs, the thread blocking messages continue until the call is hungup by
the time limit expiring in ast_generic_bridge.
> 
> Regards,
> 
> Greyman.
> 
>      
____________________________________________________________________________________
Yahoo!7 Mail has just got even bigger and better with unlimited storage on all
webmail accounts.
> http://au.docs.yahoo.com/mail/unlimitedstorage.html
> 
> _______________________________________________
> --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