[asterisk-dev] Real-time call control for Dial app
Charles Wang
lazy.charles at gmail.com
Thu Mar 27 11:47:17 CDT 2008
Hi Kaloyan,
I think I understand what it means.
Thank you for your help.
Best regards,
Charles
2008/3/27, Kaloyan Kovachev <kkovachev at varna.net>:
>
> 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
>
>
> _______________________________________________
> --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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20080328/f304acda/attachment.htm
More information about the asterisk-dev
mailing list