The use of the docker is due to the ability to simultaneously launch several calls with different network parameters for each, which can significantly reduce the testing time of many records in different network conditions.
In addition - the tested library is not changed at all - the testing tool does not affect the tested library - the sound is transmitted through virtual audio devices.

The submitted tgvoiprate app got a score of 649 and took the 3rd place in the scoring table, receiving 4⭐️.
The issue #issue9059, which we couldn't fix by ourselves, prevented us from using tgvoipcall in generating the rating dataset. -0.3⭐️
External dependencies: Docker, Python and sudo. -0.15⭐️
While Docker might indeed be useful for collecting the dataset, providing this assistance was outside of the scope of the contest – especially given the significant external dependencies. This could have been done optionally.
External dependency: PESQ (commercial license) -0.25⭐️
Final result is 3.3⭐️

tgvoipcall should be standalone application with a Command-Line interface, not bash script

Your application can not run on fresh Debian buster, only in your Docker image (which is Debian stable based) with your environment. This is a contest condition violation, as I think

It seems that replying here is very limited.. though I'll post this like a new issue.
https://t.me/contest/108
Here you can see that contest task was to write two C++ applications. Nevertheless, this information is missing in full description.

This solution is TL;DR; kind of stuff. Why so many upvotes? It doesn't even conform to the contest contract e.g. becase -i and -o should be the names of files, not devices.

On errorneus call tgvoipcall does not return non zero error code and JSON status string

tgvoiprate should be a standalone C++ application, not just a wrapper around other executables (pesq and ffmpeg).

Can't manage to make tgvoipcall work on Buster. Every time ends with 'not_inited' problem.

{"libtgvoip_version": "2.4.4", "log_type": "call_stats", "network": {"type": "unknown"}, "p2p_type": "none", "packet_stats": {"in": 0, "lost_in": 0, "lost_out": 0, "out": 41}, "pref_relay": "10878166832805", "problems": ["timeout", "not_inited"], "protocol_version": 0, "relay_rtt": 0, "rtt": 0, "tcp_used": false, "udp_avail": false}

Same for callee. Tcpdump shows traffic both to and from reflector.

Does it have proper multithreading support for multiple CPUs?