A secure call has more than one data path. Signaling coordinates who is calling and how endpoints connect; the media path carries audio and video. Protecting one path does not automatically protect the other, and neither alone hides every communication pattern.
WebRTC provides important security mechanisms, but an application's identity checks, server roles and recording mode still determine the complete privacy boundary.
Signaling and media do different jobs
| Layer | Typical purpose | Security question |
|---|---|---|
| Signaling | Invitations, session descriptions and connection candidates | Who can read or alter setup information, and how is the intended peer authenticated? |
| Media | Audio, video and related real-time streams | Where does encryption terminate, and which endpoints can access the media? |
| Operational records | Routing, connection timing and delivery state | Which metadata can the service or network observe? |
| Recording | Producing a retained copy | Who receives plaintext or usable recording keys, and where is the copy stored? |
A messaging protocol can carry encrypted signaling, but WebRTC does not universally require a particular messenger's envelope format. Other authenticated designs are possible.
What DTLS-SRTP provides
The WebRTC Security Architecture, RFC 8827, requires protection for media channels and describes DTLS-SRTP key establishment. In simplified terms, DTLS helps establish the cryptographic context and SRTP protects the real-time media packets.
The endpoints of that protection matter. A direct encrypted connection between participants is different from a connection that terminates at a media-processing server. Some multiparty systems add a separate end-to-end layer above server-facing transport encryption. The word “WebRTC” alone does not tell you which architecture a product uses.
Why signaling authentication matters
A call setup can contain information used to bind the media connection to the intended party. If an attacker can substitute that information without detection, encryption may establish a protected connection to the wrong endpoint.
RFC 8827 discusses this relationship between signaling, identities and DTLS fingerprints. HTTPS protects a connection to the signaling service; it does not by itself remove the need to consider a malicious or compromised service. End-to-end authenticated signaling or an appropriate independent peer-verification mechanism can strengthen that boundary.
Signaling confidentiality is a related but different goal: it limits who can read setup details. A design should explain both confidentiality and authentication rather than treating an encrypted blob as sufficient evidence of each.
Encrypted signaling does not make a call invisible
The relay may still know which accounts or devices it routes between. Network observers may see connection timing, traffic volume and server addresses. Peers or relay infrastructure can also learn network information depending on the connection design.
Consequently, encrypting a call invitation does not prove that the service cannot infer a call, map relationships or retain call-related records. Hiding content and hiding traffic patterns are separate problems.
Livara's published boundary
Livara's security page describes direct and group calls as end-to-end encrypted, but makes an explicit exception for optional server recording: while the visible REC state is active, the call uses transport encryption rather than E2EE.
Its threat model also rejects metadata-anonymity claims and protection against a compromised device. These are product statements, not an independent verification of every call path. This guide does not claim an unverified participant limit, signaling format or post-quantum media implementation.
In particular, a post-quantum messenger key exchange does not automatically upgrade a separate WebRTC media handshake. The algorithms and key binding on the media path must be assessed independently.
Before a sensitive call
- Confirm the participants and review unexpected identity changes.
- Check whether recording is enabled and what the application says that changes.
- Understand whether the service processes media or only forwards protected packets.
- Consider the devices and rooms around participants: malware, screen capture or a nearby listener can expose content after decryption.
- Ask for architecture and test evidence for the exact mode you use, rather than relying on a general “encrypted calls” badge.
The useful security claim identifies who can access signaling, media, metadata and recordings separately.
