[Home]

Summary:ASTERISK-12240: NoCDR() is not working
Reporter:Private Name (falves11)Labels:
Date Opened:2008-06-20 16:02:58Date Closed:2008-07-02 19:09:10
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) blowup1.txt
Description:I have this tiny dialplan:
exten =>_X.,1,NoCDR() ;bridge does not store cdr
exten =>_X.,n,NoOp(${CHANNEL(channeltype)})
exten =>_X.,n,GotoIf($["${CHANNEL(channeltype)}" = "H323"]?default,${EXTEN},300)
exten =>_X.,n,Set(SIPIP=${SIPCHANINFO(recvip)})
exten =>_X.,n,Set(CALLERPRES()=allowed)
exten =>_X.,n,Set(SIPIP=${SIPCHANINFO(recvip)})
exten =>_X.,n(entrada),Set(CALLERID(name)=${SIPIP})
exten =>_X.,n,Verbose(0,Callerid: ${CALLERID(num)} From: ${CALLERID(name)} To: ${EXTEN})
exten =>_X.,n,GotoIf($["${EXTEN:0:1}" = "1"]?dialout,${EXTEN},1)
exten =>_X.,n,GotoIf($["${EXTEN:0:1}" = "0"]?dialout,${EXTEN},1)
exten =>_X.,n,Goto(dialout,${EXTEN},1)
exten =>_X.,100,Hangup(34)
exten =>_X.,300,NoOp(${CHANNEL})
exten =>_X.,301,Set(SIPIP=${CUT(CHANNEL,:,1):8})
exten =>_X.,302,Goto(entrada)

[dialout]
exten =>_#X.,1,NoCDR()
exten =>_#X.,n,Dial(SIP/${EXTEN:1}@${GW},45,L(3600000))
exten =>_#X.,n,Hangup()
exten =>_X.,1,NoCDR()
exten =>_X.,n,Dial(SIP/${EXTEN}@${GW},45,L(3600000))
exten =>_X.,n,Hangup()


****** ADDITIONAL INFORMATION ******

Yet I have cdr_odb loaded and I get a record for every call. I need to have cdr_odb loaded because in another context of the dialplan I need to save the cdr, but not in this one, and it generates thousands of records per hour. How do I avoid generating CDR records in this context??
Please notice that I included again, by second time, NoCDR() in the [dialout] context, but it makes no difference.
Comments:By: Steve Murphy (murf) 2008-06-23 10:34:49

falves11 -- Since you have reported this problem against trunk,
I need to ask if my CDRfix6 branch fixes the problem...
The CDRfix5 branch is based on trunk, but includes more than
just the fixes.


http://svn.digium.com/svn/asterisk/team/murf/CDRfix6

Can you check out this branch and let me know? Please
let me know what new problems you might have as a result
of the changes in the CDRfix6 branch...


By: Private Name (falves11) 2008-06-23 11:40:53

can you provideinstructions as how to download the branch?
I normally use this command to download my Trunk:
svn co http://svn.digium.com/svn/asterisk/trunk asterisk
By: Steve Murphy (murf) 2008-06-23 12:20:04

yes, you would do roughly the same:

svn co http://svn.digium.com/svn/asterisk/team/murf/CDRfix6

should check this out and leave it in "CDRfix6".

If you want it in some other directory, you can say:

svn co http://svn.digium.com/svn/asterisk/team/murf/CDRfix6 someother

(and try to ignore the [^] stuff inserted by the bug tracker.
By: Ronald Chan (loloski) 2008-06-23 12:21:31

falves11,

same thing just do svn co http://svn.digium.com/svn/asterisk/team/murf/CDRfix6 trunk that should do it :)
By: Private Name (falves11) 2008-06-23 13:02:22

The code works fine relating to the NoCDR() part but blows up every 3 mins.

Loaded symbols for /lib64/libgcc_s.so.1
Core was generated by `/usr/sbin/asterisk -vvvf >/dev/null'.
Program terminated with signal 11, Segmentation fault.
#0  0x00002aaac5afb716 in pthread_timer_disable_continuous (handle=Cannot access memory at address 0x3ffec
) from /usr/lib/asterisk/modules/res_timing_pthread.so
(gdb) bt full
#0  0x00002aaac5afb716 in pthread_timer_disable_continuous (handle=Cannot access memory at address 0x3ffec
) from /usr/lib/asterisk/modules/res_timing_pthread.so
       timer = (struct pthread_timer *) Cannot access memory at address 0x3fff8
(gdb)
By: Private Name (falves11) 2008-06-23 14:31:04

I think the culprit is a new module, res_timing_pthread.so. Maybe somebody could explain what does it do? The box where I have autoload=yes is blowing up, the other ones are stable
By: Private Name (falves11) 2008-06-23 14:55:52

It is confirmed: I included noload=res_timing_pthread.so and the application has not blown up. Your CDR code works fine. Please merge it.
I need some help with understanding what modules should I explicitly load for my dialplan, since I cannot obviously use autoload=yes. My dialplan is short, should I upload it? os there a way to know precisely what modules should I load?
By: Steve Murphy (murf) 2008-06-23 16:09:46

falves11-- many, many thanks for testing the CDRfix code!
I have a few other bugs depending on these changes, and as soon as
what "feels" like a sufficient number of them respond positively, I will
commit the CDRfix code to 1.4, trunk, and 1.6.0. Hopefully this week!

As to the pthread timer code, just keep the noload in place until this brand
new module gets some more testing and bug fixes. The problems will be found
soon, hopefully, and fixed, which will allow you the luxury of a choice between
the two.
By: Private Name (falves11) 2008-07-01 19:39:12

I need to know when the fix for NoCDR() will be merged. It is affecting my business.
Thanks a lot.
By: Digium Subversion (svnbot) 2008-07-02 19:09:08

Repository: asterisk
Revision: 127663

U   branches/1.4/channels/chan_dahdi.c
U   branches/1.4/channels/chan_sip.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/main/pbx.c
U   branches/1.4/res/res_features.c

------------------------------------------------------------------------
r127663 | murf | 2008-07-02 19:08:58 -0500 (Wed, 02 Jul 2008) | 30 lines

The CDRfix4/5/6 omnibus cdr fixes.

(closes issue ASTERISK-10481)
Reported by: murf
Tested by: murf, deeperror

(closes issue ASTERISK-12240)
Reported by: falves11
Tested by: murf, falves11


(closes issue ASTERISK-11309)
Reported by: greyvoip

As to 11849, I think these changes fix the core problems
brought up in that bug, but perhaps not the more global
problems created by the limitations of CDR's themselves
not being oriented around transfers.

Reopen if necc, but bug reports are not the best
medium for enhancement discussions. We need to start
a second-generation CDR standardization effort to cover
transfers.

(closes issue ASTERISK-10625)
Reported by: rossbeer
Tested by: greyvoip, murf



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

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