Resolving Audio Problems

One of the most common issues to plague new users is the lack of audio. Calls appear to complete, and show up in the call detail, etc. but nothing is heard by one or both of the parties on the conversation. This section of the wiki will be devoted to such problems and their solutions, and I encourage others to add to it as you encounter problems and then discover the solution, particularly if it's not posted here already.

NAT issues

Perhaps the most common problem encountered is one-way audio, and 99% of the time, this is caused by a NAT firewall. So here are the steps you must take to configure the PBX to work behind a NAT firewall.

Make sure you have a resolvable address on the Internet.

If you don't want to pay a few bucks to get a static IP address, and are served by an ISP that periodically changes your IP address, then get an account with a dynamic DNS service such as DynDNS. Your router may already have built-in support for one or more of these services. If so, use one that your router supports, and then configure your router to automatically update your dynamic address when your ISP changes your IP address. Failing that, you can set up an updater program such as inadyn.

Adding NAT information in the PBX GUI 

All of your settings will be under Settings > Asterisk SIP settings.

Open

Next, Click Chan SIP in the right menu.

Open

Set NAT as yes.

Static IP from your ISP 

Select "Static IP" and enter your external IP.

Dynamic IP Updated through dynamic IP service

Select "Dynamic IP" and enter the full host name, such as "http://foo.dyndns.net "

After clicking "submit changes" and the red "Apply Config" button, click General SIP Settings on the right menu.

Local Networks

Under "NAT," you will see a box for "Local Networks." 

In these boxes, enter your LAN information with the IP in the first box and the SUBNET in the second box.

If your IP is 192.168.0.254, you would enter 192.168.0.0 / 255.255.255.0

Click "Submit changes" and the red "Apply Config" button.

RTP Port Range

Open the SIP and RTP ports to your Asterisk server

You must make sure that you open the correct UDP ports in your router's firewall and make sure it is pointed at your Asterisk server. For SIP protocol, open UDP (NOT TCP) port 5060 (SIP) AND ports 10000-20000 (RTP, which must also be defined in /etc/asterisk/rtp.conf – see below). All these ports are UDP. Opening the TCP ports will NOT help anything, and may expose your system needlessly. While you are in your firewall configuration, you may as well also open UDP port 4569 (IAX), since sooner or later, you'll probably want to accept IAX connections.

You can see the actual range under the "General SIP Settings" page.

If the port values are any different, change them.  These MUST match what you opened in your firewall.

Some people feel the need to open fewer than 10,000 ports. I don't recommend this, because six months from now, when you start having audio problems, you may not remember that you opened fewer than the recommended number of ports, and you may spend hours troubleshooting the issue. But if you are simply obsessive about open ports, remember that each open SIP connection may require as many as FOUR concurrent ports, so don't cut it down to some ridiculously small number. For the non-paranoid, I suggest sticking with the recommendations above (and remember, if a hacker is looking at ports on your system, he's going to scan ALL of them, so having fewer UDP ports open really doesn't make you any more secure).

CODEC issues

Whenever a call is placed, both ends of the call must agree on the codecs they want to use. If one end speaks only ulaw and the other end refuses to communicate using anything other than gsm, no communication is going to take place. This is why I would recommend that beginners always allow ulaw (also known as g.711u) and alaw (also known as g.711a) unless specifically instructed not to by whomever you are connecting to. There are actually five different places that codecs can be specified:

1. At an endpoint/device (phone or ATA), typically in the device's configuration.

2. In a FreePBX EXTENSION configuration; however, it's best to leave those settings blank in most cases.

3. In a FreePBX TRUNK configuration using allow= statements coupled with disallow=all. If these are omitted, then the defaults in sip.conf and iax.conf are used.

4. In Settings > Asterisk SIP Settings > "General SIP Settings"

5. In Settings > Asterisk IAX Settings

Asterisk will attempt to translate formats if the codecs are available on the system and allowed for that leg of the call. So if you have a trunk that only allows gsm but your extensions will only communicate in ulaw, that's not a problem as long as you have allowed gsm in the trunk configuration. To see the available codecs and translations, type core show translation (or just show translation in Asterisk 1.2 and earlier) from the Command Line Interface. If there is a number showing between two codecs in the grid, then translations are possible. If it's a single line (and it's not to the same codec), then translations are not possible, usually because one of the codecs isn't installed on the system.

Missing files/incorrect paths

If calling into an IVR or voicemail box, and the expected recording isn't played, it's possible that it's missing or not in the expected location. Did you use the System Recordings module to import the recording? If not, are you sure it's in the correct location?

Permissions/ownership issues

This most commonly occurs when people copy audio files directly onto the system and forget that it's a Linux box and that Linux is finicky about file permissions and ownership. If permissions or ownership aren't correct, Asterisk will be unable to access the file, and therefore can't play it. One thing you can try to resolve this is to run the following from the Linux command prompt:

amportal chown

This is supposed to set appropriate permissions on files used by Asterisk.

Incorrect audio format

Sometimes people create system audio files using an external sound file editor, such as Audacity, in order to get better sound quality. What they don't realize is that Asterisk is very picky about the format of audio files it will play back. For example, if the file is .wav file format, Asterisk wants a file recorded at 8000 Hz, 16 bit, monaural (a.k.a. single channel) format, and if you directly upload a file in any other format, the CLI may show that the file is being played, but callers hear nothing. If normal system files play correctly but the files you've created do not, check the format, especially if you've directly copied it to a particular location on the system instead of importing it with the System Recordings module.

Hardware issues

Yes, even a hardware problem can cause audio failures. In one case, a T1 card had been installed in the system but not configured, and that stopped all recorded audio from being played. So if all else fails, look for any unconfigured or misconfigured hardware device, particularly if it's a DAHDI card (it appears that having ANY non-configured DAHDI card in a system may cause problems with audio output).

Related articles