<div class="gmail_quote">On Wed, Jan 4, 2012 at 12:25 PM, Kevin P. Fleming <span dir="ltr"><<a href="mailto:kpfleming@digium.com">kpfleming@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 01/04/2012 07:26 AM, Ryan Wagoner wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><div><div class="h5">I've found the CDR records to be buggy when transferring. Basic<br>
inbound/outbound calls are accounted for correctly. At the very least I<br>
would like to see transfers fixed, which is most likely the same issue<br>
for AMI redirects.<br>
<br>
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-18733" target="_blank">https://issues.asterisk.org/<u></u>jira/browse/ASTERISK-18733</a><br>
<br>
Having to parse CEL to produce my own CDR records seems like an extra<br>
step. If CEL was added so I can parse the records correctly why can't<br>
Asterisk? I know everyone has disagreements on how CDR records should be<br>
accounted for, but I don't think CDR data should be just left out.<br>
</div></div></blockquote>
<br>
CDRs, as a side-effect of their design, *cannot* reliably account for any calls except "party A calls party B, party B answers, one party hangs up, call is torn down". Transfers, holds, conferencing, redirects, any other activity other than basic call handling have no way to be properly represented in CDRs. Everyone has different opinions on how they should appear, and while I won't disagree that there could be bugs that need to be corrected, the fact that transfers are not "properly" recorded is not a bug: it can't be, because there is no commonly accepted definition of what is 'proper' for a CDR to report a transfer.<br>
<br>
CEL was added so that you'd have all the raw data necessary to make your own decisions on how to produce CDRs if you need to do so; the decisions on how to collapse/coalesce CEL records into CDRs are *business decisions* you need to make, they don't belong in Asterisk (and trying to put them there only results in frustrations and 'bug reports' from people who think that the coalescing should be done differently).<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Kevin P. Fleming<br>
Digium, Inc. | Director of Software Technologies<br>
Jabber: <a href="mailto:kfleming@digium.com" target="_blank">kfleming@digium.com</a> | SIP: <a href="mailto:kpfleming@digium.com" target="_blank">kpfleming@digium.com</a> | Skype: kpfleming<br>
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br>
Check us out at <a href="http://www.digium.com" target="_blank">www.digium.com</a> & <a href="http://www.asterisk.org" target="_blank">www.asterisk.org</a></font></span><br></blockquote><div><br><br>I understand there is no definition of a transfer CDR. That problem is the transfer is not accounted for. For example party A calls party B, party B answers, party B attended transfers to party C using a Polycom phone. I'm assuming the Polycom phones just calls party C then uses a SIP REFER.<br>
<br>This scenario is common as we have a main line that everyone answers. They answer, call the responsible party, announce the call, and transfer. The CDR logs leave out that the call was transferred to party C.<br><br>
If Asterisk just picked a format to log the transfer CDR that would be acceptable. You could always quickly parse the CDR log into the format needed. CEL provides way more information than needed and requires a more complex parser not to mention data storage. For the last year I have 1GB of CDR data in mySQL with 4.5 million rows. I'm guessing CEL would be 4-5 times this.<br>
<br>Ryan<br><br><br><br> <br></div></div>