NCA and NAT

Owned by Nathaniel Halbrooks
Last updated: Mar 15, 2024 by Kelli Higdon
8 min read

 

Overview

A limitations of NCA (version 2.0.4) is that it will not be able to establish two way communication if located directly behind a NAT. 

The two solutions to get around this limitation are:

  • replace a traditional NAT/Firewall with an SBC, 

  • introduce a B2BUA between NCA and the NAT.  

This page will go through an example to describe why this happens, and how each of the above solutions addresses the main issue, and is meant to be a supplementary resource to the NCA User Guide.
 

For the purposes of this document, we are going to reference the following Network Diagram :

 


Diagram 1: Unsupported Firewall scenario


Main Issue with Firewall & NCA - SDP

A SIP message contains two different parts, the Headers which are responsible for the signalling and call controll, and the SDP (Body) which is responsible for negotiating how the actual media (RTP) will flow between the two endpoints.  Because RTP is most often transmitted in UDP and not TCP, there are no errors thrown when a SIP device is told to send the RTP to a destination that does not exist.  This most often occurs because you explicitly tell the UA (user agent) that you are communicating with to send its RTP to a location it cannot reach.  The rest of this section will outline what would happen if NCA were setup on the network above.
 

Setting Up The Call

Below is a diagram that details the SIP signalling that is sent and received by NCA when attempting to connect the Dialer to the SIP Trunk of the Network diagram above .  (The general case is outlined on page 106 of the NCA User Guide).

In this diagram, I have highlighted exactly what information NCA receives from each endpoint during initial communications, and how we re-transmit that data in order to have the Dialer and the SIP Provider send audio directly between each other.

It is important to note that the firewall (of the Network diagram) is not a SIP UA, and as such it is not present in the SIP Diagram below.  The diagram only represents SIP messages (OSI Layer 7), not TCP/IP (OSI Layer 3/4) messages.

The orange "RTP" arrows illustrate how NCA is expected to operate under a correct environment, but are absent due to the SDP issues (with reference to the first network diagram)
 

Diagram 2: Unsupported Firewall scenario

 

Analyzing the SDP

If you are familiar with some basic networking as well as basic SIP, then you will have noticed that the issue of the above call setup is due to the Local IP address that was used in the SDP when communicating with the SIP Trunk.  Both the Dialer and NCA will be able to send packets to the intended destination by routing their packets to 75.56.116.75 through the firewall, however the SIP Provider has no way of sending audio to the proper destination when it is explicitly told to send the audio somewhere locally, and not out over the public network.
 

 

Diagram 3: Unsupported Firewall scenario



Fixing the SDP

From a signalling point of view, in order to get two way communications to happen, we must ensure two things:

  1. The SDP we send to the SIP Provider uses the Public IP Address of the Firewall - 70.52.96.118

  2. The SIP Provider can send RTP to both NCA and the Dialer

Each of the initially mentioned solutions for deploying NCA behind a NAT address both these issues, and each will be discussed at length in the next sections.
 

Limitations of NCA

NCA is unable to specify an IP in the SDP that is different from the IP assigned to the interface it is listening for SIP/RTP on.

Because of this, even if you were a networking expert, NCA will never be able to work directly behind a NAT.
 

Limitations of Firewalls

While it is technically possible to configure a Firewall with a range of RTP ports for each SIP device configured to forward packets to the appropriate destination, and each device on the network specifically configured to use a unique set of ports for RTP, this is generally not implemented due to extreme amounts of overhead when trying to setup or modify the network.

If you do not use a unique configuration for every device on the network, you cannot do typical NAT (PAT = port-address-translation), and you will not be able to send audio to the proper device.
 

Solution 1: Integrating an SBC

A Session Border Controller (SBC) is an ideal way of allowing SIP devices inside and outside of a private network to communicate easily and securely with each other.

An SBC is a device that sits on the edge of your private network much like a traditional firewall does, but is able to perform deep packet manipulation on all inbound and outbound SIP messages, and perform NAT-style manipulation on all information necessary to enable two way communications.

