[asterisk-users] CDR

Wed Oct 17 03:07:45 CDT 2007

I for one would like to thank you for looking at the CDR processing in Asterisk. In the scheme of things I guess it's not the most compelling of tasks but it's definitely somehting that needs some work.

At the moment I actually block SIP responses from my users with a status code > 300 and < 399. Users were ringing their own number and then redirecting the call to a higher cost destination. The CDR from asterisk uses the original destination. 

For REFER requests it's the opposite and the final destination gets put in the CDR overwriting the initial one. In this case I let them through since the most common usage pattern is an incoming call being transferred to a mobile or landline. The user will be billed for the entire call at the mobile or landline rate even if they spent the majority of the time on the incoming call without doing the transfer. This is of course not ideal but at least it lets them do transfers.

Regards,

Greyman.

----- Original Message ----
From: Steve Murphy <murf at digium.com>
To: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users at lists.digium.com>
Sent: Monday, 15 October, 2007 6:22:45 PM
Subject: Re: [asterisk-users] CDR

Sorry!

I've gotten some complaints on this; I will try this week to 
mod 1.4 so that you can choose to see the single-channel unanswered 
CDR's, in a new config file option. I've gotten complaints both ways,
tho, so pardon me if I get a little confused about what users out there
want from CDR's.

My biggest trouble is that by forcing all channels to have a CDR at
creation time
solves problems with missing CDR's, but creates a problem by generating

extra unanswered CDR's that weren't generated before... for instance,
when you
ring three phones via a dial command, you then get 3 CDR's, including
the
two phones that were rung, but not answered.

Another problem is with Zap-based phones; you take the handset
 off-hook,
and 
a channel is created and dialtone generated. If you hang up, you get a
CDR there, also.

I have not found an easy way to detect and drop these kinds of CDR's,
 as
most folks really do not find them very useful.

And, I've gotten a complaint that you end up with 'duplicate' CDR's,
which is also an artifact of forcing all channels to have a CDR
associated. If anybody 
thinks they have a magic spell that will calm down the CDR's, I will
 not
mind the information at all! I worked all last week to try to iron out
the 1.4 zap-transfer CDR issues. I have 12 cases I test with involving
hook-flash and #-blindxfers, and so far, I've got 9 of the 12 working
 OK
(as far as I'm concerned.), but I have 3 cases that come up with
problems. For instance, if you hookflash, and dial a number, the CDR's
will be different, if you hang up before the dialed party answers,
versus hanging up afterwards... The diff between a blind xfer and an
attended xfer (without the 3 way), I guess, but I lose the calling
channel name... I'll try to sort all this out, and then I'll attack
 this
problem. Hopefully, I get it all into svn before the next release of
1.4...!

As far as xfers in 1.4 go, I'm trying to make sure that the source and
destination channel names reflect the true dialing party, as this makes
more sense from a billing perspective, at least to me.  So, if A calls
B, and B forwards the call to C, then the CDR's need to reflect a call
from A to B, and a call from B to C, which you may or may not be seeing
right now. AFAICT, transfers pretty much result in confused CDR's. I
gave up totally on generating separate CDR's for any 3-ways that might
occur. Such 3-ways will end up being billed to the dialing parties.

Here's an interesting situation: A calls B, A then hookflashes, and
 then
A calls C, and hookflashes again. It's now a 3-way call, between A, B,
and C. A then drops out and B and C converse.  My goal with this
situation was to have two CDR's, one for A->B and one for A->c. Since A
placed both calls, it seems only just that A pay for B's and C's
conversation. Especially if A is in the US, for example,  and B is in
Uganda, and C is in Bangladesh!

Getting the right info in the right field from the driver level is
pretty tricky, and you can add the fact that there's definite timing
issues at play. If I make changes to CDR's in channels A and B, near to
the time a hangup occurs (and it's very commonly the case), I can end
 up
with some pretty strange stuff happening! I found that adding debug
logging statements to the driver can affect the way the CDR's are
generated! I solved some of this by locking channels (which to me is
pretty ugly, considering the number of locks involved).

So, please, cut me some slack... and keep me informed about your
"happiness" levels. I want this stuff to be good, solid, and useful to
the majority. But also keep in mind that I fix something, someone out
there is going to be unhappy, because they have code/backends/whatever
that depends on the borked behavior!
1.4 ***IS**** a release, and I dare not do ANYTHING but fix bugs. But,
wow, fixing a bug changes behavior, and my goal is minimal impact, but
real and useful fixes.

murf

On Mon, 2007-10-15 at 10:40 +0200, Andrew Nowrot wrote:
> Hi
> 
> Thanks for reply
> 
>         Yes, there's a change. For me it's completely unacceptable,
 so
>         i 
>         reverted the patch
 (http://bugs.digium.com/view.php?id=10659).
> 
> 
> For me too. This bug occur in September. Is it still present in
> asterisk 1.4.12.1. I also have asterisk 1.4.4 on a different box and
> there everything works like in 1.2.21. 
> I need the old behaviour to have everything working flawlessly. 
> 
> Thanks
> 
> Andrew 
> 
> 
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
> 
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
-- 
Steve Murphy
Software Developer
Digium

      Sick of deleting your inbox? Yahoo!7 Mail has free unlimited storage.
http://au.docs.yahoo.com/mail/unlimitedstorage.html