03-29-2018 01:07 PM - edited 03-17-2019 12:31 PM
Hello everyone,
Very strange issue appear with my CUCM 9.1.
From this monday all 9971/8865 phones unable to open Missed calls or Corporate dir. Missed calls just do nothing, Corporate Dir shows "Host not found" error. Of course, I checked Enterprise Param, all is fine there, use IP. Restarting of phones, TomCat won't helpfull too. Meanwhile CIPC - working well.
Logging one of 8865 phones during Missed Calls or CorpDir access displays strange messages like:
NativeUserInput|cip.userio.InputManager:? - Received Navigation: 9
0396 NOT Mar 29 15:12:51.678582 invalid event: Success
0397 DEB Mar 29 15:12:51.678520 (9009:9142) JAVA-appmgr MQThread|Appframe:ALERT stopNotification -
0398 NOT Mar 29 15:12:51.678833 (9009:9152) JAVA-display MQThread|EWProperty:getDurationFromNow - PSP is disabled
0399 NOT Mar 29 15:12:51.882525 (9009:9141) JAVA-NIOGetEvent: hard key event read
0400 NOT Mar 29 15:12:51.882583 (9009:9141) JAVA-CreateKeyEvent type is 2, value is 9 and action is 1
0401 INF Mar 29 15:12:51.882792 (9009:9141) JAVA-NativeUserInput|cip.userio.InputManager:? - Received Navigation: 9
0402 NOT Mar 29 15:12:51.883052 invalid event: Success
0403 NOT Mar 29 15:12:51.883161 (9009:9170) JAVA-contacts MQThread|cip.go4.OverviewModel:detect key - model:ContactsList
0404 WRN Mar 29 15:12:51.883917 (9009:9170) JAVA-contacts MQThread|cip.app.XsiAppData:? - Check if #DEVICENAME# or #EMCC# is present in the URL
0405 NOT Mar 29 15:12:52.292921 (9009:9141) JAVA-NIOGetEvent: hard key event read
or
3334 NOT Mar 29 15:21:25.705823 (9009:9141) JAVA-NIOGetEvent: hard key event read
3335 NOT Mar 29 15:21:25.705875 (9009:9141) JAVA-CreateKeyEvent type is 5, value is 1 and action is 1
3336 INF Mar 29 15:21:25.706116 (9009:9141) JAVA-NativeUserInput|cip.userio.InputManager:? - Received SOFT: 1
3337 NOT Mar 29 15:21:25.706361 invalid event: Success
3338 NOT Mar 29 15:21:25.708363 (9009:10504) JAVA-RDIF Directory/1183474059 MQThread|cip.srvc.XsiOverviewModel:detect key - model:Xsi2
3339 ERR Mar 29 15:21:25.708984 (9009:9145) JAVA-HTTP JNI| cancelHttpRequest: cancel req_id=0 failed, incorrect state=6
3340 ERR Mar 29 15:21:25.709707 (9009:9145) JAVA-HTTP JNI| cancelHttpRequest: cancel req_id=0 failed, incorrect state=6
3341 ERR Mar 29 15:21:25.709774 (9009:9145) JAVA-HTTP JNI| cancelHttpRequest: cancel req_id=0 failed, incorrect state=6
3342 NOT Mar 29 15:21:25.711226 (9009:10504) JAVA-RDIF Directory/1183474059 MQThread|SystemManager:? - SystemManager n/a module "RDIF Directory"/RDIF Directory/1183474059(51) is UNLOADING
3343 NOT Mar 29 15:21:25.711532 29/03/18 15:21:25, SystemManager n/a module "RDIF Directory"/RDIF Directory/1183474059(51) is UNLOADING
3344 NOT Mar 29 15:21:25.711737 (9009:10504) JAVA-RDIF Directory/1183474059 MQThread|SystemManager:? - SystemManager n/a module "RDIF Directory"/RDIF Directory/1183474059(51) is UNLOADED
3345 NOT Mar 29 15:21:25.711977 29/03/18 15:21:25, SystemManager n/a module "RDIF Directory"/RDIF Directory/1183474059(51) is UNLOADED
3346 ERR Mar 29 15:21:25.712918 (9009:9145) JAVA-HTTP JNI| cancelHttpRequest: cancel req_id=0 failed, incorrect state=6
3347 NOT Mar 29 15:21:29.371050 (9009:9232) JAVA-HTTP JNI| processFileResponse: Sending, fileName=/tmp/cache/messages to client with additional headers: (null)
3348 NOT Mar 29 15:21:29.981054 (9009:9231) JAVA-HTTP JNI| processStatusResponse: call mg_printf with HTTP/1.1 200 OK Content-Type: text/plain Content-Length: 50 Content: The requested URL was not found on the web server.
So, for now, i'm lack of ideas (pathes and new firmwares useless too...).
Have anyone face this problem?
03-29-2018 01:31 PM
Do you have any expired certificates?
03-29-2018 01:34 PM
03-31-2018 12:33 PM
> I checked Enterprise Param, all is fine there, use IP.
You can’t do this in modern versions due to the Secure Service URLs. The server’s IPv4 address is not listed in the Tomcat certificate as a SAN. The TLS handshake will fail if the server portion of the URL doesn’t appear in the certificate. Return the Service URLs to DNS FQDN and ensure the IP Phones have a valid internal DNS server to resolve with.
Also, your comment that “all non-Trust certificates have been regenerated” is concerning because if done without great care you risk breaking the ITL chain of trust. If that happens, it would also cause the symptoms you’re seeing since TVS may not be trusted by the phone, causing it to reject the Tomcat certificate presented by CUCM.
04-02-2018 03:36 AM
So, regeneration of ITL chain can help?
04-02-2018 05:08 AM
Have you seen this:
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