Troubleshooting Tip: Solving a Persistent Cisco IP Phone Registration Issue

Troubleshooting Cisco IP phone registration issues. The project sounded easy … at first. By the time I was finished, I realized things aren’t always as easy as they sound. Just allow me to narrate error_f1-ytsvdmy experiences for you.

I happened to engage with one of our customers for a new cluster installation and to migrate some of the phones. As usual, per the best practices, I built the cluster and set the enterprise parameter “Prepare Cluster for Rollback to pre 8.0” for a smooth migration. That way I wouldn’t have to fight the ITL, CTL certificate issue.

The plan was to get the TFTP IP Option 150 changed for the production cutover, so the phones would be migrated over to the new cluster without any complaints. As a test process, I had the alternate TFTP IP applied to the new cluster & registered an IP phone that was configured using the BAT tool. It was registered. Everything was hunky dory to that point, but it wouldn’t last.

Next, I picked up a 7962 phone from the existing production cluster and deleted it from there. Then I manually added that phone in the new CUCM and, just like that, the registration failed. I received an error that read “Registration Rejected” and the phone still showed the Unified CM addresses as the existing production cluster. It showed that even though the alternate TFTP server was set. Hence, for some reason, the phone didn’t clear the configs from the previous registration. I performed a factory reset and yet the issue remained. The initial log analysis and checking didn’t reveal any evidence and everything seemed fine from the first glance. My engineer mind told me to take a deep breath and then dive into the logs. While looking at the phone console logs, I noticed a weird message (shown below):

 

4004: NOT 06:58:26.583489 JVM: Startup Module Loader|cip.cfg.h:? – ====>123Config handleTftpResponse, status=20 for file=ram/SEPB000B4D9B628.cnf.xml

4005: WRN 06:58:26.584933 JVM: Startup Module Loader|cip.xml.au:parse – Encoding Updated to UTF-8

4006: WRN 06:58:26.586363 JVM: Startup Module Loader|cip.xml.au:  – XML Parser Warning: Unknown element ‘portalDefaultServer’ in element ‘/device’ (line=4)

4007: ERR 06:58:26.587867 JVM: Startup Module Loader|cip.xml.au:  – XML Parser Exception: null (line=6)

4008: ERR 06:58:26.589281 JVM: Startup Module Loader|cip.cfg.h:? – ERROR PARSING CONFIG file:ram/SEPB000B4D9B628.cnf.xml

4009: NOT 06:58:26.606517 JVM: Startup Module Loader|cip.cfg.h:? – Config processConfigNoError() result code=CONFIG_FILE_BAD_FORMAT

 

I then tried pulling the phone’s config file (below) from the CUCM TFTP server to check on line 6.

 

<device  xsi:type=”axl:XIPPhone” ctiid=”54″ uuid=”{ea3a8c84-9e44-7cdc-3bed-f09965ecdf0a}”>

<fullConfig>true</fullConfig>

<portalDefaultServer>CUCMTCS01.corp.com</portalDefaultServer>

<deviceProtocol>SCCP</deviceProtocol>

<sshUserId>administrator</sshUserId>

<sshPassword>???V??u?
</sshPassword>

 

This was the SSH password from the device configuration that’s being auto populated from the FireFox web browser used. It was also adding the IP phone from the Saved Logins for the CUCM Admin username & password.

When I tried from the Internet Explorer web browser and applied the config file with blank SSH User/Pass, the phone came up and registered.

That’s how my so-called simple IP phone registration issue ended up taking a fairly significant amount of time to solve. However, the important thing is, it did get solved!

Happy troubleshooting.

Arraya Insights