[asterisk-dev] CDR Problem Proposals

[Atis Lezdins]

On Fri, Nov 21, 2008 at 5:20 PM, John Lange <john at johnlange.ca> wrote:
> On Thu, 2008-11-20 at 16:49 -0500, Leif Madsen wrote:
>> Perhaps building CDRs into Asterisk is the wrong approach, and maybe we
>> need to take the course of allowing people to build their own CDRs via
>> the dialplan; and that just means providing them the tools to do it, and
>> some examples of the most common scenarios (this is what CEL is supposed
>> to be right?)
>
> It doesn't seem like this would be workable. For example, how in the
> dialplan do you track an attended transfer capturing all 3 legs of the
> call?
>
> Or what about putting a caller on hold? How do you keep track of how
> long the first leg of the call was, how long they were on hold, and then
> how long the third portion of the call was? None of those things are
> normally part of the dialplan.
>
> On the other hand, ALL of those actions touch the bridging code (1.
> Bridge two callers, 2. Bridge to music, 3. bridge 2 callers) so again, I
> feel strongly all of the raw CDR code should go in bridging.
>
> As a parallel effort their could be new "custom" CDR-style functions
> added to the dialplan that log to a completely different place but the
> "raw" CDR stuff still needs to be there.
>
> I can't think of a single things that needs to be logged that doesn't
> involve a bridge between two (or more) channels being taken down.
>
> In simple terms, every time a bridge is taken down, create a log entry
> that records the two end points, the reason the bridge was taken down,
> the date & time of the event, and duration the bridge was up. That would
> pretty much cover everything.
>
> Of course, since I'm not a major contributor this is all very easy for
> me to say ;)
>

I haven't personally tested 1.4.22, but i doubt that we will switch to
it. Currently we do have 1.4.19 with lot of backports and patches - ok
there are some deadlocks once per month - due to some queue backport,
which are already fixed in 1.6.0, but backporting that would take much
effort - because 1.6 uses astobj2 there.. So for now, we're sticking
to 1.4.19 and looking into 1.6.0 tree. However we can't switch to
1.6.0 because of CDR issues..

So, i would recommend that whatever new CDR sytem there will be, it
should be merged also into current stable branches (perhaps starting
from 1.6.0 and up) - and should be selectable trough compiler flags.
Well, i kind of see that it would be some additional work, however CDR
is the thing that directly affects money - so much care should be
taken by implementing and testing something new. So, unless it's
tested by huge amount of users, and users request it as default
option, current implementation should remain. Well, perhaps some
additional compiler flags can be added - for each of current issues -
which cannot be solved in a way to satisfy everybody.

I'm also very much in favor of dialplan based control, extending
dialplan to places like attended transfer, etc.

Also some functions that allow setting inherited CDR fields (like
current accountcode) would be nice.. So you can set some known fields
at beginning, which are inherited into all the rest of CDRs until it's
overridden.

Regards,
Atis

-- 
Atis Lezdins,
VoIP Project Manager / Developer,
IQ Labs Inc,
atis at iq-labs.net
Skype: atis.lezdins
Cell Phone: +371 28806004
Cell Phone: +1 800 7300689
Work phone: +1 800 7502835