5.10. NAT Traversal

SIP devices behind Network Address Translators (NATs) cannot reach other SIP devices reliably. The root reason is SIP protocol advertises SIP device’s IP addresses in several places in the protocol: Contact and Via header fields SDP c line. These addresses are unroutable once they cross a NAT device and break signaling. The ABC SBC is designed to assist the to facilitate NAT traversal for SIP devices by several techniques: it centers itself in the middle of communication path, sends signaling and media reversely to where it came from even in violation of the SIP standard, replaces private IP unroutable addresses with its own and keeps all bindings alive.

As depicted in Fig. SBC and NAT traversal, when an INVITE request traverses a NAT then only the IP addresses in the IP header will be changed. Any IP addresses included in the message itself, e.g., Contact, SDP c line, will still reference the private IP address of the caller. As the callee would use the information in the Contact header for replying back to the caller and send media packets to the address in the SDP the call establishment will fail.


Figure 1: SBC and NAT traversal

In the context of NATs, there are basically three different possibilities with respect to the network topology that will influence the possible measures that can be taken by the ABC SBC to deal with those NATs:

  • Far end NAT: This is the most common case in public SIP service scenarios. The SBC is located on the public Interned and the end-devices access the SBC from behind NATs. The SBC must facilitate the NAT traversal for the end-devices: it must accomplish RTP traversal, SIP traversal and registration off-load.
  • SBC is placed on the NAT:. This is the most common case in enterprise deployments in which the SBC acts as firewall between a private network with SIP telephones and PBXes, and the outside network. It has at least one signalling and media interface inside and one outside the NAT. SIP signaling is handled natively without any additional configuration. However, it is necessary to enable RTP anchoring (relay) so that the media payload can flow from between the otherwise unroutable networks.
  • Near end NAT: here, the SBC is placed right behind the NAT and a port forwarding is configured from the NAT to the SBC. This is considered by the ABC SBC as a special case of the previous configuration. In this case, it is perfectly sufficient to configure the signalling and media interfaces with the public IP address on the outside of the NAT. It is also necessary that the configured port range on the media interface corresponds to the forwarded ports for media transport, as no port translation is supported at this place.

In order to enable users behind a NAT to be reachable the ABC SBC needs to perform the following tasks.

  • Detect if a SIP user is behind a NAT. This allows to eliminate expensive NAT traversal faciliation for users who do not need it. The test is performed by the condition NAT in inbound rules.
  • Fix outgoing calls: The ABC SBC must fix SIP INVITEs from users behind NATs so that subsequent SIP messages coming back will cross the NATs successfuly. Particularly, the SBC fixes Contact header-field and stores NAT information in dialog context. This functionality must be enabled in inbound rules using the Enable Dialog NAT Handling action.
  • Fix incoming calls: The ABC SBC must deliver incoming INVITEs for a user behind a NAT through the NAT devices. This is only possible if the NAT devices keep the UDP or TCP binding open over which the user registered. Otherwise the user becomes unreachable once the binding expires. Therefore the ABC SBC pays great attention to the SIP registration process: It can force more frequent registrations to keep the bindings alive and it also keeps source address from which the registration came. Subsequent requests for the registered client are forwarded to the address (as opposed to the private IP address advertised in Contact header-field). To enable this functionality the actions REGISTER throttling and Enable REGISTER caching must be applied to REGISTER messages, and the action Retarget R-URI from cache, with the enable NAT handling option turned on musst be applied to calls towards the client. See section Registration Caching and Handling for more details.
  • Media anchoring: The ABC SBC redirects RTP stream to itself and sends symmetrically one’s party RTP media to where the RTP media from the other party came from. This symmetric mode of operation overrides SIP signaling but works more reliable, because it is better compatible with how most NAT devices work. The downside of this approach is the extra bandwidth consumption on the ABC SBC and increased RTP latency. Media anchoring is enabled by the action Enable RTP Anchoring. “Force symmetric option” can be turned on and off for UACs in inbound and UAS in outbound rules. Media handling and RTP anchoring ABC SBC is described in more detail in Sec. Media Handling.

In summary the following conditions and actions are used to configure NAT traversal:

  • NAT condition - check if the first Via address is or is not behind NAT. This checks if the first Via address is the same as the IP address that the SIP message was received from.
  • Enable dialog NAT handling action - force all subsequent in-dialog messages to be sent to IP/port from which the dialog-initiating request came.
  • Enable RTP anchoring action - force RTP from a SIP user to be sent through the ABC SBC. The Force-symmetric RTP option forces media from the other side to be sent reversely to where the user’s media came from. Turn it off only if a Call Agent is known to reject symmetric media.
  • Enable REGISTER caching must be applied to REGISTER messages for retargetting to function. See section Registration Caching and Handling for more details.
  • Retarget R-URI from cache (alias) action. This action makes sure that INVITEs coming to a registered client will reach it by sending them to the transport address from which a REGISTER came. The options  Enable NAT handling  and  Enable sticky transport should be turned on.

The example in the following subsection shows how to place the respective actions in the ABC SBC rulebase.


In an actual deployment, the specific topology needs to be considered carfuly. For example, if SIP passes the SBC twice, RTP could without precaution be also anchored twice resulting in unnecessary performance degradation. That’s because the SBC recognizes inbound and outbound call legs as two separate calls.

5.10.1. NAT Traversal Configuration Example

This example shows how to put all the NAT-faciliating actions in a consistent rule-base. This example is based on the “far-end” NAT traversal topology as shown in the Figure NAT Traversal Example: Network Topology. In this topology, the ABC SBC is multihomed: it connects to the public Internet with one interface and to a private network with the other interface. Both networks are not mutually routable, the ABC SBC connects them on application layer. SIP telephones are on the public side behind NATs, service provider infrastructure including a SIP registrar, proxy, media server and PSTN gateway are located in the private network.


Figure 2: NAT Traversal Example: Network Topology

The first preparatory step to be is handling telephone’s outgoing SIP messages coming from the external realm. That is done in the external realm’s A rules: Dialog-initiating requests must be fixed in a way that reverse messages will follow the same path. REGISTERs must be stored along with the transport address from which they came. Frequent re-registration must be enforced to keep NAT-bindings alive. Eventually RTP anchoring must be enabled. The configuration fragment is shown in the Figure A-rules for traffic coming from outside.


Figure 3: A-rules for traffic coming from outside

When requests pass the SIP proxy and come again from the inside network to the SBC, the addresses in them must be reverted to the form used initially by SIP User Agent. The configuration fragment is shown in Figure A-rules for traffic coming from inside.


Figure 4: A-rules for traffic coming from inside

Eventually RTP anchoring is turned in in C-rules for calls going to the public network, as shown in Figure C-rules for traffic leaving for outside.


Figure 5: C-rules for traffic leaving for outside

Table Of Contents

Previous topic

5.9. Media Handling

Next topic

5.11. Registration Caching and Handling

This Page