Introducing FreeSWITCH Part One
At one time I discovered Asterisk and VoIP in general after reading a series of articles on opennet.ru about how to configure it. I will try to repeat this kind of PR for FreeSWITCH.
The installation of FreeSWITCH is nothing special, the msi package for Windows, the sources for all other platforms. Assembly in the standard sequence. For fans of package installation options, it is possible to build deb packages through at least standard debian / rules binary.
')
So, the first thing I have to tell you is that the FS is already set up after installation, it works and is ready, if not for use, then for tests.
The IP address of the host is selected as the domain, there are users with numbers from 1000 to 1019, voice mail is functioning (dial your number when you are registered to listen), three types of conferences (8kHz - 30xx, 16kHz - 31xx, 32kHz - 32xx), and Many examples to demonstrate the possibilities.
And all this is quite possible to immediately begin to use to its fullest, but in any case, the scheme will have to be redone by itself. The main thing that I will tell you is that the demo numbering plan needs to be studied, studied and understood each item - you can find examples of using the newest features in it, and indeed most of the features are there.
Now let's deal with the configuration. The main directory is conf, it contains freeswitch.xml — the root file from which the configuration will be obtained after preprocessing, vars.xml — the file which contains many settings. From this point on in more detail.
For example, the string <X-PRE-PROCESS cmd = "set" data = "domain = $$ {local_ip_v4}" />. It is in this standard line from vars.xml that the name of our domain is used in the standard numbering plan.
But in this line it is used in the number plan <action application = "set" data = "domain_name = $$ {domain}" />,
and domain_name - <action application = "bridge" data = "user / $ {dialed_extension} @ $ {domain_name}" />
In this example, let's deal with constants and variables. The constant is defined as $$ {constant_name} and will be replaced during the preprocessing of the configuration with a value. That is, in the resulting configuration, we will not see a word about constant_name (or about domain and local_ip_v4).
Variables are set as $ {domain_name}. Their meaning may be different, depending on the circumstances. For example, when you call, there is always a variable destination_number containing the incoming number, or caller_id_number containing the number of the calling party.
Constants are set using the <X-PRE-PROCESS cmd = "set" data = "domain = my.malenky.no.ochen.gordy.domen.rf" /> construction, variables are set by the system or you can set them through the numbering application " set ”, example: <action application =" set "data =" domain_name = $$ {domain} "/>. After preprocessing, it takes the form <action application = "set" data = "domain_name = my.malenky.no.ochen.gordy.domen.rf" />.
Responsible for SIP support is mod_sofia, based on the Sofia-SIP library from Nokia. The list of supported capabilities from the relevant RFCs is very close to 100%. These are TCP transport, TLS, SIMPLE and many more.
The first thing that is needed for mod_sofia to work is a profile declaration (conf / sip_profiles / {internal, external} .xml). A profile can be viewed as a virtual server from the world of HTTP servers (SIP generally has many analogies with HTTP). Each profile defines an address / port pair, context in which incoming calls will be processed, registration rules, domain, restrictions, whether authorization is necessary.
For example, the standard internal profile serves to serve internal subscribers. Through this profile, clients of our installation are registered, use voice mail, call each other, arrange conferences, and generally conduct active business life with bureaucratic inclusions.
The external profile is used to communicate with the outside world. In its settings, a standard context is set from the public numbering plan, in which all these possibilities are not available. It mainly serves for routing incoming calls to an internal context for certain numbers. For example, incoming calls to 78-14-90 transfer to extension number 1009.
There is also the concept of gateways. View the contents of the conf / sip_profiles / external / example.xml file. Here is an example gateway configuration (commented out). Gateways are designed for use with VoIP providers that require registration on their servers. If the SIP host does not require registration, then calls through it can be arranged through the number plan without using the configuration entity “gateway”. But for beauty, you can set the same gateway with the parameter <param name = "register" value = "false" />
In the next series, the analysis of the room plan.
Installation, start
The installation of FreeSWITCH is nothing special, the msi package for Windows, the sources for all other platforms. Assembly in the standard sequence. For fans of package installation options, it is possible to build deb packages through at least standard debian / rules binary.
')
So, the first thing I have to tell you is that the FS is already set up after installation, it works and is ready, if not for use, then for tests.
The IP address of the host is selected as the domain, there are users with numbers from 1000 to 1019, voice mail is functioning (dial your number when you are registered to listen), three types of conferences (8kHz - 30xx, 16kHz - 31xx, 32kHz - 32xx), and Many examples to demonstrate the possibilities.
And all this is quite possible to immediately begin to use to its fullest, but in any case, the scheme will have to be redone by itself. The main thing that I will tell you is that the demo numbering plan needs to be studied, studied and understood each item - you can find examples of using the newest features in it, and indeed most of the features are there.
Now let's deal with the configuration. The main directory is conf, it contains freeswitch.xml — the root file from which the configuration will be obtained after preprocessing, vars.xml — the file which contains many settings. From this point on in more detail.
Variables
For example, the string <X-PRE-PROCESS cmd = "set" data = "domain = $$ {local_ip_v4}" />. It is in this standard line from vars.xml that the name of our domain is used in the standard numbering plan.
But in this line it is used in the number plan <action application = "set" data = "domain_name = $$ {domain}" />,
and domain_name - <action application = "bridge" data = "user / $ {dialed_extension} @ $ {domain_name}" />
In this example, let's deal with constants and variables. The constant is defined as $$ {constant_name} and will be replaced during the preprocessing of the configuration with a value. That is, in the resulting configuration, we will not see a word about constant_name (or about domain and local_ip_v4).
Variables are set as $ {domain_name}. Their meaning may be different, depending on the circumstances. For example, when you call, there is always a variable destination_number containing the incoming number, or caller_id_number containing the number of the calling party.
Constants are set using the <X-PRE-PROCESS cmd = "set" data = "domain = my.malenky.no.ochen.gordy.domen.rf" /> construction, variables are set by the system or you can set them through the numbering application " set ”, example: <action application =" set "data =" domain_name = $$ {domain} "/>. After preprocessing, it takes the form <action application = "set" data = "domain_name = my.malenky.no.ochen.gordy.domen.rf" />.
Sip profiles
Responsible for SIP support is mod_sofia, based on the Sofia-SIP library from Nokia. The list of supported capabilities from the relevant RFCs is very close to 100%. These are TCP transport, TLS, SIMPLE and many more.
The first thing that is needed for mod_sofia to work is a profile declaration (conf / sip_profiles / {internal, external} .xml). A profile can be viewed as a virtual server from the world of HTTP servers (SIP generally has many analogies with HTTP). Each profile defines an address / port pair, context in which incoming calls will be processed, registration rules, domain, restrictions, whether authorization is necessary.
For example, the standard internal profile serves to serve internal subscribers. Through this profile, clients of our installation are registered, use voice mail, call each other, arrange conferences, and generally conduct active business life with bureaucratic inclusions.
The external profile is used to communicate with the outside world. In its settings, a standard context is set from the public numbering plan, in which all these possibilities are not available. It mainly serves for routing incoming calls to an internal context for certain numbers. For example, incoming calls to 78-14-90 transfer to extension number 1009.
There is also the concept of gateways. View the contents of the conf / sip_profiles / external / example.xml file. Here is an example gateway configuration (commented out). Gateways are designed for use with VoIP providers that require registration on their servers. If the SIP host does not require registration, then calls through it can be arranged through the number plan without using the configuration entity “gateway”. But for beauty, you can set the same gateway with the parameter <param name = "register" value = "false" />
In the next series, the analysis of the room plan.
Source: https://habr.com/ru/post/50140/
All Articles