VICIdial recording will not stop: investigate channel buildup safely

Identify the recording type before following a channel

Start on the authorized lead’s Recordings area and record its recording ID, extension/type, start time, owning server and file path privately. This procedure is for legacy mono agent-session recording, such as the captured 8309 Monitor/Wait leg. A blank STEREO marker identifies legacy mono in the current project documentation; an S-prefixed stereo type needs the stereo guide instead.

The signal is specific: a recording keeps growing well past the point a transfer or hangup should have ended it, or the count of active channels on the server keeps climbing instead of settling back down between calls. A channel, in Asterisk (the open-source phone engine underneath VICIdial), is one live leg of audio — the agent's leg, the customer's leg, and a leg inside a conference are each their own channel, and one call can involve several at once.

This is different from a recording that only looks long because the call itself ran long, or a storage alert that fires because old finished recordings were never archived. Confirm the call's own timestamp, the recording's own start time, and whether the underlying channel still shows as active before assuming anything is actually stuck.

Some VICIdial troubleshooting instinct reaches for the dialplan — Asterisk's own set of call-handling instructions — first. This guide does not: the mechanism below centers on the agent's own conference and the one leg VICIdial records from it, not a dialplan setting anyone would need to edit.

A VICIdial forum thread reports exactly this pattern: a recording that kept growing for hours, with channel buildup on the server, after a three-way transfer — one account of the mechanism below, not a guaranteed match for your own build.

Identify and verify stereo recordings →

Why a recording keeps running after the call should be over

On this build's stock recording extension, VICIdial does not use Asterisk's newer MixMonitor application at all; starting a recording from the agent screen runs `agc/manager_send.php`'s MonitorConf action, which writes a row to `recording_log` and then queues an AMI Originate into the campaign's own Recording Extension — 8309 on a stock build, or 8310 for a GSM-format recording. That extension is a short, fixed sequence: Answer, then Asterisk's older Monitor application (still present and running on this build, though marked deprecated), then a long Wait, then Hangup. The Originate creates a dedicated recording leg inside the agent's own conference — ConfBridge on this build — and Monitor names the file from the caller ID name field VICIdial set on that leg. Stopping works the same way in reverse: VICIdial's StopMonitorConf action writes that `recording_log` row's end time and length, then finds the matching leg among the live SIP channels and queues an AMI Hangup for it — VICIdial's own "stop" is exactly that one hangup, nothing more.

VICIdial does use a dialplan `h` extension on this build, confirmed with `dialplan show trunkinbound`, which runs an AGI hook for hangup and call-logging — but that extension governs call-detail records, not recordings. A context missing or breaking that `h` handling can leave a call's log entry incomplete; on its own, it is not why a recording keeps running.

A transfer or a three-way call is the riskiest moment for a stuck recording, because it adds a leg to the conference for the new party without necessarily tearing down the original recording leg the instant the call looks, on screen, like it has ended. If that original leg is never actually hung up, it keeps running its own Monitor and keeps writing, even though the agent and the customer both believe the call is already over — the exact pattern the forum report above describes.

One consequence of this shipped design is worth knowing on its own: a recording leg actually running the stock 8309 steps stops itself, through its own Wait and Hangup, after roughly an hour, whether or not VICIdial's own stop message ever arrives. If a recording appears to grow beyond that interval, verify the active channel, file identity and configured extension. A custom dialplan or another process writing the file may explain the discrepancy; the duration alone does not identify the cause.

Rank the likely causes before you touch anything

Work through these in the order below: the fix for the first cause does nothing for the third, and acting on the fourth without recognizing it is how a diagnostic session turns into an outage.

