Summary:	ASTERISK-11118: Allow for the conditional logging of CDRs based on call disposition
Reporter:	Stephen Kratzer (kratzers)	Labels:
Date Opened:	2007-12-27 13:52:47.000-0600	Date Closed:	2008-04-30 09:47:19
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	CDR/NewFeature
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) dispositionmask.patch ( 1) dispositionmask.patch.1
Description:	In our setting, we've found it desirable to log CDRs conditionally based on the call disposition. For instance, only log CDRs for calls that were either answered or not answered. Attached is a patch which allows users to specify the dispositions to log using a mask (inverse) such as NOANSWER|ANSWERED. The default is to log everything: FAILED|BUSY|NOANSWER|ANSWERED. Note: This serves a different purpose than "unanswered" and, for this purpose, is much more granular. ****** ADDITIONAL INFORMATION ****** Path: . URL: http://svn.digium.com/svn/asterisk/trunk Repository Root: http://svn.digium.com/svn/asterisk Repository UUID: 65c4cc65-6c06-0410-ace0-fbb531ad65f3 Revision: 94974 Node Kind: directory Schedule: normal Last Changed Author: file Last Changed Rev: 94934 Last Changed Date: 2007-12-27 12:34:00 -0500 (Thu, 27 Dec 2007)
Comments:	By: Stephen Kratzer (kratzers) 2007-12-29 07:33:26.000-0600 Fixed a few issues with the initial patch and did some fail-proofing. dispositionmask.patch.1 obsoletes dispositionmask.patch. By: Tilghman Lesher (tilghman) 2008-02-11 12:10:22.000-0600 The neat thing is that you can already do something like this in cdr_adaptive_odbc, via the filter mechanism. By: Stephen Kratzer (kratzers) 2008-02-12 08:00:26.000-0600 Initially, I had written a patch to do this for cdr_addon_mysql, but it was suggested that it be moved to the core of Asterisk so that it would be global across all CDR modules. If a user wishes to filter on a per-module basis, the default setting for this would allow that also. Dunno. By: Jason Parker (jparker) 2008-03-20 14:04:45 I don't really see much of a need for this.  Records can easily be filtered out afterwards.  This is the same logic we applied for other "unwanted" CDRs. By: Donny Kavanagh (donnyk) 2008-03-21 02:02:44 I agree w/ qwell i'm not sure i see the point, you can easily filter the records you want with any of the backends.  The only situation i can see this being of any use in would be the cdr_manager backend.  In that situation you may only want to see manager events for certain types of cdr's.  Besides that i dont see why you cannot filter at the destination. By: Stephen Kratzer (kratzers) 2008-04-30 09:39:49 That's fine. Though I do think it's backwards to generate unwanted data that will have to be sifted through later. It's like not using an RBL because you use SPAM filtering software or not blocking a DDoS at the edge of a network because you're running a firewall on the end system. Feel free to close this issue. By: Tilghman Lesher (tilghman) 2008-04-30 09:47:19 It's actually different from spam filtering.  CDRs are logs, and as a system administrator, you never try to filter just the messages you think are important; you log the general cases, and filter out the messages you don't want afterwards.  You never want to be in the situation where you have failed to log enough information.  Too much is always better than too little. Closing, as requested.