Telephony providers

Providers - service companies providing access to external networks. Internet, PSTN, etc. To access the PSTN, you must have a communications services agreement with one of these companies. Connection by providers is provided via various channels and protocols, e.g. E1 streams, analog lines, SIP, H.323. The platform works only with SIP protocol. If the provider can provide a SIP connection point, the platform connects directly to the provider. If not, intermediate nodes - gateways - are required. For example, from E1 to SIP.

Let’s assume that the rest of the domain is already configured and users can call each other.

In the domain, you need to configure provider account: link description of all properties. Customization can be done:

In the minimum mode, you need to set up:

We’ll look at the remaining fields as we go along below.

If a point-to-point connection is made, an explicit port for the client connection point can be set by the provider. This port must be configured in the configuration in the master domain for the ESG role instance to which account service should be bound. By default, in the configurations created in the configuration wizard, a port is assigned to esg 5080. In case different connections require many different ports - this can be solved either by multiplying esg instances or by using an intermediate gateway in the project that solves this problem.

If a server has an external address on the Internet, it is at risk. If it is possible to connect from arbitrary external addresses to the SIP port of the ESG microservice, it is an open area for attacks. Attacks are performed by external systems (sniffers) searching accounts. They send INVITE requests, substituting various values and authorization data. If the system starts to respond, the sniffer is activated and starts an intensive search of credentials in order to break into the number plan.

Protection against attacks is provided by a boundary filter. Permission checking is done based on border filter rules for incoming external SIP requests. Filter rules can be configured:

Rules can create black and white lists.

On closed networks, you may not configure a border filter, or you may configure blacklists.

In open networks, you should set up a whitelist, i.e. allow requests only from certain addresses and deny all other requests by the last priority rule. The deny mode should be set to 'drop' so that the server does not even respond to the incoming request and does not provoke external sniffers to continue to look for credentials.

If a rule has only a filter in the "address" field, such a request is not parsed and is processed directly on the socket. This is much more efficient than other modes.

Thus, the most productive and efficient way to configure is a whitelist with allow rules on ip addresses and drop mode for all others.

In all other cases of setting filters - the SIP request goes through parsing, and after that other filters are checked and the action specified in the rule is applied.

When an incoming call (INVITE) arrives on the esg microservice port, it performs permission checking (discussed above) and binds to an account.

The account is searched among all provider accounts (across all domains) that are currently served by the instance esg.

When an INVITE request is received, active accounts are enumerated and conditions are checked. Two fields from the query are matched against two fields from the account. The search function takes two fields that are substituted sequentially in 6 steps from different headers up to the first discovery:

1. Search among accounts with registration:

1.1. username and domain are taken from the To header. In the example, these values are "1234567890" and "172.27.103.90".

1.2. username is taken from the To header, and domain is taken from the From header. In the example, the values are "1234567890" and "44.55.66.77".

1.3. username and domain are taken from the Contact header. In the example, these values are "" and "44.55.66.77".

2. Search among accounts without registration (point-to-point):

2.1. username and domain are taken from the Contact header. In the example, these values are "" and "44.55.66.77".

2.2. username is taken empty (""), domain from the Contact field. In the example these values are "" and "44.55.66.77".

2.3. username is taken from the To field, domain is taken from the From field. In the example, these values are "1234567890" and "44.55.66.77".

The search function itself checks the values passed in:

If the account is not found as a result of the above algorithm, the server responds with '404 Not Found' and places a message in the Reason header "EB2B. Unknown account in contact".

In most cases, you don’t have to sort out the ISP connection, you just need to make an account and the calls start going through.

In complicated cases, when incoming calls fail and the system returns the specified message, you need to turn to the logs, find the incoming request there and analyze it. Based on the discussed algorithm, identify the cause of non-standard behavior. As a result, add settings to the account. For example,

If the account is detected, the addresses matched to it are checked against the INVITE packet sender address (domain, proxy server address, domain name resolve results, address masks set in the account). If successful, the call is transferred to the service - creating a second arm towards the microservice b2b.

A common technique for complex customization:

If the provider with registration specifies in the domain field of the To header of an INVITE request the external IP address of the server itself with ESG, and an unambiguous mapping of the provider account is made by username in the To header of incoming INVITE requests, then this address should be included in the list of 'extaddrs' parameters of the ESG microservice in the configuration (except if it is the only server address defined by the STUN request).

