[asterisk-bugs] [Asterisk 0012982]: CDR(billsecs) is not set if the M() option is used and the dialed party answers but hangs up whilst the macro is running

Tue Aug 5 18:05:00 CDT 2008

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12982 
====================================================================== 
Reported By:                bcnit
Assigned To:                murf
====================================================================== 
Project:                    Asterisk
Issue ID:                   12982
Category:                   Applications/app_dial
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.4.20.1 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-07-03 09:32 CDT
Last Modified:              2008-08-05 18:05 CDT
====================================================================== 
Summary:                    CDR(billsecs) is not set if the M() option is used
and the dialed party answers but hangs up whilst the macro is running
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.
====================================================================== 

---------------------------------------------------------------------- 
 (0091119) svnbot (reporter) - 2008-08-05 18:05
 http://bugs.digium.com/view.php?id=12982#c91119 
---------------------------------------------------------------------- 
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 http://bugs.digium.com/view.php?id=12982)
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 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-08-05 18:05 svnbot         Checkin                                      
2008-08-05 18:05 svnbot         Note Added: 0091119                          
======================================================================