I am currently exploring the utilization of the simple-peer library to create browser-to-browser WebRTC connections through data channels. My understanding, although it may be flawed, is that for two browsers to establish a connection via WebRTC, they need to exchange SDP data and undergo NAT traversal. This process typically involves implementing a STUN server.
Within the simple-peer library documentation, it is mentioned that while simple-peer itself does not include a signaling protocol, it does offer a way to input STUN/ICE servers. The following are excerpts from their mesh example showcasing three HTML files:
peer1.html
<!DOCTYPE html>
<html lang="en">
<!-- Rest of peer1.html code goes here -->
peer2.html
<!DOCTYPE html>
<html lang="en">
<!-- Rest of peer2.html code goes here -->
peer3.html
<!DOCTYPE html>
<html lang="en">
<!-- Rest of peer3.html code goes here -->
In the examples above, I have included references to STUN servers. Do STUNs adequately facilitate the required signaling data exchange? Interestingly, in discussions within their issue tracker, mention is made of using websockets for exchanging such information. Does this imply that STUN's role is solely limited to gathering SDP details, with websockets being necessary for subsequent data exchange between peers? Is the final goal to reduce reliance on central server communications swiftly in favor of direct browser-to-browser data channels?
I initially believed STUN could handle all aspects of these exchanges. Planning to minimize dependence on centralized servers highlights the importance of establishing efficient browser-to-browser communication channels sooner rather than later.
An ideal response would address these queries and potentially enhance the provided example.