Freeze one call and classify the first failed state
Record the Linphone or Liblinphone build, operating system, account, peer, call direction, timestamp and expected security policy. Classify the symptom precisely: the call fails when encryption is required, the call completes without the preferred protection, the selected method differs, the application reports a security downgrade, the ZRTP token is absent, the SAS is unknown or changed, or the two parties read different strings.
Do not collapse these into “encryption broken.” Registration, SIP TLS, media capability, offer and answer, selected call protection, packet flow and ZRTP peer verification are separate evidence. Preserve current settings and continuity state before reinstalling the app, removing an account or clearing security data.
Confirm the effective policy and failure contract
Establish the configured media-encryption type and whether it is mandatory on the affected build and account. Liblinphone 5.5 distinguishes support, selection and mandatory enforcement. If mandatory is true and the desired mechanism cannot be negotiated, call failure is expected; if it is false, the library documents an unencrypted retry path.
Use a controlled peer approved for the selected mechanism. Compare with one known-good account or endpoint without broadening the allowed mechanisms globally. Do not switch off mandatory protection to make the symptom disappear; that converts a visible policy failure into a possible downgrade.
Follow the offer and answer to the selected media state
Capture sanitized signaling and application state for the exact call. Identify each offered and answered media line, key-establishment method, transport profile, selected encryption type and any renegotiation. Confirm that both endpoints support the same method and that an intervening PBX, SBC, conference service or gateway is not terminating or rewriting the leg.
A successful TLS connection protects only that signaling hop. A protected RTP profile in one SDP body is not proof that the answer accepted it or that packets used the same destination. Conversely, unreadable captured media does not establish the far party’s identity. Keep credentials, SDES key material, private addresses and media payloads out of shared evidence.
Investigate ZRTP SAS state without forcing trust
When ZRTP is selected, confirm that the call produces the authentication token and compare the displayed SAS with the intended party over a trusted channel. Liblinphone tracks whether the token was verified and a peer status of unknown, invalid or valid. Do not change unknown or invalid to valid unless the comparison actually succeeds.
If a previously accepted peer now shows a different SAS, record device replacement, app reinstall or reset, account change, backup restoration, endpoint identity and continuity-cache history. A benign state loss is possible, but do not assume it. Stop sensitive communication when organizational policy requires it and escalate a mismatch or unexplained continuity change to the security owner.
Correct one boundary and repeat negative tests
Correct only the demonstrated owner: choose the approved mechanism, restore mandatory policy, align peer support, fix the intervening media path, restore an expected endpoint under change control, or re-establish ZRTP verification after a trusted identity check. Keep the previous configuration and do not delete continuity evidence merely to remove the warning.
Repeat the original call, an intentionally incompatible peer when safe, inbound and outbound directions, and any transfer, conference or network-change case in scope. Record expected call rejection under mandatory policy, selected protection on success and the separate ZRTP verification result. No app, SDK, account, peer, PBX, signaling session, SDP body, media stream, ZRTP cache, SAS comparison, packet capture or call was inspected or tested for this diagnostic.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Linphone softphone security architecture ↗
- Liblinphone 5.5 media parameters ↗
- Liblinphone 5.5 call control ↗
- Liblinphone provisioning configuration keys ↗
- RFC 3711 Secure RTP ↗
- RFC 6189 ZRTP ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.