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

[Grey Man]

----- Original Message ----
>From: Kaloyan Kovachev <kkovachev at varna.net>
>To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
>Sent: Saturday, 14 July, 2007 3:00:54 PM
>Subject: Re: [asterisk-dev] Real-time call control for Dial app
>
>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.

Hi Kaloyan,

My idea is to put the real-time call control onto the the thread in channel.c that is already monitoring the bridge. You already nicely slotted in the "recheck" thread into this main bridge thread with your patch by using the nexteventts property and I think I might be able to do call control I need on the bridge thread and remove the need for the "recheck" thread.

The problem with doing things on channel.c is it rightly doesn't know anything about applications, dialplans or specific channel properties. However the more I've played around with real-time call control the more I'm thinking the main requirement is to have a clean scalable way to update the call time and not so much about being able to periodically call more involved applications on an in progress calls. For example my requirement would be satisifed by having the bridge thread on channel.c send the accountcode, call destination and call time to an external IP socket and get back a single integer that specifies any adjustment that should be made to the call time. Passing those 3 bits of info to an external socket does not need the extra applications. Sure there is a loss of flexibility in that the "recheck" app is essentially being hard coded but I do suspect the reason this functionality would get used in at least 90% of cases is to get back that single integer to adjust
 the call time.

Another reason I'm toying with this approach is that I did run into a problem with the thread locking when a FastAGI call is made and it hangs. Unlike previously reported the hang in the FastAGI application meant that the bridge thread was unable to hangup the call. This makes me very nervous as it means a bug in the FastAGI application could potentially allow untimed calls. So that combined with a desire to avoid the additional thread due to load and scalability concerns mean I'll probably give the approach described above putting the check on the bridged thread a shot although unfortunately my C skills are very poor and if I didn't have your original patch to work from would really be stuck!

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