Linphone provisioning link is ignored, stale or overwrites the wrong settings

Freeze one build, one configuration owner and one wrong value

Record the exact client and Liblinphone version, operating system, package, user profile, affected account, expected value, observed value and first failure time. Preserve whether the value never changes, changes only once, returns at every start or is replaced after managed-policy refresh.

List all possible owners before editing: defaults, factory configuration, local file, MDM inline XML, MDM configUri, stored provisioning URI, desktop fetch handler, QR or link, and user action. Do not clear application data or re-enroll the device until the failing source and current effective state are preserved.

Prove which URI path ran and when it ran

For a stored Core provisioning URI, reproduce the next Core start and capture configuring state, request and response. For desktop linphone-fetch-config, preserve that immediate handler invocation. For Android MDM, determine whether inline XML, a separate configUri or a nested config-uri is in control and whether another Core start is required.

A valid-looking URL, successful QR scan or URI parse is not a completed fetch. Preserve sanitized DNS, certificate, redirect, authentication, status, content type, revision and error evidence without disclosing the full URL, token, header or XML.

Validate the returned document and supported key

Confirm the response is the intended Linphone XML rather than a sign-in page, stale cache object, proxy error or another user’s document. Check XML namespace and structure, exact section, entry name and value, then verify that the exact application or SDK build supports that key.

The current Liblinphone provisioning-key page warns that its inventory is incomplete. Absence from the page is not automatically proof that a client rejects a key, while presence is not proof that every distributed app exposes or honors it identically. Use a harmless observable value to isolate parsing before changing account secrets.

Test precedence, overwrite and transient behavior independently

If Android MDM supplies both inline XML and configUri, verify the documented order: inline content first and the separate remote URI taking priority. If the document reaches the client but an old value remains, check whether the entry needs overwrite="true". If a value applies once but does not return, inspect transient_provisioning=1.

Run a bounded matrix across initial application, next restart and one local edit. Do not add overwrite flags to every key or disable transient behavior globally as a diagnostic shortcut; either change can replace valid user, account or security state beyond the reported symptom.

Separate authentication failure from configuration failure

Preserve whether the provisioning endpoint expects ordinary web authentication, added headers, an account-manager token or OAuth2/OpenID Connect. Linphone documents OAuth2 provisioning support starting with version 6.0.0, so an older client, wrong redirect setup or expired token can fail before XML parsing.

Treat a tokenized provisioning link or QR image as credential material. If exposure is suspected, revoke or rotate it at the issuing service. Removing the local account, shortening a screenshot or changing the XML does not invalidate a server-side token or reset action.

Correct the first owner and verify runtime plus service outcome

Correct only the first demonstrated layer: configuration source, precedence, restart boundary, network or trust path, authentication, cache revision, XML structure, supported key, overwrite rule or transient rule. Then capture a clean configuring result and read the effective runtime value.

Verify registration, calling, media, push or messaging separately where required. A successful configuration fetch does not prove any SIP outcome, and a working call does not prove every managed setting is current. No Linphone build, device, MDM policy, provisioning service, account, packet, media stream or call was inspected or tested.

Verify the effective provisioned account before registration

The Linphone registration diagnostic starts from effective AccountParams so provisioning and registrar failures are not conflated.

Check the 6.2.4 profile before declaring XML ignored

The post-update diagnostic proves user, executable, URL, downloaded XML, overwrite flags and next-start application before a local restore.