[asterisk-users] CDR

[Steve Murphy]

On Tue, 2007-10-16 at 21:25 +0200, Philipp Kempgen wrote:
> Michael Collins wrote:
> 
> > I don't know if it's relevant or not, but I do know that at least one
> > legacy PBX vendor (NEC) has a 'solution' that helps with some of the
> > sillier CDR's that could get generated.  They have what they call a
> > "pseudo-answer timer" which is basically just a way of saying, "If a
> > call doesn't last for at least X number of seconds then it really isn't
> > a call and no CDR should be generated."  It is a bit of a case of
> > throwing away all really short phone calls, even legit ones, but it does
> > also get rid of the silly stuff: I pick up, get dial tone, then hang up
> > or I pick up, dial ext 1234, let it ring for two seconds and then hang
> > up.
> 
> I would definitely want a CDR record in this case.
> 
> Regards,
>   Philipp Kempgen
> 

Michael--

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.

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

And, yes, the butterfly effect is definitely something to consider. And,
I might add, one man's poison, another man's meal, might also apply. I
have yet to see *ANY* cdr suggestion or demand that was not opposed by
somebody, as Philipp demonstrates! ;)

BTW, I just today discovered that what I did all last week is backwards.

For instance, if Zap/52 dials Zap/51, who hookflashes and dials Zap/50,
and 51 hangs up, leaving 52 and 50 to talk away, we should get 1 cdr
that records the call from 52 to 51, which would last until the
hookflash; 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. Even tho 52 and 50 might talk an hour, 51 is the one who
dialed, and therefore seems naturally responsible for the call...

Here is the 12 test cases I am using:
(HF=hookflash, HU=hangup; calls==dials; the numbers 52,51, and 50 are
Zaptel
FXS lines.... although they could just as easily be FXO... 200 is a sip
phone (ran out of zap phones); Make sure the dial commands in your
dialplan have the proper T/t options...!)

1) 52 calls 51, 52 HF, 52 calls 50, 52 HF, (3way), 52 hangs up first,
then 50/51

2) 52 calls 51, 52 HF, 52 calls 50, 52 HF, (3way), 50 hangs up first,
then 52/51

3) 52 calls 51, 52 HF, 52 calls 50, 52 HF, (3way), 51 hangs up first,
then 50/52


4) 52 calls 51, 51 HF, 51 dials 50; 51 HF (3way); 51 hangs up first


5) 52 calls 51, 51 HF, 51 dials 50; 51 HF (3way); 50 hangs up first


6) 52 calls 51, 51 HF, 51 dials 50; 51 HF (3way); 52 hangs up first


7) 52 calls 51, 51 HF, 51 dials 50; 51 HU (after 50 answers); 52 & 50
converse, HU


8) 52 calls 51, 51 HF, 51 dials 50; 51 HU (before 50 answers); 52 & 50
converse, HU


9) 52 calls 51, 51 HF, 51 dials 50; 51 hangs up, 50 answers, 50 HF,
dials 51, hangs up. 51 answers, talks to 52, hangs up.


10) 52 calls 51, 51 hf, 51 dials 50 and 50 answers. 51 HF for 3 way; 50
HF and calls 200; 50 HF again for 3 way (Actually, a 4-way!) 200 HU
first, 50 HU next, 51 HU next


11) 52 calls 51, 51 #xfers to 50, 50 answers, talks, hangs up first


12) 52 calls 51, 51 #xfers to 50, 50 answers, talks, 50 hookflash xfers
to 51 talks to 51, and 50 hangs up; 52 hangs up

You'd not believe how tricky getting these sequences to generate the
"right" CDR data can be! It's almost humorous!




murf

-------------- 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/20071016/7701ef34/attachment.bin