H3S1: A desktop TURN server<Turing>:
The reason STUN is needed is because the clients cannot discover each others’ IP address, but private web implementation, I am sending the other person’s IP address manually. This needs to be accounted for, in my research. The other part of STUN is to determine peer connection restrictions, which could be useful. Q: For peers, in the current paradigm, who are re-routed to TURN, is the IP address still discovered? Or is it the fact that the IP address cannot be discovered, that necessitates TURN?
Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)<2020>: https://datatracker.ietf.org/doc/html/rfc8656
Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal<2018>: https://datatracker.ietf.org/doc/html/rfc8445
SIP: Session Initiation Protocol<2002>: https://datatracker.ietf.org/doc/html/rfc3261
Traversal Using Relays around NAT (TURN) Extension for IPv6<2011>: https://datatracker.ietf.org/doc/html/rfc6156
TURN URI: https://datatracker.ietf.org/doc/html/rfc7065
ICE + WebSockets for Flare first, before also adding WebRTC, but seems like docs most prevalent for linking ICE and WebRTC.
WebRTC API says it’s built on top of other protocols: https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Protocols