How to properly tune network for Turn Server in a WebRTC application? - webrtc

I'm working on a WebRTC solution for audio/picture comunication and I'm a bit concerned about the lack of bandwidth control when two Peers in LAN are communicating.
Basically I want to be able to prioritize and pre-allocate bandwidth on my switch for WebRTC calls. But I couldn't see a proper way of filtering the packets when they are in a P2P call.
Also, I don't want to decode the packet to do that, because of the possible delay caused by this operation.
I hope you guys can show me a proper way or just tell me if my teorical solution could work.
I'm not 100% sure about the idea I'm planning to test, because I don't know how TURN server works internally.
But here is the idea:
And what I dont know is: Is it possible to make 2 turn servers know each other? Would they work like a 2 layer proxy between callers? If yes, could you please show me what I have to do to make it work?

Just install a internal proxy server to the external turn server and prioritize the proxy on your lan.
(answering my own question after realizing the solution was easier than I thought)

Related

Does TURN Server (WebRTC) eliminate redundant uploads (like SFU)?

The problem with p2p apps is the amount of Uploads, since most connections are asymmetrical (weak upload, strong upload).
If you're connected to 10 Peers you have to upload your own video stream 10 times, which quickly falls apart.
SFU (selecting forwarding units) solve this by routing your single upload to all peers.
Does a TURN server do the same? Technically it could, since it's already acting as a relay, but my fear is that it tries to emulate the underlying p2p protocol to closely and hence Uploads are still redundant?
No. TURN servers do not decrypt, SFUs need to do that (and a couple of things that require more logic). They're different components, solving different problems.
No, by default TURN server doesn't do it.
You can take some more complicated webrtc servers like flussonic for example (maybe wowza) and get star topology with them.

WebRTC - Video conferencing with only one emitter

I am new to WebRTC technology.
I want to create a video chat / video conferencing with a transmitter and many followers (more 1000).
Example:
I read a lot of documentations :
https://medium.com/linagora-engineering/scalability-in-video-conferencing-part-1-276f52b4acac
https://webrtcglossary.com/sfu/
But I still don't know what is the best solution (in my case) between Selective Forwarding Unit (SFU) and Multiploint Control Unit (MCU).
Can you help me to understand?
I think the best way is MCU but I am not sure.
Second question:
Can you suggest some sources and links that can help me to set up such an architecture. Currently my project works perfectly in Peer To Peer (Mesh) but it is not the right solution. I have absolutely no idea how to set this up.
Thank you so much
It is possible to implement this using an SFU. The more peers are connected, the more you would need processing power to handle those new peers. This could be done by using more threads and/or forwarding requests to another machine.
With mediasoup it is possible have control over this. With this tool you have routers where peers can connect to to get the stream. A router works on a worker which has a limited amount of receiving peers (depending on cpu capacity). Now to allow more peers you can forward the stream to other routers which can expand the total capacity.
useful links:
https://mediasoup.org/documentation/v3/scalability/#one-to-many-broadcasting
https://mediasoup.org/documentation/v3/mediasoup/design/#architecture
https://mediasoup.discourse.group/t/scalability-in-mediasoup-example/793/2?u=dirvann

TURN servers: always or never needed for a given network, or needed unpredictably?

I am currently just using a STUN server and am wondering whether TURN is necessary for an MVP. The number of users accessing the website from a workplace with super secure firewalls should be near-zero.
Let's say 4 people are testing WebRTC connection reliability. Sometimes they all successfully connect and can see/hear one another, but other times they cannot see/hear someone and refresh the page to try again.
Does the fact that they can sometimes all see/hear each other rule out whether a TURN server would make a difference?
In other words, is it possible for a STUN server to identify my IP so I can connect one second, but fail if I try again a few seconds later? Or is it just network-based, so if I a STUN doesn't work for me on my network now, it 100% will not work in 5 minutes either?
If the latter (and a TURN is either always or never needed for a given network), I guess that tells me the problem in my code is elsewhere...

How signaling in WebRTC works in following scenario?

I read about this online and I come to know that signaling is used for initiation of the communication, But I am very confused about how would I get the ip:port combination for the other peer.
I thought of three scenarios.
On the same network (LAN)
On the internet(but not behind a
proxy/NAT)
On the internet but behind a proxy/NAT
For 1. I get that we can get the ip:port from the signaling process it self(if I am not wrong)
For 2. and 3. How would we get the IP:PORT, how would STUN/TURN servers and ICE will play their role in all these cases? I know for what reason they are used for but can't figure out how each of them will fit in these scenarios.
Update: The question that is posted in comments is the one which compliments what I assumed that it should work in this way, what I don't know is how TURN would do the update, would it be establishing the communication using SDP? like it did for STUN? Is it absolutely necessary for TURN to work we should deploy it on cloud?

WiFi communication to embedded display

I'm trying to create an embedded outdoor display of bus arrival times at my university. I'd like the device to utilize my school's secured WiFi network to show arrival time updates determined from a server script I have running.
I was hoping to get some advice on the high-level operation of this thing -- would it be better for the display board to poll a hosted database via the WiFi network or should I have a script try to communicate with the board directly over 802.11? (Push or Pull?)
I was planning to use a Wifly or WIZnet ethernet board in combination with a wireless access hub. Mostly inspired by this project: http://www.circuitcellar.com/Wiznet/winners/001166.html Would anyone recommend something else over one of the WIZnet boards? I saw SPI/UART options and thought these boards could work with an AVR platform.
And out of curiosity -- if you were to 'cold start' this device (ie, request a bus arrival time by pushing the display's on button) you might expect it to take 10-20 seconds to get assigned an IP and successfully connect to the database, does that sound right?
I'd go pull. In fact, I'd have outdoor display make http or https requests of the server. That way the server could tell it how long to show a given set of data before polling for a new one using standard http page expiration.
I think pull would make it easier to have multiple displays, and to test your server as well. I've also got a gut feeling that this would make your display more secure. Someone would have to hack your server to hijack your display.
There's a very cool looking Arduino-targetted product called the WiShield. Seems super easy to use and he provides some source code. It uses SPI for host communication. If you're not interested in going the Arduino route, I'm sure the source code wouldn't be too hard to port to something like avr-gcc. Check it out, might save you some time and headaches for $55. Worth checking out anyway.