I have a CUCM 220.127.116.1100-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?
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 18.104.22.16800-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.
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.
These are the paths to get to each CCX logs through CLI. They may be helpful if you are having issues accessing RTMT or downloading logs through it.
If you want to download them you have to prefix "file get " and you can add one of the options (re...