Linphone remote provisioning downloads but settings stay wrong

Freeze one client and one wrong value

Record the Linphone platform, exact app build, operating-system version, provisioning-entry method, sanitized URL, expected value, observed value and first failure time. State whether this is first enrollment, a changed file, a replaced device or a value that returns after a restart. Preserve the current account list without exposing SIP or web credentials.

Do not use successful registration as proof that the XML was fetched or applied. Conversely, a correct codec, transport or DSCP value does not prove that account authentication, inbound calling, media or mobile background delivery works.

Prove the selected URL and restart boundary

Linphone's reference says supported Android, iOS and desktop clients download XML configuration from a provisioning URL and apply it at the next application start; the account wizard can restart the application automatically. Reproduce with one controlled start and correlate the exact URL, request time, response status, content type and returned revision. A QR code carries the URL; scanning it is not delivery evidence.

Use an authorized endpoint and a sanitized server record. Confirm name resolution, certificate and trust behavior when HTTPS is used, redirects, authentication and reachability from the affected device. Do not publish a credential-bearing URL or XML file in a ticket or capture.

Validate the returned XML before changing the account

Retain a redacted copy and prove that the response is the intended Linphone XML rather than a sign-in page, proxy error, stale cache object or another user's document. Check the XML structure, target section, entry name and value against the deployed client. Linphone notes that many internal configuration keys are not officially documented, so an attractive but unsupported key is not an acceptance contract.

Minimize the file to the required changes. The reference recommends including only entries that differ from defaults. Test a harmless visible or inspectable value first; do not rotate SIP credentials merely because the configuration document was malformed or the wrong revision was served.

Resolve overwrite and one-time application separately

The documented desktop conversion tool produces XML entries that do not overwrite existing keys by default; an entry needs overwrite="true" when the existing value must be replaced. Separately, transient_provisioning=1 applies provisioning changes only once rather than at every start. Determine which behavior the deployed XML requests and compare first start, the next start and a deliberate local change.

Also distinguish app defaults that apply on first launch from factory settings that can be applied at every launch in a custom package. A value that returns can therefore have a different owner than a value that never changed. Change only the demonstrated owner and keep the previous file revision available for rollback.

Accept configuration, account and calling as separate stages

After the intended XML value survives the required restart behavior, verify that the expected SIP identity and transport are loaded, then check registration, an authorized inbound and outbound call, two-way media, hangup and any required transfer or messaging behavior. Current Linphone guidance warns that some conferencing and group-chat features require a Linphone account; a third-party SIP account does not inherit them through provisioning.

Revoke any exposed temporary credential, remove diagnostic logging and repeat one negative case such as a retired URL or unauthorized device. No Linphone application, provisioning service, account, registration or call was tested for this diagnostic.

Check whether the expected local database belongs to this build

When provisioned values and visible data disagree, use the Linphone local-data guide to prove the package, user profile and effective files before changing XML or credentials.