Keep-Alive with CR LF 2832
Release S-CX6.3F1 provides an alternative NAT (Network Address Translator) Traversal method. The current method is SBC-based and requires no explicit participation by the SIP endpoint. Rather the SBC manipulates SIP registration requests and responses to the endpoint — causing it to issue frequent and extraneous registration requests thus maintaining existing NAT bindings.
The alternative method is based upon RFC 5626, Managing Client-Initiated Connections in the Session Initiation Protocol (SIP), and RFC 6223. Unlike the current SBC-centric method, the new alternative requires the active participation of the SIP endpoint. With this method the SIP endpoint and the SBC negotiate a request / response message sequence which generates sufficient traffic flow to maintain NAT bindings.
Section 3.5.2 of RFC 5626 defines a keep-alive method for connectionless UDP flows, but provides no guidance for keep-alive negotiation. The Indication of Support for Keep-Alive internet draft addresses this deficiency by defining 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 SBC. After receiving such a signal, the SBC returns a response indicating its willingness to exchange keep-alives, and specifying the frequency of the exchange.
SIP endpoints that initiate and participate in the keep-alive exchanges described in this section must support a minimal sub-set of client operations. Specifically, endpoints must be able to construct and transmit CR/LF binding requests, and receive and parse CR/LF binding responses.Binding request and response formats are described in Section 6 of RFC 5626.
As shown in the following SIP Registration request, the SIP endpoint, functioning as a CR/LF client, signals its willingness to exchange keep-alive messages by placing an unvalued keep parameter, newly-defined by the [RFC] 6223 in the SIP Via header. The expires parameter in the Contact header requests a registration period of 5 hours (18000 seconds).
REGISTER sip:512@172.16.101.23:5060 SIP/2.0
Via: SIP/2.0/UDP 172.16.101.38:5070;branch=dd1;keep
From: "512" <sip:512@172.16.101.38:5070;transport=UDP>;tag=443322
To: "512" <sip:512@172.16.101.38:5070>
Call-ID:1-14400@172.16.101.38
CSeq: 1 REGISTER
Max-Forwards: 70
User-Agent: ADTRAN_Total_Access_908e_(2nd_Gen)/A1.02.00.E
Content-Length: 0The SBC forwards the Registration request (absent the keep parameter) to the Registrar.
REGISTER sip:512@192.168.7.32:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.101.23:5060;branch=z9hG4bK3q43klh3dafekdepnbaqip04e1
From: "512" <sip:512@172.16.101.38:5070;transport=UDP>;tag=443322
To: "512" <sip:512@172.16.101.38:5070>
Call-ID: 1-14400@172.16.101.38
CSeq: 1 REGISTER
Max-Forwards: 69
Contact: "512" <sip:512@192.168.101.23:5060;transport=udp>;expires:18000
User-Agent: ADTRAN_Total_Access_908e_(2nd_Gen)/A1.02.00.E
Content-Length: 0
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFERThe Registrar indicates successful registration with a 200 OK response back to the SBC. The expires parameter in the Contact header grants a registration period of 1 hour (3600 seconds).
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.101.23:5060;branch=z9hG4bK3q43klh3dafekdepnbaqip04e1
From: "512" <sip:512@172.16.101.38:5070;transport=UDP>;tag=443322
To: "512" <sip:512@172.16.101.38:5070>;tag=b68b3d53a5a90225609112ff6c211bef.16a6
Call-ID: 1-14400@172.16.101.38
CSeq: 1 REGISTER
Contact: <sip:512@192.168.101.23:5060;transport=udp>;expires=3600
Server: OpenSER (1.3.0-notls (i386/linux))
Content-Length: 0The SBC, forwards the 200 OK to the endpoint after inserting a keep parameter and a parameter value in the Via header of the Registration response. The presence of the keep parameter signals the SBC’s willingness to exchange keep-alives, and the parameter value specifies the exchange frequency in seconds.
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.16.101.38:5070;branch=dd1;keep=20
From: "512" <sip:512@172.16.101.38:5070;transport=UDP>;tag=443322
To: "512" <sip:512@172.16.101.38:5070>;tag=b68b3d53a5a90225609112ff6c211bef.16a6
Call-ID: 1-14400@172.16.101.38
CSeq: 1 REGISTER
Contact: <sip:512@172.16.101.38:5070>;expires=3600
Server: OpenSER (1.3.0-notls (i386/linux))
Content-Length: 0After the keep-alive exchange has been negotiated, the SIP endpoint, acting as a CR/LF client, is required to transmit a periodic CR/LF so that the interval between each request is randomly distributed between 80 and 100 percent of the value of the keep parameter. Assuming a parameter value of 20 seconds, for example, the SIP endpoint transmits a CR/LF at random intervals between 16 and 20 seconds in length.
Upon receipt of a Ping, the SBC, transmits a Pong. Receipt of the Pong by the endpoint confirms the TCP connection between the endpoint and the SBC, and the viability of NAT bindings in the transmission path.
Once initiated, endpoint transmission of CR/LF Ping and SBC responses continue for the duration of the SIP Registration, 1 hour in the above example, or until the endpoint transmits a new Registration request. In the event of such a request, the endpoint must once again indicate its willingness to exchange CR/LF keep-alives with an unvalued keep parameter in the Via header. If keep-alive renegotiation is not successful, the endpoint must cease the transmission of keep-alive messages.
An endpoint failure to issue a timely CR/LF Ping is not fatal. In the absence of an expected request, the SBC takes no action with regard to the TCP connection, or to established sessions.