[Home]

Summary:ASTERISK-12307: CDR(billsecs) is not set if the M() option is used and the dialed party answers but hangs up whilst the macro is running
Reporter:Nick Barnes (bcnit)Labels:
Date Opened:2008-07-03 09:32:58Date Closed:2008-08-05 18:05:02
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_dial
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:
I have classed this as 'major' because of the potential financial liability this bug may impose.

Consider a simple snippet of dial plan:

--------------------
[test]
exten => s,1,Dial(SIP/403,5,M(test-macro))

[macro-test-macro]
exten => s,1,Wait(10)
exten => s,n,MacroExit()
---------------------

If '403' answers the call, but hangs up whilst the macro is running, the following CDR is produced:

"","402","s","test",""""" <402>","SIP/402-b6b06d70","SIP/403-084fc050","Dial","SIP/403|5|M(test-macro)","2008-07-03 14:16:51","2008-07-03 14:17:01","2008-07-03 14:17:01",10,0,"ANSWERED","DOCUMENTATION","1215094611.65003",""

In the example above, billsecs shows as 0, but it should really be '8'.

However, if the callee hangs up after the macro has finished (and the caller and callee are bridged), then billsecs shows the correct value (and includes the amount of time the callee spent in the macro):

"","402","s","test",""""" <402>","SIP/402-b6b01ea8","SIP/403-084b8cb0","Dial","SIP/403|5|M(test-macro)","2008-07-03 14:20:30","2008-07-03 14:20:31","2008-07-03 14:20:46",16,15,"ANSWERED","DOCUMENTATION","1215094830.65021",""

This behaviour is, at best, inconsistent and, at worst, financially costly. If the callee does answer but hangs up within the macro, it is impossible to know what the billable part of the total call duration was.

I believe that if the call is answered, regardless of the value returned in MACRO_RESULT or where the call was terminated, the CDR field 'billsecs' should always contain the time between the callee answering the call and the call being terminated irrespective of whatever hoops the callee has to jump through to get the call bridged to the caller.
Comments:By: Digium Subversion (svnbot) 2008-08-05 18:05:00

Repository: asterisk
Revision: 135799

U   branches/1.4/apps/app_dial.c
U   branches/1.4/include/asterisk/cdr.h
U   branches/1.4/main/cdr.c
U   branches/1.4/main/channel.c
U   branches/1.4/res/res_features.c

------------------------------------------------------------------------
r135799 | murf | 2008-08-05 18:04:59 -0500 (Tue, 05 Aug 2008) | 34 lines

(closes issue ASTERISK-12307)
Reported by: bcnit
Tested by: murf

I discovered that also, in the previous bug fixes and changes,
the cdr.conf 'unanswered' option is not being obeyed, so
I fixed this.

And, yes, there are two 'answer' times involved in this
scenario, and I would agree with you, that the first
answer time is the time that should appear in the CDR.
(the second 'answer' time is the time that the bridge
was begun).

I made the necessary adjustments, recording the first
answer time into the peer cdr, and then using that to
override the bridge cdr's value.

To get the 'unanswered' CDRs to appear, I purposely
output them, using the dial cmd to mark them as
DIALED (with a new flag), and outputting them if
they bear that flag, and you are in the right mode.

I also corrected one small mention of the Zap device
to equally consider the dahdi device.

I heavily tested 10-sec-wait macros in dial, and
without the macro call; I tested hangups while the
macro was running vs. letting the macro complete
and the bridge form. Looks OK. Removed all the
instrumentation and debug.



------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=135799