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

[Steve Davies]

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)

As before, any thought welcome. Pretty please?

Thanks,
Steve