<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 9, 2013 at 9:58 AM, Steve Davies <span dir="ltr"><<a href="mailto:davies147@gmail.com" target="_blank">davies147@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I believe there is a regression in the CDR code since 1.8.11. It also<br>
affects versions 10 and 11, but probably not version 12.<br>
<br>
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-22954" target="_blank">https://issues.asterisk.org/jira/browse/ASTERISK-22954</a><br>
<br>
After a SIP attended transfer, the code that was added in<br>
ASTERISK-16990 tries to copy userfield etc CDR data onto the bridge<br>
CDR before writing it to the DB, which is fine most of the time, but<br>
after a transfer/masquerade, the CDR that is being copied from is a<br>
masqueraded channel's CDR, and is unrelated to the original bridge.<br>
The results are fairly messy :(<br>
<br>
The patch I've suggested is as simple as I could make it without just<br>
rolling back the patch.<br>
<br clear="all"></blockquote><div><br></div><div>Hey Steve -<br><br></div><div>I replied on the issue, but your analysis looks correct. Oh what fun CDRs are...<br><br>Matt <br></div></div><br>-- <br><div dir="ltr"><div>Matthew Jordan<br>
</div><div>Digium, Inc. | Engineering Manager</div><div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div><div>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div>
</div>
</div></div>