Freeze one affected user and the exact installed build
Record the first affected launch, expected and visible data, operating system, signed-in user, package source, executable path, About version and whether the change followed update, migration, account deletion, provisioning or profile change. Preserve current directories and files read-only before reinstalling or clearing anything.
The stable archives list 6.2.4, but that does not prove it is installed. Compare with one approved unaffected profile or pre-change evidence without exposing other users.
Prove the profile and files the running process owns
Correlate process owner and executable with effective configuration and data locations using recent file activity, application logs and controlled restart evidence. Inventory configuration, databases, companions, logs and attachment folders with hashes and permissions.
The published file-tree page is based on desktop 4.2. A legacy file in its documented location is a lead, not proof that 6.2.4 opened it. Stop before merging databases when schema or journal ownership is uncertain.
Classify each missing object and any deletion event
Check account selection, configuration, contacts, call history, conversations, meetings and attachments independently. If an account was deleted, preserve the exact confirmation and compare the documented local-data classes with actual post-delete state.
Do not treat local account deletion as server erasure, SIP credential revocation or backup deletion. A working registration does not prove history or contacts, and a restored contact list does not prove account or media settings.
Resolve provisioning and URI-handler ownership
Preserve the provisioning URL, retrieval result, XML hash, supported key, overwrite attribute and next-start application. Record any linphone-fetch-config or other URI-handler action that preceded the change. Compare local edits with the effective value after one controlled restart.
If managed configuration owns the setting, correct the authorized source. Do not repeatedly edit the client, remove TLS or wipe the profile to hide a precedence problem.
Create a sanitized, bounded support reproduction
Use Help and Troubleshooting only after identifying the approved recipient. Clear logs, reproduce once, stop collection and review the original locally. Redact passwords, tokens, SIP identities, IP addresses, domains, message content and unrelated call records from the smallest useful extract.
A successful Share logs action proves neither that the right interval was captured nor that the upload is safe, retained or viewed.
Restore one proven object and repeat the original workflow
After proving build, profile, owner and schema, restore the minimum approved configuration or database from a verified copy with rollback. Never replace files while Linphone is writing them. Confirm startup, account selection, registration, contacts, history, conversations, meetings, devices and logging separately.
Then repeat the original authorized call, transfer, URI or provisioning workflow and another restart. No package, workstation, database, account deletion, provisioning source, PBX, log upload, packet 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 6.2 release overview ↗
- Linphone stable Windows application archive ↗
- Linphone stable macOS application archive ↗
- Linphone stable Linux application archive ↗
- Linphone Desktop application files tree ↗
- Linphone remote provisioning ↗
- Linphone troubleshooting and support-log collection ↗
- Linphone Desktop URI handlers ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.