CUCME-CUE Labs - CUCME Release 7.1 Update

Before moving onto to the next series of labs, I've updated the router code to reflect the newest CUCME 7.1 update. Using the Cisco Unified CME 7.1 Supported Firmware, Platforms, Memory, and Voice Products, the updates consist of the following:

• cme-124-22YB1.zip: contains all of the appropriate CUCME packages, except the actual IOS.
• IOS 12.4(22)YB, c2800nm-adventerprisek9_ivs-mz.124-22.YB.bin, feature set "INT VOICE/VIDEO GK, IPIPGW, TDMIP GW AES"

For the upgrade, I completed the following procedures:

1. Booted the routers. I also back up the configs.
2. Cleaned up the existing flash, removing the existing IOS code, gui files, phones loads, so on. Note, on the NY router, I copied the modified ring lists and "Lets Go Mets Go" ringtone to the root directory on flash.
3. Uploaded the new IOS. Rebooted.
4. Uploaded the appropriate TAR files (gui, ringtones, phone loads)
5. Modified the existing configs to reflect the new phone loads, etc.
6. Began poking around...

During which should have been a straight forward update, I noticed the following pecularities:

The SIP phone loads for the 79xx phones are now bundled with the CUCME Zip package, which means that you no longer have to fish for these separately.

During the phone upgrade failed initially on the Baltimore SCCP router. Upon further investigation, the phones stated that the JAR files could not be located. After playing around with various commands, the router console barked that the "system" was not a valid location associated with the "load 7942 SCCP42.8-4-2S" command. I untuitively poked around under the "telephony-service" section and added the "cnf-file location flash:". Note, this was not required for the SIP router (NY).

The NY upgrade started off without any hitches. However, when I tried to test calls across the VOIP link to Baltimore, the phones in NY would just dial the number and sit idle, until eventually timing out with a fast busy. This proved to be a very time consuming troubleshooting process...

1. I began by looking at the VOIP (SIP) dial peers configured CUCME-CUE Lab 4 – CUCME POTS & VoIP Dial Peers. Everything looks correct. Hmm...
2. After spending an inordinate amount of time dwelling above, I modified the dial peers to H323. Vola! calls were working correctly across the VOIP link. So, I reset them back to SIP.
3. I started tweaking various parameters, such as the “destination-pattern” as well as the “dialplan patterns”. After some nerd-knob tuning, I was able to pass calls. Cool, or so I thought.
4. However, upon closer inspection, the calls were using the PSTN, not the VOIP link.
5. After beating my head against the wall for another 90 minutes or so, looking at various debug outputs, and consulting various documentation on CCO, the thought occurred to look elsewhere. This time I deactivated call fallback on one end. At this point, I was able to pass a call across the VOIP link. Ok, on to something.
6. I still not want to give up on call fallback. I consulted the Configuring SIP QoS Features chapter of the Cisco IOS SIP Configuration Guide, Release 12.4T. Upon my interpretation of this document, call fallback should be a fairly straight-forward and simple configuration. However, despite my efforts, I could not get call fall to work properly with the SIP dial peer.

The end result was to remove all the call fallback parameters discussed on CUCME-CUE Lab 4 – CUCME POTS & VoIP Dial Peers. I hesitate to call this a “bug” since in my personal experience most “bugs” = user misconfiguration. I’ll return to this at a later date, but for now I will move on without this command.