Signal Jan 31, 2013

Low Latency Switching in Signal

Article Summary

Signal's team discovered that building encrypted voice calls was easy. Building a VoIP system that actually worked well? That was the hard part.

The Signal team shares how they built RedPhone's low-latency voice infrastructure. They needed to route calls efficiently across the globe while keeping mobile clients simple (no persistent connections, no complex SIP protocols). The cryptography was straightforward, but delivering high-quality voice over pathological mobile NATs required creative solutions.

Key Takeaways

Critical Insight

By combining DNS-based geographic routing with simultaneous multi-connect logic, Signal built a self-load-balancing VoIP infrastructure that automatically routes to the lowest-latency server.

The article hints at client-side optimizations for audio quality that complement this network strategy, but those details are saved for a future post.

About This Article

Problem

Signal's Route 53 latency-based routing didn't cover Africa and central Asia well. A user in South Africa calling through the UK saw over 200ms round-trip latency, which made calls between nearby people too slow to be practical.

Solution

Signal built multi-connect logic where clients open TCP connections to every IP address in their DNS GSLB region at once, use whichever connects first, and close the rest. This picks the lowest-latency switch automatically without clients needing to know which server is closest.

Impact

Signal removed the need for dedicated load balancers by having clients act as load balancers instead. This enabled transparent failover and zero-downtime rolling upgrades through simple connection draining before updates.