Rake, or 5 typical Asterisk configuration errors

The article is aimed at novice users of Asterisk , who, nevertheless,
have knowledge about the operation of computer networks at the CCNA level and who studied the basics of IP-telephony without specialized courses.


1. You do not disable anonymous calls and use the default context for the numbering plan

Problem
By default, anonymous calls are included in Asterisk so that you can be called directly from anywhere in the world, indicating the number @ your domain as the destination of the call and relying on the operation of DNS. This is a very useful feature, but it can play a trick on you if you use the default context for the main numbering. It turns out that anyone who sends a request to phone_number @ your_domain will be able to call intercity at your expense, for example.

Solution
The first rule to always follow is: do not use the default context for numbering. Remember,
the default context is only for anonymous calls from the Internet, consider it as the most untrusted of all. If you do not plan to receive anonymous calls, be sure to disconnect them.

sip.conf
[general]
  allowguest=no

2. You respond differently to the registration request with the correct username and invalid password and to the request with the nonexistent username.

Problem
There are enough people on the Internet who want to call at someone else's expense, so you need to make their life as complicated as possible. Asterisk, by default (until recently, but suddenly you have a not-so-fresh version), responds differently to registration attempts with an invalid username and a valid name but an invalid password. This gives the attacker the opportunity to find out the existing names of subscribers and already purposefully select passwords for them.

Decision

sip.conf
[general]
  alwaysauthreject = yes

3. You do not use ACL access lists and / or dynamic access restriction tools.

Since, despite the efforts made in the previous paragraph, the possibility of password selection is still possible, in all cases, when possible, you should use access control rules (acl)

sip.conf
[my_user]
  deny=0.0.0.0/0
  permit=172.16.0.0/12 ; указывайте сети, откуда может выполняться регистрация

There are cases when it is impossible to use acl - the subscriber can register from an arbitrary network. In this case, you need to use dynamic blocking tools, for example, fail2ban - Asterisk log processing utility to identify and block addresses from which many failed registration attempts were made.

4. In terms of numbering, you missed _ and are surprised that the calls do not go.

A fairly simple mistake, but it is often found among beginners.

Wrong

[citycalls]
  exten => XXXXXX,1,Dial(DAHDI/g1/${EXTEN})

Right

[citycalls]
  exten => _XXXXXX,1,Dial(DAHDI/g1/${EXTEN})

In the first case, you did not specify a template, but a call to XXXXXX (x-x-x-x-x-x-x). Just do not forget that the patterns are specified by _

5. You use nat and the sound goes only one way.

The theme of Asterisk and subscribers between whom in different configurations the address translation is so extensive that it is beyond the scope of this article, but still I’ll give a few useful tips:

1. If there is no sound, take a piece of paper and depict how the traffic (not only SIP, but also RTP) goes between clients. Already at this step you can understand a lot, especially if you know how NAT works.
2. If the clients are potentially located behind the nat, do not let them do reinvite (canreinvite = no in the corresponding section of sip.conf) and set directmedia = nonat if you do not need to pass all the traffic through Asterisk, which may be required to record conversations.
3. Choose one thing: support for nat in Asterisk or SIP support in the firewall of your OS: in Windows ISA Server, SIP support, which is enabled in parallel with nat support in Asterisk, gives a complete absence of sound, so if you cannot affect the OS, set nat = no in relevant sections of sip.conf
4. Remember that in addition to traffic on port 5060 / udp, audio data is transmitted via the RTP protocol through udp ports, the range of which is specified in rtp.conf (by default 100005) -20000)
5. If all else fails, turn on debug in Asterisk and use tcpdump - this will allow you to see where requests and audio traffic go, and understanding the problem is 90% of its solution.

Good luck learning Asterisk!