[Home]

Summary:ASTERISK-16336: Billsec is zero although disposition is Answered
Reporter:Private Name (falves11)Labels:
Date Opened:2010-07-08 21:38:22Date Closed:2011-06-07 14:00:39
Priority:MajorRegression?No
Status:Closed/CompleteComponents:CDR/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:The call lasts for over 10 seconds, duration is 13 secs, billsec is zero but disposition is Answered, or "8"
I use cdr_odbc.
This is my code for the "h" extension:
exten => h,1,GotoIf($["${DIALSTATUS}" = "ANSWER" & "${CDR(billsec,l)}" = "0" ]?label1:label2)
exten => h,n(label1),Set(CDR(amaflags|r)=billing)
exten => h,n(label2),Verbose(1,${HANGUPCAUSE} --DIALSTATUS= ${DIALSTATUS} Seconds= ${CDR(billsec,l)} AMAFLAGS=${CDR(amaflags)})

The trace goes below

****** ADDITIONAL INFORMATION ******

Executing [h@defaultproc:1] GotoIf("Local/12337274907253@dialer-acae,2", "1?label1:label2") in new stack
   -- Goto (defaultproc,h,2)
   -- Executing [h@defaultproc:2] Set("Local/12337274907253@dialer-acae,2", "CDR(amaflags|r)=billing") in new stack
   -- Executing [h@defaultproc:3] Verbose("Local/12337274907253@dialer-acae,2", "1|DIALSTATUS= ANSWER Seconds= 0 AMAFLAGS=BILLING") in new stack

As you can see, the condition is true in the first line of "h", i.e, Dialstatus="Answer"  but billsec=0, and that condition is a bug by definition, since if somebody answered, we need to pay for the call.

I can demo this issue to a developer in my system. It happens all the time. So far what I do is this: this condition is true, I assume the duration to be six seconds, which is making my billing completely inaccurate. It does not happens in all calls, just in a few, but in my current app I can reproduce it all the time. The relevant dialing part goes below:

exten =>_X.,n,Dial(${CUT(CARRIERLIST,-,${i})},${CUT(TO,-,${i})},aM(get-callidX^${PROMPT})L(10800000))

[macro-get-callidX]
exten => s,1,Verbose(2,Playing ${ARG1})
exten => s,n,GotoIf($["${ARG1}" = "0" ]?salida)
exten => s,n,Background(${ARG1})
exten => s,n(salida),MacroExit

and this is the trace
== Trying: SIP/g729.X.X.X.X./1727490XXX /XXX3171603
   -- Executing [727490XXX@defaultproc:29] Dial("Local/1233727490XXX@dialer-acae,2", "SIP/g729.XX.XX.XX.XX/1727490XXX|70|aM(get-callidX^0)L(10800000)") in new stack
   -- Limit Data for this call:
      > timelimit      = 10800000
      > play_warning   = 0
      > play_to_caller = yes
      > play_to_callee = no
      > warning_freq   = 0
      > start_sound    =
      > warning_sound  = timeleft
      > end_sound      =
   -- Called g729.X.X.X.X/1727490XXX
   -- SIP/g729.X.X.X.X-00000000 is ringing
   -- SIP/g729.X.X.X.X-00000000 is making progress passing it to Local/1233727490XXXX@dialer-acae,2
   -- SIP/g729.X.X.X.X-00000000 answered Local/1233727490XXXX@dialer-acae,2
   -- Executing [s@macro-get-callidX:1] Verbose("SIP/g729.X.X.X.X-00000000", "2|Playing 0") in new stack
 == Playing 0
   -- Executing [s@macro-get-callidX:2] GotoIf("SIP/g729.X.X.X.X-00000000", "1?salida") in new stack
   -- Goto (macro-get-callidX,s,4)
-- Executing [s@macro-get-callidX:4] MacroExit("SIP/g729.X.X.X.X-00000000", "") in new stack
      > Channel Local/1233727490XXXX@dialer-acae,1 was answered.
Comments:By: Matthew Nicholson (mnicholson) 2010-07-09 12:59:11

Make sure you have endbeforehexten enabled in your cdr.conf.  If you have that option on, and you are still seeing a problem, please post a sample CDR record demonstrating the problem and instructions on exactly how to reproduce it.
By: Tilghman Lesher (tilghman) 2010-07-09 13:04:42

However, you cannot change the CDR once it is ended.  You can get around this by calculating the "billsec so far" as 1.6 and forward do by default:

$[${EPOCH}-${CDR(answer)}]
By: Private Name (falves11) 2010-07-09 13:11:10

I do have the endbeforehexten=yes in my cdr.conf. I already posted the trace. I have no idea how to reproduce it away from my application in live-conditions. I think that it is related to playing a file to the callee and hanging up the call before the file has been played out.
By: Matthew Nicholson (mnicholson) 2010-07-09 13:50:05

I didn't ask for a trace, I asked for a sample CDR record.  The trace does not contain all of the information that I want to see.
By: Paul Belanger (pabelanger) 2010-07-19 10:25:30

Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested.

Further information can be found at http://www.asterisk.org/developers/bug-guidelines