Debugging a SIP/ISDN Gateway

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.

Pre-Checks

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.

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.

ISDN

The below debugs show output for a Layer 3 and Layer 2 level respectively.

SIP

We can use the following debug to show all SIP messages going through the Gateway.

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.

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:

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:

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?

Done!

Leave a Comment