Glossary
WebRTC Signaling
The part of WebRTC that WebRTC does not define. Signaling carries the offer, answer and network candidates that set a call up, over whatever channel the app already has, which for a chat product is the chat connection itself.
General definition
WebRTC Signaling is everything two endpoints have to tell each other before media can flow: what they want to send, which codecs they support, the cryptographic fingerprints for DTLS-SRTP, and the network candidates where they can be reached. The WebRTC standard defines the media engine, encryption and NAT traversal in detail but deliberately does not specify how this setup information travels. The application supplies the signaling channel; WebRTC only defines the messages.
The messages follow the JSEP model (RFC 8829). One side creates an offer, a Session Description Protocol (SDP, RFC 8866) document describing its media; the other replies with an answer; both then exchange ICE candidates (RFC 8445), the addresses gathered through STUN and TURN, as they discover them, a process called trickle ICE (RFC 8838). Because the offer carries the DTLS certificate fingerprint that the media path is verified against, the signaling channel must itself be protected with TLS; an attacker who can alter signaling could otherwise insert themselves into the call.
- WebSocket to a custom server: the most common choice in web apps, with JSON messages defined by the app
- XMPP with Jingle (XEP-0166): a standardised signaling vocabulary that reuses the chat connection, presence and contact list
- SIP over WebSocket (RFC 7118): bridges browser calls into existing telephony infrastructure
- Any other channel that works: HTTP long polling, a push notification for the initial ring, even a QR code for demos
Signaling does more than the handshake. It carries the ring, accept, reject and hang-up events, mute and camera state, renegotiation when someone starts screen sharing, and in a group call the list of who is present. With an SFU, each participant signals with the server rather than with every other peer, which is simpler and lets the server decide who may join. A chat server is the natural home for all of this because it already knows who is online, already holds an authenticated, encrypted connection to each device, and already delivers messages to the right person in real time.
In the Ethora ecosystem
Ethora is built on an XMPP chat server, and its voice and video calls are WebRTC calls through an SFU, so the ingredients for signaling are already in place: every user holds an authenticated connection to the server, presence shows who is reachable, and the server can route a call event to the right person or room the way it routes a message. Calls are started from within chat, and VoIP push notifications wake a mobile app for an incoming call when it is not in the foreground.
The practical benefit for a developer is that there is no second real-time system to run. Identity, room membership and connection state are shared between chat and calls, the SDK handles the WebRTC offer, answer and ICE exchange, and the voice and video call API lets you work at the level of users and rooms rather than SDP. On a dedicated or self-hosted deployment the signaling path, the SFU and the chat archive all run inside the same infrastructure you control.
