> ## 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.

# Pull a packet capture (pcap) for a voice call

> When a call has a wire-level packet capture, download it from the call detail page or the recording metadata endpoint and diagnose jitter, codec mismatches, and one-way audio in Wireshark — without an external SIP tracing tool.

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](https://www.rfc-editor.org/rfc/rfc5102) — 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:

```bash theme={null}
curl "https://api.orbit.devotel.io/api/v1/voice/calls/<call_id>/recording" \
  -H "X-API-Key: dv_live_sk_your_key_here"
```

The response carries the capture fields alongside the audio ones:

```json theme={null}
{
  "data": {
    "recording_url": "https://storage.googleapis.com/...signed-audio...",
    "expires_at": 1758000000000,
    "pcap_url": "https://storage.googleapis.com/...signed-capture...",
    "pcap_expires_at": 1758000000000,
    "pcap_size_bytes": 183412
  },
  "meta": { "request_id": "req_abc123", "timestamp": "2026-09-18T09:12:00Z" }
}
```

`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.

<Note>
  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.
</Note>

***

## Related

* [Recording lifecycle](/concepts/recording-lifecycle) — how recordings move from provider webhook to stored artifact.
* [Searchable recording and transcript library](/voice/recording-library) — the QA surface that lists every recording across channels.
* [SIP trunk troubleshooting](/channels/voice/sip-trunks-troubleshooting) — when the capture points at the carrier, e.g. the SDP negotiation above.