SIP Hosted NAT Traversal (HNT)

This section explains how to configure SIP Hosted Network Address Translation (HNT) traversal. SIP HNT lets endpoints behind a NAT/firewall device send and receive signaling and media using the Oracle Communications Session Border Controller as a relay.

About SIP HNT

SIP HNT is a technique the Oracle Communications Session Border Controller uses to provide persistent reachability for SIP UAs located in private Local Area Networks (LANs) behind Nat/firewall devices. It relies on frequent, persistent messaging to ensure that the binding on the intermediary NAT device is not torn down because of inactivity. HNT does not require support for the NAT in the SIP endpoint.

The following diagram illustrates SIP HNT traversal.

The Oracle Communications Session Border Controller’s HNT function allows endpoints located behind NATs to communicate; providing means to traverse NATs. The Oracle Communications Session Border Controller interacts with endpoints (using SIP) to allow persistent inbound and outbound signaling and media communications through these NATs.

The Oracle Communications Session Border Controller automatically detects when an intermediate NAT exists between the UA and the Oracle Communications Session Border Controller by comparing the Layer 3 IP address of a REGISTER message with the IP address indicated within the UA. The Oracle Communications Session Border Controller sends signaling responses to the address and port that the request came from, rather than the address and port indicated in the request. The Via header in the request message indicates where the response should be sent.

Using HNT with Existing NAT Device

For network architectures in which premise devices and endpoints reside behind an existing NAT device, the Oracle Communications Session Border Controller’s HNT function allows these premise NATs to be traversed without requiring an upgrade to the premise equipment, the deployment and management of additional premise-based hardware or software, or any NAT device configuration changes.

Registering Endpoints

The Oracle Communications Session Border Controller uses periodic endpoint registration messages to dynamically establish and maintain bindings in the NAT. These bindings keep a signaling port (port that is opened on a firewall to allow traffic to pass through it is a pinhole) open in the NAT that allows the inbound signaled communications to pass through. Using the endpoint registrations, the Oracle Communications Session Border Controller then maps the Layer 3 (OSI network layer that deals with switching and routing technologies for data transmission between network devices) IPv4 address/port information from the NAT device to the Layer 5 (OSI session layer that deals with session and connection coordination between applications) entity (for example, user name or phone number) behind the NAT so that when an incoming signaling message is received, the Oracle Communications Session Border Controller sends it to the appropriate address and port on the NAT for the called party.

Establishing Media Flows

During call setup, the ports for bidirectional media flows are established dynamically. Since the media flows also pass through the Oracle Communications Session Border Controller, it can identify the IPv4 address/port information on the NAT device used for the outgoing media coming from the user name/phone number. The Oracle Communications Session Border Controller then uses that same NAT’s IPv4 address/port information to send incoming media to the correct user name/phone number behind the NAT device.

Prerequisites

In order to achieve HNT, the endpoints involved must be capable of:

