search

kyren / webrtc-unreliable

Just enough hacks to get unreliable unordered WebRTC data channels between a browser and a server
Other
394 stars 29 forks source link

Does it support TURN/relay candidates? #28

Closed ris-work closed 7 months ago

ris-work commented 8 months ago

Does it support TURN/relay candidates or is it only STUN?

kyren commented 7 months ago

It's not really what it's designed for, since this is an abuse of peer to peer protocols to do something that is specifically not meant to be peer to peer. You're meant to run this on a server that can accept incoming UDP connections.

However... I think it might work? I'm honestly not sure because I'm not familiar enough with TURN, but I don't think the connected-to peer actually needs to understand TURN, right? It just looks like to the peer that the connection is coming from the TURN relay?

I wish I could answer more definitively, I'm not sure how the peer connection looks when the other peer is going through a TURN relay, in any case this crate doesn't contain anything specific to support it.

Please feel free to educate me here, I'm not actually an expert at all of this stuff, this crate is sort of a big ol' hack that somehow works.

ris-work commented 7 months ago

It's not really what it's designed for, since this is an abuse of peer to peer protocols to do something that is specifically not meant to be peer to peer. You're meant to run this on a server that can accept incoming UDP connections.

However... I think it might work? I'm honestly not sure because I'm not familiar enough with TURN, but I don't think the connected-to peer actually needs to understand TURN, right? It just looks like to the peer that the connection is coming from the TURN relay?

I wish I could answer more definitively, I'm not sure how the peer connection looks when the other peer is going through a TURN relay, in any case this crate doesn't contain anything specific to support it.

Please feel free to educate me here, I'm not actually an expert at all of this stuff, this crate is sort of a big ol' hack that somehow works.

I thought it supports P2P. It is understandable, ICE can be very complicated on its own (STUN, TURN) along with host which are supposed to be different and the best among the other candidates. Moreover, on top of these, all of these options can also have a tcptype for them in case none of them can actually do UDP. Moreover, straight old SCTP is not supported that we have to tunnel it through UDP (which is something already done I think). I think I will stick to webrtc-rs then, it does not do TCP ICE transport yet, but hopefully will. I was considering alternative options because it did not work for my usecase; messages were only working in one direction. After questioning my professional competence and my decision to do WebRTC, I found that it is a problem in that particular machine, all the others worked better than expected.

Although I have experience working as a Telco Engineer with experience in SIP, I am far from being an expert on WebRTC and I still have no idea whether the open ICE relay and relay tcptype candidates behaves the same as if they are the host or srflx from the other end. Thank you for taking the time to respond, I am closing this issue.