Linphone remote provisioning: lifecycle, precedence and effective configuration

Inventory every configuration owner before changing a value

Record the exact Linphone application, Liblinphone version, operating system, package or store channel, user profile, configured accounts and provisioning entry method. Then identify each possible owner: application defaults, factory configuration, local linphonerc, mobile-device-management payload, inline managed XML, remote configuration URI, provisioning link or QR code, and a later user change.

These are not interchangeable delivery paths. A QR code can carry a URL, Android MDM can supply inline XML and a separate configUri, and desktop URI handlers can request a fetch. A value visible in the interface is effective state, not proof of which source last wrote it.

Distinguish the saved URI from a completed retrieval

Liblinphone 5.5 documents linphone_core_set_provisioning_uri() as saving a URI for retrieval during the next Core start. A parse-success return does not validate the endpoint or prove a later download. The Core can pass through a configuring state, and the configuring-status callback distinguishes disabled or skipped processing from a completed or failed attempt.

Preserve one timestamped transaction: selected URI, Core start, DNS and trust result, request, redirects, authentication, response status, content type, body revision, configuring state and error. A scanned QR code, accepted link or stored URI is only the beginning of that chain.

Resolve delivery-path precedence before reading the XML

The Android MDM reference says an inline xmlConfig is loaded first, while a separate configUri takes priority when both are present; a config-uri inside the inline XML is followed on the next Core start. Desktop also documents linphone-fetch-config as a URL handler that fetches and applies a remote configuration immediately.

Record which path was actually invoked and its timing. Do not generalize immediate desktop-handler behavior to a saved Core provisioning URI, or assume that an inline managed value remains final when a higher-priority remote URI is configured.

Apply merge, overwrite and one-time rules deliberately

Linphone remote provisioning maps an XML document onto its INI-style configuration. The documented desktop conversion tool does not overwrite existing keys by default; entries that must replace existing values need overwrite="true". Separately, transient_provisioning=1 makes the remote changes a one-time application instead of reapplying them at every start.

Test first start, later restart and an authorized local edit as separate cases. A value that never changes, changes once or returns on every launch can have different owners. Use a minimal file and retain the previous revision so a configuration mistake can be rolled back without rotating unrelated credentials.

Treat keys, credentials and provisioning links as versioned secrets

The current Liblinphone 5.5 key reference is explicitly under construction and not an exhaustive application contract. Confirm each target key against the exact client or SDK build, and keep legacy section names such as proxy_N separate from the newer account objects they configure.

Provisioning documents and URLs can contain account material, authentication headers or bearer-like tokens. Linphone documents OAuth2 or OpenID Connect support for provisioning and SIP starting with version 6.0.0, while the Linphone service API exposes tokenized provisioning endpoints and optional password-reset behavior. Protect links, headers, QR images and XML as credentials; do not paste them into public tickets or analytics.

Verify effective configuration and service behavior as later stages

After a successful configuring result, read the effective runtime account, transport, codecs, directory and feature settings from the affected build. Then verify registration, authorized inbound and outbound calling, media, push or messaging only where those capabilities are required and the selected SIP service supports them.

A downloaded XML file does not prove a key was supported, an overwritten key does not prove registration, and registration does not prove calling or background delivery. Acceptance should identify source, revision, merge result, effective value and the separate service outcome. No application, provisioning service, account, packet, media stream or call was inspected or tested.

Bind provisioning precedence to the 6.2.4 profile

The Linphone guide retains XML overwrite attributes, next-start timing and URI-handler input separately from the effective account and runtime value.