VICIdial agent alert sounds and drop-call audio: test before changing prompts

First, name who heard the sound

'The call played music' is not enough to diagnose an audio problem. An agent alert is intended for the agent; music on hold is normally heard by a caller placed on hold or queued; a drop/abandon message can be heard by a customer when no agent is available. Browser notification sounds are separate again, and ringing may come from a phone, softphone or call path. Record who heard it and when before deciding where it originated.

VICIdial's own feature list describes configurable agent alert sounds and custom music on hold. Those features share a telephony system but do not necessarily use the same setting or audio file — list the music-on-hold classes Asterisk actually has configured before assuming one exists. Which class is actually attached to a given campaign or trunk is a separate question from which classes exist at all; this command only answers the second one.

asterisk -rx 'moh show classes'

A long alert can look like hold music

A VICIdial forum case is a useful warning: an apparent third-party hold-music problem turned out to be a five-minute default agent-alert clip when an agent joined a conference. Do not assume the audible result proves its source — a conference-join alert plays inside the same audio path a caller's hold music would use, which is exactly why the two are easy to confuse without a timestamp.

Write down the listener, the exact moment it began, the action that preceded it, and whether the call was answered, held, transferred, queued, or dropped. That timeline is safer than changing several prompt settings at once. A simple shared log, even one spreadsheet row per test, beats memory once more than one person is reproducing the same symptom.

Guided example: make a zero-customer audio timeline

Use only the internal test endpoint. Run one ordinary agent login/join test and one authorised inbound or transfer test if your lab supports it. Do not intentionally raise a dial ratio or create a real abandoned call to make an alert happen. If your lab exposes a second internal line, have a colleague call it so 'agent side' and 'far side' can be labeled independently for the same event.

For each sound, capture a local timestamp and label the listener. If the agent hears a sound but the test endpoint does not, that strongly narrows the layer without changing server configuration.

Test: <AGENT_LOGIN | TEST_TRANSFER | TEST_QUEUE>Listener: <AGENT | TEST_ENDPOINT>Time: <YYYY-MM-DD HH:MM:SS>Action immediately before sound: <JOIN | HOLD | TRANSFER | QUEUE>Sound duration: <SECONDS>Customer involved: no

Guided example: inspect the active call evidence

During an approved lab reproduction, an Asterisk owner can collect bounded CLI evidence. The goal is to learn which channels and applications were active at the timestamp, not to edit dialplan or music-on-hold files.

Screenlog output can be useful for a server-generated sound; a VICIdial forum thread points to Asterisk screenlog output specifically when tracing unexpected audio. Redact phone numbers, caller IDs, credentials and customer details before sharing evidence. On a shared lab, seeing a channel for a phone that is not part of your own test is the expected baseline when someone else happens to be logged in at the same time — it is not by itself evidence of anything wrong. The opposite result is just as normal: an idle lab with no live calls in progress at that exact moment can legitimately show zero active channels, which is the correct baseline, not a sign that the command failed or that Asterisk is unreachable.

To look closer at one specific channel, take its exact name from the command below and run core show channel against that name — there is no single fixture channel to hand you here, since which phone is active depends entirely on who is logged in at the time you run it.

asterisk -rx 'core show channels concise'

Change one approved test asset, then repeat

This guide does not identify an upload screen or setting for every audio path. Ask the Asterisk administrator to identify the exact setting for the observed sound and provide the build-specific procedure. Confirm format, language, licensing, volume and duration before selecting a test asset; a file on disk does not prove the active configuration uses it.

Do not overwrite a production prompt to 'see if it helps'. Keep the previous selection documented, perform the single change in the isolated lab/campaign, repeat the same observation card, and explicitly restore the previous state if the result is wrong. Note the exact filename, format and duration you selected — 'the new file' is not a useful rollback record if two similarly named assets exist.

• I know whether the sound belongs to the agent, caller, or browser.
• I tested one event with no real customer.
• I have evidence and an approved rollback before an audio asset changes.

Treat drop-call audio as a policy path

A dropped call is not merely an audio cue: it is a call-handling and compliance event. VICIdial supports drop timing and safe-harbor-style handling, and its feature list also describes routing a dropped call to voicemail, queue or extension when no agent is available. The correct message and routing depend on the jurisdiction and campaign policy — confirm which of those routing options your build actually has configured before promising a caller-facing behavior to compliance or to a customer.

If agents report customers hearing unexpected music after a disconnect, preserve the timestamp and call identifier for the owner. Do not tune drop timers, routing extensions or predictive dialing to silence the symptom; first establish whether the call was an agent alert, hold path, transfer issue, or true drop. Where a jurisdiction sets a specific safe-harbor message or timing, treat that requirement as the floor, not a suggestion the campaign owner can waive for convenience.