Suppose, we have a media server S deployed. We have a client C who is behind a symmetric NAT. The direct WebRTC media streaming is not possible due to symmetric NAT. So we want to deploy a TURN server T, which would relay all media between S and C.
Now, it seems that developers sometime deploy T near S for simplicity. But does it help to stream media between C and S? "Near" means "in the same network", so S and T are behind the same NAT if there is some. Since, they are behind the same NAT, it doesn't seem to improve connectivity: chances to stream WebRTC traffic between S and C are the same as between T and C.
Is this reasoning correct or am I missing something? In my current understanding, TURN servers act like a proxy with better connectivity with respect to C. So they should be placed in another network to make any effect.
C -> T can do a few things that C -> S can't do
DTLS and TLS transport, ICE only allows UDP and TCP. Some gateways only allow TLS on 443
Single port, you can do all traffic on one well know port. Gateway may only allow :443
S may not support ICE-TCP. Some SFUs do support it though!
Related
I have been reading a bit about WebRTC, and I'm not getting why we need a Turn Server if only 1 peer is using Symmetric NAT, and the other is using neither Symmetric nor Port Restricted NAT, so let’s say A is using Full Cone NAT, B is using Symmetric NAT:
STUN SERVER will send the correct IP address of B to A, and the correct IP + Port address of A to B.
A tries to connect to B (now A will be able to accept messages from B since it’s in the Dest Address Column).
B tries to connect to A, which will allow requests from A going to B (ofc A needs to update the port to the one received from B instead of the Sdp).
am I missing something, or is this correct (and implemented), or is this too complicated to be implemented?
And if this is correct, then theoretically, if I’m peer A and I'm using Full Cone NAT, any peer B can connect to me (as long as I send the connection request first), without needing a TURN server.
Thanks
If the symmetric NAT environment only changes the port, you would be correct with regarding connectivity to Full Cone NAT. The hole punching step would work.
But many enterprise and mobile environments have complex routing schemes and crazy network environments that are different from a legacy home network router. These environments aren't just a little router box that hooks up to a cable modem. It's a complex array of routers and load balancers using a bank of IP addresses. And each outbound connection might get an IP address different from a previous connection. So it's technically "symmetric NAT".
And so after a node within this environment obtains an external IP/port pair from a STUN server, subsequent sends to a peer address might change both both the port and the IP address as well.
As such, the NATs see completely different IP addresses than expected when the UDP packets arrive during the hole punching step. Hence, a relay address (TURN) is needed here.
This question is a little easier if you think in terms of Mapping/Filtering. The other NAT terms don't do a good job of describing how things actually work. My answer comes from RFC 4787 and WebRTC for the Curious: Connecting
Mapping is when your NAT allocates a IP/Port for an outbound packet. A remote peer can the send traffic to this mapping. Filtering are the rules around who can use these mappings.
Filtering and Mappings can then be address dependent and independent. If a mapping is address dependent it means a new mapping is created for each time you contact a new IP/Port. If a mapping is address independent it means it is re-used no matter where you send traffic. These same rules apply to filtering.
If one peer is address + filtering independent I don't believe a TURN server would provide a benefit.
If you want TCP connectivity deploying a TURN server is a good idea. Some WebRTC servers support TCP, but I don't believe any browsers generate passive TCP candidates.
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 building this video teaching site and did some research and got a good understanding but except for this thing. So when a user want's to connect to another user, P2P, I need signaling server to get their public IP to get them connected. Now STUN is doing that job and TURN will relay the media if the peers cannot connect. Now if I write signaling server with WebSocket to communicate the SDP messages and have ICE working, do I need coTURN installed? What will be the job of the job of them particularly?
Where exactly I am confused is the work of my simply written WebSocket Signaling server (from what I saw in different tutorials) and the work of the coTURN server I'll install. And how to connect them with the media server I'll install.
A second question, is there a way to use P2P when there is only two/three participants and get the media servers involved is there is more than that so that I don't use up the participant's bandwidth too much?
The signaling server is required to exchange messages between peers (SDP packets) until they have established a P2P connection.
A STUN server is there to help a peer discover information about its public IP and to open up firewall ports. The main problem this is solving is that a lot of devices are behind NAT routers within small private networks; NAT basically allows outgoing requests and their response, but blocks any other "unsolicited" incoming requests. You therefore have a Catch-22 scenario when both peers are behind a NAT router and could make an outgoing request, but have nowhere to send it to since the opposite peer doesn't expose anything to make a request to. STUN servers act as a temporary middleman to make requests to, which opens a port on the NAT device to allow the response to come back, which means there's now a known open port the other peer can use. It's a form of hole-punching.
A TURN server is a relay in a publicly accessible location, in case a P2P connection is impossible. There are still cases where hole-punching is unsuccessful, e.g. due to more restrictive firewalls. In those cases the two peers simply cannot talk 1-on-1 directly, and all their traffic is relayed through a TURN server. That's a 3rd party server that both peers can connect to unrestrictedly and that simply forwards data from one peer to the other. One popular implementation of a TURN server is coturn.
Yes, basically all those functions could be fulfilled by a single server, but they’re deliberately separated. The WebRTC specification has absolutely nothing to say about signaling servers, since the signaling mechanism is very unique to each application and could take many different forms. TURN is very bandwidth intensive and must usually be delegated to a larger server farm if you’re hoping to scale at all, so is impractical to mix in with any of the other two functions. So you end up with three separate components.
Regarding multi-peer connections: yes, you can set up a P2P group chat just fine. However, each peer will need to be connected to every other peer, so the number of connections and bandwidth per peer increases with each new peer. That’s probably going to work okay for 3 or 4 peers, but beyond that you may start to run into bandwidth and CPU limits of individual peers, especially if you’re doing decent quality video streaming.
I am beginner level.
I try to broadcast data to the browsers in local area ( Same router by sending . . . 255 ).
I should implement the real time streaming service to the local level browsers.
But it will occur high traffic when the client browsers is increased.
To broadcast data, it seems to need UDP protocol.
But web browser base on TCP.
So i investigated the webRTC that is based on UDP.
But i don't really know how to use this.
Is it possible to broadcast the data to the web browser like chrome in local area ?
If not, why it is impossible to implement ? just for hazard of DDOS ? How can i solve this high traffic problem ?
( It really occur high traffic when each clients respond to every data from server (TCP) or the server send same data to the every client amount to number of clients (not broadcasting).
I just want to implement that the server just send one broadcasting datagram packet to the local area and each clients in local level receive same one data from the server but not respond to that. )
From a web app (not a modified web browser itself), you cannot create nor manipulate raw (UDP/TCP) sockets.The sandboxing and other mechanisms won't let you.
with webRTC, you will need to make an handshake, and use ICE.
=> You cannot push to a peer knowing only his IP/port
=> You have to have the receiver accept and acknowledge the transfer
you might have more change with WebSockets, but that requires additional mechanisms as well and not all parties will be able to support web socket (or accept the upgrade from http to WS).
For illustration purpose, you can see the work of Jess on a web-based bit torrent. He has exactly the same problems. https://github.com/feross/webtorrent
I'm curious why is it more pervasive. Does it has a better API?
I remember long ago when i first learned about NAT (i used it for sharing a dialup 14.4kbps modem), i thought that someday every home would have a router with NAT included, but it would "obviously" need also a SOCKS process to be able to open listening ports. When broadband started appearing, it was nice to see NAT as a common feature, and I supposed that SOCKS would be an extra, and slowly become more and more common... but nothing! i had to manually forward ports. then appeared that uPNP, but very few 'serious' applications support it, mostly P2P sharing, games, and some IM.
I still haven't seen any home router to include SOCKS (apart from Linux-based firmware upgrades, of course). does anybody know why??
edit:
as Vartec noted, UPnP is a zeroconf and service discovery, not proxy service. now i know that what i'm referring to is IGD protocol, the NAT traversal service present in home routers, and discovered via UPnP. so, my question would more properly be "Why IGD/UPnP instead of SOCKS?"
SOCKS has limitations compared to UPnP. Generally SOCKS requires configuration on each client and isn't transparent to applications (system-wide socket SOCKSification isn't installed/enabled by default on Windows), while NAT even without UPnP mostly works transparently and without any additional client configuration for outgoing TCP sockets and outgoing UDP.
NAT with UPnP also supports server TCP sockets better than SOCKS: SOCKS can only accept a single connection with its BIND request, which is okay for receiving a single TCP connection in a protocol like FTP, but useless for running a server that needs to accept many connections from many clients. SOCKS 4 also had a 2 minute timeout on the BIND request, but a server generally cannot know when the next client will try to connect.
Low-level TCP settings (eg. TCP Nagle, traffic class) also don't work across the SOCKS proxy, but they work through a NAT.
As far as I know, UPnP is zeroconf discovery type of protocol for devices in local networks, while SOCKS is tunnel-proxy server. They are completely different, actually I don't see anything, that they would have in common.
these are two different things, socks is a protocol that allows you to route tcp and udp (socks v5) through a proxy server and it's for outgoing connections, routers dont have anything to do with this (except they are acting as a proxy too)
the IGD of upnp is an 'api' that allows you to tell your router that you want to open a port and foward it to a computer, this is for incoming connections.. my linksys came with upnp enabled by default and one app i know to use this is msn messenger (maybe only for file transfers)