WebRTC is an open-source project providing peer=to-peer, real-time communication capabilities to web browsers, mobile devices, and any other device that can run code using the available API's for JavaScript, Python, .NET, Golang and more.
WebRTC is mainly used to build a chat or video conferencing application, or you want to build distributed systems that communicate efficiently without putting a huge strain on a central server
How the WebRTC works it's a peer-to-peer communication available platform, but not directly NATS, private networks and all that good stuff that makes IPv4 still usable. To use this 3 main types of servers in WebRTC architecture
- STUN Server: in order for two peers to exchange packets directly, first, they have to find out how they can be contacted directly. This information is gathered though the use of a STUN Server.
- Signaling Server: It allows two peers to exchange that information about how they can connect directly, there is no specification to implement, It requires coding, and it can use Firebase, or it can be a Django App, it can run WebSockets or just HTTP.
- TURN Server: if two peers can't exchange packets directly, the packets will have to be relayed through a TURN server, this requires some configuration, it will be used throughout the whole communication session and it will require bandwidth.
In this tutorial we will act as the signaling server by just copy-pasting information that needs to be exchanged between the two peers in order to connect them,
and in this tutorial we are using just two branches of code, one is "caller" function and other one is "callee" function. ### WebRTC API we are not explaining it briefly we are just going through some instance only
Every peer has an instance of
RTCPeerConnection every instance of a RTCPeerConnection has a localDescription and a remoteDescription of type RTCSessionDescriptionInit An instance of the latter class can be of type offer or answer depending on who created it, the caller or the callee.It also contains information such as RTCIceCandidates and the channels (such as text, media).
A
localDescription contains info about what type of data the current peer can exchange (channels such as text, media), and how it can be reached (ICECandidates)
A
remoteDescription contains info about what type of data the other peer can be exchange and how it can be reached.
A
localDescription can be type offer if the current peer is the caller, and it can be of type answer if the current peer is the callee.
A
remoteDescription can be of type offer if the current peer is callee, and it can be of type answer if the current peer is caller.
