[asterisk-users] Simple CDRs

[Grey Man]

On Thu, Jan 8, 2009 at 6:22 PM, Steve Murphy <murf at digium.com> wrote:
>
> In general, stuff like FXO's activating, would signal an incoming call,
> but.... gee, I could wire up some odd circuit to make it a local
> extension...
> Some external rule to the pbx determines which devices and peers you'll
> want to pay (billable) attention to. Don't you think?

That's the classic one alright. Should a CDR be generated whenever
someone picks up an analogue phone connected to a DAHDI port on
Asterisk? I would argue yes. It may seem like something that could
generate an overwhelming number of CDRs but when you think about it a
person dedicating themselves to tkaing a phone on and off hook as
quickly as possible may be able to generate 3 or 4 CDRs per second. A
misbehaving SIP gateway could generate 100's of spuirous call requests
and CDRs per second.

In both cases as the Asterisk administrator I'd be quite happy to get
the CDRs so as to be alerted to the situation so I can take remedial
action.

>> >> - channel: The data that was passed to the channel driver for a call.
>> >
>> > you probably mean the lastapp/lastdata fields here. I think we may
>> > need to look at these fields a little closer. There are several places
>> > in the code where a dial-type-operation is performed, but the Dial() app
>> > is not called to do it... followme, queues, call files, ami originate,
>> > places like that. It might be good to have the method of making the
>> > call recorded in the CDR in the lastapp field; like queue#Dial
>> > park#Dial,
>> > CallFile#Dial, etc.
>> >
>> > Also, you left out the "party" field... If A calls in, and dials B,
>> > (well, asterisk dials B in A's behalf), and B xfers A to C, then,
>> > wouldn't you be at all interested in the fact, that even tho B called
>> > C, it was A that spent all the time on the line? Eh, I guess it wouldn't
>> > really matter, would it? If C was in Namibia, would B always be billed
>> > for the call, or would anyone ever be tempted to bill A's dept for that
>> > call? (Assuming, I guess, that A & B are both internal)...
>>
>> I was thinking more of the piece of data passed to the channel driver
>> and not the data provided to any particular dialplan application. It
>> gets back again to CDRs reflecting channel activity and not dialplan
>> application activity. The current Asterisk CDR situation illustrates
>> the problem of moving the CDRs up to the dialplan application layer,
>> the solution is to sink them back down to the channel layer.
>>
>> At the end of the day a Call Detail Record by definition should be
>> recording call activity. In Asterisk it's the channels that end up
>> making and ending the calls and not the dial plan or it's applications
>> hence it's the channels that are the best place to generate the CDRs.
>
> I take that as a "heck no, I'm not interested in the slightest
> about that!" ;)

I would be interested in additional information in the CDRs as I'm
sure others would. My worry is it's not a critical peice of CDR
information and because it sounds like information being generated at
the dialplan level it could end up being complicated to implement or
confusing to desgin and become a distraction from getting the core CDR
fields sorted out.

> As to the current CDR situation, it is where it is, because
> of several factors; like a large number of users with vastly different
> desires and demands; The cdr is stored on channels; several of the
> CDR fields are copies of channel fields, and no spec to define
> where/when the proper updates are supposed to be done; CDR fields
> are updated and set at various places and times with no development
> documentation as to why; CDRs depend on "channel/peer" roles that
> channels take on, but that some operations swap around;
> and on and on... I have never seen a mechanism so intertangled
> and interdependent... It's screaming "rewrite me!".

I've seen a lot worse. Asterisk isn't even 10 years old and in the
last couple has started to get some quite rigid coding guidelines. Try
30 years, no guidelines and every programmer and his dog poking
around!

Regards,

Greyman.