Category: CUCM Features

New codec on the block – recording failures and CUCM 11.x

The inspiration for this post comes from spending way too much time trying to solve an issue that would have taken only minutes had I been aware of the key information I’m generously bestowing upon my fine readers today.

The problem started with reports that just 8841 phones weren’t successfully recording. I happened to have a spare 8841 phone, so I set up a line, configured recording parameters, and began testing. Sure enough – the recording failed on the spare phone.  I also happened to have a 7942 phone, set up an extension and the recording worked just fine.  Note that I had previously examined the endpoint configurations like recording server profile, Built in Bridge enabled, recording calling search space, and recording server setup for the extension.

Thinking this might be related to a SIP versus SCCP issue, I employed the RTMT to see if the audio for the SIP calls was being forked and sent to the recording server. I was able to drill into the SIP call placed to the recording server, check out the Call Flow Diagram, and confirm the recording server was invited to the party.  If you’ve not done this before, just need to log into the RTMT and navigate to Real Time Monitoring Tool -> Voice/Video -> Session Trace Log View -> Real Time Data. While snooping around all the SIP calls to the recording server, I noticed some successes belonging to 8841 phones.  Intrigued that my problem might not be model dependent, I hopped over to the recording server to see which extensions on 8841 phones *did* record successfully.  Which is where things began to make even less sense – only intermittent failures on some 8841 phones in question, others never recorded at all.

Using my any-excuse-for-a-packet-capture philosophy, I setup two 8841 phone endpoints to allow spanning to PC port and fired up Wireshark.  My test recording failed, but my packet analysis hit pay dirt.  When filtering for RTP, I saw PT=OPUS in the Info column.  Immediately, I had my answer.

I was vaguely aware the Opus codec was a thing, but I previously had no idea that 8841 phones supported the OPUS codec and that CUCM 11.X enabled the OPUS codec automagically (thanks?) – all information I gleaned from this link.

Knowing that recording servers historically hate anything that isn’t g.711 or maybe g.729, I immediately proceeded to follow the instructions from the aforementioned link to find and disable Opus for recorded phones. I previously did this for g.722 many years ago, which is why this solution stung a little, my not being aware there was a new codec on the block and to have preemptively avoided this issue entirely.

from https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/200591-OPUS-Codec-Overview.html

While looking at the Opus parameter, I couldn’t help but notice iSAC was new to me as well.  Sifting through my packet captures, I found RTP streams using that codec as well and so disabled it for recorded phones, too.

Below are a couple of screen shots of what you can expect to see in the SIP/SDP packets if you are experiencing this same issue. Hopefully this saves you a bit of leg work should you have some recording failures after an 11.x upgrade.

Feel free to send thanks in the form of flowers, coffee, and cheesecake.

Published 10/18/2018

8841s and line selection woes…

Just a quick post in case there is at least one other person in the world that didn’t know this particular trick for the 8800* series phones that always go off hook on the last line used.  In case you weren’t aware that these phones had this behavior, don’t worry, as soon as you deploy one to a receptionist that handles more than a single phone line, you WILL be made aware. You may not survive the encounter, but you will know…

Should the user let you live long enough to research a solution, you will find that TAC doesn’t offer you any hope in restoring the requisite amount of receptionist happiness to keep oxygen flowing to your lungs. TAC will politely inform you that the phone is operating as designed and that you might want to buy the receptionist some flowers instead.  Okay, maybe that last part was my idea…

Technically TAC is right, you cannot force the phone back to selecting the primary line after hanging up a call that was answered or placed on any of the other lines. However, as my awesomely brilliant coworker discovered, you can change the behavior of the phone so that when calls come in they are DISPLAYED on the primary line.

This way, when the user hangs ups, the phone still has the primary line selected, even if the last call received was for one of the other lines on the phone. This mimics a behavior users have come to know and love of the older generation of phones, a behavior users who manage multiple lines desperately want back.

You can set this option on the phone configuration page, just search for Show All Calls and change the feature to Enabled.

Show All Calls on Primary Line

