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

Kaloyan Kovachev kkovachev at varna.net
Thu Mar 27 06:45:46 CDT 2008


Hi,
 the curl version was provided from greyvoip, so probably he will be able to
tell you more about it.
 If you use some of the non curl versions (i may send you the latest diff if
you wish), you may achieve the same results by setting in advance (as global
variable):

LIMIT_RECHECK_APP=$
LIMIT_RECHECK_APP=${LIMIT_RECHECK_APP}{CURL(http://127.0.0.1/test.php?
LIMIT_RECHECK_APP=${LIMIT_RECHECK_APP}app=rtcc&accountcode=$
LIMIT_RECHECK_APP=${LIMIT_RECHECK_APP}{ACCOUNTCODE}&dst=$
LIMIT_RECHECK_APP=${LIMIT_RECHECK_APP}{EXTEN}&channelid=$
LIMIT_RECHECK_APP=${LIMIT_RECHECK_APP}{UNIQUEID}&seqnum=1)}

and you change your dial command to:

exten => _X.,n,Dial(SIP/1025,,L(${TimeLimit}:${RTCC_INTERVAL}))

it should work, but keep in mind that it requires at least parameters to L()
and that 60000 is 60sec not 6sec.
 As your script is returning fixed number (120 or 80 which for the curl
version is in milliseconds, but in seconds for the non curl version) this will
cause your call duration to be increased with that amount of
milliseconds/seconds each time. I would suggest for the tests to start with
${TimeLimit} set to 120000, ${RTCC_INTERVAL} being 10000 and your script
returning '-10'.


On Thu, 27 Mar 2008 18:10:40 +0800, Charles Wang wrote 
> Hi all, 
>   
> I tried to using rtcc-curl-1.4.13.patch in bug id 6335
http://bugs.digium.com/view.php?id=6335  reported by KNK. I patch it to
asterisk 1.4.18.1 and it seems work. 
>   
> My extensions.conf lists below: 
>   
> exten =>
_X.,1,Set(TimeLimit=${CURL(http://127.0.0.1/test.php?app=rtcc&accountcode=${ACCOUNTCODE}&dst=${EXTEN}&channelid=${UNIQUEID}&seqnum=1)})

> exten => _X.,n,Set(TimeLimit=${MATH(${TimeLimit}+5,int)}) 
> exten => _X.,n,Set(TimeLimit=${MATH(${TimeLimit}*1000,int)}) 
> exten => _X.,n,Set(dst=${EXTEN}) 
> exten => _X.,n,NoOp(Initial time limit for ${ACCOUNTCODE} and ${EXTEN} set
at ${TimeLimit}) 
> exten => _X.,n,Set(RTCC_START_SEQNUM=2) 
> exten => _X.,n,Set(RTCC_INTERVAL=60000) 
> exten => _X.,n,Dial(SIP/1025,,L(${TimeLimit}:::http://127.0.0.1/test.php)) 
> exten => _X.,n,Hangup 
> 
> My URL test.php always reponses interger 120. It is pure text format without
any symbol before/after it. 
>   
> My test.php: ( one row only ) 
> 120 
>   
>     -- Accepting AUTHENTICATED call from XXX.XXX.XXX.XXX: 
>        > requested format = ilbc, 
>        > requested prefs = (), 
>        > actual format = ilbc, 
>        > host prefs = (ilbc), 
>        > priority = mine 
>     -- Executing [_X. at default:1] Set("SIP/2922-10", "TimeLimit=120") in new
stack 
>     -- Executing [_X. at default:2] Set("SIP/2922-10", "TimeLimit=125") in new
stack 
>     -- Executing [_X. at default:3] Set("SIP/2922-10", "TimeLimit=125000") in
new stack 
>     -- Executing [_X. at default:4] Set("SIP/2922-10", "dst=295") in new stack 
>     -- Executing [_X. at default:5] NoOp("SIP/2922-10", "Initial time limit
for  and 295 set at 45000") in new stack 
>     -- Executing [_X. at default:6] Set("SIP/2922-10", "RTCC_START_SEQNUM=2")
in new stack 
>     -- Executing [_X. at default:7] Set("SIP/2922-10", "RTCC_INTERVAL=60000")
in new stack 
>     -- Executing [_X. at default:8] Dial("SIP/2922-10",
"SIP/1025||L(125000::http://127.0.0.1/test.php)") in new stack 
>     -- Limit Data for this call: 
>         > timelimit      = 125000 
>        > play_warning   = 0 
>         > play_to_caller = yes 
>         > play_to_callee = no 
>         > warning_freq   = 0 
>        > rtcc url       = //127.0.0.1/test.php 
>        > rtcc interval  = 60000 
>        > rtcc exp intvl = 0 
>         > rtcc seqnum     = 2 
>         > start_sound    = (null) 
>        > warning_sound  = timeleft 
>        > end_sound       = (null) 
>   
> During the period, I trace the /var/log/httpd/access_log. I can't find any
request to test.php. Should it be visited each 6 sec ? 
> 
> (Only this line) 
> 127.0.0.1 - - [27/Mar/2008:17:51:54 +0800] "GET
/test.php?app=rtcc&accountcode=&dst=295&channelid=1206611514.2&seqnum=1
HTTP/1.1" 200 3 "-" "asterisk-libcurl-agent/1.0" 
>   
> Then, I tried to reduce the integer number 120 to 80. I wish it can be 
hunup when 80 seconds reached. But the answer was NO. It made my asterisk
crashed. I got this message in debug mode. 
>   
> [Mar 27 17:52:58] DEBUG[32053]: app_dial.c:877 rtcccallback: call control
accountcode=2922, dst=295. 
> asterisk: symbol lookup error: /usr/lib/asterisk/modules/app_dial.so:
undefined symbol: curl_easy_init 
>   
> Can anyone kindly give me any idea? 
>   
> Best regards, 
> Charles 
>   
> 2007/7/15, Grey Man <greyvoip at yahoo.com.au>:  
> 
> ----- 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 
> 
> _______________________________________________ 
> --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 
>  
>  
> -- 
> 
> Best Regards 
> Charles




More information about the asterisk-dev mailing list