Asterisk Audio Formats Explained

Getting Started -- Last reviewed 2026-08-22 audio music-on-hold sox formats codec Found this useful? Upvote it. ×

Asterisk plays audio files for music on hold, IVR prompts, and voicemailAsterisk's built-in voice messaging system (app_voicemail), configured in voicemail.conf with mailboxes per user. greetings. For best performance, these files should be in a native codecA coder-decoder that compresses audio for transmission, such as ulaw, alaw, GSM, or Opus. Endpoints negotiate which codec a call uses. format so Asterisk does not need to transcode them in real time. This guide explains each supported format, when to use it, and how to convert files on the command line.

Supported formats

Format ExtensionA dialplan entry that matches a dialed number or pattern within a context and triggers a sequence of prioritized steps. Use case
G.711 u-law .ulaw North American telephony (T1/PRI lines). Most common Asterisk format.
G.711 a-law .alaw European and international telephony (E1 lines).
GSM .gsm Good compression, widely compatible. Default for many Asterisk installations.
WAV (PCM) .wav Uncompressed 8 kHz 16-bit. Highest quality, largest file size.
Signed Linear .sln Raw PCM with no header. Asterisk internal format. Smallest overhead.
G.722 .g722 Wideband (16 kHz). Higher quality on PJSIPThe modern SIP channel driver in Asterisk (chan_pjsip), replacing the older chan_sip. Configured in pjsip.conf using endpoints, AORs, auths, and transports. endpoints that support it.

All narrowband formats use 8 kHz sample rate and mono (single channelA single call leg passing through Asterisk. Channels represent connections to endpoints and are what dialplan applications act on.). G.722 uses 16 kHz for wideband audio on endpoints that support it.

ulaw vs alaw: which one do I need?

Both are G.711 codecs encoding audio at 64 kbps. They sound nearly identical but are not interchangeable. U-law (mu-law) is the standard in North America and Japan, used on T1/PRI lines. A-law is the standard in Europe and most other regions, used on E1 lines.

Check what codec your SIPSession Initiation Protocol, the standard signaling protocol used to set up, manage, and tear down VoIP calls between Asterisk and phones or carriers. trunkA connection between Asterisk and another PBX or an ITSP/carrier, used to send and receive external calls. or ISDN lines use and convert to match. If your system handles both (common with PJSIP), provide files in both formats and let Asterisk pick the right one.

When to use G.722 wideband

G.722 uses a 16 kHz audio sampling rate, twice the sampling rate of G.711, and sounds noticeably better for voice. Its common network payload rate is still 64 kbps, the same as G.711, so it does not require twice the network bandwidth. If your PJSIP endpoints negotiate G.722, providing .g722 files means callers on hold or listening to IVR prompts get wideband audio. Asterisk will fall back to narrowband formats for endpoints that do not support G.722.

G.722 conversion requires ffmpeg since sox does not support the codec natively.

Why provide multiple formats?

When Asterisk needs to play audio, it looks for a file in the codec that matches the caller's channel. If your MOH directory only has .wav files but the caller is on a G.711 u-law channel, Asterisk transcodes in real time, using CPU. On a busy system with many concurrent calls on hold, this adds up.

If you provide the same file in multiple formats (.ulaw, .alaw, .gsm, .wav, .g722), Asterisk picks the best match with zero transcoding overhead.

Converting files with sox

sox (Sound eXchange) is the standard command-line tool for Asterisk audio conversion. The basic command resamples to 8 kHz, converts to mono, and encodes to the target format:

sox input.mp3 -r 8000 -c 1 -t ul output.ulaw
sox input.mp3 -r 8000 -c 1 -t al output.alaw
sox input.mp3 -r 8000 -c 1 output.gsm
sox input.mp3 -r 8000 -c 1 -b 16 output.wav
ffmpeg -i input.mp3 -ar 16000 -ac 1 -acodec g722 output.g722

Add lowpass 3400 highpass 300 after the output filename for telephone bandpass filtering. Add gain -n -3 for volume normalization.

If you prefer not to install sox locally, the Asterisk Audio Converter runs the same commands on the server and lets you download all formats at once.

Rotating hold-music start positions

Asterisk's default music-on-hold behavior selects a file randomly from the directory but always plays it from the beginning. With only one track, every caller hears the same opening chords. Rotated variants create the perception of variety without needing additional source music: take a single track, clip it at evenly spaced points, and append the clipped portion to the end.

