Voice and video, DChat Guides

Voice and video

One-to-one calls and group calls are built on genuinely different infrastructure, with genuinely different guarantees. This is the single most important correction on this site, so it is stated once here without hedging: one-to-one calls are end-to-end encrypted; group calls are not.

One-to-one. A 1:1 call is WebRTC over SIPSorcery, connecting directly, peer-to-peer, between the two devices, with DTLS-SRTP securing the media end to end - no server sits in the media path. Call signalling rides as ephemeral relay messages that are never written to a pool; nothing about setting up the call is persisted anywhere. ICE servers are issued as short-lived, per-call credentials fetched from DChat's middleware over an authenticated endpoint, following the standard coturn REST pattern - a username of the form "<expiry>:<wallet>" paired with an HMAC-SHA1 credential - with public STUN as a fallback if TURN relaying is not needed. One consequence of peer-to-peer connectivity is unavoidable and should be said plainly: your IP address is visible to your call partner, and to the TURN server if the call relays through one. This is inherent to how direct calling works, not specific to DChat, but it is real and worth knowing before you place a call to someone you don't want locating you. On screen, a 1:1 call gives you camera-flip, speaker/bluetooth output, a video toggle, mute and end-call controls, and every call - 1:1 or group - is logged afterward in a call history screen.

Group calls. Multi-party calls run through a Janus VideoRoom SFU (selective forwarding unit), supporting up to 25 publishers in a room, reachable either from an existing group or ad hoc from a multi-select contact picker's "New Call" option. An SFU works by terminating the encrypted connection with each participant individually and re-encrypting outward to everyone else - that is what lets it scale past two people at all. The practical result: the SFU decrypts every participant's audio and video in the middle of the call before re-encrypting it for the rest of the room. There is no frame-level or insertable-streams end-to-end encryption anywhere in the DChat codebase for group calls. They are encrypted in transit to and from the SFU - not end-to-end between participants. The call screen shows every participant in a grid, with options to minimize the call or pin one participant to keep them large on screen.

What that does and does not mean for a real threat model: it means whoever operates or compromises the SFU can see plaintext audio and video of a group call, the same exposure a traditional video-conferencing bridge has always had. It does not mean the call is sent in the clear over the network - a passive observer between your device and the SFU still sees only encrypted RTP, and it does not affect the confidentiality of DChat's direct messages or 1:1 calls, which remain genuinely end-to-end. If a group call carries something you would not say in front of the SFU operator, use a 1:1 call, or accept that a group call has the trust profile of a conference bridge rather than a sealed channel.