> 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/call-quality-mos.md).

# Call quality (MOS)

Voice calls are scored for quality once the measurements for them arrive. That score is a **Mean Opinion Score**, or MOS — a long-standing telephony measure of how a call would have sounded to the person on it.

MOS is the number behind every call quality figure in the product, so it is worth understanding once.

## The scale

Scores run from **1 to 4.5**, and higher is better. 4.5 is the ceiling the scoring method can produce — a perfect 5 is not reachable, so a fleet sitting around 4 is performing well rather than falling short.

The product itself only ever sorts calls into three bands, described below. Anything finer than that is not something the screens ask you to judge.

## How the product shows it

MOS appears in three different forms, which is the part that causes confusion.

### As a raw score, per call

On [Device details](/amie-advanced/using-the-platform/device-details.md), the **Call History** table shows each call's own MOS under **Quality (MOS)**, to one decimal place, with a colored band:

| Band     | Score         |
| -------- | ------------- |
| **Good** | 4.0 and above |
| **Fair** | 3.0 up to 4.0 |
| **Poor** | Below 3.0     |

A call with no score recorded shows no band at all, rather than being counted as poor.

{% hint style="warning" %}
**Poor Quality counts more than the Poor band.** The **Poor Quality** figure in the summary row counts every call scoring below **4.0** — so it includes **Fair** calls as well as **Poor** ones. It also covers all of the device's calls, not just the ten shown on the current page.

A device can show a **Poor Quality** count higher than the number of red rows you can see, and that is correct rather than a display fault.
{% endhint %}

### As a score out of 100, across many calls

On the [Dashboard](/amie-advanced/using-the-platform/dashboard.md), **Call Performance** averages the MOS of every call in the period and converts it to a figure out of 100, shown with a percent sign.

Below the top of the scale the conversion is proportional, so a higher average produces a higher score. There are two things worth knowing about the edges:

{% hint style="warning" %}
**100 is the top of the scale, not a perfect call.** The score reaches 100 at an average of about **4.4**, which is close to the highest score the method can produce at all. So **100 means "excellent", not "flawless"** — and once an average is that high, further improvement cannot move the figure.
{% endhint %}

### As an average, per access point and per device

On the [Performance](/amie-advanced/using-the-platform/performance.md) screen, MOS is averaged and broken down by where calls happened — **Avg AP MOS** and **Avg Device MOS** — alongside a count of **Low MOS Events**. This is where you go to find out *which* access point or device is responsible for a quality problem the Dashboard only hints at.

Access point rows there carry their own status bands, which are **stricter than the per-call bands**:

| Status      | Average MOS   |
| ----------- | ------------- |
| **Good**    | 4.0 and above |
| **Warning** | 3.6 up to 4.0 |
| **Poor**    | Below 3.6     |

An average of 3.7 marks an access point as **Warning**, while a single call at 3.7 would read as **Fair**. That is reasonable — an average that low means many calls were bad — but the same number does carry different labels on the two screens.

## What MOS does and doesn't tell you

**It reflects what the caller experienced**, not what any single piece of equipment was doing. A poor MOS is a symptom. The cause could be Wi-Fi coverage, a roaming problem between access points, packet loss on the network, or the handset itself.

**An average hides its own distribution.** A hundred excellent calls and ten unusable ones can average to a respectable-looking score. When a fleet-wide figure looks acceptable but people are complaining, the **Poor Quality** count and the per-device breakdown will show what the average smoothed over.

**Only completed calls count.** A call is scored once it has ended.

## Edge cases

* **No calls reads as 0.** When there were no calls at all in the period, **Call Performance** shows **0** — the same as uniformly terrible quality. Check **Call Volume** on the same screen to tell the two apart.
* **A small number of calls is not a trend.** One bad call in a quiet period moves a fleet average much further than it would in a busy one.
* **Bands have hard edges.** A call at 3.99 is **Fair**; at 4.0 it is **Good**. Nothing about the call changed meaningfully.
* **The Dashboard and Performance averages are not calculated the same way.** The Dashboard treats every call equally, while Performance weights each call by how long it lasted. A few very short bad calls move the two figures by different amounts.

## Where you'll see it

* [Dashboard](/amie-advanced/using-the-platform/dashboard.md) — as **Call Performance**
* [Device details](/amie-advanced/using-the-platform/device-details.md) — as **Quality (MOS)** per call, and the **Poor Quality** count
* [Performance](/amie-advanced/using-the-platform/performance.md) — as **Avg AP MOS**, **Avg Device MOS**, and **Low MOS Events**

## Related metrics

* [Call Performance](/amie-advanced/metrics-reference/call-performance.md): the Dashboard figure that this score feeds, including which periods it covers.


---

# 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/call-quality-mos.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.