<div dir="ltr">Matt,<div style> 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.</div>
<div style><br></div><div style>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...</div><div style><br></div>
<div style>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.<br>Party A dials Party B (no intermediate dialtone from Asterisk, just "direct" through SLA "conference" to Party B</div>
<div style>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.</div><div style>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.</div>
<div style>Last two scenarios with a Party D, E, F etc. joining and leaving.</div><div style><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>Thanks</div><div style>David</div><div style><br></div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 8, 2013 at 5:05 PM, Matt Jordan <span dir="ltr"><<a href="mailto:reviewboard@asterisk.org" target="_blank">reviewboard@asterisk.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div style="font-family:Verdana,Arial,Helvetica,Sans-Serif"><div class="im">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border:1px #c9c399 solid">
<tbody><tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://reviewboard.asterisk.org/r/2378/" target="_blank">https://reviewboard.asterisk.org/r/2378/</a>
</td>
</tr>
</tbody></table>
<br>
</div><table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image:url('https://reviewboard.asterisk.org/media/rb/images/review_request_box_top_bg.png');background-repeat:repeat-x;border:1px black solid">
<tbody><tr>
<td><div class="im">
<div>Review request for Asterisk Developers.</div>
<div>By Matt Jordan.</div>
</div><p style="color:grey"><i>Updated March 8, 2013, 4:05 p.m.</i></p>
<h1 style="color:#575012;font-size:10pt;margin-top:1.5em">Changes</h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border:1px solid #b8b5a0">
<tbody><tr>
<td>
<pre style="margin:0;padding:0;white-space:pre-wrap;white-space:-moz-pre-wrap;white-space:-pre-wrap;white-space:-o-pre-wrap;word-wrap:break-word">Fixed bad link (silly ')')</pre>
</td>
</tr>
</tbody></table>
<h1 style="color:#575012;font-size:10pt;margin-top:1.5em">Description (updated)</h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border:1px solid #b8b5a0">
<tbody><tr>
<td>
<pre style="margin:0;padding:0;white-space:pre-wrap;white-space:-moz-pre-wrap;white-space:-pre-wrap;white-space:-o-pre-wrap;word-wrap:break-word">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 <a href="https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+Bridging+Project" target="_blank">https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+Bridging+Project</a> ). 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: <a href="https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+CDR+Specification" target="_blank">https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+CDR+Specification</a><div class="im">
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!</div></pre>
</td>
</tr>
</tbody></table><div class="im">
<div style="margin-top:1.5em">
<b style="color:#575012;font-size:10pt;margin-top:1.5em">Bugs: </b>
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-20521" target="_blank">ASTERISK-20521</a>
</div>
<h1 style="color:#575012;font-size:10pt;margin-top:1.5em">Diffs </h1>
<ul style="margin-left:3em;padding-left:0">
</ul>
<p><a href="https://reviewboard.asterisk.org/r/2378/diff/" style="margin-left:3em" target="_blank">View Diff</a></p>
</div></td>
</tr>
</tbody></table>
</div>
</div>
<br>--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br></blockquote></div><br></div>