Signaling is the process by which two WebRTC peers exchange the metadata needed to establish a media session: SDP (Session Description Protocol) offers and answers that describe each peer's supported codecs, media directions, and security parameters, as well as ICE candidates that describe their network addresses. Critically, WebRTC does not define how signaling is done — the specification explicitly leaves this to the application, which means each platform implements its own signaling protocol on top of WebSocket, HTTP long-polling, or a proprietary channel. This is a deliberate design choice that allows flexibility but means there is no universal signaling standard to interoperate with. In a virtual classroom architecture the signaling server is the rendezvous point: when a participant joins, the server coordinates the SDP exchange between the new participant and the SFU (or other peers), distributes ICE candidates via trickle ICE, and handles room-level events like mute, admit, and hand-raise. Signaling messages are small and infrequent compared to media traffic, so a WebSocket-based signaling server can handle thousands of concurrent classrooms on modest hardware. The trade-off is reliability: if the signaling connection drops mid-class, the media session may continue but control events (mute, layout changes) will be lost until reconnection. Signaling is also the layer where authentication and authorization are enforced — the server validates tokens and controls which participants are permitted to publish media before forwarding their SDP to the SFU.
