When a phone call misbehaves, the fault is almost always in one of three places. The signalling: the call never sets up, or it tears down early. The media: the call connects, but the audio is bad or one-way. The registration: a trunk or a SIP phone cannot authenticate. This page is the field guide for all three. Start from the symptom. Read the likely cause. Apply the fix. Every call keys off a single call_sid. When you have that from your reports, you can follow one call across signalling, media, and the agent. Pull the SIP ladder and the per-call quality numbers from the call trace explorer in the console before you start to guess.
This is the debugging reference. For the step-by-step guide for a trunk that does not come up at all, see SIP Trunk Issues. For audio that flows only one way, see One-Way Audio. For a call that never answers, see Call Does Not Connect.

​
Where to look first

1

Get the call_sid

Find the call in your reports and copy its call_sid. Every downstream tool is keyed on it: the SIP ladder, the media quality record, and the CDR.
2

Read the SIP ladder

Open the call trace explorer. Pull the full request/response ladder for that call_sid. Read the final response code and the Reason / Q.850 cause on the last message. They tell you whether signalling failed or the far end failed.
3

Read the media quality record

Every call that reached the media plane has a per-call quality record: packet loss, jitter, and an MOS score computed from them. If signalling looks clean but callers complain, the answer is here. See MOS, Jitter & Packet Loss.
4

Drop to packets only if needed

If the summary numbers do not explain it, capture the raw SIP and RTP at the edge. See Packet-Level Debugging.

​
SIP signalling failures

The SIP gateway answers inbound calls as a back-to-back user agent (B2BUA). Thus it owns both legs of every dialog. A healthy inbound answer runs 100 Trying → 183 Session Progress with SDP (early media) → 200 OK with the same SDP → ACK. Deviations from that sequence are the most common cause of “the call connected and then dropped.”

​
Symptom → cause → fix

​
Q.850 cause codes

When a call clears, the gateway writes a CDR that includes the Q.850 cause: the PSTN-world reason the call ended, mapped from the final SIP response. Read the cause on the cleared event to classify a hang-up without a replay of the whole ladder. The common ones:
A CDR row for an AI-handled call has a handler tag on the segment. Thus you can tell whether the leg that cleared was the AI stretch or a human stretch of the same call_sid. Multi-segment calls split at the handoff. See Observability Overview.

​
RTP / media failures

The media plane runs RTP/RTCP in-engine. The wire codec is G.711 (µ-law PT 0 / A-law PT 8). The engine decodes it to the runtime’s 8 kHz PCM16 bus, applies noise suppression, and re-paces it back out every 20 ms (160 samples per tick). It scores each call’s quality from loss and jitter with an ITU-T G.107 E-model and writes an MOS estimate to the per-call quality record. DTMF rides as RFC 2833 events.

​
Reading the RTP stats

Two numbers do most of the work:
​
percent
Computed from RTP sequence-number gaps. Sustained loss above ~1–2% is audible. Above ~5% the call is rough. Bursty loss (dropped runs of sequence numbers) sounds worse than the same average spread evenly, because the jitter buffer cannot conceal a long gap.
​
milliseconds
Inter-arrival variation. The jitter buffer absorbs a working range. Past that range, late packets are discarded (and counted as loss) or add delay. Jitter that rises together with discard-loss is a network-path problem, not a codec problem.
The MOS score folds both into one number. Thus you can rank calls without the raw counters. Treat MOS as the triage signal. Treat loss/jitter as the diagnosis. The full interpretation guide is MOS, Jitter & Packet Loss.

​
Symptom → cause → fix

media_mode: direct is defined on the trunk, but the live runtime degrades it to proxy now. If you configured direct and see no recording, no MOS, and no AI audio, that is why. Proxied media is the working path. See Transport to Telephony Overview.

​
Registration failures

The engine embeds its own SIP registrar. It is on by default and multidomain. It uses digest auth plus a source-IP ACL, with nonce/replay hardening. There is no separate registration server to run. Two kinds of party register: outbound trunks that register to a carrier, and human agents on real SIP deskphones/softphones that register to your workspace. Each workspace has its own SIP host, <workspace-id>.sip.clutchcall.dev. The engine identifies the tenant from the leftmost DNS label of the inbound request.

​
Symptom → cause → fix

Trunk INVITEs bypass the registrar ACL. They match by source IP instead. Thus a trunk can deliver calls even while a device registration fails. Do not conflate the two. Registration problems affect SIP phones and outbound trunk registration. Inbound carrier trunks match by IP.

​
A quick triage flow

1

Did the call set up?

No final 200 OK in the ladder → signalling. Read the final response and the Q.850 cause above. If the trunk never came up, go to SIP Trunk Issues.
2

Did it set up but sound bad or go one-way?

The call is established but the audio is poor → media. Read loss/jitter/MOS. For one-way audio, check the RTP addressing. Go to One-Way Audio or MOS, Jitter & Packet Loss.
3

Is it a device or trunk that won't come up?

REGISTER fails → registration. Check the credentials, the ACL, the tenant subdomain, and the expiry above.
4

Still stuck?

Capture the raw packets at the edge and read the wire directly. Go to Packet-Level Debugging.

SIP Trunk Issues

The focused runbook for a trunk that does not register or route.

MOS, Jitter & Packet Loss

How to read the media quality metrics that this page points you at.

Packet-Level Debugging

When the summaries are not enough, read the SIP and RTP off the wire.

Call Lifecycle

The healthy INVITE-to-CDR sequence that these failures deviate from.