[asterisk-users] CDR

[Steve Murphy]

On Wed, 2007-10-17 at 02:41 +0200, Philipp Kempgen wrote:
> Steve Murphy wrote:
> 
> > It's not a bad idea, but I think the philosophy would be that whatever
> > turns CDR records into billing statements could/should/would decide
> > which to skip, and which to process, and not something in Asterisk. It's
> > "easier" just to state what happens, and let each org that uses the data
> > decide what to do with it.
> 
> I like that approach. I think it should be possible to tell exactly
> what happened just by looking at the CDRs (e.g. who transferred
> which call to whom etc.)
> 
> > As far as picking up handsets, and dropping them again, such would
> > always have 0 duration and billsec figures, because an answer is needed
> > for either field to be greater than zero. I guess in this regime, they'd
> > all be dropped if you set your threshold at 1 or more...
> 
> Dropping records with duration == 0 is an easy task for custom
> post-processing. Even more so if you store your CDRs in an SQL
> database.
> 
> > 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". 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.

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.


> > Even tho 52 and 50 might talk an hour, 51 is the one who
> > dialed, and therefore seems naturally responsible for the call...
> 
> 51 is responsible, correct. But the fact that it was 52 (not 51)
> who talked to 50 might be equally important.
> 

True.

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

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.

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.

And another issue you brought up earlier-- collect calls. 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.)


> 
> > You'd not believe how tricky getting these sequences to generate the
> > "right" CDR data can be! It's almost humorous!
> 
> This could be much easier if Asterisk did not have fancy
> features like transfers etc. ;)

I totally agree!!!!

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

> 
> Regards,
>   Philipp Kempgen
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3239 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20071019/661133b5/attachment.bin