> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Troubleshooting: voice call quality — one-way audio, dead air, jitter, and PDD > Diagnose audio-quality complaints on connected calls — one-way audio, dead air after answer, choppy or jittery speech, echo, and long post-dial delay — by mapping each symptom to the layer that causes it. # 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](/troubleshooting/sip-trunk) 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](#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](#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](#choppy-audio-packet-loss-and-jitter) | | **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](#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](#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](/reference/glossary) 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: 1. **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](/reference/glossary) covers why real-time media needs a routable advertised address, and the [SIP trunk troubleshooting page](/troubleshooting/sip-trunk) covers the signalling half of the same problem. 2. **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. 3. **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](/troubleshooting/sip-trunk): 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](/guides/sip-trunk-connection) 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](/reference/faq#what-codecs-does-orbit-support) | | `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](/troubleshooting/sip-trunk) | 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: ```bash theme={null} 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: ```json theme={null} { "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](/channels/voice/sip-trunks-troubleshooting) 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](/reference/glossary), 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`](/channels/voice/sip-trunks-troubleshooting) 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](/troubleshooting/sip-trunk). * **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: 1. **Call ID** (`call_…`) of one affected call — the worst-calls table and the call detail both show it. 2. **Trunk ID** (`trunk_…`) the call routed on, if it went over your own SIP trunk. 3. **Direction** — outbound, or inbound on an incoming trunk. 4. **Codec negotiated** for the call (visible on the worst-calls row — `codec` — or on the call detail). 5. **The per-call quality row** from `GET /api/v1/voice/quality/worst-calls?days=7` — MOS, jitter, packet loss, RTT — or the dashboard equivalent. 6. **Your organization ID** (Settings → Organization, or `organizationId` from `GET /api/v1/me`). 7. 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](/troubleshooting/sip-trunk) 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. ## See also * [Troubleshooting: SIP trunk registration, health, and failover](/troubleshooting/sip-trunk) — registration verdicts, health ranking, the TLS/SRTP decision path, and the failover chain this page links to for route congestion. * [Troubleshooting: SIP trunk down or calls failing](/channels/voice/sip-trunks-troubleshooting) — the dashboard-side route-quality and auth-ledger views. * [Voice channel: SIP trunks](/channels/voice) — trunk setup and the outbound-routing overview. * [Glossary](/reference/glossary) — the PDD and NAT definitions this page builds on. * [Voice API reference](/api-reference/voice) — the request/response schema for the quality endpoints quoted here.