Quick answer
Robotic and choppy are two different faults. Twilio documents them separately: jitter “results in noisy or robotic-sounding audio”, packet loss “results in choppy audio”. It tags a non-SDK call once cumulative packet loss exceeds 5%, or once average jitter exceeds 5 ms with max jitter above 30 ms. Read the carrier tags first, then the mark clock.
The sentences people actually type are “why does my AI voice agent sound robotic” and “our AI agent’s audio keeps cutting out on calls”. Those are two diagnoses, not one, and the carrier publishes the numbers that separate them. Every figure below comes from Twilio’s Voice Insights Call Summary, its Voice Insights FAQ, the Twilio Media Streams specification, or the Pipecat issue tracker.
Two boundaries. If the agent is slow to reply rather than degraded, that is timing — start at why sub-second responses matter in voice AI. If audio stops entirely, how to build failover into an AI voice agent owns trunk, transcriber, voice and model fallback in full, and this page does not repeat it.
Robotic means jitter, choppy means packet loss — the carrier says so
Twilio puts the mapping in plain words on its Voice Insights FAQ: “when people talk about ‘choppiness’ on a call what they are actually talking about is packet loss. When they talk about ‘noise’ or ‘robotic speech’ they are almost certainly talking about jitter. Many reports of ‘one-way audio’ and ‘dropped calls’ are really high post-dial delay.”
That is the first triage step and it costs nothing: ask which word the complaint used. Robotic and crackly points at jitter, the variation in packet arrival times. Stuttering and cutting out points at packet loss. Long gaps with both parties talking over each other points at latency, which is not an audio-quality fault at all.
Network checks come before software checks here on the carrier’s own frequency claim, not ours: Twilio says “our analysis of hundreds of billions of calls over more than ten years supports the theory that network transport issues are the number one contributor to reports of audio quality degradation for VoIP calls.”
What Twilio tags, at what value, and what the caller hears
Every value below is verbatim from the Twilio Voice Insights Call Summary page or its FAQ, both read 20 September 2026. These six are the ones that bear on audio; Twilio also publishes ICE Failure (Voice SDK only), post-dial-delay and short-duration tags. The last column is the part the two pages never put side by side: the value Twilio tags at sits deliberately below the value at which it says a human notices.
| Tag | Applies to | Published tagging threshold, verbatim | What the caller hears, and where Twilio puts perception |
|---|---|---|---|
| Packet Loss Detected | All calls | “cumulative packet loss >5% for non-Voice SDK calls; >1% for 3 out of 5 consecutive samples for Voice SDK calls” | “Packet loss results in choppy audio.” Perception: “>5% is going to result in noticeably choppy audio” |
| Jitter Detected | All calls | “more than 1% of the packets are delayed by 200ms, or if the average jitter is greater than 5ms and max jitter is >30ms for non-Voice SDK calls; max jitter >30ms for 3 out of 5 consecutive samples for Voice SDK calls” | “Jitter results in noisy or robotic-sounding audio.” Perception: “average jitter >5 is going to result in robotic audio” |
| Low MOS | “Voice SDK only” | “true if MOS <3.5 for 3 out of 5 consecutive samples” | Derived, not heard: “a function that takes jitter, packet loss, and round trip time as inputs”. Good is “4.2 or higher” |
| High Round Trip Time | “Voice SDK only” | “true if RTT > 400 ms for 3 out of 5 consecutive samples” | Turn collision, not distortion. Perception: “RTT > 1000 ms is going to result in people either talking over each other or long periods of silence” |
| High latency (Twilio RTP Latency) | All calls | tagged “if the Twilio-internal RTP time for outbound packets received at the media edge for a call SID is greater than 150ms” | “long delays between speakers or speakers talking over each other”. No perception figure published |
| Silence Detected | All calls | “true in the event of a missing RTP stream or total silence from one of the parties” | “may be reported as dead air or dropped calls”. Twilio warns “silence detection is not the same thing as human speech detection” |
Twilio explains the gap: its thresholds are “based of ITU-T standards for VoIP quality, and do indeed lean toward sensitivity”, set “at-or-below the edges of perceptibility … before users notice”. A tagged call is therefore not automatically a call anyone complained about — that is deliberate design, not a false positive.
Why there is no MOS score on a SIP-trunked agent, and what to use instead
The standard advice for robotic audio is to check the mean opinion score. On a telephony AI agent there usually is not one. Twilio scopes three of its tags explicitly: Low MOS is prefixed “Voice SDK only”, and so are High Round Trip Time and ICE Failure. A Voice SDK call is a browser or mobile app using Twilio’s client library; an agent on a SIP trunk or a Media Streams WebSocket is not one.
The field list agrees. Twilio documents “four possible edges: carrier_edge, client_edge, sdk_edge, and sip_edge. SIP trunking calls will have both a carrier_edge and a sip_edge.” The SDK Edge Metrics object documents mos and rtt. The generic Edge Metrics object, used by the other three edges, documents nine fields and neither of those is among them: codec, codec_name, packets_received, packets_sent, packets_lost, packets_loss_percentage, jitter, latency and packet_delay_variation. Take that as a statement about documented fields rather than about Twilio’s internals — the same page mentions MOS once more, in an aside about transcription accuracy, without scoping it.
Two further Twilio pages settle it. Its Call Tags reference enumerates the tags twice, and the carrier, client and SIP list runs silence, high_jitter, high_packet_loss, high_pdd, high_latency, pstn_short_duration — low_mos is only in the separate SDK edge list, where high_latency also means RTT above 400 ms rather than 150 ms of internal traversal, so one tag string means two things depending on the edge. Its Call Metrics resource gives the per-interval payload as “sdk_edge: audio in/out, jitter, packet loss, rtt, and packet loss percentage for the sampling interval. All other edges: packets received, packets lost, and packet loss percentage”.
So substitute. packet_delay_variation is a “Distribution of packets delayed by a certain value; e.g. "d50": 24 indicates that 24 packets were delayed by more than 50 ms” — which is exactly what the jitter tag’s first limb is computed from. Take packets_received and the bucket for packets delayed past 200 ms from the same edge and divide: above 0.01, the limb “more than 1% of the packets are delayed by 200ms” is met. One caveat: "d50" is the only bucket key Twilio publishes, and only as an example, so read the keys your own response returns rather than assuming a d200 exists. With placeholder inputs to show the shape, 212 / 14,832 = 1.43% meets it; 140 delayed packets against the same 14,832 gives 0.94% and does not. The tag’s second limb is independent and needs both parts: average jitter above 5 ms and max jitter above 30 ms. Substitute your own two numbers and you have recovered the decision the missing MOS score was meant to give you.
The 50-second blind spot: why a three-second burst never shows up
Two Twilio sentences on two pages combine into a limit neither page states on its own. The Call Summary page writes the sampled form of its thresholds as “3 out of 5 consecutive samples”, inside the Voice SDK limbs. The FAQ then asks the question itself — “When we say ‘packet loss > 1% in 3 out of last 5 samples’, what’s a ‘sample’?” — and answers for both call types: “For Voice SDK calls we sample each second; for Carrier and SIP calls we sample the cumulative stats for the previous 10 seconds every 10 seconds.”
Multiply it out. On a Voice SDK call, five consecutive samples cover five seconds. On a carrier or SIP call — which is what an AI voice agent is — five consecutive samples cover 50 seconds, each a ten-second cumulative average. Be exact: Twilio prints the 3-of-5 form in the Voice SDK limbs and publishes the non-SDK packet-loss threshold as cumulative over the whole call, so 50 seconds is the granularity its own sample definition gives a SIP leg, not a tagging window it prints for one. Either way the burst is diluted. On a four-minute call, three seconds of total loss is 1.25% cumulative, a quarter of the 5% the tag needs — and three seconds of dropped audio is plenty for a caller to say the line cut out. The arithmetic is ours; both inputs are Twilio’s.
Twilio publishes three further limits on its own instrumentation: echo “or noise that is not related to jitter or packet loss, can’t be detected by Voice Insights today”; “degradation introduced on the way to the destination due to poor signal strength or a carrier issue would be transparent to Voice Insights today”; and, asked how anyone can know for sure that a user experienced a detectable issue, “The short answer is, we can’t.” The rule that falls out: an untagged call is not an exonerated call. A clean Call Summary narrows the fault; it never clears it.
The mark-clock test: network cause or software cause
This test is in neither vendor’s documentation, because it needs both sides read together: Twilio’s wire format and playout clock on one, your framework’s own accounting on the other. Twilio’s Media Streams specification fixes the wire format: outbound, “The payload must be encoded audio/x-mulaw with a sample rate of 8000 and must be base64 encoded”; inbound, the sample rate “is always 8000” and channels “is always 1”. Mu-law is one byte per sample, so 8,000 bytes is exactly one second of audio. Count decoded bytes — base64 is four characters per three bytes, so a character count overstates duration by a third.
Twilio then hands you a playout clock: “When your server sends a media message, it should then send a mark message to Twilio. When that media message’s playback is complete, Twilio sends a mark message to your server using the same mark.name as the one your server sent.” Media messages “are buffered and played in the order received”. The mark is a statement about what the caller heard, measured at the carrier — not about what your framework believes it did. Two limits, both Twilio’s own: “Twilio sends the mark event only during bidirectional Streams”, so a plain SIP trunk with no media stream gets the carrier tags and the edge comparison but not this test; and a mark returns immediately “if there is no audio buffered”, which reads as a ratio well below 1.0.
The mark-clock test. For one agent utterance, record when you sent the first media message, the decoded mu-law byte count for the whole utterance, and when Twilio returned the final mark. Then:
expected_seconds = decoded_bytes / 8000
ratio = (mark_returned_at − first_media_sent_at) / expected_seconds
| What you observe | What it rules out | What it points at | The next test |
|---|---|---|---|
| Ratio near 1.0, and a Jitter or Packet Loss tag on the call | Your pipeline. The bytes went out and played at playout rate | Network, between the media edge and the caller | Compare edges: on a trunking call read sip_edge against carrier_edge |
| Ratio near 1.0, Call Summary clean, caller insists | Nothing yet — this is the 50-second blind spot, or a class Twilio publishes as undetectable | Short-burst loss below the tag, or in-stream damage: echo, gain, or resample artefacts inside bytes that arrived intact | Pull the recording and listen. Twilio says these “may be captured in any recordings of the calls” |
| Your framework reports the bot finished speaking well before the final mark returns | The network. Playout is proceeding normally at the carrier | Your transport is not pacing output. The caller is still listening; your agent has moved on | Check your framework version against the table below |
| A local recording has gaps the caller never reported | The caller’s experience. A broken recording is not a broken call | A downstream consumer of audio frames, not the wire | Compare decoded bytes on the wire against the recording length |
One line to keep: the caller’s clock is the mark, not your frame.
That third row exists because of a dated, public regression, and it is the archetype of a software cause with clean carrier metrics. Pipecat issue #5592, opened 2 September and closed 11 September 2026, reported that the WebSocket transports returned early from write_audio_frame without pacing whenever the serializer produced no payload — not an error path, because the telephony serializers resample through a stream resampler that buffers audio across calls. In the words of merged pull request #5593, “on any pipeline whose output rate differs from the wire rate (the 24kHz default against a provider’s 8kHz) most frames took that path”. The reporter’s own measurements, not ours: 44 of 151 writes paced against 151 of 151 on 1.4.0, the output queue draining “about 3.5x faster than playout”, and on an eleven-second utterance the bot-stopped-speaking signal firing after 3.2 seconds.
The diagnostic value is in the next sentence: “All of the audio still reaches the wire. Byte-identical in both versions, 47300 bytes of mu-law either way, so nothing is dropped from the caller’s side.” At 8,000 bytes per second that is 47,300 / 8,000 = 5.91 seconds of audio, all delivered — so the carrier clock stays honest while the framework clock runs more than three times fast. That inference is ours, from Twilio’s documented mark behaviour and Pipecat’s byte measurement, not a measurement we made. It is also why an offline eval suite can pass while real calls fail: a harness that never opened a mu-law 8 kHz stream cannot reproduce a fault that only exists on the resample path.
The software causes, in the order the published record puts them
This order follows what the published defaults make likely, not a measured incidence rate, and we will not invent one. Re-order it once you have counts from your own calls.
| Cause | Caller-audible symptom | The tell | Published state |
|---|---|---|---|
| Pipeline output sample rate differs from the wire rate, so every frame takes the stream-resampler path | Agent talks over the caller because it believes it finished speaking; recordings gappy | Framework signals bot-stopped-speaking early; final mark returns much later; wire bytes intact | Pipecat #5592, fixed by PR #5593 merged 11 September 2026, first shipped in v1.10.0 on 12 September 2026 |
| Transport pacing interacting with a websocket TTS service, producing intra-word gaps | Short gaps between words; the reporter’s words were “choppy and crackly” | Gaps in the caller’s audio but not in a local recording of the same call. Mind the direction: on the published case the gaps were there with pacing at its default and vanished when the reporter set the sleep to 0, the opposite way round from the row above | Pipecat #3315, reported on 0.0.94, opened 29 December 2025 and closed 1 July 2026 with no code change, after a staleness prompt went unanswered: gaps of 100 ms to 350 ms. Do not copy the reporter’s workaround — a Pipecat contributor on the thread: “We need to pace the audio output from the transport in order to interrupt the bot. Without this, interruptions will not work correctly.” |
| Speech-to-text service pinned to the wrong input sample rate | Audio sounds fine; the agent mishears | Clean tags, ratio near 1.0, degraded transcript. A recognition fault, not a playback fault | Pipecat #5290, opened and closed 11 August 2026: a constructor default of 16000 overrode a pipeline set to 8000, with “no resampling in this path”. Fixed by PR #5298, first shipped in v1.8.0 on 26 August 2026 |
| In-stream damage: echo, gain, room noise | Noise that is not jitter, or the agent hearing itself | Twilio publishes this as a gap in its own detection, so the tags will never show it | Twilio: echo “or noise that is not related to jitter or packet loss, can’t be detected by Voice Insights today” |
Two of those four have a version number as the fix, which is the cheapest outcome available, and the two boundaries do not overlap. On a Pipecat build from 1.8.0 up to and including 1.9.0 with an output rate other than 8 kHz, the first row is live on your stack; on anything before 1.8.0 the third row is, whatever the output rate. Either way the remedy is an upgrade, not a tuning exercise. If the transcript is what is wrong rather than the audio, the trigger field on Deepgram Flux end-of-turn events is where that diagnosis starts instead.
Diagnose it yourself, or hand the monitoring over
All of the above runs this afternoon on a stack you already have, and none of it requires buying anything. What it costs to keep running is the honest part.
| Your situation | Do it yourself | Hand it over |
|---|---|---|
| One number pool, one carrier, occasional complaints | Yes. Read the tags on the calls people complained about, run the mark clock once, done | Not worth it |
| You want the mark ratio on every call, not just complaints | Workable: a timer and a byte counter per utterance, plus somewhere to keep the ratio | Marginal |
| Several countries and carriers, media in more than one region | Costly. Each carrier leg needs its own baseline before a tag means anything | Reasonable |
| Call audio cannot leave your infrastructure, so recordings cannot go to a third party | Only if the analysis runs inside the boundary too | Only to a platform that deploys inside it |
That last row decides more evaluations than the rest combined, because listening to a recording is the documented fallback for every fault Twilio says its tags cannot see, and a recording is the most sensitive artefact a voice programme produces. Zian AI runs live phone, SMS, email and WhatsApp agents in 30+ languages and supports private model deployment on customer infrastructure, which keeps that fallback available without shipping audio out of the building. What an agentic voice platform takes on is set out on the Zian AI solutions overview, and the rest of this cluster sits on the Zian AI questions and answers hub.
Either way, run the mark clock once before launch rather than during an incident — it belongs in the same pass as testing an AI voice agent before go-live, because a scripted call with one long agent utterance is the only reliable way to produce the measurement.
Frequently asked questions
Why does my AI voice agent sound robotic?
On a VoIP call, robotic almost always means jitter rather than a poor voice model. Twilio states that jitter results in noisy or robotic-sounding audio, and tags a non-SDK call when more than 1% of packets are delayed by 200ms, or when average jitter is greater than 5ms and max jitter is above 30ms. Its FAQ puts the perceptible point at average jitter above 5ms. Check the carrier tags before you change a voice.
My AI agent audio keeps cutting out on calls. Is it the network or my code?
One test separates them, and it needs a bidirectional Media Stream, because Twilio sends the mark event only during bidirectional Streams. Count the decoded mu-law bytes of one agent utterance, divide by 8000 for its duration in seconds, and compare that against the wall-clock time Twilio takes to return the mark for the last media message of that utterance. A ratio near 1.0 means the caller heard the whole thing at playout rate, so look at the network. A framework that reports the bot finished speaking long before that mark comes back has a pacing fault in your own transport.
Why is there no MOS score for my AI voice agent calls?
Because Twilio documents the Low MOS tag as Voice SDK only, and an agent on a SIP trunk or a Media Streams WebSocket is not a Voice SDK call. Twilio also enumerates the tags for the carrier, client and SIP edges separately, and low MOS is not among them. The generic Edge Metrics object used by those three edges documents packets lost, packet loss percentage, jitter, latency and a packet delay variation histogram, and no MOS or RTT field. Use the histogram instead: divide the bucket for packets delayed past 200 ms by packets received and compare against the published 1% limb. Twilio publishes one example bucket key, d50, so read the keys your own response returns.
Can a short burst of bad audio show up as clean in Twilio Voice Insights?
Yes, and the arithmetic is public. Twilio samples Voice SDK calls every second but samples carrier and SIP calls as the cumulative stats for the previous 10 seconds, every 10 seconds, so five consecutive samples span 50 seconds of call on a SIP leg. Twilio prints the 3 out of 5 consecutive samples form inside the Voice SDK limbs of its tags, and the threshold it publishes for non-SDK packet loss is cumulative across the whole call, so three seconds of total loss on a four-minute call is 1.25% against a 5% threshold. A clean record narrows the fault; it does not clear it.
Which Pipecat versions carry the output pacing fault?
It reproduced on 1.8.0 and on main, and the fix was merged on 11 September 2026 in pull request 5593. The first tagged release containing that commit is v1.10.0, published 12 September 2026, so builds from 1.8.0 up to and including 1.9.0 carry it. It only bites when the pipeline output sample rate differs from the wire rate, which for telephony means any output rate other than 8000 Hz.
Where every figure on this page comes from
| Figure or quotation | Who published it | Link (their own page) | Date read |
|---|---|---|---|
| All six tag definitions and thresholds; the choppy and robotic-sounding wording; the four edges | Twilio | Voice Insights Call Summary | 20 September 2026 |
| High latency above 150ms; the 1-second and 10-second sampling intervals; perception at 5% loss, 5ms jitter and 1000 ms RTT; choppiness-is-packet-loss and robotic-is-jitter; ITU-T basis; undetectable echo; no visibility past the media edges | Twilio | Voice Insights FAQ | 20 September 2026 |
| Edge Metrics field list with no MOS or RTT; SDK Edge Metrics MOS scale of 0-5; the packet_delay_variation description | Twilio | Call Summary API details | 20 September 2026 |
| Wire format always mu-law at 8000 Hz, one channel; outbound payload rules; the mark returned when playback completes; media buffered and played in order | Twilio | Media Streams WebSocket messages | 20 September 2026 |
| Tag list for carrier, client and SIP edges with no low_mos and no RTT; the separate SDK edge tag list | Twilio | Details: Call Tags | 20 September 2026 |
| Per-interval payload: rtt for sdk_edge only, “All other edges: packets received, packets lost, and packet loss percentage” | Twilio | Call Metrics Resource | 20 September 2026 |
| Pacing skipped on buffered serializer output; 44 of 151 writes paced; 3.5x drain; 3.2 s signal on an 11 s utterance; 47300 bytes byte-identical | dileep-chagam, reporting on the Pipecat issue tracker | Issue #5592 | 20 September 2026 |
| “the 24kHz default against a provider’s 8kHz”; merged 11 September 2026 | omChauhanDev, in the pull request a Pipecat maintainer then merged | Pull request #5593 | 20 September 2026 |
| First tagged release carrying the pacing fix | Pipecat project (pipecat-ai) | Release v1.10.0 | 20 September 2026 |
| First tagged release carrying the AssemblyAI sample-rate fix (PR #5298) | Pipecat project (pipecat-ai) | Release v1.8.0 | 20 September 2026 |
| Gaps of 100 ms to 350 ms reported with pacing at its default; the contributor comment of 22 January 2026 on why the pacing is required | jeekhof-lumeris (report) and markbackman (comment), on the Pipecat issue tracker | Issue #3315 | 20 September 2026 |
| Constructor default of 16000 overriding a pipeline set to 8000, “no resampling in this path” | timofey-TK, reporting on the Pipecat issue tracker | Issue #5290 | 20 September 2026 |
Three figures here are ours, and all three are arithmetic over published inputs: 47,300 mu-law bytes at 8,000 bytes per second gives 5.91 seconds; five ten-second samples give the 50-second window; three seconds of loss in four minutes gives 1.25%. The packet counts in the histogram example are placeholder inputs to replace, not a measurement, and the 200 ms bucket key is ours to look up rather than Twilio’s to publish.
Robotic is jitter, choppy is packet loss, and the mark clock tells you whether either of them is your own code. If you would rather have that instrumented on every call than reconstructed after a complaint, Zian AI is in partnership-application beta. Apply For Partnership.