SIP Outbound Framework (RFC 5626): Maintaining Persistent Connections Across NAT and Firewalls

Overview

Key takeaways

• RFC 5626 enables SIP User Agents behind NATs to establish persistent, bidirectional flows to Edge Proxies.
• Uses unique +sip.instance URNs and reg-id parameters to uniquely identify physical devices and individual transport flows.
• Eliminates binding timeouts by mandating active client-initiated keep-alive mechanisms (STUN binding requests or CRLF keep-alives).
• Flow tokens allow Edge Proxies to route incoming requests directly back over existing outbound transport sockets.
• Supports multi-homed, redundant registrations to multiple Edge Proxies for high availability.

Prerequisites

• Fundamental understanding of SIP registration workflows and RFC 3261 transaction rules.
• Basic knowledge of Network Address Translation (NAT) and stateful firewall behavior.
• Familiarity with standard SIP headers including Contact, Via, Path, and Route.

Guide

1. section #1

   The NAT Traversal Challenge in Standard SIP Under standard RFC 3261 rules, a SIP User Agent (UA) behind a Network Address Translation (NAT) device includes its private IP address in the Contact header during registration. While the Registrar can learn the public IP and port from which the REGISTER packet arrived (often using symmetric response routing or rport), traditional SIP provides no standardized mechanism to guarantee that an incoming invite can reach the UA later. NAT bindings and stateful firewall pinholes expire quickly—often in 30 to 60 seconds for UDP. If a UA re-registers, it may open a new public port binding, leaving the previous path orphaned and rendering incoming calls unreachable.

2. section #2

   Core Identifiers: +sip.instance and reg-id RFC 5626 introduces two essential URI parameters attached to the Contact header: '+sip.instance' and 'reg-id'. The '+sip.instance' parameter contains a Universally Unique Identifier (UUID) formatted as a URN that persistently identifies the specific physical device. The 'reg-id' parameter is a numeric value representing a specific network flow from that device to a given Edge Proxy. By combining these parameters, the Registrar can differentiate between a client establishing a secondary backup connection, a client re-establishing a lost flow, and a completely different physical device registering to the same Address of Record (AOR).

   sipcopy

   REGISTER sip:example.com SIP/2.0
   Via: SIP/2.0/TLS 192.168.1.50:5061;branch=z9hG4bK-73921
   From: <sip:alice@example.com>;tag=a1b2c3
   To: <sip:alice@example.com>
   Call-ID: 849201948@192.168.1.50
   CSeq: 1 REGISTER
   Supported: outbound, path
   Contact: <sip:alice@192.168.1.50:5061;transport=tls>
     ;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
     ;reg-id=1
   Expires: 3600
   Content-Length: 0

3. section #3

   Establishing Flows and Flow Token Routing When an outbound-compliant UA sends a REGISTER request to an Edge Proxy, the Edge Proxy inspects the incoming physical socket (IP, port, and transport protocol). The Edge Proxy generates an opaque, encrypted, or signed string known as a 'flow token' that identifies this active connection. The Edge Proxy appends this flow token to a Path header field and forwards the request to the core Registrar. When a call arrives for the user, the Registrar includes the saved Path header containing the flow token in its route set. Upon receiving the INVITE, the Edge Proxy extracts the flow token, maps it back to the active TCP/TLS connection or NAT-mapped UDP socket, and forwards the request down that exact socket.

   sipcopy

   Path: <sip:edge01.example.net;lr;ob;received="sip:203.0.113.45:51294;transport=tls">
   Via: SIP/2.0/TLS 203.0.113.45:51294;branch=z9hG4bK-ep-flow-99a8f

4. section #4

   Proactive Flow Keep-Alive Mechanisms To prevent NAT bindings and firewall pinholes from expiring, RFC 5626 mandates active client-initiated keep-alive traffic over every established flow. The framework defines two distinct keep-alive protocols depending on transport layer type. For connection-oriented transports such as TCP and TLS, the UA sends a double CRLF sequence (\r\n\r\n) over the existing socket; the Edge Proxy responds with a single CRLF (\r\n). For connectionless transports like UDP, the UA sends STUN (Session Traversal Utilities for NAT) Binding Requests multiplexed over the same port used for SIP signaling, and the Edge Proxy replies with a STUN Binding Response.

   textcopy

   Client -> Edge Proxy (TCP/TLS Keep-Alive):
   \r\n\r\n
   
   Edge Proxy -> Client Response:
   \r\n

5. section #5

   Redundancy and High Availability via Dual Flows RFC 5626 natively supports high availability and failover by allowing a UA to maintain active registrations over multiple separate flows simultaneously. A single UA can send two REGISTER requests with identical '+sip.instance' parameters but different 'reg-id' values (e.g., reg-id=1 to Edge Proxy A and reg-id=2 to Edge Proxy B). The Registrar records both active paths. If Edge Proxy A experiences a system or network outage, the Registrar automatically routes incoming traffic to the flow associated with reg-id=2 without requiring the UA to re-register or wait for registration timeout intervals.

   sipcopy

   /* Registration to Secondary Edge Proxy */
   REGISTER sip:example.com SIP/2.0
   Via: SIP/2.0/TLS 192.168.1.50:5061;branch=z9hG4bK-73922
   From: <sip:alice@example.com>;tag=a1b2c3
   To: <sip:alice@example.com>
   Call-ID: 849201948@192.168.1.50
   CSeq: 2 REGISTER
   Supported: outbound, path
   Contact: <sip:alice@192.168.1.50:5061;transport=tls>
     ;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
     ;reg-id=2
   Expires: 3600

6. section #6

   Architectural Considerations for SBCs and Registrars Implementing RFC 5626 requires synchronized capabilities across Edge Proxies (or Session Border Controllers) and core Registrars. SBCs must act as Outbound Edge Proxies by advertising the 'outbound' option tag in Supported/Require headers and handling flow token generation. Furthermore, SBCs must be configured to process CRLF keep-alives and STUN packets without passing them to the core network. Core Registrars must support RFC 5627 (GRUUs) and RFC 3327 (Path header) to store flow tokens accurately and deliver inbound requests back to the appropriate Edge Proxy path.

Further reading

• RFC 5626 - Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)
• RFC 5627 - Obtaining and Using Globally Routable User Agent URIs (GRUUs) in SIP
• RFC 3327 - Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts (Path Header)