Freeswitch: the path of least resistance

Some lyrics

How many I remember myself in the chair of the system administrator (and the total experience is already approaching 15 years), so many questions of office telephony were perceived by me as a line from Californication California-based RHCP: hard core soft porn. Telephony always seemed to be a parallel dimension; I tried not to go into its administration and configuration. More precisely, generally bypassing all these telephone questions in a wide arc, throwing off all such tasks on "specially trained people."

However, as often happens, how much rope does not curl, and the end is one ... After finding a job in a new organization, I became the “happy” administrator of the perfect bundle of Ericsson digital-analog PBX and Cisco 2911 Cisco Integrated Services Router. More than a hundred analog phones, three a dozen digital Ericsson and two or three dozen Cisco and Ericsson IP phones. All this splendor was once set up by the hard core soft porn specialists themselves, and to this day I still present only in general terms. However, be that as it may, what is an extension, how is conditional and unconditional redirection organized, how does IVR work, what is DID, etc., I still had to find out. And I was not thrilled with the acquired knowledge (yes, not everything that is useful is interesting and pleasant). Only the tsiska, after I mastered the logic of its setting, became a more or less pleasant piece of iron.

At some point, the humility came that telephony is still an integral part of the system administrator's household.

A Sound of Thunder

The organization in which I work moves to another building. Of course, all analog and digital equipment remains at the place of perpetual residence. Tsiskovsky VoIP in the preparation of 2911 provides 50 lines, and the price tag on tsisko telephones is completely inhuman. And either because of the humility that has already come, or because of an innate burden of knowledge, or through a combination of these two factors, I decided that I would pick up telephony myself at a new place.
')
The requirements were simple: cheap, and better for free, ~~and, ideally, for extra pay~~ , to provide basic functionality (direct city numbers for employees, IVR, call forwarding, conferences, call transfer), from 150 lines and above. The first word that came to mind was “SIP”, the second “Asterisk”, the third “Google”.

AsteriskNOW was downloaded and deployed. Stunned in the web interface. I appreciated again the hardcornsoftporn logic of telephonists and again went to google. And accidentally came across the word "FreeSWITCH". New word, new search queries. Praise odes of sustainability, ease of customization (everywhere XML), undemanding of resources, plus the work out of the box, plus the “people” without any complaints, works in a virtual environment with hundreds and even thousands of lines without voice distortion (although the developers do not recommend virtual environments due to the lack of access to the CPU in real time). OK. We try.
Raise a virtual machine under the recommended Debian 8 x64, 1 2 GHz core, 2 gig of RAM, 16 gig disk. We carry out the installation in accordance with the instructions ( tyts ). We set up a softphone (I liked the 3CX feature set).

Softphone is registered. Test calls have gone. Lyapota. Ericsson Dialog 4422 also registered, ringing, the voice is heard in both directions. Lyapota. The Cisco 7945 device was grafted with SIP-enabled firmware, and, after relatively brief dances with the SCCP setup, the device also registered and the calls went without any complaints. Lyapota. FreeSWITCH in production!

Enough lyrics

Initial data:

Switching ground floor equipment:

The switch is owned by MTS, where we are allocated a group of ports. From it we take the Internet and we will take the SIP-telephony. Traffic tagged vlan4
Our switch, he has allocated a group of ports, which are assigned to vlan. An Internet from MTS (port 2 - vlan2), an Internet from Miralogic (port 3 - vlan3), SIP from MTS (port 4 - vlan4) comes to these ports. Port 1 is also allocated for trunk, the cable goes to the server floor of the fourth floor.

Server equipment on the fourth floor:

A switch that accepts trunk from the first floor. Port 1 - trunk inbound (from the first floor. Port 2 - outgoing trunk (to the server).
Server, on it is VMware vSphere 6. On this host, a guest machine with Mikrotik RouterOS, acting as a gateway and firewall. Also on this host is a guest machine with FreeSWITCH. A vSwitch is configured on the host and ports with the appropriate traffic tagging have been added: vlan2, vlan3, vlan4.

M1 telephony provides us. From MTS, however, was provided for the test SIP-trunk.
These are the settings that were sent to me by MTS engineers:

 !  SIP     9  5555555 ip-: 172.16.160.154 : 255.255.255.252 : 172.16.160.153   ,  -  sip-: 172.16.253.3, port: 5060 UDP media-: 172.16.253.4, port: 10000 - 30000 UDP : G711a/u   DTMF: rfc-2833

The machine with FreeSWITCH has one network interface, network settings:

 IP: 172.18.253.1 Netmask: 255.255.0.0 GW: 172.18.1.254

Flew, Mikrotik

Extinguish the guest machine with Mikrotik and add another network interface, assign it vlan4. Turn on the guest machine, Mikrotik is loading, we see that the new interface has appeared.

Customizable.

Configuring the interface in Mikrotik

We list the available interfaces:
/interface ethernet print

We see that the newly added interface is an interface named ether6
Rename it to if-sip:
/interface ethernet set [ find default-name=ether6 ] name=if-sip

Set up the address:
/ip address add address=172.16.160.154/30 comment=mts-sip interface=if-sip network=172.16.160.152

We configure routing in Mikrotik

We configure mangle (so that the traffic will be marked as we want, and that the traffic will go only through the interface we need based on these labels):

/ip firewall mangle add action=mark-routing chain=prerouting comment="mark sip traffic" new-routing-mark=sip src-address=172.18.253.1

Configure routing:
/ip route add comment=mts-sip distance=1 dst-address=172.16.0.0/16 gateway=172.16.160.153 routing-mark=sip

We configure firewall and NAT in Mikrotik

We configure the absence of filtering with a firewall (at this stage I am not afraid of evil hackers from a SIP trunk from MTS PAN addresses ):

/ip firewall filter
add chain=forward comment="allow any to mts-sip" dst-address=172.16.0.0/16 in-interface=if-local out-interface=if-sip src-address=172.18.253.1
add chain=forward comment="allow any from mts-sip" dst-address=172.18.253.1 in-interface=if-sip out-interface=if-local src-address=172.16.0.0/16

Make sure the two allow rules are located at the very top of the list of rules. This will reduce the load on the firewall.

For myself, I decided that my SIP gateway would be located on the local network so that:

Do not have a trachyudia with the reluctance of individual telephones to work with the gateway behind NAT.
Internal traffic is dozens of times higher than outgoing and incoming traffic together,
no need to drive him through the Mikrotik.
And in general, setting up the gateway once will be more far-sighted than fighting with a multitude of telephones (hundreds) with different firmware, or even different manufacturers, in the future.

For this reason, we configure 1: 1 NAT .

/ip firewall nat
add action=netmap chain=srcnat comment="source NAT for sip" src-address=172.18.253.1 to-addresses=172.16.160.154
add action=netmap chain=dstnat comment="destination NAT for sip" dst-address=172.16.160.154 to-addresses=172.18.253.1

If you disabled the service ports, turn sip back on:
/ip firewall service-port set sip ports=5060,5061,5080,5081 disabled=no

We ping the gateway (172.16.160.153), ping the SIP gateway (172.16.253.3), and ping the Media gateway (172.16.253.4). Pings are walking. Perfectly.

At this easy and understandable part is over.

Flew, FreeSWITCH

For the “release”, we will need to do the following things, the names of which are foreign to the ear of an IT person who has not encountered telephony:

Specify which IP addresses and where to use FreeSWITCH to establish connections.
Specify the region code and subscriber number allocated by the operator.
Create extension - subscriber number. Out of the box, FreeSWITCH has 30 pre-configured subscriber numbers. We will create another one.
Create a gateway. This is not what you thought. A gateway is a named set of settings required to connect to the provided SIP trunk. We will not do this,
we will change default gateway settings
Configure dialplan. Transliteration has a terrible sounding word. In the correct pronunciation, the sound is even worse. I do not like. In the well-established spelling and pronunciation of "dialplan". Means a set of scripts. From this set, depending on the condition that triggered, FreeSWITCH performs one or another action. Dialplans are created for outgoing and incoming calls.
Configure ACLs for networks and domains from which calls are allowed.

Disclaimer : FreeSWITCH is assumed to be installed in the default folder: / etc / freeswitch

The very first thing we do is change the default password. But again, not because you thought. Although, therefore, too. The password is checked by dialplan, and if the password coincides with the default password, then a 10-second pause is inserted before the connection. Therefore, we first change the password.
File: /etc/freeswitch/vars.xml

 <X-PRE-PROCESS cmd="set" data="default_password=ballsofsteel"/>

Alternatively, if you really like the password “1234”, you can remove the pause from the dialplan by simply editing the corresponding block.
File: /etc/freeswitch/dialplan/default.xml

 <condition field="${default_password}" expression="^1234$" break="never"> <action application="log" data="Fuck pretense just let's dance"/> <action application="log" data="Never Open $${conf_dir}/vars.xml and change default password."/> </condition>

IP address settings
File: /etc/freeswitch/sip_profiles/external.xml

 <param name="ext-rtp-ip" value="172.16.160.154"/> <param name="ext-sip-ip" value="172.16.160.154"/>

Regional Settings
File: /etc/freeswitch/vars.xml

 <X-PRE-PROCESS cmd="set" data="outbound_caller_name=3435555555"/> <X-PRE-PROCESS cmd="set" data="outbound_caller_id=3435555555"/> <X-PRE-PROCESS cmd="set" data="default_areacode=343"/> <X-PRE-PROCESS cmd="set" data="default_country=RU"/>

Details from the operator
File: /etc/freeswitch/vars.xml

 <X-PRE-PROCESS cmd="set" data="default_provider=172.16.253.3"/> <X-PRE-PROCESS cmd="set" data="default_provider_username=3435555555"/> <X-PRE-PROCESS cmd="set" data="default_provider_password=not-used"/> <X-PRE-PROCESS cmd="set" data="default_provider_from_domain=172.16.253.3"/> <X-PRE-PROCESS cmd="set" data="default_provider_register=true"/> <X-PRE-PROCESS cmd="set" data="default_provider_contact=73435555555"/>

The most interesting note

You, probably, just noticed that the value of the default_provider_register parameter doesn’t fit in a bit with the settings that the operator issued ( connection without registration, point - point ). However, in the case of the MTS, registration was still needed, without it, outside calls did not go inside. With that, without registration it was quite possible to call from the inside to the outside. This feature drank a lot of blood to me, before I grasped and caught it.

A characteristic sign that authorization is required is a 407 Proxy Authentication Required error.

This error is caught by enabling SIP tracing:
sofia global siptrace on

Turns off tracing, respectively:
sofia global siptrace off

Add a subscriber number (extension)
Create an xml file with any name in the / etc / freeswitch / directory / default folder. I created a file with the same name.
File: /etc/freeswitch/directory/default/4545.xml

 <include> <user id="4545"> <params> <param name="password" value="$${default_password}"/> <param name="vm-password" value="4545"/> </params> <variables> <variable name="toll_allow" value="domestic,international,local"/> <variable name="accountcode" value="4545"/> <variable name="user_context" value="default"/> <variable name="effective_caller_id_name" value=" .."/> <variable name="effective_caller_id_number" value="4545"/> <variable name="outbound_caller_id_name" value="$${outbound_caller_name}"/> <variable name="outbound_caller_id_number" value="$${outbound_caller_id}"/> <variable name="callgroup" value="techsupport"/> </variables> </user> </include>

Create a gateway
Most likely, after you have configured the IP addresses and filled in the fields in vars.xml with the details provided by the operator, registration at the gateway of the operator will take place without problems.

I didn’t have “no problems”, because MTS sent the details, but the subscriber number (extension) 3435555555 did not start. Before I suspected the operator in the setup, I managed to go through a million options for setting the gateway. However, as a result, the operator created a subscriber number on his SIP-gateway, and everything started, if not with default settings, then with close ones. I give a listing of the mts.xml file, which was obtained by renaming the external.xml file.
File: /etc/freeswitch/directory/default/mts.xml

 <include> <user id="$${default_provider}"> <gateways> <gateway name="$${default_provider}"> <param name="username" value="$${default_provider_username}"/> <param name="password" value="$${default_provider_password}"/> <param name="from-user" value="$${default_provider_username}"/> <param name="from-domain" value="$${default_provider_from_domain}"/> <param name="expire-seconds" value="600"/> <param name="register" value="$${default_provider_register}"> <param name="retry-seconds" value="30"/> <param name="extension" value="$${default_provider_contact}"/> <param name="context" value="public"/> </gateway> </gateways> <params> <param name="password" value="$${default_provider_password}"/> </params> </user> </include>

Now we add permissions to the domain and the network so that our FreeSWITCH does not block attempts to establish connections from the domain and from the operator’s networks. ~~And yes, at this stage I just allow everything.~~ My task is to finally call outside the organization.
File: /etc/freeswitch/autoload_configs/acl.conf.xml

So you can not do

 <list name="lan" default="allow"> <node type="allow" cidr="172.18.0.0/16"/> <node type="allow" cidr="172.16.0.0/16"/> </list> <list name="domains" default="allow"> <node type="allow" domain="172.18.253.1"/> <node type="allow" domain="172.16.253.3"/> <node type="allow" cidr="172.16.0.0/16"/> <node type="allow" cidr="172.18.0.0/16"/> </list>

 <list name="lan" default="allow"> </list> <list name="domains" default="deny"> <node type="allow" cidr="172.16.253.3/32"/> </list>

Note!
ACL is intended only for domains and networks of providers. The domains list should be deny by default. Use of the domain variable should be avoided; cidr and the IP address of the operator's gateway with the / 32 mask should be used instead. Failure to comply with these basic rules leads to unexpected consequences in the form of attempts to force the provider's gateway to authenticate by user and password for incoming calls (Digest-authorization), to get internal subscriber numbers in the wrong context (for example, external , as a result - to switch to ACL authorization, instead of Digest) and disruption of the work of dialplans, etc.
This is not a firewall. Traffic filtering does not occur. These are access lists for FreeSWITCH services.

Congratulations! You can see what we have (not) turned out.
Run the FreeSWITCH console:
fs_cli -rRS
Restart xml's:
reloadxml or F6.
Reboot the ACL:
reloadacl
Reboot the Sofia module responsible for phone connections:
reload mod_sofia
We look that we have connections with gateways.

freeswitch@phone> sofia status Name Type Data State ================================================================================================= external profile sip:mod_sofia@172.16.160.154:5080 RUNNING (0) external::172.16.253.3 gateway sip:3435555555@172.16.253.3 REGED 172.18.253.1 alias internal ALIASED internal profile sip:mod_sofia@172.18.253.1:5060 RUNNING (0) ================================================================================================= 2 profiles 1 alias

Nice Registration at the operator's gateway was successful.
See the details:
sofia status gateway 172.16.253.3

freeswitch@phone> sofia status gateway 172.16.253.3 ============================================================== Name 172.16.253.3 Profile external Scheme Digest Realm 172.16.253.3 Username 3432788299 Password yes From <sip:3435555555@172.16.253.3> Contact <sip:gw+172.16.253.3@172.16.160.154:5080;transport=udp;gw=172.16.253.3> Exten 73435555555 To sip:3435555555@172.16.253.3 Proxy sip:172.16.253.3 Context public Expires 600 Freq 600 Ping 0 PingFreq 0 PingTime 0.00 PingState 0/0/0 State REGED Status UP Uptime 3932s CallsIN 1 CallsOUT 1 FailedCallsIN 0 FailedCallsOUT 0 ==============================================================

The case is for small.

Dialplans
For calls to the outside, we create the mts.xml file from scratch, all other files in the / etc / freeswitch / dialplan / default folder can be renamed with the extension changed / moved to another location / ~~banged~~ .
File: /etc/freeswitch/dialplan/default/mts.xml

 <include><extension name="outbound-city-call"> <condition field="${toll_allow}" expression="local"/> <condition field="destination_number" expression="^(\d{7})$"> <action application="set" data="effective_caller_id_number=${outbound_caller_id_number}"/> <action application="set" data="effective_caller_id_name=${outbound_caller_id_name}"/> <action application="bridge" data="sofia/gateway/${default_gateway}/8${default_areacode}$1"/> </condition> </extension> <extension name="outbound-country.cellular-call"> <condition field="${toll_allow}" expression="domestic"/> <condition field="destination_number" expression="^8(\d{10})$"> <action application="set" data="effective_caller_id_number=${outbound_caller_id_number}"/> <action application="set" data="effective_caller_id_name=${outbound_caller_id_name}"/> <action application="bridge" data="sofia/gateway/${default_gateway}/8$1"/> </condition> </extension> <extension name="outbound-international-call"> <condition field="${toll_allow}" expression="international"/> <condition field="destination_number" expression="^(810\d+)$"> <action application="set" data="effective_caller_id_number=${outbound_caller_id_number}"/> <action application="set" data="effective_caller_id_name=${outbound_caller_id_name}"/> <action application="bridge" data="sofia/gateway/${default_gateway}/810$1"/> </condition> </extension> </include>

For calls from outside to inside, we create the mts_inbound.xml file in the / etc / freeswitch / dialplan / public folder. The rest in this folder can be renamed to * .bck or * .noload by analogy above .
File: /etc/freeswitch/dialplan/public/mts_inbound.xml

 <include> <extension name="public_did"> <condition field="destination_number" expression="^(73435555555)$"> <action application="set" data="domain_name=$${domain}"/> <action application="transfer" data="4545 XML default"/> </condition> </extension> </include>

Well. Fingers crossed, check.

Run the FreeSWITCH console again:
fs_cli -rRS
Restart xml's:
reloadxml or click F6
Reboot the dialplan module, which is responsible for telephone connections:
reload mod_dialplan_xml
We try to dial from inside to outside. We try to dial outside from inside. We happily repeat the test “one, two, two,” and make sure that the sound goes both ways. We check the passage of clear-out signals in both directions.

We are glad to have joined soft porn.

PS: I deliberately avoided deciphering the meaning of any edits. Partly, because the names of parameters and system variables speak very well for themselves. Partly so as not to turn the turbo launch of telephony into a nude with the excuses of each bunch.

PPS: The writing of this text was dictated by the horror of the fact that I could not find an intelligible manual in a piece of text where the same task would be solved: as simply as possible, to lift telephony with point-to-point authorization as quickly as possible. The abundance of documentation for some reason is not accompanied by an abundance of discussions and living examples. Or it just so happened that I finished the whole thing faster than googled “the very example” that would work for me. Anyway, let this be a cheat sheet for me and colleagues for the future.

Source: https://habr.com/ru/post/348458/

All Articles