> ## Documentation Index
> Fetch the complete documentation index at: https://docs.firetone.com.au/llms.txt
> Use this file to discover all available pages before exploring further.

# Recording, and what is kept

> The one rule that decides whether a call is recorded, where the audio lives, and how long anything is kept.

FireTone can record a call, take a voicemail and keep a transcript of what an
AI agent said. Three different stores, three different answers to "how long",
and one rule deciding whether a call is recorded at all.

## Whether a call is recorded

Six settings can switch recording on, and **the call is recorded if any of
them says so**. They are not a hierarchy and none overrides another:

| Level            | Where it is set            | Covers                                  |
| ---------------- | -------------------------- | --------------------------------------- |
| **Organisation** | Organisations → the tenant | every call the tenant makes or takes    |
| **Team**         | Teams & agents → the team  | calls handled by anyone on that team    |
| **Extension**    | Extensions → the extension | calls that desk makes **or** takes      |
| **Queue**        | Queues → the queue         | calls offered through that queue        |
| **Trunk**        | Trunks → the carrier       | calls carried over that carrier         |
| **Process**      | Processes → the service    | calls that arrived through that service |

<Warning>
  A switch can turn recording **on** and cannot turn it **off**. Switching
  "record calls" off on an extension does not stop recording if the
  organisation, the team, the queue it came through or the carrier it came
  over has it on. To stop recording a call, switch it off at every level that
  covers it.
</Warning>

The call's own page names which level did it, so "why was this recorded"
has an answer without opening six screens. On a call that was not recorded,
the same line reads *no level of this call has recording enabled*.

### The one way it can fail quietly

A node needs somewhere to put the file. If recording is on and the node has
no recordings directory configured, nothing is recorded and the panel looks
exactly as it does when recording is off. The daemon says so at warning
level and the call's page carries *enabled, but this node has no recordings
directory*. An operator fixes it by setting `FIRETONE_RECORDINGS_DIR` on that
node.

## Where the audio lives

A recording starts as a file on the node that took the call, named after the
call. Where it goes next depends on whether the organisation has given
FireTone a bucket of its own:

* **With cloud storage configured**, the file is handed to the
  organisation's own bucket. It is then reachable from any node, survives a
  node being rebuilt, and sits on storage the organisation controls — which
  also means they can apply their own lifecycle rules to it if they would
  rather answer the retention question themselves.
* **Without it**, the file stays on the node that took the call. That works,
  and it has three limits worth knowing: one disk, unreachable from other
  nodes, and gone if that node is rebuilt.

Either way the panel plays it from the same button, and a recording is only
ever played by somebody holding `recordings:listen`.

## How long anything is kept

Three windows, set per organisation, because these are three different
exposures with different answers. A recorded sales call and a member of the
public's voicemail are not the same risk.

| What            | Setting                  | Default                  |
| --------------- | ------------------------ | ------------------------ |
| Call recordings | **Recording retention**  | none — kept indefinitely |
| Voicemail       | **Voicemail retention**  | none — kept indefinitely |
| AI transcripts  | **Transcript retention** | 365 days                 |

<Note>
  **Nothing is deleted unless somebody asked.** Recording and voicemail
  windows are empty until a number is typed, and empty means keep. This is
  deliberate: software that starts destroying a tenant's recordings because
  an upgrade invented a default is worse than software that keeps too much.
  The transcript window is the exception — it has carried 365 days since the
  store was created, and that is a default, not a recommendation. A tenant
  with a shorter obligation should lower it.
</Note>

Set all three under **Organisations → the tenant**. Each accepts 1 to 3,650
days.

### What deletion actually does

A sweep runs every hour and takes a bite at a time rather than one long
delete, so a busy system is not locked while it runs.

**The file and the row go together.** A recording of somebody's voice that
nothing points at any more is the worst kind of file to leave on a disk, and
a row pointing at a file that has gone is a broken player in the panel. So
each is removed with the other — and where audio has moved to an
organisation's bucket, the row is cleared only once the object is gone. If
the bucket cannot be reached, the row stays, on purpose: an orphaned
recording is exactly what this is meant to prevent.

Deleting a recording does not delete the call. The call record, its duration,
its cost and its outcome stay; what goes is the audio and the transcript.

## Who can hear what

Reading and listening are different permissions, and they are different
disclosures:

| Permission           | Lets somebody                                         |
| -------------------- | ----------------------------------------------------- |
| `recordings:listen`  | play a call recording, or a conference session's      |
| `voicemail:listen`   | play a voicemail message                              |
| `voicemail:read`     | see that a message exists, and read its transcription |
| `conversations:read` | read what was said on an AI call, as text             |

A person with `conversations:read` and no `recordings:listen` can read a
transcript and cannot hear the voice. That is the intended shape: the text
answers "what was agreed", the audio is the recording of a person.

## Telling callers

FireTone records what you tell it to record; announcing it is yours to do,
and in most places it is the law. An IVR flow can play an announcement before
anything else happens, which is the usual place for it. Nothing in the
product announces recording on your behalf.
