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

David Kerr david.a.kerr at gmail.com
Tue Mar 12 13:11:34 CDT 2013


Matt,
  If you are messing with CDRs please take a look at bug id 20747 and the
corresponding fix I posted to reviewboard (which has received no comments).
 CDRs are not accurately recorded for outbound calls that go through SLA.
 I understand the reasons why it is broken and partly it is to do with the
implementation of SLA and partly it is just the nature of what SLA is in
the first place.  I would very much like some review of this bug id and the
fix on reviewboard.

But for your CDR spec for Asterisk 12, you should at least document how it
should work for extension(s) and trunk configured as SLA.  There are
multiple scenarios...

Party A connects to Asterisk SLA (hears a dialtone) and dials Party B
(which connects or does not answer). Dialtone comes from either analog
trunk or DISA() Asterisk application.
Party A dials Party B (no intermediate dialtone from Asterisk, just
"direct" through SLA "conference" to Party B
Party A dials Party B (either of above two scenarios).  Party C joins in by
pressing SLA trunk button on phone. Three way conference takes place.
 Party C hangs up.  Party A later hangs up.
Party A dials Party B.  Party C joins in by pressing SLA trunk button on
phone. Three way conference takes place.  Party A hangs up.  Party C later
hangs up.
Last two scenarios with a Party D, E, F etc. joining and leaving.

And there may be other scenarios as well.  In Asterisk 1.8 and 11 the CDR
for Party A is frequently wrong... For example, in the first scenario Party
A CDR is "answered" when receiving the dialtone (entering the SLA
conference) not when Party B answers.  And in many cases when Party B
answers a bridge/masquerade takes place that "ends" the CDR.

The Asterisk 12 CDR spec should document expected behavior for SLA.  For
example, should even the simplest of SLA calls generate two CDR records...
one from Party A to SLA "conference" the other from the SLA conference to
Party B.  This may sound strange, but when you have a Party C, D, E
potentially joining and leaving the conference it may be the only way to
accurately keep track of billing seconds.... and in the dialplan you can
make use of NoCDR() etc. to control which records you actually want.

Thanks
David




On Fri, Mar 8, 2013 at 5:05 PM, Matt Jordan <reviewboard at asterisk.org>wrote:

>    This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2378/
>   Review request for Asterisk Developers.
> By Matt Jordan.
>
> *Updated March 8, 2013, 4:05 p.m.*
> Changes
>
> Fixed bad link (silly ')')
>
>   Description (updated)
>
> 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!
>
>   *Bugs: * ASTERISK-20521<https://issues.asterisk.org/jira/browse/ASTERISK-20521>
> Diffs
>
>
> View Diff <https://reviewboard.asterisk.org/r/2378/diff/>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130312/3f7704db/attachment.htm>


More information about the asterisk-dev mailing list