There comes a time in every Voice Engineer’s life where you will need to take debugs on the gateway.
You can choose how you want to analyse your logs, do you want to view them in real time? do you want to log the session output to a file? Do you want to send them to the buffer or a syslog server?
This short guide will leave that option to you, but will focus on viewing the output in real time or saving the session output to a file and viewing it after.
There are 2 types of Gateway you will likely be troubleshooting on depending on what protocols you are using in your environment.
Let’s take a look at both and get started.
Before we start any debugs check CPU usage on the Gateways. This is because while most of the debugs wont impact CPU usage too much, if the CPU is already too high on the Gateways, it could tip it over the edge and send your Gateways to bite the dust.
show process cpu history
It is also a good idea to check if there are any other existing debugs on your Gateways. We can do this with the simple command:
If there are, we know that it isn’t a good idea to blanket turn off all debugging at the end of our session.
Lastly, since we assumed that we would be viewing the output in real time (or sending the output to a log file) we will need to make sure that we can see the debug information on the screen.
The above command will ensure that all output will be displayed on the terminal connection.
The below debugs show output for a Layer 3 and Layer 2 level respectively.
debug isdn q931
debug isdn q921
We can use the following debug to show all SIP messages going through the Gateway.
debug ccsip messages
It is important to bare in mind that this can get very CPU intensive, so only run it in production hours if you absolutely have to, and if its for a very short amount of time. Otherwise, do this outside of normal hours.
Protocol Independent Debug
In the case that you need more information, you can use the below debug to display more information.
debug ccapi voice inout
What is great about this is that you can combine it with either of the debugs above. It isn’t too CPU intensive on its own, and can be run on either a SIP or ISDN setup.
Ending the Debugs
We could end the debugging by using the command:
However as we noted earlier, there might be other debugs running. So in any case we should disable our debugs individually using the below command structure:
undebug [name of initial debug here]
Lastly, to stop the terminal output from being flooded with data, we need to turn showing live output off.
This is done with the below command:
terminal no monitor
You will notice that this is not the expected “no terminal monitor” command as you might have expected, but hey – what would VOIP be without the occasional nonsensical CLI command?