Quality youcan measure
Answer rate, call duration and post-dial delay on every route, your own calls measured on every purchase, and a formal route issue when a route slips.
Rates are easy to publish; quality is not.
Every listing carries its answer rate, average call duration and post-dial delay, and the Exchange Score is only awarded once a route has carried real traffic. On the routes you buy, your own calls are measured, so price is never the only thing you compare. When a route you bought stops performing, raise a route issue against it: the seller is notified, their fix is re-tested automatically, and the record stays on the marketplace, so a dispute starts from the same numbers on both sides.
Quality on every listing
ASR, ACD and PDD on every route, and an Exchange Score once it has carried real traffic.
Route issue reports
A structured complaint loop between buyer and seller.
Automatic re-test
When the seller marks an issue fixed, their endpoint is re-tested automatically.
Failure diagnostics
SIP code, hangup cause and the fix, on every failed call.
From choosing a route to fixing one
Quality on PacketExchange runs as a loop: compare before you buy, watch what connects, diagnose what fails, and settle it on the record.
- 01
Compare before you buy
Every listing shows its ASR, ACD, PDD, tier and caller ID type, sortable side by side. The Exchange Score only appears once a route has carried real calls.
- 02
Watch what connects
The marketplace reports the answer rate measured on real calls over the last 30 days. Switch operators get a verdict per destination, with the numbers behind it.
- 03
Diagnose a failure
Every failed call carries its cause in plain English. On a route you hold, a SIP trace shows the full exchange, and a probe checks the endpoint from every media address.
- 04
Raise it and close it
Report the route from the failed call. The seller works it in a thread, marking it fixed triggers an automatic re-test, and you confirm or reopen.
A verdict that shows its working
On the Switch, every destination on a supplier trunk and on a customer is judged on answer-seizure ratio and post-dial delay from real sessions. The verdict never arrives alone: it names the metric that failed, the line it crossed, how many calls it rests on and the window it covers. An ASR below 60% is a warning and below 40% a failure; a post-dial delay above 3 seconds is a warning and above 6 a failure. A destination with fewer than 30 sessions reads Not judged, so two failed test calls can never brand a route.
- Windows of the last hour, the last 24 hours or the last 7 days.
- Rates count calls, not attempts, so a call that failed over counts once.
- A metric with too few samples is shown with its count and kept out of the verdict.
ASR 57%, below the 60% warning line, across 1,284 customer sessions. Last 24 hours.
Fewer than 30 sessions reads Not judged. MOS, jitter and packet loss appear on call records and never decide a verdict.
From failed call to fixed route, on the record
When a route you bought stops completing, report it straight from the failed call. The report carries that call's evidence (the hangup cause, the SIP code, the number and a diagnosis), plus a live SIP trace if you attach one. The seller is told in the app and by email and works the problem with you in a thread. When they mark it fixed, PacketExchange re-tests their endpoint automatically and posts the verdict for both sides to read, and if the re-test still sees a refusal, it says so and names the fix.
- Report straight from a failed call in your usage records, or from a SIP trace.
- You confirm the fix or reopen the issue, and either side can escalate to PacketExchange support.
- Only buyers who hold the route or have sent traffic over it can raise an issue.
- SIP code
- 403
- Hangup cause
- INCOMING_CALL_BARRED
- Number
- +44 7700 900123
- Category
- Call failure
- RaisedYou · 09:14
Reported from the failed call, with its evidence and a live SIP trace attached.
- Seller notifiedPacketExchange · 09:14
In the app and by email. The seller sees you as Buyer #3F7A.
- InvestigatingSeller · 09:41
Seller acknowledged the report and is investigating.
- Marked fixedSeller · 10:06Automatic re-testPassed
Automatic re-test passed: the endpoint accepted our SIP probe. Calls should connect again.
- ResolvedYou · 10:20
You confirmed the fix and the report closed.
Every media address, checked
Calls to a seller leave from several media addresses, and a firewall that allows only some of them fails a share of real calls while a single-address probe calls it healthy. So PacketExchange probes with a real SIP INVITE from every address, and returns a verdict per address, a diagnosis in plain words and the exact fix, whether the endpoint is down, barring our calls or refusing just one address. Active voice routes are re-probed this way on a rolling sweep, and the seller is alerted when an endpoint goes down or starts refusing an address.
- A real INVITE rather than OPTIONS, so a switch that ignores OPTIONS is not marked down.
- A partial whitelist is reported as degraded, naming the address that still needs allowing.
- The listing wizard runs a live SIP probe against a seller's endpoint before a route is published.
- Probe from 203.0.113.10Responded, SIP 200
- Probe from 203.0.113.11Responded, SIP 200
- Probe from 203.0.113.12No SIP response. This address appears to be blocked or unrouted on your side.
- 1Allow SIP (UDP and TCP 5060) from 203.0.113.12 on your firewall or SBC. The other addresses already work, so copy that rule.
- 2Whitelist all of our media addresses: calls are load-balanced across them and any one can carry the next call.
- 3Re-run this test after the change. Every probe line should turn green.
Quality you can compare, check and dispute
Everything a buyer needs to judge a route beyond its price, and everything a seller needs to fix one.
Quality columns you can sort
ASR, ACD and PDD on every listing, sortable, beside the tier, the caller ID type and the billing increment.
A score that has to be earned
The Exchange Score rates a route out of 100 from its ASR, ACD, PDD and tier, and stays blank until the route has carried real calls.
Measured answer rate
The share of calls that connected over the last 30 days, across the routes in view, counted per call rather than per attempt.
Verdicts with thresholds
OK, Warn or Bad per destination on the Switch, each naming the metric, the threshold, the sample and the window.
Failures in plain English
A refused call says what happened and whose move it is: yours, the other side's or ours, with a SIP code that matches.
SIP traces on your routes
Capture the full SIP exchange of a probe through a route you own or bought, with the final status, hangup cause and Q.850 code.
Endpoint health sweep
Active voice routes are probed from every media address on a rolling sweep, and the seller is alerted when one goes down or degraded.
Route issues with re-test
Evidence from the failed call, a thread with the seller, an automatic SIP re-test on every fix and escalation to support if it stalls.
Quality that holds up in an argument
A rate sheet tells you the price. The rest of what a buyer needs to know about a route is here, and both sides of the trade read the same record.
Buy on more than the rate
Compare stated quality, tier and caller ID handling before you commit, then check the answer rate measured on real calls. The rate sheet is where the decision starts, not where it ends.
Disputes that start from the same evidence
The failed call, its SIP code and the seller's re-test verdict sit in one report both sides can read, so the conversation starts from the call rather than from two different sets of logs.
Faults found before they cost you
The health sweep probes seller endpoints on its own schedule, and a partial whitelist is flagged with the exact address to allow, so a quiet failure has a short life.
Anonymous on both sides
The seller sees a pseudonym, you never see the seller's endpoint, and contact details are kept out of every report. Problems get fixed without either side being exposed.
How route quality usually works, and how it works here
| The usual way | On PacketExchange | |
|---|---|---|
| Judging a route | The rate sheet and whatever the seller says about it | ASR, ACD, PDD, tier and caller ID side by side, and a score only after real calls |
| A bad destination | A red flag with no number behind it | The failed metric, its threshold, the session count and the window, or Not judged |
| A failed call | A bare error code and a support ticket | The cause in plain English, whose move it is, and a SIP trace on demand |
| A half-open firewall | One probe passes while part of the traffic is refused | Every media address probed, with the refused address named |
| Raising a problem | Email threads and screenshots from two different logs | A route issue carrying the call's evidence, with the fix re-tested automatically |
| Escalation | Chase an account manager | Either side escalates to PacketExchange support from the report |
Buy on evidence
Compare routes on quality figures and the Exchange Score, not on the rate alone.
Hold a seller to it
Escalate formally when a route stops performing.
Diagnose fast
See the SIP cause instead of guessing why calls fail.
Quality tools come with the account
Comparing routes, reading measured answer rates, running SIP traces and connection tests, and raising route issues are part of every PacketExchange account, with no separate charge.
You pay for traffic: the route rate, plus the platform fee of 2% of the carrier rate, capped at $0.001 per call.
Browse the marketplaceCompare before you sign up
Listings, their stated quality and their scores can be compared on the public marketplace.
Traces and probes included
SIP traces and connection tests are not billed to your balance.
Issues and escalation included
Route issues, the automatic re-test and escalation to support carry no fee.
Caller ID tests, which place a real call to an opted-in handset in the destination country, are billed per test.
Route quality, answered
Are the ASR, ACD and PDD on a listing measured?
They are the figures the seller states for the route, shown so listings can be compared before any traffic flows. What was measured sits alongside them: the marketplace answer rate over the last 30 days of real calls, and the Exchange Score, which a route only receives once it has carried real calls. Sellers see the measured answer rate and call duration for each of their own routes.
How is the Exchange Score worked out?
It rates a route out of 100: 45% answer rate, 25% call duration, 15% post-dial delay and 15% tier. A route that has carried no calls has no score, so a new listing cannot claim one.
Who can raise a route issue?
A buyer who holds an active purchase of the route, or who has sent traffic over it. Nobody can file one against their own route.
What happens when the seller marks an issue fixed?
PacketExchange re-tests the seller's endpoint with a live SIP probe and posts the result in the report. If the endpoint still refuses our calls, the message says so and tells the seller which addresses to allow. You then confirm the fix or reopen the issue.
Will the seller know who reported the problem?
No. The seller sees a stable pseudonym for you on that route, such as Buyer #3F7A, never your name, email or account. Contact details are blocked in the thread in both directions, and the traces you see have the seller's address removed.
Why are routes not judged on MOS, jitter or packet loss?
Those readings only exist on calls whose audio passes through our media servers, and they do not separate a good destination from a bad one reliably enough to set a threshold on. Verdicts use answer rate and post-dial delay instead. On calls whose audio we carry, the call record also shows packets in each direction, which is how one-way audio shows up.
How often are seller endpoints checked?
Every active voice route with an endpoint is re-probed on a rolling sweep, from every media address, at most once every 30 minutes per route. The seller is alerted when an endpoint stops answering or starts refusing one of the addresses.
Can I run a SIP trace on any route?
On any route you own or have bought. A trace sends a probe through the route and returns the full SIP exchange, the final status and the hangup cause, up to 10 traces a minute.