• Most likely: a recording leg was left behind in the agent's own conference after a transfer or a three-way call, the exact forum-reported pattern above, and it was never actually hung up.
• Second: VICIdial's own stop never reached the recording leg — either the agent closed the browser tab instead of logging out normally, so the screen never sent a stop at all, or VICIdial queued the stop's AMI Hangup action but the `ASTsend` screen session that delivers queued AMI actions never actually delivered it.
• Third: nothing is actually stuck — the mover or cron job that clears finished recording files out of the working directory has fallen behind, so a backlog of already-finished files looks like ongoing growth.
• Fourth, and the one to escalate rather than fix yourself: the audio is genuinely still live, meaning a real person remains connected on a channel somewhere, and this is not a cleanup bug at all.

Check the shipped Agent API before opening the Asterisk CLI

VICIdial's own Agent API ships a `recording` function with a STATUS value built for exactly this question, so check it before reaching for a raw Asterisk command. One read-only call reports the recording ID, filename, server, start time and the agent's own session state together.

The config file supplies the API URL, user, password and `source`; the only fields you add per call are `agent_user`, the VICIdial user whose session you are checking, plus `function` and `value`. Nothing sensitive appears outside the file.

Use a dedicated permitted API account and an isolated synthetic agent. Keep the config, returned recording ID and filename private; an API version response does not prove protected recording access.

curl --fail-with-body --silent --show-error --config /etc/vicidial-api/agent.cfg --data-urlencode "agent_user=<AGENT_USER>" --data-urlencode "function=recording" --data-urlencode "value=STATUS"

Confirm the channel, the file paths, and the screen sessions

Once the agent has logged out, or when you need to see a channel the API is not reporting on, go straight to Asterisk. `core show channels verbose` lists every live channel and the context it is currently running, which shows immediately whether the call you are chasing has actually ended underneath.

On the documented lab, extension 8309 or 8310 and Wait 3600 can suggest a recording leg. These values do not establish ownership or prove a leg is stranded; correlate the exact channel and recording ID with your synthetic test and check the configured recording extension.

The two variables in `/etc/astguiclient.conf` that name where in-progress and completed recordings live are worth confirming by name rather than guessed at; grep for them specifically instead of reading the whole file, since it also holds database credentials that must never be printed.

The channel listing may contain other people’s calls. Inspect it privately and correlate only the exact channel belonging to your authorized synthetic test; extension and Wait values alone do not establish ownership.

asterisk -rx 'core show channels verbose'screen -lsgrep -i "PATHmonitor\|PATHDONEmonitor" /etc/astguiclient.conf

Fix the cleanup path, not the symptom

For a confirmed stranded recording belonging to your own isolated synthetic test, prefer the Agent API STOP path if the agent session is still open. The example below is unexecuted; obtain the synthetic agent ID and a dedicated authorized API configuration. This stops one recording, not the underlying cause.

If the agent session has ended, ask the administrator to inspect the exact channel and recording ID privately. A direct channel hangup bypasses VICIdial recording-stop bookkeeping and can require reconciliation; do not use a channel based on extension or Wait alone. Document the observed transfer or conference path and escalate a recurring symptom.

curl --fail-with-body --silent --show-error --config /etc/vicidial-api/agent.cfg --data-urlencode "agent_user=<AGENT_USER>" --data-urlencode "function=recording" --data-urlencode "value=STOP"

Verify with a fresh call, not the same one

Recovery means a brand new synthetic call, not another look at the one you were diagnosing. Place one more test call, transfer it through the same path the original symptom happened on, hang up normally, and repeat the checks above.

This is a prospective test only. A new synthetic call and its result have not been demonstrated here.

• The Agent API STATUS call for that fresh test now returns no active recording once the call is over.
• `core show channels verbose` no longer lists a channel from that test after a normal hangup delay.
• The finished file actually lands in the completed directory named in `/etc/astguiclient.conf`, not the in-progress one.

When to stop and hand this to someone else

Escalate immediately, rather than continuing to test alone, the moment a real customer's channel is the one still recording, disk usage on the recording partition is climbing toward full, or channel counts are rising across calls that have nothing to do with the transfer path you are testing. Any one of those turns a cleanup bug into an outage or a compliance problem, and neither is safe to keep diagnosing solo on a live system.