To all,
We’ve opened a couple of tickets in the past when our UC560 quit sending CDR to our NSS324 in the past. Clearing it usually required we simply turn CDR reporting off and then back on again. Unfortunately, that didn’t fix it this time.
I’d been waiting until this weekend so I could update to CCA 3.0(1) and the 8.0.1 software pack. I did that and I could still not get the UC560 to send CDR to the NSS324.
My guess is I’ve got something wrong in my configuration. We have switched to Windows and there is the possibility this is a routing or credentials issue. I can ping the NAS device from the UC560 on all of its interfaces. Here’s a sample:
Here are the call detail records failing over to flash for storage:
Here is the Call Accounting dialog box:
My guess is something is wrong with the above data, but I don’t know how force the UC560 to try to write the CDR records and throw an error I can see. This has worked in the past (but the URL may have changed). I can reach the ftp site of the NAS device at ftp://nss324/cdr with the credentials I've entered.
Any ideas how to debug this so I can force the write to the ftp site and see where the UC560 is failing?
Dave
Accepted Solutions
Adam,
Thanks for the input. You were right on target. I was with Cisco Support on another issue and I dragged this one in to them. They agreed with your debug suggestions and what we located was that I had the URL entry was incorrect. Instead of the FQDN or IP and the name of the folder, the folder had to be followed by a forward slash and then the root name I wanted used for the CDR files saved to the NAS device. Here is how the correct configuration looks:
So to recap, the folder on the ftp share of the NAS device is called cdr. It needs a trailing slash to let the UC know it is a folder and not the prefix to the file name. I also wanted all of the files from the UC to be prefixed with the same string 'cdr' in front of the name Cisco uses for each CDR file.
You pointed us in the irght direction, so I gave you the points for the right answer.
Thank you again for your help,
Dave
