I have developed a p2p video chat using Webrtc. I am aware that STUN or TURN server is required to identify the public IP behind NAT. Currently am using Google's STUN server.
I have the application installed in the server connected to the LAN which will not have internet access, do I need to install the STUN server in my server to make Webrtc video chat work within the LAN?
Peers should be able to connect within a LAN (on the same side of a NAT) without STUN, i.e. using the host candidates. Try it out!
In general, you won't need a STUN server. However, depending on the firewall configuration, you may actually need STUN (and even TURN). For example, at the SFHTML5 WebRTC Hackathon, we were on a corporate guest WiFi network that blocked local UDP and TCP traffic. Making successful calls required a TURN server in this case.
Related
I would like to use WebRTC with HTML and Javascript on the client side and then have a server written in
Javascript or even C on my server side. I will be happy to use either a Linux or a Windows Server.
I don't want to use a remote server. I would like to perform the NAT traversal locally on my own server.
I have WebRTC running peer-to-peer without NAT traversal and it is very effective.
It is possible to have WebRTC running and do the NAT traversal myself on the local machine?
For WebRTC an ICE Agent just needs a 3-Tuple on each side (IP/Port/Protocol).
Your C server just needs to publish an address that is reachable by the WebRTC Agent in the browser. You have a couple different choices.
You can use a STUN server and establish a NAT Mapping
You can run your server on a internet routable address, and don't need to worry about mapping
You can do port forwarding. Your server can be in a NAT, but will be world routable on a range of ports
You can use something like NAT-PMP or PCP
ICE (the protocol that WebRTC uses) doesn't care where the candidates come from. It just works on finding a route that works.
If I am building a WebRTC app and using a Selective Forwarding Unit media server, does this mean that I will have no need for STUN / TURN servers?
From what I understand, STUN servers are used for clients to discover their public IP / port, and TURN servers are used to relay data between clients when they are unable to connect directly to each other via STUN.
My question is, if I deploy my SFU media server with a public address, does this eliminate the need for STUN and TURN servers? Since data will always be relayed through the SFU and the clients / peers will never actually talk to each other directly?
However, I noticed that the installation guide for Kurento (a popular media server with SFU functionality) contains a section about configuring STUN or TURN servers. Why would STUN or TURN servers be necessary?
You should still use a TURN server when running an SFU. To understand diving into ICE a little bit will help. All SFUs work a little differently, but this is true for most.
For each PeerConnection the SFU will listen on a random UDP (and sometimes TCP port)
This IP/Port combination is giving to each peer who then attempts to contact the SFU.
The SFU then checks the incoming packets if they contain a valid hash (determined by upwd). This ensures there is no attacker connecting to this port.
A TURN server works by
Provides a single allocation port that peers can connect to. You can use UDP, DTLS, TCP or TLS. You need a valid username/password.
Once authenticated you send packets via this connection and the TURN server relays them for you.
The TURN server will then listen on a random port so that others can then send stuff back to the Peer.
So a TURN server has a few nice things that an SFU doesn't
You only have to listen on a single public port. If you are communicating with a service not on the internet you can just have your clients only connect to the allocation
You can also make your service available via UDP, DTLS, TCP and TLS. Most ICE implementations only support UDP.
These two factors are really important in government/hospital situations. You have networks that only allow TLS traffic over port 443. So a TURN server is your only solution (you run your allocation on TLS 443)
So you need to design your system to your needs. But IMO you should always run a well configured TURN server in real world environments.
I am working on a WebRtc application to broadcast video to my clients. I use Kurento as the WebRtc media server and use Spring Boot to build my signaling server. There is only media data that flows from my media server to clients but no media data in the opposite direction. So the media server's public address is not needed while clients's public addresses are required. That is I need to find ICE candidates that contains public address for my clients.
I know clients can setup up an extra stun server to achieve this. But since the clients are already talking to my signaling server, is it possible that I just use my signaling server to find ICE candidates for the clients?
A stun server lets the client figure out a UDP port where other clients can connect. This is different from the TCP connection the client uses to connect to your signaling server.
If you client is only talking to your media server, that is not needed. However, you may need a TURN server to allow connections from networks that block UDP (unless your media server supports ICE-TCP)
I wish to understand what generates the ICE candidates in a local webRTC application that does not use a STUN server.
Without a STUN server configured, the only candidates you might get from onicecandidate are host candidates, based on your system's IP address in its local network. The browser running on your system already knows this IP, and does not need ask a STUN server for it.
A STUN server is only needed to learn what IP addresses a system might be contactable on from outside a NAT. A STUN server acts as a mirror that sends back the IP it sees from packets sent through the NAT.
will I need STUN/TRUN-Servers, if the devices running my WebRTC-application are in a corporate VPN, or can I expect it to just work like in LAN?
I am using the PeerJS library and the PeerServerCloud for Signaling.
if both( or all) peers are behind the corporate VPN network, then probably not. In most other cases, you would most definitely need a TURN Server,
also, if your network blocks/ restricts the 443 port to internet, you would need to connect with the TURN server through TCP transport instead of the usual UDP.