CDR: finalCalledPartyNumber not correct in 8.6.2

[6rmisior]

Hi,

I have a CUCM  8.6.2.21900-5 and I'm noticing that the CDR records generated have a issue with the finalCalledPartyNumber

The finalCalledPartyNumber is not correct when the call is answered by another number.

For example if an extension 7800 is called and the phone answers the call the finalCalledPArtyNumber is 7800 (this is correct)

If the extension 7800 is called and the call is not answered and it goes to voicemail the 7800 is still put in the finalCalledPartyNumber. Before in this case the finalCalledPartyNumber would have the voicemail number 6500 in this case as the finalCalledPartyNumber.

I'm attaching a CSV file that shows both of the cases / generated file send to SFTP server by the CUCM. I wonder if anyone else is running into this issue?

Thanks,

Robert

[Andrew Skelly]

Is the format of this .csv correct?  It looks like the rows and columns are not aligned properly.

I see a value of 6500 in cell CY10, but there is no column heading.  The value could be misalligned with the proper heading.

[6rmisior]

I did copy and past for the file trying just to get the relevant parts.

The 6500 number is the vocie mail number but in thic case the column name is huntPilotDN.

I did more reasearch into this, at our office we also have CUCM  8.6.2.21900-5 in our case when the call is forwarded to voicemal the voice port's External Phone Mask number is placed in the finalCalledPartyNumber CDR record which I also think is not correct.

Robert

[afrancis95]

Hi 6rmisior,

Have you checked in the service parameters to make sure the following bits are set to false?:

Show Line Group Member DN in finalCalledPartyNumber CDR Field

Show Line Group Member Non Masked DN in finalCalledPartyNumber CDR Field

The way the finalCalledPartyNumber number comes out in the CDR is a nightmare at the best of times anyway!

If it still doesn't come out as you expect it sounds like it could be the 7800 is a shared line?  The same problem happens when we collect the data in our product, and it has to be corrected using other methods.  The same thing happens with transfers too.

Best regards,

Andy