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

[Steve Murphy]

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.

I suggest looking into the CEL realm for a solution.

murf


>
> Regards,
> Steve
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>



-- 

Steve Murphy

ParseTree Corporation

57 Lane 17

Cody, WY 82414

✉  murf at parsetree.com

☎ 307-899-5535
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20110510/f134d570/attachment.htm>