Troubleshooting Cisco IOS voice gateways present challenges that I enjoy solving, but if you’re a network engineer who doesn’t do voice engineering every day, it’s easy to feel lost in unfamiliar commands and loquacious debug outputs.
In this post, I'll share some common voice gateway commands that have helped me hone in on particular problems quickly and eased the troubleshooting process. Armed with these commands and a basic understanding of how VoIP systems work, you’ll be ready to jump in and start troubleshooting the next voice gateway issue.
1. show dialplan number. This command is a great way to determine what dial peers your calls are going to hit when the gateway sees them; sometimes the output will be a lot different from what you were expecting. You also can see quite a bit of additional detail about the dial peer being matched, including any inbound and outbound translation profiles being applied that you might not have factored into your troubleshooting process.
2. test voice translation-rule. Whether you’re new to translation rules or they are old hat to you, it’s nice to be able to test rule sets to confirm their expected behavior. This command allows you to input your call digits and see how the system thinks they match the translation patterns configured. This is an especially handy tool if you are troubleshooting complex rule sets manipulating inbound or outbound digits to a carrier.
3. show call active voice compact. This command is perfect for determining how many active calls a voice gateway currently has going through it. I often use this command to figure out if I can reset a voice gateway without anyone noticing a dropped call after I complete a configuration that requires a reset.
4. debug isdn q931. An old favorite and easily one of the cleanest debugs to read, this command provides obvious information like calling/called numbers and channel ID. I have also found this output to be invaluable in troubleshooting a carrier’s ISDN switch pre-pending or discarding digits based on the plan type of ISDN call. Usually the carrier is unaware that their ISDN switches are doing this, but with this debug, you are able to unravel the mystery and find a resolution.
5. debug ccsip messages. If you have SIP trunks in your environment, this debug is golden. In addition to easy-to-interpret error codes like ‘SIP/2.0 400 Bad Request -- 'Invalid IP Address,' other useful information like RTP ports, media types, and codecs used can be seen in the resulting output.
6. debug voip dialpeer all. Determining if a failing voice call actually makes it to the voice gateway at all is an important first step that engineers often overlook. If you turn on this debug, make your test call, and see no output, there’s a good chance your call died in transit and the gateway never saw it. When you do see output, you’ll see handy information like inbound and outbound dial peer matches, often highlighting the root cause of your call routing issue.
7. show voice port summary. I have used this command most often when dealing with analog devices -- specifically analog devices that no one knows which ports they're plugged into. Taking the device off hook, running this command, and seeing which port changes status can save you some serious cable tracing time.
8. show ccm-manager. If you have an MCGP gateway that won’t register, this command is your best friend. There’s a good chance you do not have the fully qualified domain name of the gateway listed correctly in your CUCM configuration, and this output will show you exactly what that needs to be. This command is also useful for confirming primary and backup CUCM registration IPs.
9. debug voice ccapi inout. This is the catch-all command of voice call debugs. It’s overly chatty, seemingly difficult to parse, and looks quite a bit like the router verbally spit up on the screen. I mention it, however, because if none of the above commands are showing you what you need to see, there is a good chance this one will. This output includes dial peer matches, signaling details, and disconnect cause codes, among other useful details. Cisco docs and Cisco TAC come in handy in interpreting the verbose output and can help you make sense of the overwhelming output.
While the above commands are just a sample of the tools available on voice gateways for troubleshooting, they are a good start for common voice issues. Hopefully, they will give you an edge the next time you’re facing troublesome voice gateway issues.