Can I load balance SIP/VoIP traffic?
Short answer
Yes, with a Network vService. SIP signaling is published with Protocol UDP - L4 and port 5060; by turning on L4 Persistence and SIP Persistence in the Details panel, all SIP messages that belong to the same call (Call-ID) are sent to the same Backend Service. SIP persistence is applied only while L4 persistence is on and Port Range is off; since it drops UDP packets that cannot be parsed as SIP, it is turned on only on a vService that carries only SIP traffic. SIP over TLS (5061) is carried with TCP - L4, and SIP persistence is not used for this traffic. TR7 does not change the media addresses in SIP messages; the RTP voice stream goes to the address advertised by the SIP server.
Problem: Why Are SIP Calls Split?
A SIP call is not a single message: messages such as INVITE, ACK and BYE arrive as separate UDP packets, at different times. If these messages are distributed to different servers, the call stays incomplete or is never established. Persistence by source IP gathers all phones on a single server in environments where many phones come from behind the same NAT. The SIP-specific solution is to group the messages by the call identifier (Call-ID).
Solution
Publishing SIP with a Network vService and SIP Persistence
- How it works TR7 reads the Call-ID in the SIP packets and sends all messages of the same call to the same Backend Service.
- Where it is opened vService → Type: Network → Details → LB Algorithm → L4 Persistence + SIP Persistence
- RequirementProtocol: UDP - L4; Port Range off; L4 persistence on
- vService type Network (UDP - L4)
- Backend Service side Depends on the selected LB Mode: with SNAT, no change is required (the server sees the registrations as coming from the SNAT IP); with Direct Server Return, the vService address is added to the server as a local address without ARP replies; with Route Mode, TR7 is made the return path of the server (Can I load balance UDP traffic (DNS, Syslog, NTP)?). For media (RTP), the address advertised by the SIP server must be an address the clients can reach.
Step-by-Step Configuration
The Load Balancer → Backend Services → Add steps are followed (How is a Backend Service added; which information is required?). This step and the next two steps are repeated for each SIP server.
Backend Service Name and Address (e.g. 192.0.2.40:5060) are entered; the route table of the vService is selected as the Route Table. For servers that do not respond to be removed from distribution, a profile of type UDP is selected in the Health Check field (How do I health check UDP services other than DNS (UDP scenario, Hex/Base64/text)?); a Backend Service with no health check defined is always considered reachable.
The Add button at the bottom of the form is clicked.
If the vService address is not defined in TR7, the Network → Interfaces → Actions → Add IP steps are followed (how to add).
In the IP Interface field, the interface the clients will reach is selected; the address and CIDR are written. In a cluster, the address is added as a VIP (Add IP Address (Cluster)).
The Add IP button at the bottom of the form is clicked.
The Load Balancer → Load Balancer vService List → Add steps are followed; Name is entered and Network is selected as the Type.
Route Table is selected; UDP - L4 is selected as the Protocol. Port Range stays off (default).
A row is added to the Frontend table with (+), the IP is selected and the port is set to 5060 (the new row comes with port 80).
The SIP servers are selected in the Default Backend Services table. LB mode is selected according to the network layout (default Direct Server Return); if SNAT is selected, the source address is selected from the SNAT IP field that appears.
The Details switch at the top right of the form is turned on; L4 Persistence is turned on in the LB Algorithm box. The duration field comes with 5 minutes and is set according to the longest call duration.
The SIP Persistence switch in the same box is turned on (off by default).
The Save button is clicked. On a Network vService, every save restarts the vService; the change is made at a low-traffic time. In a cluster setup, the change is also transferred to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent manually with Synchronize.
Verification
A softphone is registered to the vService address, and a call is started and ended.
The call is established, voice is transmitted in both directions and the call ends without problemstcpdump -n -A udp port 5060 | grep -i call-idAll messages of the same Call-ID appear on the same serverCommon Mistakes
- Turning on only SIP persistence. SIP Persistence is not applied if L4 Persistence is not on.
- Turning on port range. While Port Range is on, SIP persistence and LB mode are not applied.
- Turning on SIP persistence on a vService that carries non-SIP UDP traffic. UDP packets that cannot be parsed as SIP are dropped.
- Assuming that RTP also passes through this vService. TR7 does not change the media addresses in SIP messages (SDP); RTP goes to the address and ports advertised by the SIP server. If the SIP server advertises the vService address for media, the RTP port range is published separately (Can I make a vService listen on a wide port range (e.g. 4000-5000)?).
- Expecting SIP persistence with SIP over TLS. SIP with TLS on port 5061 is carried with TCP - L4; since it is encrypted, the Call-ID cannot be read and SIP persistence is not used.
How it is done in the documentation
