Hi All, Asterisk 1.4.12 on CentOS 5 I'm trying to increment an AstDB key with the length of the last outgoing call. Here's what I've got for "01" UK geographical numbers: exten => _01.,1,Dial(${UKGeographical}/${EXTEN},,g) exten => _01.,n,Log(NOTICE,Call to ${EXTEN} lasted ${DIALEDTIME}) exten => _01.,n,Set(CALLTIME=${DIALEDTIME}) exten => _01.,n,Set(ACCUMULATED=${DB(freevoip/seconds)}) exten => _01.,n,Set(DB(freevoip/seconds)=$[${ACCUMULATED}+${CALLTIME}]) The first priority after the Dial() application is there to log the call in /var/log/asterisk/messages This extension is proving flaky at best. On very few occasions, processing has continued after the Dial() application (which is the behaviour I thought the "g" option was meant to specify). However, on most outgoing calls processing goes straight from Dial() to the first priority of the "h" extension (i.e. the default behaviour that should occur without the "g" option). On the few occasions that processing continues with the next priority after the call to Dial(), the call is logged and the AstDB key updated as expected. Is this a known bug? Have I done something wrong? TIA, -- Geoff
hi all, I have the script but i have a small issue and need some help..can you help plz? On 2/21/09, Geoff Lane <geoff at gjctech.co.uk> wrote:> Hi All, > > Asterisk 1.4.12 on CentOS 5 > > I'm trying to increment an AstDB key with the length of the last > outgoing call. Here's what I've got for "01" UK geographical numbers: > > exten => _01.,1,Dial(${UKGeographical}/${EXTEN},,g) > exten => _01.,n,Log(NOTICE,Call to ${EXTEN} lasted ${DIALEDTIME}) > exten => _01.,n,Set(CALLTIME=${DIALEDTIME}) > exten => _01.,n,Set(ACCUMULATED=${DB(freevoip/seconds)}) > exten => _01.,n,Set(DB(freevoip/seconds)=$[${ACCUMULATED}+${CALLTIME}]) > > The first priority after the Dial() application is there to log the > call in /var/log/asterisk/messages > > This extension is proving flaky at best. On very few occasions, > processing has continued after the Dial() application (which is the > behaviour I thought the "g" option was meant to specify). However, on > most outgoing calls processing goes straight from Dial() to the first > priority of the "h" extension (i.e. the default behaviour that should > occur without the "g" option). On the few occasions that processing > continues with the next priority after the call to Dial(), the call is > logged and the AstDB key updated as expected. > > Is this a known bug? Have I done something wrong? > > TIA, > > -- > Geoff > > > _______________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users >
Geoff Lane schrieb:> I'm trying to increment an AstDB key with the length of the last > outgoing call. Here's what I've got for "01" UK geographical numbers: > > exten => _01.,1,Dial(${UKGeographical}/${EXTEN},,g) > exten => _01.,n,Log(NOTICE,Call to ${EXTEN} lasted ${DIALEDTIME}) > exten => _01.,n,Set(CALLTIME=${DIALEDTIME}) > exten => _01.,n,Set(ACCUMULATED=${DB(freevoip/seconds)}) > exten => _01.,n,Set(DB(freevoip/seconds)=$[${ACCUMULATED}+${CALLTIME}])> This extension is proving flaky at best. On very few occasions, > processing has continued after the Dial() application (which is the > behaviour I thought the "g" option was meant to specify). However, on > most outgoing calls processing goes straight from Dial() to the first > priority of the "h" extension (i.e. the default behaviour that should > occur without the "g" option). On the few occasions that processing > continues with the next priority after the call to Dial(), the call is > logged and the AstDB key updated as expected.To be quite precise the documentation says ---cut--- g - Proceed with dialplan execution at the current extension if the destination channel hangs up. ---cut--- So I would not expect the g option to have any effect if the *source* channel hangs up. I guess you should do any kind of logging or post-hangup calculations in the h extension. Philipp Kempgen -- AMOOCON 2009, May 4-5, Rostock / Germany -> http://www.amoocon.de Asterisk: http://the-asterisk-book.com - http://das-asterisk-buch.de AMOOMA GmbH - Bachstr. 126 - 56566 Neuwied -> http://www.amooma.de Gesch?ftsf?hrer: Stefan Wintermeyer, Handelsregister: Neuwied B14998 --