[asterisk-dev] Interesting/Broken (?) CDR behaviour during transfer. Help please!

[Steve Davies]

On 6 May 2011 14:52, Steve Davies <davies147 at gmail.com> wrote:
> On 5 May 2011 17:16, Steve Davies <davies147 at gmail.com> wrote:
>>
>> It appears that the CDR data generated by a SIP attended-transfer of a
>> call to an already answered call is different to a SIP attended
>> transfer to a ringing call, to the point of being quite badly wrong in
>> the case of a transfer to a ringing call.
>>
>> As far as I can tell, the reason for the discrepancy is that once a
>> call is bridged, asterisk keeps a "bridge_cdr" knocking about, and the
>> act of masquerading the calls during the transfer leaves this
>> untouched, so the correct data is retained when the bridge eventually
>> completes and the CDR is saved.
>>
>> When transferring to a ringing call, there is no "bridge_cdr" yet, so
>> when ast_do_masquerade swaps the CDR records between channels, it is
>> destroying the only copy of the correct CDR for the ringing channel.
>>
>
> Further to this, there is another CDR data--loss case from a similar mechanism.
>
> An attended transfer of a caller in an IVR to an already bridged call
> will cause the destruction of the CDR relating to the initial IVR
> call-leg.
>
> My earlier theory about AST_CDR_FLAG_BRIDGED was a non-starter, but I
> think it may be that the ast_do_masquerade() code that swaps the CDR
> records needs to do this only when the 2 channels are either both
> bridged, or both un-bridged. I am following all of the
> attended-transfer code paths that I can find to see if the problem is
> already solved elsewhere (ie. not in chan_sip, where I currently have
> the issue)
>

I assume this one qualifies as "too hard" for now :) so I've raised an
issue so this is not lost to the mists of time.

https://issues.asterisk.org/view.php?id=19259

Regards,
Steve