[asterisk-users] CDR

[Philipp Kempgen]

Steve Murphy wrote:
> On Wed, 2007-10-17 at 02:41 +0200, Philipp Kempgen wrote:
>> Steve Murphy wrote:

(Sorry for quoting so much but I need to keep the context.)

>>> For instance, if Zap/52 dials Zap/51,
>> 52 --- dials & talks ---> 51
>>
>>> who hookflashes and dials Zap/50,
>> 51 ------- dials -------> 50
>>
>>> and 51 hangs up, leaving 52 and 50 to talk away,
>> 52 ------- talks -------> 50
>>
>>> we should get 1 cdr
>>> that records the call from 52 to 51, which would last until the
>>> hookflash;
>> No doubt about it.
>>
>>> and a second CDR that would be from 51 to 50, which would
>>> start at either chan 50/51 channel creation time, or even at hookflash
>>> time, have an answer time when 50 picked up, and last until either 50 or
>>> 52 hang up.
>> Right. But why should it start at 50->51 channel creation time?
>> That way you would think (by looking at the CDRs) that 51 talked to
>> 50 for longer than they did. I'd prefer hookflash time.
>>
> 
> Well, the "start" time isn't as important as the "answer" time; because
> your billing times from "answer" to "end".

True if billing was the only thing CDRs are good for.

> The time from "start" to
> "answer" is how much time it took to dial, wait, and have the call
> answered... which people usually don't pay as much attention to.

Right. But nonetheless the value that gets stored should be as
accurate as possible. Or else you could just store a random
value because nobody cares about it anyway. ;)

> 50's channel creation time will be when 50 picked up the phone to answer
> the call from 51.
> 
> 51's channel creation time will be when 51 picked up the phone to answer
> the call from 52.
> 
> If we use 51's channel creation time as the start time, it would be
> possible to see that 52's conversation with 51 and 51's with 50,
> overlap. It may not help much, but it's a hint that 52 was there.

Need to think about it for a while.

>> How about splitting the "src" into "rsp" (who's responsible for the
>> call, i.e. who should pay the bill) and "src" (who was involved in
>> the audio bridge)?
>>
>> Example:
>> rsp  src  dst  duration  billsec
>> 52    52   51       130      120
>> 51    51   50        10        5
>> 51    52   50      3610     3600
> 
> Actually, I've been thinking about this; adding a CDR field to record
> the responsible party for a call is a good way to handle these
> situations.
> 
> But, in 1.4, I really can't add a new CDR field and call it a 'bug fix'.
> It really is a 'new', 'enhanced' sort of thing. So, this kind of change
> will have to go into trunk at the moment.

Sad but true.
I guess it couldn't go in even if there was a config option
defaulting to off (i.e. old-style behavior)?

> Since I can't add the new field into 1.4, I'm restricted to having to
> record something true and useful, and I have to surrender what could be
> a valuable
> piece of information: how much time 52 spent talking to 50. But, as far
> as billing is concerned, I would save the most valuable thing: that 51
> made the call to 50, and ****that**** call lasted xxx seconds, no matter
> who else may or not have spent time in the circuit.

Right.

> And another complication not brought up by this scenario, concerns
> 3-ways. (really, using assisted xfer, you can form n-way conferences
> this way)-- CDR's like the 3rd one you listed above, would add up to way
> more seconds than were
> actually spent on the call. I guess we could set such CDR's to
> DOCUMENTATION instead of BILLING (or whatever), to mark them.

Haven't yet decided on how I would naturally expect such things
to appear in the CDRs.

> And another issue you brought up earlier-- collect calls.

Actually I wrote that later. Maybe the first messages was delayed
before showing up on the list. Whatever.

> I see in the
> libpri code, that there's a q931 Information element that signals a
> collect call; perhaps we can insinuate this into the CDR's and dialplan
> somehow, to either
> record or even block incoming collect calls. (I guess it'd be a good
> selling point for moving to PRI.)

I had guessed that this is signaled on PRI but wasn't sure.
Could be made available to the dialplan as a channel variable.
And possibly as a flag or something in the CDRs but that would
certainly not pass as a bugfix.

> Transfers, parking, masquerading, local channels! Bah!!! Humbug!! 
> :)

Humbug - I wasn't aware that this word existed in English.
Same thing for German. :)

Regards,
  Philipp Kempgen

-- 
amooma GmbH - Bachstr. 126 - 56566 Neuwied - http://www.amooma.de
    Let's use IT to solve problems and not to create new ones.
          Asterisk? -> http://www.das-asterisk-buch.de

Geschäftsführer: Stefan Wintermeyer
Handelsregister: Neuwied B 14998