Troubleshooting: voice call quality — one-way audio, dead air, jitter, and PDD

A call-quality complaint is different from a call that never connects: the call answers, the parties are on the line, and the audio itself is broken — one side hears nothing, both sides hear nothing, the speech chops and drops, or it took far too long to start ringing. None of those are fixed by re-registering a trunk or retrying the dial. Each quality class maps to a specific layer — SIP signalling, the media path, the carrier route, or the client network — and this page works each one as a decision path. For a trunk that will not register or will not fail over, see Troubleshooting: SIP trunk registration, health, and failover instead; this page starts where that one ends — at a call that sets up.

Symptom → layer index

Find the symptom row first, then go to the section below that works that layer.

Symptom	Layer that causes it	Go to
One-way audio — one side hears, the other does not	Media path — RTP blocked or mis-addressed in one direction (NAT, SIP ALG, or an SRTP keying mismatch)	One-way audio
Dead air after connect — the call answers, both sides hear nothing	Media negotiation or media security — codec or SRTP mismatch that signalling still completed (`200 OK` carries no audio guarantee)	Dead air after connect
Choppy, robotic, or jittery audio	Client network or route media path — packet loss and jitter on the RTP stream	Choppy audio
Long ring-delay (high PDD) — seconds of silence after dialling before ringback	SIP signalling across the carrier route — not the audio path	High PDD / long ring-delay
Echo — the far end hears itself	Far-end device or carrier route — the endpoint returning the stream, not the platform	Echo

One rule cuts most triage time in half: PDD and ring-delay are signalling problems; everything else above is a media problem. The PDD glossary entry makes the same distinction — setup time is driven by SIP across the carriers, never by the audio stream.

One-way audio

One side hears the other perfectly; the reverse direction is silent. The call always answers and the signalling always looks clean — which is why this fault confuses: SIP and RTP are separate paths. A firewall that passes SIP on 5060/5061 can still drop or mis-route the media stream, and the call connects anyway. Work the decision path in order:

Is it exactly one direction, and always the same direction? Then the cause is almost always address translation on the silent side. A SIP endpoint (PBX, SBC, desk phone) embeds its own address inside the SDP body of the INVITE/answer — and if that device is behind NAT and advertises its private address, the far side sends RTP to an address that cannot be reached. Audio then flows inbound but not back: classic one-way audio. The NAT glossary entry covers why real-time media needs a routable advertised address, and the SIP trunk troubleshooting page covers the signalling half of the same problem.
Does it correlate with the customer’s firewall, not one PBX? Check for a SIP ALG (Application Layer Gateway) on the router or firewall between the customer’s network and the platform. SIP ALG rewrites the SDP addresses “to help” and routinely rewrites them wrong — mangling one media direction. Disabling SIP ALG on the customer firewall is the single highest-hit-rate fix for one-way audio on a site where the PBX itself is configured correctly.
Only on TLS trunks, and only after a TLS change? Then treat it as an SRTP keying mismatch. On a TLS trunk the media keys ride the encrypted signalling, and a carrier that declines SRTP — or offers a keying mode the trunk did not accept — produces exactly this shape: registration green, calls connect, one or both directions silent. The full decision tree is in the TLS and SRTP section of Troubleshooting: SIP trunk registration, health, and failover: registration succeeds, calls connect with no audio, and the fix lives in the carrier’s media-security setting, not the codecs.

On your own SBC/PBX side, two checks close out most remaining cases: confirm both media directions are allowed through the SBC (whitelisting only the signalling edge passes SIP and drops RTP), and confirm the PBX advertises a routable IP in SDP rather than an internal one — the RTP / media section of the SIP trunk connection guide walks both.

Dead air after connect

The call answers — 200 OK, ACK, both legs up — and neither side hears anything. Here the signalling is genuinely done, so the cause sits in what the signalling negotiated:

SIP exchange	What actually happened	Where to look
`INVITE` → `488 Not Acceptable Here`	Codec mismatch caught at setup — the carrier rejected every offered codec, so no call exists. This is a signalling-visible failure, not dead air	Enable at least one of OPUS, PCMU, or PCMA on the carrier side — the codecs Orbit negotiates; see the codec question in the FAQ
`INVITE` → `200 OK` → silence both ways	Negotiation “succeeded” but produced an unusable media path: the sides settled on a codec one of them cannot actually send (a carrier-side transcoding failure), or SRTP keying failed after the 200 OK — keys mismatch, every media packet is discarded, both directions dead	Read the negotiated codec off the call (below) and compare it against what both ends genuinely support; on TLS trunks, apply the SRTP decision path linked above
`INVITE` → `200 OK` → dead air only on a TLS trunk	The carrier’s media-security setting — SRTP declined or keying refused — with signalling unaffected	The carrier’s media-security setting on the trunk, per the SRTP section of the SIP trunk page

The distinguishing check for this class: a 488 means the codec problem surfaced in signalling (the call never existed); dead air means the same family of problem surfaced after 200 OK (the call exists but carries nothing). Do not treat the second as a trunk health problem — the trunk is fine, the negotiated media is not.

Choppy audio: packet loss and jitter

The call connects and both sides hear — but the speech chops, drops syllables, or turns robotic. This is the media stream degrading in flight: packets lost, or arriving too unevenly for the jitter buffer to absorb. The thresholds the platform itself alarms on frame what “bad” means: MOS below ~3.5 sounds dissatisfied, packet loss above ~5% chops audibly, and sustained jitter above ~30 ms strains the buffer. Do not open a ticket with “audio was choppy” and nothing else. Capture the per-call evidence first — it is already collected:

