09-18-2019 10:10 AM
Need help ASAP. Cisco Tech support not really fast on response time nor do they work during pacific times at least the techs i get not in same time zone. My Extension Mobility was working apprixmiatly 30 days ago just fine. I go to BAT import a group of UDP's. I update the UDP's and the phone devices to be subscribed with no issues. I assign the udp to their perspective end users. No problems. EM is running across all servers. The issue I am having is I can log in the phone but the phone never restarts or resets with the UDP profile. I get no errors. Only indication of successful login is the initial mesage and I can see when i look at the settings again or look up the device on CUCM showing someone is logged in. I can log out the phone as well. I have restarted both the Feature and the network services regarding EM across all servers. I have all restarted TOMCAT via CLI on the pub but did not do it across all servers unless thats needed too. I have deleted everything and started from scratch and get same results. I did this on my home lab with no issues but my work environment not working anymore. Can anyone help with a STEP I may have missed. The only thing I can think of is my NTP for the phones is not working but my home lab has same problem and worked just fine.
Running CUCM 11.5.1
Phone: CP7841
Solved! Go to Solution.
09-19-2019 02:01 PM
I figured out my problem. Couldn't find any documentation on it but the problem was my clock on the phones were roughly 4 mins fast when compare to your watch. This isn't a big deal as long as everything else in your network is subject to the same NTP source. The culprit ended up being that my ESXi NTP configuration was never changed when my team installed the network with NTP authentication and setup proper sources. So when the phones time was enough out of phase when compared to my CUCM servers time EM services would not work essentilly timing out with the process it goes through for it to reset.
09-18-2019 12:05 PM
When I review the phone log messages. This is something that shows up after logging in.
057 INF Sep 18 12:03:15.169025 (542:1311) JAVA-HttpClientWorkingThread|cip.http.HttpClientConnection:? - response status: 3, response code: 200
7058 NOT Sep 18 12:03:15.169574 (542:1311) JAVA-HTTP JNI| processHttpResponseFromJava: complete sending response to Java
7059 NOT Sep 18 12:03:15.170124 (542:1311) JAVA-HTTP JNI| processHttpRequest: complete processing connection 3
7060 NOT Sep 18 12:03:15.348668 (542:1323) JAVA-services MQThread|cip.xml.XmlParser:parse - Encoding Updated to utf-8
7061 ERR Sep 18 12:03:15.364477 (542:1307) JAVA-HTTP JNI| cancelHttpRequest: cancel req_id=3 failed, incorrect state=6
7062 ERR Sep 18 12:03:15.372504 (542:1307) JAVA-HTTP JNI| cancelHttpRequest: cancel req_id=1 failed, incorrect state=6
7063 ERR Sep 18 12:03:15.376380 (542:1307) JAVA-HTTP JNI| cancelHttpRequest: cancel req_id=1 failed, incorrect state=6
7064 ERR Sep 18 12:03:15.378029 (542:1307) JAVA-HTTP JNI| cancelHttpRequest: cancel req_id=1 failed, incorrect state=6
7065 ERR Sep 18 12:03:15.379463 (542:1307) JAVA-HTTP JNI| cancelHttpRequest: cancel req_id=1 failed, incorrect state=6
7066 ERR Sep 18 12:03:15.387734 (542:1307) JAVA-HTTP JNI| cancelHttpRequest: cancel req_id=3 failed, incorrect state=6
7067 ERR Sep 18 12:03:15.403360 (542:1307) JAVA-HTTP JNI| cancelHttpRequest: cancel req_id=3 failed, incorrect state=6
7068 ERR Sep 18 12:03:15.404764 (542:1307) JAVA-HTTP JNI| cancelHttpRequest: cancel req_id=3 failed, incorrect state=6
7069 DEB Sep 18 12:03:16.338291 (542:1335) JAVA-SIPCC-SIP_MSG_SEND: ccsip_register_send_msg: cmd=86=SIP_REG_CANCEL ndx=119
7070 DEB Sep 18 12:03:16.339268 (542:1335) JAVA-SIPCC-SIP_STATE: 1/0, sip_stop_ack_timer: ccb->index=119 ack_timer_index=22
7071 DEB Sep 18 12:03:16.339420 (542:1335) JAVA-SIPCC-SIP_STATE: 1/0, sip_start_ack_timer: ccb->index=119 ack_timer_index=22
7072 DEB Sep 18 12:03:16.340275 (542:1335) JAVA-SIPCC-MSG_SEND_REQ: sipSPIBuildRegisterHeaders: Sending REGISTER.
09-19-2019 02:01 PM
I figured out my problem. Couldn't find any documentation on it but the problem was my clock on the phones were roughly 4 mins fast when compare to your watch. This isn't a big deal as long as everything else in your network is subject to the same NTP source. The culprit ended up being that my ESXi NTP configuration was never changed when my team installed the network with NTP authentication and setup proper sources. So when the phones time was enough out of phase when compared to my CUCM servers time EM services would not work essentilly timing out with the process it goes through for it to reset.
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