Engine has built in TURN server so you should be able to run without external STUN

You can read more here https://link.medium.com/CtZceqqpczb

TY, was my understanding correct:
- Each Membrane host needs to be publicly routable for TCP/UDP TURN to work (so the port ranges need to be open and each instance/task has to have a public IP)
- But the client can be behind NAT

We are focused on providing server side of the WebRTC

This means that you won't be able to connect two Membrane's WebRTC Endpoints together, at least we don't support this

Which is a shame. The long term goal is to have the full ICE implementation and allow to setup P2P WebRTC connection using Membrane

Hmm, I think 2 Membranes talking with each other using WebRTC would be an interesting exercise but you have to choose your battles no? So it is understandable, priorities etc

https://github.com/evadne/emporium#unable-to-establish-webrtc-connections updated section accordingly

If I don’t do that, some weird stuff happens in local testing in dev env

I think we should rename those variables in Membrane to IP and LISTEN_IP. I believe they are more meaningful

SFU_SERVER_TURN_LISTEN_IP
SFU_SERVER_ICE_CANDIDATE_IP
Would be what I would do… thoughts?!

It depends on how much we want to expose WebRTC terminology to the end user. In case of Jellyfish, I would hide WebRTC terms not to overhelm people with questions like what is TURN, what is ICE etc. Instead, just think about Jellyfish as any other server

Hmm a leaky abstraction is at least clear when deploying and troubleshooting

Too much packaging can be a hindrance. I’d call a spade a spade in that regard. But of course it is up to you to decide

External STUN

evxi

14 responses

Join out Discord Community