This won’t make the remembering-the-last-line-selected-for-off-hook behavior go away, but it does make its impact far less noticeable to end users who might otherwise want to plot your demise.

* In this case we were working with 8841 phones, but my coworker has used this trick in the past on 9971 phones, so I’d be inclined to believe this would work on pretty much any SIP phone that has this behavior. 

Published 04/11/2016

Updating DNS server IP addresses on Cisco voice servers

This post focuses on something that went right when making voice changes – shocking, I know!  Yes, I did open two different TAC cases before making the changes, and yes, I did have to talk to TAC once during the actual change process, but in my book, that’s a total win.

My mission, which the sys admin gave me no choice but to accept, was to change the DNS ip addresses each voice server was pointing to.  Now in sys admin world, this is hardly a big thing, but in voice world, no change is so small and insignificant that cannot be made intricately cumbersome to complete.

If you live in the CUCM 8.x universe, you are probably familiar now with the concept of a license mac. Changing any of the components that went into generating the precious license mac for the server invalidates all the pretty, pretty licenses you spent hours (likely even days) of your life trying to get in the first place. Changing primary DNS *is* one of those components in 8.x, so accepting your fate of needing to rehost licenses for ALL THE THINGS is step one in 8.x universe. Step two likely involves some heavy drinking.

But I currently live in 9.1.2 world – so some of this misery is offset.  The CUCM and Unity Connection (UNCX) teams at some point decided this whole invalidating-the-licenses-for-minor-changes deal was a suckfest, at least I’m assuming that was their thought process, so with version 9.x, changing primary DNS server ip address for CUCM and UNCX servers doesn’t upset the license mac gods. Cisco IM&P now leverages CUCM licensing in 9.x, so no rehosting required for those servers, either.

UCCX, though. Of course UCCX still cares. Because UCCX.

So enough background and onto the process – which is pretty straightforward considering it’s voice stuffs. Standard disclaimer, I put this list together from various calls with TAC asking for documentation and clarification on the process for each application and what to expect. Your mileage may vary, don’t take my word for it, always have a good backup, and certainly don’t blow your voice servers up. Check the docs, check with TAC. Note that for each application, the changes are made on the publisher/primary server first, then any subscribers or secondary servers.

For CUCM and UNCX servers:

-In the GUI of the License server, remove the CUCM or UNCX server instance from the License server.  Yes, I know the trepidation of deleting anything from a voice server – especially involving licensing, but it is strongly recommended to do so. If you forget or don’t do this, PROBABLY nothing will happen, according to my conversations with TAC.  But no way I’m taking that chance, you decide for yourself…

-At the CLI of the server, issue the following commands:

set network dns primary X.X.X.X
set network dns secondary X.X.X.X
show network eth0 – confirm the changes

-Add the instance back to the license server and synchronize. When adding the server back, remember it’s the OS username and password that you want to be using.

-Additional step for CUCM highly recommended by TAC: restart the Cisco Tomcat service at the CLI with the command utils service restart Cisco Tomcat

-This is also the process for stand alone license servers, but of course you don’t have to remove any instances from the license server or perform the Tomcat restart.

For IM&P servers:

-At the CLI of the server, issue the following commands:

set network dns primary X.X.X.X – note you will still get an error message that rehosting is required, but I confirmed later with TAC that this is just a holdover error message from the 8.x days.
set network dns secondary X.X.X.X
show network eth0 – confirm the changes

For UCCX servers (note I have an HA environment):

-Take note of the current server license MAC, put it in a safe place.  I copied the contents of the license files to my desktop and took a screenshot of the current license configuration page. Because it’s voice and the paranoia with licensing runs deep.

-Sacrifice a chicken or two, and then at the CLI of the server, issue the following commands on each server:

set network dns primary X.X.X.X
set network dns secondary X.X.X.X
show network eth0 (confirm the changes)

-Reboot the primary, wait for what feels like an eternity for the primary to come back up and get it’s services started, then reboot the secondary.

-Take note of the new license mac and request a rehost, provide licensing with the new and the old license macs.

