[asterisk-dev] CDR fixes--- Wait a minute!! (LONG)

[Steve Murphy]

OK, I've been agonizing over what changes I'd have to make in the 
SIP driver to accommodate detailed CDR records in the cases where
transfers occur.

And then, it hit me like a freight train... I may not need to be doing
some of this!!!

It occurs to me that most of you may not care exactly what went on with
transfers! So, A transferred the call to B, WHO CARES?

Let's look at one simple example of a simple transfer situation, what
I've been doing to make it complex, and what I could do to make it
simple.

Scenario 7: attended xfer via hookflashes: Zap/52 calls Zap/51; Zap/51
hookflashes, dials Zap/50. Zap/50 answers. 50 and 51 talk, and Zap/51
hookflashes again; it's a 3-way conference now...  Zap/52 hangs up
first; 50 and 51 continue for a while, and then hang up, also.

This involves 2 bridges forming, and some fancy stuff going on to
interlink the conversations.

I picked #7 because it's fresh in my memory. It's a little different
from the other related scenarios, but who cares?

the timing diagram looks something like this:


11:12:08 (52 picks up) --------------O----------------O-----
                                     |                |
11:12:14 (51 ANS) ----- 52==+==51----+A---------------+A
                            |        |                |
11:12:45 (51 HF)
-----------|--------V----------OA----|-----O-----------CDR1
                            |                   |     |     |
11:12:50 (50 ANS) ----------|-----51==+==50-----|(MOH)|-----+A
                            |         |         |     |     |
11:12:54 (51
HF)------------|---------|---------V-----|-----|-----------CDR2
                            |         |               |     |
11:13:06 (52 HU)--------52==
+==51-----|---------------V-----|-----------CDR3
                                      |                     |
11:13:23 (50/51 HU)---------------51==
+==50-----------------V-----------CDR4

In the above, HF=hookflash, ANS=answers, HU=hangs up
O = start time for a CDR
+A = Answer time for a CDR
OA = start and Answer times the same
V = end time for a CDR

CDR1, CDR2, and CDR3 will all have the same uniqueID. (in this case)
CDR4 will have a different uniqueID.  (in this case) (in general,
                                       a second bridge will always
                                       have a different uniqueID.)

Bridges are marked with this notation X==+==Z for when they begin
                                         |
                                         |  for while they are in force
                                         |
                                      X==+==Z for when they close
         The X and Z notation: X is the originating Channel name
         The channel names are repeated at the closing because they CAN
change.

In the above, it might be possible to conclude that the 2nd bridge
(51->50) is
part of a transfer and involves 52, because it starts at the same time
as CDR1 ends, and CDR2 starts/answers.

CDR2 reflects the time 52 was on hold, listening to MOH. 

the time from the end of CDR2 to the end of CDR3 is the time spent in
the
3-way conference.

CDR3 reflects the time the first bridge was in action; the start time is
when 52 picked up, the ANSWER time is the beginning of the bridge, and
the end time when 52 hung up.

CDR4 reflects the 2nd bridge's total lifespan; It starts when 51
hookflashes,
the answer time is when 50 picked up, and it ended with 50/51 hanging
up.

================================ BUT WAIT
=====================================

It hits me that maybe, just maybe, nobody NEEDS this level of detail!

What if.... instead....


11:12:08 (52 picks up) -------------------------------O-----
                                                      |
11:12:14 (51 ANS) ----- 52==+==51---------------------+A
                            |                         |
11:12:45 (51 HF) -----------|-------------------------|-----O----
                            |                         |     |
11:12:50 (50 ANS) ----------|-----51==+==50-----------|-----+A
                            |         |               |     |
11:12:54 (51 HF)------------|---------|---------------|-----|----
                            |         |               |     |
11:13:06 (52 HU)--------52==
+==51-----|---------------V-----|-----------CDR1
                                      |                     |
11:13:23 (50/51 HU)---------------51==
+==50-----------------V-----------CDR2

What if I just gave everybody just CDR1 and CDR2, reflecting the two
bridges instead? Would anyone mourn the loss?

Who would care about the MOH time for 52, the 3-way conference time, the
fact, even, that CDR1 has anything to do with CDR2?

If somebody calls into your switch, and as a process, someone inside
your site transfers them offsite... do you really ever need to bill the
incoming caller for the outgoing call? Wouldn't just the fact that 51
did the deed and opened the connection to the outside world at
$9.99/minute mean that 51 pays the tab, and not 52?

Let me know. If you really, really, really need all this detail. Because
the temptation to cut it out of the code and simplify things is more
than I can resist. The NewCDR stuff I've been working on could be used
if you need a real fine level of detail...

Also, there are some philosophical questions in this kind of CDR system,
that makes apps like ForkCDR of questionable worth... Or at least of
questionable implementation... let me know how you'd use ForkCDR.... or
I'll leave it as it is, or remodel it to my own bidding.

This kind of thing will muck up implementations (maybe) that already
exist. I'm not going to touch 1.2; and I'm beginning to wonder if I
should leave 1.4 alone, too, and only put this sort of thing in
1.6/trunk.

Share your thoughts, or I'll do your thinking for you! Warning! I think
strangely!

murf


-- 
Steve Murphy
Software Developer
Digium
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3227 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20070608/b1e20ddf/smime.bin