Asterisk Audio Formats Explained
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:
- 20 ms packetization interval, or 50 RTP packets per second
- IPv4, UDP, and RTP transport
- 18 bytes of Ethernet overhead per packet
- No SRTP, VPN, VLAN, or compressed RTP headers
- 80% of the nominal link rate available for voice media
- Equal media in both directions
- No other traffic, retransmission, transcoding, or provider capacity limit
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
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.