The receiver stops receiving data unexpectedly.

[Lighty0410]

Hey everyone! I have a remote srt-live-transmit service i try to get data from to my local machine. However, i cannot.
For some weird reason, the receiver randomly stops working. And the problem is i can't make head nor tail of the issue.
There's around ~50ms ping on average between me and the remote service. I tried different methods to eliminate the issue:

1. Different srt-live-transmit settings.
2. Different SrtSocketBuilder settings.
3. Different server settings/location/hardware (within all the same ~50ms).

What's happening:

1. I start the srt-live-transmit service on the remote machine - srt-live-transmit -loglevel:debug udp://:1234 srt://:12345latency=1000&oheadbw=100
2. Use ffmpeg to push data to it - ffmpeg -re -stream_loop -1 -i stream.ts -c copy -map 0 -f mpegts "udp://127.0.0.1:1234?pkt_size=1316"
3. Run example from here - https://github.com/russelltg/srt-rs/blob/master/srt-tokio/examples/receiver.rs with the appropriate addr/port.
4. The receiver just randomly stops getting packets. However, the connection remains active for quite a while (maybe a minute or two). Furthermore, the connection also remains active on the server side! And after a minute or two, it drops on both sides.

And there a couple of weird stuff is going on:

1. It works fine if the bandwidth is low. Around ~500 kb/sec.
2. The old version available on crates.io also seems to work fine. There's a memory leak, but it works.
3. Original implementation/ffplay srt also works fine.
4. There are no issues if i run the srt-live-transmit locally and connect to it locally.

There's a trace log (i can replace it if needed with the full version, but it's pretty huge) - https://gist.github.com/Lighty0410/a4cdacef1b37599fee85c5888c0dab52

UPD:
Finally, i was able to find the root of the issue. It's the value of this field - AckControlInfo::FullSmall { **buffer_available** } .
After i set it to 1_000 here it solved my problem.
As far as i understand due to the decent bandwidth there's no room for the receiver to store all ACK packets during a certain period of time and it stops receiving new packets unexpectedly causing this weird behavior.