[asterisk-dev] CDR Fixings

Steve Murphy murf at digium.com
Fri Jun 1 22:34:27 MST 2007

I'm hard at work, reshaping the CDR code to handle transfers better...

I'll show you what I'm doing, and now's your chance to correct things!

Teminology:  HF=hookflash;  HU= hang up;  ->  = dials  A= Answers

Ref: my branch:  team/murf/CDRfix5 (derived from trunk)

Scenario 1: Simple. 152 calls 151. They talk. They hang up.

Example output: (1 CDR)

TtWw","2007-06-01 20:41:56","2007-06-01 20:42:08","2007-06-01

No big changes here.

Scenario 2: blind xfer via # key 152->151; 151->#150; 150 A

Example output: (2 CDR's)

TtWw","2007-06-01 20:43:02","2007-06-01 20:43:10","2007-06-01

TtWw","2007-06-01 20:43:27","2007-06-01 20:43:31","2007-06-01

Notes: the first CDR is emitted when the "#" button is hit.

Scenario 3: blind xfer via "transfer.blind" buttons on SIP phone
            152->201; 201 hits transfer, then blind buttons, 200; 200 A
200 HU

Example output: (2 CDRs)

<152>","152","s","extension","Zap/52-1","SIP/polycom430-08267d80","Dial","SIP/polycom430|30|TtWw","2007-06-01 22:29:07","2007-06-01 22:29:24","2007-06-01 22:29:41","34","17","ANSWERED","DOCUMENTATION","","1180758547.47",""

<152>","152","s","extension","Zap/52-1","SIP/snom360-08271a38","Dial","SIP/snom360|30|TtWw","2007-06-01 22:29:41","2007-06-01 22:29:48","2007-06-01 22:29:53","12","5","ANSWERED","DOCUMENTATION","","1180758547.47",""

Notes: the first CDR is emitted when the "send" soft button is hit.
Scenario 4: blind xfer via Zap hookflash (152->151; 151 HF; 151->150;
151 HU
                                          while ringing.)

Example output: (3 CDRs)

TtWw","2007-06-01 20:53:24","2007-06-01 20:53:33","2007-06-01

<151>","151","s","extension","Zap/51-1<ZOMBIE>","Zap/51-1","Dial","Zap/51|30|TtWw","2007-06-01 20:53:24","2007-06-01 20:53:33","2007-06-01 20:53:55","31","22","ANSWERED","DOCUMENTATION","","1180752804.22",""

TtWw","2007-06-01 20:53:52","2007-06-01 20:53:59","2007-06-01

Ugh. Changes for scen.5 loused up CDR#2 in this scenario... It should be
Zap/52, not a zombied 51... I'll check into it.

The first CDR is generated at the first HF. The second, when 151 hangs
up after dialing. The last, when 152 or 150 hang up. If 151 doesn't hang
up fast enough,
the 2nd CDR will record the time spent talking with 151; the 2nd CDR is
messed up. I'll see if I can start it when #1 ends... (before I worked
on Scen#5, Scen#4
generated only two CDRs! :))

Scenario 5: Zap Attended xfer: (152->151; 151 HF; 151->150; 151 HF; 151
                                    152/150 HU.)

Example output: (4 CDR's)

TtWw","2007-06-01 19:17:24","2007-06-01 19:17:31","2007-06-01

19:17:37","2007-06-01 19:17:37","2007-06-01

""fxs.52 <152>","152","s","extension","Zap/52-1","Zap/51-1",
"3WAY","Zap/51-1","2007-06-01 19:17:51","2007-06-01

TtWw","2007-06-01 19:17:37","2007-06-01 19:17:43","2007-06-01

Notes: 1st CDR emitted on first HF; 2nd emitted on 2nd HF; 3rd emitted
when 151 hangs up;  Last when 152 or 150 hang up.

2nd CDR has MOH for app; it actually documents when 152 was played MOH
during the xfer. The 3WAY time started with HF #2, ended when 151 hung
up. For the moment, 
you can determine the 3rd party by finding the record with the same
clid, and a start time equal to the first CDR's end time. Basically CDR
#1 + CDR #4 account for the entire time that 152 spent connected to
151/150. You can just drop "MOH" and "3WAY" records if this is not

As from above, you can probably make out that I'd like to keep the
"source" caller the same thru the sequence. I also try to keep the
uniqueid the same thru the sequence, but that gets hard when dealing
with multiple bridges that don't even share the same channel. I'd like
to put the 3rd channel in a 3WAY in the appdata field, but it's hiding
somewhere in the zap driver.

Any thoughts on what you'd like to see/ don't want to see... tell me!

More to come...


Steve Murphy
Software Developer
-------------- 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/20070601/037eef69/smime-0001.bin

More information about the asterisk-dev mailing list