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

[Kaloyan Kovachev]

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 fields.

 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
> 
> _______________________________________________
> --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