Phone provisioning succeeds but settings stay wrong

Define one device and one wrong setting

Record the exact model, hardware revision, firmware, MAC address, extension, template, provisioning address and protocol. Name one harmless expected field and the value actually visible after a controlled refresh or reboot. A green registration state or successful call does not prove that the intended configuration file was selected, parsed or activated.

Build a timestamped chain: discovery or configured URL, DNS result, network connection, file request, HTTP/TFTP/FTP response, returned bytes, parser or device log, activation event and resulting field. Stop at the first unproven state. A server log showing a 200 response proves delivery of that response, not that it contained the right device file or that the phone accepted it.

Discovery, authority and applied configuration

Follow EPM ownership from MAC to artifact

Sangoma separates Global Settings, brand templates, Extension Mapping, model-specific settings, Basefile Edit, custom extensions and firmware slots. Extension Mapping ties a MAC address and extension to the template used to build files; the template carries the destination and provisioning addresses and model choices. Confirm that exact chain instead of editing a similarly named template.

Record the requested filename and compare its generated content with the mapped extension and model. A yellow mapping, saved template, rebuilt file, pushed resync and phone reboot are separate states. EPM's global resync interval can cause a later fetch, so capture whether the device changes immediately and whether that value survives the next scheduled synchronization.

Separate delivery, parsing and activation

Preserve the response status, content type, byte count and a secret-redacted digest of the retrieved file. A captive-portal page, login form or generic default returned with an apparently successful HTTP code is not a valid configuration. Compare syntax and parameter names with the exact model and installed firmware; a key supported by a sibling model or later image can be silently ignored.

Use one harmless, reversible visible marker where the manufacturer supports it. Distinguish file accepted, settings staged, phone resynced, phone rebooted and field active. Do not factory-reset first: a reset can erase useful evidence and simply repeat the same wrong mapping, redirect or cloud owner.

Keep support, certification and firmware scope explicit

Sangoma's device table distinguishes certified from non-certified manufacturers and tested from not-tested models. A model present in EPM can therefore have only generated configuration support without a laboratory provisioning result or guaranteed support. Phone Apps support is also a separate matrix. Record the exact row and any firmware or manual-upload note before treating EPM presence as compatibility.

EPM's firmware management can assign Recommended, Slot 0, Slot 1 or Slot 2 by template. The administrator guide says Recommended is a version Sangoma tested, not proof that all features work or that the firmware is bug-free. Compare the device's installed image, assigned slot, retrieved artifact and completed upgrade separately; retain the vendor-supported recovery path before changing firmware.

Find the later writer

If the controlled marker appears and later disappears, correlate the time with EPM resync, a PBX manager rebuild, DHCP or redirect service, vendor cloud, local administrator, phone import or another provisioning server. Identify one authoritative owner for each field. Do not run OSS and commercial EPM together: Sangoma states that their different base configuration files interfere.

Basefile Edit is an advanced override layer, and Sangoma recommends using it with support guidance. A value emitted there can defeat a normal template change. Inspect only the relevant keys in a restricted workspace because generated files can contain SIP passwords, administrator credentials, internal addresses and certificate material. Never paste a complete configuration into a public ticket or forum.

Prove the repaired lifecycle

After correcting the demonstrated owner, regenerate the artifact and retain a redacted before-and-after comparison. Prove the harmless marker, account identity, registration, inbound and outbound calls, DTMF, transfer or monitored keys when required, certificate or VLAN policy and firmware state. Repeat after scheduled resync, reboot and a server or credential change.

Remove the marker and temporary logging, confirm the retired owner no longer writes the field and document rollback. Do not declare success from registration alone. No PBX, EPM module, template, basefile, phone, file, credential, firmware, network path, registration or call was inspected or tested for this guide.

Follow the FreePBX-specific state chain

When a mapped FreePBX phone fetches an old or wrong value, use the Endpoint Manager diagnostic. It checks the MAC mapping, selected template, generated artifact, discovery owner, server request and device runtime before a reset or firmware change.

Use the application-specific Linphone branch

Linphone's XML path has its own focused diagnostic: the URL is selected in the application or carried by a QR code, configuration applies at a startup boundary, and overwrite and transient flags control whether a value changes or returns. Keep it separate from MAC-addressed desk-phone templates.

Do not collapse GRP2624 Wi-Fi state into provisioning state

The GRP2624 Wi-Fi diagnostic proves hardware, association and IP service before checking the authoritative provisioning URL, certificate state, delivered configuration, SIP registration and calls.