[asterisk-users] Simple CDRs

[Leif Madsen]

Steve Murphy wrote:
> So, what I'm thinking, is to spec out two CDR generation modes,
> one detailed one according to the spec I'm working on, and the
> other mode will follow these lines...

Hmmm... I'm liking this idea so far.

> On Tue, 2009-01-06 at 10:37 +0000, Grey Man wrote:
>>> so, if A calls B, B parks A,

CDR generated (hangup event due to attd-xfer)

>>> A's park expires, B is rung,
>>> B answers, B xfers A to C, they hang up,

CDR generated (hangup event)

>>> we should have
>>> a CDR for A's time, with the start time being the time
>>> the PBX created the channel for A; the answer time would
>>> be (if A is an incoming call) when the PBX answered the
>>> incoming call and maybe started giving A the IVR experience,
>>> and (if A is an extension), when B answered the call. The
>>> end time would be when A was hung up.

In the above scenario, would there be a CDR for when B was called (start 
time when B answers, or some other event in the dialplan that causes an 
answer, i.e. Answer(), Playback(), etc...), and then and then hungup? 
The hangup would be when B attd-xfer A to the parking lot, and B was 
then hung up.

>>>
>>> A CDR for B would be generated? with his answer time when
>>> he picked up the phone to answer the incoming call from A?
>>> and an end time when he parked A?

Aha... it seems we agree :)

>>> Another CDR for B would be produced he answered the callback
>>> from the PBX for the expired session with A, and end when
>>> he got hung up xferring the call to C?

Agreed.

>>> Another CDR for C would be produced to record C's conversation
>>> with A, start when his phone started ringing, answer when he
>>> answered, and end when he hung up?

Also agreed.

>>> Am I on the right track?

Based on the premise that a CDR would be generated whenever a channel 
was hung up, then yes, it appears I'm in agreement with you.


>> I don't use Parking myself so my understanding may be slightly off but
>> from what I do understand of Parking the CDRs would not be generated
>> quite how you describe. The main point is that Parking a call should
>> not generate a CDR as the Park operation has not necessarily ended a
>> call.
> 
> Parking a call will hang you up, in most normal cases. This includes
> calling the Park() app, bxfer to the parking exten, and using the
> one-touch parking features. But, if some strange combo of events
> allows someone to park without a hangup, then I'd agree, no CDR 
> should be generated.

I'm in agreement with how Murf has described the above scenario. If 
you're going to "keep it simple(tm)" and generate a CDR whenever a 
channel is hung up, then what Murf has outlined would generate the CDRs 
as described.

>> In your description I think the CDRs should be:
>>
>> 1 The call from A to the PBX, start time when B answers, end time when
>> the A-C call is hungup,
> 
> 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.

If at all possible, it would be nice if you could build the A-C hangup 
time, i.e. when call enters the PBX, and when the call is disconnected 
from the PBX. Ideally you could get a less fine grained picture of a 
single channels life in the PBX, time-wise.

> 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

(or a Background(silence/1&...) or Playback(silence/1&...) which would 
also answer the channel)

> 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?

Simple CDRs should be as simple as possible. No heuristics should be 
done automatically. Perhaps there would be enough information in the 
CDRs to do this after the fact?

> 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'm in agreement with this. A is a live channel. It was processed (I 
specifically don't say 'answered' here), and then terminated. The 
disposition should tell me something about the attempted call, which you 
  have outlined.

Perhaps we don't want to use the words "Answered" and "Hungup" here. 
Maybe a better description of a CDR generate is when a 'channel' is 
'processed' and 'terminated' instead. The disposition would tell us 
whether it was answered or not.

>> 2. The call from the PBX to B, start time when B answers, end time
>> when the call to B is hungup once the blind transfer of A to C is
>> initiated,
> 
> The start time will be when B is first dialed; The answer time when
> he answers.
> 
> 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'm pretty sure I'm in agreement with Murf here with how the CDRs should 
be generated in this scenario.

>> 3. The call from the PBX to C, start time when C answers Am end time
>> when the A-C call is hungup.
>>
>> I think the main difference in our approaches is that to me the PBX,
>> in this case Asterisk, should be considered a black box as far as the
>> CDRs are concerned. Things like parking, holding, re-inviting to
>> change codecs, etc. etc. are all irrelevant events as far as a CDR is
>> concerned. The only events of relevance are when the calls to and from
>> end points external to the PBX are answered and hungup.

Based on this paragraph, is seems Aaron would expect a single CDR for 
call coming into Asterisk (A), and a single CDR to be generated when A 
is then hung up. (Excuse me if I have over simplified your thoughts.)

However, based on the way I know Asterisk works with channels, I would 
expect 2 CDRs to be generated for every call between end points (when A 
calls B). This is because there is a channel from A to Asterisk (CDR) 
and from Asterisk to B (CDR).

I do have to agree that being able to get a picture of the A --> 
Termination as a 'single record' could make the CDRs a bit simpler, but 
I think that approach needs to be based on some sort of unique tag that 
would follow channel A around the PBX. I think Murf has mentioned some 
things can happen to cause that channel to go away, and to not allow 
that unique identifier to persist in all situations, however the 
specifics of why and how that happens are hazy at best.




Those are at least a few of my thoughts from a third party observer :)

Leif Madsen.
http://www.leifmadsen.com
http://www.asteriskdocs.org