SIP over UDP, TCP and TLS: Key Differences

SIP messages can travel over three common transports. UDP sends each message as a separate datagram with no delivery guarantee and no encryption. TCP opens a connection and delivers messages reliably and in order, still without encryption. TLS runs the same SIP messages over a TCP connection wrapped in Transport Layer Security, so the signalling is encrypted and the server is authenticated by certificate. The SIP messages themselves are identical in all three cases. What changes is reliability, behaviour through NAT, handling of large messages and privacy. Note that none of these encrypt the audio. That requires SRTP.

Why does SIP support more than one transport?

RFC 3261 requires every SIP element to implement both UDP and TCP. It also requires proxies, registrars and redirect servers to implement TLS, and strongly recommends that user agents can open TLS connections. The designers wanted SIP to work on simple embedded devices where UDP was cheap, and on networks where connection-oriented transports made more sense. The Via header records the transport used for each hop, for example Via: SIP/2.0/UDP ... or Via: SIP/2.0/TLS ..., so proxies and endpoints know how to route responses back.

How does SIP over UDP behave?

UDP is the historical default for SIP and still the most common on local networks and older PBXs. Each SIP message is a single UDP datagram sent to port 5060 by default.

Advantages:

• No connection setup. The first REGISTER goes out immediately.
• Low overhead on the server, which does not hold open connections for thousands of phones.
• Simple to debug with a packet capture.

Disadvantages:

• No delivery guarantee. SIP compensates with its own retransmission timers, but lost messages still cause delays of 500 milliseconds or more before a retry.
• No encryption. Anyone on the network path can read the messages, including who is calling whom and the digest authentication exchange.
• NAT problems. Home routers keep UDP mappings for a short time, often 30 to 120 seconds. If the client does not register or send keepalives often enough, the mapping closes and incoming calls cannot reach it.
• Message size. A SIP INVITE with a long SDP body can exceed the typical 1500-byte path MTU. RFC 3261 requires a request to move to a congestion-controlled transport such as TCP when it is within 200 bytes of the path MTU, or larger than 1300 bytes when the MTU is unknown. Not every implementation does this correctly.

How does SIP over TCP behave?

With TCP the client opens a connection to the server, by default on port 5060, and sends all its SIP messages over that connection. The connection stays open as long as the client is registered.

Advantages:

• Reliable, in-order delivery. No SIP-level retransmissions are needed, so there are fewer stalls.
• Large messages are not a problem.
• NAT friendly. The server can send incoming requests back down the connection the client opened, so the client's private address in the Contact header matters less. RFC 5626 describes this formally, and many servers do it in practice even without full RFC 5626 support.
• TCP keepalives, or occasional CRLF keepalives from the client, maintain the NAT mapping.

Disadvantages:

• Still unencrypted. The content is as readable as over UDP.
• A dropped connection must be detected and re-established. A client that does not notice a dead connection will believe it is registered while it is not.
• Slightly more server resources per client.

How does SIP over TLS behave?

TLS wraps the TCP connection in encryption and authentication. Its current version is 1.3, defined in RFC 8446, although many SIP servers still use TLS 1.2. SIP over TLS uses port 5061 by default. The client connects, performs a TLS handshake, verifies the server's certificate, and then sends ordinary SIP messages inside the encrypted channel.

Advantages:

• Confidentiality. Nobody between the client and the server can read the signalling, including the From and To headers, the Call-ID and the SDP body with its media addresses and SRTP keys.
• Integrity. Messages cannot be altered in transit without detection.
• Server authentication. The certificate proves the client is talking to the real server, not an impostor.
• All the NAT and reliability benefits of TCP.

Disadvantages:

• The server needs a certificate. Clients verify that the certificate is issued by a trusted certificate authority and that the name matches the host they connected to. Self-signed certificates fail this check in strict clients. SIPdia, for example, requires a certificate from a public CA and rejects self-signed ones; for a PBX without such a certificate, UDP or TCP over a VPN is the alternative.
• Some networks block port 5061 outbound. If the client cannot reach the server over TLS, check the firewall before assuming a configuration mistake.
• TLS secures only the hop between the client and the server. If the server forwards the call to a trunk over UDP, that leg is unprotected.

What is the difference between sip: and sips:?

A sips: URI, defined in RFC 3261 and clarified in RFC 5630, requests that TLS be used on every hop to the target. A sip: URI sent over a TLS transport protects only the first hop. In practice, most softphones expose a transport setting rather than asking the user to type sips:. Setting the transport to TLS protects the connection to your own server, which is the hop you control. End-to-end sips: depends on every server along the path, and few deployments achieve it.

Does TLS encrypt the call audio?

No. This is the most common misunderstanding. TLS protects SIP signalling. The voice travels in RTP packets, normally over UDP, on ports negotiated in the SDP. Those packets are unencrypted unless both sides use SRTP. The usual arrangement is TLS for signalling plus SRTP for media, with the SRTP keys exchanged inside the TLS-protected INVITE and 200 OK. Using SRTP without TLS is weak when the keys are exchanged with SDES, the most common method in SIP, because they would then be sent in plain text. See What is SRTP? for how the two fit together.

Which transport should you choose?

Situation	Recommended transport
Softphone on the internet, server has a public CA certificate	TLS, with SRTP for audio
Softphone on the internet, server has no valid certificate	TCP or UDP inside a VPN
Office LAN, trusted network, older PBX	UDP, or TCP if NAT or large messages cause trouble
Mobile data with frequent network changes	TLS or TCP, so the connection reuse helps with NAT
Provider documentation names a specific transport	Follow the provider

Always match what the server actually listens on. A server configured only for UDP 5060 will not respond to a TLS connection on 5061, and the client will report that it could not reach the server. Common SIP ports lists the defaults.

Next steps

See how transport and encryption options appear in a softphone on the TLS and SRTP feature page. To complete the security picture, read What is SRTP and how does it protect voice traffic?. For what happens on the connection once it opens, see SIP registration explained.