Skip to main content
A packet capture is the raw network trace of a call’s media. Where a standard recording keeps the decoded audio, a capture keeps the actual RTP packets — their timing, their sequence numbers, and the negotiated codec — so support and QA teams can answer a voice-quality complaint with wire-level evidence instead of inference. A capture exists only when the recorder forked one — and pcap forking is opt-in at the recorder, so most calls are audio-only. When a capture was forked, it is stored alongside the audio as a .pcap file and exposed on the same surfaces. When none was forked, the dashboard shows no button and the API returns no field — neither pretends otherwise. This guide covers when a capture is the right evidence to pull, how to download it from the dashboard or the API, what it contains, and how to share it with support safely.

​
1. When a packet capture helps

Pull a capture when the question is about the transport, not the content:
  • Packet loss and jitter. One-way audio, clipped syllables, and robot-voice artifacts usually come from dropped or late RTP packets. The capture shows per-packet timing and sequence gaps, which separates “the sender stopped sending” from “the network lost the packets” — the fix differs.
  • Codec mismatches. If the call negotiated a codec that one leg could not actually produce, the audio recording is uniformly bad and never points at the cause. The capture shows the SDP offer/answer and the payload type on the wire.
  • Verify a remediation. After a route change or a codec allowlist change, fresh captures let support confirm the remediation on new calls rather than wait for the next complaint.
That’s the remediation loop support runs on a capture: confirm the fault class (loss, jitter, codec), apply the fix, sample the outcome. Capture sampling for QA follows the same sampling-family discipline as RFC 5102’s “ipfix” flow record export — you capture what you need to answer the question, not every call. The capture is network diagnostic evidence, not a lawful-intercept artifact and not the call recording. It does not change what you must retain or what consent covers: the same call that produced a recording also produced the capture, and both are held for diagnosis, not handed to a regulator by default.

​
2. Download the capture from the call detail page

  1. Open Voice → Calls and pick the call.
  2. Find the recording panel. Whenever a capture exists for that call, a Packet capture button sits next to the recording download, labelled with the file size when the recorder reported it.
  3. Click it — the browser downloads the .pcap file.
Calls without a capture show no button at all, so low-forking tenants (the common case) never see a dead control. The button carries a short-lived signed link whose expiry mirrors the audio link — one hour. That window is how long the file stays fetched with no extra authentication; after it expires, refresh the call page (or re-fetch the recording metadata, section 4) and click again to get a new link.

​
3. Open it in Wireshark

Wireshark reads .pcap directly; there’s no convert step. After you open the file:
  • Decode as RTP. If streams show as plain UDP, select a packet and Decode as… → RTP.
  • Measure jitter and lost packets. Telephony → RTP → Stream Analysis shows packet timing, worst-to-best jitter, and where sequence numbers jump.
  • Listen to the RTP stream (Telephony → RTP → Player) if the codec is decodable — this confirms whether the fault is transport or content without shipping the audio anywhere.
If jitter spikes at a fixed interval, look for a buffer or shaping device between the caller and the edge; if a fixed number of packets is dropped every burst, check a mis-sized queue. For one-way audio, check that both directions of the RTP stream are present and that the SDP directions were symmetric.

​
4. Download it from the API

The same call-recording metadata endpoint that returns the audio link also returns the capture link when one exists:
The response carries the capture fields alongside the audio ones:
pcap_url is present only when the recorder forked a capture for this call; pcap_expires_at is the epoch-ms expiry of the signed link (mirrors expires_at); pcap_size_bytes is the artifact size when the recorder reported it. Calls without a capture omit all three fields — your tooling should treat their absence as “no capture for this call”, not as an error, and skip the download instead of iterating a dead link. Where the capture was forked at call outset by the SIPREC recorder (the common enterprise path), the metadata joins both legs onto one call id, so the link still resolves for calls that also returned a Telnyx recording_url.

​
5. Treat the capture as sensitive

A .pcap contains the audio — every payload on the wire, not just call metadata. Share it on the same footing as a full recording:
  • Attach it to a support ticket rather than pasting a public link. Signed URLs are how the capture leaves your tenant, and a ticket attachment narrows who can fetch it.
  • If you must move it outside a ticket, re-encrypt the file (e.g. age, GPG) before upload and revoke the URL after — any bearer of a still-valid signed link can fetch it.
  • Keep the capture-retention expectation aligned with your recording retention: the capture answers a diagnostic question, then is as obsolete as the recording for the same call.
Packet capture is diagnostic traffic. Nothing on this page turns it into lawful-intercept evidence or changes where outbound media terminates; outbound voice and SMS still exit only through the Devotel softswitch, and Telnyx/DIDWW stay on their inbound-only lane. Collections for LI follow the recording pipeline’s retention rules your organization already configured.