iCallU.online

Open source & components

At a glance

  • Transport: WebRTC for real-time audio/video (secure by default with DTLS-SRTP).
  • Crypto primitives: WebCrypto where supported (audited building blocks vs custom crypto).
  • Optional E2EE path: Insertable Streams on compatible browsers (see E2EE design).
  • Coordination: Socket.IO signaling to exchange session metadata (not the media path).
  • Connectivity: STUN/TURN for NAT traversal and hard networks.

Why it matters

iCallU.online is built on widely used, public standards and audited primitives - especially for cryptography. This matters because security improves when the core building blocks have been tested by many researchers, developers, and real-world deployments.

This page is not a full SBOM (software bill of materials), but it provides a high-level view of the components that shape the security model of iCallU.online: browser transport (WebRTC), cryptographic primitives (WebCrypto), signaling (Socket.IO), and the server runtime (Node.js).

Major components (high level) and what they do

WebRTC (browser real-time media)

WebRTC is the browser standard used for real-time audio/video transport. It handles media capture (camera/mic), packetization, congestion control, jitter buffering, NAT traversal (ICE), and secure media transport (DTLS-SRTP) by default. iCallU uses WebRTC for low-latency 1-on-1 calls with modern browsers.

WebCrypto (cryptographic primitives)

WebCrypto is the browser API for standard cryptographic operations. Where supported, it provides well-defined primitives such as hashing, key derivation, and authenticated encryption building blocks. iCallU uses audited primitives instead of "rolling our own crypto". (When optional E2EE is enabled, these primitives support key agreement / derivation / AEAD style flows.)

Insertable Streams (E2EE path for media)

Some browsers support WebRTC Insertable Streams, which allow an application to transform encoded frames before they are sent (and after they are received). This capability enables an end-to-end encryption layer on top of standard WebRTC transport for compatible clients. This page stays high-level; see the E2EE design page for the conceptual flow.

Node.js (application server)

Node.js runs the iCallU.online application server that serves pages, handles authentication, routes, and session logic, and coordinates ephemeral call setup. The server is designed to support a relay-style model: it helps peers find each other and exchange signaling data, but it is not intended to learn call content.

Socket.IO (signaling)

Socket.IO provides the real-time messaging channel used for signaling: exchanging offers/answers, ICE candidates, and other session metadata required to establish a WebRTC connection. Signaling is a coordination layer - it is not the media path. (In a relay-only approach, signaling can forward public key material, but should not be able to decrypt content.)

TURN/STUN (connectivity, NAT traversal)

For reliable connectivity across networks, WebRTC commonly uses STUN (to discover public-facing connectivity details) and TURN (to relay media when direct peer-to-peer paths are blocked). TURN can also help reduce peer IP exposure depending on the call path and configuration. iCallU uses standard WebRTC ICE behavior with TURN support for hard networks.

Related security pages

What users can verify

If you're evaluating iCallU for privacy and security, the most useful next steps are:

  • Review the Security Hub for model and guarantees.
  • Read the E2EE design page for the high-level key agreement and encryption flow.
  • Check the Privacy Policy for data handling and retention commitments.
  • Try the Crypto demos to understand the primitives and tradeoffs.