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

[Steve Davies]

On 10 May 2011 13:56, Steve Murphy <murf at parsetree.com> wrote:

>
>
> On Tue, May 10, 2011 at 4:27 AM, Steve Davies <davies147 at gmail.com> wrote:
>
>> 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
>>
>
> If you look back further, on the subcategory of CDR in the bug reports,
> you'll find a set dealing with CDR's and transfers and parking. 2 or 3
> years
> ago.
>
> The problem cannot be solved with CDR's stored on the channel struct. And
> thus the problem remains.
>

Hi,

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?

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:

- ast_async_goto is called on B, but B has no PBX object, so...
- Create a temp channel
- Copy CDR from B
- Setup Masq B with temp channel
- Lock channel, cause the Masq, Unlock channel
- Start the PBX on the channel (new thread spawned)
- Return to the transferer.

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.

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.

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.

Thanks,
Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20110512/e37f489a/attachment.htm>