Had a strange one today…
A colleague completed a CUCM upgrade from 10.5 in-version. No issues were experienced after the minor upgrade. However, a few days later the client called reporting their contact center and switchboard as down. This had apparently occurred directly after a power failure in their server room. Single server BE6K installation.
I jumped onto the gateway, confirming a 404 sent from CUCM to the SIP Gateway. No routing changes had taken place, so i assumed something was down – immediately thinking CTI. Their switchboard IVR was fairly complex, so a script had been written on UCCX instead of using Unity Connection AA functionality with Call Handlers. Reviewing the CTI Ports and Route Points showed me the problem – both “Unknown” – i.e. down since the last reboot.
I next moved to UCCX, and first check CCX Serviceability, noting that Cisco Unified CCX Engine was in Partial Service. Drilling down to the Sub-System, I could see that Unified CM Telephony Subsystem was marked as OUT OF SERVICE, which made perfect sense due to the non-registration on CUCM. As all other services were in service, this ruled out any script-related issue as well. So… time to look at JTAPI.
After enabling Debugging on the JTAPI logs on CCX, the fault was clear from the logs:
226: Aug 07 13:07:03.201 SAST %JTAPI-JTAPI-7-UNK:[CTIRP_12345]CiscoRegistrationExceptionImpl caught: Device registration failed because of unsupported device IP Addressing capability
227: Aug 07 13:07:08.202 SAST %JTAPI-JTAPI-7-UNK:(P1-JTAPI_1)[MIVR_SS_TEL_PROVIDER-39-0-INIT][CTIRP_12345] getIPAddressingMode= 2
228: Aug 07 13:07:08.202 SAST %JTAPI-JTAPI-7-UNK:(P1-JTAPI_1)[MIVR_SS_TEL_PROVIDER-39-0-INIT][CTIRP_12345]Request: register( myhostname/192.168.1.2, 0, capabilities: “G.711 A-law 64k 30 frame packet size”, “G.711 U-law 64k 30 frame packet size”, algorithmIDs: null, IPv6 address: null)
A quick google (which should have happened sooner!) identified the support forum thread, with an immediate bug match:
https://tools.cisco.com/bugsearch/bug/CSCuq26061
My only concern was only that I didn’t have an exact version match, as my UCCX was only on version 10.5.1, not 10.6 as quoted in the bug. However, CUCM did have a similar match.
Workaround was easy – I implemented the CDC as per the documented workaround in CSCuq26061. In my case, I had to apply this to both the CTI Ports and Route Points. After a Device Reset, Data Resync, JTAPI Resync (both unnecessary really) and CCX Engine restart, the ports all came up. I’d recommend BAT here if you face the same. I tested this on one CTI Port, found it working, then applied to all + CTI RP’s.
Been hitting a few bugs in 10.5 for CCX – hope this helps someone else.
#dontcalltac
