VoIP.infoThe independent guide to business communications.
VoIP.info Security guide

Linphone media encryption: policy, negotiation and ZRTP verification

Separate Linphone media-encryption capability, required policy, call-selected mechanism and ZRTP peer authentication before describing a call as protected.

Reviewed 2026-10-13Current Linphone softphone security page and Liblinphone 5.5 media-parameter, call-control and provisioning references reviewed October 13, 2026 with RFC 3711 and RFC 6189; API capabilities and protocol specifications do not prove that one distributed Linphone build exposes the same controls, that a third-party SIP service accepts them, or that a call negotiated, retained or authenticated protected media, and no app, SDK build, account, peer, PBX, signaling session, SDP body, media stream, ZRTP cache, SAS comparison, packet capture or call was inspected or testedAdvancedDocumentation based · not lab tested

Separate signaling protection from media protection

Linphone lists TLS-capable authentication and SRTP, ZRTP and DTLS-SRTP media choices, but those labels protect different boundaries. SIP TLS can protect a signaling hop when certificate validation and the selected transport succeed; it does not by itself encrypt RTP. A media setting likewise does not prove the registrar, proxy, PBX, gateway or far endpoint used a protected signaling path.

Record the exact Linphone application or Liblinphone build, account, signaling transport, peer, selected media policy and whether encryption is required. Preserve the call direction and every server or gateway that can terminate a protected leg. Do not transfer Linphone-suite end-to-end claims to an arbitrary third-party SIP account, PSTN destination or back-to-back PBX call.

Keep capability, selection and enforcement as three states

Liblinphone 5.5 exposes None, SRTP, ZRTP and DTLS as media-encryption types. It separately reports whether a type is supported, selects the media-encryption policy and controls whether the selection is mandatory. These are not interchangeable facts: a compiled capability can be available without being selected, and a selected mechanism can be allowed to fall back when mandatory enforcement is off.

The 5.5 reference says a call fails when mandatory encryption cannot negotiate the desired protection; when encryption is not mandatory, it may resend an INVITE with encryption disabled. Treat a completed unprotected call under optional policy as a downgrade result, not proof that the preferred protection succeeded. Test the approved failure condition before relying on a required-policy control.

Prove the mechanism selected for the call

Inspect the effective call parameters and the offer and answer for the exact session. Liblinphone exposes the media-encryption kind selected for a call and the encryptions supported in call parameters. For SDES-SRTP it also exposes the enabled SRTP suites, while DTLS-SRTP and ZRTP use different key-establishment evidence. A lock icon, settings screen, encrypted-capability list or unreadable packet payload is not a complete negotiation record.

Retain only authorized, sanitized evidence: call timestamp and identifiers, local and remote identities, both SDP bodies, selected method, suite or keying family, application security state and any change event. Protect SDP key material, credentials, logs and captures. Do not publish keys or use a packet capture as a substitute for peer authentication.

Treat the ZRTP SAS as a separate identity check

ZRTP establishes SRTP keys in the media path and can display a Short Authentication String so the parties can compare what their endpoints calculated. RFC 6189 describes that comparison as a way to detect a man-in-the-middle condition. Liblinphone separately exposes the authentication token and a peer status of unknown, invalid or valid; encrypted media and verified peer identity are therefore different states.

Compare the SAS through an already trusted human or organizational channel and bind the result to the intended peer identity and endpoint. Do not mark a token verified merely to clear a warning. A changed or unknown SAS can follow device replacement, application reset, lost continuity state or a different endpoint, but it can also require a security investigation; classify it before accepting the call.

Bound PBX, conference and gateway claims

A PBX or gateway can terminate one protected leg and create another. RFC 6189 explicitly describes PBX cases with two back-to-back ZRTP connections and separate keys and SAS values. That is not the same trust boundary as a direct end-to-end ZRTP session. Record every termination point, who administers it and whether recording, transcoding, conferencing or PSTN interworking exposes media.

Repeat acceptance after transfers, conference entry, hold and resume, video changes and network transitions when those workflows matter. A protected initial audio leg does not automatically cover a newly negotiated stream or downstream carrier leg. No Linphone application, SDK, account, PBX, protected path, SAS or call was tested for this guide.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.

Continue your research

Client research · Current Linphone product, download, 6.2 release, stable desktop archives, third-party account, provisioning, push and security documentation rechecked October 7, 2026; the Windows, macOS and GNU/Linux stable archives all remained at desktop 6.2.3 dated September 22, 2026; no app, build, provisioning service, SIP account, Flexisip service, PBX, push, protected-media, message or call test

Linphone softphone: platform, provisioning and third-party SIP limits

Research the installable desktop and mobile clients, remote configuration and documented push boundary.

Read guide →
Hub · Primary softphone documentation reviewed through October 10, 2026; app, package, browser, mobile-wrapper, Windows audio and PBX interoperability not lab tested

Softphone research

Choose a desktop, mobile or browser calling client by SIP account, provisioning control, encryption and reliable call delivery.

Explore topic →
Protocol reference · RFC 3261 SIP, RFC 3711 SRTP, RFC 4568 SDP Security Descriptions, RFCs 5763 and 5764 DTLS-SRTP, and current Asterisk PJSIP documentation reviewed October 6, 2026; deployed endpoints, intermediaries, certificates and calls require direct verification

SIP TLS and SRTP: what each protects

Distinguish adjacent-hop signaling protection, SRTP media protection, SDES and DTLS-SRTP keying, and the actual termination points on every call leg.

Read guide →
Hub

VoIP security

Reduce PBX exposure, constrain calling permissions and prepare for accountable recovery.

Explore topic →
Guide · Wireshark 4.x / current upstream tool documentation; inspect installed versions

VoIP packet-capture methodology

Select interfaces, time windows and paired capture points that distinguish network loss from missing evidence.

Read guide →
Diagnostic · Current Linphone softphone security page and Liblinphone 5.5 media-parameter, call-control and provisioning references reviewed October 13, 2026 with RFC 3711 and RFC 6189; API capabilities and protocol specifications do not prove that one distributed Linphone build exposes the same controls, that a third-party SIP service accepts them, or that a call negotiated, retained or authenticated protected media, and no app, SDK build, account, peer, PBX, signaling session, SDP body, media stream, ZRTP cache, SAS comparison, packet capture or call was inspected or tested

Linphone call is unencrypted or the ZRTP SAS changed

Trace one Linphone call from configured policy through offer and answer, selected media protection, mandatory behavior and ZRTP peer verification before changing security controls.

Read guide →