What is Worker

On the platform Worker is a server which is responsible for voice data processing during the call. It converts data from SIP to Telegram format and vice versa. This task works in real-time and requires a lot computational resources and the efficiency of this affects to the quality of the voice during the call.

Because of high computational complexity, there are unlimited number of Workers is designed in the platform, which allow to scale the system and to distribute the load. In addition, locating Workers in different geographic areas makes better another metric of quality — decreases the latency.

In addition to official Workers, every user of SIP.tg can create their own user Worker.

Benefits of own Worker

By creating your own Worker and connecting it to SIP.tg platform you get the following additional possibilities:

  • choose the equipment according to expected load;
  • locating the Worker in the same data center of you PBX, achieve the minimum latency during the call;
  • ensure full confidentiality of the conversation, because voice streams don't transmitted even to SIP.tg platform;
  • get the access to SIP servers from local and restricted networks outside;
  • ensure an additional confidentiality of SIP accounts (optional);
  • share you computational resources with other users of SIP.tg (optional).
System requirements

The environment of the Worker is based on Docker platform virtualization, basing on Ubuntu 18.04 image. The main image is built for amd64 platform, but images for other platforms are also available. We do not recommend to use the host operating system except Linux (Mac OS, Windows) to avoid a program emulation of the environment. All another software requirements are included to the distributed image of the Worker, on the host is required only Docker CE and Docker Compose.

The server must has external IP address and be accessible from the Internet, or you must have ability to map some port to the external IP address.

According to our performance tests, each call requires about 2.5% of one CPU core of AMD Ryzen 5 1400 and 1 Mb of RAM while using A-law codec.

Worker settings

Certificates obtaining

Encryption certificates allow to establish secure connection between SIP.tg platform and the server where the Worker is run on. In settings of the bot @siptg_bot execute command /workers and push button New.


Choose the section


Push New

As a result bot will sent 2 files: the private key and the certificate, which are required for secure connection. Save them — they will be required to send to the server of the Worker.

Server prepare

Most detailed and actual information is located on the page of the project on GitHub. The sequence of actions includes:

  • updating installed software (optional);
  • installing Docker software;
  • obtaining configuration templates;
  • pushing certificate files from the bot to the server;
  • making changes to configuration files (optional);
  • running the Worker on the server.
Connecting to the Worker

The last step in settings is setting up the connection address through the bot. Push Address button and input the address and the port of the server where the Worker is run on. Next push Turn on button to make an attempt to connect to the Worker's server. If connection parameters are wrong, you will get the message with error and the Worker will be switched off automatically.

Usage rights

One of 2 modes of the Worker can be set up through the bot. The mode affects to the rights of using the Worker by other SIP.tg users:

  • 🔑 Private — the mode which allows to use the Worker by the owner and users who were granted the access;
  • 🌐 Public — the mode which allows to use the Worker by any SIP.tg user.
Users list

On the Worker settings push Users button to enter the list.

Changes to the list affect while 🔑 Private mode is active only. But during changing the mode from 🌐 Public mode, the access to the Worker will be lost for all users who are absent from the list. To save the access rights for some users, it is required to make the list before changing the mode.

To remove the user from the list push the button with appropriate @username or ID of the user and confirm deleting. To enter to adding mode push Add button. Next you have to forward any messages from users you would like to add to the list, to the bot @siptg_bot. For usability, the list of new users will be forming on-the-fly. This mode will be active for 5 minutes, you are free to stop adding users at any time.

Giving the access to the Worker doesn't mean users will use it. The decision of using the Worker for each SIP account makes a user. By default and after revoking the access all SIP accounts which were used a revoking Worker will use one of ✅ Official Workers.

Limitations of user's Workers

Your own Worker can be used in SIP Client and SIP Gateway modes both. But the last one can has SIP accounts of 2 types: with incoming and with otgoing connections. The restriction is SIP accounts with incoming type of connection can be used with Official Workers only. This limitation is due to internal architecture of the platform SIP.tg.

The second limitation is about fault-tolerance. In the case the user's Worker is unavailable, the load will be moved to other Worker of the same owner. If no other Workers the load will not be moved. The load is not moved to Workers of other users (including official ones) due to user's Worker can be configured in other way, which can be a reason of disabling SIP accounts (for example if SIP server restricts connections outside or you set up replacing SIP passwords — see below). In the case Worker is not available more than 30 minutes it becomes disabled, at the same time @siptg_bot sends a notification to the owner and other users who use this Worker for their SIP accounts.

Confidentiality of SIP accounts

The core of SIP subsystem is Yate. The flexibility of Yate allows to change any data about SIP account (for example, passwords) which comes from SIP.tg platform on-the-fly. So, SIP.tg platform can contain fake passwords, but on a connection to SIP server through your Worker a password will be replaced to the correct one. This behaviour achieves by using external module the sample of which is published on GitHub.