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

[Kaloyan Kovachev]

On Fri, 13 Jul 2007 01:20:26 -0700 (PDT), Grey Man wrote
> > ----- Original Message ----
> > From: Kaloyan Kovachev <kkovachev at varna.net>
> > To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
> > Sent: Sunday, 8 July, 2007 6:21:29 PM
> > Subject: Re: [asterisk-dev] Real-time call control for Dial app
>  >
> >> Hi,
> >> 
> >> In doing some further testing of the recheck/call control patch a warning is
> popping up about a blocked thread.
> >> 
> >> channel.c:1608 ast_waitfor_nandfds: Thread xxx Blocking 'SIP/xx-xxx',
> already blocked by thread xxx in procedure ast_waitfor_nandfds
> >
> >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.
> 
> Hi Kaloyan and All,
> 
> You were right about the thread locking issue being related to the AGI
application. The original thread executing the dial_exec_full needs a lock on
the original channel somewhere in ast_channel_bridge. Then the Agi application
also requests a lock on the same channel in agi_exec_full in res_agi.c. As you
indidcated I also don't think it's a huge deal as I haven't been able to cause
any serious malfunctions by stalling or killing my fastagi application. The
worst thing that seems to be able to happen is if the Agi application hangs
and coincides with the time the original dial thread should be hanging it up
due to the time limit expiring. In that case the call will not be hungup until
the Agi application is interrupted by a timeout signal, I'm not sure exactly
what the timings are but I think the hung thread will get interrupted after
about 20 to 30s so in the worst case the call would go 30s over.
> 
> One other concern that cropped up is the impact the additional thread load
could have on the Asterisk audio processing. Each in progress channel now has
two threads, I'm wondering if the thread extra context switching could cause a
load problem. Asterisk and/or the libpthread code does seem very efficient at
switching amongst threads so I'm hoping it will be alright with the doubling
of threads. I'd be very interested to know if anyone has any insights into the
possible impact of introducing an extra thread for every call in order to do
the real-time call control.
> 
Hi again,
 i guess Asterisk is not used for prepaid applications too much, or more
likely the risk of overused account is just ignored (there are providers with
'pay as go' services with which i had negative balance for a while).
 Even separate thread for each call bridge is not the best way and adding
another one is not a good idea - agree, but the call control thread is
sleeping most of the time, so it shouldn't cause too much problems.
 Unfortunately my C skills (and available time) are not enough to make (my
long term idea) a single call control thread for which each call will just
register and which will also be responsible for the warning messages on that
call instead of the bridging thread itself. I think this is the way to go, but
for now this is at least some way to control the call duration after it has
started.

P.S. For the warning messages it plays (actually whispers) successfully the
one for the calling channel, but still couldn’t (had the time to) make it to
play to the called or simultaneously to both channels if configured.


> 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