<- ...Back>   Continue... ->



Sometimes, when debugging an issue, it's useful to see and log extra information and at

other times, you want logging to be minimal. Asterisk provides a number of ways of

logging information, to files or to a syslog server. The file /etc/asterisk/logger.conf

contains the configuration elements for logging. Asterisk has different types of message

that can be logged these are:







General 'chatter' about what is

happening on the system.

Verbosity levels greater than 3

display dialplan commands as

they are executed. This

generates lots of log information





Debug messages, normally only

used by programmers to extract

extended information






Non urgent alert messages




Warning alert messages,

something happened that might

be bad. Some tell you how bad

the warning is






Error messages, something bad

happened – These should be rare.



In logger.conf you will see the [logfiles] section, this is where you define the filename

and content of log files. Take a look at this example entry





debug => debug



This tells Asterisk to log debug messages (the right side of the =>) to a file called debug

(the left side of the =>) located in /var/log/asterisk/. This directory can be changed in

/etc/asterisk/asterisk.conf by modifying the line astlogdir => /var/log/asterisk to point

to the desired directory. You can log multiple information types to the same file or you

can spread the information over a number of files. For example





debug => debug

messages=>warning, error



Will log debug messages to a file called debug, and will also log warning and error

messages to a file called messages. There is a special “file” called console which when

used will cause the message types specified to be logged to the Asterisk console, for






console => debug, warning, error, notice, verbose




Would log everything to the console (not to any files). The above is not recommended

since the amount of information that would be generated could be far to much to be of

any real use. If you change logger.conf you need to perform a reload or do a logger

rotate (see next section). You can also log messages to a syslog sever (remote logging

server), useful if you have either a lot of machines or want centralized logging. To do

this use the file syslog, with the suffix you will use in /etc/syslog.conf for example, in






syslog.local0 => debug, warning, error, notice, verbose



And /etc/syslog.conf




local0.*                  @




This would send the Asterisk logging information to the syslog server at


Setting up a syslog server is beyond the scope of this document and is left as an exercise

for the reader.
Rotate logs


It is advisable to rotate your logs frequently, depending on the amount of logging you

have turned on and the about of data that is actually logged. Files larger than 2Gb can

cause some nasty effects resulting in Asterisk crashes. You can rotate logs by using the





logger rotate







This will rename the old log and start a new one. It will also reload logger.conf and

adopt any changes you have made to it.




You can change the verbosity (how much information we get) of the output on processes attached to the Asterisk console by setting the level of verbosity. To do this we use the set verbose command, for example:




set verbose 999







Sets the verbosity level to 999, Asterisk will tell you that the level of verbosity changed




asterisk*CLI> set verbose 999

Verbosity is at least 999




You should see every message when it is set to this level, whereas setting it to 1 will

show very little information.



Setting the verbosity level changes the level on every attached

process (connected via asterisk -r) not just the one you issue the

command from.


Getting to Grips with sip.conf


sip.conf is not difficult to understand, however there is a fundamental problem with SIP making it awkward to use. The problem is not so much with SIP itself, it's more to do with how we protect our networks. We all know that there are some nasty little people out there who are quite happy to steal your resources, make free calls using someone else's money etc. As a consequence of this we tend to put a firewall between them and us. This is where the problems start for SIP. In a network environment that requires no firewall, for example and Internal network, there will be no issues, but in a more complex network, perhaps using NAT (Network address translation) there are all sorts of hurdles to overcome.


You have a number of choices,


1.     Buy yourself a SIP aware firewall, such as the IX66 from Intertex.

2.     Use port forwarding to forward from your firewall to your Asterisk server.

3.     Put your Asterisk server outside your firewall.

4.     Use SIP internally only and IAX2 for communicating with the outside world


Lets look at each one in turn.


Buy yourself a SIP aware firewall, such as the IX66 from Intertex.


This will solve all of your problems with regard to SIP, however, there is a premium to be paid on firewalls that are SIP aware. Given time SIP aware firewalls may become the norm, eliminating the premium paid, but at present you have to pay extra.


Use port forwarding to forward from your firewall to your Asterisk server.


A SIP aware firewall will open and close ports as required when calls come in, port forwarding leaves the ports open all the time. Essentially you tell your firewall to forward any traffic coming in on specific ports to your Asterisk server – This means ANY DATA not just SIP packets. By default, Asterisk wants to use the port 5060 for SIP signalling and (get this) ports 10,000 to 20,000 INCLUSIVE!!! for rtp data (audio) [not just for SIP]. That's 10,000 ports.


Thankfully you can change the range that Asterisk will use by modifying /etc/asterisk/rtp.conf – You should change this to a much more sensible range. The range used will depend on how many concurrent calls you are expecting to receive, but you should be able to cut it down drastically. The default values in rtp.conf are








Change it to something a little smaller than the Grand Canyon. Even 20 ports is a lot, but should be more than enough for a small install.


Put your Asterisk server outside your firewall.

Solves your SIP issues, but you need to be sure that your Asterisk server is fully patched and up to date with OS and Asterisk patches as vulnerabilities are discovered. Often vulnerabilities are discovered after equipment is deployed – Keep your eyes and ears open, subscribe to the vuln mailing lists (you should be doing this if you have any servers exposed on the Internet, not just Asterisk machines).


Use SIP internally only and IAX2 for communicating with the outside world

Cures all your SIP ills in one fell swoop. IAX2 uses a single port for both it's signaling and its audio. However, IAX2 is not an IETF (Internet Engineering Task Force) standard, so not all providers or 3rd parties you connect to support it. 


Getting back to sip.conf...


As with most of the channel configuration files sip.conf starts with a [general] section, this section contains, amongst other things, which port, which IP address etc to use for the protocol.  For example:









Port 5060 is the default for SIP in general, so it makes sense for Asterisk to use the same port – though not essential, it is advisable if dealing with 3rd parties or expecting people to be able to dial a SIP uri and talk direct to you. The bindaddr is used to state which IP address or network card you listen for SIP messages, a value of indicates all IP addresses should be listening for SIP messages. Not particularly useful unless you have more than one network card in your Asterisk server and want to only listen on a particular interface, in which case you can specify the IP address you want to listen on.











If you own your own domain, it may be preferable for people to call you by using a uri. To do this you need to define an SRV record in your DNS server along the lines of




Host, TTL, Type, Data




_sip._udp.yourdomain.com 43200 SRV 0 0 5060 yourdomain.com.



If you are not sure how to configure your DNS then it is suggested that you leave it alone. With the above configuration someone with a SIP phone can dial,  Fred@yourdomain.com and have a SIP phone attached to the user Fred ring.







Getting to Grips with iax.conf



Understanding configs - TODO

<- ...Back>   Continue... ->