It is important to remember that when using the built-in SIP-ALG, white addresses will be spoofed to gray addresses, and account settings should take this into account. In the previous case, the gray address should be entered into the 'extaddrs' list of microservice settings ESG.

To make an outgoing call through an ISP account, it should be routed to an external loop in routing rules of the same domain and specify the ISP account code.

Routing is done by a microservice b2b. Before sending a call to the corresponding esg account, its availability and the availability of the account are checked. If its state is inactive, if the set limit for simultaneous sessions is exceeded - routing goes to the next priority rule.

If there are multiple rules with the same priority, the sequence in which they are traversed is random each time. This can be used to distribute outgoing calls to two or more accounts.

Since the outgoing call comes to esg from inside, from the b2b microservice, the second arm is sent outward to the ISP.

The esg microservice separates two number plans, an internal number plan and an external number plan (PSTN, or external PBX). There is probably a difference between these license plate plans. For example, there are 10-digit numbers on the outside and 4-digit numbers on the inside.

When calling across this boundary, the numbers mostly require modification.

Logs related to the handling of telephony provider accounts are maintained by microservices esg. It is necessary to include in the configuration of the corresponding esg instance the parameter 'log_trn'. For extended logging it is necessary to set the TRACE logging mode in the nodes management section (Master Domain Administrator’s Workstation - System - Nodes) or DEBUG.

Log logs are in the directory specified during installation. The default path is '/opt/ERA_INSTANCE_NAME/log' in the host, and '/var/log/era' in the container. The full path to the esg logs directory might look like this: '/opt/ERA_INSTANCE_NAME/log/esg1@SERVER_ADDR/sip'

In the log 'trn_*.log' you can find all packets (across all ISPs). In the 'erl_*.log' log you can find detailed traces of the registration process.

Activity on all providers is placed in the logs. In debugging mode, it may be convenient to start a separate instance of a microservice with low priority (high value of the 'roleid' parameter in the configuration), bind the account under investigation to it (by setting the RoleId value in the account field) serveridxs).

The esg logic corresponds to the b2bua (back-to-back useragent) mode. That is, each incoming call generates a dialog and a second arm. Esg to the second shoulder always generates a new Call-Id.

esg never broadcasts a REFER to another shoulder, but processes it locally, creating a new fork to the same side from whose shoulder the REFER request came. This ensures that the call is routed to the correct number plan. Correct means matching the number for the call transfer. This also means that the platform without additional modification cannot be configured to forward a call with out internal processing.

Each ISP account can operate in either Reinvite Probe mode, Local Media Processing mode, or both, but necessarily at least one mode.

Reinvite throw mode means that every session change is broadcast through esg to the opposite shoulder without change SDP.

Local media processing mode (field 'media'=true). Then it short-circuits all re-INVITE requests within the dialog, processing them locally by configuring media. This uses a bgmg media gateway located on the same server as the instance esg. This mode can be useful if you need to guarantee that media data is sent from the same address as the signaling SIP traffic to connect to the provider, or, for example, the number of addresses in the provider’s dedicated vlan subnet is narrowly limited and cannot be extended to all servers in the platform cluster. When using local media processing mode, signaling traffic can be terminated on a shoulder (reinvite=false) or broadcast to the opposite shoulder with a change in SDP (reinvite=true).

The default mode is reinvite=true and media=false, suitable for the vast majority of installations.

Instances of esg, as well as other microservices responsible for SIP signaling, raise listeners on all interfaces (0.0.0.0). The ports are specified in the configuration for each individual microservice instance, but the ports specified refer to all interfaces of the corresponding server. This means that the platform without additional modification cannot be fine-tuned to listen for specific ports on specific interfaces.

In template configurations, ports are assigned to the esg role 5080, 5081. On these ports, listeners are raised on all server interfaces where the corresponding esg instance is executing, and UDP signaling protocol packets are sent from these ports.

There are instances where a particular ISP requires a port from a customer 5060. In this regard, port 5060 should be configured for esg. Then it may also be necessary to change the ports for instances as well sg. The only exception is when esg and sg instances are executed on different servers. In descending order of convenience, the following options are recommended: