Key Concepts

CallMeter is built around a set of interconnected concepts that work together to enable SIP stress testing and VoIP quality monitoring at scale. Understanding these concepts will help you design effective test scenarios, interpret results accurately, and get the most value from the platform.

This page explains each concept in detail, how it relates to other concepts, and practical guidance on how to use it.

Organizations

An organization is the top-level container in CallMeter. Everything you do on the platform happens within the context of an organization.

An organization owns all resources beneath it: projects, team members, workers, billing subscriptions, and API keys. When you sign up for CallMeter and create your first organization, you become its Owner with full administrative control.

Organizations map to real-world entities in whatever way makes sense for your team. A telecom carrier might create one organization for the entire company. A managed service provider might create separate organizations for each client to maintain strict data isolation. A consultant might have a personal organization for lab testing and be invited as a member of client organizations.

The key properties of an organization are:

• Members and roles. Users are invited to organizations and assigned one of five roles (Viewer, Tester, Editor, Admin, Owner) that control what they can see and do. Role-based access control ensures that stakeholders can view dashboards without accidentally modifying test configurations.
• Billing. The subscription plan is set at the organization level. All projects within the organization share the plan's limits for concurrent endpoints, test duration, probe count, and worker capacity.
• Isolation. Organizations are fully isolated from each other. Members of one organization cannot see projects, tests, or metrics belonging to another organization, even if they belong to both.

You can belong to multiple organizations and switch between them from the sidebar. See Creating an Account for setup details and Managing Members for team management.

Projects

A project is a workspace within an organization that groups related testing resources. Projects contain registrars, SIP accounts, tests, test runs, probes, media files, and their associated metrics.

Projects serve an organizational purpose. They let you separate different testing contexts so that a "Production SIP Trunk" project does not mix with a "Lab PBX" project. Each project has its own sidebar navigation, its own registrar list, and its own test history.

Common project structures include:

• Per environment. One project for production, one for staging, one for lab. This is the most common pattern for teams that test the same infrastructure across deployment stages.
• Per SIP platform. One project for each SIP trunk provider, PBX vendor, or UCaaS platform you test. This works well when you have multiple vendors to evaluate or monitor.
• Per team or customer. If different teams own different parts of the infrastructure, or if you are an MSP testing for multiple clients, separate projects keep concerns isolated.

Members can be granted access to all projects in the organization or to specific projects only. This means you can invite a customer stakeholder as a Viewer on their project without exposing other projects.

See Creating a Project and Project Settings for management details.

Registrars

A registrar represents a SIP server that your test endpoints authenticate with before placing or receiving calls. In SIP terminology, a registrar is the server that processes REGISTER requests and maintains a location table of active endpoints.

When you add a registrar to CallMeter, you are telling the platform: "Here is a SIP server I want to test. Here is how to connect to it." Each registrar stores:

• Domain. The SIP server's address, either as a fully qualified domain name (like sip.example.com) or an IP address (like 10.0.1.50). This becomes the Request-URI in SIP REGISTER messages.
• Transport protocol. How to reach the SIP server: UDP (the most common), TCP, TLS (encrypted signaling), or WSS (WebSocket Secure, used for browser-based SIP). You can also select AUTO for RFC 3263 DNS-based transport discovery.
• SIP accounts. The username/password credentials that test endpoints use to authenticate. Each account represents one SIP identity (one extension, one line, one trunk credential).

A single registrar can hold many SIP accounts. During test configuration, you select which accounts to assign to which groups of endpoints. This lets you test with realistic per-user credentials rather than sharing a single credential across all endpoints.

CallMeter also provides a cloud registrar with ephemeral credentials for users who do not have their own SIP infrastructure yet. The cloud registrar lets you explore the platform and run test calls without any external dependencies.

See Adding a Registrar, SIP Accounts, and Transport Protocols for configuration details.

Tests

A test defines a SIP load scenario that you want to execute against your infrastructure. It specifies everything needed to generate a controlled burst of SIP calls: how many endpoints, how long they call, what media they send, which registrars they use, and how endpoints are distributed.

The key parameters of a test are:

• Endpoints. The total number of concurrent SIP endpoints that participate in the test. Each endpoint is an independent SIP user agent that registers, places or receives a call, sends and receives media, and hangs up. You can run tests with as few as 2 endpoints (one caller, one callee) or scale to thousands.
• Duration. How long each call lasts, measured in seconds. During this period, endpoints actively send and receive RTP media packets and collect quality metrics.
• Buildup. A staggered startup period in seconds. Instead of all endpoints registering simultaneously (which can overwhelm a SIP server), buildup spreads registrations evenly over the specified period. A 10-second buildup with 100 endpoints means approximately 10 endpoints start per second.
• Groups. Subsets of endpoints with different configurations. Groups are explained in detail in the next section.

