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:
Verbose |
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 |
Debug messages, normally only used by programmers to extract extended information |
Notice |
Non urgent alert messages |
Warning |
Warning alert messages, something happened that might be bad. Some tell you how bad the warning is |
Error |
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
|
[logfiles] 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
|
[logfiles] 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
example:
|
[logfiles] 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
logger.conf
|
[logfiles] syslog.local0 => debug, warning,
error, notice, verbose |
And /etc/syslog.conf
|
local0.* @192.168.1.22 |
This would send the Asterisk
logging information to the syslog server at 192.168.1.22.
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
command
|
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 asterisk*CLI> |
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. |
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
|
rtpstart=10000 rtpend=20000 |
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:
|
[general] port=5060 bindaddr=0.0.0.0 |
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 0.0.0.0 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 e.g. _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.
Understanding
configs - TODO
<- ...Back> Continue... ->