Pin the package before using a file-path reference
On October 18, 2026, Linphone’s official stable Windows application archive listed Linphone-6.2.3-win64.exe dated September 22, 2026 and pointed Linphone-latest.exe to the same timestamp. Record the platform, package name, release channel, retrieved artifact, signature result and running About version separately. A daily snapshot, SDK build, mobile store version or older Call Edition package is not the same desktop release.
The first-party desktop file-tree page says it is based on version 4.2, and the linphonerc page says it is based on 4.3. Preserve that limitation beside every path or filename taken from those pages. Use the running 6.2 process, its logs and observed filesystem access to confirm effective locations before copying, deleting or declaring state lost.
Separate application storage from configuration storage
The version-scoped file-tree reference places application data under ~/.local/share/linphone on Linux, ~/Library/Application Support/linphone on macOS and %LOCALAPPDATA%/linphone on Windows. It separately places configuration under ~/.config/linphone, ~/Library/Preferences/linphone/ and %LOCALAPPDATA%/linphone. Same-looking Windows roots do not make every file interchangeable.
Record the user profile, executable, process owner, package channel, resolved directories, file sizes, modification times, hashes and access controls. Roaming profiles, sandboxed packages, portable wrappers, distribution patches and later releases can change effective behavior; the legacy documentation is a hypothesis to test, not a universal 6.2 migration recipe.
Preserve each database and binary store independently
The file-tree page names call-history.db for call logs, friends.db for contacts, linphone.db as the main database and message-history.db as an older message store. It also lists separate avatars/, codecs/, logs/ and thumbnails/ directories. A visible empty history is therefore not proof that one database was deleted, and one recovered database is not proof that its schema matches the current build.
Freeze the original files before inspection. Do not open production SQLite files with a tool that may write journals or migrations. Use a copy, retain hashes and preserve database, WAL and shared-memory companions together when present. Treat contacts, call history, messages, attachments, thumbnails and credentials as different data classes with different retention and disclosure consequences.
Keep linphonerc, application preferences and provisioning distinct
The older desktop references identify linphonerc as SDK and application settings and linphone.conf as Qt application state. Remote provisioning downloads an XML representation that is applied to Linphone configuration, normally at the next start; the documented sample warns that it can overwrite proxy and authentication information. Local file presence, fetched XML, applied key, effective runtime value and SIP account object remain separate observations.
A value that returns after restart may come from a forced default, a repeated provisioning URL, a managed package or another user profile. Preserve the selected URL, retrieval result, content hash, supported key, transient-versus-repeated setting and next-start application before editing the SIP account. Treat the XML, QR or URL as deployment material that can direct credential-bearing configuration.
Collect support logs without turning them into a disclosure
Linphone’s support guidance asks for exact version, platform, operating system, reproduction steps and logs, and tells users not to provide passwords or other sensitive information. On desktop 6.x it directs users to Help, Troubleshooting, enable debug logs if necessary, clear them, reproduce the issue and use Share logs. That sequence can upload or link diagnostic material outside the organization.
Define an approved recipient, retention period and redaction step before sharing. Review SIP identities, phone numbers, IP addresses, domains, tokens, message content and unrelated calls. Preserve an internal original when authorized, but provide the smallest sanitized extract needed to reproduce the fault. An uploaded log link is not proof that the intended recipient accessed it or that the log contains the failing interval.
Pilot restore, restart and call behavior as separate stages
Restore only after the effective owner, schema and version are known. Start with a read-only inventory, create a rollback copy, and import or replace the minimum approved object. Then verify application start, account selection, registration, contacts, history, messages, audio devices and logs before placing an authorized inbound and outbound call.
Record DTMF, hold, transfer, two-way audio, restart, sleep or wake and the original failure separately. A recovered contact list does not prove call history, registration, protected media or future upgrade safety. No Linphone installation, update, local-data migration, provisioning run, support upload, interoperability result or live 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.
- Linphone stable Windows application archive ↗
- Linphone supported platforms and downloads ↗
- Linphone Desktop application files tree ↗
- Linphone Desktop linphonerc configuration reference ↗
- Linphone troubleshooting and support-log collection ↗
- Linphone remote provisioning ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.