Tests are reusable. Once you create a test configuration, you can run it as many times as you want. Each execution produces an independent test run with its own metrics, timeline, and results. This makes it easy to run the same test before and after a change and compare results.

Tests do not run automatically when created. You must explicitly trigger a run from the test detail page or through the API. This gives you control over when load hits your infrastructure.

See Creating a Test and Running a Test for configuration and execution details.

Groups

A group is a subset of endpoints within a test that share the same configuration. Groups are one of CallMeter's most powerful features because they let you model complex, realistic call scenarios in a single test.

Every test has at least one group. The simplest test has two groups: one containing caller endpoints and one containing callee endpoints. But groups can do much more:

• Different registrars. Group A registers with SIP Trunk Provider X while Group B registers with SIP Trunk Provider Y. This lets you test cross-trunk call quality in a single test.
• Different codecs. Group A uses G.722 wideband audio while Group B uses PCMA narrowband. This is useful for testing codec negotiation or comparing quality across codecs.
• Different regions or workers. Group A runs from a cloud worker in US East while Group B runs from an on-premise worker in your European data center. This tests geographic call quality.
• Different media. Group A sends a pre-recorded voicemail prompt while Group B sends a music-on-hold file. Custom media files make tests more realistic than synthetic tones.
• Cross-targeting. Group A can be configured to call Group B, and vice versa. You can also have a group call an external URI or receive calls from an external system.

The total endpoint count of a test is divided across its groups. If a test has 100 endpoints and two groups, you might allocate 50 to each, or 80 to one and 20 to the other, depending on your scenario.

Each group has its own registrar selection, SIP account assignment, media configuration, worker assignment, and callee targeting. This flexibility means a single test can simulate complex real-world topologies: internal extensions calling external PSTN numbers, one PBX calling another, cloud softphones calling on-premise desk phones, and more.

See Creating a Test for group configuration details.

Test Runs

A test run is a single execution of a test configuration. Every time you click "Run Test" or trigger a run through the API, a new test run is created with its own lifecycle and metrics.

Test runs progress through a series of statuses:

Each test run stores the complete metric history for every endpoint that participated. You can revisit any past test run to analyze its results, compare it against other runs, or export data through the API.

Running the same test multiple times is a best practice. It establishes a quality baseline and helps you distinguish transient network issues from persistent infrastructure problems. If your SIP trunk shows 2% packet loss in one run but 0.1% in the next three runs, the first run was likely an anomaly.

See Running a Test and Analyzing Results for execution and analysis details.

Probes

A probe is a lightweight, automated monitor that continuously tests your SIP infrastructure by placing real calls at regular intervals. While tests are designed for on-demand load and stress testing, probes are designed for ongoing health monitoring.

A probe places a single SIP call at a configured interval (every 5, 15, 30, or 60 minutes), collects quality metrics from that call, and evaluates the results against configurable thresholds. Based on the evaluation, the probe reports one of four health states:

Probes are valuable for several reasons:

• Early warning. Probes detect quality degradation before end users notice it. A gradual increase in jitter or a slow rise in packet loss shows up in probe data hours or days before it becomes a user complaint.
• SLA compliance. Probes generate continuous quality records that prove your infrastructure meets its Service Level Agreements. This data can power public status pages visible to customers and partners.
• Change validation. After a network change, firmware upgrade, or configuration update, probes show whether quality improved, stayed the same, or degraded compared to the baseline.
• Alerting. When a probe's health state changes (for example, from Healthy to Degraded), it can trigger webhook notifications to your monitoring tools, chat systems, or incident management platforms.

You can configure multiple threshold levels per metric (warning and critical) and define which metrics matter most for your use case. A carrier might threshold on MOS and packet loss. A contact center might also threshold on RTT to ensure low-latency agent-customer interactions.

See Creating a Probe, Threshold Configuration, Webhooks, and Status Pages for probe setup and management.

Workers

Workers are the compute engines that execute SIP endpoints. When you run a test or a probe places a call, workers do the actual work: they register with your SIP server, establish calls, send and receive RTP media, collect metrics, and report results back to CallMeter.

CallMeter supports two types of workers:

Cloud Workers

Cloud workers are managed by the CallMeter platform. They run in specific geographic regions and are automatically allocated when you run a test. You do not need to install, configure, or maintain anything.

Cloud workers are ideal for:

