You know, I think the CCM CDR is actually working as expected. Have a look at this explanation for the records created for a call like you have described (the chart really shows it well). It seems to me that the MEIPS query may need to be modified to look at the correct fields. Can you check with the support group (MIND) to see if they have the bug # (like: CSCsd49924 ). I did not see any of the 15 bugs that sounded like this.
Transfer Without Consultation
A single CDR cannot show call transfer, which is too complex to show. Each time that a call is transferred, the Cisco CallManager terminates the CDR for that call. The process of transferring a call, without consultation, involves the creation of three CDRs. The first CDR reflects the call between the original two parties (A and B), the second CDR represents the (zero length) call between the transferring party (A) and the new party (C), and the final CDR reflects the call between B and C.
No CDR reflects the time that a call is on hold. If a call is through a PSTN gateway, the call accrues charges that are not reflected in the CDRs while the call is on hold.
Result - see attached screenshot - 9272 to external - INCORRECT
There is a problem with the last call - it is processed as Incoming Forward instead of Outgoing Forward. Although the scenario assumes an outgoing call, the CDR record generated by the Call Manager indicates an incoming call :
the origSpan field contains a different-from-0 value, while the destSpan field is 0;
the callingPartyNumber field is the mobile number (1061314689);
the finalCalledPartyNumber and originalCalledPartyNumber is the extension number (9272)
Now, according to how the CDR data looks, our driver processes the call correctly (Incoming Forward). What i don't understand is why the Call Manager sends the last call in that format (so, as an Incoming Forward) - can you check this with someone from Cisco or check if there's something to be configured on the Call Manager ?
I want to know your opinion concerning this answer.
I think that what needs to be done now is to open a case with Cisco Tac. Get the Bug ID from MIND Support, so it can be forwarded to Cisco. This may be a problem with a straight forward workaround, but we need to know the Bug ID.
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...