Types of Audio Quality Problems
| Problem | Symptoms | Common Cause |
|---|
| Echo | Caller hears their own voice repeated | Analog interface impedance, acoustic feedback, hybrid circuit |
| Jitter | Audio sounds choppy, words cut in/out | Variable network latency, insufficient jitter buffer |
| Packet Loss | Missing syllables, robotic voice | Network congestion, overloaded switch/router |
| Latency | Long delay between speaking and hearing | Geographic distance, transcoding, buffering |
| Static/Noise | Background hiss, crackling sounds | Bad cabling, electrical interference, low-quality codec |
| Choppy Audio | Audio breaks up regularly | CPU overload (transcoding), packet loss, timer issues |
Jitter Buffer Configuration
The jitter buffer smooths out variable packet arrival times. Without it, packets that arrive even slightly out of order or late cause audible glitches. Asterisk has a built-in adaptive jitter buffer.
Enable Jitter Buffer (sip.conf):
[general]
; Enable the jitter buffer
jbenable=yes
; Force jitter buffer on all channels (even if one side doesn't need it)
jbforce=yes
; Jitter buffer implementation: fixed, adaptive, or netEQ (if available)
jbimpl=adaptive
; Maximum jitter buffer size in milliseconds
jbmaxsize=200
; Resync threshold in ms (reset buffer if drift exceeds this)
jbresyncthreshold=1000
; Log jitter buffer stats (useful for diagnostics)
jblog=no
PJSIP Jitter Buffer:
; In pjsip.conf - jitter buffer is per-endpoint:
[my-endpoint]
type=endpoint
; PJSIP uses its own jitter buffer implementation
; Adjust via the pjproject build options or res_pjsip settings
Tuning Tip: Set jbmaxsize based on your network. For LAN calls, 50-100ms is enough. For WAN/internet calls, 150-200ms. For satellite or very high latency, up to 500ms. Larger buffers add latency but reduce choppiness.
Echo Cancellation
Echo in VoIP typically comes from two sources: acoustic echo (speaker audio picked up by microphone) and hybrid echo (electrical reflection at the 2-wire/4-wire junction in analog circuits). For DAHDI (analog) channels, echo cancellation is critical.
DAHDI Echo Cancellation (chan_dahdi.conf):
; In /etc/asterisk/chan_dahdi.conf:
[channels]
; Enable echo cancellation
echocancel=yes
; Echo cancellation tail length (128 or 256 taps)
; 128 taps = 16ms, 256 taps = 32ms
echocancel=128
; Echo training (learns the echo pattern at call start)
echotraining=800 ; Train for 800ms at call start
; Use OSLEC (Open Source Line Echo Canceller) - much better than default
; First install OSLEC module, then:
; echocancel=oslec
Install OSLEC (Recommended):
# OSLEC provides significantly better echo cancellation than the default
# Install on Debian/Ubuntu:
apt-get install dahdi-linux dahdi-tools
# Edit /etc/dahdi/system.conf to use OSLEC:
# echocanceller=oslec,1-4
# Regenerate DAHDI config and restart
dahdi_genconf
systemctl restart dahdi
asterisk -rx "dahdi restart"
# Verify echo canceller is active:
asterisk -rx "dahdi show channels"
cat /proc/dahdi/1 # Check echo canceller status
SIP Phone Echo:
For echo on SIP (VoIP-only) calls, the problem is usually on the phone/headset side:
- Lower the speaker volume on the phone/headset
- Use a headset instead of speakerphone
- Enable acoustic echo cancellation (AEC) on the phone itself
- Check for firmware updates for the SIP phone
- Reduce the TX gain:
txgain=-3.0 in chan_dahdi.conf
QoS & DSCP Configuration
Quality of Service (QoS) marks VoIP packets with DSCP (Differentiated Services Code Point) values so network equipment can prioritize them over regular data traffic. This is essential on congested networks.
Asterisk QoS Settings:
; In sip.conf [general]:
; DSCP values for SIP signaling and RTP media
tos_sip=cs3 ; SIP signaling: CS3 (DSCP 24)
tos_audio=ef ; RTP audio: EF (DSCP 46) - Expedited Forwarding
tos_video=af41 ; RTP video: AF41 (DSCP 34)
; Or use numeric values:
; tos_sip=0x60
; tos_audio=0xB8
; Also set CoS (Class of Service) for Layer 2 (802.1p/q):
cos_sip=3
cos_audio=5
cos_video=4
; In pjsip.conf:
[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0:5060
tos=0x60 ; SIP signaling TOS
cos=3 ; SIP signaling CoS
Linux QoS with iptables:
# Mark RTP packets with DSCP EF (46)
iptables -t mangle -A OUTPUT -p udp --sport 10000:20000 -j DSCP --set-dscp 46
# Mark SIP signaling with DSCP CS3 (24)
iptables -t mangle -A OUTPUT -p udp --sport 5060 -j DSCP --set-dscp 24
iptables -t mangle -A OUTPUT -p udp --dport 5060 -j DSCP --set-dscp 24
# Verify the markings
tcpdump -i eth0 -n -v udp port 5060 | grep tos
Network Diagnostics
Before tuning Asterisk settings, diagnose the network. VoIP requires:
| Metric | Acceptable | Good | Excellent |
|---|
| Latency (one-way) | < 150ms | < 80ms | < 30ms |
| Jitter | < 30ms | < 15ms | < 5ms |
| Packet Loss | < 1% | < 0.5% | 0% |
| Bandwidth per G.711 call | ~87 kbps (with Ethernet overhead) |
| Bandwidth per G.729 call | ~31 kbps (with Ethernet overhead) |
# Measure latency and jitter to your SIP provider
ping -c 100 sip.provider.com
# Look at avg and mdev (mean deviation = jitter)
# Use mtr for detailed path analysis
mtr -n -c 100 sip.provider.com
# Measure packet loss with iperf (UDP mode simulates VoIP)
# On remote side: iperf -s -u
# On Asterisk: iperf -c remote.ip -u -b 1M -t 60
# Check for network interface errors
ethtool -S eth0 | grep -i error
ifconfig eth0 | grep -i error
# Monitor real-time RTP quality from Asterisk
asterisk -rx "rtp set debug on"
# Watch for sequence number gaps (packet loss) and timing jitter
Codec Selection for Quality
| Codec | Bitrate | Quality (MOS) | CPU Load | Best For |
|---|
| G.711 ulaw | 64 kbps | 4.1 | None | LAN, high bandwidth links |
| G.711 alaw | 64 kbps | 4.1 | None | LAN, European standard |
| G.722 | 64 kbps | 4.5 | Low | HD voice, wideband calls |
| G.729 | 8 kbps | 3.9 | High | Low bandwidth WAN trunks |
| Opus | 6-510 kbps | 4.5+ | Medium | WebRTC, variable bandwidth |
| GSM | 13 kbps | 3.5 | Low | Legacy, low bandwidth |
| iLBC | 15 kbps | 3.7 | Medium | Lossy networks (built-in PLC) |
Recommendation: Use G.722 for HD voice quality on LAN. Use G.711 for standard quality with zero CPU overhead. Use Opus for WebRTC clients. Avoid G.729 unless bandwidth is truly constrained — the quality difference is noticeable and CPU cost is high.
Related Solutions