One of my favorite things about my job is working with Cisco’s Unified Communications Manager (CUCM). It’s so robust and complex that there always seems to be something new to learn.  Last week I ran into a couple of interesting issues that I thought I’d share with you.

The first is an issue for which I’ve been trying to find a solution for several weeks.  One of our clients was experiencing issues with external auto-attendants recognizing the DTMF tones their phones were sending.  What made this issue particularly strange is that if the user was on speaker phone they were able to get the remote AA to respond to the DTMF tones without issue.

I searched Google several times with various terms looking for this issue and was finally able to find a thread concerning DTMF working on speakerphone but not on the headset in CUCM.  Someone in the thread had opened a bug report, number CSCsv04751, and this led to a resolution.

The following is an excerpt from the Bug Details on Cisco.com:

Symptom:
Duplicate DTMF is detected and users have problems entering DTMF mid-call.  The side tone from the phone appears to be introduced into the RTP stream in addition to the out-of-band signaling normally sent.

Workaround:
Both speaker phone and the headset use a different side tone than the handset and they should not experience the same DTMF problem.  Downgrading the firmware is the only other workaround.

Basically what was happening is that CUCM was sending both the in-band, which would only be recognized by other Cisco equipment, and the out-of-band DTMF tones, which we have enabled for compatibility with other vendors equipment.  The in-band tones were not being properly squelched by CUCM and so the remote AA was receiving both tones and getting confused by the input.  This issue effects phones using the 8.4.1 firmware so I resolved by upgrading the phone firmware to 8.4.2 (which Cisco confirmed that the bug was fixed in).

The second was something I’ve done numerous times in Cisco Unified Communications Manager Express (CUCME).  Our client wanted to be able to manage the greeting on their auto-attendant from a remote location.  On the CUCME this is simply a matter of pointing a DID to the extension of the built-in prompt management system.

Here the capabilities of CUCM worked as a disadvantage as configuring the same thing required several more steps and was much less intuitive.  In addition to creating a DID, this service request required the creation of a new routing rule, a new call handler and elevated permissions for a user.

This process was further complicated by the fact that CUCM consists of several interconnected GUIs rather than the single point of management that CUCME offers.  This is an unfortunate rule of thumb in the technology world; when you get an increase in the power and functionality of your systems there is often an increase in the complexity and learning curve.