
KEY TAKEAWAYS
By DialerKing Senior Engineering Team | Published 2026 | 14+ Years of Asterisk Deployment Experience
An Asterisk sound files path issue is responsible for more silent IVR failures and broken hold-music incidents in contact centers than most administrators initially suspect. When callers hear nothing, or get dropped, instead of the expected prompt, the culprit is almost always a misconfigured file path, an unsupported audio format, or a permission error buried in the Asterisk file system.
This guide, written by DialerKing’s senior engineering team with over 14 years of hands-on Asterisk and VICIdial deployments, walks you through every layer of the problem: how Asterisk resolves audio paths, what breaks silently, how to diagnose the issue in under five minutes, and how to apply a permanent fix.
Asterisk does not play audio by absolute path by default. Instead, it resolves filenames relative to a configured base directory, typically /var/lib/asterisk/sounds/ on most Linux distributions. When your dialplan calls Playback(welcome) or Background(menu-options), Asterisk appends the filename to that base path and scans for a file it can play in a compatible codec. This base path is defined in asterisk.conf under the [directories] section:
[directories]
astetcdir => /etc/asterisk
astmoddir => /usr/lib/asterisk/modules
astvarlibdir => /var/lib/asterisk
astdatadir => /var/lib/asterisk
astagidir => /var/lib/asterisk/agi-bin
astspooldir => /var/spool/asterisk
astrundir => /var/run/asterisk
astlogdir => /var/log/asterisk
astsbindir => /usr/sbinThe sounds directory inherits from astvarlibdir. Understanding this resolution chain is the first step to diagnosing any audio path problem.
Asterisk also factors in language settings. If your dialplan or channel sets LANGUAGE=en, Asterisk first looks in /var/lib/asterisk/sounds/en/ before falling back to the root sounds directory. A mismatch here, for instance, uploading files to /sounds/ when the channel is configured for a language subdirectory, produces silent failures with no obvious error in the Asterisk CLI.
Based on our deployment experience across hundreds of contact center installations, these are the most frequent triggers:
Using Playback ( /tmp/custom-prompts/welcome) or Playback( custom/welcome) when the file lives at /var/lib/asterisk/sounds/custom/welcome.gsm are both valid approaches, but only if the subdirectory exists and the file is in a supported format. Many administrators place files in /tmp/ thinking Asterisk will reach outside its configured directory tree. It will not unless an absolute path is explicitly provided and the channel driver supports it.
Asterisk is format-selective. Uploading a 44.1 kHz stereo MP3 and referencing it without the extension will result in Asterisk scanning for a codec-compatible variant and finding none. The platform natively prefers GSM, ULAW (G.711 μ-law), and ALAW (G.711 A-law) at 8 kHz mono for telephony-grade playback.
Even when the path is correct and the format is valid, the asterisk process user (typically named ‘asterisk’) must have read access to the file. Files uploaded via SFTP often inherit root or the SFTP user’s ownership, causing a permission denied failure that Asterisk logs, but continues past silently from the caller’s perspective.
If your system language is set to ‘en_AU’ or any non-default locale, Asterisk looks for /var/lib/asterisk/sounds/en_AU/ first. If that directory does not exist or does not contain the expected file, playback fails without a loud error, just silence on the line.
Some contact center installations add custom sound modules or use res_speech integrations that alter module search paths. A stale or misconfigured modules.conf can prevent the relevant format modules (format_gsm, format_wav, format_ulaw) from loading, making Asterisk unable to decode any audio file.
Run through these diagnostic steps in order before making any changes to your configuration. This sequence takes approximately five minutes on a running system.
1. Connect to the Asterisk CLI with: asterisk -rvvvv (the extra v flags increase verbosity to show sound resolution steps in real time)
2. In a separate terminal or from your dialer, trigger the IVR flow that should play the broken prompt.
3. Watch the CLI output for lines containing ‘Unable to open’ or ‘File does not exist’, these confirm the path Asterisk is actually trying to resolve.
4. Run the command: core show sounds, this lists every sound file Asterisk has indexed from its configured sound directory. If your file is absent, the path or format is wrong.
5. Check the full log at /var/log/asterisk/full and grep for the prompt name: grep ‘welcome’ /var/log/asterisk/full | tail -30
6. Verify physical file existence and permissions: ls -la /var/lib/asterisk/sounds/l, confirm the file is present, owned by the asterisk user, and readable (at minimum 644).
7. Run ‘file your-prompt.gsm’ or ‘sox –info your-prompt.wav’ to confirm the actual encoding of the uploaded file matches what Asterisk expects.
8. Check the active language setting for the channel by adding ‘NoOp(Language: ${LANGUAGE})’ in the relevant dialplan context and observe the output in the CLI.
Once you have identified the specific cause from the diagnostic steps above, apply the appropriate fix below:
If the file exists but the dialplan is pointing to the wrong location, update extensions.conf or the relevant AEL file:
; WRONG — absolute path outside sounds dir
exten => s,1,Playback(/tmp/prompts/welcome)
; CORRECT — relative to /var/lib/asterisk/sounds/
exten => s,1,Playback(custom/welcome)
; ALSO CORRECT — explicit absolute path (ensure permissions allow)
exten => s,1,Playback(/var/lib/asterisk/sounds/custom/welcome)After editing extensions.conf, reload the dialplan without restarting Asterisk: asterisk -rx ‘dialplan reload’
Use sox or ffmpeg to convert files to the Asterisk-preferred 8 kHz mono ULAW or GSM format:
# Convert MP3 or WAV to GSM (recommended for maximum compatibility)
sox input.mp3 -r 8000 -c 1 output.gsm
# Convert to ULAW (.ul) format
sox input.wav -r 8000 -c 1 -e u-law output.ul
# Convert using ffmpeg to WAV (ulaw, 8kHz, mono)
ffmpeg -i input.mp3 -ar 8000 -ac 1 -acodec pcm_mulaw output.wavPlace the converted file in the correct sounds subdirectory and run: asterisk -rx ‘module reload format_gsm’
# Fix ownership (replace 'asterisk' with your actual process user if different)
chown -R asterisk:asterisk /var/lib/asterisk/sounds/
# Set correct read permissions
chmod -R 644 /var/lib/asterisk/sounds/*.gsm
chmod -R 644 /var/lib/asterisk/sounds/*.wav
# Verify
ls -la /var/lib/asterisk/sounds/custom/# Create the language directory Asterisk expects
mkdir -p /var/lib/asterisk/sounds/en
# Copy your files or symlink from default location
cp /var/lib/asterisk/sounds/welcome.gsm /var/lib/asterisk/sounds/en/
# Or set a universal default in your dialplan to avoid language lookups
; exten => s,1,Set(CHANNEL(language)=)# Reload specific format modules without full restart
asterisk -rx 'module reload format_gsm'
asterisk -rx 'module reload format_wav'
asterisk -rx 'module reload format_ulaw'
# Verify modules are loaded
asterisk -rx 'module show like format'A regional financial services contact center running a VICIdial-based inbound queue contacted DialerKing after callers reported hearing only silence when entering the IVR. The queue had been running without incident for two years before a routine OS upgrade broke audio playback entirely.
Initial investigation by the client’s internal team focused on the dialplan logic, suspecting a scripting error in the IVR campaign. After 48 hours of fruitless investigation, DialerKing engineers ran the standard diagnostic sequence outlined above.
The root cause: the OS upgrade had installed a newer version of Asterisk as a dependency, which reset astvarlibdir in asterisk.conf to a package default of /usr/share/asterisk . The operation team’s custom prompts remained in /var/lib/asterisk/sounds/ , now an unmonitored directory. Asterisk was looking in the right relative subdirectory path but starting from the wrong base.
Resolution Summary
Asterisk is built for telephony-grade audio, not multimedia playback. Using the wrong format is a leading contributor to the Asterisk sound files path issue because Asterisk silently skips files it cannot decode, making it appear as a path problem when the path itself is correct.
Recommended formats in order of preference for contact center deployments:
Resolving an Asterisk sound files path issue comes down to understanding three things: where Asterisk looks for audio files, what formats it can decode, and whether the process user has permission to read them. The vast majority of audio prompt failures in contact center environments trace back to one of these three areas, and all three are correctable within minutes once properly diagnosed.
The step-by-step diagnostic and fix sequences in this guide give any contact center IT team a repeatable process for resolving audio issues without extended downtime. The best-practice recommendations ensure the problem does not resurface after the next OS patch or configuration migration.
At DialerKing, our engineering team has deployed and maintained Asterisk-based contact center platforms for over 15 years, including complex VICIdial environments, custom IVR trees, and multi-site dialer configurations. We pre-validate sound file structures, dialplan configurations, and format module compatibility as part of every deployment, so your agents and customers never experience silent prompts or broken queue audio.
If you are still experiencing Asterisk sound file issues after following this guide, or if you need a fully configured contact center dialer platform that eliminates these problems from the start, contact the DialerKing team today.
We offer platform assessments, deployment services, and ongoing support for Asterisk, VICIdial, and IVR systems of all scales.
Visit www.dialerking.com or reach out to our technical team for a consultation.
