Info

Download ZIP (4.3 MB)

Testing and Issues

You can test this entry and submit issues during the testing period of the VoIP Contest, Stage 2. $75,000 contest.

Entries with serious issues will not be able to win the contest, but even minor issues might be important for overall results.

Voting

Comments

WebRTC inside libtgvoip protocol
Because of the source code of libtgvoip is difficult to read, it would be wasting time if I tried to improve it. Instead, I've rewritten libtgvoip with a strong OOP approach and tried to save compatibility with old protocols. Instead of using OPUS codec inside with tuned parameters on-the-fly, I replaced it by WebRTC stream. The task is very ambitious, so not all parts were completed and work well.

The strengths:
- Telegram relay servers are used with the original encryption algorithm;
- possibility to reimplement old GrVP protocol to maintain backward compatibility;
- MediaEngineWebrtc class as a standalone solution of WebRTC Native API;
- very simple build step (which builds WebRTC with required options under the hood);
- strong OOP approach.
Works bad or doesn't work:
- only the last added endpoint is used: endpoint switching is not implemented yet;
- tcp relay is called "obfuscated" and didn't tested at all;
- (fixed!) udp relay is not delivering all packets to the peer (probably I missed some details in implementation);
- (fixed!) init stage of call flow is skipped due to the previous point;
- there is a lot of WebRTC logs in the stderr which are not switching off;
- call statistic is missing.

How to build
(fixed!) Just run `cmake . && make`. It should automatically download and compile all dependencies, including WebRTC! If something goes wrong, let me know.

How to run
Small modification into [tgvoipcall](https://github.com/telegramdesktop/tgvoip-test-suite/blob/master/src/tgvoipcall/main.cpp) is required: delete the line `rtc::LogMessage::SetLogToStderr(false);`. After that use libtgvoip.so as libtgvoip.so.0 for tgvoipcall.
1
To make the solution better, I fixed the following problems of original submission:
- build steps (of downloading and compile all WebRTC dependencies);
- udp relay is not delivering all packets to the peer (probably I missed some details in implementation);
- init stage of call flow is skipped due to the previous point;
- missed README and deb-packages.txt files.

https://www.dropbox.com/s/e8ta2x3bazlyml6/result.zip?dl=1
You have not added any comments yet...
by rating

Issues

Fair Wombat Mar 9, 2020 at 19:25
A promising implementation of an ambitious task.
Compatibility with current relay servers is a plus.
Huge room for improvement in terms of audio quality.

We expect the contestant to take part in round 3. Suggested priorities:
1. Focus on improving audio quality on different connections.
2. Build library for Android (real device I/O etc).
Debian 5.2.9
10
Mindful Pug Jan 30, 2020 at 19:10
I'm really sorry, but I was run out of time to include it into submission 🙁. I added it just now in the comments above.
There are no README and build instructions 
Even more it was builded with wrong dependencies:
$ ldd ./tgvoipcall 
...
libtgvoip.so.0 => not found
libopus.so.0 => not found
...
Mindful Pug Jan 30, 2020 at 19:23
You should build https://github.com/telegramdesktop/tgvoip-test-suite/tree/master/src/tgvoipcall first with commented out the line `rtc::LogMessage::SetLogToStderr(false);`. After that use lobtgvoip.so as libtgvoip.so.0 from the submission with tgvoipcall.

As I said, I published the README above.
"You should build" - I should not, sorry
Fair Wombat Feb 5, 2020 at 11:00
This is not an issue, just a request. If there were any specific network conditions which you used to optimize the initally provided library, you are welcome to share test sequences as well as your results. e.g.:

->loss(12)->rateControl('32kbit')->networkType('3g')
Stable version: 3.0
My submission: 3.3

->loss(3)->rateControl('64kbit')->after(3)->loss(20)->rateControl('8kbit')->after(3)->rateControl('64kbit')->networkType('3g')
Stable version: 3.2
My submission: 3.4

We will re-check your results and may use the sequences you provide to test other submissions.
Debian 5.2.9
Mindful Pug Feb 5, 2020 at 20:22
Your point to obtain network conditions from participants is very well. But it's a lack of my submission because it based on a different approach. Unfortunately, I was running out of time to make comparison tests, but I hope the improvements are measurable.

There are a lot of variables of WebRTC which can be tuned afterward, but initially, default values are used. Those variables are not matched to initially provided library ones "as is".
First of all, do not try to reach me for a private messages.

Then,
https://drive.google.com/open?id=1bO2O5rhPLlU7YESRKjTRArL62vV_4TuR
Look at the 2nd example. tgvoiprate esimates it in 1,24... While Dejavu's confidence is 242 (it's about the same as the original sample).
What could you say?
Mindful Pug Feb 5, 2020 at 23:44
Sorry for the inconvenience, but your issue is not related to this contest submission.
Nobody added any issues yet...