SIP User's Manual  382  Document #: LTRT-65415 
 MediaPack Series 
 
Parameter  Description 
[UsePingPongKeepAlive] 
Determines whether the carriage-return and line-feed 
sequences (CRLF) Keep-Alive mechanism, according to RFC 
5626 “Managing Client-Initiated Connections in the Session 
Initiation Protocol (SIP)” is used for reliable, connection-
orientated transport types such as TCP. 
  [0] Disable (default) 
  [1] Enable 
The SIP user agent/client (i.e., device) uses a simple periodic 
message as a keep-alive mechanism to keep their flow to the 
proxy or registrar alive (used for example, to keep NAT 
bindings open). For connection-oriented transports such as 
TCP/TLS this is based on CRLF. This mechanism uses a 
client-to-server "ping" keep-alive and a corresponding server-
to-client "pong" message. This ping-pong sequence allows the 
client, and optionally the server, to tell if its flow is still active 
and useful for SIP traffic. If the client does not receive a pong 
in response to its ping, it declares the flow “dead” and opens a 
new flow in its place. In the CRLF Keep-Alive mechanism the 
client periodically (defined by the PingPongKeepAliveTime 
parameter) sends a double-CRLF (the "ping") then waits to 
receive a single CRLF (the "pong"). If the client does not 
receive a "pong" within an appropriate amount of time, it 
considers the flow failed. 
Note: The device sends a CRLF message to the Proxy Set 
only if the Proxy Keep-Alive feature (EnableProxyKeepAlive 
parameter) is enabled and its transport type is set to TCP or 
TLS. The device first sends a SIP OPTION message to 
establish the TCP/TLS connection and if it receives any SIP 
response, it continues sending the CRLF keep-alive 
sequences. 
[PingPongKeepAliveTime] 
Defines the periodic interval (in seconds) after which a “ping” 
(double-CRLF) keep-alive is sent to a proxy/registrar, using the 
CRLF Keep-Alive mechanism. 
The default range is 5 to 2,000,000. The default is 120. 
The device uses the range of 80-100% of this user-defined 
value as the actual interval. For example, if the parameter 
value is set to 200 sec, the interval used is any random time 
between 160 to 200 seconds. This prevents an “avalanche” of 
keep-alive by multiple SIP UAs to a specific server.