Amy Arnold

Network Computing Blogger

Upcoming Events

Where the Cloud Touches Down: Simplifying Data Center Infrastructure Management

Thursday, July 25, 2013
10:00 AM PT/1:00 PM ET

In most data centers, DCIM rests on a shaky foundation of manual record keeping and scattered documentation. OpManager replaces data center documentation with a single repository for data, QRCodes for asset tracking, accurate 3D mapping of asset locations, and a configuration management database (CMDB). In this webcast, sponsored by ManageEngine, you will see how a real-world datacenter mapping stored in racktables gets imported into OpManager, which then provides a 3D visualization of where assets actually are. You'll also see how the QR Code generator helps you make the link between real assets and the monitoring world, and how the layered CMDB provides a single point of view for all your configuration data.

Register Now!

A Network Computing Webinar:
SDN First Steps

Thursday, August 8, 2013
11:00 AM PT / 2:00 PM ET

This webinar will help attendees understand the overall concept of SDN and its benefits, describe the different conceptual approaches to SDN, and examine the various technologies, both proprietary and open source, that are emerging. It will also help users decide whether SDN makes sense in their environment, and outline the first steps IT can take for testing SDN technologies.

Register Now!

More Events »

Subscribe to Newsletter

  • Keep up with all of the latest news and analysis on the fast-moving IT industry with Network Computing newsletters.
Sign Up

See more from this blogger

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.

More Insights


More >>

White Papers

More >>


More >>

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.

Related Reading

Network Computing encourages readers to engage in spirited, healthy debate, including taking us to task. However, Network Computing moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. Network Computing further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | Please read our commenting policy.
Vendor Comparisons
Network Computing’s Vendor Comparisons provide extensive details on products and services, including downloadable feature matrices. Our categories include:

Research and Reports

Network Computing: April 2013

TechWeb Careers