[asterisk-dev] possible lack of CDR data recorded after an attended transfer (atxfer)

[Steve Murphy]

On Fri, 2007-05-18 at 09:52 -0300, Caio Begotti wrote: 
> On 16/05/2007, at 17:17, Caio Begotti wrote:
> > There are 3 calls in there (all of them had an atxfer), each one  
> > starting with a empty src and clid and always ending to a "s" dst  
> > although the dstchannel is different and contains the real  
> > destination. My userfields are custom, they doesn't mean anything.
> >
> > Is this CDR behavior normal for attended transfer?
> 
> Replying to myself, yeah I know, sorry. According to this message  
> (and the whole thread as well), seems that this behavior have been  
> confirmed by some other people. Murf, do you think it's the very same  
> case? Any idea? :-)
> 

I have tons of ideas, but they are all pretty disruptive to those who
have current billing systems in place.

CDR's  are real weak when it comes to transfers in general. Whoever put
the CDR system together (Mark, mainly?) did a great job, but I get the
feeling that asterisk grew up after CDR's were implemented, in ways that
couldn't be foretold, and CDR's are needing to be re-arranged to fit
better in the evolved asterisk. I was working on a new event system for
asterisk, which I named CEL, (Channel Event Logging), which would log
individual events (instead of storing a CDR, and pushing the CDR out
when an event triplet (start, answer, end) were collected). In trying to
collect more info on transfer events (like hookflash, etc), I found that
even the manager events are weak in this area, and will need some
updating, as I found myself reporting these events in code where no
manager events were being reported. I did enough of this before I quit,
to get a feel for what was going on underneath, so to speak, in
asterisk. Unfortunately, my work on CEL comes under the heading of 'pet
project', and I've already burnt up all my allocated time on it, and
then some. I might get back to it next year.

But, I've got plenty of time to work on straightening out CDR's. And the
more I do, the more I want to just totally rip it out, and re-code it. 

I've been downright afraid to touch what's in 1.2. I resolved that I
will not touch anything but minor point fixes in 1.2, until I have 1.4
CDR problems fixed and most users happy therewith. When 1.4 actually
solves the basic problems, I'll backport the fixes into 1.2. I suspect
there will be a storm of complaints at that point, because there will be
changes, some subtle, some not so subtle. Some changes in behavior, but
hopefully minimal. (For example, I have been trying to keep the ForkCDR
and other apps so they work the same as they did before). If the
majority of users are surviving on 1.2 with what's there, the temptation
will be great to just entirely skip 'fixing' 1.2.

The biggest changes I've done, is to force every channel to have a CDR
associated them. Why do this? because unless I did, some events (like
ANSWER) were lost, because they occurred on a channel that didn't have a
CDR on it.

The next biggest change, is that I merge CDR's when a bridge occurs
between two channels. Why? because sometimes, one channel has some of
the events, and the other has the other events. I merge all the events
to one of the channels, so the CDR can be cut. I delete the other
channel's CDR, so only one CDR occurs from the two channels. I currently
have a complaint that the wrong values are being merged when both sides
have different, conflicting values. I'm thinking about that. I think
I'll add a flag to CDR's, that might mark one as more authoritative, and
disambiguate based on that, trying to mark the CDR's based on updates.

Transfers occur outside the normal flow of CDR updating/posting/etc, but
still randomly update CDR fields, so that's why you see the mess you
see.

The more I look at this stuff, the more convinced I am that the bridge
is the fundamental "unit" of communication traffic in asterisk. And I'm
not talking about the bridge in dial, I'm talking about ast_bridge_call
in res/res_features.c. It's where asterisk connects one device to
another. It's used by Dial, builtin_atxfer, park, and others. If I
create a CDR in every channel, and every CDR gets its ANSWER time from
the beginning of a bridge, and every CDR gets its END time from the end
of a bridge, then we might generate some zero-length CDR's, but we catch
every single sub-conversation there is, guaranteed. But folks will have
to adapt to the fact (at least for billing purposes) that you can ignore
zero-length conversations, you can ignore CDR's with NO_ANSWER, BUSY,
etc. dispositions. Little details like how to handle Local channels,
masqeraded channels, and etc. will need to be worked out. For instance,
Local channels seem to serve as sub-bridges to another channel, and we'd
mostly be interested in what's at the other side, since the internal
wiring to make calls happen will not be interesting to folks doing
billing (unless they want to bill at different rates for different kinds
of internal wiring?). There are a few things that the CDR system, even
if fixed, will not let you do. CEL in the future might, tho, as it will
lay out a time line of events, which you will be able to gather into
billing information.

Hope this helps you get a feel for where I am with CDR fixing, and why
its in its current troubled state, and where I'm heading with it.


murf


-- 
Steve Murphy
Software Developer
Digium
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3227 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20070518/5c87ec09/smime.bin