Key WebRTC Terms and Technologies
Key WebRTC Terms and Technologies
-
JavaScript APIs:
getUserMedia: Acquires audio/video media from devices (e.g., camera, microphone)RTCPeerConnection: Manages peer-to-peer connections for audio/video/data exchangeRTCDataChannel: Enables bidirectional data communication between peersgetStats: Retrieves statistics about WebRTC sessions
-
ICE (Interactive Connectivity Establishment):
-
Helps find the best path for communication through firewalls and NATs by exchanging ICE candidates
-
Uses STUN servers for public IP discovery and TURN servers for relaying media when direct P2P isn’t possible
How can we create an ICE Server? How does it work, and what exactly does it do?
ICE: ICE itself is a protocol designed to establish peer-to-peer connections over the Internet. It’s useful where devices are behind NATS or Firewalls.
Components of ICE Server:
- ICE Candidate
- Stun servers
- turn server
-
-
Signaling:
- Signaling servers act as intermediaries for exchanging setup messages (SDP offers/answers, ICE candidates)
- This transfer of ICE candidates is commonly called signaling.
-
SDP (Session Description Protocol): SDP is a full session description
that contains:
- Media types (audio, video, data channels)
- Connection parameters
- Codec details
- ICE credentials (but NOT actual ICE candidates)
- DTLS fingerprints for security
-
Media Streams:
- Represent audio/video streams captured from devices; can be added to
RTCPeerConnectionfor transmission
- Represent audio/video streams captured from devices; can be added to
-
Security:
- WebRTC encrypts data using DTLS (Datagram Transport Layer Security) and SRTP (Secure Real-time Transport Protocol)
What is an Audio Codec?
An audio codec is a type of codec specifically developed to reduce the size of audio data, thereby enhancing its transmission and storage capacities. It operates by encoding or decoding audio in a particular audio format.
This may be:
- Uncompressed audio codec
- Lossless codec
- Lossy codec.
It’s worth noting that each type of audio codec behaves differently with your audio data. An uncompressed audio codec keeps the sound quality intact by not compressing the audio data. This process assures high-quality audio, though it results in larger file sizes.
On the other hand, lossless codecs work a little differently. They compress audio data without losing any information, maintaining excellent sound quality. The resulting audio file is smaller than the original uncompressed but can be fully restored without losing quality. That’s why it’s known as a lossless audio format.
Lossy codecs compress audio by removing some data. The result is a significantly smaller file size than uncompressed or lossless audio codecs but with a compromise in sound quality. Despite this compromise, most listeners will only notice the difference if they have a trained ear or high-quality audio equipment.
Many codecs are available; the most popular is MP3, and the most suitable is AAC (advanced audio codec).
WEB RTC APIs:
The WebRTC standard covers, on a high level, two different technologies,
- Media capture devices
- peer-to-peer connectivity.
Media Capture, Devices:
Includes Cameras and Microphones as well as screen-capturing devices.
For Cameras and Microphones, we use navigator.mediaDevices.getUserMedia() to capture the media stream.
For Screen recording, we use navigator.mediaDevices.getDisplayMedia() instead.
Peer-to-peer connectivity: Peer-to-peer connection is handled by the RTCPeerConnection interface. This is the central point for establishing and controlling the connection between two peers in WebRTC.
RTCPeerConnection:
- onmessage: an event handler used to process the incoming message. When the message has received the parameter (it could be e/event) containing the message,
e.data= (message.) - onopen:
- The
onopenevent fires when the channel is ready for communication. - Once open, you can send messages using
dataChannel.send("message").
- The
- onclose:
oncloseevent helps detect when the channel closes. - onicecandidate:
- The
onicecandidateevent fires whenever a new candidate is available. - You typically send the ICE candidates to the remote peer via a signaling server.
- The
- ondatachannel:
- The local peer creates a
RTCDataChannelusingcreateDataChannel(). - The local peer sends an offer to the remote peer.
- The remote peer receives the data channel through
remoteConnection.ondatachannel.
- The local peer creates a
SDP Sample:
v=0
o=- 1234567890 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0
m=application 9 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 0.0.0.0
a=ice-ufrag:abcd
a=ice-pwd:xyz123
a=fingerprint:sha-256 1A:2B:3C...
a=setup:actpass
What is an ICE Candidate?
- An ICE candidate is a network path that a peer can use to connect.
- They are gathered after the SDP exchange and sent separately.
- Candidates describe actual IP addresses and ports for the connection.
✅ ICE candidates are exchanged after the SDP offer/answer.
a=candidate:607798563 1 udp 2113937151 192.168.1.10 54778 typ host
candidate:607798563→ Candidate ID1→ Media component ID (1 = RTP, 2 = RTCP)udp→ Transport protocol2113937151→ Priority192.168.1.10→ Local IP address54778→ Port numbertyp host→ This is a local network candidate (not a public IP)