> For the complete documentation index, see [llms.txt](https://docs.spectralink.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.spectralink.net/amie-advanced/metrics-reference/packet-loss.md).

# Packet loss

The share of a call's audio that never reached the listener in time. Voice travels over Wi-Fi as a stream of small packets, each carrying a fraction of a second of sound; when packets are lost the listener hears gaps, clicks, or a robotic voice.

{% hint style="warning" %}
TODO: the console does not define dropped and missed; the definitions below are from the previous Console Administration Guide. Confirm they still apply.
{% endhint %}

## Dropped and missed

AMIE measures loss over call segments. A call segment is a stretch of a call spent connected to one access point: a call that stays on one access point is a single segment, and a call that moves between two produces two. Both kinds of loss are given as a percentage of the packets in a segment:

| Kind        | What happened                                                    |
| ----------- | ---------------------------------------------------------------- |
| **Dropped** | The packet arrived, but too late to be played, and was discarded |
| **Missed**  | The packet was expected but never arrived                        |

Dropped packets point at delay: packets queuing behind others on a busy access point or channel and arriving after the moment they were needed. Missed packets point at packets lost outright — interference, a weak signal, or a handset moving between access points.

## How the product shows it

The [Packet Loss Summary](/amie-advanced/using-the-platform/performance/performance-packet-loss.md) tab of the Performance screen plots **Dropped Packet Rate** and **Missed Packet Rate** over time and lists them per access point and handset. Each figure is the average, across the call segments in that period or row, of each segment's own percentage, to two decimal places. In the chart, a segment that carries no loss figures counts as 0%.

## What it does and does not tell you

Packet loss is the most direct measure of a congested or interfering network: signal can be strong and roaming fast while packets still go missing. It does not say why. Read it with [Signal strength (RSSI)](/amie-advanced/metrics-reference/signal-strength-rssi.md): loss with weak signal points at coverage; loss with strong signal points at a loaded access point or a noisy channel.

## Edge cases

* **Average of averages.** The rate for an hour is the average of the call segments in it, not the lost packets divided by all packets, so one short bad segment can move an hour's figure as much as a long one.
* **0% has three meanings.** No calls were made, no packets were lost, or the segments carried no loss figures at all. The chart draws all three the same.

## Where you'll see it

* [Packet Loss Summary](/amie-advanced/using-the-platform/performance/performance-packet-loss.md) — the chart and both tables

## Related metrics

* [Signal strength (RSSI)](/amie-advanced/metrics-reference/signal-strength-rssi.md): whether the signal was weak while packets were lost
* [Call quality (MOS)](/amie-advanced/metrics-reference/call-quality-mos.md): how the loss sounded


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.spectralink.net/amie-advanced/metrics-reference/packet-loss.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.