Adaptive HNT

Overview

Without adaptive HNT, the Oracle Communications Session Border Controller keeps NAT pinholes open and port mapping cached by forcing the UAC to send frequent SIP REGISTER messages. It does so by setting the expires time to a short interval. Some NATs only need a message to be sent by the private client once every twenty minutes, while other NATs delete their cache/pinhole in thirty seconds if no messages appear. Given this large variation in time intervals, the Oracle Communications Session Border Controller’s nat-interval (expire time), set on the applicable sip-interface, has been set to a low value in order to support as many NAT types as possible. However, CPU performance and scalability issues result from such a small refresh time, especially when there is a very large number of potential registered users.

When you use adaptive HNT, the Oracle Communications Session Border Controller waits for a time interval and then sends a SIP OPTIONS message to the UAC to see if it can still be reached. If the UAC can still be reached, the Oracle Communications Session Border Controller increases the timer and tries again. In case the pinhole closes because it has exceeded the NAT's cache time, the Oracle Communications Session Border Controller sets the expires time to be slightly longer than the time it tests using the OPTIONS method. This way, the UAC will send another REGISTER message shortly thereafter and impact on service will be minimal.

Adaptive HNT Example

An example call flow using adaptive HNT involves a basic HNT user and a Oracle Communications Session Border Controller. It begins when the Oracle Communications Session Border Controller receives and forwards the 200 OK for the REGISTER message. Then the Oracle Communications Session Border Controller sends an expires timer for slightly longer than the time for which to test; in this example, it begins the test for the amount of time set for the minimum NAT interval, specified by the nat-interval set on the applicable sip-interface. It adds ten seconds to this time when it sends the expires timer. This way, there is time for the OPTIONS message to be sent before the REGISTER message is received (which would refresh the NAT’s cache). The Oracle Communications Session Border Controller also tries to keep the REGISTER time short enough so that even if the NAT pinhole closes, there is minimal time before the UAC creates a new NAT binding by sending another REGISTER. Because a ten second interval may be too long, you might want to set this value to a better-suited time.

The test succeeds with a minimum test-timer because the UAC responded to the OPTIONS message. So the test-timer value is increased by thirty seconds and tried again. The expires time in the REGISTER message will be increased to the test-timer value plus ten seconds. This time, the UAC does not respond to the OPTIONS message even though it was sent multiple times. Because the OPTIONS fails, when the Oracle Communications Session Border Controller receives another REGISTER, it responds with the previously successful timer value (in this case, the minimum NAT interval).

However, if the OPTIONS request succeeds, then the Oracle Communications Session Border Controller persists with the test until it fails or until the maximum NAT timer value is reached. In this case, when the OPTIONS message fails, the Oracle Communications Session Border Controller uses the last successful test-timer value as the time for the expires header in the 200 OK for the REGISTER message.

Adaptive HNT over TCP

The SBC supports Adaptive Host NAT Traversal (AHNT) over TCP in addition to UDP. TCP AHNT configuration and behavior is largely the same as for UDP. You use sip-interface parameters that are equivalent to, but separate from the UDP parameters to configure Adaptive HNT for TCP.

The SBC detects that an endpoint is behind a NAT using the same process for both UDP and TCP, comparing the layer 3 IP address of a REGISTER with the VIA header before proceeding with a registration. If the first VIA is different from the layer three address, the SBC assumes there is a NAT and sets up flows accordingly. For subsequent HNT timing processes, the SBC refers to TCP-related HNT configuration parameters, which are separate from those used for UDP transport.

When configuring adaptive HNT for TCP, you use the tcp-nat-interval parameter on a sip-interface to specify the NAT interval for TCP transport. The SBC starts AHNT testing using this value as the initial interval after which the SBC sends an OPTIONS request and waits for an OPTIONS response from the endpoint it is testing until the test expires, calculated as tcp-nat-interval plus the tcp-nat-int-increment.

Parameters on the sip-interface that apply to AHNT testing over TCP connections include:

tcp-sip-dynamic-hnt
tcp-nat-interval
tcp-max-nat-interval
tcp-nat-int-increment
tcp-nat-test-increment

The system ends the AHNT test when:

The OPTIONS request was not sent because the NAT gateway or UA closed the connection.
The new expires header value calculated by the SBC for the next RE-REGISTERs 200 OK exceeds your configured value for max-nat-interval (or tcp-max-nat-interval).
The early RE-REGISTER occurrence count, monitored by the SBC exceeds 3.
The UE sends a keep-alive SIP request for a contact to keep the NAT port open for 5 or more consecutive times.
When you configure the nat-int-increment (or tcp-nat-int-increment) value higher more than 32s, and the OPTIONS sent by the SBC has not received a response within the Client Transaction expires time (32s).

When the test is complete, the SBC uses the last successful test time for the expires value in the current and subsequent refresh REGISTER’s 200 OK for that contact.

Feature Limitations

This Adaptive HNT over TCP feature generates several limitations on SBC operation:

When you deploy this feature, the configuration change does not apply to existing contacts already using AHNT functionality.
When you enable both sip-dynamic-hnt and tcp-sip-dynamic-hnt, the SBC applies this feature based on transport type of each REGISTER request. Either AHNT over TCP or UDP is applicable for a users contact.
A UA with the same contact does not change its transport type when it sends refresh REGISTER. A UA can only change its transport type by a new registration with the new contact for that transport type.
The SBC synchronizes the learned expires time to HA only after the AHNT test is complete for both UDP and TCP contacts.
A SIP contact URI (IP:Port:transport) must remain the same in a user's REGISTER and RE-REGISTER. The transport type between the UA or NAT Gateway and the SBC cannot change until that contact expires.

Adaptive HNT Call Flows

This section presents call flow diagrams to help explain AHNT functionality on the SBC.

The call flows below depict the SBC performing AHNT testing to establish an expires value that keeps a NAT pinhole open while additional signaling and media traverses the NAT device for a specific call. The NAT device uses this pinhole for either UDP or TCP transport.

Call flows are the same for both TCP and UDP, using the applicable parameters on the sip-interface:

sip-dynamic-hnt (or tcp-sip-dynamic-hnt)—Enables or disables AHNT for UDP or TCP connections respectively.
nat-interval (or tcp-nat-interval)—The number of secs used to calculate the test-timer for sending OPTIONS request or to perform the AHNT test.
nat-int-increment (or tcp-nat-int-increment)—The number of seconds added to the expires header value in REGISTERs 200 OK. The actual AHNT test would be done only during this incremented interval time we added to expires header in REGISTERs 200OK.
nat-test-increment (or tcp-nat-test-increment)—The number of seconds used to increment the next test timer value when a RE-REGISTER arrives.
max-nat-interval (or tcp-max-nat-interval)—The maximumn number of seconds used for the expires value. When reached, the SBC stops AHNT testing.

Normal ANHT Process

This call flow depicts an example of the SBC performing AHNT testing. The steps provided below expand upon the behavior.

This image depicts an example of AHNT Operation.

As shown in the call flow above, the SBC implements this feature within the context of registration. The first three lines in the flow present a successful registration using the registrar, and ending with a 200 OK from the registrar to the SBC. Assume TCP transport, but note the behavior is the same for UDP when the equivalent configuration is in place.

When it receives the 200 OK reply to the REGISTER request from the registrar, the SBC refers to the expires value, normally 3600 seconds, and checks whether you have enabled the tcp-sip-dynamic-hnt parameter for this connection's transport protocol on the sip-interface where the REGISTER request arrived. If so, the SBC:

Replaces the expires header parameter value in its 200 OK to the endpoint with the sum of the values configured in the tcp-nat-interval and tcp-nat-int-increment parameters. In the flow, the system has used the defaults of both parameters respectively and arrived at an expires time of 90 + 10 = 100 seconds.
In addition, the SBC starts a timer using the value configured in tcp-nat-interval. Notice that the expires time is slightly longer than the timer time. This allows the SBC to decide whether this test iteration succeeded or failed and change the value of the next expires time accordingly.
The SBC sends an OPTIONs message at the 90th second and waits for a reply. Note that the test timer is active.
The end station replies, in this case, with a 404 - Not found message within the test window. This concludes the first iteration of the AHNT test successfully, indicating that the NAT device does not close the pinhole sooner than the expires time of 90 seconds.
Because this test was successful, the SBC recalculates the test time using the sum of the values configured in the tcp-nat-interval and tcp-nat-testincrement parameters. Again, the flow shows the system using the defaults of both parameters respectively and arriving at an expires time of 90 + 30 = 120 seconds.
The UA responds with a re-REGISTER at the original expires time.
The SBC sends the 200 OK to the re-REGISTER, including a new expires time and starts the test timer.
The SBC sets the expires using the sum of the test times and the tcp-nat-int-increment parameters (120 +10 = 130 seconds).
The SBC sends an OPTIONS request at or after 120th second and waits for the response. The actual testing happens between 120th second to 130th second.
For this test iteration, the UA does not respond before the test window expires (130 seconds). The SBC reverts is test timer to that last successful value of 90 seconds.
The UA sends a re-REGISTER at the expires time of 130 seconds.
The SBC sends a 200 OK for the re-REGISTER and sets the expires time to the same value as the last successful test timer value, which in this case is 90 seconds.

