Using Worker Servers

Worker within the SIP.TG platform is the server responsible for processing and converting voice data from SIP format to Telegram format and back.

This is a real-time, computationally intensive task that directly affects call quality.

Due to high computational complexity, the platform provides unlimited number of Worker Servers for system scalability and load balancing. In addition, the placement of Worker servers in different geographical areas improves another indicator of the quality of the connection - reducing the delay in signal transmission.

SIP.TG's Worker server infrastructure is secure, the servers can be scaled quickly if needed, and are located in different geographical areas.

Today our Worker servers operate in data centres in Moscow, Frankfurt, Amsterdam, London, Washington and Minsk.

Servers serving users on paid tariffs are more productive and reliable.

In addition to the official Worker servers, there is also provision for custom Worker servers.

By connecting your own Worker to the SIP.TG platform, you get the following additional features

• choose the equipment yourself on the basis of the expected load;
• by placing the Worker in the data center next to the virtual PBX, to achieve minimal voice delay during a conversation;
• ensure complete confidentiality of the contents of the conversation, as voice streams are not transmitted even to the SIP.TG platform;
• access externally to SIP servers located in local or restricted networks;
• provide additional privacy for SIP accounts (optional);
• share your computing resources with other SIP.TG users (optional).

The Worker runtime environment is based on the virtualization platform Docker based on the Ubuntu 18.04 operating system image. The main image is prepared for the amd64 platform, but images are also available for other platforms.

In order to avoid software emulation of the runtime environment, we do not recommend using an operating system other than Linux as the base operating system (e.g. Mac OS or Windows).

All additional software dependencies are already present in the distributed Worker image and only Docker CE и Docker Compose.

The server must have a dedicated IP address and be accessible from an external network, or you must be able to "forward" one random TCP port to an external IP address.

Based on our performance tests, each call consumes about 2.5% of the resources of one AMD Ryzen 5 1400 processor core and about 1 MB of RAM when using the A-law codec.

Obtain certificates

Encryption certificates allow you to establish a secure connection between the SIP.TG platform and the server where Worker is running. In the settings of the @siptg_bot bot run the command /workers and click New.

The bot will send you 2 files: a private key and a certificate, necessary for a secure connection. Save them, you will need them later to write to the Worker server.

Server preparation

The most detailed and up-to-date information on setting up a server can be found on the page project on GitHub. The procedure includes:

• update the installed software (if necessary);
• installation of the Docker software;
• obtaining configuration file templates;
• save the certificate files from the bot to the server;
• making changes to the configuration files (if necessary);
• running Worker on the server.

Connecting to Worker

The last step in the configuration is to configure the settings for connecting to Worker via the bot, namely specifying the connection address. Click the Address button and enter the external address and port of the server on which Worker is running. Then click the Enable button to attempt to connect to the Worker server. If the connection settings are incorrect, you will receive an error message and Worker will be disabled.

Rights of use

One of 2 modes can be set via the bot, which affects the rights to use the Worker by other SIP.TG users:

• (key) Consumer - a mode in which only its owner and users explicitly granted access can use the Worker;
• (globe) Public - a mode that allows any SIP.TG user to use your Worker.

User list

In Worker edit mode, click on Users to enter user management mode.

Changes made to the user list only take effect when Consumer mode is active. However, when switching from Public mode, access to Worker is lost for all users not on the list. To retain access during a mode change, a list must be generated in advance.

To remove a user from the list, press the button with the appropriate @username or user ID and confirm the removal. To go to the mode of adding users to the list, press Add. Next you need to forward any messages from users you wish to add to the bot @siptg_bot. For convenience, the list of added users will be formed "on the fly". This mode will be active for 5 minutes, adding can be stopped at any moment.

Granting access to Worker does not mean that users will use it. The decision to use the Worker for each SIP account is made by the user. By default, and when user access is revoked, one of the ✅ official Workers is assigned to all SIP accounts using the revoked Worker.

Limitations of the User Worker

The User Worker can be used in both Softphone and Gateway mode. However, the latter can contain SIP accounts of 2 types: with incoming connection and with outgoing connection. The limitation is that SIP accounts with incoming connection type can only be used with Official Worker. This limitation is due to a peculiarity of the inner workings of the SIP.TG platform.

The second limitation is the fault tolerance. If a user Worker is unavailable, the load is transferred to another Worker of the same owner. If this is the only Worker the user has, the load is not transferred. The load is not transferred to the Worker of other users (as well as official ones) because the user Worker may be configured differently, which may cause unreasonable disabling of SIP accounts (e.g. if the SIP server, prohibits connections from outside, or if your Worker changes passwords from SIP accounts - see. below).

If the Worker is unavailable for more than 30 minutes, it is disabled completely, with @siptg_bot sending a notification to both the owner and users who have set up SIP accounts to use the disabled Worker.

SIP account privacy

The core of the SIP subsystem is the IP telephony platform Yate. The flexibility of the platform allows any SIP account data (e.g. passwords) coming from the SIP.TG platform to be changed on the fly. Thus, the SIP.TG platform can contain fake passwords, but when connecting to the SIP server through your Worker, the password will be replaced with the real one. This behavior is achieved by using external module, an example of which presented by on GitHub.