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:
- SIP Registration --- The worker registers SIP accounts with your registrar (PBX, SBC, or SIP proxy) using the credentials you configure.
- Call Establishment --- Workers initiate and receive SIP calls based on your test configuration, including caller/callee roles, codecs, and media settings.
- Media Transmission --- During active calls, workers send and receive RTP media streams (audio, video, or both) using the codecs and media files you selected.
- 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.
- 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:
| Component | Value |
|---|---|
| Prefix | cmw_ (identifies user-owned worker tokens) |
| Body | 64 cryptographically random hex characters |
| Total length | 68 characters |
| Example | cmw_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
- You create a worker in your CallMeter project and receive a token
- You pass the token to the Docker container as the
WORKER_TOKENenvironment variable - On startup, the worker connects to
wg.callmeter.io:443and presents the token - The gateway validates the token, associates the worker with your organization and project, and starts accepting heartbeats
- 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
| Feature | Cloud Workers | User-Owned Workers |
|---|---|---|
| Setup required | None | Docker deployment |
| Test private infrastructure | No | Yes |
| SIP/RTP traffic stays local | No | Yes |
| Dedicated capacity | No (shared) | Yes |
| Requires public IP | N/A | No |
| Inbound firewall rules | N/A | None required |
| Automatic updates | Yes | Manual (pull new image) |
| Geographic placement | CallMeter regions | Any location you choose |
| Worker license required | No (included in plan) | Yes |
| Capacity limit | Plan-dependent | License-dependent |
| Test from multiple locations | Yes (select region) | Yes (deploy multiple workers) |
| Ideal for compliance | No | Yes (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:
| Status | Meaning |
|---|---|
| ONLINE | Connected, healthy, and ready to accept test assignments |
| OFFLINE | Not connected to the Worker Gateway |
| DRAINING | Finishing current work; no new test assignments will be allocated |
| ERROR | A connection or health issue has been detected |
For detailed status definitions and transitions, see the Worker Statuses reference.
Next Steps
- Cloud Workers --- How managed cloud workers operate, regions, and capacity
- Deploying Your Own Workers --- Step-by-step Docker deployment guide
- Configuration --- All environment variables and tuning options
- Networking --- Firewall rules, ports, NAT, and bandwidth requirements
- Capacity and Scaling --- Plan capacity, license tiers, and horizontal scaling
- Troubleshooting --- Diagnose and resolve common worker issues