[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: Sunday, 15 July, 2007 10:50:29 AM
Subject: Re: [asterisk-dev] Real-time call control for Dial app

On Sat, 14 Jul 2007 14:36:27 -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: 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.

> Can't you do this via Manager? By leaving blank the LIMIT_RECHECK_APP, but
> setting LIMIT_RECHECK_INTERVAL and LIMIT_RECHECK_DELAY you will get Manager
> event and then you may have enough time (LIMIT_RECHECK_DELAY) to proces it and
> to set CALL_LIMIT variable to that channel back from Manager. As you need the
> acount code you will need to add it to the event field.

MAPI is an option but it would result in another moving part to be able to control calls and would still need the extra thread per bridged call to fire the events. If the real-time call control mechanism was a request approach from channel.c then there is need to use MAPI or any additional threads. The bridge thread in channel.c doesn't seem to be doing much at all, just waiting for the call time limit to expire, so giving it an extra task would give better utilisation of that thread.

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