[asterisk-dev] Real-time call control for Dial app
Kaloyan Kovachev
kkovachev at varna.net
Thu Mar 27 10:01:39 CDT 2008
On Thu, 27 Mar 2008 21:19:01 +0800, Charles Wang wrote
> Hi, Kaloyan
> Can you please give me the last diff or tell me where to get it?
sure http://my.varna.net/dwl/rtcc-1.4.diff
> Please also give me some tips to configure it.
> The asterisk-backports.org seems be closed.
> And can I ask some questions about the non-curl version?
> 1. Can I only set the results as channel variable instead of global variable?
yes, but please not the way variable is set (in multiple lines) in order to
pass the variables for proccesing on execution
> 2. Is the unit of RTCC_INTERVAL 1/1000 second(ms) not 1 second ?
it is in milliseconds - preserving the original behavior of L() option
> 3. Assume that orginal the first parameter TimeLimit of L option is
120000(120 seconds). Then, RTCC_APP should recheck the URL(test.php) after
${LIMIT_RECHECK_INTERVAL} milliseconds such as 6000 is 6 sec.
> Does it mean the TimeLimit will be added 10 sec if the result of
URL(test.php) is 10? And the TimeLimit is 130 sec.
yes and this will happen each 6 sec, so after 1 minute you will end with
220sec limit.
On each execution the number of seconds returned from test.php will be added
to the TimeLimit and the negative numbers will result in reducing the TimeLimit
> Best regards,
> Charles
>
>
> 2008/3/27, Kaloyan Kovachev <kkovachev at varna.net>: 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
>
> _______________________________________________
> --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