aboutsummaryrefslogtreecommitdiffstats
path: root/main/cdr.c
AgeCommit message (Collapse)AuthorFilesLines
2010-04-22Fix broken CDR behavior.mnicholson1-6/+3
This change allows a CDR record previously marked with disposition ANSWERED to be set as BUSY or NO ANSWER. Additionally this change partially reverts r235635 and does not set the AST_CDR_FLAG_ORIGINATED flag on CDRs generated from ast_call(). To preserve proper CDR behavior, the AST_CDR_FLAG_DIALED flag is now cleared from all brige CDRs in ast_bridge_call(). (closes issue #16797) Reported by: VarnishedOtter Tested by: mnicholson git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@258670 f38db490-d61c-443f-a65b-d21fe96a405b
2010-01-22Add Dialed Number Identifier (DNID) field to cdr.alecdavis1-0/+1
Branch support, retains ABI, if backend CDR collector is adaptive then database requires 'dnid' field to be added, otherwise no functional changes. Reported by: alecdavis Tested by: alecdavis Patch cdr_dnid.diff2.txt uploaded by alecdavis (license 585) Review: https://reviewboard.asterisk.org/r/455/ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@242142 f38db490-d61c-443f-a65b-d21fe96a405b
2009-08-10AST-2009-005tilghman1-2/+2
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@211528 f38db490-d61c-443f-a65b-d21fe96a405b
2009-05-29Use AST_CDR_NOANSWER instead of AST_CDR_NULL as the default CDR disposition.mnicholson1-2/+10
This change also involves the addition of an AST_CDR_FLAG_ORIGINATED flag that is used on originated channels to distinguish: them from dialed channels. (closes issue #12946) Reported by: meral Patches: null-cdr2.diff uploaded by mnicholson (license 96) Tested by: mnicholson, dbrooks (closes issue #15122) Reported by: sum Tested by: sum git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@198068 f38db490-d61c-443f-a65b-d21fe96a405b
2009-05-21This commit prevents cdr records with AST_CDR_FLAG_ANSLOCKED and ↵mnicholson1-0/+24
AST_CDR_FLAG_LOCKED from being updated in certain cases. This is accomplished by adding two functions to update the answer time and disposition of calls that checks for the proper lock flags. These functions are used in the ast_bridge_call() function so that ForkCDR(A) calls are respected. This patch also modifies the way ast_bridge_call() chooses the cdr record to base the bridged_cdr on. Previously the first unlocked cdr record would be chosen, now instead the first cdr record is chosen and forked cdr records are moved to the bridge_cdr. This allows the original cdr record and any forked cdr records to be properly updated with answer and end times. (closes issue #13797) Reported by: sh0t Tested by: sh0t (closes issue #14744) Reported by: deepesh git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@195881 f38db490-d61c-443f-a65b-d21fe96a405b
2008-11-25(closes issue #12694)murf1-0/+3
Reported by: yraber Patches: 12694.2nd.diff uploaded by murf (license 17) Tested by: murf, laurav Thanks to file (Joshua Colp) for his IAX fix. the change to cdr.c allows no-answer to percolate up into CDR's, and feels like the right place to locate this fix; if BUSY is done here, no-answer should be, too. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@159316 f38db490-d61c-443f-a65b-d21fe96a405b
2008-10-30instead of comparing the string pointer to 0, let's compare the value that ↵kpfleming1-2/+2
was actually parsed out of the string (found by sparse) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@152811 f38db490-d61c-443f-a65b-d21fe96a405b
2008-09-02I am turning the warnings generated in ast_cdr_free and post_cdr into ↵murf1-10/+10
verbose level 2 messages. Really, they matter little to end users. You either get the CDR's you wanted, or you don't, and it is a bug. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@140747 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-20(closes issue #13263)murf1-4/+7
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. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139074 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-05(closes issue #12982)murf1-0/+5
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. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@135799 f38db490-d61c-443f-a65b-d21fe96a405b
2008-07-15remove 4 lines of redundant code.mvanbaak1-4/+0
(closes issue #13080) Reported by: gknispel_proformatique Patches: trunk_ast_cdr_setapp.patch uploaded by gknispel (license 261) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@131012 f38db490-d61c-443f-a65b-d21fe96a405b
2008-07-03The CDRfix4/5/6 omnibus cdr fixes.murf1-1/+32
(closes issue #10927) Reported by: murf Tested by: murf, deeperror (closes issue #12907) Reported by: falves11 Tested by: murf, falves11 (closes issue #11849) 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 #11093) Reported by: rossbeer Tested by: greyvoip, murf git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@127663 f38db490-d61c-443f-a65b-d21fe96a405b
2008-06-12Arkadia tried to warn me, but the code added to ast_cdr_busy, _failed, and ↵murf1-12/+0
_noanswer was redundant. Didn't spot it until I was resolving conflicts in trunk. Ugh. Redundant code removed. It wasn't harmful. Just dumb. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@122127 f38db490-d61c-443f-a65b-d21fe96a405b
2008-06-12(closes issue #10668)murf1-0/+20
Reported by: arkadia Tested by: murf, arkadia Options added to forkCDR() app and the CDR() func to remove some roadblocks for CDR applications. The "show application ForkCDR" output was upgraded to more fully explain the inner workings of forkCDR. The A option was added to forkCDR to force the CDR system to NOT change the disposition on the original CDR, after the fork. This involves ast_cdr_answer, _busy, _failed, and so on. The T option was added to forkCDR to force obedience of the cdr LOCKED flag in the ast_cdr_end, all the disposition changing funcs (ast_cdr_answer, etc), and in the ast_cdr_setvar func. The CHANGES file was updated to explain ALL the new options added to satisfy this bug report (and some requests made verbally and via email, irc, etc, over the past months/year) The 's' option was added to the CDR() func, to force it to skip LOCKED cdr's in the chain. Again, the new options should be totally transparent to existing apps! Current behavior of CDR, forkCDR, and the rest of the CDR system should not change one little bit. Until you add the new options, at least! git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@122046 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-29(closes issue #10668)murf1-33/+40
(closes issue #11721) (closes issue #12726) Reported by: arkadia Tested by: murf These changes: 1. revert the changes made via bug 10668; I should have known that such changes, even tho they made sense at the time, seemed like an omission, etc, were actually integral to the CDR system via forkCDR. It makes sense to me now that forkCDR didn't natively end any CDR's, but rather depended on natively closing them all at hangup time via traversing and closing them all, whether locked or not. I still don't completely understand the benefits of setvar and answer operating on locked cdrs, but I've seen enough to revert those changes also, and stop messing up users who depended on that behavior. bug 12726 found reverting the changes fixed his changes, and after a long review and working on forkCDR, I can see why. 2. Apply the suggested enhancements proposed in 10668, but in a completely compatible way. ForkCDR will behave exactly as before, but now has new options that will allow some actions to be taken that will slightly modify the outcome and side-effects of forkCDR. Based on conversations I've had with various people, these small tweaks will allow some users to get the behavior they need. For instance, users executing forkCDR in an AGI script will find the answer time set, and DISPOSITION set, a situation not covered when the routines were first written. 3. A small problem in the cdr serializer would output answer and end times even when they were not set. This is now fixed. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@118858 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-10Move where unanswered CDRs are dropped to the CDR core, not everything uses ↵file1-5/+6
app_dial. (closes issue #11516) Reported by: ys Patches: branch_1.4_cdr.diff uploaded by ys (license 281) Tested by: anest, jcapp, dartvader git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@107016 f38db490-d61c-443f-a65b-d21fe96a405b
2008-02-28Make pbx_exec pass an empty string into applications, if we get NULL.qwell1-6/+2
This protects against possible segfaults in applications that may try to use data before checking length (ast_strdupa'ing it, for example) (closes issue #12100) Reported by: foxfire Patches: 12100-nullappargs.diff uploaded by qwell (license 4) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@105005 f38db490-d61c-443f-a65b-d21fe96a405b
2008-01-27When deleting a task from the scheduler, ignoring the return value couldtilghman1-5/+3
possibly cause memory to be accessed after it is freed, which causes all sorts of random memory corruption. Instead, if a deletion fails, wait a bit and try again (noting that another thread could change our taskid value). (closes issue #11386) Reported by: flujan Patches: 20080124__bug11386.diff.txt uploaded by Corydon76 (license 14) Tested by: Corydon76, flujan, stuarth` git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@100465 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-27closes issue #11379; OK, this is an attempt to make both sides happy. To the ↵murf1-2/+11
cdr.conf file, I added the option 'unanswered', which defaults to 'no'. In this mode, you will see a cdr for a call, whether it was answered or not. The disposition will be NO ANSWER or ANSWERED, as appropriate. The src is as you'd expect, the destination channel will be one of the channels from the Dial() call, usually the last in the list if more than one chan was specified. With unanswered set to 'yes', you will still see this cdr entry in both cases. But in the case where the dial timed out, you will also see a cdr for each line attempted, marked NO ANSWER, with no destination channel name. The new option defaults to 'no', so you don't see the pesky extra cdr's by default, and you will not see the irritating 'not posted' messages. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@89622 f38db490-d61c-443f-a65b-d21fe96a405b
2007-09-21gcc 4.2 has a new set of warnings dealing with cosnt pointers. This set ofrussell1-1/+1
changes gets all of Asterisk (minus chan_alsa for now) to compile with gcc 4.2. (closes issue #10774, patch from qwell) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@83432 f38db490-d61c-443f-a65b-d21fe96a405b
2007-09-14closes issue #10668; thanks to arkadia for his patch; had to leave out the ↵murf1-26/+32
bit about ending the previous cdr in the fork; it would destroy current implementations. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@82444 f38db490-d61c-443f-a65b-d21fe96a405b
2007-09-11this change should fix issue # 10659 -- what I worry about is how many other ↵murf1-0/+2
bug reports it may generate. Hopefully, we can please the/a majority. Hopefully. We shall see. Calls not marked ANSWERED and with only one channel name will not be posted. This should eliminate the double CDR's. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@82261 f38db490-d61c-443f-a65b-d21fe96a405b
2007-08-30via issue 10599, where 'CDR already initialized' messages are being ↵murf1-2/+0
generated. Since all channels will have an init'd CDR attached at creation time, this message is now particularly useless. Removed. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@81392 f38db490-d61c-443f-a65b-d21fe96a405b
2007-08-24From a complaint by jmls, I realize that the message in cdr_disposition is ↵murf1-9/+5
unnecessary. To get failure disposition, just return -1; no use having more than one case do that. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@80789 f38db490-d61c-443f-a65b-d21fe96a405b
2007-08-10Re bug behavior mentioned in #asterisk, made this tweak to code, to prevent ↵murf1-0/+1
hundreds of log messages from being generated git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@79049 f38db490-d61c-443f-a65b-d21fe96a405b
2007-08-10This will help debug; from a question asked on #asteriskmurf1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@79044 f38db490-d61c-443f-a65b-d21fe96a405b
2007-07-09Give Agent channel names priority when doing CDR merging. (issue #10011 ↵file1-1/+1
reported by krtorio) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@73980 f38db490-d61c-443f-a65b-d21fe96a405b
2007-06-29Minor change for older GCC versions.file1-2/+2
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@72599 f38db490-d61c-443f-a65b-d21fe96a405b
2007-06-25Fix it so 1.4 actually compiles on my box.file1-2/+2
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@71422 f38db490-d61c-443f-a65b-d21fe96a405b
2007-06-23This patch is meant to fix 8433; where clid and src are lost via bridging.murf1-7/+69
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@71230 f38db490-d61c-443f-a65b-d21fe96a405b
2007-06-22My conditions for merging amaflags info was naive; DOCUMENTATION is the ↵murf1-4/+5
default, although null is possible; theft of user-settable fields is not good. Just copy them, leave them alone. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@71063 f38db490-d61c-443f-a65b-d21fe96a405b
2007-06-21Merged revisions 70948 via svnmerge from murf1-2/+5
https://origsvn.digium.com/svn/asterisk/branches/1.2 ........ r70948 | murf | 2007-06-21 16:29:50 -0600 (Thu, 21 Jun 2007) | 1 line This little fix is in response to bug 10016, but may not cure it. The code is wrong, clearly. In a situation where you set the CDR's amaflags, and then ForkCDR, and then set the new CDR's amaflags to some other value, you will see that all CDRs have had their amaflags changed. This is not good. So I fixed it. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@70949 f38db490-d61c-443f-a65b-d21fe96a405b
2007-06-21Via complaints aired in asterisk-users, I submit these changes, which allow ↵murf1-7/+6
cdr updates to see macro context/exten, whether hung up or not git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@70656 f38db490-d61c-443f-a65b-d21fe96a405b
2007-06-14use ast_localtime() in every place localtime_r() was being usedkpfleming1-1/+2
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@69392 f38db490-d61c-443f-a65b-d21fe96a405b
2007-06-04This typo has been here since 1.4 forked. It has been the source of ↵murf1-1/+1
heartburn to many a dialplan/CDR programmer. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@67073 f38db490-d61c-443f-a65b-d21fe96a405b
2007-05-18Ugh. The svnmerge didn't catch the shift from cdr.c to main/cdr.c, and ↵murf1-2/+20
neither did I. This is the remainder of the 9717 patch, the fix for the run-away FAIL status for a call git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@65201 f38db490-d61c-443f-a65b-d21fe96a405b
2007-05-14As per 9570, worrisome CDR warnings have been removed, that are either not ↵murf1-10/+0
helpful, or not relevant. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@64193 f38db490-d61c-443f-a65b-d21fe96a405b
2007-05-02Merged revisions 62737 via svnmerge from murf1-3/+5
https://origsvn.digium.com/svn/asterisk/branches/1.2 ........ r62737 | murf | 2007-05-02 14:10:32 -0600 (Wed, 02 May 2007) | 1 line Some tweaks to satisfy CDR bug 8796, where being in 'h' extension louses up the dst field ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@62738 f38db490-d61c-443f-a65b-d21fe96a405b
2007-04-13This is a fix to the way CDR merge handles the data that results from ForkCDR.murf1-4/+17
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@61658 f38db490-d61c-443f-a65b-d21fe96a405b
2007-04-10Finished up a previous fix to overcome a compiler warning; the app NoCDR() ↵murf1-1/+12
has been updated to mark the channel CDR as POST_DISABLED instead of destroying the CDR; this way its flags are propagated thru a bridge and the CDR is actually dropped. The cases where only one channel in a bridge has a CDR was cleaned up. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@61136 f38db490-d61c-443f-a65b-d21fe96a405b
2007-04-09This is a big improvement over the current CDR fixes. It may still need ↵murf1-17/+54
refinement, but this won't have as many folks bothered. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@60989 f38db490-d61c-443f-a65b-d21fe96a405b
2007-03-30several changes via kpflemings reviewmurf1-4/+27
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@59522 f38db490-d61c-443f-a65b-d21fe96a405b
2007-03-30These mods fix CDR issues from 8221, 8593, 8680, 8743, and perhaps others. ↵murf1-0/+106
Mainly with CDRs generated from transfer situations. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@59486 f38db490-d61c-443f-a65b-d21fe96a405b
2007-01-31Merged revisions 53045 via svnmerge from russell1-0/+1
https://origsvn.digium.com/svn/asterisk/branches/1.2 ........ r53045 | russell | 2007-01-31 15:25:11 -0600 (Wed, 31 Jan 2007) | 3 lines Fix a bunch of places where pthread_attr_init() was called, but pthread_attr_destroy() was not. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@53046 f38db490-d61c-443f-a65b-d21fe96a405b
2006-12-27since these variables all have static duration, none of them need ↵kpfleming1-1/+1
initializers (they default to zero anyway) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@49006 f38db490-d61c-443f-a65b-d21fe96a405b
2006-11-30Merged revisions 48151 via svnmerge from file1-5/+5
https://origsvn.digium.com/svn/asterisk/branches/1.2 ........ r48151 | file | 2006-11-30 13:42:45 -0500 (Thu, 30 Nov 2006) | 2 lines Print certain CDR messages out at the NOTICE level versus WARNING since they can occur when used with the CDR applications and are perfectly fine. (issue #8367 reported by dartvader) ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@48152 f38db490-d61c-443f-a65b-d21fe96a405b
2006-10-25apparently developers are still not aware that they should be use ↵kpfleming1-1/+1
ast_copy_string instead of strncpy... fix up many more users, and fix some bugs in the process git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@46200 f38db490-d61c-443f-a65b-d21fe96a405b
2006-10-04update thread creation code a bitkpfleming1-2/+2
reduce standard thread stack size slightly to allow the pthreads library to allocate the stack+data and not overflow a power-of-2 allocation in the kernel and waste memory/address space add a new stack size for 'background' threads (those that don't handle PBX calls) when LOW_MEMORY is defined git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@44378 f38db490-d61c-443f-a65b-d21fe96a405b
2006-09-18merge qwell's CLI verbification workkpfleming1-8/+4
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@43212 f38db490-d61c-443f-a65b-d21fe96a405b
2006-09-07Merged revisions 42260 via svnmerge from file1-3/+4
https://origsvn.digium.com/svn/asterisk/branches/1.2 ........ r42260 | file | 2006-09-07 12:30:44 -0400 (Thu, 07 Sep 2006) | 2 lines Let's use the same thing we use in other places to calculate our time for ast_cond_timedwait (issue #7697 reported by bn999) ........ git-svn-id: http://svn.digium.com/svn/asterisk/trunk@42261 f38db490-d61c-443f-a65b-d21fe96a405b
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-20 23:20:01 +0000