Runt post: When voicemail is a dirty word

New deployments often require configuring a direct transfer to voicemail. Not too long ago @ifoam wrote this great piece on the steps involved in setting up this up: Transfer to Voicemail, which I recently referred to when I found that my configuration wasn’t working.

The article, however, confirmed my suspicions that I hadn’t missed any steps in the system configuration process, but when calls were transferred straight to the voicemail server, the user extensions weren’t coming along for the ride.

Fast forward several research minutes later to this obscurity, in particular the third entry by Randall White: https://supportforums.cisco.com/thread/2053902

Upon first reading, I found the fix too absurd to be likely, which I’m sure why Mr. White added the “no, I’m not joking” part. The solution being proposed was the removal of the word “voicemail” from the alerting name of the CTI route point.

For those of us in voice, we’re rather familiar with what the alerting name controls, and no, it doesn’t usually have anything to do with this. Alerting name shows up on phone displays and it’s generally one of those put-whatever-you-want-here-the-system-doesn’t-care fields. Except in this case it did. It cared a lot.

So instead of calling my CTI route point Direct To Voicemail – I changed it to Direct To VM. Yep, that was it. I removed the offending vocabulary, quit infringing on the voicemail server’s sensitivities, and all was set right with the world.

And this is why voice engineers drink.

Publish Date: 2011/11/28

User speak madness

One of the most valuable skills an engineer can possess is the ability to translate user speak into reality. When a user presents you with the dreaded “the network is down” complaint, an engineer has to be able to decipher that gem of ambiguity into the actual issue at hand. This can be tricky since users often conspire to give you only half the facts, and then misrepresent the other half. This is mostly because they are bored and us banging our heads in frustration provides them some entertainment value. Okay, that may or may not represent their actual (evil) intentions, but it’s safe to say you are rarely given a true picture of the situation when tossed in the troubleshooting pit.

For example, it was reported that all calls placed from a branch office to the central site were failing. In addition, it was reported that the branch site could not reach voicemail, a centralized resource. No other sites were reporting issues so this presented like classic WAN link failure to the branch site. However, when I logged into the Call Manager server and saw all the branch phones registered and happy, it was time to come up with a new theory.

So what looks like WAN failure but isn’t? In this case, a series of unsuccessful pings to the voicemail server gave me all the information I needed. It wasn’t at all that calls were failing to from the branch site to the central site as users had reported- it was that calls were ringing those extensions and then going to voicemail – which was currently DOWN. The fact that calls were ringing four or five times before “failing” had been left out of the reports entirely.

This got me thinking about some of other infamous “translations” I’ve encountered that have helped hone my skills with user speak and caused me to develop a nervous twitch whenever the phone rings:

Report that the wireless was down. Meant that user was trying to connect to wireless from a workstation that didn’t have a wireless card.

Report that outbound dialing to a branch was broken for all users. Meant that user was confused by the sound of dial tone, stopped dialing, and therefore never completed the calls.

Report that the phone system couldn’t dial an outside phone number. Meant that user was trying to dial a number that had been disconnected for years.

Report that the fax machine no longer worked. Meant that user moved fax machine and plugged it into a dead wall jack.

Page that the paging system is down. Page received. You can guess what this meant about the user…

Please feel free to share your amusing encounters with user speak, would love to hear them!

Presence and peace of mind, not necessarily compatible…

I categorize configuring Presence as a test of endurance and concentration. Fifty bazillion steps, forget one, and you’ll spend hours hunting down never-ending oddities in the CUPS client’s behavior.

And even if you do configure it all right, I’ve recently found you *still* get to hunt down mysteries of bizarre grandness.

The situation unfolded like this: new deployment, about sixty users, all but four can get logged into their CUPS client. Not a bad ratio, but unfortunately the four remaining users aren’t going to be pleased until the success rate hits 100%. Some users are *so* picky.

Quick glance at the configuration confirmed that these four users were in no way special configuration-wise, all the Cisco Unified Communication Manager (CUCM) and Presence configuration hoops had been successfully navigated, leaving the reason for the users’ login failures elusive.

At this point in troubleshooting, I decide it’s a really good idea to isolate the system at fault. Too many options on the table- the culprit could be the CUPS client, CUCM, the Presence server, or even Active Directory- time to narrow it down to exactly which device needs a good kicking.

Ruling out the client piece, that’s super easy. Logged in as someone else successfully – time to move on, nothing to see here.

Next up, CUCM. Since Presence passes login requests over to CUCM, which is this case is LDAP integrated, it’s necessary to confirm that CUCM and AD are making nice with one another.

Since I’ve got about 50 some odd users (some odder than others) having no problems logging in, I’m comfortable that the overall LDAP integration configuration is likely in good shape. So how to isolate an issue with a single user login?

I prefer using the ccmuser web page. For those not familiar, users can go to this web address: http://ipaddressofserver/ccmuser to setup options for his/her phone. This is a fabulous feature for administrators who get tired of adding/modifying yet another speed dial for Sue down the hall who gets on your last nerve.

The ccmuser page is also an awesome tool for LDAP integration testing – if the user can login to the ccmuser page successfully, you know that CUCM has successfully pulled the users credentials from AD.* If they can’t, you need to hunt down the weird little sysadmin guy because he’s got some explaining to do.

In the case at hand, three out of four of the problem users couldn’t login into the ccmuser page. This brings me to the next step of troubleshooting: pleading with the weird little sysadmin guy to reset the users’ passwords. Yes, you will have to plead, because no way the sysadmin takes your word for it that the passwords he set for the users isn’t what he thinks it is. Don’t be afraid to bribe them either. Sysadmins will do anything for a coffee and a cookie. Seriously, anything. Need you’re bathroom remodeled? Your car washed?

Anyway, 3 password resets later, and only 1 problem user remains between myself and a decent lunch. User de annoyance can login to the ccmuser page but still cannot login to CUPS. Out of standard tricks at this point, I google this: user cannot login cups but can ccmuser. I know, very creative, it’s a gift. My search found me this gem: http://www.learnios.com/viewtopic.php?f=4&t=30324 .

In the post, a user presents a similar issue, although an older version of Presence, and the fix suggested is to restart the “Cisco UP Sync Agent” and the Cisco Tomcat service, the latter needing to be done via the command line by typing utils service restart Cisco Tomcat. User mentions that just restarting the Sync Agent worked for him, but I found that I had to do both to resolve the issue. I’m just lucky that way.

So there you have it. Even if the configuration on your Presence server is pristine, you may find yourself wading through issues that turn your hair (what’s left of it) prematurely gray and make you wish you’d chosen a career as a potato farmer.

*Being able to login to the ccmuser page is also contingent on the user being assigned the Standard CCM Users group in CUCM. Do this from User Management in CUCM.