Worker Networking

CallMeter workers communicate on two separate network planes: the control plane (worker-to-CallMeter platform) and the media plane (worker-to-your-SIP-infrastructure). Understanding both is essential for a successful deployment.

This guide covers every networking aspect of deploying user-owned workers, from firewall rules to bandwidth planning.

Network Architecture Overview

┌─────────────────────────────────────────────────────┐
│                  Your Network                        │
│                                                      │
│  ┌──────────────┐         ┌──────────────────────┐  │
│  │   CallMeter   │◄──────►│  Your SIP Server     │  │
│  │   Worker      │  SIP   │  (PBX / SBC / Proxy) │  │
│  │              │◄──────►│                        │  │
│  │              │  RTP   │                        │  │
│  └──────┬───────┘         └──────────────────────┘  │
│         │                                            │
│         │ Outbound TCP/443                           │
│         │ (control plane)                            │
└─────────┼────────────────────────────────────────────┘
          │
          ▼
┌─────────────────────┐
│  CallMeter Gateway   │
│  wg.callmeter.io:443│
└─────────────────────┘

The worker maintains two types of connections:

1. Control plane (outbound) --- A persistent encrypted TCP connection from the worker to wg.callmeter.io:443. This carries authentication, heartbeats, test assignments, and metric reporting.

2. Media plane (local) --- SIP signaling and RTP media between the worker and your SIP infrastructure. This traffic stays entirely within your network.

Control Plane: Worker to CallMeter Gateway

Connection Details

Why No Inbound Firewall Rules Are Needed

The worker uses a reverse-tunnel architecture. The worker initiates a persistent outbound connection to wg.callmeter.io:443 and keeps it open. All communication --- including test assignments from CallMeter to the worker --- flows over this worker-initiated connection.

This means:

• No inbound ports need to be opened on your firewall
• No port forwarding is required
• No public IP address is needed on the worker host
• No DNS records need to point to the worker
• No VPN tunnels are needed between your network and CallMeter
• The worker operates identically behind NAT, corporate firewalls, and restrictive network policies

The only requirement is that the worker can make an outbound TCP connection to wg.callmeter.io on port 443. This is the same type of connection your browser makes to any HTTPS website --- port 443 outbound is permitted by virtually every network in the world.

What Flows Where

Understanding which traffic goes where helps you evaluate security and compliance:

┌─────────────────────────────────────────────────────────────────────────┐
│                         YOUR NETWORK                                     │
│                                                                          │
│  Worker ◄──── SIP signaling ────► SIP Server    ← STAYS IN YOUR NETWORK │
│  Worker ◄──── RTP media ────────► SIP Server    ← STAYS IN YOUR NETWORK │
│                                                                          │
│  Worker ────► aggregated metrics ────────────────► wg.callmeter.io:443  │
│  Worker ◄──── test assignments ──────────────────► wg.callmeter.io:443  │
│  Worker ────► heartbeats ────────────────────────► wg.callmeter.io:443  │
│                                       LEAVES YOUR NETWORK ──────────┘    │
└─────────────────────────────────────────────────────────────────────────┘

What stays in your network:

• All SIP signaling (REGISTER, INVITE, ACK, BYE, and related messages)
• All RTP media (audio and video streams)
• All SIP credentials (never sent to CallMeter)
• All media file content (audio/video files are downloaded to the worker at test start, but playback happens locally)

What leaves your network (through wg.callmeter.io:443 only):

• Aggregated quality metrics (jitter, packet loss, RTT, codec statistics, SIP timing)
• Worker status and heartbeats
• Test assignment data (test configuration parameters)

No raw SIP messages, no RTP packets, and no credentials ever leave your network.

Firewall Rules for Control Plane

That is the only firewall rule required for the control plane.

Connection Lifecycle

