Skip to main content

Provisioning Config Preview

Super admins can render the configuration a deskphone or DECT base would receive — without the device touching the live provisioning endpoint, and without polluting any of the device's persisted state.

This is the engineer-safe replacement for curling a device's provisioning URL during triage. The live provisioning path updates last_provisioned_at, captures the caller's IP, and on first contact persists the auto-detected model. The preview path does none of that.

Where to find it​

Open the device's detail page in the admin portal. A Provisioning config card appears at the bottom of the page for super admins only. The card is hidden for platform admins and account admins.

The card is shown for deskphones and DECT bases. Handsets do not have an independent config — their configuration is part of the base's payload.

What you see​

Click Preview to render the current configuration. The result includes:

  • The raw bytes the device would download, shown in a monospace viewer with copy and download actions.
  • Diagnostic badges: vendor, stored model, detected model, and which User-Agent the preview used.
  • A warning panel that shows anything a real phone hit on the live URL would have changed, including:
    • The model that would be persisted on first provisioning.
    • The handsets a DECT base hit would transition to provisioned.
    • Any other advisories (synthetic User-Agent in use, vendor mismatch, etc).

The preview itself never writes any of these changes — the warnings describe what live provisioning would do, so you can decide whether you want to trigger a real download from the device or not.

User-Agent override​

By default, the preview uses a synthesized User-Agent built from the device's stored vendor and model. That UA always advertises a current firmware version, so firmware step-upgrade or force-upgrade paths a real older-firmware phone would hit are not visible in the default preview. The card displays a synthetic UA warning in that case.

If you need to reproduce what a phone on a specific firmware version sees, type the observed User-Agent (e.g. snom M500/1.14.4) into the User-Agent override field before clicking Preview. Override mode is what makes the preview byte-accurate for firmware-sensitive debugging.

SIP credentials in the response​

The configuration body contains SIP authentication material in cleartext (that is what the phone needs to register). Treat the preview output like any other credential:

  • The admin portal sends the response with Cache-Control: no-store, so browsers and intermediaries do not retain it.
  • Do not paste the raw config into shared chat threads, public docs, or ticket attachments without redacting the credentials first.
  • Closing the card clears the in-memory preview; refreshing the page does not restore it.

Audit trail​

Every preview generates a provisioning_config.previewed audit log row attributed to your admin user, with the device ID, the User-Agent used, and the warning set. Search the audit log on the account if you need to retrieve a list of past previews.