When you’re configuring a SIP trunk to an SBC, there are a couple of network setup steps that you’ll need to implement to prevent pain and suffering down the road. That pain and suffering might be “just doesn’t work” or it could be “intermittent interruptions”.

If your SBC is behind a firewall, you’ll need to ensure that firewall isn’t killing things that it shouldn’t. This means turning off “deep packet inspection”, “SIP Session Helpers”, and “Application Layer Gateways”. The last two are really meant for SIP phones outside the firewall accessing a PBX inside the firewall. They can (and do) work well for that. Deep packet inspection has two main challenges. First, every major firewall that I’ve met is too dumb to understand SIP, and it breaks things. Second, it adds latency to real-time communications. That may not be an issue if everything else in the network path is adding minimal latency, but it can add enough to be a problem.

The solution here is to disable this functionality, and to use the IP addresses and ports associated with the SBC and SIP trunk provider to allow or deny traffic. (You should be doing this anyway – don’t depend on your cool, smart firewall when you can just outright block a ton of potential issues by IP address allow/deny).

If you are a security person and you’re freaking out over this outlandish proposal and insisting that you be able to deep scan everything, take a minute here to consider this: The SBC is a better SIP security device that your firewall will ever be. SIP security is part of its job! The carrier you are connecting to is very interested in the security of their end of that connection, as the most likely security issue is a bad actor making use of their SIP services for free.

Next, let’s talk NAT. Your firewall is likely translating your internal address space (10.10.10.27 for example) to a public IP assigned by your ISP (203.0.113.12 for example). This changes the “outside” of the IP packets, but doesn’t touch anything inside the packets. That’s fine for most things, but it can really break SIP.

The inside of a SIP packet has IP address information contained in it, too – that 10.10.10.27 is there. However, the SIP provider you’re passing this packet along to can’t access that, it is an internal IP range on your network (and since I used a popular range in this example, likely on many other networks too). The IP address inside the packet must also be translated to 203.0.113.12.

This is what firewalls are terrible at. They don’t speak SIP, they don’t know how to do this. SIP Session Helpers and Application Layer Gateways can take care of this for Internet endpoints accessing an internal PBX, but fail miserably on SIP trunks.

Good news, however. Your SBC has the capability to deal with this problem. There’s a field in the NAT configuration of your SBC for you to input the public IP (203.0.113.12) that your firewall will translate its traffic into. The SBC will send packets with the 10.10.10.27 replaced with 203.0.113.12 inside the packet. It leaves the 10.10.10.27 in place on the outside, however, as this is needed for the internal network path from your SBC to your firewall, which then translates this part.