-Load the new license file and start happy dance.  Unless you hit an issue like I did and the new license won’t load. Then try another reboot of the pair, attempt license load once more with fingers more tightly crossed than before, and then proceed to happy dance.

Last, but not least, my good twitter friend and awesome voice guru Ryan Huff pointed out to me this Answer File Generator tool which can be used to predict your new license mac so you can request a rehost in advance. I decided that the 30 day grace period for UCCX would be enough for this project, but it’s fantastic to know that such a thing exists. Especially if you are going to be invalidating a lot of licenses, have a very small change window, and want to go ahead and get off grace period licensing as quickly as possible*.

 

*my rehosted license file for UCCX was generated in under 15 mins. Impressive. Still a PITA, but at least a quick PITA…

Published 09/09/2015

 

 

 

 

 

 

 

 

PLAR, UCCX, Redirects, oh my…

Typically my UCCX (Unified Cisco Contact Center Express) stories involve much weeping and gnashing of teeth, but here’s one that (mostly) just left me scratching my head for a while.

I got a ticket reporting that a courtesy phone in a lobby was no longer working. After a little digging, I found that this phone was put in place to be a PLAR (private line automatic ringdown) phone, and when users picked up the handset they were greeted with an unfriendly fast busy instead of being courteously and automatically connected to the proper extension.

The phone in question was assigned its own Calling Search Space (CSS) and that CSS contained a single partition with a single translation pattern. This pattern translated “nothing” (meaning the user enters no digits) to an extension, but in typical network discovery fashion, I found that this extension pointed to yet another extension assigned to a different translation pattern and then that was pointed to a UCCX trigger. Yes, because complexity always makes the network run better.

First order of business, simplify. This extra translation didn’t seem likely to be the cause of the issue at hand, but it certainly wasn’t necessary so by pointing the PLAR translation the to UCCX trigger directly I made my life a whole lot easier, which I am a huge fan of doing.

Knowing what I know about UCCX and CUCM hand-offs, I honed in quickly on determining if the CSS of the translation pattern could “reach” the UCCX trigger.  The device calling the UCCX trigger has to have access to the partition the trigger is in otherwise the call isn’t going through, and you’re going to be having a bad day.

In this case, we are actually talking about the CSS of the translation pattern and upon inspection the translation pattern was assigned a CSS that included the partition the UCCX trigger was in.

At this point, I needed to prove to myself that this was a UCCX issue and not a general CUCM issue, so I changed the destination on the translation pattern to my own extension – also in the same partition as the UCCX trigger. Worked like a charm. Definitely looking like UCCX weirdness then…

Quickly tired of grasping at straws, I took some logs from CUCM and threw them into Translator X and Notepad++, both of these tools are awesome and if you are not using them, you should be!

Here’s the line I kept seeing from my CUCM traces, indicating what I first suspected, a CSS issue:

10:03:35.086 |Digit analysis: potentialMatches=NoPotentialMatchesExist

CUCM could not find a potential match for the destination directory number in any partition in the CSS of the translation pattern. Which didn’t make sense. Which is why Contact Center so often makes me wanna cry.

I decided it was time to talk to my excellent friends over at TAC. After reviewing the configuration with the engineer, I was presented with Bug ID CSCso91760* which basically reports that instead of using the CSS on the translation pattern redirecting the call, the hand-off was using the CSS of the originating phone. In our case this meant the CSS being used was the PLAR CSS of the phone – which couldn’t reach anything except that single PLAR translation pattern. Lovely.

The fix was simple enough, though. In UCCX**, just go to the configuration page for the trigger and click the “Show More” button at the bottom.  Then look for Calling Search Space for Redirect under the Directory Number Settings Section. Change the CSS from Default Calling Search Space to whatever CSS you need for the call to go through.

Here’s what you should be looking for in the trigger settings page, you can see that Default Calling Search Space is, well, the default:

redirect

Nothing further required, problem solved. Yay you! Now somebody pass the tissues…

Published July 17, 2013.

*CCO account required

**UCCX version in this case is 8.5, I was too lazy to research if earlier version have this same option box, if you have an earlier version and you don’t see this option, you may want an extra box of tissues.

