In a SIP network, you often have multiple servers communicating with each other. As soon as you add TCP and TLS to the mix, you will want to reuse connections. Why? Setting up A TLS connection involves a lot of messages going back and forth in the process up validating certificates and coming up with keying material for the encrypted session. Now if you have a re-invite that wants to put a call on hold, you don’t want to loose a lot of packet-roundtrip-times while this happens. A better solution is to keep connections open where possible and allow communication both ways.

RFC 3261 states that if you open a connection with a connection-oriented protocol, like TCP or STCP, the connection should stay open to cover the whole transaction. This means that if the other end sends a message in the dialog, a connection needs to be opened in the other direction. This is of course a problem with NAT between a device and a server, something that the SIP Outbound standard handles. Between servers, like B2bua’s and proxys, the problem still exists. This is managed by the Connection Reuse RFC, RFC 5923.

Mutual TLS authentication opens up for two-way communication

RFC 5923 – SIP Connection reuse – explains how this can work. One requirement is that the TLS connection has mutual connection, which means that the server ask the client for a certificate. The client indicates in the request that it is prepared to receive inbound requests, not only the response to the request, on the same connection. When that happens, the server and client sets up a connection table where the content of the certificates are stored – the domains and host names. Now if one of them has a request that is targeted to the same domain and the same IP and port (after DNS SRV lookups), the connection can be reused.

Checking and caching the certificate content

When the connection is initiated, both ends provide TLS certificates that contain one or multiple names or SIP uri’s. This list is cached and associated with the session. Now, if the same server host multiple domains, you can’t use the connection if the domain that is the target of the request doesn’t match the names in the certificate. In that case, you need to open a new connection to the same server.

Use DNS host names instead of IP addresses

On a related topic, notice that the RFC always use host names and not IP addresses in the Via: headers. This is of course a requirement if you want to match certificates. For TLS to work in all directions, host names should be used in Via: and Record-Route/Route headers. With a GRUU, you can also have a domain in the Contact. This also helps IPv4/IPv6 dual stack handling, letting every path select the optimal connection.

Combined with SIP outbound we have open connections all the way

Connection reuse is an important feature for all SIP servers, B2BUAs like Asterisk and SIP servers like Kamailio. Without it TLS will be hard to use and cause delays that will affect the calls. In combination with SIP Outbound, where the UA manages the connections to the first-hop servers, it is a working solution for TLS over NAT as well. Keeping TCP/TLS connections open like this is not new, Jabber/XMPP has done this from start. It’s just new to SIP.

I think SIP Connection Reuse support should be on the list of requirements when you select your next SIP application server for your Open Unifed Communication platform.