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-0600Date Closed:2008-04-30 09:47:19
Versions:Frequency of
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.


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.