CallMeter Docs

Workers Overview

Understand how CallMeter workers execute SIP tests, the differences between cloud and user-owned workers, and when to deploy your own.

Workers are the execution engines behind every SIP test and probe on CallMeter. When you create a test with 500 concurrent endpoints and click Run, workers are the machines that register those SIP accounts, establish calls, send and receive media, collect real-time quality metrics, and report results back to the platform.

Every test run on CallMeter requires at least one worker with available capacity. Understanding how workers operate, what types are available, and when to deploy your own is fundamental to getting the most out of the platform.

What Workers Enable

Deploying workers transforms CallMeter from a cloud-based testing tool into a distributed SIP testing platform that reaches every corner of your infrastructure:

  • Test from any network --- Place a worker inside a datacenter, a branch office, behind a corporate firewall, or in a cloud VPC. If it can run Docker and reach the internet, it can run CallMeter tests.
  • Test behind firewalls --- Your private PBX, lab environment, staging infrastructure, and internal SIP servers become testable without exposing them to the public internet.
  • Geographic distribution --- Deploy workers in the same locations as your actual users to measure the call quality they experience. Test from Tokyo, Frankfurt, Sao Paulo, and New York simultaneously.
  • Customer premises testing --- Managed service providers can deploy workers at customer sites to validate SIP quality from the customer's perspective, using the customer's actual network path.
  • Internal infrastructure validation --- Test internal SIP trunks, inter-office voice links, and private telephony infrastructure that is invisible to the outside world.
  • Enterprise-scale stress testing --- Deploy dozens of workers across multiple machines and locations to simulate thousands of concurrent calls against your infrastructure.
  • Compliance and data sovereignty --- Keep SIP signaling and RTP media entirely within your network boundary. Only aggregated quality metrics leave your premises.
  • Consistent, reproducible results --- Dedicated hardware eliminates the variability that comes from shared cloud infrastructure, giving you reliable benchmarks.

What Workers Do

A worker handles the full lifecycle of SIP endpoint simulation:

  1. SIP Registration --- The worker registers SIP accounts with your registrar (PBX, SBC, or SIP proxy) using the credentials you configure.
  2. Call Establishment --- Workers initiate and receive SIP calls based on your test configuration, including caller/callee roles, codecs, and media settings.
  3. Media Transmission --- During active calls, workers send and receive RTP media streams (audio, video, or both) using the codecs and media files you selected.
  4. Metric Collection --- Workers measure over 60 VoIP quality metrics in real time, covering SIP signaling health, RTP transport quality, codec performance, call establishment timing, and network behavior.
  5. Result Reporting --- All metrics are streamed back to CallMeter for storage, analysis, and visualization in your dashboard.

Workers are stateless between test runs. Each test run gets a clean execution context --- no residual state from previous tests can affect your results.

Architecture: How Workers Connect

Workers communicate with the CallMeter platform through the Worker Gateway, a secure relay endpoint at wg.callmeter.io:443. Here is how the pieces fit together:

┌──────────────────────────────────────────────────────────────────────────┐
│                         Your Infrastructure                              │
│                                                                          │
│  ┌──────────────────┐                    ┌──────────────────────────┐    │
│  │  CallMeter Worker │◄──── SIP/RTP ────►│  Your SIP Infrastructure │    │
│  │  (Docker)         │   (local traffic)  │  (PBX / SBC / Proxy)    │    │
│  └────────┬─────────┘                    └──────────────────────────┘    │
│           │                                                              │
│           │ Outbound TLS to wg.callmeter.io:443                         │
│           │ (only aggregated metrics leave your network)                 │
└───────────┼──────────────────────────────────────────────────────────────┘


┌───────────────────────────┐       ┌──────────────────────────┐
│  Worker Gateway            │──────►│  CallMeter Platform       │
│  wg.callmeter.io:443      │       │  (dashboard, analytics,   │
└───────────────────────────┘       │   test scheduling)        │
                                    └──────────────────────────┘

Key points about this architecture:

  • The worker initiates all connections outbound. The gateway never connects inbound to your worker. This means zero inbound firewall rules, no port forwarding, and no public IP required.
  • SIP and RTP traffic stays local. When the worker registers with your SIP server and establishes calls, that traffic flows directly between the worker and your SIP infrastructure on your network. CallMeter never sees or handles your SIP signaling or media.
  • Only metrics leave your network. The worker streams aggregated quality measurements (jitter, packet loss, timing, codec statistics) to the platform through the gateway. No raw SIP messages or RTP packets are forwarded.
  • The connection is persistent and encrypted. The worker maintains a TLS-encrypted connection to the gateway for receiving test assignments, reporting status, and streaming metrics.

Token-Based Authentication

Every worker authenticates to the CallMeter platform using a worker token --- a cryptographically random credential generated when you create a worker in the dashboard.

Token Format

Worker tokens follow a recognizable format:

ComponentValue
Prefixcmw_ (identifies user-owned worker tokens)
Body64 cryptographically random hex characters
Total length68 characters
Examplecmw_a1b2c3d4e5f67890...

Cloud workers use a different token prefix (cmc_) and are managed entirely by the platform --- you never interact with cloud worker tokens.

