SIP Keepalives: OPTIONS, REGISTER, and CRLF Explained

You’ve configured your VoIP system to use Session Initiation Protocol (SIP) for signaling, but calls still drop after a few minutes of silence. The phone stays registered on the dashboard, yet when you dial out, it rings into the void or fails with a timeout error. This is rarely a codec issue or a bandwidth shortage. It’s usually a broken NAT binding. Your router decided that since no data passed through that specific port for 60 seconds, the connection was dead, so it closed the mapping. When the incoming call arrived, the router had nowhere to send it.

To fix this, you need SIP keepalives. These are periodic signals sent between devices to prove that a communication path is still alive and to reset the idle timers on intermediate firewalls and Network Address Translation (NAT) devices. But not all keepalives are created equal. There are three main mechanisms used in modern VoIP: SIP OPTIONS, a method for querying capabilities and availability, SIP REGISTER refreshes for maintaining location bindings, and CRLF keepalives for TCP-based connections. Choosing the wrong one can waste battery life on mobile devices or flood your server with unnecessary traffic. Let’s break down how each works, when to use them, and why mixing them up causes headaches.

The Problem: Why NAT Kills Silent Calls

NAT exists because we ran out of IPv4 addresses. A router translates private internal IP addresses (like 192.168.1.50) to a single public IP address for the internet. To do this efficiently, it creates temporary mappings-think of them as sticky notes on the firewall-that say "If data comes back to port 5060 from this external IP, send it to the internal phone."

These sticky notes have an expiration date. Most consumer routers clear UDP mappings after 30 to 60 seconds of inactivity. If your SIP phone sends a REGISTER message at 12:00 PM and then sits silent until 12:02 PM, the router wipes the map. An incoming INVITE from the provider arrives at the public IP, hits the closed port, and gets dropped. The phone never knows the call came in.

Keepalives solve this by sending tiny packets before the timer expires. They don’t carry voice or video; they just scream "I’m still here!" to keep the mapping open. The challenge is doing this without overwhelming the network or draining the device’s battery.

SIP OPTIONS: The Application-Layer Probe

SIP OPTIONS is defined in RFC 3261 as a request to discover supported methods, content types, and extensions without ringing the endpoint. In theory, it’s a capability query. You ask, "Do you support G.711? Do you accept REFER requests?" The other side replies with a list of what it can do.

In practice, VoIP administrators repurpose OPTIONS as a "qualify" mechanism. Systems like Asterisk use it to check if a peer is actually reachable. When Asterisk sends an OPTIONS request, it expects a 200 OK response within a set time (often 3 seconds). If it gets a reply, it marks the peer as "available" and records the Round-Trip Time (RTT). If it times out, it marks the peer as "unavailable" and stops trying to route calls there.

This approach has distinct advantages. Because OPTIONS is a full SIP transaction, it proves that the application layer is responsive. It’s not just checking if the port is open; it’s checking if the software behind the port is awake and functioning. It also works over any transport: UDP, TCP, or TLS.

However, OPTIONS is heavy. It involves parsing headers, potentially handling authentication challenges (401 Unauthorized), and generating complex SDP bodies. For a large PBX managing thousands of endpoints, sending OPTIONS every 60 seconds generates significant CPU load. Furthermore, some aggressive firewalls might block OPTIONS if they don’t recognize it as part of an active dialog, leading to false negatives where a healthy phone is marked offline.

SIP REGISTER Refreshes: Maintaining the Binding

SIP REGISTER is the primary method for creating and maintaining address bindings between a user’s address-of-record and their current Contact address. Unlike OPTIONS, which checks health, REGISTER updates the directory. When you register, you tell the registrar, "Send my calls to this IP and port."

Registrations are soft state. They expire unless refreshed. If your registration interval is set to 3600 seconds (one hour), you must send a new REGISTER before that hour ends. This refresh serves double duty: it keeps the registrar’s database current and resets the NAT timer on your local router.

Using REGISTER as your sole keepalive strategy is common in simple deployments. It’s efficient because you’re already sending these messages anyway. However, relying solely on long intervals (like 1 hour) is risky for NAT traversal. If your NAT timeout is 30 seconds, a 1-hour registration leaves a massive window where the mapping could drop. You’d need to shorten the registration interval significantly-perhaps to 30-60 seconds-to keep the NAT alive. This increases signaling overhead and battery consumption on mobile clients.

