Diagnosing SIP Issues - Hints & Tips

A SonicWall user recently came to us for help; the user felt the problem was within SIP and UDP. Here are some thoughts and ideas we provided to help him with his SIP diagnosis.

SIP is a somewhat troublesome protocol. The basic SIP transactions flow with a well known UDP port number. That makes it relatively easy for a firewall to allow (or disallow) the SIP protocol itself.

However, SIP is basically a call setup protocol; SIP itself does not carry the voice. Part of the SIP setup is to designate the UDP ports that will be used for the data/voice transfer.

Unless a firewall tracks that aspect of SIP the firewall will not have any way of knowing what temporary UDP ports to allow so that the data/voice can proceed.

(There is a similar issue at the end of the call in which the firewall needs to know when it is OK to start blocking the temporary UDP ports used for the now-completed conversation.)

Things can get more complicated when your firewall/router is also doing NAT (Network Address Translation). The UDP port numbers, particularly the temporary ones used to do the actual data/voice carriage, are often different inside your network (e.g. "behind your firewall/NAT" than outside on the open internet.) SIP often has to use various approaches to penetrate NATs, things with names like "STUN", in order to figure out the mapping between "inside" and "outside" UDP port numbers.

(To make all of this even more "fun" if the other end of the call, or more likely the SIP exchange, is behind a NAT then this kind of port mapping game also happens at the other end. You can understand why this sort of thing can drive people to distraction and why many network experts look upon NAT with great disdain.)

By-the-way, these same issues can exist whether you are using IPv4 or IPv6. However, with IPv6 there is usually no NAT to make life difficult. It is possible that your call setup (the SIP phase) is happening using IPv4 or IPv6 and the data is being attempted via the other flavor of IP. Hopefully that is not happening as it can be hard to diagnose without resorting looking at actual packet captures both within and without your firewall.

We do not know Sonicwall software; we do not use it ourselves (we use pfSense).

However, a quick Google search for Sonicwall and SIP does indicate that there are a lot of items about SIP issues and configuration.

I don't know what SIP exchange provider you are using (if any). They may be able to offer some assistance as well.

If you really want to get down into the tech end you could fire up a local "Asterisk" SIP engine that exists completely within your firewall/NAT world. There are, I believe, downloadable images that you can put onto a USB or DVD that you boot on a spare PC. But Asterisk is a complicated thing and it may be more distracting than helpful.

By-the-way, a lot of SIP phones/implementations can interoperate directly without an intervening SIP exchange (such as Asterisk). You might want to try setting up a second SIP phone inside your network either on another computer (or even on the same computer).

We would like to help, but firewall/NATs in general and SonicWall in particular are not part of our expertise. We are in the business of building/selling tools to help folks who implement network code to check whether their stuff works well under bad conditions.

In fact, we offer a SIP Test Suite.