I am developing a tool for a research experiment and struggling with the feeling that I do not know enough about WebRTC and networking to make an informed decision on the approach to use (because I don’t how much I don’t know and don’t want to step into a pitfall or make things overly complicated).
What I Want to Accomplish
- Facilitate a video call via WebRTC between 2 clients.
- Manipulate network properties such as latency, packet loss, or delay on the fly via an administration tool
- Extend this to work over the internet and handle a lot of simultaneous calls for eventual use in crowdsourced research.
- (Best case, but optional) Simulate different network capacities for each client.
Steps Taken / Thought Process
❗ I don’t have a solid enough understanding of networks and protocols to really understand what I’m talking about here, so please correct me if these are not actual problems or if I understood something wrong.
Problem: WebRTC needs a server to facilitate the connection between the clients, but from then on it’s peer-to-peer. That means, simply
throttling the network on the server doesn’t work, since the video
call network packages do not run through it.
I solved this using a cumbersome setup (see image) with a server that spawned two WebRTC clients that were used as call partners for the real clients and exchanged the video and audio streams internally in order to send them to their actual target.
Then I can manipulate the server’s network properties (using tc) and introduce artifacts on both clients because the traffic must go over the server.
I do not like working with what I created here and feel like it is more complicated than it needs to be. Also, it requires a second physical server for WebRTC signalling, since the manipulated network on the call server would make it unreliable.
I read about TURN servers and from what I understand, if I used one of these, all packets would be passing through it as well, without the overhead of spawning additional WebRTC clients on the server. If I kept the webrtc clients in different networks, this could be a solution.
Questions
- Can you identify obvious issues with this setup that might lead to unforeseen problems in the future?
- Could a TURN server solve this more easily with effectively the same results? Is it worth looking into that?
- What are pitfalls to look out for when I want to use this for crowdsourcing and handle lots of connections?