This matters even for small phone systems. A dental office, a small law firm, or a retail shop may not get many calls, but the callers they do get (patients, clients, vendors) are often the same people calling back. Without rotation, those repeat callers hear the exact same 30 seconds of hold music every time. With rotated variants, Asterisk picks a different start point for each hold session, so the music feels fresh even though it comes from one source file.

Place all the variants in your Asterisk MOH directory. Asterisk will randomize across them automatically:

[default]
mode=files
directory=/var/lib/asterisk/moh/default
; Place hold-music.ulaw, hold-music-offset-30s.ulaw, etc. in this directory

Rotation works best with tracks at least 10-15 seconds long. Very short clips produce abrupt seams when rotated.

Codec bandwidth and concurrent call capacity

Codec choice affects network capacity as well as audio quality. The codec payload is only part of the traffic. Every RTPReal-time Transport Protocol. Carries the actual audio (media) of a VoIP call after SIP signaling has set it up. packet also carries IP, UDP, and RTP headers, and the link may add Ethernet, VLAN, SRTP, VPN, or tunnel overhead.

Calculation assumptions

The estimates below use these assumptions:

The approximate one-way bandwidth formula is:

one-way bandwidth = codec payload rate
                 + (IP/UDP/RTP overhead + link overhead) × packets per second × 8

With IPv4, UDP, RTP, and Ethernet, the per-packet overhead used here is 58 bytes. At a 20 ms packetization interval, that overhead is approximately 23.2 kbps per direction. SIP signaling is not included because it is small compared with the RTP media stream.

Approximate bandwidth per call

Codec Typical payload rate Approx. one-way media Approx. bidirectional media
G.711 u-law 64 kbps 87 kbps 174 kbps
G.711 A-law 64 kbps 87 kbps 174 kbps
G.722 64 kbps 87 kbps 174 kbps
G.729 8 kbps 31 kbps 62 kbps
GSM 13.2 kbps 36 kbps 73 kbps
Opus 32 kbps example 55 kbps 110 kbps

G.722 has wideband audio because of its sampling and coding characteristics, not because it consumes twice the network bandwidth of G.711. Opus is variable bitrate, so its result depends on the configured bitrate, packetization, and use of features such as in-band forward error correction.

These are planning estimates, not wire captures. The exact result changes with packetization interval, codec mode, RTP extensions, encryption, transport, and implementation.

Estimated simultaneous calls

The following table applies the 80% usable-link assumption to the bidirectional estimates above. It represents approximate simultaneous calls for voice media only:

Link rate G.711 or G.722 G.729 GSM Opus at 32 kbps
1 Mbps 4 12 10 7
5 Mbps 22 64 54 36
10 Mbps 45 128 109 72
50 Mbps 229 641 548 362
100 Mbps 459 1,282 1,096 724

The table is a starting point for sizing an uplink, not a promise that Asterisk can handle that many calls. CPU, transcoding, RTP timing, encryption, NAT, jitter, packet loss, SIP trunk limits, firewall state tables, and concurrent non-voice traffic can reduce the practical capacity substantially. Leave additional headroom for bursts and data traffic, and validate the result under realistic load.

Packetization and transport overhead

A shorter packetization interval increases overhead because more packets are sent per second. A longer interval reduces overhead but can increase latency and the amount of audio lost when a packet is dropped.

IPv6 adds 20 bytes to the network-layer header compared with IPv4. VLAN tags, VPNs, SRTP authentication tags, RTP header extensions, and tunnel headers add more. Compressed RTP can reduce header overhead on suitable links, but it requires compatible equipment and careful testing.

Voice capacity should be measured in both directions. A link advertised as 10 Mbps may have asymmetric upload and download capacity, and the smaller direction can be the limiting factor. Wireless links and shared Internet connections also need additional margin for contention and variable latency.

Interactive calculator

An interactive bandwidth and capacity calculator may be added to this guide in the future. If provided, it should use the same codec data and formulas as the tables above while preserving the static reference tables for readers and search engines.

See also

A solid choice for hosting Asterisk.

High-performance cloud compute starting at $2.50/mo. Deploy a VPS in seconds.

Get $100 Free Credit

Referral link. Helps support this site.

User Notes

Know a tip or gotcha for this topic? Share it below and help others.

Contribute a note

Share a tip, gotcha, or practical example. Keep it under 2000 characters. No questions (use the Asterisk community forums for support). Wrap code in backticks.

Moderated before publishing. Email never shown.
Related Snippets