Most call problems you can diagnose from the event timeline and the MOS/jitter/loss numbers — those tell you what went wrong. This page is for the times you need to see the actual packets to understand why: a carrier that tears calls down at the ring stage, a 488 you can’t explain, DTMF that never registers, or audio that flows one way. The telephony leg speaks SIP for signalling and RTP for media, and both are captured for you — so you rarely have to reach for tcpdump at all.

​
Signalling is already captured

Every SIP message on every one of your calls is captured automatically, keyed by sid, and kept in a searchable store you reach from the console at agent.telequick.dev. You don’t run a capture agent, mirror a port, or schedule anything — the SIP gateway mirrors each message as it sends or receives it. Capture uses HEP (the Homer Encapsulation Protocol), the same open format Homer and other SIP-capture stacks speak, so the data is portable: on a self-hosted deployment you can point your own HEP collector at the same feed.
Capture is tenant-scoped. You only ever see calls that belong to your workspace — traces are filtered by your tenant and your DID ranges before they reach you, so a shared managed-cloud plane never leaks another tenant’s signalling.
What you get per call, without any packet tooling of your own:
  • The full SIP transaction — every INVITE, provisional, 200, ACK, BYE, re-INVITE, and REFER, with wire timestamps.
  • The SDP offered and answered on each leg (codecs, media IP/port, DTMF mode), so codec and media-path negotiation is visible without decoding anything.
  • Both B2BUA legs — the carrier-facing dialog and the agent/endpoint-facing dialog — lined up under the one sid.

​
Reading a ladder diagram

The capture explorer renders a SIP transaction as a ladder (a flow diagram): each participant is a vertical line, time runs top to bottom, and every arrow is one SIP message annotated with its method or status code and timestamp. For an inbound call to an AI agent it reads like this: 
   carrier / SBC              SIP gateway (B2BUA)            agent endpoint
        │                            │                            │
        │ ── INVITE (SDP offer) ────▶│                            │
        │ ◀──── 100 Trying ──────────│                            │
        │                            │ ── INVITE (SDP) ──────────▶│   (only on a
        │                            │ ◀──── 200 OK (SDP) ────────│    human/SIP leg)
        │ ◀── 183 Session Progress ──│                            │
        │        (SDP answer)        │                            │
        │ ◀──── 200 OK (SDP) ────────│                            │
        │ ── ACK ───────────────────▶│                            │
        │ ═══════ RTP media ═════════│════════════════════════════│
        │ ── BYE ───────────────────▶│                            │
        │ ◀──── 200 OK ──────────────│                            │
Read it for the things that go wrong:
  • A gap where a message should be. No ACK after the 200 OK? The dialog never confirmed. No 183/200 at all after the INVITE? Your response never reached the caller (loss, ACL, or an unreachable route).
  • The same message repeated at ~500 ms, 1 s, 2 s intervals. That’s SIP retransmission — the sender isn’t getting a reply. Follow the arrows to see which hop is silent.
  • A 4xx/5xx/6xx instead of a 200. The code and its reason phrase name the rejection; expand the message to read the headers.
  • The SDP on each side. Open the INVITE and the answering response and compare the m=audio lines — a codec list with nothing in common is a 488 waiting to happen.
  • Timing. Wide gaps between arrows are where the latency lives; the ladder timestamps are your first cut before the latency breakdown.

​
Common telephony packet symptoms

