<br><br><div class="gmail_quote">On Tue, May 10, 2011 at 4:27 AM, Steve Davies <span dir="ltr">&lt;<a href="mailto:davies147@gmail.com">davies147@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On 6 May 2011 14:52, Steve Davies &lt;<a href="mailto:davies147@gmail.com">davies147@gmail.com</a>&gt; wrote:<br>
&gt; On 5 May 2011 17:16, Steve Davies &lt;<a href="mailto:davies147@gmail.com">davies147@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; It appears that the CDR data generated by a SIP attended-transfer of a<br>
&gt;&gt; call to an already answered call is different to a SIP attended<br>
&gt;&gt; transfer to a ringing call, to the point of being quite badly wrong in<br>
&gt;&gt; the case of a transfer to a ringing call.<br>
&gt;&gt;<br>
&gt;&gt; As far as I can tell, the reason for the discrepancy is that once a<br>
&gt;&gt; call is bridged, asterisk keeps a &quot;bridge_cdr&quot; knocking about, and the<br>
&gt;&gt; act of masquerading the calls during the transfer leaves this<br>
&gt;&gt; untouched, so the correct data is retained when the bridge eventually<br>
&gt;&gt; completes and the CDR is saved.<br>
&gt;&gt;<br>
&gt;&gt; When transferring to a ringing call, there is no &quot;bridge_cdr&quot; yet, so<br>
&gt;&gt; when ast_do_masquerade swaps the CDR records between channels, it is<br>
&gt;&gt; destroying the only copy of the correct CDR for the ringing channel.<br>
&gt;&gt;<br>
&gt;<br>
&gt; Further to this, there is another CDR data--loss case from a similar mechanism.<br>
&gt;<br>
&gt; An attended transfer of a caller in an IVR to an already bridged call<br>
&gt; will cause the destruction of the CDR relating to the initial IVR<br>
&gt; call-leg.<br>
&gt;<br>
&gt; My earlier theory about AST_CDR_FLAG_BRIDGED was a non-starter, but I<br>
&gt; think it may be that the ast_do_masquerade() code that swaps the CDR<br>
&gt; records needs to do this only when the 2 channels are either both<br>
&gt; bridged, or both un-bridged. I am following all of the<br>
&gt; attended-transfer code paths that I can find to see if the problem is<br>
&gt; already solved elsewhere (ie. not in chan_sip, where I currently have<br>
&gt; the issue)<br>
&gt;<br>
<br>
</div></div>I assume this one qualifies as &quot;too hard&quot; for now :) so I&#39;ve raised an<br>
issue so this is not lost to the mists of time.<br>
<br>
<a href="https://issues.asterisk.org/view.php?id=19259" target="_blank">https://issues.asterisk.org/view.php?id=19259</a><br></blockquote><div><br>If you look back further, on the subcategory of CDR in the bug reports,<br>
you&#39;ll find a set dealing with CDR&#39;s and transfers and parking. 2 or 3 years<br>ago. <br><br>The problem cannot be solved with CDR&#39;s stored on the channel struct. And<br>thus the problem remains.<br><br>I suggest looking into the CEL realm for a solution.<br>
<br>murf<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Regards,<br>
<div><div></div><div class="h5">Steve<br>
<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>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div><span style="font-size:13.3px;font-family:Verdana,Arial,Helvetica,sans-serif"><div style="margin:0pt 0pt 8px"><p style="margin:0pt"><span style="font-family:comic sans ms,sans-serif;font-size:medium">Steve Murphy</span></p>

<p style="margin:0pt"><span style="font-family:comic sans ms,sans-serif;font-size:medium">ParseTree Corporation<br></span></p>
<p style="margin:0pt">57 Lane 17</p>
<p style="margin:0pt">Cody, WY 82414</p>
<p style="margin:0pt">✉  <a href="mailto:murf@parsetree.com" target="_blank">murf@parsetree.com</a></p>
<p style="margin:0pt">☎ 307-899-5535</p></div></span><br></div><div><span style="font-size:13.3px;font-family:Verdana,Arial,Helvetica,sans-serif"><img src="http://s.wisestamp.com/pixel.png?p=mozilla&amp;v=2.0.3&amp;t=1287885769470&amp;u=6672444&amp;e=5113" width="1" height="1"></span></div>
<br>