CM 3.0(11) CDR oddities

[Kluso]

I'm using CallManager 3.0(11) with a WS-X6608-T1 for call egress and conferencing.

My call detail records are incorrect when I use the WS-X6608-T1 for a transfer or conference. In both cases the called number appears in the CallingPartyNumber field. So I can't tell which phone actually placed the call. This situation is making billing IMPOSSIBLE!

Has anyone else seen this? Is this unique to the 6608 blade or is this behavior the same on all gateways? Has it been fixed in CallManager 3.1?

For testing, I placed a call from IP phone extension 100 to PSTN 2311111111 held that call for 30 seconds then transferred the call to PSTN 2312222222. I left the call between 2311111111 and 2312222222 up for 60 seconds before hanging up both phones. These are the CDRs I got:

CallingParty,Duration,FinalCalledParty,GlobalCallId,LastRedirectDn,OriginalCalledParty

100,30,2311111111,4260,2311111111,2311111111

100,6,2312222222,4259,2312222222,2312222222

2311111111,70,2132222222,4258,2312222222,2312222222

The 3rd record implies 2311111111 called 2312222222. But it was actually extension 100 that called both numbers. The GlobalCallId field is unique for each call so I can't use it to associate the 3rd record to extension 100.

The records are even more bizarre when extension 100 places a call to 2311111111 then conferences with 2312222222. These are the resulting CDRs:

CallingParty,Duration,FinalCalledParty,GlobalCallId,LastRedirectDn,OriginalCalledParty

100,6,2312222222,4281,2312222222,2312222222

100,11,b00110001001,4278,b00110001001,2312222222

2311111111,28,b00110001001,4278,b00110001001,b00110001001

2312222222,28,b00110001001,4278,b00110001001,b00110001001

The first record implies 2312222222 was the first number called. 2311111111 was really the first party called and 2312222222 was added via conference. The next 3 records have the same GlobalCallId but what is b00110001001? Why do the called parties appear as the calling party number?

For a real brain twister, extension 100 could then transfer this conference to another extension or PSTN number. I've done it but will mercifully spare you the gore of resulting CDRs.

[dgoodwin]

I sit right next to the TAC engineer that owns the case you opened. We are going to research this and see what we can find out for you.

[dgoodwin]

Okay, here is some info for you. We did some testing and research, and what you are seeing is normal. The first call is the outbound PSTN call. Then second call is after you pressed the transfer key and dialed the other PSTN number. The third call is the call after you pressed the transfer key a second time (this call is still being handled in CallManager since it is still using our gateway(s).

This shortcoming in the CDR (which really just has to do with properly identifying why special calls like this took place) is addressed in CallManager 3.1. A new field is added called JoinOnBehalfOf which is a hex field that can have a variety of values. The values are here:

http://www.cisco.com/univercd/cc/td/doc/product/voice/vpdd/cdd/3_1/cdr.htm#xtocid1279646

and you should probably go over that whole page as there is a lot of good info there on CM3.1 CDR.

Note - if you want to identify all calls that are joined in some manner due to special circumstances such as transfer, conference, park, etc. then you can use this SQL command:

use cdr

 select *

 from calldetailrecord

 where joinonbehalf != 0

Also, the b00110001001 looking identifiers are just conference IDs. They are not normal looking numbers since an adhoc conference has no called number per se.