You old softie…

If you already know how to add a softkey template to a 3905, 8961, 9951 running as a SIP phones, you get a gold star, a free pass, and an opportunity to move along, there’s really nothing to see here.

But, if you’re like me, a voice engineer that spends a good deal of time supporting older releases and older models of phones, here’s something you might not have run into as of yet.

To configure a softkey template on one of these newer phones running as SIP, your old ways are useless and will leave you feeling puzzled and shunned by devices that should obey your every whim.

Why is this?  Well, even though you can still apply a Softkey Template on the phone configuration page of these new SIP phones, the device will just ignore it, much like an insolent teenager ignores a parent telling them to get a hair cut or turn that music down.

So what’s the deal?

Let me introduce you to the concept of a Feature Control Policy.  A Feature Control Policy allows you to select options that you are traditionally used to defining on a softkey template, but because everyone *loves* change, you now get to define them here – in the place nobody bothered to tell you about.

To create a Feature Control Policy, go to Device -> Device Settings -> Feature Control Policy and Add New.

Yours will look something like this:

Only yours will be wrong if it looks like this.

You see, it isn’t enough that this process changed entirely from the old way of doing it, BUT, the process has one more trick for you to overcome.  Just checking the Enable Setting box for the feature you want to show up on your phone doesn’t cut it.  You gotta go that extra step and check the Override Default box for your option as well.  Why?  Because the interface designers have a dastardly sense of humor is my guess.  Whatever the reason, check the column on the left and the column on the right for your desired feature, otherwise the results will be rather disappointing.

To apply this beautiful gem of a Feature Control Policy you just created, you need to assign it to the phone. You can do so on the phone configuration page. Be sure to go ahead and reset your device.

So that’s it. Note that there is no re-ordering of buttons in this brave new world.  Your button order is predetermined and no you cannot bribe it to display otherwise, no matter how many beers are offered to the networking gods.

Published 11/13/2012

Upgrades 101

I find the upgrade research process far more entertaining if you approach it like a less than ideal scavenger hunt – a poorly planned, slightly brutal game of talent and luck- mixed with just a pinch of despair.

In this example, which will not begin to cover all the ways/paths/routes you can go for an upgrade, we will take a common scenario and walk through the basic research process. This is more to outline the process and things you should be checking rather than trying to be a comprehensive list of links for upgrades.

I apologize in advance for all the links in this post that will inevitably become dead after a matter of time, but there’s only so much in the universe I can control. Also, I shouldn’t have to say this, but ALWAYS check the latest versions of the documentation – things change – but it’s highly unlikely I’ll modify this post to reflect it.  I’m just lazy that way.

Let’s say in our example you have 5 unified communications servers in your cluster and are looking to upgrade to the latest & greatest versions of each product:
2 Call Managers – MCS7825-H3 with 2×160 GB drives and 2 GB of memory running 7.1.3.20000-2
1 Unity server – MCS7825-H3 with 2×160 GB drives and 2 GB memory running Unity 8.0
2 UCCX servers – MCS7825-H3 with 2×160 GB drives and 2 GB memory running 7.0(1)SR05_Build504

Let’s start with determining the upgrade path for your Unity server:
In case you have been living under a rock, the reign of tyranny Unity has enjoyed over voice engineers has been given an official end date, so if you are looking to upgrade your voicemail server, Unity Connection is the way to go.  The breeze with which this product installs in comparison to it’s predecessor will make you want to kiss your mother-in-law and hug your neighbor’s yappy little dog.

Step one in the Unity Connection research process is to determine your hardware compatibility. In this case, you get to play the find-your-server-model on the Big Long List ‘o Compatibility for the version you want to go to – in this case I pulled up the compatibility list for 8.x of Unity Connection: http://www.cisco.com/en/US/docs/voice_ip_comm/connection/8x/supported_platforms/8xcucspl.html

In our current example, you can see that this model of server is supported for versions of Unity Connection 8.x.   Yay, you! Specifically, it’s supported for Platform Overlay 1 which requires 4 gig of RAM and 2 250 gig drives.

