Ticket #3478 (closed Bugs: fixed)

Opened 2 years ago

Last modified 1 year ago

CDR double entriy

Reported by: mbrevda Assigned to: p_lindheimer
Priority: minor Milestone: 2.6
Component: Core Version: 2.5-branch
Keywords: Cc:
Confirmation: Need Feedback SVN Revision (if applicable):
Backend Engine: All Backend Engine Version:

Description

wrt, should the fix be implemented, or does it break something else?

Change History

01/20/09 10:09:07 changed by p_lindheimer

I had not noticed the double entry as I have a custom hangup macro on my system. I ran some tests and found the following, if you use the v option:

exten => s,1,ResetCDR(vw)

then the double CDR is not written out (I have that in my custom version and it never gets written out). If you remove it the double entries appear. (I don't know if this is a bug in Asterisk or a lack of understanding in the use of ResetCDR?)

The reset/nocdr is there to make sure that the call ends there despite any additional work that might be done in the hangup macro. So I would prefer to see this tested and get it working right then remove the call to reset.

01/20/09 10:56:26 changed by p_lindheimer

  • confirmation changed from Unreviewed to Need Feedback.

further update, I removed my custom macro and ran with the standard one. I am not getting double entries, I am using 1.4.21.1. We need to have a better understanding of what is going on before taking any action. Also - if you remove the ResetCDR() and leave the NoCDR() I believe it will result in no CDR record for canceled calls as well as possibly busy, congestion, etc.

01/21/09 13:43:37 changed by mbrevda

im using 1.4.22 and i suspect that is where the problems shows itself most.

03/03/09 11:32:05 changed by wiseoldowl

This issue came up on an Elastix forum this morning - in this message user jgutierrez suggested the following:

to fix the cdr issues, go to /etc/asterisk/extensions.conf

and find the following section: 

  [macro-hangupcall] 
  exten => s,1,ResetCDR(w) 
  exten => s,n,NoCDR() 
 
  ; Cleanup any remaining RG flag 
  ; 
  exten => s,n,GotoIf($[ "x${USE_CONFIRMATION}" = "x" | "x${RINGGROUP_INDEX}" = "x" | "${CHANNEL}" != "${UNIQCHAN}"]?skiprg) 
  exten => s,n,Noop(Cleaning Up Confirmation Flag: RG/${RINGGROUP_INDEX}/${CHANNEL}) 
  exten => s,n,DBDel(RG/${RINGGROUP_INDEX}/${CHANNEL})

and edit it, so it will look like this: 

  [macro-hangupcall] 
  ;exten => s,1,ResetCDR(w) 
  ;exten => s,n,NoCDR() 
 
  ; Cleanup any remaining RG flag 
  ; 
  exten => s,1,GotoIf($[ "x${USE_CONFIRMATION}" = "x" | "x${RINGGROUP_INDEX}" = "x" | "${CHANNEL}" != "${UNIQCHAN}"]?skiprg) 
  exten => s,n,Noop(Cleaning Up Confirmation Flag: RG/${RINGGROUP_INDEX}/${CHANNEL}) 
  exten => s,n,DBDel(RG/${RINGGROUP_INDEX}/${CHANNEL})

as you will see, that will comment the first two lines of the context, and the next line will have the priority 1, instead of n save the file and exit, the on the sheel execute the following command: asterisk -rx "reload"

I have made the changes suggested above and in very limited testing (three calls) it seems to fix the problem, but I don't know if this creates any other issues. I'm particularly wondering if commenting out the entire macro-hangupcall context (except for the context header) is a good idea, but without letting this run for a while I can't say if there are any other potential implications.

03/09/09 12:41:30 changed by p_lindheimer

I believe we looked at this, removing this will end up in some un-answered calls having no CDR records written. This issue does appear to be related to the version of Asterisk as there are lots of installs that are not writing double entries. We've left the ticket open until we can pin-point if there is an Asterisk fix to address this (or which version is is addressed), or otherwise if there is something that we can change if the problem is how we are instructing Asterisk to do things.

03/23/09 12:32:51 changed by p_lindheimer

here's a thought that some testers can try: 

Index: extensions.conf
===================================================================
--- extensions.conf     (revision 7550)
+++ extensions.conf     (working copy)
@@ -292,12 +292,9 @@
 
 ; What to do on hangup.                                         
 [macro-hangupcall]
-exten => s,1,ResetCDR(vw)
-exten => s,n,NoCDR()
- 
 ; Cleanup any remaining RG flag
 ;
-exten => s,n,GotoIf($[ "x${USE_CONFIRMATION}" = "x" | "x${RINGGROUP_INDEX}" = "x" | "${CHANNEL}" != "${UNIQCHAN}"]?skiprg)
+exten => s,1,GotoIf($[ "x${USE_CONFIRMATION}" = "x" | "x${RINGGROUP_INDEX}" = "x" | "${CHANNEL}" != "${UNIQCHAN}"]?skiprg)
 exten => s,n,Noop(Cleaning Up Confirmation Flag: RG/${RINGGROUP_INDEX}/${CHANNEL})
 exten => s,n,DBDel(RG/${RINGGROUP_INDEX}/${CHANNEL})

The resetcdr/nocdr was originally in there from a time, many moons ago, when there was a 'wait(5)' in that macro as well and I think it was there so that wait did not get included in the cdr. Since the remaining instructions in the macro are simple bookeeping that will not add to the time of the call, removing both calls all together may have the desired results.

I still believe there is a bug somewhere in Asterisk since the double CDR is not seen on all systems, but if we no longer need these two instructions, getting rid of them may fix this issue. I'd just like some testing and feedback from other eyes to confirm whether this would somehow break something else in the CDR system.

03/24/09 09:40:00 changed by wiseoldowl

I've been testing that patch here and so far I'm not seeing double entries, and it does appear that both answered and unanswered calls are being shown. I've only been running it for a day or so, so I guess I'm not prepared to go out on a limb and say that it will work perfectly in every conceivable situation, but what I'm seeing so far is exactly what I'd expect to see.

03/24/09 09:43:35 changed by wiseoldowl

(I should add that I had installed the previous patch from about three or four messages up, which did essentially the same thing and it was also working fine, but got wiped out by the last set of module upgrades. So I installed p_lindheimer's patch yesterday and now the double entries are gone again).

05/07/09 20:35:14 changed by p_lindheimer

  • status changed from new to closed.
  • resolution set to fixed.

(In [7697]) fixes #3478 this appears to be an asterisk issue as it does not happen on all systems. Putting patch into 2.6 and after proper testing we can look at back porting it to 2.5

08/02/09 19:51:37 changed by p_lindheimer

(In [7917]) Merged revisions 7697,7699-7701,7703-7707,7709-7710,7713-7722,7725-7731,7735-7736,7739-7740,7744-7751,7753-7758,7761,7763,7765-7769,7771-7774,7776-7785,7787,7789-7791,7793-7794,7798,7806,7808-7809,7811-7813,7816,7818-7821,7838,7858-7865,7867,7871,7875-7878,7881-7882,7886-7887,7889-7890,7892-7893,7895-7896,7901 via svnmerge from http://svn.freepbx.org/modules/branches/2.6

........

r7697 | p_lindheimer | 2009-05-07 20:35:14 -0700 (Thu, 07 May 2009) | 1 line

fixes #3478 this appears to be an asterisk issue as it does not happen on all systems. Putting patch into 2.6 and after proper testing we can look at back porting it to 2.5

........

r7713 | mickecarlsson | 2009-05-08 12:38:29 -0700 (Fri, 08 May 2009) | 1 line

Fixed spelling errors in dialparties.agi

........

r7721 | xrobau | 2009-05-13 15:48:19 -0700 (Wed, 13 May 2009) | 2 lines

Apply fixes from #3423

........

r7728 | mickecarlsson | 2009-05-14 21:57:43 -0700 (Thu, 14 May 2009) | 1 line

Fixed spelling errors in extensions.conf

........

r7731 | xrobau | 2009-05-15 11:33:22 -0700 (Fri, 15 May 2009) | 2 lines

Minor tabindex warning cleanups

........

r7751 | p_lindheimer | 2009-05-26 12:42:42 -0700 (Tue, 26 May 2009) | 1 line

closes #3691 added usage of EXTENSION_STATE in dialparties in place of manager connection when present

........

r7753 | p_lindheimer | 2009-05-26 16:27:57 -0700 (Tue, 26 May 2009) | 1 line

use the STAT() function in place of the checksound.agi script for Asterisk 1.4+ systems, in vmx locater, to check for file

........

r7754 | p_lindheimer | 2009-05-26 17:11:23 -0700 (Tue, 26 May 2009) | 1 line

fixes #3693 change ZAP to DAHDI in trunk tech when generating config in ZAP2DAHDI compatibility mode

........

r7784 | p_lindheimer | 2009-06-01 12:19:05 -0700 (Mon, 01 Jun 2009) | 1 line

fixes #3705 so & can be used in sip and iax secrets, also modifies core_trunks_getDetails to provide a table of all the trunks from the new trunk table if no paramter is passed

........

r7838 | p_lindheimer | 2009-06-20 09:46:08 -0700 (Sat, 20 Jun 2009) | 1 line

add alwaysauthreject=yes to sip settings to enhance security

........

r7871 | p_lindheimer | 2009-06-26 22:04:39 -0700 (Fri, 26 Jun 2009) | 1 line

fix bug when accessing a stale page where the trunk no longer exists and no technology type is returned resulting in a sql query accessing a blank table

........

r7901 | p_lindheimer | 2009-07-25 08:43:58 -0700 (Sat, 25 Jul 2009) | 1 line

fixes #3792 create astman handle from AGI's unique 'new' function

........