Manager comes in and asks me if I have any tasks the shiny new intern can observe, my response: I’m about to troubleshoot a Call Forward All issue- if the intern doesn’t have anything more interesting, he’s welcome to watch. And to my complete dismay, he really doesn’t have anything more interesting and I have an audience.
First step: gather the facts. Call the user’s extension, the phone rings- super. Set the call forward all- super. Call the user’s extension- get busy signal. Not so super. Okay, Houston, we’ve verified there is a problem.
Second step: check the obvious. In this case, checking the CSS of the Call Forward All of the Directory Number is the place to start. If no CSS or the wrong CSS is set, the call that’s supposed to be forwarded to Timbuktu isn’t going to get there no matter how much you will it to do so. So I verify the CSS is correct, and I give a lengthy explanation of CSSs to the intern who, once again to my dismay, has not fallen asleep yet.
Third step: isolate the issue- This is also known as the simplify-the-issue stage or eliminate-all-the-factors-you-can stage. In this situation, I whittle down the problem to it’s most basic parts- taking the directory number, which was a shared line, isolating it to a known good test phone. Also, I confirm the number I’m forwarding to is an internal, reachable, working number. I repeat the tests. And for the love of Pete, it still doesn’t work.
Soooo, thinking I’d like the intern to think I’m smarter than a potato, I blow through the rest of my bag of tricks, including using the Dialed Number Analyzer to confirm my call is taking the expected path. I also proceed to rule out any PBX conflicts. As a side note, if you have customers that run a Cisco voice system integrated with a legacy PBX, it is perfectly acceptable to blame the PBX for all issues. They are like telco carriers, it’s the right thing to do.
While I still have what is left of your attention, let’s move along. At this point, I hang my head in shame, admit defeat, and do what all good mentors do – show the intern how to collect logs and open a TAC case.
And TAC’s findings on the source of my malcontent? Bug ID CSCse19548. Which, for those who would rather I google that for them, the essence is there’s a counter that is supposed to prevent looping calls and it has been triggered. This counter tells the Directory Number “you are a loop!! no call forward for you!!” (call forward Nazi…)
The fix: reset the counter. You can do this two ways: the take-a-hammer-to-it approach and stop/start the CCM Service, temporarily taking down call processing on your CUCM server, OR the slightly milder approach, you can reset the max forwards counter using the phone itself:
-Go off hook on a phone that is registered to CCM that has the high counter, make sure the CallFwdAll is set
-enter “**##*30 (enables codes)
-Go off hook again
-enter “**##*35 (clears the max hop counters)
By the way, if you are wondering what this issue looks like in the log files, you are looking for something like this:
06/17/2011 11:25:21.637 CCM|Forwarding – processCFA – ERROR –
Forward loop detected. — Clear the call with USER_BUSY. callKey=
Final thoughts:
The last thing I will mention I learned from this situation is that users rarely tell you all of the story. If you’ve ever seen House and heard his rant on “all patients lie” it’s similar in concept. In this case, I later found that the directory number in question was once part of a group of two directory numbers in which two very nice, very old ladies, kept call forwarding their phones to each other. You guessed it, creating a call forwarding loop! Just shortly before this CallFwdAll issue had been discovered, the hooligans had been assigned a single directory number to share which put a stop to their shenanigans. Reminding me to always, always, ask questions. And lots of them.
Amy Engineer 
What version of CUCM were you using?
7.x – I can check next week and let you know the exact release
I know absolutely nothing of voice networking, but these are great posts – keep it up!
I’m surprised how many people I run into who *suck* at what you’ve labeled “third step” – they try things in an ever-*widening* radius of the problem, rather than establishing facts and narrowing the scope of the problem.
So true! I’ve seen it too! It amazes me that instead of simplifying they do the opposite – scary really!
CCNP-Voice in your future?
I got the CCNP Voice about a yr ago when playing catch up switching from R/S to voice (job change to a Cisco Partner). The CIPT2 test nearly killed me…
Oh, there is a long list of trouble reports that are worthy of additional followup questions:
– “phone doesn’t work” (have you threatened to fire it?, is it a union phone?, is it still a teenage phone?)”
– “cannot call number” (have you recently broken your fingers?, do you find the buttons to be too small to press and often hit more than one key at a time?, are you currently being held captive with your wrists taped behind your back?)
Welcome to the blogging community, enjoyed the read!
Hahahah! Love the follow up questions!!! Thanks for the positive feedback – I adore your blog so it means a lot!! 🙂
I just found your blog and have been reading post after post of your experiences and loving every one of them! I’m a voice technician with an Avaya/Nortel system and even though it’s different from Cisco, we have the exact same scenarios and situations with users not giving all the details. Also – loved the reference to Seinfeld in this one!
Hi, how do I find out which phone has the highest counter? Also, am I suppose to hear something different to know the codes are enabled when I dial **##*30?
I don’t recall hearing any tones when I went through this process, I remembering wondering if anything was happening at all – but the process worked, so that verified the process for me. I don’t recall if you could tell which phone had the highest counters – I believe the logs may have shown the counter value but I am not for sure.