Here is a simple example of replacing a Firewall with an SBC.  While in reality SBC's rarely replace a firewall in a network, this setup is technically possible and is used to simplify the network for demonstration purposes.


Diagram 4: Solution 1 using SBC



Call Flow

As you can see in the diagram below, the SBC modifies the SDP in the SIP messages that need to go from the internal network to the public network so that each device is specifically told to send the media to the correct destination.

Notice that unlike the previous scenario with the Firewall, the SBC is present in this call flow diagram because it understands SIP and processes SIP messages.  Not only that, but the SBC is a Back-to-Back-User-Agent (B2BUA) and there are actually four UA's involved.

Diagram 5: Solution 1 using SBC




Analyzing the SDP

As you can see, because the SIP messages on either side of the SBC have been modified, each UA is specifying an IP that is reachable by the other side, so there will be communications as expected on this call.

Benefits of adding an SBC

  • An SBC is not only used to traverse NAT's, and usually adds security features to the network

  • Relatively easy to integrate into the network

  • Scalable solution for complex SIP networks

Solution 2: Adding a B2BUA (Asterisk)

Adding another B2BUA to your network is another way of allowing NCA to communicate through a NAT.  While NCA is limited by its inability to modify the SDP of outbound SIP packets, IP PBX's like Asterisk and FreeSWITCH both have this ability and can be inserted into the network to resolve this issue.

Unlike with the SBC in the previous scenario, the B2BUA we insert does not replace the firewall.  Instead it sits directly behind the firewall and is the only UA that communicates through the NAT.  Typically an SBC is deployed like this and is combined with a traditional firewall for complete security on the network.


Call Flow

The call flow from a SIP point of view is almost identical to that of the previous example, but it is important to note that to get the SIP message from the Dialer to the Provider, we now have 4 UA's AND the Firewall that handle the packets in order for communications to happen.

Analyzing the SDP

As you can see this call flow diagram is extremely similar to the previous example.  The most important difference is that 192.168.0.4 and 72.56.116.75 are communicating through a device that is not aware of SIP (the firewall) and that device must be configured to forward the SIP traffic and RTP traffic based on the ports being used.  This means that if you have a range of 1000 possible RTP ports that could be used by your B2BUA, you must forward 1000 ports from the firewall back to the B2BUA.

Each direction of RTP uses a different port, so if you expect to have 500 "calls" up on your system you must have 1000 ports available on your firewall for this.

Benefits of adding a B2BUA

Very Cost Efficient - Free if your current hardware can support another VM running Asterisk/FS, or if you have extra hardware around

Unfortunately this is the only real benefit above adding an SBC to the Network, as it tends to be much more difficult to configure without adding any functionality other than allowing the SIP messages to traverse the NAT.

Integrating NCA

Integrating NCA into an existing solution behind a NAT is not difficult, but it is definitely not simple.

There are two ways to configure NCA.  Depending on how you choose to integrate NCA it will shift the responsibility of who determines the final destination of the call.

NCA AsOutboundProxy

When NCA is configured "AsOutboundProxy" you will need to ensure the following:

  • The DIALER is responsible for ensuring the final destination of the SIP Message

  • The DIALER is configured to use NCA as an Outbound Proxy

  • NCA is configured to be in "AsOutboundProxy" mode

  • NCA is configured to use the B2BUA as an Outbound Proxy

  • The B2BUA can route calls based on the DOMAIN part of the "TO" Header

NCA in "Genesys" mode

 

When NCA is configured to be in "Genesys" mode, we the SIP messages we receive are TO:123@[NCA], and we must be configured to send all SIP messages to a pre-configured hard-coded IP address.  This means that you must ensure the following:

  • The DIALER sends its outbound call attempts TO NCA

  • NCA sends all of it's calls TO the B2BUA

  • The B2BUA must be able to determine the correct final destination of the SIP Invite

  • None of the devices are configured to use "Outbound Proxies"

 

Return to Documentation Home I Return to Sangoma Support