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:
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:
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.
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:
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...