Using Worker Servers

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

This is a real-time task that requires large computing resources and the efficiency of its execution directly affects the quality of the voice during a conversation.

Due to the high computational complexity, the platform provides for an unlimited number of Worker servers for system scalability and load distribution. In addition, placing Worker servers in different geographical areas allows you to improve another indicator of connection quality - reduce the delay in signal transmission.

The infrastructure of SIP.TG Worker servers is reliably protected, the servers are quickly scalable if necessary, and are located in different geographical areas.

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

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

In addition to the official Worker servers, there are also custom Workers.

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

• independently select equipment based on the expected load;
• By placing the Worker in a data center next to a virtual PBX, achieve minimal voice delay during a conversation;
• ensure complete confidentiality of the contents of the conversation, because voice streams are not transmitted even to the SIP.TG platform;
• gain external access to SIP servers located in local or limited networks;
• provide additional confidentiality of SIP accounts (optional);
• share your computing resources with other SIP.TG users (optional).

The Worker runtime environment is built on a virtualization platform Docker based on the Ubuntu 18.04 OS image. The main image is prepared for the amd64 platform, but there are also images for other platforms.

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

All additional software dependencies are already contained in the distributed Worker image; the main OS only needs to have Docker-CE и Docker Compose.

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

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

Obtaining Certificates

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

As a result, the bot will send 2 files: a private key and a certificate, necessary for a secure connection. Save them, they will be needed later to write to the Worker server.

Preparing the server

The most detailed and up-to-date information on setting up the server is located On the page project on GitHub. The procedure includes:

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

Connection to Worker

The last step in the setup is to configure the parameters for connecting to the Worker through 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. Next, click the Enable button to try to connect to the Worker server. If the connection parameters are incorrect, you will receive an error message and the Worker will be disabled.

Rights of use

Through the bot you can set one of 2 modes, which affects the rights to use Worker by other SIP.TG users:

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

Custom Worker Limitations

You can use your Worker in both Softphone and Gateway modes. However, the latter can contain 2 types of SIP accounts: with an incoming connection and with an outgoing connection. The limitation is that SIP accounts with an incoming connection type can only be used with Official Workers. This limitation is due to the internal structure of the SIP.TG platform.

The second limitation is fault tolerance. If a user's 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 Workers of other users (as well as official ones), since the user Worker can be configured differently, which can lead to unjustified disabling of SIP accounts (for example, 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 completely disabled, while @siptg_bot sends a notification to both the owner and users who have configured SIP accounts to use the disabled Worker.

Confidentiality of SIP accounts

The core of the SIP subsystem is the IP telephony platform Yacht. The flexibility of the platform allows you to change on the fly any data about your SIP account (for example, passwords) coming from the SIP.TG platform. Thus, the SIP.TG platform may contain fake passwords, but the moment you connect to the SIP server through your Worker, the password will be replaced with a real one. This behavior is achieved by using external module, an example of which submitted on GitHub.