1. Initial connection --- Worker resolves wg.callmeter.io, establishes TCP connection on port 443, performs TLS handshake, and authenticates with the worker token.
2. Heartbeats --- Worker sends a heartbeat every 30 seconds. If the gateway does not receive a heartbeat for 60 seconds, the worker is marked as stale and transitions to ERROR status.
3. Reconnection --- If the connection drops, the worker automatically reconnects with exponential backoff:
   • First retry: 5 seconds
   • Subsequent retries: doubling up to a maximum of 60 seconds
   • Reconnection continues indefinitely until the connection is restored or the container is stopped

Data Transferred Over Control Plane

The control plane is extremely lightweight. Even a worker running 500 concurrent endpoints generates less than 1 Mbps of control plane traffic.

Firewall Approval Cheat Sheet

If you need to submit a firewall change request to your network team, here is a concise summary:

Request: Allow outbound TCP from [worker host IP] to wg.callmeter.io on port 443.

Purpose: CallMeter SIP testing worker connecting to the managed platform.

Direction: Outbound only. No inbound rules required.

Protocol: TLS-encrypted TCP (standard HTTPS port).

Traffic pattern: Persistent connection with small keepalive heartbeats every 30 seconds, plus metric data during test runs (under 1 Mbps).

Risk profile: Equivalent to allowing outbound HTTPS to a SaaS platform. No inbound attack surface is created.

Media Plane: Worker to Your SIP Infrastructure

The media plane carries SIP signaling and RTP media between the worker and your SIP servers. This traffic stays entirely within your network and never touches CallMeter's infrastructure.

SIP Signaling

RTP Media

Firewall Rules for Media Plane

If the worker and your SIP infrastructure are on the same subnet, no additional firewall rules are needed. If they are separated by a firewall:

Complete Port Summary

NAT Considerations

Worker Behind NAT (Most Common)

Most corporate deployments place the worker behind NAT. This works seamlessly for the control plane (outbound TCP to wg.callmeter.io:443). For the media plane, NAT behavior depends on your network topology:

Worker and SIP server on the same private network: No NAT issues. Both devices use private IPs, and traffic stays internal.

Worker behind NAT, SIP server on a different network: The worker needs to advertise the correct IP address in SIP headers and SDP bodies so the SIP server knows where to send RTP. Configure:

environment:
  SIP_IP: "10.0.1.50"           # Worker's private IP (bind address)
  SDP_IP: "203.0.113.10"        # IP the SIP server can reach (NAT public IP)
  EXTERNAL_IP: "203.0.113.10"   # Advertised in SIP Via/Contact headers

Worker behind symmetric NAT: Symmetric NAT assigns different external ports for each destination, making RTP difficult. If possible, place the worker on the same network as the SIP server. If that is not an option, consider deploying an RTP relay (e.g., RTPengine) on a network reachable by both parties.

SIP Server Behind NAT

If your SIP server is behind NAT and the worker is on a different network, the SIP server must be configured to advertise its externally reachable address. This is a SIP server configuration concern, not a CallMeter worker concern.

Docker NAT Layer

Docker's default bridge networking adds a NAT layer between the container and the host. For most deployments, this is transparent. If you experience media issues at high endpoint counts, switch to host networking:

services:
  callmeter-worker:
    network_mode: host

This eliminates Docker's NAT overhead and gives the worker direct access to the host's network interfaces.

Corporate Proxy and Firewall Considerations

HTTPS Proxies

If your network routes all outbound traffic through an HTTPS proxy, the worker's connection to wg.callmeter.io:443 may need to traverse the proxy. Set the standard proxy environment variables:

environment:
  HTTPS_PROXY: "http://proxy.corp.example.com:8080"
  NO_PROXY: "10.0.0.0/8,172.16.0.0/12,192.168.0.0/16"

Deep Packet Inspection (DPI)

Firewalls with DPI may flag the persistent connection to wg.callmeter.io:443 as suspicious due to its long-lived nature. The connection maintains a persistent encrypted stream that carries periodic small heartbeat messages. If your DPI system drops long-lived connections, configure an exception for wg.callmeter.io.

