Pre-production route testing is the process of evaluating a wholesale VoIP route against defined pass/fail criteria using controlled test traffic before any live customer calls are placed over it. The goal is to catch problems — poor ASR, high PDD, FAS billing, CLI stripping, audio degradation — in a contained environment rather than on calls with real customers on the line.
A route that passes a single test call can still fail under load, to specific destination operators, at peak hours, or for calls lasting longer than thirty seconds. The only way to know whether a route is safe for live call center traffic is to run it through a controlled test plan and compare the results against thresholds you defined before testing began.
This guide covers every stage of that process: legal test setup, destination coverage, what to measure, how to detect FAS, CDR reconciliation, and a go/no-go decision framework. Understanding how CC routes work from dialer to destination gives useful context before diving in.
Why testing before go-live matters
Problems that surface after you commit live traffic are more expensive than problems found during testing. The categories of failure — and their costs — are distinct:
- Dropped calls: Lost revenue, agent time wasted, potential customer damage on outbound sales or support calls.
- FAS billing: You are charged for call duration that never corresponded to a connected conversation. On high-CPS dialer traffic the total is material. See the FAS section below.
- CLI stripping: Your caller ID does not arrive at the destination. For outbound campaigns, this directly suppresses contact rates — fewer people answer calls from unknown or unrecognized numbers.
- Audio issues: One-way audio, echo, clipping, or background hiss. Agents cannot conduct effective calls; customer experience degrades immediately.
- Destination gaps: The route performs well to some prefixes and fails silently to others. You discover this only when campaign results from a specific country, operator, or area code collapse.
Pre-production testing is cheaper than any of these outcomes. It is also reversible — you decline the route, document the findings, and source an alternative. Once live traffic is committed, switching has operational cost and timeline pressure.
Note the distinction: pre-production testing is a controlled one-time evaluation. It does not replace ongoing live traffic monitoring, which catches degradation that develops after go-live. Both matter; this article covers the pre-production phase. Choosing the right provider is a prerequisite — see choosing a CC routes provider for the evaluation framework that precedes testing.
Legal setup: test calls must go to numbers you control
Before any test call is placed, the legal requirement is simple and non-negotiable: test calls must terminate to real numbers that you own, control, or have explicit permission to call. Placing automated test calls to random public PSTN numbers is illegal in most jurisdictions and constitutes unsolicited calling — in the United States, this can violate the TCPA and similar regulations.
The standard legal setups for test traffic are:
- Your own numbers on a second provider: Numbers you have provisioned on a separate carrier that you control. You can answer them, record what CLI appears, and measure audio quality.
- Test bed subscriptions: Third-party test bed services that provide numbers in target countries specifically for quality testing — these log call characteristics, measure audio, and return results.
- Provider's test number bank: Some route providers maintain their own test numbers. Ask before testing whether this option is available — it can simplify international destination coverage.
- Your own SIP endpoints: SIP extensions under your control at a different location or carrier that can log call metadata and record audio.
If your route provider suggests placing test calls to public numbers that you do not own or have permission to call, that is a red flag about how that provider operates.
Destination coverage: test what you intend to send
In wholesale voice, a route that performs excellently to Tier-1 destinations can fail silently to specific mobile operators, rural zones, or secondary country destinations. A route rated for "US traffic" may behave very differently across US mobile, US landline, toll-free, and specific area codes. A route rated for "Brazil" may perform inconsistently across different Brazilian mobile operators.
The principle: test the specific destination prefixes you intend to send live traffic to — not proxies or approximations.
- If you plan to call US mobile numbers, test US mobile — not just US landlines.
- If you plan to call international, test the specific countries and specific operator types (mobile vs fixed) you will target.
- In markets where operator-level routing quality varies significantly (many Latin American and Asian markets), test per-operator if your volumes to specific operators are meaningful.
- If your traffic mixes destination types, your test sample should reflect that mix proportionally.
Destination testing also has a geographic bias risk on the originating side: if all your test calls originate from a single location, you are only testing how the route handles traffic from that originating carrier and region. If your live call center agents are distributed across geographies or use multiple originating carriers, test from representative source locations where possible.
What to measure and how
The metrics below are the standard quality indicators for a wholesale CC route. Each has a specific measurement method and interpretation. The targets vary by business use case — define your pass thresholds before testing starts.
| Metric | What You Measure | Method |
|---|---|---|
| ASR | Answered calls / attempted calls per destination prefix | CDR analysis — segment by destination prefix, not in aggregate |
| NER | Network delivery success — includes busy, ring-no-answer, terminal rejects as delivered | CDR analysis distinguishing network failures (503, 404) from user-side responses (486, 408) |
| PDD | Time from SIP INVITE to first 180 Ringing or 183 Session Progress | SIP trace timestamps; flag calls where PDD exceeds 6–8 seconds |
| ACD | Average call duration of answered calls | CDR analysis; abnormally low ACD (<10–15 s on outbound campaigns) is a FAS indicator |
| CLI delivery | Whether your caller ID arrives intact at the destination | Call a number you control and confirm what CLI appears at the receiving end; test multiple CLI formats |
| Audio quality | One-way audio, echo, clipping, background hiss, garbled speech | Call recording on a sample; human listener assessment on each recorded sample |
| Cause codes | SIP response codes for failed calls — identifies where failures originate | SIP trace or CDR cause code field; see diagnostic table below |
For average call duration specifically: in an outbound call center context, a very low ACD on a route that is supposed to be connecting to human answerers is a signal worth investigating — it may indicate FAS or poor destination coverage. Compare ACD against your baseline on verified clean routes.
For calls per second: also test that the route handles your expected CPS without degrading — some routes perform well at low CPS and exhibit quality problems under the burst load typical of predictive dialer traffic.
Sample size, timing, and statistical validity
A common mistake is drawing conclusions from too few test calls. ASR calculated from 20 calls is not statistically reliable — the margin of error is too wide to distinguish a good route from a marginal one. The practical minimum before trusting ASR or NER figures for a destination prefix is 100 calls to that prefix. For high-stakes destinations where route selection matters most, more is better.
Timing matters as much as volume. Route quality often degrades during peak hours when carrier infrastructure is under load. Some routes are effectively over-sold: quality is excellent at 2 a.m. on a Sunday and materially worse at 11 a.m. on a Monday when business traffic peaks. Run test calls across multiple time windows, including the hours when you plan to operate live traffic. If your campaign runs weekday mornings, test weekday mornings — not only off-peak periods.
Spread calls across the full test period rather than batching them all in one burst. A single high-CPS batch tests how the route handles a spike; distributed calls across the test window tests steady-state quality. You need both.
Cause code diagnostics
When calls fail, the SIP response code tells you where in the call path the failure occurred. Analyzing the distribution of cause codes across failed calls reveals whether failures are network-side (provider problem), destination-side (user behavior or coverage gap), or configuration-side (your equipment or setup). Dominant cause codes that cluster around network failures indicate a route problem; dominant codes around user-side events indicate normal call behavior.
| SIP Code | Meaning | Failure Origin | What It Indicates in Testing |
|---|---|---|---|
| 486 | Busy Here | Destination terminal | Normal — the called number is in use. High rate may indicate a destination coverage issue. |
| 408 | Request Timeout | Network / routing | Route is not completing the signaling path within timeout. Investigate PDD and routing hops. |
| 404 | Not Found | Route / destination | Route does not have coverage for this destination prefix. Route is not fit for those destinations. |
| 480 | Temporarily Unavailable | Destination terminal | Normal user-side response. High rate on some destination types (mobile) may reflect coverage or network issues. |
| 503 | Service Unavailable | Provider infrastructure | Provider-side failure. Dominant 503 rate is a hard route quality problem — the provider cannot handle the traffic. |
| 487 | Request Terminated | Originating side | Normal — call cancelled by originator (dialer abandonment, AMD). Not a route failure. |
| 488 | Not Acceptable Here | Codec / SDP negotiation | Codec mismatch between your equipment and the route. Configuration issue to resolve before go-live. |
When 503 responses appear consistently during peak test windows but not off-peak, the route is over-sold — capacity is insufficient for the load you plan to send. Do not go live on an over-sold route expecting peak performance to improve.
FAS detection during testing
False Answer Supervision is a billing practice where the route signals "answered" (SIP 200 OK) before a real conversation begins — billing you for ring time or fabricated audio. Testing is the most reliable time to detect it, because you can use known-controlled destinations and compare your internal logs against the route's CDRs.
The primary FAS indicators during pre-production testing:
- Abnormally low ACD on answered calls: If your route shows many "answered" calls with duration under 5–10 seconds when your test calls should last longer, investigate. At known test numbers you control, you know the call was not answered by a human — an answered record is suspicious.
- CDR discrepancy: Compare the answered call count and duration in your platform's CDR against the route provider's CDR. If the provider's CDR shows more answered calls or longer total duration than your internal log, that gap requires explanation before go-live.
- Answered records for unattended test numbers: If your test destination was not actively answered (you left it to ring unanswered intentionally), and the route CDR records it as answered, FAS is occurring.
- Audio content of answered calls: Record the early media and post-answer audio on a sample. If "answered" calls carry looped ringback or a pre-recorded greeting rather than real two-way audio, that is early media FAS.
FAS is fraud. Document it with CDR exports, timestamps, and audio recordings. It is grounds for refusing the route and, if the provider is complicit, terminating the relationship. For the full mechanics of FAS and detection methodology, see the False Answer Supervision guide.
CDR reconciliation
After the test period concludes, reconcile your internal CDR against the route provider's CDR before making a go/no-go decision. This is not optional — CDR discrepancies that emerge after go-live are harder to dispute when you have no pre-production baseline.
What to compare:
- Call count: Attempted call count from your platform should match the attempted count the provider received. Significant discrepancy indicates a connectivity or signaling issue between your equipment and the route.
- Answered call count: Answered calls in the provider's CDR should match answered calls in your internal CDR. Provider showing more answered calls than you recorded is a FAS signal.
- Total billed duration: Compare total billed seconds against your internal connected seconds, destination by destination. Duration should match within rounding tolerance (typically 1 second per call). Systematic overages by the provider are a billing dispute trigger.
- Per-call duration outliers: Look for individual calls where the provider's billed duration substantially exceeds your internal connected duration. Short systematic gaps are rounding; large gaps on individual calls may be fraudulent duration padding.
Keep the test CDRs from both sides as baseline evidence. If disputes arise after go-live, having documented pre-production reconciliation data strengthens your position.
Acceptance criteria and the go/no-go decision
The most important rule of pre-production testing: define your pass/fail thresholds before testing begins. Setting thresholds after you have seen the results introduces unconscious rationalization — you adjust the criteria to match what the route delivered rather than evaluating the route against what your business requires.
Write the acceptance criteria document before the first test call is placed. Get sign-off from whoever will use the route. Then apply it mechanically.
| Metric | What You Measure | Pass Threshold | Fail Indicator |
|---|---|---|---|
| ASR | Answered / attempted per destination prefix (min 100 calls) | Define per destination type based on your business baseline | Below threshold; or abnormally high ASR combined with low ACD (FAS signal) |
| NER | Successful network delivery rate (including busy and no-answer) | Define per destination type; NER below ASR indicates network failures, not user behavior | High proportion of 503 / 404 failures dominating NER gap from ASR |
| PDD | Average and 95th-percentile INVITE to 180 Ringing delay | Define maximum acceptable (e.g. average <4 s, P95 <8 s for outbound dialers) | Consistent PDD above threshold, especially at peak test windows |
| ACD | Average answered call duration (compare to your business baseline) | Above your defined FAS floor (e.g. minimum 15 s average on outbound test calls) | ACD below floor; cluster of sub-10 s "answered" calls in CDR |
| CLI delivery | CLI arriving intact at controlled test destination numbers | Define minimum delivery rate (e.g. 100% of test calls to your own numbers) | Any test call showing stripped, altered, or missing CLI at destination |
| Audio quality | Human listener assessment of recorded call samples | Zero one-way audio; no echo or clipping in sample (define sample size) | Any one-way audio in sample; consistent echo or clipping above threshold |
| CDR reconciliation | Your CDR vs provider CDR: answered count and total billed duration | Define maximum acceptable discrepancy (e.g. within 1 s rounding per call on duration) | Provider showing more answered calls or systematically longer duration than your log |
The thresholds in the table above are structural — the specific values depend on your destination types, business use case, and existing baseline from your current routes. What matters is that the structure is fixed before the test data arrives.
Go/no-go decision framework
After testing concludes, the decision is binary per criterion: pass or fail. Any fail criterion that cannot be explained and remediated is a no-go. Do not average pass criteria against fail criteria to reach a borderline "go."
Go criteria (all must be met):
- All destination prefixes meet ASR and NER thresholds
- PDD within acceptable range at peak test windows
- ACD above FAS floor; no CDR discrepancy suggesting FAS
- CLI delivers intact to all controlled test destinations
- No audio failures in defined sample
- CDR reconciliation within defined tolerance
- No dominant 503 or 404 failures across tested destinations
No-go actions:
- Document all findings with timestamps, CDR exports, SIP traces, and audio samples
- Present findings to the route provider with specific evidence — not general complaints
- If provider acknowledges the issue and commits to a fix with a timeline, consider a structured retest on the specific failing dimensions
- If provider disputes findings without addressing the evidence, decline the route
- Do not lower acceptance thresholds retroactively to accommodate a failing route
The documentation discipline matters beyond this test cycle. Timestamped CDR exports and audio recordings become evidence if a billing dispute arises after go-live on a different route, or if a route that passed testing begins to degrade later. The testing process creates an evidence baseline, not just a one-time verdict.
For more on how quality-based route selection compares to purely cost-driven approaches, see the discussion of LCR vs quality-based routing. And if you are still evaluating route provider options before testing begins, the full framework is in choosing a CC routes provider.