We will want to confirm that our proposed Unity Connection version is compatible with both our current version of CUCM and our proposed upgrade version of CUCM – this typically isn’t an issue since Unity Connection plays very nicely with almost all versions of CUCM, but definitely a check you want to make: http://www.cisco.com/en/US/docs/voice_ip_comm/connection/compatibility/matrix/cucsccpmtx.html

In the case of Unity Connection upgrades, you are going to want to look closely at the DiRT tool and the COBRAs tool to make the transition from the old to the new – there are excellent tutorials/instructions/information on this web page: http://ciscounitytools.com/

Moving on, let’s tackle the process of determining the upgrade path for CUCM:

Step one is once again to determine your hardware compatibility.  Find your model of server on this chart clearly constructed by evil forces seeking to wreak havoc on the universe: http://www.cisco.com/en/US/prod/collateral/voicesw/ps6790/ps5748/ps378/prod_brochure0900aecd8062a4f9.html

Note that if you actually want to see your server model AND the headers at the same time, you are just out of luck unless you have a really, really large monitor or can read really, really tiny font. I’ve been known to take a screen shot of the header row and a screen shot of my server model row and line the two up. The entire time chanting curses upon the chart creators.*

As you can see, our example server does support CUCM 8.6 but there is both an X and a (2).  If you look at the sub notations on this already freaking fabulous chart (note sarcasm font), you will see indicators that while this server is supported, there are certain memory and hard drive upgrade considerations.

In this case, our sample server meets the hard drive specs (160 GB drives), but is going to need an extra two gig of RAM to make the leap into hyperspace. One note here, be sure to watch out for servers that are supported only for bridged upgrades – this means you can take the server up to the latest version, but the only thing it’ll be good for is to take a backup that can be restored onto a supported server. That, and I’m sure it makes a really useful, if somewhat noisy, door stop.

Once you’ve confirmed hardware compatibility of your CUCM servers, you will need to check your upgrade path.  Even though ideally you would like to go directly to the latest and greatest CUCM version, unfortunately you may run across a you-can’t-get-there-from-here scenario – especially if you are looking at upgrading from versions of 6.x.  In our sample case we are looking to go from 7.1.3.20000-2 to 8.6.2.  Time to pull out the magic eight ball.  Nah, actually, just use this document:  http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/compat/ccmcompmatr.html#wp373165

Note that you will likely need to know what your full version number translates to in SU-speak, in this case 7.1.3.20000-2 is actually 7.1(3a).  What you are looking for is your release in SU-speak under the Direct Upgrade column of the release you want to go to. If it’s not there, you are going to get to do a step upgrade – intermediate upgrades FTW! (sarcasm font again)

Be sure if you find yourself in this situation to pick a stable intermediate version.

The last piece of our CUCM cluster upgrade is UCCX (formerly IPCC):
Step one is, of course, to check the hardware compatibility, and there’s a doc for that: http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/crs/express_compatibility/matrix/crscomtx.pdf

This document may make your head spin a little, but first look for the version of UCCX you want to go with, in our case 8.5(1). Then check and see of your server makes the cut.

In our example case, we do make the cut – our version of UCCX 7.0(1)SR05_Build504 is even listed under supported upgrade paths- BUT looking at the document closely, UCCX 8.5(1) isn’t supported with our current CUCM 7.1.  Welcome back step upgrade.  You will need to keep your UCCX and CUCM versions compatible, so upgrading to UCCX to 8.02 then upgrading CUCM to 8.6, then upgrading UCCX to 8.5(1) will do the trick. And lead to excessive drinking.

Note, however, that our example CUCM version is not explicitly listed in the chart- only 7.1(3) and 7.1(3b) – so if it were me, I would confirm with Cisco support that 7.1(3a) indeed did support UCCX 8.02. Make no assumptions when it comes to the documentation- ever.