symmetric signaling: sending and receiving SIP messages from the same transport address (IP address or User Datagram Protocol/Transmission Control Protocol (UDP/TCP) port
symmetric media: sending and receiving Real-Time Transport Protocol (RTP) messages from the same UDP port

These conditions are required to allow signaling and media packets back through the NAT (through the bound external address and port). These packets must come from the address and port to which the outbound packet that created the NAT binding was sent. The NAT sends these inbound packets to the source address and port of the original outbound packet.

When SIP HNT is used, the Oracle Communications Session Border Controller sends signaling responses to the address and port that the request came from rather than the address and port indicated in the request. The Via header in the request message indicates where the response should be sent.

Keeping the NAT Binding Open

Additional measures are also required to keep the NAT binding open because most NAT bindings are discarded after approximately a minute of inactivity. The Oracle Communications Session Border Controller keeps the SIP NAT binding open by returning a short expiration time in REGISTER responses that forces the endpoint to send frequent REGISTER requests.

In order to keep the NAT binding open for SIP, the Oracle Communications Session Border Controller maintains the registration state. When an endpoint first registers, the Oracle Communications Session Border Controller forwards that REGISTER message on to the real registrar. You can define the real registrar using either of the following methods:

Configure the SIP config registrar host and registrar port to indicate the real registrar.
Map the SIP config registrar host and registrar port values to the SIP NAT home proxy address and home proxy port values. Then configure the SIP NAT’s external proxy address and external proxy port values to correspond to the real registrar.

Note:
A registrar can be located in a SIP NAT realm.

When a successful response is received, the Oracle Communications Session Border Controller caches the registration to memory. This cached registration lives for the length of time indicated by the expiration period defined in the REGISTER response message from the registrar. The response sent back to the endpoint has a shorter expiration time (defined by the SIP config’s NAT interval) that causes the endpoint to send another REGISTER message within that interval. If the endpoint sends another REGISTER message before the cached registration expires, the Oracle Communications Session Border Controller responds directly to the endpoint. It does not forward the message to the real registrar.

If the cached registration expires within the length of time indicated by the NAT interval, the REGISTER message is forwarded to the real registrar. If the Oracle Communications Session Border Controller does not receive another REGISTER message from the endpoint within the length of time indicated by the NAT interval, it discards the cached registration.

The Contact Uniform Resource Identifier (URI) in the REGISTER message sent to the registrar by the Oracle Communications Session Border Controller points at the Oracle Communications Session Border Controller so that the proxy associated with the real registrar sends inbound requests to the Oracle Communications Session Border Controller. This way, the inbound requests can be forwarded to the endpoint through the NAT binding.

The following example illustrates the SIP HNT registration call flow for the SIP HNT feature.

The OCSBC supporting the the SIP HNT registration call flow for the SIP HNT feature.

The following example illustrates the SIP HNT invitation call flow for the SIP HNT feature.

The OCSBC supporting the the SIP HNT invitation call flow for the SIP HNT feature.

Working with Multiple Domains

You can use a wildcard (*) with the HNT feature to accommodate multiple domains and to allow the Oracle Communications Session Border Controller to cache all HNT endpoints. The wildcard functionality is enabled in the SIP config by entering an asterisk (*) in the registrar domain and registrar host fields.

The wildcard allows the use of either a local policy or Domain Name Service (DNS) to resolve the domain name to the correct registrar. Either method can be used to route the Fully Qualified Domain Name (FQDN) when the you enter an asterisk (*) for the register host. An FQDN consists of an unlimited number of domain labels (domain names), each separated by a dot (.). The FQDN can include the top level domain name (for example, acmepacket.com).

In the hostname acme-packet.domainlbl.example100.com, the syntax is as follows:

acme-packet is a domain label
domainlbl is a domain label
example100 is a domain label
com is the top label

The information configured in a local policy is used before DNS is used. If the next hop destination address (defined in the local policy’s next hop field) is an IPv4 address, a DNS server is not needed. A DNS server is needed when the IPv4 address of the next hop destination address is a FQDN or cannot be determined from the Oracle Communications Session Border Controller’s configuration. Even with a configured local policy, the next hop destination address might be an FQDN that requires a DNS lookup.

If the registrar host does not use the wildcard, the Oracle Communications Session Border Controller always uses the configured address. You can limit the number of endpoints that receive the HNT function. For example, you can use a non-wildcarded registrar domain field value (like acme.com) with a wildcarded registrar host field value.

HNT Configuration Overview

To configure SIP HNT NAT traversal, you need to configure both the SIP interface and the SIP config.

SIP HNT Single Domain Example

The following example shows values entered for the SIP config and SIP interface elements to configure SIP HNT for a single domain and registrar.

SIP config

Parameter	Sample Value
registrar domain	netnetsystem.com
registrar host	192.168.12.1
registrar port	5060

SIP interface

Parameter	Sample Value
NAT traversal	always
NAT interval	60
minimum registration expire	200
registration caching	disabled
route to registrar	enabled

SIP HNT Multiple Domain Example

The following example shows values entered for the SIP config and SIP interface elements to configure SIP HNT for a multiple domains and multiple registrars.

SIP config

Parameter	Sample Value
registrar domain	*
registrar host	*
registrar port	0

SIP interface

Parameter	Sample Value
NAT traversal	always
NAT interval	60
minimum registration expire	200
registration caching	disabled
route to registrar	enabled

HNT Configuration

To configure a SIP interface on the Oracle Communications Session Border Controller (SBC):

In Superuser mode, type configure terminal and press Enter.
```
ORACLE# configure terminal
```
Type session-router and press Enter to access the system-level configuration elements.
```
ORACLE(configure)# session-router
```
Type sip-interface and press Enter. The system prompt changes to let you know that you can begin configuring individual parameters.
```
ORACLE(session-router)# sip-interface
ORACLE(sip-interface)#
```
From this point, you can configure sip-interface parameters. To view all sip-interface parameters, enter a ? at the system prompt.
nat-traversal—Define the type of HNT enabled for SIP. The default value is none. Available values include:
- none—Disables the HNT feature for SIP (default value)
- rport—SIP HNT function only applies to endpoints that include the rport parameter in the Via header and the sent-by of the topmost VIA matches the Contact-URI host address, both of which must be different from the received Layer 3 address.
- always—SIP HNT applies to requests when the sent-by of the topmost VIA matches the Contact-URI host address, both of which must be different from the received Layer 3 address. (Even when the rport parameter is not present.)
nat-interval—Set the expiration time in seconds for the SBC’s cached registration entry for an HNT endpoint. The default value is 30. The valid range is:
- Minimum—0
- Maximum—4294967295
  
  Oracle recommends setting the NAT interval to one-third of the NAT binding lifetime. A NAT binding lifetime is the network connection inactivity timeout. The value is configured (or hardwired) in the NAT device (firewall). This timer is used to prevent the NAT device from keeping an unused port open.
registration-caching—Enable for use with all UAs, not just those that are behind NATs. By default, this field is set to disabled. If enabled, the SBC caches the Contact header in the UA’s REGISTER request when it is addressed to one of the following:
- SBC
- registrar domain value
- registrar host value
  
  The SBC then generates a Contact header with the SBC’s address as the host part of the URI and sends the REGISTER to the destination defined by the registrar host value.
  
  Whether or not SIP HNT functionality is enabled affects the value of the user part of the URI sent in the Contact header:
- enabled—The SBC takes the user part of the URI in the From header of the request and appends a cookie to make the user unique. A cookie is information that the server stores on the client side of a client-server communication so that the information can be used in the future.
- disabled—The user part of the Contact header is taken from the URI in the From header and no cookie is appended. This is the default behavior of the Oracle Communications Session Border Controller.
  
  When the registrar receives a request that matches the address-of-record (the To header in the REGISTER message), it sends the matching request to the SBC, which is the Contact address. Then, the v forwards the request to the Contact-URI it cached from the original REGISTER message.
min-reg-expire—Set the time in seconds for the SIP interface. The value you enter here sets the minimum registration expiration time in seconds for HNT registration caching. The default value is 300. The valid range is:
- Minimum—1
- Maximum—999999999
  
  If, for example, an endpoint sends a REGISTER message with the "Expires:" field set to 60 seconds, then the SBC (when re-originating the REGISTER message to the registrar) changes that value to the min-reg-expire value if the latter is greater. This is because the SBC requires the value of the Expires field to be at least the value of the min-reg-expire parameter. If the value of the Expires field in the original message is equal to or greater than the value of the min-reg-expire parameter, the SBC will not change it.
  
  This value defines the minimum expiration value the SBC places in each REGISTER message it sends to the real registrar. In HNT, the SBC caches the registration after receiving a response from the real registrar and sets the expiration time to the NAT interval value.
  
  Some UAs might change the registration expiration value they use in subsequent requests to the value specified in this field. This change causes the SBC to send frequent registrations on to the real registrar.
registration-interval—Set the SBC’s cached registration entry interval for a non-HNT endpoint. Enter the expiration time in seconds that you want the SBC to use in the REGISTER response message sent back to the UA. The UA then refreshes its registration by sending another REGISTER message before that time expires. The default value is 3600. The valid range is:
- Minimum—1
  
  A registration interval of zero causes the SBC to pass back the expiration time set by and returned in the registration response from the registrar.
- Maximum—999999999
  
  If the expiration time you set is less than the expiration time set by and returned from the real registrar, the SBC responds to the refresh request directly rather than forwarding it to the registrar.
  
  Note:
  With registration caching, there is no NAT; therefore, a short registration interval causes the UA to send excess REGISTER messages.
  
  Although the registration interval applies to non-HNT registration cache entries, and the loosely related NAT interval applies to HNT registration cache entries, you can use the two in combination. Using a combination of the two means you can implement HNT and non-HNT architectures on the same SBC. You can then define a longer interval time in the registration interval field to reduce the network traffic and load caused by excess REGISTER messages because there is no NAT binding to maintain.
route-to-registrar—Enable routing to the registrar to send all requests that match a cached registration to the destination defined for the registrar host; used when the Request-URI matches the registrar host value or the registrar domain value, not the SBC’s address. Because the registrar host is the real registrar, it should send the requests back to the SBC with the SBC’s address in the Request-URI. The default value is disabled. The valid values are:
- enabled | disabled
  
  For example, you should enable routing to the registrar if your network uses a SBC and needs requests to go through its service proxy, which is defined in the registrar host field.

Global SIP Configuration

To configure the SIP configuration:

In Superuser mode, type configure terminal and press Enter.
```
ORACLE# configure terminal
```
Type session-router and press Enter to access the system-level configuration elements.
```
ORACLE(configure)# session-router
```
Type sip-config and press Enter. The system prompt changes to let you know that you can begin configuring individual parameters.
```
ORACLE(session-router)# sip-config
ORACLE(sip-config)#
```
From this point, you can configure SIP config parameters. To view all SIP config parameters, enter a ? at the system prompt.
registrar-domain—Optional. Define the domain to match against the host part of a URI to determine if a request is addressed to the registrar. If there is a match, the registration caching, NAT traversal, and route to registrar parameter values for the SIP interface are applied to the request. By default, this field remains empty. Available values are:
- an asterisk (*) to specify the values apply to all requests.
- any alphanumeric character or any combination of alphanumeric characters. For example, acme1.com.
  
  A hostname consists of any number of domain labels, separated by dots (.), and one top label. A top label is the last segment of the hostname. It must start with an alphabetical character. After the first character, a top label can consist of any number or combination of alphanumeric characters, including those separated by dashes. The dash must be preceded and followed by alphanumeric characters. A single alphabetical character is the minimum requirement for a hostname field (for example, c to indicate .com).
  
  When the REGISTER message’s Request-URI has an FQDN, it is matched against the registrar domain’s value to determine if the message needs to be forwarded to the registrar port on the registrar host. The registrar domain’s value is also used when route to registrar is set to enabled, to determine if a request needs to be forwarded to the registrar.
  
  Only the right-hand part of the domain name in the Request-URI needs to match the registrar domain value. For example, acme3.acmepacket.com matches acmepacket.com. However, the entire domain label within the domain name must match. For example, the domain label “acme3.acmepacket.com” would not match packet.com.
registrar-host—Define the address of the registrar for which requests for registration caching, NAT traversal, and router to registrar options apply. You can use a specific hostname, a IP address, or a wildcard (*):
- an asterisk (*) indicates normal routing (local policy, DNS resolution, and so on) is used to determine the registrar’s address.
- hostname: can consist of any alphanumeric character or any combination of alphanumeric characters (for example, acme1.com). The hostname can consist of any number of domain labels, separated by dots (.), and one top label. You can use the minimum field value of a single alphabetical character to indicate the top label value (for example, c to indicate .com).
- IPv4 address: must follow the dotted notation format. Each of the four segments can contain a numerical value between zero (0) and 255. For example, 192.168.201.2. An example of a invalid segment value is 256.
  
  By default, the registrar host field remains empty.

registrar-port—Set the SIP registrar port number. The SIP registrar server configured in this and the registrar host field is the real registrar. Or the values entered in those fields map to the home proxy address and home proxy port of the SIP NAT with external proxy address and external proxy port values that correspond to the real registrar. The default value is 0. The valid range is:

Minimum—0, 1025

Maximum—65535

The following example shows the values for a single domain and registrar configuration.

sip-config
        state                          enabled
        operation-mode                 dialog
dialog-transparency		disabled
        home-realm-id                  acme
        egress-realm-id
        nat-mode                       Public
        registrar-domain
        registrar-host
        registrar-port                 0
        init-timer                     500
        max-timer                      4000
        trans-expire                   32
        invite-expire                  180
        inactive-dynamic-conn          32
        red-sip-port                   1988
        red-max-trans                  10000
        red-sync-start-time            5000
        red-sync-comp-time             1000
        last-modified-date             2005-03-19 12:41:28