Idle Connection Timeouts

Many firewalls and NAT devices drop idle TCP connections after a timeout (often 300-900 seconds). The worker's 30-second heartbeat interval ensures the connection is never idle for long. However, if your firewall has an unusually aggressive idle timeout (under 30 seconds), the connection may be dropped between heartbeats. In this case, consider adjusting the firewall timeout or deploying the worker on a network with less restrictive policies.

DNS Requirements

The worker needs to resolve the following hostnames:

Ensure your DNS resolver can resolve these hostnames. If you use a split-horizon DNS or internal-only resolver, you may need to add exceptions for the callmeter.io domain.

Bandwidth Requirements

Control Plane Bandwidth

The control plane uses negligible bandwidth:

Media Plane Bandwidth

Media bandwidth depends on the codec, call type, and number of concurrent endpoints:

These are per-direction values (send or receive). A bidirectional call doubles the bandwidth requirement. However, in most test configurations, the worker handles both sides of the call, so traffic is local.

Bandwidth Planning Formula

Required bandwidth = Endpoints x Per-endpoint rate x 2 (bidirectional)
                     + 1 Mbps (control plane overhead)

Example: 200 endpoints, audio-only (G.711), calling an external SIP server:

200 x 90 Kbps x 2 = 36 Mbps + 1 Mbps = ~37 Mbps

Summary: Network Requirements at a Glance

For quick reference, here is everything the worker needs at a network level:

Minimum Requirements (Worker to CallMeter)

Requirements for SIP Testing (Worker to Your Infrastructure)

Not Required

Troubleshooting Connectivity

Worker Cannot Connect to Gateway

Symptoms: Worker status stays OFFLINE. Logs show connection timeout or refused errors.

Diagnostic steps:

1. Verify DNS resolution:

   nslookup wg.callmeter.io
   # or
   dig wg.callmeter.io

2. Test TCP connectivity:

   nc -zv wg.callmeter.io 443
   # Expected: Connection to wg.callmeter.io port 443 [tcp/https] succeeded!

3. Test from inside the container:

   docker exec callmeter-worker nc -zv wg.callmeter.io 443

4. Check for proxy interference:

   curl -v https://wg.callmeter.io

Common causes:

• Firewall blocking outbound TCP 443 (check egress rules)
• DNS resolution failing (check resolver configuration)
• TLS inspection breaking the connection (bypass wg.callmeter.io)
• Network proxy not configured (set HTTPS_PROXY)

Worker Connects But Keeps Disconnecting

Symptoms: Worker alternates between ONLINE and OFFLINE/ERROR.

Common causes:

• Aggressive firewall idle timeout (under 30 seconds)
• Unstable network connection (packet loss on the path to gateway)
• TLS inspection intermittently resetting connections
• Docker container being OOM-killed (check docker inspect for OOM events)

SIP Registration Fails

Symptoms: Test starts but endpoints fail to register.

Diagnostic steps:

1. Test SIP connectivity from the worker:

   docker exec callmeter-worker nc -zuv <sip-server-ip> 5060

2. Check if the SIP server is reachable on the expected port and protocol

3. Verify SIP credentials are correct in the registrar configuration

4. Check if the SIP server's firewall allows traffic from the worker's IP

RTP Media Issues

Symptoms: Calls establish but no audio/video, or poor quality metrics.

Common causes:

• Firewall blocking UDP in the RTP port range
• NAT not configured correctly (SDP_IP or EXTERNAL_IP missing)
• Docker bridge networking adding latency (switch to host mode)
• Port range too narrow for the number of concurrent endpoints

Next Steps

• Configuration --- All environment variables including SIP/media network settings
• Capacity and Scaling --- Bandwidth and resource planning by endpoint count
• Troubleshooting --- Comprehensive troubleshooting for all worker issues