Add markdown files for basic explanation on WebRTC

webrtc-explained.md

@@ -0,0 +1,128 @@
+# WebRTC Core Concepts
+
+Below are the core components you see in WebRTC libraries (including Rust implementations like webrtc-rs).
+
+## Media
+Handles audio and video streams:
+- microphone
+- webcam
+- screen share
+- encoding/decoding (Opus, VP8, H264, etc.)
+- track pipelines
+- jitter buffers
+
+Represents the actual media content.
+
+## Interceptor
+Middleware for packet flow in WebRTC.
+
+Used for:
+- congestion control
+- retransmissions
+- analytics
+- logging
+- bitrate adaptation
+- simulcast filters
+
+## Data
+Refers to WebRTC Data Channels.
+
+Supports:
+- text and binary
+- reliable or unreliable delivery
+- ordered or unordered delivery
+
+Used for chat, game sync, file transfer, etc.
+
+## RTP (Real-time Transport Protocol)
+Packet format for real-time media transmission.
+
+Includes:
+- timestamps
+- sequence numbers
+- SSRC identifiers
+
+Carries media data.
+
+## RTCP (RTP Control Protocol)
+Feedback channel for RTP.
+
+Reports:
+- packet loss
+- jitter
+- round trip time
+- bandwidth
+- keyframe requests
+
+## SRTP (Secure RTP)
+Encrypted RTP for media.
+
+Uses keys negotiated via DTLS.
+
+## SCTP (Stream Control Transmission Protocol)
+Protocol used by WebRTC Data Channels.
+
+Provides:
+- multiple streams
+- partial reliability
+- no head-of-line blocking
+
+Runs inside DTLS.
+
+## DTLS (Datagram TLS)
+TLS over UDP.
+
+Used for:
+- verifying peer identity
+- negotiating encryption keys
+- securing SCTP
+- securing SRTP
+
+## mDNS
+Masks local LAN IP addresses for privacy (e.g. *.local hostnames).
+
+## STUN
+Discovers:
+- public IP
+- public port
+- NAT mappings
+
+Used for peer-to-peer connectivity.
+
+## TURN
+Relay server fallback when direct P2P isn't possible.
+
+Used in restrictive NAT environments.
+
+## ICE (Interactive Connectivity Establishment)
+System that tests multiple network paths and selects the best one.
+
+Uses:
+- host candidates
+- STUN candidates
+- TURN relay candidates
+
+Continuously monitors connectivity.
+
+## SDP (Session Description Protocol)
+Text-based connection description used for signaling.
+
+Contains:
+- codecs
+- ICE credentials
+- DTLS fingerprints
+- media types
+- transport configs
+
+Used in offers and answers.
+
+## Util
+Shared helper utilities.
+
+Commonly includes:
+- random generators
+- buffer helpers
+- parsers
+- timers
+- UUID helpers
+

webrtc-signaling-explained.md

@@ -0,0 +1,115 @@
+# WebRTC Signaling Explained
+
+## What is Signaling?
+
+Signaling is the process where two peers exchange the information required to establish a WebRTC connection.  
+It happens *before* any direct peer connection is possible.
+
+This includes exchanging:
+- SDP Offer
+- SDP Answer
+- ICE Candidates
+
+
+## Why Signaling Is Needed
+
+WebRTC peers cannot discover each other on their own.
+
+They need to:
+- agree on codecs and media setup
+- share network information
+- exchange security fingerprints
+
+Signaling provides this exchange.
+
+
+## What Signaling Is Not
+
+Signaling is **not**:
+- part of WebRTC itself
+- standardized
+- a fixed protocol
+- tied to any transport
+
+
+## Signaling Transport Options
+
+Signaling can use any transport, including:
+- WebSockets
+- HTTP
+- REST
+- SSE
+- MQTT
+- TCP
+- UDP
+- Redis pub/sub
+- anything else
+
+
+## What Information Gets Exchanged
+
+### SDP (Session Description Protocol)
+Contains:
+- codecs
+- media directions
+- ICE usernames/passwords
+- DTLS fingerprints
+- transport description
+- media streams
+
+### ICE Candidates
+Contain:
+- IP addresses
+- ports
+- transport protocol
+- candidate priority
+
+
+## Typical Signaling Flow
+
+1. Peer A creates PeerConnection
+2. Peer A generates Offer (SDP)
+3. Peer A sends Offer to Peer B using the signaling channel
+4. Peer B sets remote Offer
+5. Peer B generates Answer (SDP)
+6. Peer B sends Answer back via signaling channel
+7. Both sides exchange ICE Candidates
+8. ICE finds a working route
+9. Peers connect directly
+
+
+## Signaling Server Responsibilities
+
+A signaling server:
+- relays Offer
+- relays Answer
+- relays ICE candidates
+
+It does *not*:
+- relay audio/video (RTP)
+- relay data channel traffic
+- stay involved after connection succeeds
+
+
+## Server After Connection
+
+Once the WebRTC connection is established:
+- the signaling server is no longer required
+- peers communicate directly (unless TURN is used)
+
+
+## Simplified Diagram
+
+Peer A ---- Offer/Answer/ICE ----> Signaling Server ---- Offer/Answer/ICE ----> Peer B
+
+Peer A <------------------------------------- P2P ------------------------------------> Peer B
+
+
+## Summary
+
+- Signaling exists only to bootstrap WebRTC.
+- It exchanges Offer, Answer, and ICE candidates.
+- It is not part of WebRTC protocol.
+- You can use any transport you want.
+- Once done, peers can communicate directly.
+