Connection Reuse in the Session Initiation Protocol (SIP)
Extracted elements (25)
Connection reuse is restricted to TLS (over TCP or SCTP) because TLS mutual certificate exchange authoritatively establishes the identities of both communicating parties. Plain TCP and SCTP connections carry no such guarantee, leaving them vulnerable to inadvertent or malicious connection hijacking when reused in the backwards direction.
Opening a new TLS connection requires a TCP three-way handshake, multiple round trips for TLS negotiation, expensive asymmetric cryptography, and certificate verification. Reusing an existing connection for requests in both directions avoids this overhead, preventing CPU saturation and reducing latency for subsequent in-dialog requests such as re-INVITE and BYE.
Connection reuse interacts with DNS SRV load balancing: over time a proxy will maintain a distinct aliased connection to each SRV-selected server (e.g., S1, S2, S3). Once established, subsequent traffic continues to be distributed across the downstream servers in the normal SRV manner.
Connection reuse is strictly hop-by-hop between adjacent SIP entities; there is no requirement to share a complete path. The mechanism complements but does not replace RFC 3261 persistent connection behavior, which governs reuse of a connection for responses and subsequent requests by the original connection initiator.
Servers that do not support or choose not to honor the "alias" Via parameter MUST treat the request as a normal RFC 3261 request, ensuring that a client can include the "alias" parameter without risk that the server will reject the SIP request because of its presence.
A client reuses an aliased connection only if (1) RFC 3263 resolution on a URI yields a resolved address already in the alias table, AND (2) the URI used for resolution matches one of the cached identities in the corresponding alias table row. Both conditions must hold simultaneously.
A proxy hosting multiple virtual domains MUST NOT open a connection on behalf of one domain and reuse it to send a new request on behalf of another domain. Separate alias tables (or equivalent bookkeeping) SHOULD be maintained per virtual domain to preserve the boundary between domains.
A TLS server conformant to this specification MUST request a client certificate (mutual TLS). If the client does not present a certificate, the server MUST proceed as if the "alias" parameter was not present and MUST NOT update the alias table.
Before closing a TLS connection, the initiating party MUST either wait for any outstanding SIP transactions to complete or explicitly abandon them. After sending a TLS closure alert, it MUST discard TLS messages until receiving the peer's closure alert. The receiver of a closure alert MUST NOT start any new SIP transactions.
Before forming an alias, a client MUST authenticate the TLS connection per RFC 5922 Section 7.1, then MUST cache the server's identity (or identities) from the X.509 certificate, the server's resolved IP/port/transport from RFC 3263 server resolution, and the connection handle in the alias table.
Clients MUST be prepared for the case that a previously aliased connection no longer exists; in such a case, a new connection MUST be opened to the resolved address and the alias table updated. For CANCEL or ACK-to-non-2xx sent after the connection closed, the client SHOULD open a new connection and MAY insert it into the alias table.
Clients MUST NOT assume that a server's acceptance of a request automatically enables connection aliasing, and MUST continue receiving requests on their default port regardless of whether the server created an alias.
Clients SHOULD keep connections up as long as they are needed and SHOULD NOT automatically drop connections on completion of a transaction or termination of a dialog, because connection reuse works best when long-lived connections are maintained.
If a client places an "alias" parameter in the topmost Via header of a request, it MUST accept requests over that connection — in addition to its default listening port — from its downstream peer, and SHOULD keep the connection open for as long as operating-system resources allow.
If a server chooses not to honor an aliased connection, it MUST allow the request to proceed as though the "alias" Via parameter was not present, ensuring backwards compatibility with RFC 3261 behavior.
If the sent-by production of the Via header field contains a port, the server MUST use it as the destination port for the aliased connection; otherwise the default port (5061) is used.
Servers SHOULD keep connections up unless they need to reclaim resources and SHOULD NOT automatically drop connections on completion of a transaction or termination of a dialog.
Virtual servers MUST only perform connection reuse for TLS connections; they MUST NOT perform connection reuse for other connection-oriented transports such as plain TCP or SCTP, because only TLS ties an authenticated identity to a specific connection.
The "alias" Via header field parameter is introduced to signal that the client wants to create a transport-layer alias — i.e., that the server may reuse the existing connection to send requests back toward the client. Its ABNF is: via-params =/ via-alias; via-alias = "alias".
The connection alias table is a conceptual data structure maintained by each SIP entity that stores, per aliased connection: destination IP address, destination port, destination transport, destination identity (from the peer's X.509 subjectAlternativeName), and a connection handle (alias descriptor). It is used to look up an existing connection before opening a new one.
This specification registers a new Via header field parameter named "alias" in the IANA "Header Field Parameters and Parameter Values" sub-registry (created by RFC 3968). The entry is: Header Field = Via, Parameter Name = alias, Predefined Values = No, Reference = RFC 5923.
Unauthenticated connection reuse would allow rampant abuse and hijacking — for example, a malicious program on a multiuser system could hijack SIP requests destined for the well-known SIP port from a large relay proxy. Authenticating connection aliases via TLS mutual certificate exchange is essential to prevent this.
When a virtual server hosts multiple SIP domains on the same IP address and port, a cached aliased connection authenticated for domain A MUST NOT be reused for requests destined to domain B, even if RFC 3263 resolution for domain B resolves to the same IP/port tuple. The "Destination Identity" column in the alias table enforces this per-domain isolation.
Client alias formation: (1) perform RFC 3263 resolution on next-hop URI; (2) if no existing alias matches, open TLS connection and authenticate peer certificate per RFC 5922; (3) populate alias table with {IP, port, transport, identity, descriptor}; (4) for subsequent requests, reuse the connection if RFC 3263 resolution yields a matching alias table row AND the URI matches a cached identity; (5) if connection is gone, open a new one and update table.
Server alias formation: on receipt of a request with "alias" in the topmost Via, (1) authenticate the client certificate per RFC 5922 Section 7.4; (2) if client presented no certificate, treat as if "alias" not present and do not update alias table; (3) otherwise cache client identities, populate {IP from "received" param, port from Via sent-by or 5061 default, transport, descriptor} in alias table; (4) reuse the connection for subsequent outbound requests when both RFC 3263 resolved address and URI identity match the cached row.