turn-rs
turn-rs copied to clipboard
mycrl
Unstable connection only when 1 peer uses a reflexive candidate
Description
I have a simple 1:1 connection. The connection is stable when both peers are configured with forced relay. But, the connection struggles to connect or stabilize if one of the peers is allowed to use reflexive candidates.
The connection keeps disconnecting every ~30 seconds, so I don't think it's related to the allocation lifetime (default to 600 seconds).
Wireshark data
https://drive.google.com/drive/folders/1PCFO4VHQjX4x7ymFzmlq_yOtZCCmOrNh?usp=sharing
- both-relay: force relay for both peers. This connection is good.
- one-relay: only 1 peer is configured with force relay. This connection is bad.
- pion-one-relay: only 1 peer is configured with force relay, but with a Pion TURN server. This connection is good.
I've been looking into the codebase and Wireshark, unfortunately I still haven't found anything definitive yet. One thing I found different in "one-relay" from the rest is turn-rs returned PeerAddressFamilyMismatch (https://github.com/mycrl/turn-rs/blob/main/src/turn/operations/create_permission.rs#L91). I'm not sure if this is relevant to our past discussion, https://github.com/mycrl/turn-rs/blob/main/src/turn/operations/create_permission.rs#L91.
Because a single peer forcing forwarding is the same as all communicating with that peer needing to go through forwarding communication.
This problem has existed for a long time, this is an opportunity, I will try to solve it, it is related to the place you mentioned, it is mandatory for turn-rs internal routing, I will try to remove this restriction, but it will require some changes to the internal routing implementation.
@mycrl that makes sense. Since the reflexive candidate peer will appear with a reflexive IP (public in most cases), turn-rs doesn't have the mapping to route the traffic. Thanks for confirming, and the help!
Forgot to mention about the peers' information in my original description. Both peers ran on Chrome 134.0.6998.117.
Allowing clients to bind to arbitrary addresses would enable clients to send data to any address, which is a poor implementation. Therefore, it has been decided not to support this feature.