Signal’s relay calls feature represents a significant advancement in protecting user privacy during voice and video communications. When enabled, this feature routes all call traffic through Signal’s servers, preventing the other party from discovering your IP address. This article explores the technical implementation, use cases, and configuration options for developers and power users who want maximum privacy.

How Signal Relay Calls Work

When you make a standard VoIP call, the calling and receiving devices typically exchange IP addresses directly. This direct peer-to-peer connection enables low-latency communication but exposes sensitive network information. The other party can potentially:

Signal’s relay calls feature solves this by introducing an intermediary server into the call path. Instead of connecting directly, both parties connect to Signal’s relay server, which forwards audio and video data between them. The call remains encrypted end-to-end—the relay server cannot decrypt the content.

Standard Call (Peer-to-Peer):
[Caller IP] <─────> [Recipient IP]

Relay Call:
[Caller IP] <────> [Signal Relay Server] <────> [Recipient IP]
                 (encrypted content)

The Signal server acts as a simple packet forwarder. Neither party ever sees the other’s IP address, only the relay server’s IP address. This is particularly valuable for:

Technical Implementation Details

Signal uses WebRTC for its voice and video capabilities. The relay mechanism operates at the ICE (Interactive Connectivity Establishment) layer. Understanding this helps developers appreciate the privacy guarantees.

WebRTC ICE Candidates

WebRTC collects multiple connection candidates during negotiation:

When relay calls are enabled, Signal’s client prioritizes relayed candidates, ensuring traffic flows through the relay:

// Simplified WebRTC priority configuration
const iceServers = [
  {
    urls: 'turn:turn.signal.org:3478',
    username: 'relay-user',
    credential: 'relay-credential'
  }
];

// With relay enabled, client only uses relay candidates
// This prevents direct peer-to-peer connections

The actual implementation happens in Signal’s native clients, which manage ICE candidate gathering and selection automatically.

Encryption Guarantees

The relay server handles encrypted packets only. Signal uses the Signal Protocol (formerly TextSecure Protocol) for voice and video, which provides:

This means Signal’s servers—even when operating as relays—cannot eavesdrop on conversations. The relay sees only encrypted bytes it forwards between parties.

Enabling and Configuring Relay Calls

Signal provides straightforward controls for enabling relay calls on mobile and desktop clients.

Mobile Clients (iOS and Android)

  1. Open Signal Settings
  2. Navigate to Privacy
  3. Enable “Relay Calls” or “Privacy Network”

The setting is per-device, so enabling it on one device doesn’t automatically enable it on others.

Desktop Client

Desktop Signal supports relay calls with additional configuration:

Settings → Privacy → Enable Call Relay

Desktop users can also configure custom TURN servers for enterprise deployments requiring additional control:

# Custom TURN server configuration (advanced)
turn:
  - urls: turn:your-turn-server.com:3478
    username: your-username
    credential: your-password

Performance Considerations

Relaying calls introduces latency because traffic makes an additional hop. The impact varies based on:

Closer relay servers reduce delay. Congested connections often benefit from relay routing, and video calls consume more bandwidth through relays than voice.

Signal automatically selects optimal relay servers based on geographic location. Users with strict privacy requirements often accept the slight performance trade-off for the IP protection benefits.

Typical latency additions range from 20-80ms depending on server distance. For most users, this remains imperceptible during voice calls.

Use Cases for Developers and Power Users

Threat Model Considerations

Relay calls protect against specific threats while acknowledging limitations:

Relay calls protect against IP address exposure to call recipients, basic geographic location inference, and ISP identification through IP lookup. They do not protect call metadata (who called whom, when, and for how long), Signal’s server knowledge of call timing, or government demands for records.

For high-security scenarios, combine relay calls with additional measures:

Integration Possibilities

Developers building privacy-focused applications can learn from Signal’s implementation:

Developers can self-host relay infrastructure using coturn, prioritize relay candidates in WebRTC configuration, and implement the double ratchet algorithm for forward secrecy.

Example coturn configuration for relay services:

listening-port=3478
external-ip=your-public-ip
realm=your-domain.com
user=username:password

Limitations and Trade-offs

Power users should understand several constraints:

  1. Battery impact: Continuous relay connections may increase battery consumption on mobile devices
  2. Bandwidth costs: Relaying consumes more server resources; Signal limits apply
  3. Feature restrictions: Some features may work differently with relay calls enabled
  4. Connection reliability: Additional hops can cause connection issues on unstable networks

Signal’s relay feature strikes a practical balance between privacy and usability. For most users, the privacy benefits outweigh these trade-offs.

Conclusion

For privacy-conscious users, enabling relay calls adds a layer of protection against IP-based tracking and attacks. Combined with Signal’s existing encryption guarantees, it creates a more complete privacy solution for voice and video communications.

Built by theluckystrike — More at zovo.one