Troubleshooting External VoIP Calls on Cisco UCM

One day management decided that because the voice servers run on the network, and because you're a network engineer, you must be able to make all things phone-related work. You find yourself lost in a sea of voice jargon as phrases such as "route groups," "codecs" and "calling search spaces" swim by. Here's a lifeline to keep you from drowning.

I'll take a commonly reported issue: Sally in finance can't dial 555-555-5555. She absolutely must be able to dial this number from her work phone, and it's simply unacceptable that this one phone number in the entire North American Numbering Plan (NANP) is not working properly. The ticket severity is, of course, marked at the highest possible level, just in case you missed the gravity of the situation.

You must gather one very important piece of information at the beginning of your investigation: Can you call this number from outside your phone system? You might be surprised at just how often an enterprise phone system is blamed for a non-working number that has actually been disconnected from the PSTN entirely. (Unless you've dealt with voice users before, in which case nothing should surprise you.)

Once you confirm there is an actual working number, you should address problem in this manner:

1. Dialed Number Analyzer (DNA)

2. Test route group/route list/route pattern

3. Debugs on the gateway

For those not familiar with the DNA tool available with Cisco Unified Communications Manager (CUCM), DNA can be found by going to Cisco Unified Serviceability -> Tools -> Dialed Number Analyzer.

Once here, select Phones under the Analysis menu and choose the phone having the problem. Select the proper line, and in the Dialed Digits field enter the digits just as the user would dial them. Finally, click Do Analysis.

Dialed Number Analyzer

The results will look something like this. Click the Expand All button:

DNA Analysis Output

Once expanded, you will see some important details: the device Calling Search Space of the phone, the route pattern/partition the call is matching and the gateway the call is supposed to be routed to.

From here you have a few options, but my preference is to put in place a structure to make the next round of troubleshooting go faster. I like to go over to the Call Routing menu in CUCM and put the following in place: a Test Route Group, a Test Route List and a Test Route Pattern.

Inside my Test Route Group, I put the gateway the call should be routed to, in this case the gateway the DNA output showed me. Next time, though, I'll remove this gateway and add whatever other gateway the next DNA analysis shows.

The Test Route List that I create, for the most part, stays the same, always containing my Test Route Group. I do, however, have to remember to check the digit stripping on the gateway Route List based on whether I'm dealing with an h.323, MGCP or SIP gateway.

The Test Route Pattern I create always points to the Test Route List, but changes based on the number reported by the user. In this case, it would be a pattern for 9.5555555555, but the route pattern entry would be modified to whatever number is in question at the time.

The beauty of this structure is that now you have call routing that you can be certain of for the number in question. You can also make changes without affecting all production call routing. Finally, the structure can be adapted to whatever external phone number is at issue.

For debugs for the gateway, I go with debug isdn q931, debug voice ccapi inout, or debug ccsip messages, depending on the type of circuit. In each case, you are looking for a properly formatted called number being sent to the telco. Check that the trunk access code has been stripped and the number contains all the digits it needs to be routed across the PSTN.

If you see a properly formatted number in your debug output, you can be reasonably certain it's time to play blame the carrier, a rather exhausting but rewarding game that voice engineers get to play.

As an example, examine this recent debug in which users couldn't call a certain external number. In the debug, you can see the disconnect cause code Cause i = 0x80E6, and if I hadn't masked part of the number, you would also see that the number was properly formatted for the PSTN, pointing to a carrier issue.

Debug Output

On a final note, if you ran one of the above debugs and experienced the misfortune of not seeing your call go out to the PSTN, do not despair. Try running debug voip dialpeer all. You will see what dial peer is, or isn't, being matched, as well as what digits are being presented to the gateway. Likely you will identify the need to adjust the stripping/prefixing either in CUCM or on the gateway itself.

That's definitely material for another post, but at least now you know where to start looking. Your honorary voice badge is in the mail; if you're lucky, it comes with a nice bottle of Scotch.

Amy Arnold, CCNP/DP/Voice, currently works as an engineer in the public sector with a focus on all things networking. You can follow her on Twitter at @amyengineer.