[asterisk-users] Fwd: Simple CDRs

[Grey Man]

On Tue, Jan 6, 2009 at 3:53 PM, Steve Murphy <murf at digium.com> wrote:
>
> Can't do this; it would be inaccurate; start time is when A either
> picks up the phone (if dahdi exten), or when A submits an invite
> (if sip exten), or when an incoming call (via sip invite, or dahdi
> fxo i/f) arrives at the pbx.

I understand what you are saying about start time and I think your
approach is correct. I was a bit loose in the use of start and answer
time but I agree with you. The answer time is absolutely critical but
start time is also required as it can be used for things like
identifying how long a user waited for a call to answer.

> As to Answers, we have to start getting pedantic; if A is an exten,
> then the first answer will be when B answers. But if A is an incoming
> call via, say a dahdi fxo interface, or an incoming sip invite, then
> an s exten is going to get run, and usually the PBX runs the answer()
> app, and this will usually be the first answer. Now, I can use heuristics
> to override this first answer if a dial occurs, but... if multiple dials
> occur, this heuristic would tend to record the last answer; if we
> override only Answer() in the 's' exten, then we would only record
> the first answer... is this more like it?

That sounds a bit dangerous to me. If you go down the path of setting
the answer time based on dial plan applications or events you'll need
to understand and modify every dial plan application that can answer a
call. To me it would seem a lot simpler to do the
override/modification in each channel or even better even lower in
ast_channel. A channel has to have a very clearly defined definition
of answer and hangup whereas dial plan applications don't.

> Oh, and BUSY/NO ANSWER/FAIL for a non-s exten, would also override
> an ANSWER on exten s, BTW...
>
> And, would it be proper to include all dial attempts? My guess is
> that you would *NOT* want to see any dial attempts in this mode. Well,
> at least, in this particular case, if A *tries* to dial B, but B
> doesn't answer, then since A is a live channel, we would record
> it's life in the system. When A hangs up, we would see the NO ANSWER
> disposition, and the destination of B, right? If A tried to dial a
> group, and nobody answered, the destination would be a random member
> of that group, the args to the Dial command would record the other
> members, usually.

I liked you previous approach where all call attempts were recorded
and there was a config option to opt out of CDRs for non-answered
calls for people that didn't want them. When the Dial command
specifies multiple destinations then there should be one CDR for each
destination that is dialled irrespective of whether it is answered or
not. A disposition of something like CANCELLED could be set for the
dial legs that Asterisk cancels after the first one is answered.

As an example consider the standard call scenario where a user calls
into Asterisk and the dialplan forwards the call to 3 destinations:

User A --> Asterisk: Dial(SIP/x&SIP/y&SIP/z) --> SIP/y answers

That should generate 4 CDRs:

1. A to Asterisk which is answered,
2. Asterisk to X which is cancelled,
3. Asterisk to Y which is answered,
4. Asterisk ti Z which is cancelled.

For people setting the no unanswered call CDRs the 2 and 4th CDRs
would not be generated.

> I notice that you group the two B CDRs I described into a single
> entity, but in doing so, you violate your own rule; when B parked
> A, B was hung up. (He could easily dialed party D, eg, and had a
> conversation and hung up while A was parked!) According to the
> rules, there should be two CDR's for B, right?

I think this was just me not being that familiar with parking. If the
example had been a transfer I would have been on the ball :-).

> OK, gotcha. Now, let's talk about the fields in current/future CDRs,
> and see which you consider relevant?

The core fields I would put into the Asterisk CDRs are:

- uniqueid: A GUID/UUID that cannot be changed and is critical for billing,
- calldirection: 0 for a call Asterisk receives and 1 for a call
Asterisk initiates,
- accountcode (user modifiable)
- clid: The channel identifier of the call originator equivalent to
the A number on a traditional telco CDR,
- dst: The destination of the call equivalent to the B number on a
traditional telco CDR,
- starttime: The time Asterisk first receives or initiates a call,
- progresstime: The time Asterisk first receives or generates a
progress indication,
- answertime: The time a call is answered,
- endtime: The time a call is hungup or cancelled,
- duration: endtime - starttime,
- billsec: endtime - answertime,
- disposition: ANSWERED, TIMEOUT, CANCELLED, HUNGUP and maybe others,
- userfield (user modifiable): General purpose field for any custom
CDR info needed by Asterisk users.

Some extra fields that I think would also be very (if not very very)
useful to people:

- remoteip: The remote IP address of the call where relevant. For an
incoming call the originator's IP address, for an outgoing call the
desitanation IP address.Apart from being very useful information it
would also be one piece of information useulf in identifying brute
force or DoS attacks,

- linkedid: Where there is a logical link between different calls such
as an incoming call generating an outgoing call this field could be a
common UUID/GUID.This field is not as important as the core ones so if
there are situations where it becomes ambiguous or doesn't make sense
it could be ignored,

- channel: The data that was passed to the channel driver for a call.

Regards,

Greyman.