How STUN, TURN and ICE work (two endpoints interaction process):
We assume a situation where two peers A and B both use WebRTC peer-to-peer two-way media streams (for example, a video chat application).
To connect to B's application, A's application must generate an SDP offer. The SDP offer contains information about the session that A's application wants to establish, including the codec to be used, whether this is an audio or video session, etc. It also contains ICE candidates, and their B application is used to try to connect to the IP and port of A that the A application needs.
In order to build the ICE candidate list, A's application sends a series of requests to the STUN server. The server returns the public IP address and port pair that initiated the request. A's application adds each pair to the ICE candidate list, in other words, it collects ICE candidates. Once A's application has completed the collection of ICE candidates, it can return to SDP.
Next, A's application must pass the SDP to B's application through the signaling channel through which these applications communicate . The WebRTC standard does not specify the transport protocol used for this exchange. It can be executed via HTTPS, secure WebSocket or any other communication protocol.
Now, B's application must generate an SDP Answer. B’s application follows the A step used in the previous step: collect ICE candidates, etc. Then B's application program needs to return this SDP Answer to A's application program through the signaling server.
After A and B exchange SDP, they will perform a series of connection checks. The ICE algorithm in each application obtains the ICE candidates IP/port pair from the list received in the SDP of the other party, and sends a STUN request to it. If another application returns a response, the original application considers the check successful and marks the IP/port pair as a valid ICE candidate.
After completing the connection check for all IP/port pairs, the application negotiates and decides to use one of the remaining valid pairs. After selecting a pair, the media starts to flow between applications. (The effective channel selection strategy is generally host>p2p>releay)
If none of the applications can find an IP/port pair that passes the connectivity check, they will send a STUN request to the TURN server to obtain the media relay address. The relay address is a public IP address and port used to forward data packets received between the application and the application and set the relay address. Then the relay address is added to the candidate list and exchanged through the signaling channel.
PS: In actual implementation, it is used to generate SDP and exchange ICE candidates, which can be executed in parallel. That is, generating SDP does not need to communicate with STUN server. ICE candidate information does not need to be included in the SDP to send. This can increase the speed of establishing a link. There is no need to wait for the ICE candidate collection to complete the signaling communication.