Unreliable channels are actually reliable

[CouleeApps]

Due to https://github.com/webrtc-rs/webrtc/issues/371, trying to construct a data channel with RTCDataChannelInit::max_retransmits: Some(0) will actually produce a reliable (though unordered?) channel. After a bit of testing on my own, I found that even under significant packet loss, all packets sent on the unreliable channel still arrive and perfectly in order. I tried playing around with the parameters to RTCDataChannelInit and have not found a configuration yet that actually produces an unreliable channel.

With that being said, I guess the issue in this repo mostly revolves around:

• Is there a workaround to get at least unreliable transfers?
• Is there some other substitute instead?
• Can this be fixed with a PR or patch to webrtc-rs/webrtc?
• Should this repo even advertise unreliable channels if they are in fact, not unreliable?

I'm not sure what you want to do / what is even actionable from this, but it is still a downstream problem in this crate.

---

Reference for things I tried:

• Setting max_retransmits to 1 instead of 0
• Specifying max_packet_life_time as 1 (ms) instead of None
• Both of the above
• Verified that webrtc-rs does try to create a channel of type PartialReliableRexmitUnordered or PartialReliableTimedUnordered based on the provided configs
• Fork with testing code at https://github.com/CouleeApps/matchbox/tree/fce57ea0b885ad61e383ebfe201ff0b20d8e12da

[simbleau]

This seems like a webrtc issue that will solve itself with time. Just needs more attention on the webrtc side. It seems there's 0 urgency on it, because no one is pointing out the issue in a pull request or a minimum reproducible example.

I'm not satisfied relying on or working around it. If you want to do that in your own code, you may.

[simbleau]

Closing because it's not our bug