[asterisk-dev] [Code Review] 2378: A CDR Specification for Asterisk 12

[Matt Jordan]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2378/
-----------------------------------------------------------

(Updated Sept. 26, 2013, 7:56 p.m.)


Status
------

This change has been marked as submitted.


Review request for Asterisk Developers.


Bugs: ASTERISK-20521
    https://issues.asterisk.org/jira/browse/ASTERISK-20521


Repository: Asterisk


Description
-------

First, let me begin by saying the following:
1) CDRs are the devil
2) We didn't want to have to touch CDRs again
3) We approach this problem with a healthy dose of respect for the insanity we're about to begin

Unfortunately, we don't have much choice. In order to present a sane model of Asterisk bridging to the outside world, we have to migrate Asterisk's bridging models under one cohesive framework - Josh's Bridging Framework (see https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+Bridging+Project ). Unfortunately (or fortunately, depending on how you look at it), this means that a lot of masquerades are going to no longer occur, and the bridging loop in features.c is going to go away. That implies that all of the cruft that attempted to make CDRs work in transfers, asynchronous gotos, and other standard-ish PBX scenarios is going to simply get deleted.

We considered simply hitting the delete key on cdr.c too, but unfortunately, we don't *quite* have the luxury of doing that. So if we have to preserve CDRs in some form or fashion, what do we do?

To begin, rather than stick all of the existing CDR madness into the Bridging Framework, we're going to leverage Stasis Core to build CDRs off of the channel and bridge messages moving through Asterisk. This has the following benefits:
1) CDR code now no longer lives anywhere but in the CDR engine (some restrictions may apply to that statement, but it should be a lot better than it is now)
2) CDRs can actually have something like their own state machine
3) This is basically the "let's build CDRs on CEL" task that we always wanted to do but never got around to (except that instead of building it on CEL, we're building it on the same framework that AMI, CEL, and a whole host of other APIs are going to be built on)

Before we begin hacking on Asterisk however, the first step in this is to define *what* CDRs are. Anything not in the specification is undefined behavior and will not be "fixed" in a release branch of Asterisk. Before the behavior will be modified in trunk, someone will have to create a specification for the target Asterisk version and document the behavior. We will then have to agree that the behavior can actually be implemented before attempting to support it. Hopefully, this mitigates some of the moving target shenanigans that afflicted us in the past.

Specification is here: https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+CDR+Specification

A few highlights:
* There will be more then one CDR for a call. A CDR represents a period of communication between two parties. Post-processing will be needed to build a full billing picture.
* We are not going to try and determine your billing practices for you. Asterisk doesn't know what an internal endpoint versus an external endpoint is. It doesn't know that you don't want to bill people for calls parked on Tuesday after 5 PM. If you need that logic, the CDRs will provide the durations, but you have to implement it in your billing system. Alternatively, use CEL.
* CDRs will keep the same structure and representation for backends. Modules that receive CDRs from the Asterisk core should remain unaffected.

Flame away!


Diffs
-----


Diff: https://reviewboard.asterisk.org/r/2378/diff/


Testing
-------


Thanks,

Matt Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130926/45e6961a/attachment-0002.html>