Endpoint-Initiated Keep-Alives

The Oracle Communications Session Border Controller provides three Keep-Alive algorithms designed to generate sufficient traffic flow to maintain NAT (Network Address Translation) bindings. Prior releases provided a single Keep-Alive algorithm that is described in the SIP Hosted NAT Traversal (HNT) section of the SIP Signaling Services chapter of the ACLI Configuration Guide. This method is SD-based and requires no explicit participation by the SIP endpoint. Instead the SD manipulates SIP registration requests and responses to spoof the endpoint — generating frequent and extraneous registration requests that generate a periodic traffic flow to maintain existing NAT bindings.

Unlike the current SD-centric method, the new methods require the active participation of the SIP endpoint. With these methods the SIP endpoint initiates a Keep-Alive negotiation with the SD that produces a periodic request/response message sequence which also generates sufficient traffic flow to maintain NAT bindings.

The new methods are based upon the following RFCs.

RFC 5626, Managing Client-Initiated Connections in the Session Initiation Protocol (SIP), which, in Section 3.5.2, provides a framework for the implementation of an endpoint-initiated Keep-Alive on both TCP and UDP connections and provides two approaches to generating endpoint-initiated Keep-Alive traffic flows. One approach described in Section 4.4.1 of the RFC is restricted to connection-oriented transport protocols such as TCP. It defines an end-point initiated ping which requires an SD pong in response. A second approach described in Section 4.4.2 of the RFC is restricted to connectionless transport protocols such as UDP. It defines an endpoint-initiated STUN binding request which requires as SD-originated STUN binding response.

RFC 6223, Indication of support for Keep-Alive, was initially published as an internet draft (most recently as draft-ietf-sipcore-keep-12.txt). RFC 6223 defines a procedure that enables a SIP endpoint to signal its capability and willingness to send and receive periodic Keep-Alive messages to a device referred to by the RFC as an edge proxy, a role performed by the SD. After receiving such a signal, the SD returns a response indicating its willingness to exchange Keep-Alives, and specifying the interval between Keep-Alive exchanges.

RFC 5389, Session Traversal Utilities for NAT (STUN), defines STUN binding requests and responses in Section 6 of the RFC. Endpoints that support endpoint-initiated Keep-Alives over a UDP connection must be capable of constructing and transmitting a STUN binding request, and receiving and parsing a STUN binding response.