Also, REGISTER is expensive. It often requires digest authentication, which means hashing credentials and verifying signatures. Doing this every 30 seconds is wasteful compared to a lightweight ping. Best practice suggests keeping registration intervals reasonable (e.g., 300-3600 seconds) and using a separate, lighter keepalive mechanism for NAT maintenance.

CRLF Keepalives: The Lightweight TCP Solution

If you’re running SIP over TCP or TLS, CRLF keepalives are the most efficient option defined in RFC 5626. CRLF stands for Carriage Return Line Feed. The client sends two consecutive CRLF sequences (`\r\n\r\n`) to the server. The server responds with a single CRLF (`\r\n`). That’s it. No headers, no body, no parsing overhead.

This mechanism is strictly for connection-oriented transports. You cannot use CRLF over UDP because UDP is connectionless; there’s no persistent stream to inject bytes into. For UDP, you’d need STUN keepalives, which are more complex. CRLF is ideal for TCP because it tests the integrity of the existing connection. If the TCP stack has silently dropped the connection (a common issue with firewalls that forget state), the CRLF will fail to transmit or receive a pong, alerting the client to reconnect immediately.

RFC 5626 specifies strict timing rules. The client must treat the flow as failed if no pong arrives within 10 seconds of sending a ping. The interval between pings should be randomized between 80% and 100% of the server’s recommended Flow-Timer. If no Flow-Timer is provided, the default recommendation is a random interval between 95 and 120 seconds for non-battery devices. This randomness prevents synchronized bursts of traffic if hundreds of phones reboot at the same time.

Negotiating Keepalives with RFC 6223

How does a phone know if the server supports CRLF? Enter RFC 6223. This specification adds a `keep` parameter to the Via header. During the initial REGISTER exchange, the client includes `Via: ... ;keep`. If the server supports CRLF keepalives, it responds with `Via: ... ;keep=120`, indicating it wants keepalives every 120 seconds.

This negotiation is crucial for interoperability. Without it, a client might send CRLF bytes to a legacy server that doesn’t understand them, causing the server to reject the malformed input or close the connection. By negotiating first, both sides agree on the frequency and format of the keepalives. Oracle SBCs and many modern softswitches implement this standard, allowing dynamic adjustment based on network conditions.

Choosing the Right Mechanism

Selecting the right keepalive depends on your transport protocol, device type, and network topology. Here’s a quick decision guide:

For **mobile users** on LTE or Wi-Fi, battery life is king. Use CRLF if you’re on TCP/TLS. If you’re stuck on UDP, use STUN keepalives with intervals around 24-29 seconds (to beat typical 30-second NAT timeouts). Avoid frequent OPTIONS probes on mobile apps unless necessary for quality monitoring.

For **hardphones** plugged into office networks, power isn’t an issue. You can afford OPTIONS every 60 seconds to get detailed reachability data. However, ensure your firewall allows OPTIONS traffic. Some corporate security policies block unsolicited SIP requests.

For **cloud providers**, scalability matters. Sending OPTIONS to 10,000 users every minute creates 10,000 transactions per minute. CRLF or STUN is vastly superior here because the server can handle millions of tiny pings with minimal CPU cost compared to parsing full SIP messages.

Common Pitfalls and Troubleshooting

One major mistake is setting the keepalive interval too short. If your NAT timeout is 60 seconds, sending a keepalive every 10 seconds wastes bandwidth. Send it every 45-50 seconds instead. Another trap is ignoring the difference between UDP and TCP. Enabling CRLF on a UDP transport does nothing; the packet is just ignored or rejected. Always verify your transport type first.

False positives are another headache. A phone might respond to OPTIONS but fail to process an INVITE because its media stack is hung. Conversely, a phone might ignore OPTIONS due to a bug but successfully handle calls. Don’t rely solely on OPTIONS status for critical routing decisions. Combine it with actual call success rates if possible.

Finally, watch out for asymmetric routing. If your outbound traffic goes through Firewall A but inbound returns via Firewall B, keepalives sent to A won’t keep the mapping on B open. This requires symmetric routing configuration or specific firewall stateful inspection settings.