Note:
The system does not perform any calculation using the tcp-nat-int-increment value for the final setting.

Early Refresh REGISTER Scenario

In some cases, a UA may send a re-REGISTER before the expires time. The SBC does not end its AHNT testing when this happens, instead adjusting its test timing to try and avoid any further early REGISTER refreshes. Specifically, the SBC increases the expires time it sends to the UA in the 200 OK by the NAT test's increment value, and restarts the OPTIONS test timer without increasing its value.

The SBC, however, also tracks the number of early REGISTER refreshes that it receives during a session, and ends AHNT testing if that count reaches three in a row. Each early refresh REGISTER resets the NAT device pinhole. If the NAT device is keeping the pinhole open, there is no need for the SBC to expend processing cycles for the same purpose.

This image depicts an example of AHNT Operation with early registration.

As shown in the call flow above, the SBC implements this feature within the context of registration. The first three lines in the flow present a successful registration using the registrar, ending with a 200 OK from the registrar to the SBC.

Like the first example, this flow includes the system using the defaults of the interval and increment parameters respectively to set an expires time of 90 + 10 = 100 seconds.
In addition, the system starts the OPTIONS timer using 90 seconds.
In this flow, however, the UA sends a re-REGISTER before the OPTIONS timer expires.
As described above, the SBC increases the expires time using the tcp-nat-test-increment value (30 seconds) and sends the 200 OK with an expires time of 130 seconds. The SBC also restarts the OPTIONS test timer using its original value of 90 seconds.
After 90 seconds, the SBC sends the OPTIONS request and gets a 200 OK (or other) response.
For this iteration, there is no early REGISTER refresh. The SBC starts the test timer using its normal calculation, in this case 90 + 30 = 120, and sends the 200 OK with an expires calculated as the first successful test, 130 seconds.
This call flow completes by receiving no reply to the OPTIONS request in time, so the SBC reverts to the last successful expires time of 90 seconds.

Note:
The system does not perform any calculation using the tcp-nat-int-increment value for the final setting.

If the UA/NAT sends another early refresh REGISTER at any time during the session, the SBC increases the expires time in the 200 OK by the tcp-nat-test-increment and restarts the test timer to its original value.

Early Refresh REGISTER while OPTIONS In-Progress

Within this example, the SBC receives a refresh REGISTER before getting a 200 OK for the OPTIONS request it sent to the UA. When it gets this refresh REGISTER, the SBC marks the test as done and sets the expires time to the tcp-nat-interval if no test completed successfully, or to the last successful test's expires time.

In this same scenario, if the OPTIONS client transaction expires due to no response from UA, the SBC marks the test as done and inserts the same expires header values as above. By default, OPTIONS expiry happens at 32 seconds.

This image depicts an example of AHNT Operation with early registration after the SBC issues an OPTIONs keepalive.

Keep-Alive from UA Flow

Within other use cases, the UA itself tries to keep the NAT pinhole open by sending OPTIONS or any other out of dialog SIP request for that contact from the same IP address and port number that it used for its last REGISTER. When it detects this, the SBC disables AHNT testing for that contact for 5 or more consecutive instances, and uses the last successful test time for future RE-REGISTERs expires times.

This image depicts an example of AHNT Operation with the UA issuing the keepalive.

AHNT Operation in Conjunction with TCP Behavior

Some call flows applicable to this feature are subject to normal packet delivery delays that allow the NAT pinhole to close. Examples include TCP connections that experience segmented packet transfer wherein a segment may not have received an ACK, lengthening the amount of time consumed by a transmission. In these cases, the SBC persists with its AHNT behaviors, ultimately waiting out the closed pinhole and proceeding with packet reassembly after the TCP connection resumes transmission.

