[asterisk-users] CDR and Transfer, an asterisk scaring bug lasting from 1.4 version...

Leandro Dardini ldardini at gmail.com
Thu Jan 23 15:25:54 CST 2014


2014/1/23 Matthew Jordan <mjordan at digium.com>

> On Thu, Jan 23, 2014 at 12:44 PM, Leandro Dardini <ldardini at gmail.com>
> wrote:
> > When you use a product which version number is 11 or even 12, you might
> go
> > with the assumption all big bugs are fixed and then you find there is a
> > huge, important, expensive bug still running in the code we are relaying
> > upon...
>
> First, not all versions in 11 are the same. Bugs do get fixed. What
> version of Asterisk 11 are you using?
>

I am using asterisk 11.6 and searching for "CDR transfer" in the issue
tracker return unfixed bugs

https://issues.asterisk.org/jira/browse/ASTERISK-11309
https://issues.asterisk.org/jira/browse/ASTERISK-21822



>
> Second, CDRs are not the same in Asterisk 12. Due to extensive changes
> in the bridging core, CDRs were re-worked heavily. You may want to
> take a look at the notes on the Asterisk wiki [1] for Asterisk 12, as
> well as the CDR specification for Asterisk 12 [2].
>

That seems great! Asterisk 12 really solved the CDR problem when
transferring!


>
> > The problem is simple. If you transfer a call, that dialing will be not
> > reported in the CDR, so no billing will happen. This is a simple example:
>
> And how did you do the transfer? Via DTMF features? Via a particular
> channel driver technology? If so, which channel drivers were involved?
>

Transfer was made using the "transfer" button of the phone and the result
was the same with blind or attended transfer


>
> What kind of transfer was it? Blind? Attended? Failed attended (the
> notorious blonde transfer)?
>
> >
> > Extension 100 calls extension 101
> > After 10 seconds, extension 100 transfer the call to
> > 00VERYEXPENSIVEDESTINATION
> > After 100 seconds, extension 101 hangup the call
> >
> > What do you find in the CDR? Just one record for a call from extension
> 100
> > to extension 101 lasting 10 seconds. What about the 100 seconds call from
> > 100 to 00VERYEXPENSIVEDESTINATION? It will never get billed.
> >
> > How do you manage these cases?
> >
>
> I'm not sure if there is a bug report filed against CDRs for the
> currently maintained branches for lost records during a blind or
> attended transfer that matches your issue. There is ASTERISK-17826,
> which may or may not be your issue: the noted lack of information
> makes it a bit hard to tell. The last issue that I'm aware of that we
> fixed regarding lost CDRs during a transfer was ASTERISK-21394, which
> was fixed in 11.4.0.
>
> So, if you're using a version prior to 11.4.0, you may want to
> consider upgrading. Again, due to the lack of information, it's hard
> to tell whether or not that would help you.
>
> Finally, CDRs in versions of Asterisk prior to 12 are subject to the
> whims of channel masquerades. This has historically made it difficult,
> if not impossible, to guarantee correctness during all transfer
> operations. Additionally, even if we could guarantee a particular set
> of behaviour in all circumstances, the lack of any clear agreement as
> to what a CDR should look like after an attended transfer (or in any
> situation that involved multiple parties) made the problem impossible
> to solve to the satisfaction of everyone. This particular reason is
> why CEL was created. If you continue to have problems with the billing
> records, you may want to consider moving your billing logic to CEL.
>
> Note that since (a) Asterisk 12 re-architected using a consistent
> bridging framework, which killed visible channel masquerades; and (b)
> we decided to not try and please everyone and just defined CDRs for
> how we thought they should work; the behaviour of CDRs in Asterisk 12
> and in future versions should be substantially more predictable.
>
> Matt
>

Thank you a lot! I am going to move ahead with asterisk 12!


>
> [1] https://wiki.asterisk.org/wiki/display/AST/New+in+12
> [2]
> https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+CDR+Specification
>
> --
> Matthew Jordan
> Digium, Inc. | Engineering Manager
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at: http://digium.com & http://asterisk.org
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>                http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20140123/2860ab18/attachment.html>


More information about the asterisk-users mailing list