Maybe not an issue, but in compare to other submissions very high CPU usage

This is not a good idea for encoding and writing data to an ogg file inside a blocking callback in a single thread - avcodec_encode_audio2 and av_interleaved_write_frame can take a lot of time, especially in the case of variable data rates .
The receive cycle is locked until the page is written - so it increases the temporal latency and you loose some data. You must exit this handler as soon as it possible to not affect receiving process - save data to the buffer(pipe) which is being processed by asynchronous task.

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

error connecting with params:
caller> tag_hex = 'ba7201826967456c4c090d70a4ae365b'
caller> encryption_key_hex = '2297537d8196e1c9008fff319eeaa2d461be76fa591b2b66bb6318efef53abc801ef3d82d16c51ae29c0ba8760268551c86f8f189de7f6deae54ce6ca06c8d648cf7fa....redacted
caller> sound_in = '/home/user/voip/samples/file.ogg'
caller> sound_out = 'out.ogg'
caller> config = '/home/user/voip/tests/config.json'
caller> role = 'caller'

Same for callee. Tcpdump shows traffic both to and from reflector.
Is libtgvoip linked statically? Any way to enable libtgvoip debug output?

The ogg file was sample15_4a30a6c03e108b963d0afe692558e3ec.ogg from provided samples, both ways. Tried other files as well.

Here is the config:
https://pastebin.com/raw/29fQSfGF

VPN is not used, because the relector is on the same network, so blockings etc can't affect.

The submitted tgvoiprate app got a score of 1228 which means it is less precise than the solution that always returned 3.0 as the result. Unfortunately, this is not good enough to compete for the prize.