A SIP Load Balancer Needs Dialog Awareness Somewhere

Distributing initial INVITEs is easy; keeping in-dialog requests on a valid path is where the architecture starts to matter.

By Reaz Romen✓ Site verified

Lab period August 2025 Published 2020-04-11 1 min read

Lab Note. Reconstructed in 2026 as a technical lab note from the 2025 voice, telecom and infrastructure study period. The archive date indicates the period covered; the current site publication date is shown separately.

A round-robin list of FreeSWITCH servers looks like a SIP load balancer until the first re-INVITE or BYE takes a path that no longer understands the dialog.

The system needs a routing story for sequential requests. That can involve Record-Route in a proxy, topology state, dispatcher behavior, consistent dialog ownership, or an architecture where the application servers remain reachable through the same signalling edge.

Failure handling makes the problem more interesting. A dead backend should stop receiving new calls, but existing dialogs may still have media and state tied to it. Moving a live call is very different from routing the next INVITE elsewhere.

This is why I stopped evaluating SIP load balancing only with registration counts or calls per second. Correct dialog routing and predictable failure behavior matter before scale numbers do.