After you’ve survived all of this, I’d say your about 1/2 way through the research process.  Among other things, you will still need to review the release notes for each application, check for COP file requirements, check the prerequisites for each proposed version, and confirm phone firmware compatibility. You will also need to check third party application support for all your extra voice applications**, determine the order in which the upgrades need to happen, and review detail over again***.  You’ll also need to determine down times and back out options should upgrades not go as planned. Of course upgrades always go as planned, right? (sarcasm font at it’s finest)

This will get you started on your hardware check, help determine if you need to invest in new servers, and give you an idea of what version you should be targeting and what it’s going to take to get your hardware there.

*To say I hate this chart with the passion of a thousand suns is a woefully pathetic understatement. If it burned in the fires of Hades for all eternity, that wouldn’t be long enough.
**Be sure not to forget to check the compatibility for your Presence servers, your CER servers, your recording servers, your paging servers, your fax servers, your voice gateways, your legacy PBX, and anything else that integrates with CUCM
***Note that in some cases you may actually lose some functionality your users are dependent on, specifically I would mention the loss of built in Attendant Console when making the jump to CUCM 8 and above. Double check everything for gotchas and caveats, it’ll save your arse and your upgrade.

The sting of rejection: Part 1


Ever have one of *those* days where you just aren’t on your game?  Usually we try to keep those days to ourselves and hope no one is noticing, but I’ll share a couple of pieces of one of my brain dead days in hopes that someone gets a good chuckle, that someone learns something, and that *I* never, ever, make this particular mistake again.

So there were two tasks remaining to complete my voice gateway setup: configure local conferencing and configure a single MGCP port on the router – in this case on a 2800 series.  Let me just preface this by saying this same setup had been done for approximately 20 other sites.  Imagine my surprise when neither the conference bridge nor the MGCP port registered. This blog entry will focus on the conferencing issue and mayhem that ensues when you just can’t see what it is you’ve done wrong.

There are a number of steps to creating a conference bridge on an IOS voice gateway.  The router configuration is going to look something like this:

dspfarm
dsp services dspfarm
sccp local GigabitEthernet0/0.1
sccp ccm 192.168.1.11 identifier 1 priority 1 version 6.0
sccp ccm 192.168.1.10 identifier 2 priority 2 version 6.0
sccp
sccp ccm group 1
bind interface GigabitEthernet0/0.1
associate ccm 1 priority 1
associate ccm 2 priority 2
associate profile 1 register my-Conf
dspfarm profile 1 conference
codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
codec g729r8
codec g729br8
maximum sessions 3
associate application SCCP

Once you’ve done this, you just need to add the conference bridge in Call Manager and it’ll register.  In theory. And in practice – if you do it right.  But I hadn’t.  My bridge was a bridge to nowhere – status Rejected. <cue sad violin music>

If you find yourself in a similar situation, there are several things you should check right out of the gate. Or should that be gateway?  But I digress.

Is sccp running on the router?

Enter no sccp, then sccp to confirm.

Is the dspfarm profile active?

Enter dspfarm profile 1 conference, then do a no shut.

Is the name of the conference resource correct on the router and in CUCM? In our example above it’s my-Conf, that *exact* name should be entered in CUCM. No wiggle room in this one – copy and paste it from the router to be sure.

And here’s the kicker.  At least what kicked me a few times over:

Is the conference bridge type you selected correct?

When I added the bridge to CUCM, I selected Cisco IOS Conference Bridge.  Sounds like a good choice, right? Uh, no.

What you really want is Cisco IOS Enhanced Conference Bridge. Which is what had been picked the other 20 times this had been done.  But for whatever reason, I picked the former, and let me tell you, the system does not provide a handy error message that says “hey bozo, you picked the wrong bridge type.”  Although, I am sure that will make it into the latest release.

Here’s what you will likely see as options in the drop down, go ahead and make the enhanced selection, you deserve it:

If, however, you choose poorly error either due to oversight or just not knowing any better, you will a status of Rejected for the bridge. In the RTMT Application Log for the CUCM server, you will likely see this error message over and over again:

