You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm doing research for a project and figured webrtc between server to server would be an interesting use case, or client to server mixing the audio of multiple users into a single connection per client. However running it in a system where you only wanted to open up a few ports, for example kubernetes instead of all 60,000+ ports.
Then in the past this was mentioned for this project too, but looked like settled on defining a range of port, not just running multiple connections over a single port. #354
Seems like the other idea for a workaround could be running a TURN server though, but seems to defeat the idea of servers going point to point... and then you could mix and match, some services could run outside of the firewall while some run outside of the firewall but still be able to connect.
The text was updated successfully, but these errors were encountered:
Hi @keverw, probably this is more feasible in a project like pion/webrtc or rawrtc/rawrtc. node-webrtc is just bindings over the webrtc.org implementation. Anything not implemented there won't be implemented here. You could check the webrtc.org bug tracker for feature requests, though.
I'm doing research for a project and figured webrtc between server to server would be an interesting use case, or client to server mixing the audio of multiple users into a single connection per client. However running it in a system where you only wanted to open up a few ports, for example kubernetes instead of all 60,000+ ports.
There's a project in Go discussing this too pion/webrtc#639
Then in the past this was mentioned for this project too, but looked like settled on defining a range of port, not just running multiple connections over a single port. #354
Seems like the other idea for a workaround could be running a TURN server though, but seems to defeat the idea of servers going point to point... and then you could mix and match, some services could run outside of the firewall while some run outside of the firewall but still be able to connect.
The text was updated successfully, but these errors were encountered: