Transport Protocols

The transport protocol determines how SIP signaling messages are delivered between your test endpoints and the registrar. Choosing the correct protocol is critical for successful registration and call setup. This guide covers every available option, when to use it, and how to troubleshoot transport-related issues.

Available Protocols

CallMeter supports five transport options for SIP signaling:

UDP -- User Datagram Protocol

UDP is the most widely used transport for SIP signaling. It is connectionless, fast, and supported by virtually every SIP implementation.

How it works:

• Each SIP message is sent as an independent UDP datagram
• No connection setup or teardown overhead
• The SIP transaction layer (not the transport) handles retransmissions for reliability
• Message ordering is not guaranteed at the transport level

Advantages:

• Lowest latency -- no connection handshake
• Minimal resource usage on both client and server
• Universal compatibility with SIP infrastructure
• Best for high-volume testing where speed matters

Limitations:

• Messages larger than the network MTU (typically around 1400 bytes) may be fragmented or lost
• No delivery guarantee -- reliability depends on SIP-level retransmission timers
• No encryption -- SIP headers (including authentication) are visible on the network
• NAT traversal can be problematic without proper keep-alive mechanisms

When to use UDP:

• Testing legacy SIP infrastructure that only supports UDP
• High-volume load tests where connection overhead must be minimized
• When latency is the primary concern
• When your SIP server's firewall is configured for UDP

TCP -- Transmission Control Protocol

TCP provides reliable, ordered delivery for SIP messages over a persistent connection.

How it works:

• A TCP connection is established before any SIP messages are sent
• All SIP messages flow over the same connection
• The transport layer guarantees delivery and ordering
• Connection failures are detected immediately

Advantages:

• Handles large SIP messages (long SDP bodies, many Via headers) without fragmentation
• Immediate detection of connection loss
• More reliable through firewalls and NAT devices (persistent connection)
• No SIP-level retransmission needed -- TCP handles it

Limitations:

• Connection setup adds latency (TCP three-way handshake)
• Higher resource usage -- one TCP connection per endpoint
• Not encrypted -- credentials are still visible on the network
• Head-of-line blocking can delay messages if the network is congested

When to use TCP:

• When your SIP messages exceed the UDP MTU (common with complex SDP or many headers)
• When testing TCP-only SIP servers
• When firewalls block UDP traffic
• When you need reliable transport without encryption

TLS -- Transport Layer Security

TLS encrypts the SIP signaling channel by running SIP over a TLS-secured TCP connection (sometimes called SIPS or SIP over TLS).

How it works:

• A TCP connection is established first
• TLS handshake negotiates encryption parameters and verifies server identity
• All subsequent SIP messages are encrypted end-to-end
• Server certificate is validated against trusted certificate authorities

Advantages:

• All SIP signaling is encrypted -- credentials, headers, and SDP are protected
• Server identity verification prevents man-in-the-middle attacks
• Meets enterprise security and compliance requirements (PCI-DSS, HIPAA)
• Same reliability benefits as TCP

Limitations:

• Higher latency due to TLS handshake on top of TCP handshake
• Higher CPU usage for encryption/decryption, especially at scale
• Requires the SIP server to have a valid TLS certificate
• Self-signed certificates may cause connection failures unless explicitly trusted

When to use TLS:

• Production environment testing where security is required
• Compliance-driven testing (financial, healthcare, government)
• When testing SIP servers that require encrypted signaling
• When SIP credentials must be protected in transit

WSS -- WebSocket Secure

WSS transports SIP messages over a WebSocket connection secured with TLS. This is primarily used for WebRTC-compatible SIP infrastructure.

How it works:

• An HTTPS WebSocket connection is established
• SIP messages are framed within WebSocket frames
• The connection runs over standard HTTPS port 443
• Full TLS encryption applies

Advantages:

• Traverses firewalls and proxies that only allow HTTPS traffic
• Compatible with WebRTC SIP gateways and softphones
• Uses standard HTTPS port 443, avoiding non-standard port restrictions
• Full encryption by default

Limitations:

• WebSocket framing adds overhead compared to raw TCP/TLS
• Not all SIP servers support WSS natively
• Requires a WebSocket-capable SIP proxy or gateway
• Higher latency than UDP or TCP

When to use WSS:

• Testing WebRTC-based SIP systems
• When your SIP server only exposes a WebSocket interface
• When network policies restrict traffic to port 443 only
• Testing browser-based VoIP applications

AUTO -- DNS-Based Discovery (RFC 3263)

AUTO mode uses the DNS-based server discovery procedure defined in RFC 3263 to automatically determine the correct transport protocol, server address, and port.

How it works:

The discovery follows a three-step process:

1. NAPTR query on the registrar domain -- returns service records indicating available transports and their priorities
2. SRV query for the selected service -- returns the hostname and port of the SIP server
3. A/AAAA fallback -- if no NAPTR or SRV records exist, resolves the domain directly and falls back to UDP on port 5060

Example DNS records for sip.example.com:

; NAPTR records - indicate available services
sip.example.com.  NAPTR  10 10 "s" "SIPS+D2T" "" _sips._tcp.sip.example.com.
sip.example.com.  NAPTR  20 10 "s" "SIP+D2T"  "" _sip._tcp.sip.example.com.
sip.example.com.  NAPTR  30 10 "s" "SIP+D2U"  "" _sip._udp.sip.example.com.

; SRV records - point to actual servers
_sips._tcp.sip.example.com.  SRV  10 100 5061 sipserver1.example.com.
_sip._tcp.sip.example.com.   SRV  10 100 5060 sipserver1.example.com.
_sip._udp.sip.example.com.   SRV  10 100 5060 sipserver1.example.com.

In this example, AUTO mode would prefer TLS (SIPS+D2T has the lowest NAPTR order), then fall back to TCP, then UDP.

Advantages:

• Most standards-compliant configuration
• Automatically adapts to server-side transport changes
• Supports failover -- if the primary server is unavailable, SRV records can point to alternates
• No manual port or transport configuration needed

Limitations:

• Requires proper DNS records (NAPTR and/or SRV) on the registrar domain
• DNS resolution adds latency to the initial connection
• If DNS records are missing or misconfigured, falls back to UDP on 5060
• More complex to debug than explicit transport selection

When to use AUTO:

• When your SIP server publishes NAPTR and SRV DNS records
• When you want the most flexible, standards-compliant configuration
• When the SIP server may change transport or port without notice
• For production testing against well-configured SIP infrastructure

Protocol Selection Quick Reference

Default Ports by Protocol

If you leave the port field blank on your registrar, CallMeter uses the standard default:

Override the default only if your SIP server listens on a non-standard port.

Troubleshooting Transport Issues

Next Steps

• Adding a Registrar -- Create a registrar with your chosen protocol
• SIP Accounts -- Add authentication credentials
• SIP Registration Errors -- Diagnose connection failures