: 37326: Feb 08 06:02:00.522 UTC : %CCM_CALLMANAGER-CALLMANAGER-3-DeviceTransientConnection: Transient connection attempt. Connecting Port:0 Device name [Optional].:my-CONF Device IP address.:192.168.1.11 Protocol.:SCCP Device type. [Optional]:52 Reason Code [Optional].:3 Cluster ID:StandAloneCluster Node ID:MYCMPUB

And if you are industrious enough you can track that reason code down, but it doesn’t necessarily shine much light on the situation:

So just add “Confirm the correct conference bridge type, you ninny” to your checklist when configuring a conference bridge on an IOS router.

And try very hard not to overlook this mistake the 90 times you check your configuration afterward.  It’ll save you a few hours of head scratching and an embarrassing call to TAC.

*In order for your devices to use the fabulous conference bridge you’ve just setup, be sure to assign it to the appropriate Media Resource Group and Media Resource List. Also, be certain you have assigned the MRGL to the devices or device pools that will need it.

Publish date: 02/09/2012

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

It’s not me it’s you…

One of the niftiest features Call Manager offers is Single Number Reach (SNR). Configuring SNR takes a wee bit of work, but once it’s setup you’ll never love your life more. Why? Because SNR ends the tradition of giving out a work number *and* a cell phone number just so customers, end users, and sales piranas can abuse you all hours of the day. With SNR, you can send your work calls to your cell phone on your terms, which pretty much rocks my socks.

Recently I was troubleshooting this feature of awesomeness trying to determine why a user’s mobile phone wasn’t ringing when the work number was called. Few obvious things to look for when troubleshooting this:

  • Make sure there’s a Remote Destination Profile AND a Remote Destination configured – I know they sound like the same thing, but they are not and you’ll need both
  • Make sure the Calling Search Space on the Remote Destination Profile permits a call to the cell phone- meaning if it’s a long distance call to the cell make sure your chosen CSS allows long distance
  • Make sure that the user is associated with his/her Remote Destination Profile
  • Last but not least, tweak the timer settings- Answer Too Soon, Answer Too Late, Delay Before Ringing, and Just Hang Up the Damn Call Now are timers that are all extremely helpful when customizing this feature for Mr or Mrs Picky Pants. (Yes, I made up that last one, but it sounds like an option that should be there)

So, what if you’ve got it all configured correctly and the user’s mobile phone still doesn’t ring? Time for a sanity check – if you’re me, you put your own cell phone number in the Remote Destination and give it a whirl.  Now this may sound less like sanity and more like madness, but it means you’ve injected a known working quantity into the equation.  If there’s one thing I know my cell phone does, it’s ring. All. the. time.

But back to the story. Given the new parameter, SNR works like a charm.  So why did SNR like my phone so much better than the user’s? Mine does have a pretty cool case, I’ll give you that. However, doubting that this was the magic factor, I did some research and dug up some interesting information. I found that her model of phone had a TON of complaints posted online.  The complaints: that model – an EVO on the Sprint network- apparently has a nasty habit of not ringing when people call.  Fortunately, there were lots of suggestions on how to resolve this particular issue and my customer’s phone now rings all the time. Especially since I forwarded my work number there.

The moral of the story – voice is a murky, complex world in which we engineers often find ourselves trying to manipulate devices that lay just outside of our influence or control. Whether it’s an ancient fax machine located half way across the country with ECM turned on, a cell phone running a buggy version of code and a bad PRL list, or perhaps even another vendor’s video endpoint that refuses to make nice with the expensive equipment on your end of the conversation- we’ve got to hone our skills to narrow down the issue and face the fact that sometimes the fix will be out of our hands.

In case you’ve got an EVO phone with a ringing disorder, check out this forum: http://forums.androidcentral.com/htc-evo-4g/41825-does-your-evo-rings-4-times-before-you-hear-fix-your-slot-index-cycle.html

And if you need to configure SNR from scratch, I’d recommend starting here: http://tek-tips.com/viewthread.cfm?qid=1575474

And an official Cisco doc, complete with judgmental dude looking down at you while you read, can be found here: http://www.cisco.com/en/US/docs/voice_ip_comm/hucs/7.1a/provision/CH13_HUCS.pdf