[ACCEPTED]-Is STUN server absolutely necessary for webrtc when I have a socket.io based signaling server?-stun

The STUN server is NOT the signalling server.

The 26 purpose of the signalling server is to pass 25 information between the peers at the start 24 up of the session(how can they send an offer 23 without knowing who to send to?). This information 22 includes the SDPs that are created on the 21 offers and the answers and also any Ice 20 Candidates that are created by either party.

The 19 reason to have a STUN server is so that 18 the two peers can send the media to each 17 other. The media streams will not hit your 16 signalling server but instead will go straight 15 to the other party(the definition of a peer-to-peer 14 connection), the exception to this would 13 be the case when a TURN server is used.

Media 12 cannot magically go through a NAT or a firewall 11 because the two parties do not have direct 10 access to each other(like they would if 9 they were on the same LAN).

In short STUN 8 server is needed the large majority of the 7 time when the two parties are not on the 6 same network(to get valid connection candidates 5 for peer-to-peer media streaming) and a 4 signalling server is ALWAYS needed(whether they 3 are on different networks or not) so that 2 the negotiation and connection build up 1 can take place. Good explanation of the connection and streaming process

STUN is used to implement the ICE protocol, which 21 tries to find a working network path between 20 the two clients. ICE will also use TURN 19 relay servers (if configured in the RTCPeerConnection) for 18 cases where the two clients (due to NAT/Firewall 17 restrictions) can't make a direct peer-to-peer 16 connection.

STUN servers are used to identify 15 the external address used by the computer 14 on the internet (the outside-the-NAT address) and 13 to attempt to set up a port mapping usable 12 by the peer (if the NAT isn't "symmetric") -- contacting 11 the STUN server will tell you the external 10 IP and port to try to use in ICE. These 9 are the ICE candidates included in the SDP 8 or in the trickle-ICE messages.

For almost-guaranteed 7 connectivity, a server should have TURN 6 servers (preferably supporting UDP and TCP 5 TURN, though UDP is far preferred). Note 4 that unlike STUN, TURN can use appreciable 3 bandwidth, and so can cost money to host. Luckily, most 2 connections succeed without needing to use 1 a TURN server (i.e. they run peer-to-peer)

NAT(Network Address Transformation) is used 14 to translate "Private IP', which is 13 valid only in LAN into "Public IP" which 12 is valid in WAN. The problem is that "Public 11 IP" is only visible from outside, so 10 we need STUN or TURN server to send back 9 "Public IP" to you. This process 8 enables a WebRTC peer to get a publicly 7 accessible address for itself, and then 6 pass that on to another peer via a signaling 5 mechanism

A STUN server is used to get an 4 external network address. TURN servers are 3 used to relay traffic if direct (peer to 2 peer) connection fails. for more you can 1 also refer from below link: https://www.html5rocks.com/en/tutorials/webrtc/infrastructure/#what-is-signaling

In your case, you need STUN. Most clients will 83 be behind NAT, so you need STUN to get the 82 clients public IP. But if both your clients 81 were not behind NAT, then you wouldn't need 80 STUN. More generally, no, a STUN server 79 is not strictly required. I know this because I successfully 78 connected 2 WebRTC peers without a stun 77 server. I used the example code from aiortc, a python 76 WebRTC/ ORTC library where both clients 75 were running locally on my laptop. The signalling 74 channel used my manual copy-pasting. I literally 73 copied the SD (session description) from 72 the one peer to the other. Then, copied 71 the SD from the 2nd peer to the 1st peer 70 once again.

From the ICE RFC (RFC8445), which 69 WebRTC uses

An ICE agent SHOULD gather server-reflexive 68 and relayed candidates. However, use of 67 STUN and TURN servers may be unnecessary in certain networks 66 and use of TURN servers may be expensive, so 65 some deployments may elect not to use them.

It's 64 not clear that STUN is a requirement for 63 ICE, but the above says it may be unnecessary.

However, signalling 62 has nothing to do with it. This question 61 actually stems from not understanding what STUN does, and 60 how STUN interplays with signalling. I would argue the other 3 answers here 59 do not actually answer these 2 concerns.

Pre-requisite: Understand 58 the basic concepts of NAT. STUN is a tool 57 to go around NAT, so you have to understand 56 it.

Signalling: Briefly, in WebRTC you need 55 to implement your own signalling strategy. You 54 can manually type the local session description 53 created by one peer in the other peer, use 52 WebSockets, socket.io, or any other methods 51 (I saw a joke that smoke signals can be used, but how 50 are you going to pass the following session 49 description (aka. SDP message) through a smoke signal...). Again, I 48 copy pasted something very similar to below:

 v=0
 o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
 s=
 c=IN IP4 host.anywhere.com
 t=0 0
 m=audio 49170 RTP/AVP 0
 a=rtpmap:0 PCMU/8000
 m=video 51372 RTP/AVP 31
 a=rtpmap:31 H261/90000
 m=video 53000 RTP/AVP 32
 a=rtpmap:32 MPV/90000

When 47 both peers are not behind NAT, you don't need 46 a STUN server, as the IP addresses located 45 in the session description (the c= field above, known 44 as connection data) generated by each peer would be enough 43 for each peer to send datagrams or packets 42 to each other. In the example above, they've 41 provided the domain name instead of IP address, host.anywhere.com, but 40 this can be resolved to an A record. (Study 39 DNS for more information).

Why don't you 38 need a STUN server in this case? From RFC8445:

There 37 are different types of candidates; some 36 are derived from physical or logical network 35 interfaces, and others are discoverable 34 via STUN and TURN.

If you're not using NAT, the 33 client already knows the IP address which 32 peers can directly address, so the additional 31 ICE candidates that STUN would generate 30 would not be helpful (it would just give 29 you the same IP address you already know 28 about).

But when a client is behind a NAT, the 27 IP they think they won't help a peer contact 26 them. Its like telling you my ip address 25 is 192.168.1.235, it really is, but its my private IP. The 24 NAT might be on the router, and your client 23 may have no way of asking for the public 22 IP. So STUN is a tool for dealing with this. Specifically,

It 21 provides a means for an endpoint to determine 20 the IP address and port allocated by a NAT 19 that corresponds to its private IP address 18 and port.

STUN basically lets the client 17 find out what the IP address. If you were 16 hosting a Call of Duty server from your 15 laptop, and port forwarded a port to your 14 machine in the router settings, you still 13 had to look up your public IP address from 12 a website like https://whatismyipaddress.com/. STUN lets a client do this 11 for itself, without you accessing a browser.

Finally, how does STUN interplay with signalling? The 10 ICE candidates are generated locally and 9 with the help of STUN (to get client public 8 IP addresses when they're behind NAT) and 7 even TURN. Session descriptions are sent 6 to the peer using the signalling channel. If 5 you don't use STUN, you might find that 4 the ICE candidates generated that is tried 3 by ICE all fail, and a connection (other 2 than the signalling channel) does not successfully 1 get created.