Consider the situation wherein the OPTIONS pings are retransmitted after a pinhole is closed and re-opened. The SBC would not be aware of whether this situation was caused by the absence of an ACK to an OPTIONS or because there was a network issue. In this case, the SBC follows standard TCP behavior and waits for a segment's ACK from an endpoint within its congestion window (CWIND) before sending the additional segments to the endpoint.

This call flow demonstrates AHNT operating within the context of TCP congestion window processes.

The steps below provide additional explanation on the call flow above:

The SBC establishes the TCP connection with TCP maximum segment value (MSS) of 1420. The SBC starts AHNT testing and establishes an expires value of 100.
The SBC follows its AHNT testing procedure until it finds an expires value that keeps the pinhole open.
In the meantime, the end station sends another REGISTER to which the SBC provides a 200 OK.
Notice the first 200 OK sent by the SBC is 443 bytes. The expires timer is lengthened as the AHNT testing is continuing to identify the longest window it can used without the pinhole closing.
After the re-REGISTER and 200 OK, the NAT device happens to close the pinhole.
The SBC sends an OPTIONS, with a size of 1024 bytes to continue with the AHNT test. But OPTIONS does not reach the UE because the pinhole is closed and it was dropped by the NAT. TCP keeps the connection open waiting for the ACK to the OPTIONS.
In addition, the TCP CWIND still has 1024 bytes occupied by the most recent OPTIONS.
The UE sends another refresh REGISTER, resulting in the SBC completing the AHNT test and reverting to the last successful expires timer of 90 seconds. This re-REGISTER also re-opens the NAT pinhole.
Next, the SBC prepares to send 200 OK with expires of 90 seconds. Because the 1024 bytes of the unanswered OPTIONS still occupies the a large amount of the CWIN, the SBC can only send a part of the 200 OK, in this case 384 bytes.
Later, the SBC re-transmits an OPTIONS ping and receives an ACK because the pinhole is open. This ACK applies to the OPTIONS and the 384 bytes of the outstanding 200 OK.
The CWIN is now cleared, so the SBC is able to send the remaining 59 bytes of the 200 OK.
At this point, every re-REGISTER's 200 OK for this UE has an expires value set to 90 seconds.

Synchronize A-HNT Successful Timer to Standby

Adaptive HNT enables the Oracle Communications Session Border Controller to determine, through testing, an optimum SIP REGISTER expires time interval that keeps the NAT pinhole open. For an HA node, this successful time value is determined through testing by the active system and then replicated to the standby. If there is a switchover during the active system’s testing process, then it will restart for that endpoint.

Adaptive HNT Configuration

You configure the SIP interface to set the state of this feature and to define the increments of time the Oracle Communications Session Border Controller uses to perform adaptive HNT. Remember that the Oracle Communications Session Border Controller uses the time you specify as the NAT interval, the supported time interval, as the basis on which to begin testing.

If you are configuring AHNT for TCP connections, the following sip-interface parameters perform the same functions as the equivalent UDP parameters in the procedure below:

tcp-sip-dynamic-hnt
tcp-max-nat-interval
tcp-nat-int-increment
tcp-nat-test-increment

To configure adaptive HNT:

In Superuser mode, type configure terminal and press Enter.
```
ORACLE# configure terminal
```
Type session-router and press Enter to access the session-router path.
```
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
```
sip-dynamic-hnt—Enable this parameter if you want to use adaptive HNT. The default value is disabled. The valid values are:
- enabled | disabled
  
  Note:
  Updates to sip-dynamic-hnt applies to new registration and when the registration cache is cleared.
max-nat-interval—Set the amount of time in seconds that testing should not exceed. The Oracle Communications Session Border Controller will keep the expires interval at this value. The default value is 3600. The valid range is:
- Minimum—0
- Maximum—4294967295
nat-int-increment—Set the amount of time in seconds to use as the increment in value in the SIP expires header. The default value is 10. The valid range is:
- Minimum—0
- Maximum—4294967295
nat-test-increment—Set the amount of time in seconds that will be added to the test timer. The default value is 30. The valid range is:
- Minimum—0
- Maximum—4294967295