Dashboard: open the Voice → Quality view. The worst-calls table lists the lowest-MOS calls in the window with the exact fields support needs; the aggregates charts show whether the problem follows one carrier or one trunk across the day.
API: pull the day’s worst calls, then drill into one:

curl "https://api.orbit.devotel.io/api/v1/voice/quality/worst-calls?days=7&limit=10" \
  -H "X-API-Key: $ORBIT_API_KEY"

Each row carries the measured quality set for one call — a per-call sample looks like:

{
  "call_id": "call_abc123",
  "carrier": "carrier-eu-2",
  "mos_score": 2.9,
  "jitter_avg_ms": 48.2,
  "packet_loss_pct": 7.8,
  "rtt_avg_ms": 121.4,
  "codec": "OPUS",
  "hangup_cause": "NORMAL_CLEARING",
  "recorded_at": "2026-08-24T14:03:11Z"
}

How to read it before escalating:

Loss/jitter high on one carrier, others clean in the same window — the route, not the client’s network. Query GET /api/v1/voice/quality/carriers over the same window and compare; the per-trunk route-quality view described in Troubleshooting: SIP trunk down or calls failing then tells you whether shifting traffic off that trunk is safe.
Loss/jitter on every carrier, clustered at one site or one agent — the client’s network (Wi-Fi, a saturated uplink, a local QoS gap). No trunk change will fix that; the evidence pattern is what tells you.
MOS low with zero loss and low jitter — suspect the negotiated codec on the row rather than the network: a transcoded or mismatched codec path degrades perceived quality without dropping packets.

High PDD / long ring-delay

The caller dials, then hears seconds of silence before ringback starts — or before the far end answers. Per the PDD glossary entry, post-dial delay is a setup-phase metric: it is driven by SIP signalling across the carriers between origination and termination, not by the audio path. That one fact drives the whole diagnosis:

High PDD is never a media problem. Jitter buffers, codecs, RTP pinholes — none of them start until the far end answers. If the complaint is “it takes too long to ring,” work the signalling route, not this page’s media sections.
Consistently high PDD on one trunk or one destination region is the classic early sign of a congested or poorly-routed trunk. Confirm which: query the per-trunk /api/v1/voice/sip-trunks/route-quality snapshot. A trunk whose capacity utilization is saturating at the same time PDD climbs is congested; a trunk with clean capacity but a falling answer ratio is a carrier dropping the route. The remedies — failover chain and traffic weights — are in the route-quality and failover sections of the SIP trunk troubleshooting page.
A sudden PDD spike across every trunk at once points past the trunks — check the status page and any listed carrier incident before redistributing traffic, and only then treat it as route congestion.

Echo

One side hears their own voice returned a moment after speaking. Echo is almost never introduced mid-path: the far-end device (handset, headset, speakerphone) or the terminating carrier route is reflecting the stream, and the platform’s media plane is passing it through faithfully. Isolate it by changing one endpoint variable at a time — different handset, headset instead of speakerphone, different far-end number. If echo follows a specific destination region rather than a device, capture the call per the checklist below and escalate it as a carrier-route problem.

What to capture before escalating

Work the relevant section first; if the symptom persists, open a ticket with the full set below — it mirrors what the trunk pages ask for, and it is what lets support pull the exact call without a back-and-forth:

Call ID (call_…) of one affected call — the worst-calls table and the call detail both show it.
Trunk ID (trunk_…) the call routed on, if it went over your own SIP trunk.
Direction — outbound, or inbound on an incoming trunk.
Codec negotiated for the call (visible on the worst-calls row — codec — or on the call detail).
The per-call quality row from GET /api/v1/voice/quality/worst-calls?days=7 — MOS, jitter, packet loss, RTT — or the dashboard equivalent.
Your organization ID (Settings → Organization, or organizationId from GET /api/v1/me).
For PDD complaints, the destination number and how long the delay was — “answers after ~9 seconds of silence” narrows the route faster than “slow to connect.”

What not to do

Do not re-INVITE, re-register, or re-create the trunk for a media problem. Registering the trunk again changes nothing on the RTP path — signalling was already succeeding. Worse, blind re-registration rotates credentials mid-flap and mixes two failure modes, exactly the anti-pattern the SIP trunk page calls out for registration faults. Fix the named media cause, then test one call.
Do not disable codecs blindly. A codec list narrowed to “fix” dead air can turn a keying mismatch into a real codec mismatch and take the route down. Change one variable, place one test call, keep the evidence.
Do not assume high PDD means bad audio is coming. They are different layers — a congested signalling route says nothing about what the media will sound like once the call answers, and treating PDD as an audio problem sends the diagnosis to the wrong team.

Reference

Troubleshooting: voice call quality — one-way audio, dead air, jitter, and PDD

Troubleshooting: voice call quality — one-way audio, dead air, jitter, and PDD

Symptom → layer index

One-way audio

Dead air after connect

Choppy audio: packet loss and jitter

High PDD / long ring-delay

Echo

What to capture before escalating

What not to do

See also

​Troubleshooting: voice call quality — one-way audio, dead air, jitter, and PDD

​Symptom → layer index

​One-way audio

​Dead air after connect

​Choppy audio: packet loss and jitter

​High PDD / long ring-delay

​Echo

​What to capture before escalating

​What not to do

​See also

Troubleshooting: voice call quality — one-way audio, dead air, jitter, and PDD

Symptom → layer index

One-way audio

Dead air after connect

Choppy audio: packet loss and jitter

High PDD / long ring-delay

Echo

What to capture before escalating

What not to do

See also