05-12-2016 05:29 AM - edited 03-17-2019 06:53 AM
Hi All,
We encountered unusual behavior wherein our configured setting for Billing Application Server Parameters in CUCM suddenly cannot send the CDR going to a server using FTP. It is working before and we just noticed that the sending of CDR has been stop.
For isolation, we configured different setting that will send CDR to the same server using SFTP and the sending of CDR was successful.
We tried to isolate further the issue by using other PC and transfer a file to the same server using FTP and the file sending was successful. With this, we came up that there is nothing wrong in the network.
The next action plan we did, we restarted the Cisco CDR Repository Manager service. After restarting this service, the configured setting for Billing Application Server Parameters is now working again using FTP.
We would like to know what is the cause of the issue regarding FTP in Call Manager? Our version of Call Manager is 8.6.2.20000-2. Is there a bug related to this king of issue?
Thank you.
Solved! Go to Solution.
05-12-2016 07:33 PM
Hi Kevin,
I went through the logs.
its seems that you had the following config.
Destination 1 hostname: 10.220.3.115
Destination 1 userid: lcsftp
Destination 2 hostname: 10.220.3.115
Destination 2 userid: cisco (this seems to be for the testing purpose using SFTP)
It looks like that you restarted the service at 17:25:59.
After this there was just one instance of failure at 17:30:03 for destination 1.
2016-05-11 17:30:03,092 ERROR [Thread-9] cdrrep.FtpManager (FtpManager.java:210) - java.net.SocketException: Connection reset
2016-05-11 17:30:03,092 ERROR [Thread-9] cdrrep.FtpManager (FtpManager.java:223) - SFTP/FTP failed: cdr_StandAloneCluster_01_201605092256_20321 to 10.220.3.115
I can't tell you why it failed as the logs are set to INFO and not Debug.
Also before restarting service i did not see any failure for destination 1 but for destination 2 which is out of the picture.
Please rate if helpful.
Regards,
Adarsh Chauhan
05-12-2016 05:50 AM
Hi Kiervin,
There are many cdr related bugs in 8.6.2 version but none matches this issue exactly. Ideally you should have collected the cdr traces and contacted TAC for an RCA when the issue was happening. From my understanding if the reports were being sent when you used a different PC then it is likely not a cucm issue, otherwise the behavior would have been the same for all PC's.
Manish
05-12-2016 06:50 PM
Hi Manish,
Thank you for the information regarding the bug.
We use different PC and use FTP but issue still encountered, so we are isolated that the issue might be in CUCM since we resolved it after restarting the CDR reporsitroy manager service. We just want to know now if what is the cause of the issue.
05-12-2016 10:05 AM
Hi Kiervin,
If the issue has happened recently you should collect Repository manager traces of that time frame.
Just look around that time stamp and you should be able to figure out the failure in them.
The traces are easy to read.
Regards,
Adarsh Chauhan
05-12-2016 06:48 PM
05-12-2016 07:33 PM
Hi Kevin,
I went through the logs.
its seems that you had the following config.
Destination 1 hostname: 10.220.3.115
Destination 1 userid: lcsftp
Destination 2 hostname: 10.220.3.115
Destination 2 userid: cisco (this seems to be for the testing purpose using SFTP)
It looks like that you restarted the service at 17:25:59.
After this there was just one instance of failure at 17:30:03 for destination 1.
2016-05-11 17:30:03,092 ERROR [Thread-9] cdrrep.FtpManager (FtpManager.java:210) - java.net.SocketException: Connection reset
2016-05-11 17:30:03,092 ERROR [Thread-9] cdrrep.FtpManager (FtpManager.java:223) - SFTP/FTP failed: cdr_StandAloneCluster_01_201605092256_20321 to 10.220.3.115
I can't tell you why it failed as the logs are set to INFO and not Debug.
Also before restarting service i did not see any failure for destination 1 but for destination 2 which is out of the picture.
Please rate if helpful.
Regards,
Adarsh Chauhan
05-12-2016 07:44 PM
Hi Adarsh,
Thanks a lot for the information and checking. Yup, when I also checked the logs, i can't see a detailed information to identify the reason of the issue. Actually the one that you have checked was the time when we are isolating the issue by recreating other server having username of lcsftp and cisco.
The other folder from the logs i attached which was dated on May 4, this is the time wherein no configuration changes made while we are encountering the issue. However there is no detailed information also on those logs.
With this, is it possible to turn on level of the logs from info to debug? Will it affect the production of CUCM or its utilization if the CDR Repository Manager is set to debug level?
Again, Thank you so much Adarsh for the help.
05-12-2016 07:50 PM
Hi Kiervin,
You can turn level of logs to DEBUG.
It won't affect your production.
Please rate if helpful and give a closure to this thread.
Regards,
Adarsh Chauhan
05-12-2016 08:09 PM
Hi Adarsh,
Tried checking the trace for CDR Reporsitory Manager and I have one question regarding the level of trace.
Do we need to choose Debug level or Fatal?
Thanks.
05-12-2016 08:10 PM
Hi Kiervin,
It would be debug.
Regards,
Adarsh Chauhan
05-12-2016 08:13 PM
Hi Adarsh,
Thanks a lot. Really appreciate your help.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide