CCM 4.1(3) bug about CDR

[abouhich]

Hello,

i want know if there is a bug about a cdr?

many thaks

[Rob Huffman]

Hi Hicham,

I counted 15 bugs first found with CCM 4.1(3) that were related to CDR. Can you be more specific about the nature of the problem you are having? The bugs have been fixed in later SR's like 4.1(3)sr3c.

Hope this helps!

Rob

Please remember to rate helpful posts.....

[abouhich]

Hello Rob,

please find the explanation of the problem above.

We have a billing solution (MEIPS) integrated to CCM version 4.1(3).

When starting a query at MEIPS about the forwarded call to external destinations, we get only the information about the

initiated call.

when asking the MEIPS Support (MIND), they told us that the problem is a bug known by cisco.

Here is an example to describe the probleme

example :

1_extention A call external number (Mobile number) duration 2 mn.

2_extention A transferet the communication to extension B.

3_extension B communicate 5 mn.

the 3rd call is insered in the CDR database like an incoming forwarderd call.

so when we start a query about the forwarded call, the 3rd call is not taxed,

thanks

Hicham

[Rob Huffman]

Hi Hicham,

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.

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_programming_usage_guide09186a00806556fb.html#wp29989

Hope this helps!

Rob

[abouhich]

Hi rob,

I had sent your answer to the MIND support (MEIPS), and has their answer:

###################################

I extracted from the CDR the records for the call that was made. Here's a description of the case below :

Scenario :

Extension 9243 calls external number 1061314689 , and afterwards makes a transfer to extension 9272 .

The driver should generate 2 calls from the above scenario, based on the CDR records :

1) Outgoing call from 9243 to 1061314689, until the transfer was made

2) Outgoing forwarded (transferred) call from 9272 to 1061314689, starting with the time the transfer was made; 9243 should be in the Ext2 field

Corresponding CDR records :

1.

1,1,311601,17518309,1160753742,1,0,621023660,,9243,0,126,621023660,16384,4,20,0,17518310,1,17518310,90613952,,1061314689,1061314689,0,126,90613952,19072,4,20,0,1160753754,1160753779,1061314689,CDG_Nat,logue,CDG_Nat,CDG_Nat,25,SEP0016472DB18B,192.168.102.5,0,0,0,10,10,0,0,StandAloneCluster,0,4,0,0,0,0,0,4,0,0,0,0,0,,slime,,,0,

Result - see attached screenshot - 9243 to external - CORRECT

2.

1,1,311601,17518310,1160753779,1,17518310,90613952,,1061314689,0,0,90613952,19072,4,20,0,17518323,1,0,100929964,,9272,9272,0,16,100929964,16384,4,20,0,1160753782,1160753869,9243,logue,CDG_Nat,logue,logue,87,192.168.102.5,SEP0016472DB261,0,4,0,0,12,0,10,StandAloneCluster,10,4,0,0,0,0,0,4,0,0,0,0,0,,,ylahlou,,0,

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 ?

Best Regards,

##########################################

I want to know your opinion concerning this answer.

Many thanks

Hicham

[Rob Huffman]

Hi Hicham,

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.

Let us know how you make out with this,

Rob