Today’s Random Voice Experiences.
Today’s task was to deploy a couple of 7962 Phones along with some 7915 Expansion Modules. This shouldn’t be too bad. All I need to do is head over to the client with the gear and configure their CME to accept the new phones and modules. How hard could this be? This should take me probably 2 hours max! Heh! Don’t know who I was kidding. By now I should be well aware that nothing goes as planned in networking, more so in Voice :-).
So I’m over at the client and begin by unpacking the phones, connect them up to the switch and begin my CME configurations. Ephones created, phone registers just fine and hey! I was even able to successfully place a test call. Things are progressing as planned. Next up is to test the expansion modules. Connected up the 7915 modules but for some reason they wouldn’t power up. Did a quick search on google and turns out that these modules need power supplies if the phones are power via POE which was the case here. If the phones are powered via power supply, then you don’t need a separate power supply for the first module. However, for the second module you most definitely require a power supply. Good points to know. So after heading back to the office to acquire a power supply, I was able to get the modules powered up. Now they powered up just fine but didn’t display the lines they were configured for. They just sat there stuck with the amber lights on. Time to hit up my buddy google again. He pointed me to some really cool forums which informed me that the firmware on my phone needs to be at 8.4( they’re currently 8.3 at this stage). Five minutes later and I have ver 9.2 downloaded and copied to the UC560. Rebooted the phones so that they can begin the upgrade process only to be hit with more good fortune. For whatever reason these phones weren’t upgrading. The process kept failing. Eventually I think I tried so many different stuff that the phone would not complete the boot process anymore and load it’s configuration. It would just stay stuck at “Upgrading” and then reboot, going through this cycle repeatedly.
At this point I figured da hell with it! Reset this baby to factory default and start over. If you head over to Cisco’s site for instructions on how to restore this model phone to factory default, they state this. After ensuring that I had everything in place as advised, I proceeded with the reset sequence. This proved to be unsuccessful. After entering 123456789*0# the phone simply went back to the state of “Upgrading”. My frustration level at this point was of course reaching max. Ok, so time to turn on some debugs and go from there. Enabling debugs for tftp enabled me to see what files the phone was looking for. First file I noticed it was not finding was “term62.default.loads”. Rechecking my tftp-server configurations revealed that I had the alias configured incorrectly, leaving out the .loads which prevented the phone from finding the file. I corrected this and proceeded with the factory reset procedure once again only to be greeted with the same error. This time the file that couldn’t be located was “jar42sccp.8-3-3ES2.sbn”. This one really puzzled me as the tftp configurations for this file was correct! This was where the engineer in me came to life! Comparing the firmware files I noticed that the very first file the phone looks for “term62.default.loads” was a lot smaller than the other files. It was 1KB to be exact, when compare to others that were 2439KB. This lead me to believe that this file probably just contained instructions. Opening the file with notepad revealed some gibberish followed by an orderly list of files. The files in this list were the same firmware files but in a particular order. Comparing the order the files were listed in to the order I had my tftp-server statements showed that my statements were in a different order from that of the list. This got me to thinking that maybe I should reorder my statements to the same order that was in the file. This indeed proved to be the problem because as soon as I reconfigured my tftp-server statements the phone successfully restored to factory default. Ok, so I’m some what relieved at this stage. I got the phones back to a working state however, the 7915 module still doesn’t work as we’re back to the 8.3 firmware. I proceeded to use the same logic used to perform the factory restore and retried upgrading the firmware with ver 9.2. This too was successful and the module booted up and dispalyed it’s configuration correctly.
I highly doubt this is how this procedure is supposed to work, though. What happens if your tftp server isn’t the CME device and it’s actually a server? How does it know the order? Maybe this was just a bug in my case as I haven’t seen any other reports of this while researching the issue. In anycase, it was a learning experience, one that will surely help me in the future should I encounter this problem again.