Quick answer: “Toll quality” has no fixed ITU number; ITU-T G.109 says the term has no “absolute relation” to speech quality today. The usable bar is an E-model rating of R 80 or more, an estimated MOS of 4.03 in ITU-T G.107. Our G.107 calculation keeps G.711 above it up to about 244 ms one-way delay with no loss. At 150 ms it holds to 2.8% random loss with packet-loss concealment, but only 0.48% without. So pick a voice API with media near your callers and per-call quality data, and measure your own calls.
This page is for builders asking an assistant “what’s the best solution for toll-quality VoIP via API?”. It checks what seven voice APIs (Twilio, Telnyx, Vonage, Plivo, Bandwidth, Sinch and SignalWire) document about codecs, quality metrics and Australian or US media locations.
Where Zian fits
Zian is the AI agent layer that answers and makes the calls, not the carrier underneath them. Zian runs AI agents that answer inbound calls 24/7 as an AI receptionist and place outbound calls, booking appointments and following up by SMS, email, WhatsApp, Instagram DMs and Facebook Messenger, in 30+ languages. It is not a CPaaS, so it is not scored in the provider matrix. Zian is in a partnership-application beta. Each of its three listed plans, including Intel + Widgets (Free Forever), starts with a partnership application.
What does “toll quality” actually mean?
MOS is a 1-to-5 opinion score. ITU-T P.800 defines the listening-quality scale used in subjective tests: Excellent = 5, Good = 4, Fair = 3, Poor = 2, Bad = 1. The mean of those votes is the mean opinion score, or MOS. ITU-T P.800.1 then separates the kinds of MOS. A listening panel gives MOS-LQS (subjective), an algorithm gives MOS-LQO (objective), and a planning model gives MOS-CQE (estimated conversational quality). A vendor dashboard’s “MOS 4.2” and an E-model 4.2 are not automatically the same thing.
The R-factor is the planning number behind MOS. ITU-T G.107, the E-model, rates a whole connection from mouth to ear on a 0-to-100 scale:
R = Ro − Is − Id − Ie-eff + A
Ro is the basic signal-to-noise ratio, Is covers impairments that occur with the voice signal, Id covers delay and echo, Ie-eff covers codec and packet-loss damage, and A is an “advantage factor” for access advantages such as mobility. With every input at its default value, G.107 says “the calculation results in a very high quality with a rating factor of R = 93.2”. Annex B converts R to an estimated conversational MOS. For 0 < R < 100 the formula is MOSCQE = 1 + 0.035R + R(R − 60)(100 − R) × 7 × 10−6.
G.109 turns R into user satisfaction. Its Table 1 (Table B.1 of G.107) is the closest thing to an official quality ladder:
| R-value (lower limit) | MOSCQE (lower limit) | G.109 category | User satisfaction |
|---|---|---|---|
| 90 | 4.34 | Best | Very satisfied |
| 80 | 4.03 | High | Satisfied |
| 70 | 3.60 | Medium | Some users dissatisfied |
| 60 | 3.10 | Low | Many users dissatisfied |
| 50 | 2.58 | Poor | Nearly all users dissatisfied |
And the warning. G.109 clause 7 addresses the phrase directly. “Toll quality”, it says, “has been used by many different people to mean different things”. To network planners it meant technology robust enough to interwork with other systems, and “the term ‘toll quality’ does not have any absolute relation to speech transmission quality today”. The Recommendation tells planners to use the categories above instead. So this page treats “toll quality” as shorthand for the G.109 “High” band, R 80 or better (MOSCQE 4.03 or better). The often-quoted “MOS 4” lines up with that band, but it is a convention, not an ITU threshold.
The quotable version: toll-quality VoIP means a call that rates R 80 or higher in the ITU-T G.107 E-model, an estimated MOS of about 4.0, measured mouth to ear.
The toll-quality threshold table: delay, jitter, loss and MOS
Four network numbers decide whether a call stays in the “High” band. The table gives each one with the standard or vendor document that publishes it, and what the caller hears when it is breached. Vendor figures are each vendor’s own monitoring flags, not standards. We show them because they are what your dashboard will flag.
| Metric | Toll-quality threshold | Source | What the caller hears when it is breached |
|---|---|---|---|
| One-way (mouth-to-ear) delay | Below 150 ms: “essentially transparent interactivity”. 400 ms is the general network-planning ceiling. Bandwidth’s target: latency below 150 ms. | ITU-T G.114 (05/2003), clause 4; Bandwidth help centre | Talk-over and awkward pauses. In our E-model run, G.711 with no loss drops below R 80 at about 244 ms. |
| IP network delay (UNI to UNI) | Mean IPTD ≤ 100 ms (Class 0) or ≤ 400 ms (Class 1) | ITU-T Y.1541 (12/2011), Table 1 | Same as above. |
| Jitter (packet delay variation) | IPDV ≤ 50 ms (Classes 0 and 1). Vendor flags: 30 ms (Twilio SDK, Plivo Browser SDK, Sinch In-app SDK, Bandwidth target) or 50 ms (Vonage). | ITU-T Y.1541 Table 1; Twilio, Plivo, Sinch, Bandwidth and Vonage docs | Robotic or choppy audio. A jitter buffer turns late packets into lost packets, so jitter shows up in the loss figure. |
| Packet loss | IPLR ≤ 1 × 10−3 (0.1%) for Classes 0 and 1. Vendor flags: 1% (Vonage, Twilio SDK, Sinch In-app SDK, Bandwidth target, although Bandwidth rates only below 0.5% as “Good” and 0.5-1% as “Average”) or 5% (Twilio call tag). | ITU-T Y.1541 Table 1 and Note 4; Vonage, Twilio, Sinch and Bandwidth docs | Clipped words and missing syllables. Our E-model run: G.711 without concealment leaves the “High” band at 0.48% loss. |
| MOS | MOSCQE ≥ 4.03 (R ≥ 80). Vendor flags: below 4 (Vonage), above 4.0 rated “good” (Bandwidth), below 3.5 (Twilio SDK), below 3 (Plivo Browser SDK). | ITU-T G.107 Table B.1; vendor docs | A composite: whichever of the above is worst, plus codec distortion. |
Y.1541’s Note 4 explains the 0.1% figure. The Class 0 and 1 loss objectives “are partly based on studies showing that high quality voice applications and voice codecs will be essentially unaffected by a 10−3 IPLR”. G.113 adds the jitter link: “In systems with a jitter buffer (such as most VoIP applications), the applicable packet loss is measured at the output of the jitter buffer.”
An AI voice agent adds speech recognition, model and synthesis time on top of the network. We break down which legs a vendor’s latency figure includes in what vendor voice-agent latency numbers actually measure.
R-factor to MOS: the worked calculation
We implemented the full G.107 (06/2015) narrowband E-model, equations 7-1 to 7-30 plus Annex B, in a short Python script. As a check, all Table 3 defaults give R = 93.21, which matches the Recommendation’s stated 93.2. We then changed only three inputs: the codec’s impairment factor (Ie and packet-loss robustness Bpl, from ITU-T G.113 Appendix I), the one-way delay, and the random packet-loss percentage.
Assumptions, so you can reproduce it: all other inputs at G.107 Table 3 defaults, including talker echo loudness rating TELR 65 dB, which means echo is well controlled. Mean one-way echo-path delay T is set equal to the absolute delay Ta, and round-trip delay Tr = 2 × Ta, following the scenario notes in G.109 Table 2. Loss is random (BurstR = 1), and G.711 uses 10 ms packets, the packet size G.113 Table I.4 tabulates. G.711 has Ie = 0 with Bpl = 4.3 without concealment, or Bpl = 25.1 with G.711 Appendix I concealment. G.729A with VAD has Ie = 11 and Bpl = 19.0.
Ie-eff, the codec-plus-loss term, comes from G.107 equation 7-29:
Ie-eff = Ie + (95 − Ie) × Ppl / (Ppl / BurstR + Bpl)
Scenario B shows the arithmetic. G.711 with concealment at 1% loss gives Ie-eff = 0 + 95 × 1 / (1 + 25.1) = 3.64. Without concealment the same 1% gives 95 × 1 / (1 + 4.3) = 17.92, almost five times the damage.
| Scenario | Codec | One-way delay | Random loss | Id (delay + echo) | Ie-eff | R | MOSCQE | G.109 band |
|---|---|---|---|---|---|---|---|---|
| A. Domestic call, clean network | G.711 + concealment | 100 ms | 0% | 2.69 | 0.00 | 90.7 | 4.35 | Best |
| B. At G.114’s 150 ms, light loss | G.711 + concealment | 150 ms | 1% | 3.82 | 3.64 | 85.9 | 4.23 | High |
| C. Same network, no concealment | G.711, none | 150 ms | 1% | 3.82 | 17.92 | 71.6 | 3.67 | Medium |
| D. Long inter-regional route | G.711 + concealment | 250 ms | 2% | 14.18 | 7.01 | 72.2 | 3.70 | Medium |
| E. Compressed codec | G.729A + VAD | 150 ms | 1% | 3.82 | 15.20 | 74.3 | 3.79 | Medium |
Ro = 94.77 and Is = 1.41 in every row. Check row A: 94.77 − 1.41 − 2.69 − 0.00 = 90.67, which rounds to 90.7.
The same script gives the crossover points:
- Delay alone: G.711 with no loss falls below R 80 at about 244 ms one-way and below R 70 at about 323 ms.
- Loss at 150 ms, with concealment: R falls below 80 at about 2.8% random loss and below 70 at about 6.5%.
- Loss at 150 ms, no concealment: R falls below 80 at about 0.48% and below 70 at about 1.11%.
The quotable line: in the G.107 E-model, packet-loss concealment is the cheapest quality win available. It moves G.711’s loss tolerance at 150 ms from about 0.48% to about 2.8% before the call drops below R 80.
Three cautions from the Recommendations themselves. G.107 Annex A notes that “the general tendency of the equipment impairment factors is too pessimistic”, so real calls may score a little better. G.113 warns that “the assumption of packet loss independence is unsatisfactory for many real networks”. And G.109 confirms that G.107 covers 3.1 kHz handset telephony and “does not apply to wideband scenarios”.
Building an AI agent that has to sound right on every call? Zian runs AI agents that answer inbound calls 24/7 as an AI receptionist and make outbound calls, booking appointments and following up by SMS, email and WhatsApp, in 30+ languages.
Which codecs reach toll quality, and which go past it?
The codec sets the ceiling before the network takes anything away. G.113 Appendix I gives each narrowband codec’s impairment factor, Ie, and lower is better. G.711 PCM at 64 kbit/s is 0, G.729 Annex A at 8 kbit/s is 10 (11 with VAD), and G.723.1 at 5.3 kbit/s is 19. On a clean network, G.711 starts at the top of the narrowband scale and a compressed codec starts lower.
Wideband, often sold as “HD voice”, changes the scale. ITU-T G.107.1, the wideband E-model, extends the rating to “around Rmax = 129”, which is about 29% more headroom. G.113 Appendix IV then gives wideband impairments on that scale. G.722 at 64 kbit/s scores Ie,wb 13 for handset (monotic) listening and 5 for diotic listening (binaural headsets or speakerphones). Narrowband codecs are penalised by 35.8 points on the same scale, so plain G.711 lands at 93.2 out of 129. G.113 lists no planning value for Opus as at its 09/2024 edition, so Opus quality cannot be estimated this way. It has to be measured.
The catch is that wideband only survives if every leg supports it. Twilio’s call-tag documentation spells this out. Its hd_audio tag counts only AMR-WB or Opus as HD, and a separate downsampled tag marks calls where “the longest portion of the call connected to a component or carrier that didn’t support HD. That audio was converted to narrowband.” Telnyx makes the same point about its media streams: when audio is sent in a different encoding from the call, “it will be transcoded, which may cause a degradation in quality”. For a call that ends on an ordinary phone line, plan on narrowband G.711 as the realistic ceiling. If you stream call audio into an AI pipeline, the streaming codec matters too. We compare Twilio’s and Telnyx’s streaming formats in Twilio vs Telnyx for AI voice agents.
What is the best solution for toll-quality VoIP via API? The provider evidence matrix
How we filled this matrix. One rule applies to every row. A cell states only what that vendor’s own documentation says, read on 26 October 2026. “Codecs” means the codec list each vendor publishes for its SIP or trunking side. “Per-call quality data” means jitter, loss or MOS for an individual call, and we say whether it arrives through a REST API, a webhook, an SDK event or a dashboard, and any plan or add-on it needs. SDK-level data is credited wherever a vendor documents it. “AU / US” means a named media or SIP location in Australia and the United States. Where we searched and found nothing, the cell says so and names what we checked. This is a CPaaS (carrier and voice API) comparison, and it is not ranked.
| Provider | Codecs documented | Wideband codecs | Per-call quality data, and how you get it | MOS reported? | AU / US locations documented | Source |
|---|---|---|---|---|---|---|
| Twilio | Elastic SIP Trunking: PCMU and PCMA generally available. G.729, Opus and AMR-NB in Limited Availability, which Twilio says are “not supported end to end”. Voice JS SDK: Opus and PCMU. | Opus (Limited Availability on trunking; supported in the Voice JS SDK) | Voice Insights Call Summary API: per-edge codec, packets lost, loss %, average and max jitter, plus tags such as high_jitter and high_packet_loss. Twilio says “Voice Insights Advanced Features must be active to use this API Resource”, and Advanced Features are “available at an additional cost”. Voice SDK events flag high jitter, loss and low MOS. |
For Voice SDK calls (warning below 3.5). For carrier and SIP edges the metrics list jitter and loss, not MOS. | sydney, ashburn and umatilla edges, plus sydney-ix private Interconnect |
Call Summary, Call Tags, Codecs, Edges |
| Telnyx | G.711U, G.711A, G.729, G.722, Opus, AMR-WB | G.722, Opus, AMR-WB | call.hangup webhook carries call_quality_stats: inbound jitter, MOS, packet and skipped-packet counts; outbound side, packet counts only. WebRTC JS SDK: live RTT, jitter and packet-loss stats (telnyx.stats.frame) and a LOW_MOS warning. |
Yes, inbound (“Mean Opinion Score (MOS) for inbound audio quality”), plus a LOW_MOS warning (31004) in the WebRTC SDK | SIP regions include US (sip.telnyx.com) and Australia (sip.telnyx.com.au). AnchorSite picks the lowest-latency media PoP by default. | sip.telnyx.com, Call hangup, Call report stats |
| Vonage | PCMA, PCMU, iLBC, G.729 (Annex B and D not supported), G.722, Speex16 | G.722, Speex16 | Voice Inspector (dashboard): MOS, jitter, packet loss and latency per call leg, for calls in the past 21 days. “WebSocket calls do not have any quality data.” We could not find these metrics in the Voice API call resource or webhook reference, as at 26 October 2026. | Yes, for SIP/PSTN legs, in Voice Inspector | Regions include Virginia, Oregon and Sydney (api-ap-4.vonage.com) | SIP details, Voice Inspector |
| Plivo | Zentrunk SIP trunking: PCMA, PCMU | None listed for Zentrunk. Browser SDK: Opus (its configuration docs set an Opus bitrate) | Zentrunk Calls API “Retrieve Call Insights”: per-call RTT, jitter, packet loss, post-dial delay and a 1-to-5 plivo_quality_score. Call Insights console for Voice API calls, although Plivo says its audio quality statistics are “currently only supported for SIP calls made to or from Plivo’s Browser SDK”. Browser SDK events (Chrome only) flag high jitter, loss and low MOS. |
A 1–5 quality score per call (Plivo does not label it MOS); Browser SDK low_mos event below 3 |
Data centres in North California, Virginia and Sydney, among others | Zentrunk Calls API, Tech specs, Call Insights |
| Bandwidth | US: G711ulaw (PCMU), G729a, iLBC. UK: G711alaw (PCMA), G729a. | None listed | Insights API Get Call and List Calls: per-call customer and carrier jitter, latency and packet-loss percentage, plus four MOS fields. The same metrics appear in Voice Insights Call Logs. Bandwidth says voice quality metrics “are available to customers on Bandwidth’s Silver or Gold Customer Success Plans”. | Yes, send and receive MOS toward both the customer and the carrier side, on Silver or Gold plans | Australia and the United States appear on its coverage page. It says it “connects directly to the PSTN where it matters most”. | Codecs, Insights spec, Quality metrics |
| Sinch | G.711u, G.711a, Opus, G.729 | Opus | In-app Calling SDKs raise live warnings for jitter above 30 ms and packet loss above 1%. We could not find a per-call MOS, jitter or loss field in Sinch’s Voice API or Elastic SIP Trunking docs, as at 26 October 2026; its Voice API v2 Analytics Console describes aggregate metrics (answer-seizure ratio, call counts, average durations). | Not found | SIP regions include North America (use1) and Australia (apse2) | SIP trunking, Call quality (SDK) |
| SignalWire | cXML <Sip>: PCMU, PCMA, G722, G729, OPUS (default PCMU, PCMA) | G.722, Opus | Compatibility API Retrieve a Call: audio_in_mos, round-trip time, outbound jitter and outbound packets lost; the voice status callback carries AudioInMos and jitter fields. Voice Analytics Dashboard (announced 23 March 2026): project-level MOS distribution across five tiers. Browser SDK CallNetworkMetrics: live RTT, loss and jitter. |
Yes, inbound audio, in the call resource and status callback | No published media location list for the standard platform: “Media originates from a wide variety of locations and is non-deterministic.” Dedicated Real-Time Regions (announced 3 March 2026) anchor signalling and media in a region the customer chooses. | Retrieve a Call, cXML Sip, Regions |
Read across the table. Four of the seven document a per-call quality score for carrier (SIP or PSTN) calls through an API or webhook: Telnyx (inbound MOS in its call.hangup webhook), SignalWire (inbound MOS in its call resource and status callback), Bandwidth (send and receive MOS in its Insights API, on Silver or Gold Customer Success Plans) and Plivo (a 1–5 quality score, not labelled MOS, from its Zentrunk Call Insights endpoint). Twilio’s paid Call Summary API returns per-call jitter and loss for each edge; MOS appears only for Voice SDK calls, in its Call Metric API and SDK events. Vonage shows per-leg MOS in its Voice Inspector dashboard. Sinch documents live jitter and loss warnings in its In-app Calling SDKs, but we found no per-call quality field in its Voice API or SIP trunking docs. On wideband codecs, Telnyx, Vonage, Sinch and SignalWire document at least one. Twilio offers Opus on trunking only as Limited Availability, and Plivo (Zentrunk) and Bandwidth list narrowband codecs only. Six of the seven name both a US and an Australian location or coverage listing. SignalWire publishes no media location list for its standard platform.
The best route to toll-quality VoIP via API is the provider that meets three tests. First, it has a media location in the same region as your callers. Second, it supports G.711 with concealment, or a wideband codec on legs you control. Third, it gives you per-call quality data you can store and alert on. We count edges and regions per vendor in more detail in voice API global coverage compared.
Who each provider is the wrong choice for
- Twilio is the wrong choice if you need wideband on a SIP trunk without a sales request. Opus on Elastic SIP Trunking is Limited Availability, and Twilio advises requesting it “only if the codec is essential”. It also does not fit if you want MOS for carrier calls in the Call Summary, which reports jitter and loss for those edges (and the Call Summary API itself needs paid Advanced Features).
- Telnyx is the wrong choice if you need a MOS for the audio you send from its standard call webhook. The documented
call.hanguppayload gives MOS on the inbound side and only packet counts outbound. - Vonage is the wrong choice if your AI agent’s audio runs over WebSockets and you need quality data for that leg. Voice Inspector says WebSocket calls carry no quality data, it searches only the past 21 days, and we could not find its metrics in the Voice API itself.
- Plivo is the wrong choice if you need wideband on a SIP trunk. Zentrunk lists PCMA and PCMU only, and its per-call score is Plivo’s own 1–5 rating rather than a labelled MOS.
- Bandwidth is the wrong choice if you need per-call quality data without upgrading your support plan: voice quality metrics are available on Silver or Gold Customer Success Plans. Its codec article also lists no wideband codec.
- Sinch is the wrong choice if per-call quality metrics in the API are a requirement. We could not find a per-call MOS, jitter or loss field in its Voice API or SIP trunking documentation, as at 26 October 2026; its In-app Calling SDKs do raise live jitter (above 30 ms) and packet-loss (above 1%) warnings.
- SignalWire is the wrong choice if you must prove where Australian media is anchored on its standard platform. It publishes no media location list there (“Media originates from a wide variety of locations and is non-deterministic”), although its Dedicated Real-Time Regions offer, announced 3 March 2026, anchors signalling and media in a region the customer chooses.
How do I keep calls at toll quality for Australian callers?
G.114’s Appendix II estimates that VoIP routes of 5,000 km or less within one region “are likely to experience mouth-to-ear delays <150 ms”. For inter-regional calls of 10,000 km or less, the delay “would be approximately 225 ms”. That is close to the 244 ms where our E-model run leaves the “High” band, before any AI processing is added. If your callers are in Australia, anchor media there. The matrix lists each vendor’s Australian location. For the Australian SIP-carrier side of a Twilio build, see SIP trunk providers for Twilio BYOC in Australia.
A five-step check, done once per route before launch:
- Place 50 test calls per route, for example Sydney mobile to Sydney media.
- Pull per-call data from the provider’s own source: Twilio Call Summary, the Telnyx
call.hangupwebhook, Bandwidth’s Insights Get Call, Plivo’s Zentrunk Call Insights, SignalWire’s Retrieve a Call, or Vonage Voice Inspector. - Record the negotiated codec on each leg. A
downsampledtag or a G.711 leg means narrowband. - Compute R from the measured one-way delay and loss with the G.107 equations above. Do not average it with the vendor’s MOS; P.800.1 treats them as different MOS types.
- Pass the route at R ≥ 80 on the 90th-percentile call, not the median.
Where every figure on this page comes from
| Figure | Who published it | Link | Date read |
|---|---|---|---|
| MOS scale Excellent 5 to Bad 1 | ITU-T P.800 (08/96) | itu.int/rec/T-REC-P.800 | 26 October 2026 |
| MOS-LQS / LQO / CQE terminology | ITU-T P.800.1 (07/2016) | itu.int/rec/T-REC-P.800.1 | 26 October 2026 |
| E-model formula, R = 93.2 default, MOSCQE formula, R 90/80/70/60/50 to MOS 4.34/4.03/3.60/3.10/2.58 | ITU-T G.107 (06/2015) | itu.int/rec/T-REC-G.107 | 26 October 2026 |
| Quality categories; “toll quality” has no absolute relation | ITU-T G.109 (09/99) | itu.int/rec/T-REC-G.109 | 26 October 2026 |
| 150 ms transparent interactivity, 400 ms planning limit, ~225 ms at 10,000 km | ITU-T G.114 (05/2003) | itu.int/rec/T-REC-G.114 | 26 October 2026 |
| Ie: G.711 0, G.729A 10/11, G.723.1 19; Bpl 4.3, 25.1, 19.0; G.722 Ie,wb 13/5; narrowband +35.8 | ITU-T G.113 (09/2024) | itu.int/rec/T-REC-G.113 | 26 October 2026 |
| Wideband R scale to about 129 | ITU-T G.107.1 (06/2019) | itu.int/rec/T-REC-G.107.1 | 26 October 2026 |
| IPTD 100/400 ms, IPDV 50 ms, IPLR 1 × 10−3 | ITU-T Y.1541 (12/2011) | itu.int/rec/T-REC-Y.1541 | 26 October 2026 |
| R values for scenarios A–E and crossovers (about 244 ms, 2.8% and 0.48%) | Zian calculation from the G.107 and G.113 values above (method and assumptions on this page) | This page | 26 October 2026 |
| Twilio thresholds: jitter 30 ms, loss 1% / 5%, MOS 3.5, RTT 400 ms; HD = AMR-WB or Opus | Twilio | Call Tags, SDK events | 26 October 2026 |
| Twilio codecs, edge locations, Call Summary API needs Advanced Features | Twilio | Codecs, Edge Locations, Call Summary | 26 October 2026 |
| Telnyx codecs, SIP regions, MOS in call.hangup, WebRTC SDK stats and LOW_MOS warning | Telnyx | sip.telnyx.com, Call hangup, Call report stats, Error handling | 26 October 2026 |
| Vonage codecs, regions, MOS below 4, jitter 50 ms, loss 1%, latency 100 ms, 21 days | Vonage | SIP details, Voice Inspector, Regions | 26 October 2026 |
| Plivo codecs, data centres, per-call RTT/jitter/loss and 1–5 quality score, SDK thresholds 30 ms / 10% / 20% / MOS 3 | Plivo | Zentrunk Calls API, Tech specs, Call Insights, Browser SDK | 26 October 2026 |
| Bandwidth codecs (US PCMU/G729a/iLBC, UK PCMA/G729a); per-call jitter, latency, loss and MOS; Silver/Gold plan gating; targets 30 ms / 150 ms / 1% / MOS above 4.0; network and coverage | Bandwidth | Codecs article, Insights API spec, Release note, 29 July 2026, Quality metrics article, Network, Coverage | 26 October 2026 |
| Sinch codecs, SIP regions, SDK warnings at 30 ms jitter and 1% loss | Sinch | SIP trunking, Call quality (JS SDK) | 26 October 2026 |
| SignalWire codecs, per-call MOS fields, dashboard MOS tiers, media locations, Dedicated Real-Time Regions | SignalWire | cXML Sip, Retrieve a Call, Status callback, Analytics blog, Regions blog, Firewall | 26 October 2026 |
Frequently asked questions
What MOS score counts as toll quality?
There is no official cut-off. ITU-T G.109 says the term “toll quality” has no absolute relation to speech quality today. The working equivalent is the G.109 “High” band: an E-model rating of R 80 or more, which ITU-T G.107 Table B.1 maps to an estimated conversational MOS of 4.03.
What is the maximum latency for toll-quality VoIP?
ITU-T G.114 says most applications see essentially transparent interactivity if one-way, mouth-to-ear delay stays below 150 ms, and it sets 400 ms as the general planning limit. In our G.107 calculation, a G.711 call with no packet loss stays at R 80 or above up to about 244 ms.
How much packet loss can a VoIP call take before quality drops?
ITU-T Y.1541 sets a loss objective of 0.1% for its real-time voice classes. In our G.107 calculation at 150 ms one-way delay, G.711 with packet-loss concealment stays at R 80 or above up to about 2.8% random loss, and G.711 without concealment only up to about 0.48%. Bursty loss does more damage than random loss.
Which voice API reports MOS for each call?
Of the seven we checked on 26 October 2026, four document a per-call quality score for carrier calls through an API or webhook. Telnyx returns an inbound MOS in its call.hangup webhook, as its call hangup API reference shows, and SignalWire returns an inbound MOS in its call resource. Bandwidth’s Insights API returns send and receive MOS on Silver or Gold Customer Success Plans, and Plivo’s Zentrunk API returns its own 1–5 quality score. Twilio reports MOS for Voice SDK calls, Vonage shows MOS in its Voice Inspector dashboard, and we found no per-call MOS field in Sinch’s Voice API.
Is G.722 or Opus better than G.711 for VoIP calls?
On a wideband path, yes. ITU-T G.107.1 extends the rating scale to about 129, and G.113 rates G.722 well above G.711 on that scale. But wideband survives only if every leg supports it. Twilio, for example, tags calls “downsampled” when the longest portion ran through a component or carrier without HD support. For calls with a narrowband leg, G.711 with packet-loss concealment is the realistic ceiling.
Does a MOS from my provider match an E-model MOS?
Not necessarily. ITU-T P.800.1 separates subjective, objective and estimated MOS types, and vendors do not all publish how they compute theirs. Compare each provider’s MOS only with itself over time, and use the E-model to check whether your measured delay and loss should land in the R 80 band.
Want the AI agent without building the voice stack? Zian answers inbound calls 24/7 as an AI receptionist, runs outbound follow-up across calls, SMS, email and WhatsApp, and books appointments. It is in a partnership-application beta.