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 FreePBX 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 a free account with DynDNS
or some similar service. 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, there are instructions for doing that at this blog page.

Make use that your system knows its own name.

Once you get a DynDNS or other address that identifies your system
on the Internet, put it in your etc/hosts file. For example, if you are
assigned foo.dyndns.net, then open etc/hosts in your favorite text
editor (nano, or Midnight Commander's editor will do - use mc -a from the command prompt to access Midnight Commander) and look for this line:

127.0.0.1 localhost

DO NOT REMOVE OR CHANGE THAT LINE. On a NEW line directly underneath it, place this line:

127.0.0.1 foo.dyndns.net

But substitute YOUR address, of course.

Add some information to your /etc/asterisk/sip_nat.conf file

If this file doesn't exist you'll have to create it, but make sure
that the ownership and permissions match those of sip.conf and other
files in that directory. You can use the command

touch /etc/asterisk/sip_nat.conf

To create the file. I personally use Midnight Commander's "Advanced
CHOWN" feature to check and change permissions; if you are a true Linux
geek you probably already have a preferred method.

Now edit the file and insert AT LEAST these two lines:

externip=your.external.dotted.IPaddess

localnet=192.168.0.0/255.255.255.0

The above localnet line assumes that your local network uses
192.168.0.x addresses, but if it uses something else, make the
appropriate substitution.

Personally I use four lines, as follows:

nat=yes

externip=your.external.dotted.IPaddess

fromdomain=foo.dyndns.com

localnet=192.168.0.0/255.255.255.0

The "fromdomain" line would contain your public
address, while "externip" contains the numeric IP address your ISP has
assigned you (which hopefully doesn't change often).

If your ISP does change IP addresses on you frequently, and for
some reason you can't/won't change ISP's or get a static IP address,
and you are running at least Asterisk 1.2.x then there is an
alternative way to specify your address to the system:

externhost=foo.dyndns.net

externrefresh=10

These are used IN PLACE OF the "externip" (and "fromdomain", if you
have included that) lines. DO NOT use both "externhost" and "externip."
Supposedly, "externhost" will cause Asterisk to perform DNS queries
periodically, but they say it is "Not recommended for production
environments!" and suggest using "externip" instead. "externrefresh"
tells the system how often to refresh "externhost"

Reload SIP

After you have added whichever lines you need in sip_nat.conf, go to the Command Line Interface and type

sip reload

And hit enter. Alternately you could restart Asterisk, but that will interrupt any calls that are in progress.

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 pointed at your Asterisk server. For SIP protocol, open UDP
(NOT TCP) port 5060 (SIP) AND ports 10001-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.

Check your /etc/asterisk/rtp.conf file

It should contain these two lines:

rtpstart=10001

rtpend=20000

If the port values are any different, change them. N.B. These MUST
match what you opened in your firewall, and DO NOT start with port
10000, because it conflicts with usage in Webmin (and despite what
anyone may tell you, Webmin does use UDP port 10000 in addition to
TCP port 10000 - it uses the UDP port in an attempt to discover and
communicate with other Webmin servers running on your network. So don't
believe anyone who tells you that Webmin only uses TCP port 10000 and
therefore there is no conflict).

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 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 but whomever you are
connecting to. There are actually five different places that codecs can
be specified:

• At an endpoint/device (phone or ATA), typically in the device's configuration.
• In a FreePBX EXTENSION configuration, however it's best to leave those settings blank in most cases.
• 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.
• In sip.conf, using allow= statements coupled with
  disallow=all. These are the system defaults for SIP calls but can be
  overridden by trunk or extension settings.
• In iax.conf, using allow= statements coupled with
  disallow=all. These are the system defaults for IAX calls but can be
  overridden by trunk or extension 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 show translation from the Command
Line Interface - if there is a number showing between two codecs in the
grid then translations are possible, if 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 zaptel card (it appears that having ANY
non-configured zaptel card in a system may cause problems with audio
output).