[asterisk-dev] Real-time call control for Dial app
Charles Wang
lazy.charles at gmail.com
Thu Mar 27 05:10:40 CDT 2008
Hi all,
I tried to using
rtcc-curl-1.4.13.patch<http://bugs.digium.com/file_download.php?file_id=15943&type=bug>
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=1HTTP/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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20080327/f8ed094d/attachment.htm
More information about the asterisk-dev
mailing list