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

2014-01-23 Thread Leandro Dardini
2014/1/23 Matthew Jordan 

> On Thu, Jan 23, 2014 at 12:44 PM, Leandro Dardini 
> 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
>
-- 
_
-- 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

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

2014-01-23 Thread Matthew Jordan
On Thu, Jan 23, 2014 at 12:44 PM, Leandro Dardini  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?

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].

> 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?

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

[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


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

2014-01-23 Thread Leandro Dardini
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...

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:

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?

Leandro
-- 
_
-- 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