SymptomLikely causeWhat the ladder / pcap shows — and the fix
Call rings, then the carrier sends an unsolicited BYERinging was signalled with a bare 180 and no media descriptionLadder shows 180 Ringing without a following 183 Session Progress (SDP). The gateway answers early media with 183 + SDP — if you front your own carrier/SBC, make it send 183 with SDP, not a media-less 180.
488 Not Acceptable Here on answerNo codec in common between offer and answerCompare the two m=audio SDP lines in the ladder. Phone legs must offer G.711 (PCMU/PCMA). Fix the trunk’s offered codecs.
401/407 challenge loop, call never sets upDigest auth failing on a registered endpoint or trunkLadder shows repeated INVITE → 407 → INVITE. Re-check the endpoint/trunk credentials; a mismatched secret loops here forever.
Repeated INVITEs, no response at allPacket loss, or the source IP is blocked by the ACLSilent hop in the ladder. Confirm the sender’s source IP is allowed and the route is reachable; see SIP trunk troubleshooting.
Call connects, but audio flows only one wayRTP isn’t reaching one side — NAT/SDP media address, or asymmetric flowSignalling looks clean, so this is a media problem. Check the SDP c=/m= media address the far end was told to send to; then drop to a pcap on the media path (below). See one-way audio.
DTMF digits never registerRFC 2833 telephone-event payload-type mismatch, or the far end sends in-bandThe ladder’s SDP shows the negotiated telephone-event PT; whether the digits actually arrive is only visible in an RTP pcap. Confirm both sides agree on RFC 2833 and the payload type.

​
When to drop to a pcap

Built-in capture records signalling (and RTCP/QoS summaries), not the raw RTP audio payload. Reach for a packet capture when the question is about the media stream itself and the ladder plus MOS/jitter/loss haven’t answered it:
  • One-way or no audio where signalling is clean — you need to see whether RTP is actually leaving one side and arriving at the other, and on which address.
  • DTMF (RFC 2833) that isn’t detected — inspect the telephone-event packets and their payload type on the wire.
  • Codec / payload-type drift — confirm the RTP payload type on the wire matches what the SDP negotiated.
  • Loss or jitter patterns the E-model MOS score flags but doesn’t localize — packet arrival timing tells you where the gaps are.
1

Capture on a box you actually own

Take the pcap at your SBC or carrier edge, or on a self-hosted engine host you control — not on the managed-cloud media plane. Filter to the call’s RTP by media IP/port (from the SDP in the ladder) plus the SIP signalling port, e.g. tcpdump -i <if> -w call.pcap 'udp and (host <media-ip>)'.
2

Open it as a VoIP flow

Load the pcap in Wireshark and use Telephony → VoIP Calls to reconstruct the dialog, then RTP → Stream Analysis to see per-packet loss, jitter, and sequence gaps. Wireshark builds its own ladder from the packets so you can line it up against the captured SIP trace.
3

Match it back to the call

Correlate on the SIP Call-ID (and your sid) so the pcap and the built-in capture describe the same call. The media IP/port to filter on is the one in the SDP answer you already read in the ladder.
The media plane can be invisible to tcpdump. On the managed cloud the engine can take direct, kernel-bypass ownership of the NIC for the RTP/QUIC fast path, so packets never traverse the kernel stack a host-level libpcap/tcpdump hooks into — a capture on that box will show little or no RTP. Capture at the SBC or carrier edge, on a switch mirror/SPAN port, or rely on the built-in SIP capture and QoS telemetry instead. This is why signalling capture is done for you in-engine rather than left to tcpdump.
Browser and app legs are encrypted media. A WebRTC/WebTransport leg carries audio inside DTLS-SRTP (or a QUIC session), so a pcap of it is ciphertext — you can’t read the RTP payload from the wire. Debug those legs with the MOS/jitter/loss and call-trace surfaces, not a packet capture. Packet-level debugging in the raw is a telephony-leg technique.

SIP / RTP debugging

The workflow for isolating a telephony-leg fault, start to finish.

Call traces

The assembled per-call event timeline, keyed by sid.

MOS, jitter & loss

The media-quality numbers that tell you when to open a pcap.

Call lifecycle

What each SIP message on the ladder means, and where the agent attaches.

One-way audio

The classic media-path fault a pcap resolves.

SIP trunk issues

ACLs, auth loops, and unreachable routes at the trunk edge.