For call security, do not just ask “Is it encrypted?” Ask where encryption ends and what recording changes.
Chat encryption alone does not prove that audio, video, screen sharing or call recordings receive the same protection. To assess a call, ask how far media remains encrypted, who holds the keys and what changes when features such as recording are enabled.
This guide breaks security claims down into layers that can be examined; a protocol name or a padlock icon is no substitute for answers to these questions.
Three different paths in one app
| Path | Example data | Security question |
|---|---|---|
| Stored messages | Text, photos, files and voice notes | Who can read the copies on devices, servers and in backups? |
| Live media | Microphone audio, video and screen sharing | Does encryption end on the other participant’s device or on an intermediary server? |
| Signalling | Call invitations, answers and connection coordination information | Who can alter control messages or the intended recipient’s identity? |
A voice note sent in a chat is a file; a voice call is a live stream. A product may use different keys and mechanisms for the two. Good audio quality or a text message failing to arrive does not, by itself, say anything about the security of the other path either.
What does DTLS-SRTP tell us?
In WebRTC, SRTP protects the media stream, and DTLS-SRTP provides a way to establish its keying material. RFC 5764 explains the DTLS-SRTP mechanism, and RFC 3711 explains media packet protection.
But “we use WebRTC” does not, by itself, answer whether the conferencing server decrypts the media. The encryption endpoints and their authentication must be specified. A connection between a user and a server may be encrypted while the server has access to decrypted content for processing or recording. This is not the same as E2EE between participants.
The WebRTC security architecture in RFC 8827 also shows that trust in the web application, the signalling path and the other party’s identity matter alongside media protection. Encrypted packets do not mean that every component of a product is trustworthy.
Why must signalling be assessed separately?
Signalling coordinates who calls whom and how the connection is established. If an app protects its control messages, you still need to examine how that protection is tied to the participants’ actual identities and the media keys.
Three questions are enough to guide your reading of the documentation:
- Are invitations, answers and key information protected against modification?
- How does the user know that a key belongs to the intended contact?
- What warning appears when a key or device changes?
Routing information, timing and call membership may be known to the service even in an E2EE call. Messaging metadata explained discusses this distinction.
Call recording creates a new security boundary
“Encrypted call” does not fully answer questions about the recorded copy. A participant can capture audio or video with their own device. Server-side recording also needs separate documentation: does the server gain access to readable media in order to record it? Who keeps the file? When is it deleted?
If enabling recording changes the security mode, that change must be clear to participants. Before a sensitive conversation, check the recording status and everyone’s consent; an inactive built-in recording indicator does not guarantee that nobody is recording with another device.
How should we read Livara’s current documentation?
Livara’s security page describes direct and group calls as E2EE, but makes an exception for optional server-side recording: in the visible REC mode, call protection switches to transport encryption. This is a claim in the product documentation, not the result of an independent test or audit by this article.
The old text’s restriction of all group calls to “2–6 people on Android” is inconsistent with the current documentation and is not used as a basis for this guide. For the capacity, platform and version you need, consult the current guidance and check the app’s actual behaviour; this article does not provide a capacity test.
Likewise, naming chat algorithms such as ML-KEM does not, by itself, prove that the same algorithm is used for call media. A claim that calls are post-quantum requires evidence specific to the media path and authentication. Read Livara’s threat model alongside its features page, not as a substitute for independent testing.
A short checklist before comparing two services
For each “yes”, also record the version and the source:
- Are one-to-one calls, group calls and screen sharing described separately?
- Is it clear whether the server only forwards packets or can decrypt the media?
- Can a participant’s identity and key be verified?
- Are device changes, new participants joining and recording being enabled apparent?
- Is the call path the same on the web and in the app, or does it differ?
- Is retention of recordings and metadata explained?
- Does the test or audit evidence relate to the same version and feature?
If the documentation does not answer a question, write “unknown”; an absent answer is neither proof of security nor proof of eavesdropping.
Frequently asked questions
Does an E2EE call prevent the other participant from recording it?
No. An authorised recipient has access to readable content and may record it using software or another device.
Is transport encryption bad?
Transport encryption provides important protection against eavesdropping along the transmission path. The difference is that the service acting as an endpoint can access decrypted content; this should not be called E2EE between users.
Does post-quantum encryption in chat make calls post-quantum too?
No. The claim must relate to the same layer, algorithms and implementation version. Assess chat and calls separately.
