Recordings

Purpose

Describe how Get2Dial captures, stores and serves call recordings.

Overview

Recording is enabled per campaign (campaigns.record_calls). When a call connects, the edge call engine issues uuid_record on the carrier leg to a deterministic path — <dir>/g2d_<tenantID>_<callID>.wav — and stamps it on the channel. The CDR’s recording_url holds this edge-local path while recording_status is recorded.

On split deployments the node agent runs a recording-sync loop: it polls the control plane for pending recordings, streams each file as multipart to POST /api/v1/nodes/recordings/<callID>, the control plane stores it in MinIO under tenants/<tenant>/recordings/…, and the CDR flips to uploaded with the MinIO location. Supervisors stream playback from /api/v1/recordings/{call_id}/audio.

Configuration

RECORDING_SYNC=true                      # store recordings in MinIO (control plane)
RECORDINGS_DIR=/usr/local/freeswitch/recordings   # edge uuid_record output dir
AGENT_RECORDING_SYNC_ENABLED=true        # edge → central upload (set false if co-located)
AGENT_RECORDING_SYNC_SECONDS=30          # upload poll interval

Examples

Because the queue’s uuid_transfer strips g2d_* channel variables (including the recording path) off the carrier leg, the call engine persists call context in Redis and the CDR writer backfills the recording reference — so the recording isn’t lost when a call is bridged to an agent.

Notes

The recording path is a pure function of tenant + call ID, so it can always be reconstructed.
Recordings can be subject to consent/legal requirements — configure per jurisdiction.
With MinIO disabled, recordings stay on the local recordings volume.