<div class="gmail_quote">On 10 May 2011 13:56, Steve Murphy <span dir="ltr"><<a href="mailto:murf@parsetree.com" target="_blank">murf@parsetree.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div><div></div><div>On Tue, May 10, 2011 at 4:27 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">
<div><div></div><div>On 6 May 2011 14:52, Steve Davies <<a href="mailto:davies147@gmail.com" target="_blank">davies147@gmail.com</a>> wrote:<br>
> On 5 May 2011 17:16, Steve Davies <<a href="mailto:davies147@gmail.com" target="_blank">davies147@gmail.com</a>> wrote:<br>
>><br>
>> It appears that the CDR data generated by a SIP attended-transfer of a<br>
>> call to an already answered call is different to a SIP attended<br>
>> transfer to a ringing call, to the point of being quite badly wrong in<br>
>> the case of a transfer to a ringing call.<br>
>><br>
>> As far as I can tell, the reason for the discrepancy is that once a<br>
>> call is bridged, asterisk keeps a "bridge_cdr" knocking about, and the<br>
>> act of masquerading the calls during the transfer leaves this<br>
>> untouched, so the correct data is retained when the bridge eventually<br>
>> completes and the CDR is saved.<br>
>><br>
>> When transferring to a ringing call, there is no "bridge_cdr" yet, so<br>
>> when ast_do_masquerade swaps the CDR records between channels, it is<br>
>> destroying the only copy of the correct CDR for the ringing channel.<br>
>><br>
><br>
> Further to this, there is another CDR data--loss case from a similar mechanism.<br>
><br>
> An attended transfer of a caller in an IVR to an already bridged call<br>
> will cause the destruction of the CDR relating to the initial IVR<br>
> call-leg.<br>
><br>
> My earlier theory about AST_CDR_FLAG_BRIDGED was a non-starter, but I<br>
> think it may be that the ast_do_masquerade() code that swaps the CDR<br>
> records needs to do this only when the 2 channels are either both<br>
> bridged, or both un-bridged. I am following all of the<br>
> attended-transfer code paths that I can find to see if the problem is<br>
> already solved elsewhere (ie. not in chan_sip, where I currently have<br>
> the issue)<br>
><br>
<br>
</div></div>I assume this one qualifies as "too hard" for now :) so I'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></div><div><br>If you look back further, on the subcategory of CDR in the bug reports,<br>
you'll find a set dealing with CDR's and transfers and parking. 2 or 3 years<br>ago. <br><br>The problem cannot be solved with CDR's stored on the channel struct. And<br>thus the problem remains.<br></div></div>
</blockquote><div> </div><div>Hi,</div><div><br></div><div>I think I have solved one of my 3 problems, and have posted a patch to issue #19259 accordingly. This only covers one case, but I have discovered the likely cause of the 2nd case, and wonder if there is an obvious solution?</div>
<div><br></div><div>Set up a bridged call between Originator A and Peer B, then get A to blind transfer B into the dialplan. The sequence of events seems to be:</div><div><br></div><div>- ast_async_goto is called on B, but B has no PBX object, so...</div>
<div>- Create a temp channel</div><div>- Copy CDR from B</div><div>- Setup Masq B with temp channel</div><div>- Lock channel, cause the Masq, Unlock channel</div><div>- Start the PBX on the channel (new thread spawned)</div>
<div>
- Return to the transferer.</div><div><br></div><div>At this point, the A to B bridge is still running so we have 2 relevant threads active on the channel. The new PBX runs on, and let us say that it answers the call, and begins a Playback(). While the playback is in progress, the old bridge spots the Masq and is broken, and a whole load of CDR records have ast_cdr_specialized_reset() called on them, including the CDR that represents the new PBX/Playback.</div>
<div><br></div><div>What should probably happen is that the newly created PBX thread needs to block, waiting for the bridge to finish closing down naturally before it progresses.</div><div><br></div><div>Is there an existing mechanism that would allow this? Or am I completely mis-interpreting the sequence of events? I have added debug to my local build, and definitely see the ast_cdr_specialized_reset() calls occurring after the PBX has been started.</div>
<div><br></div><div>Thanks,</div><div>Steve</div></div>