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:58 | Date Closed: | 2008-08-05 18:05:02 |
Priority: | Major | Regression? | No |
Status: | Closed/Complete | Components: | 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 |