How Authentication Works

  1. You create a worker in your CallMeter project and receive a token
  2. You pass the token to the Docker container as the WORKER_TOKEN environment variable
  3. On startup, the worker connects to wg.callmeter.io:443 and presents the token
  4. The gateway validates the token, associates the worker with your organization and project, and starts accepting heartbeats
  5. The worker is now ONLINE and ready to receive test assignments

Token Security Rules

  • Tokens are displayed exactly once at creation time --- copy immediately
  • Each token authenticates exactly one worker. Two containers cannot use the same token simultaneously.
  • Tokens are hashed server-side and never stored in plaintext
  • If a token is lost or compromised, regenerate it from the worker's settings page (this immediately invalidates the previous token)
  • Store tokens in a secrets manager or environment file with restricted permissions (chmod 600)

Two Types of Workers

CallMeter supports two distinct worker types, each designed for different use cases.

Cloud Workers

Cloud workers are managed entirely by CallMeter. They run in our infrastructure, require zero setup, and are available on every plan.

  • Zero configuration --- Available immediately when you create an account
  • Shared capacity --- Cloud workers serve multiple organizations; capacity is allocated per test run
  • Multiple regions --- Deploy tests from different geographic locations
  • Automatic updates --- Always running the latest version of the SIP engine
  • Internet-accessible targets only --- Cloud workers can only reach SIP infrastructure exposed to the public internet

Cloud workers are ideal for testing cloud-hosted PBX systems, SIP trunking providers, and any infrastructure reachable over the internet.

User-Owned Workers

User-owned workers are Docker containers you deploy in your own infrastructure. They connect outbound to CallMeter's Worker Gateway at wg.callmeter.io:443 and receive test assignments through that connection.

  • Private network access --- Test SIP infrastructure behind firewalls, in private VPCs, or on air-gapped networks
  • Data locality --- SIP signaling and RTP media stay within your network; only aggregated metrics are sent to CallMeter
  • Dedicated capacity --- Your workers serve only your organization's tests
  • Geographic flexibility --- Deploy workers in any datacenter, cloud region, or office location
  • NAT-friendly --- Workers initiate all connections outbound; no inbound firewall rules or public IP addresses required
  • Full control --- You manage the host machine, resource allocation, and deployment lifecycle

User-owned workers require a worker license, a Docker host, and outbound network access to wg.callmeter.io:443.

Feature Comparison

FeatureCloud WorkersUser-Owned Workers
Setup requiredNoneDocker deployment
Test private infrastructureNoYes
SIP/RTP traffic stays localNoYes
Dedicated capacityNo (shared)Yes
Requires public IPN/ANo
Inbound firewall rulesN/ANone required
Automatic updatesYesManual (pull new image)
Geographic placementCallMeter regionsAny location you choose
Worker license requiredNo (included in plan)Yes
Capacity limitPlan-dependentLicense-dependent
Test from multiple locationsYes (select region)Yes (deploy multiple workers)
Ideal for complianceNoYes (data stays on-prem)

When to Use Cloud Workers

Cloud workers are the right choice when:

  • You are evaluating CallMeter and want to run tests immediately
  • Your SIP infrastructure is reachable from the public internet
  • You do not have compliance requirements that restrict where SIP traffic originates
  • You want zero operational overhead for worker management
  • Your testing volume fits within your plan's cloud capacity

Most users start with cloud workers and only deploy their own when they need private network access, dedicated capacity, or geographic control.

When to Deploy Your Own Workers

User-owned workers become necessary when:

  • Your SIP infrastructure is behind a firewall --- Private PBX systems, lab environments, and staging networks are unreachable from cloud workers
  • Compliance requires data locality --- Financial services, healthcare, government, and defense organizations often require that SIP signaling and RTP media never leave their network
  • You need dedicated capacity --- Shared cloud workers may have contention during peak hours; your own workers guarantee availability
  • You need specific geographic placement --- Test from a datacenter in Tokyo, a branch office in Frankfurt, or a lab in your basement
  • You are stress testing at scale --- Deploy multiple workers across machines to generate thousands of concurrent endpoints
  • You need consistent, reproducible results --- Dedicated hardware eliminates variability from shared infrastructure
  • You are testing NAT traversal or network-specific behavior --- Place workers inside specific network topologies to validate SIP/RTP behavior under real conditions

Quick Decision Guide

Do you need to test private/internal SIP infrastructure?
  YES → Deploy your own workers
  NO  ↓

Do you have compliance requirements for data locality?
  YES → Deploy your own workers
  NO  ↓

Do you need more than your plan's cloud capacity?
  YES → Deploy your own workers (or upgrade plan)
  NO  ↓

Do you need tests from specific locations not covered by CallMeter regions?
  YES → Deploy your own workers
  NO  ↓

Cloud workers are sufficient for your needs.

Worker Statuses

Every worker reports a status visible in the CallMeter dashboard:

StatusMeaning
ONLINEConnected, healthy, and ready to accept test assignments
OFFLINENot connected to the Worker Gateway
DRAININGFinishing current work; no new test assignments will be allocated
ERRORA connection or health issue has been detected

For detailed status definitions and transitions, see the Worker Statuses reference.

Next Steps

On this page