• Testing SIP trunks and hosted PBX platforms that are accessible from the public internet
• Running probes from diverse geographic locations to measure quality from different regions
• Getting started quickly without any infrastructure setup

On-Premise Workers

On-premise workers (also called user-owned workers) are lightweight agents that you deploy on your own infrastructure. You run a single command to start a worker, and it connects back to CallMeter to receive test assignments.

On-premise workers are ideal for:

• Testing SIP infrastructure behind firewalls that cloud workers cannot reach
• Testing from specific network locations (a branch office, a data center, a customer site)
• Ensuring media traffic stays within your network for security or compliance reasons
• Measuring quality from the exact location where your users are

When you create a test, you choose how endpoints are distributed across workers. You can use region-based assignment (the platform automatically distributes endpoints across available cloud workers in a region) or explicit worker selection (you choose exactly which workers execute each group of endpoints).

See the Workers section for deployment guides and management details.

Regions

Regions are geographic groupings of cloud workers. Each region represents a physical location where CallMeter maintains worker capacity. Examples include "US East", "US West", "EU West", and "Asia Pacific".

Regions matter because VoIP quality is distance-sensitive. A test running from a worker in US East against a SIP server in the same region will show lower RTT and fewer packet loss events than the same test running from EU West. By selecting the region closest to your SIP infrastructure, you get the most realistic quality baseline.

Regions also enable geographic quality comparison. You can create a test with multiple groups, each assigned to a different region, and compare the quality metrics across regions in a single test run. This is valuable for:

• Global SIP trunk testing. Verify that your trunk provider delivers consistent quality from all regions your users connect from.
• UCaaS migration planning. Measure expected call quality from each office location before migrating to a cloud PBX.
• CDN-style voice routing validation. Confirm that geographic SIP routing is working and that calls are being handled by the nearest server.

Metrics

Metrics are the quantitative measurements that CallMeter collects from every endpoint during every second of a test or probe call. They are the core value of the platform: without metrics, SIP testing is just connection testing.

CallMeter collects over 150 real-time metrics per endpoint per second, organized into eight categories:

Quality Scores

The highest-level indicators of call quality. These are the metrics that map most directly to end-user experience.

Network Transport

Low-level packet and bitrate counters that show how the network is handling media traffic.

RTCP Feedback

Counters for RTCP feedback messages that indicate how the receiver is coping with quality issues.

Jitter Buffer

Statistics about the receiver's jitter buffer, which absorbs timing variations to produce smooth playback.

Audio Quality

Audio-specific measurements beyond the base quality scores.

Video Quality

Video-specific measurements for tests using H.264, VP8, or VP9 codecs.

FEC and Advanced

Forward Error Correction and advanced recovery statistics.

Call Timing

Measurements of the SIP signaling phase, before media begins flowing.

Direction Matters

Every media metric is collected separately in two directions:

• Send - What the endpoint transmitted to its peer
• Receive - What the endpoint received from its peer

This distinction is critical for diagnosing asymmetric issues. For example, if an endpoint shows excellent send metrics but poor receive metrics, the problem is likely in the return path (the peer's encoder, the network from peer to endpoint, or the endpoint's decoder). Without directional separation, this kind of problem is invisible in aggregate statistics.

For the complete metric reference with units, standards, and detailed descriptions, see the Metrics section.

How Everything Connects

Here is how all the concepts fit together in a typical workflow:

1. You create an organization and invite your team.
2. Within the organization, you create a project for the infrastructure you want to test.
3. Inside the project, you add a registrar with SIP accounts pointing to your SIP server.
4. You create a test with one or more groups, each configured with a registrar, codec, and callee target.
5. You run the test. The platform allocates workers (cloud or on-premise) and creates a test run.
6. Workers register endpoints with your SIP server, establish calls, and collect metrics every second.
7. The test run completes and you analyze per-endpoint metrics in the dashboard.
8. For ongoing monitoring, you create a probe that runs the same scenario automatically on a schedule.
9. The probe evaluates quality thresholds and reports health status. You publish a status page and configure webhooks for alerting.

Next Steps

• Quick Start - Put these concepts into practice by running your first test.
• Why CallMeter - See how CallMeter compares to open source tools and enterprise alternatives.
• Creating a Test - Deep dive into test configuration with groups, media, and workers.
• Creating a Probe - Set up continuous monitoring with threshold-based alerting.
• Workers - Learn about cloud and on-premise worker deployment options.
• Metrics Reference - Complete reference for all 150+ metrics with units, standards, and interpretation guidance.
• Supported Codecs - Detailed codec information for PCMA, PCMU, G.722, Opus, H.264, VP8, and VP9.
• Roadmap - See what is coming next for the platform.