[Home]

Summary:ASTERISK-12545: NoCDR does not work as expected in latest SVN
Reporter:Joerg Staedele (brainy)Labels:
Date Opened:2008-08-09 03:11:11Date Closed:2008-09-12 00:05:07
Priority:MinorRegression?No
Status:Closed/CompleteComponents:CDR/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 13263.diff2
Description:We are using NoCDR to not record incoming calls. With the latest SVN it doesnt work anymore as expected since there is a CDR recorded but not with all details:

Example (with NoCDR in the dialrule):
  calldate: 2008-08-09 10:14:07
      clid:
       src:
       dst: s
  dcontext: internal
   channel: SIP/v1941001-08381800
dstchannel:
   lastapp:
  lastdata:
  duration: 6
   billsec: 6
disposition: ANSWERED
  amaflags: 3
accountcode:
  uniqueid:
 userfield:
        id: 22876
      bill: 1
  exported: 0

and without NoCDR (the full entry is generated):
  calldate: 2008-08-09 10:13:24
      clid: "anonymous" <anonymous>
       src: anonymous
       dst: 4989xxxxxxxx
  dcontext: call
   channel: SIP/80.237.199.41-082bc1e8
dstchannel: SIP/v1941001-08375e00
   lastapp: Dial
  lastdata: SIP/v1941001/498938539262999
  duration: 6
   billsec: 6
disposition: ANSWERED
  amaflags: 3
accountcode:
  uniqueid:
 userfield:
        id: 22875
      bill: 0
  exported: 0

Comments:By: Steve Murphy (murf) 2008-08-11 15:39:42

This is very interesting. NoCDR() used to (in 1.2) just remove the cdr struct from the channel. It would then be replaced with a new, freshly created cdr struct automatically, usually, by the pbx engine. I replaced this with code that sets the  AST_CDR_FLAG_POST_DISABLED flag. With this flag set, the detach/post mechanism will not post the CDR.

So, you are doing something else with the CDR. Please show relevant dialplan code that does the NoCDR() call, and subsequent calls.
By: Joerg Staedele (brainy) 2008-08-12 04:39:10

For incoming calls we have:

[incoming]

exten => _+X.,1,Goto(incoming-call,${EXTEN:1},1)
exten => _00X.,1,Goto(incoming-call,${EXTEN:2},1)
exten => _X.,1,Goto(incoming-call,${EXTEN},1)

[incoming-call]

exten => _X.,1,NoCDR
exten => _X.,2,Set(NEX=Y)
exten => _X.,3,ExecIf($["${CALLERID(num)}" = "anonymous" ]|SetCallerPres|prohib_not_screened)
exten => _X.,4,ExecIf($["${CALLERID(num)}" : "\\+" ]|Set|CALLERID(num)=${CALLERID(num):1})
exten => _X.,5,Goto(call,${EXTEN},1)

Context "call" is:
[call]
switch => Realtime/internal@extensions

And within the realtime there's only the Dial() to the specific peer.

Nothing else.
By: Digium Subversion (svnbot) 2008-08-20 12:06:02

Repository: asterisk
Revision: 139074

U   branches/1.4/main/cdr.c

------------------------------------------------------------------------
r139074 | murf | 2008-08-20 12:06:01 -0500 (Wed, 20 Aug 2008) | 12 lines


(closes issue ASTERISK-12545)
Reported by: brainy
Tested by: murf

The specialized reset routine is tromping on the
flags field of the CDR. I made a change to not
reset the DISABLED bit. This should get rid of this
problem.



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

http://svn.digium.com/view/asterisk?view=rev&revision=139074
By: Joerg Staedele (brainy) 2008-08-21 03:56:03

Just upgraded to latest SVN and the problem is still there ->

*************************** 1. row ***************************
  calldate: 2008-08-21 11:01:19
      clid:
       src:
       dst: s
  dcontext: internal
   channel: SIP/v1941001-08226980
dstchannel:
   lastapp:
  lastdata:
  duration: 22
   billsec: 22
disposition: ANSWERED
  amaflags: 3
accountcode:
  uniqueid:
 userfield:
        id: 29344
      bill: 1
  exported: 0
1 row in set (0.03 sec)




vgw1*CLI> show version
Asterisk SVN-branch-1.4-r139213M built by root @ localhost on a i686 running Linux on 2008-08-21 08:42:47 UTC

By: Steve Murphy (murf) 2008-09-11 13:24:48

Try applying the attached 13263.diff2 patch to your 1.4 source, and see if it gets rid of the unwanted CDR's.

It looks good to me, but I'll hold off merging it to all releases until I've heard from you, unless you take more than a day to do so...
By: Steve Murphy (murf) 2008-09-12 00:05:04

Too late. Sorry. I accidentally merged it into source with the
fixes for bug 13364. Feel free to test the changes against the current
svn version of your release, and see if it solves this problem.

If, heaven forbid, it does not, or worse yet, introduces new problems,
feel free to re-open this issue, and we'll take another stab at it.