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.
I’m currently working on a VOIP project consisting of a pair of UC560s and some SPA508G Phones. Configuration for the project is pretty straight forward as no fancy or complex translation rules need to be created. The client is basically replacing their current antique Nortel system with a modern Cisco solution.
The steps required for me to get the system up to a basic state to perform tests were as follows:
- Configure a DHCP Pool for all IP Phones.
- Copy tftp files for the SPA508G phones to flash.
- Configured UC560 to serve up the files so that the phones are able to download their configuration.
- Basic ephone-dn and ephone configurations to test phones.
- Create and assign IP to loopback interface.
- Configure Service-Engine interface to use loopback interface
- Configure IP address and default-gateway of CUE
- Test connectivity to CUE by pinging interface and also establishing connection.
- Configure user accounts in CUE and assign Voicemail mailboxes to users.
- Perform Tests.
As you can see from the list, this truly is a simple deploy.
All configurations were proceeding just fine until I arrived at step 8. At this stage I should be able to both establish a connection to CUE and also receive replies from pings. However this wasn’t so. For some reason all my ping tests were failing. I checked, rechecked, checked again, then checked again to make sure my configs were correct.
Here’s an example of what the configuration would look like.
!Loopback interface created to use with our Service Engine interface. (Cisco's recommended way of configuring it) interface Loopback0 ip address 192.168.1.1 255.255.255.0 !Service Engine interface used to communicate with the Cisco Unity Express. interface Integrated-Service-Engine0/0 description Loopback interface used to manage integrated application module ip unnumbered Loopback0 service-module ip address 192.168.1.2 255.255.255.0 service-module ip default-gateway 192.168.1.1
Did I miss anything? From the configuration we see that the IP Address of the CUE is 192.168.1.2 and the IP address used to communicate with the CUE is 192.168.1.1 which is the IP of the Loopback interface.
For reasons unknowing to me, this configuration was not working. I was able to successfully establish a session to the CUE, logged in using the same credentials used to login to the UC560 and I was able to proceed with further configurations tasks. I was able to create user accounts, assign them mailboxes, assign Voicemail number so that the application is activated whenever that number is dialed etc. Unfortunately ping tests were still failing and as such when I made a test call to Voicemail, it did not work. There is one step I forgot to include in the list above, and that was to create a dial-peer so that whenever users dialed the Voicemail number it would use that particular dial-peer to transfer the call to the correct destination thereby activating the Voicemail system. This was also completed and the configuration for this can be seen below.
dial-peer voice 2 voip destination-pattern 600 session protocol sipv2 session target ipv4:192.168.1.2 dtmf-relay sip-notify codec g711ulaw no vad
I spent hours researching Cisco’s documentation and reading through different forums. Eventually I saw a user on IPexpert’s OSL was having the same issue. He was able to access and ping CUE whenever he used a physical interface or a SVI as opposed to using a Loopback interface. I decided to test this out for myself by using an SVI, Vlan1 and changed the configuration on the Service Engine to use Vlan1 instead of Loopback0. Of course this worked flawlessly! I was able to ping the CUE IP which enabled me to proceed with my further configuration and testing.
I found the whole thing really interesting, as no where on Cisco’s site mentioned there being instances where the Loopback interface wouldn’t work. Have any of you VOICE folks out there experienced this problem before? Did I miss something with my configs? And please don’t tell me that I needed to reboot/reload/reset CUE as I did this so many times till at one point I had to do a complete factory reset to get basic communication again. 🙂