With this article I will try to explain and simplify how a client and a server can communicate and exchange messages through web sockets, using SDP and ICE protocol. In this example I will try to explain the process of how a client communicates using open standard protocol in order to initiates a P2P connection with a another client or server for streaming, voice and data communication.
1. First the client initiates a connection which connects to a Web Socket server.
The ws is used for exchanging signaling data and data that cannot be lost, e.g. metadata. It is designed for full duplex client–server communications (messages can flow in both directions at the same time) establish “socket” connections between a web browser and a server.
The Web Socket protocol enables bidirectional real-time communication between clients and servers in web-based applications on top of a persistent TCP connection
2. Through the ws, the SDP is sent.
SDP is intended to be general purpose so that it can be used in a wide range of network environments and applications. However, it is not intended to support negotiation of session content or media encodings. For the latter, responsible is ICE.
2.1 SDP should include in the offer the Candidates. A CANDIDATE is a transport address – a combination of IP address and UDP port. In order for the candidates to be added in the SDP, ICE protocol is initiated.
The use of Web Socket as a transport protocol MAY indicate the connection URI for the Web Socket Client via a new SDP a= attribute defined in this section:
ws-uri = “a=ws-uri:” ws-URI
3. ICE protocol
ICE is an extension to the offer/answer model, and works by including a multiplicity of IP addresses and ports in SDP offers and answers, which are then tested for connectivity by peer-to-peer connectivity checks.
Each agent has a variety of candidate TRANSPORT ADDRESSES (combination of IP address and port for a particular transport protocol, which is always UDP in this specification).
It is important to note that the STUN requests are sent to and from the exact same IP addresses and ports that will be used for media
How ICE works:
- Gather possible CANDIDATES
Local -> HOST CANDIDATE: PRIVATE IP
Learnt using STUN ->SERVER REFLEXIVE ADDRESS -outside using STUN
Allocated with STUN Relay Usage requests -> USING TUNR
The purpose of ICE is to discover which pairs of addresses will work.
It orders them in highest to lowest priority
- Priority
local: higher priority
- Offers encoding
related address:
– From client contains the server’s IP and vice versa
C and M address lines must much in candidates (see SDP protocol)
- Connectivity checks every 20ms using Binding request
Your browser makes STUN-binding requests to the server-URL you passed over RTCPeerConnection constructor. Browser keeps making such binding requests for the life-time of the session to make sure connection is still active and none of the ports (or relaying server) is dropped. If you’re testing between two tabs or between two computers connected to same LAN or intranet then you don’t need to be using any external STUN/TURN server because both users are sitting behind same NAT. In this scenario, HOST-addresses will be used to connect peers.
