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

Match the build to the deployment

The official download page lists Windows, macOS and GNU/Linux desktops plus iOS and Android. Rechecked October 7, 2026, the three stable desktop archives each still identified Linphone 6.2.3 dated September 22: a Windows executable, macOS disk image and GNU/Linux AppImage. That convergence is a desktop release snapshot, not a universal mobile version, supported-operating-system promise or proof that every store and repository channel has converged. Record the exact client build, operating system, artifact or store channel, retrieval date and server used for each observation.

Linphone's architecture keeps native mobile applications, the desktop application, the Liblinphone engine and Flexisip server components distinct. The download page also exposes daily snapshots but labels them automatically generated and unverified. Do not replace a stable acceptance build with a snapshot merely because its timestamp is newer. A web version remains described as under development rather than a current downloadable browser phone.

Keep 6.2 feature claims attached to their server and platform

Linphone's July 2026 version 6.2 announcement describes a cross-platform family release, not one binary or entitlement. Its edited or deleted messages require SDK 5.5 and operate within a conversation whose server and peers implement the behavior. File deletion describes local storage after a message is deleted; it is not a universal retention, backup or remote-erasure guarantee. Trusted-device display, CardDAV or LDAP, document preview, keyboard shortcuts and meeting functions have platform-specific scope.

The combined blind and attended transfer interface can target an existing call or SIP address, but a visible button does not prove the PBX accepts the transfer method, identity or referred destination. Re-run attended and blind transfer acceptance against the exact PBX, call state and client build. The announcement's complete local-data removal on account deletion names authentication information, history, conversations and meetings; verify device backups, exported files, server records and remote participants separately before treating account removal as an offboarding control.

Control remote provisioning

Linphone supports remote configuration through an XML file; mobile apps can accept a QR code that carries a provisioning URL. The provisioning reference warns that supplied entries can overwrite account and authentication data. A QR code is therefore a configuration locator, not proof of the destination's trust or of successful enrollment. Use an authenticated, integrity-protected endpoint, review the XML and restrict who can issue or scan links.

A third-party SIP login separately asks for SIP identity, username, password, domain and transport. Keep the provisioning URL, retrieved configuration, SIP credential and installed account as distinct lifecycle objects. Check unavailable-server, changed-local-setting, replacement-device and revoked-user behavior. Rotate a compromised credential at the SIP service; deleting the local profile or replacing the XML is not server-side revocation.

Check encryption on both legs

The current product page lists TLS-capable authentication and SRTP, ZRTP and DTLS-SRTP media options. These are separate mechanisms whose availability and negotiation depend on the exact account, peer and server path. Inspect the negotiated signaling and media leg rather than treating a product capability or settings label as a completed protected call. Define and test failure behavior when encryption is mandatory.

Linphone also describes end-to-end and post-quantum protection through its broader Linphone, Flexisip, LIME and Ekt-server architecture. Do not transfer those suite claims to an arbitrary third-party SIP account, ordinary PSTN call or SIP SIMPLE conversation. A protected client-to-server leg does not prove protection after the server or telephone-network boundary.

Do not assume third-party push

The current Linphone FAQ limits built-in mobile push notifications to Linphone accounts and says third-party SIP accounts do not receive them. It separately offers a business or service-provider push arrangement. Linphone's server documentation shows why this is not a client-only switch: a compatible proxy retains the pending request, sends the platform push and accepts the device's refreshed registration or connection.

Treat SIP registration, platform-token provisioning, server push configuration, notification arrival, app wake, refreshed contact, pending INVITE or MESSAGE delivery and usable audio or chat as separate evidence. Test foreground, background, closed-app, locked-screen, reboot, Wi-Fi and mobile-data states with the exact account and deployment. Provide a separately approved fallback route when background reachability is operationally important.

For a missed background call, the background ringing diagnostic separates account entitlement, push token, registrar or proxy support, device wake-up and SIP request delivery instead of treating the client notification toggle as complete configuration.

Bound messaging and account-service claims

Linphone supports a community Linphone account as well as login to a third-party SIP account. Basic SIP calling or SIP SIMPLE messaging with a third party does not establish Flexisip group chat, conferencing, contact discovery, LIME encryption, history synchronization or account-management behavior. Map each required feature to the server component and credential that supplies it.

Run a bounded acceptance pilot for registration, inbound and outbound calls, DTMF, hold and transfer when required, two-way audio, video, messages, contact permissions, notification state, network changes, logs, credential revocation and provider-approved emergency behavior. Record failures without inferring availability, battery life, interoperability, quality or support from the open-source licence or feature list. No Linphone app, build, provisioning service, SIP account, Flexisip service, PBX, push path, protected-media leg, message or call was tested for this guide.

Diagnose a stale or returning provisioned value

When the configuration downloads but one value stays wrong or returns after restart, use the Linphone remote-provisioning diagnostic. It separates the selected URL, next-start fetch, returned XML, supported key, per-entry overwrite and one-time versus repeated application before touching the SIP account.

Verify Linphone media policy and ZRTP identity separately

Use the Linphone media-encryption guide to separate compiled capability, selected policy, mandatory enforcement, negotiated call protection and ZRTP SAS verification. When a call downgrades, fails under required policy or shows a changed SAS, follow the paired diagnostic without disabling protection or forcing peer trust.

Trace Linphone NAT policy into the selected media path

The Linphone ICE, STUN and TURN guide separates effective NatPolicy, server discovery, candidate gathering, SDP delivery, connectivity checks, selected pair and audible media. Use the paired diagnostic when a relay is absent, never selected or selected without working media.

Prove the Linphone push chain beyond a feature claim

The Linphone push guide separates operating-system permission, Core state, account Contact parameters, proxy action, notification delivery, app wake and refreshed SIP reachability. Use the paired diagnostic when foreground calls work but one background state fails.

Verify local-data ownership before a restore

The Linphone local-data guide keeps the current 6.2.3 package separate from the project’s older 4.2 and 4.3 file-layout references. Use the paired diagnostic when history, contacts or settings disappear after an update.