> 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/using-the-platform/performance/performance-call-performance.md).

# Call Performance Summary

**Call Performance Summary** is the first tab of the [Performance](/amie-advanced/using-the-platform/performance.md) screen and the one it opens on. It charts the average voice quality score of calls over time and breaks quality down by access point and by device, so you can see whether poor calls cluster around a place or a handset. To reach it, select **Performance** in the sidebar.

## Why this screen matters

This is the tab to start on when call quality is in question. Its score — the MOS, or Mean Opinion Score, a 1-to-4.5 rating of how a call sounded — is the single measure of call quality, and sorting the two tables on **Avg AP MOS** or **Avg Device MOS** ranks every access point and every handset by it. An access point with a low **Avg AP MOS** and many call minutes is where calls sound worst; a handset with a low **Avg Device MOS** across many access points is a handset that sounds bad wherever it goes. Once you have the worst access point or handset, the other three tabs say why: [Long Handoff Summary](/amie-advanced/using-the-platform/performance/performance-long-handoff.md) for roaming, [Low RSSI Events Summary](/amie-advanced/using-the-platform/performance/performance-low-rssi.md) for signal, and [Packet Loss Summary](/amie-advanced/using-the-platform/performance/performance-packet-loss.md) for lost audio.

## Before you start

The tab follows the [group selector](/amie-advanced/using-the-platform/the-console.md#the-group-selector), the [time range](/amie-advanced/using-the-platform/performance.md#time-range) and the [filters](/amie-advanced/using-the-platform/performance.md#filters) described on [Performance](/amie-advanced/using-the-platform/performance.md). An hour or day with no calls, or whose calls were all unscored, is plotted as **0**. Networks your organization has asked to exclude are left out as described under [Before you start](/amie-advanced/using-the-platform/performance.md#before-you-start) on Performance: on this tab the chart leaves out every handset that has ever connected to an excluded network.

## Screen layout

![Call Performance Summary over 90 days: MOS and % Good Calls above the two tables.](https://3032864282-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxfLF6IpyutR429bMnvvf%2Fuploads%2Fgit-blob-c50ad2ad6643b597bb4440e97cfb2d4543e13820%2Fperformance-call-performance.png?alt=media)

### The chart

Two lines, each on its own vertical axis:

| Series                    | Axis                                                                                                                                  | What each point is                                                                                                                |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| **MOS** (blue)            | Left, from **0** to a round number at or above the highest point — **5** once any point exceeds 2.5, even though no score exceeds 4.5 | The average of the quality scores of the calls that started in that hour or day. Each call contributes its own average score once |
| **% Good Calls** (orange) | Right, from **0%** to a round number at or above the highest point — **100%** once any point exceeds 50%                              | The share of those calls whose score was 4.0 or higher. The hover row shows it to two decimal places                              |

**MOS** — Mean Opinion Score — is a voice-quality score, from 1 to 4.5, that AMIE calculates from the network measurements the handset reports during a call. 4.0 and above is a good call. See [Call quality (MOS)](/amie-advanced/metrics-reference/call-quality-mos.md).

A call that was recorded but has no quality score counts as **0** in the **MOS** average and as not good in **% Good Calls**, so a period with several unscored calls reads worse than the scored calls alone would suggest.

### The tables

**Call Performance Metrics by AP** on the left (the by AP table) and **Call Performance Metrics by Device** on the right (the by Device table). Every figure in both is built from call segments — the stretch of a call spent on one access point — so a call that roamed across three access points contributes a segment to each. Records with an [all-zeros address](/amie-advanced/using-the-platform/performance.md#the-two-tables) are left out of the by AP table. With no calls in the range, each table reads **No data for the selected period**.

## Controls

The shared range, filter, search, sort, paging and **Export** controls are described on [Performance](/amie-advanced/using-the-platform/performance.md#controls). Exports from this tab are named `call-performance-ap.csv` and `call-performance-device.csv`.

## Columns

Every column is sortable; each table opens sorted by its first column.

### Call Performance Metrics by AP

| Column                        | What it shows                                                                                                                                                                                                |
| ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **AP BSSID**                  | The access point's hardware address                                                                                                                                                                          |
| **Avg AP MOS**                | The average quality score of the scored call segments on this access point, to two decimal places. Segments with no score are left out of the average (unlike the chart, which counts an unscored call as 0) |
| **Low MOS Events**            | The number of call segments on this access point whose score was 4.0 or lower, or that had no score                                                                                                          |
| **Total Call Min**            | The total duration of this access point's call segments, in minutes to two decimal places                                                                                                                    |
| **Low MOS Events / Call Min** | **Low MOS Events** divided by **Total Call Min**, to two decimal places. When the total is under one minute it is divided by 1 instead, so a single short bad segment reads as **1.00**                      |
| (dot)                         | Green when **Avg AP MOS** is 4.0 or higher, orange from 3.6 up to 4.0, red below 3.6                                                                                                                         |

### Call Performance Metrics by Device

The same columns for each handset, with **Device Serial** in place of **AP BSSID** and **Avg Device MOS** in place of **Avg AP MOS**, built from that handset's call segments. No dot.

## Icons and indicators

| Icon or indicator                       | Meaning                                                          | When it appears                       |
| --------------------------------------- | ---------------------------------------------------------------- | ------------------------------------- |
| Blue line                               | **MOS**                                                          | When there is data                    |
| Orange line                             | **% Good Calls**                                                 | When there is data                    |
| Green / orange / red dot on a by AP row | **Avg AP MOS** 4.0 or higher / 3.6 to just under 4.0 / under 3.6 | Every by AP row with a value to judge |

The shared icons — range buttons, filters, search, sort arrows, **Export** and the loading overlay — are described on [Performance](/amie-advanced/using-the-platform/performance.md#icons-and-indicators).

## What to look for

* A red dot with a large **Total Call Min**. Calls on that access point sound bad and there are many of them. Check the same access point on [Low RSSI Events Summary](/amie-advanced/using-the-platform/performance/performance-low-rssi.md) and [Packet Loss Summary](/amie-advanced/using-the-platform/performance/performance-packet-loss.md) to see which is the cause.
* A rate of **1.00** under **Low MOS Events / Call Min** beside a **Total Call Min** under **1.00**. One short bad segment, not a pattern. An access point with 0.10 across 900 minutes has a persistent problem.
* A healthy **Avg AP MOS** beside a large **Low MOS Events**. The average ignores segments with no score; the event count includes every one of them. Sort the by Device table on **Low MOS Events** and open the top handset's [Call History](/amie-advanced/using-the-platform/device-details/device-call-history.md) to see which calls are unscored.
* A handset near the top of the by Device table whichever **Access Point** filter you apply. The problem travels with the handset. Open its [Call History](/amie-advanced/using-the-platform/device-details/device-call-history.md) for the calls themselves.
* **MOS** on the chart falling while **% Good Calls** holds. A few very poor calls are pulling the average down while most calls stay good. The tables for the same period show where.
* Minutes that differ between the two tables. Both count each call segment once; the by AP table leaves out segments with an [all-zeros address](/amie-advanced/using-the-platform/performance.md#the-two-tables), and the by Device table leaves out segments on excluded networks.
* A segment scoring exactly 4.0 counted as a **Low MOS Event**. This tab counts 4.0 or lower as low while its own dot is green at 4.0; [Call History](/amie-advanced/using-the-platform/device-details/device-call-history.md) on a device's page labels a call **Good** at 4.0 and its **Poor Quality** counts calls under 4.0.
* Chart points placed at a different time from the table's figures. A call is plotted by when it started, in your browser's time zone; the tables cover the segments whose measurements fall in the range. See [Time and time zones](/amie-advanced/metrics-reference/time-and-time-zones.md).

## Metrics on this screen

* [Call quality (MOS)](/amie-advanced/metrics-reference/call-quality-mos.md) — what the score measures and every threshold AMIE applies to it
* [Call Performance](/amie-advanced/metrics-reference/call-performance.md) — the Dashboard's 0–100 version of the same score
* [Time and time zones](/amie-advanced/metrics-reference/time-and-time-zones.md)

## Related

* [Performance](/amie-advanced/using-the-platform/performance.md) — ranges, filters, tables and export
* [Low RSSI Events Summary](/amie-advanced/using-the-platform/performance/performance-low-rssi.md) — whether weak signal explains the poor scores
* [Call History](/amie-advanced/using-the-platform/device-details/device-call-history.md) — one handset's calls, scored individually


---

# 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/using-the-platform/performance/performance-call-performance.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.