Freeze one stale value
Choose one authorized user, device and setting. Record the expected value, observed value, app build, Cloud ID form, Live or Editable target, portal revision, account identity, external-service revision, last known refresh and first failure time. State whether the problem began at activation, after a portal edit, after an external-service edit or after promotion.
Do not change several layers at once. A working SIP registration does not prove the intended codec, push, messaging, dial rule or host reached the application.
Prove the selected portal version
Confirm whether the device requested Live or Editable. For the generic application, preserve the entered Cloud ID without exposing credentials; for a white-label app, verify the build's embedded ID and distribution channel. Compare the exact property in the portal version expected for that device.
If only Editable contains the change, promotion is a release decision rather than a transport repair. If Live contains it, continue through delivery and merge evidence before rebuilding the application.
Walk the merge in order
Capture sanitized evidence for base portal provisioning, global external provisioning and account external provisioning. Check response status, content type, the single Account XML root, revision and final precedence for the stale property. During re-provisioning, verify that the service uses %account[...]% values; the initial placeholders do not expand there.
Check whether the service returned 304 Not Modified, whether the external interval is zero, and whether Settings was open or a call was active when the update arrived. A valid response can still lose to a higher-priority value or wait before application.
Trigger the narrow refresh and observe application
Use the documented in-app or provider-controlled refresh. A full provisioning-update and external-only extprov-update have different scopes; record which one ran and when. Observe the next request, response, merge and effective setting rather than treating the command invocation as success.
If the stale symptom concerns incoming calls, keep configuration delivery separate from SIPIS registration, platform push delivery, application wake-up and the subsequent signaling dialog. Use the background-ringing diagnostic when the value is current but locked-screen calls still fail.
Correct one owner and test rollback
Change only the demonstrated owner: publish the accepted Live revision, correct one portal default, fix one external response or placeholder, enable the intended refresh interval, or wait for the documented safe application point. Do not add an arbitrary host when the selected product does not permit it.
Repeat the target case and one user that must retain the old value, then restart the app and recheck registration and a provider-approved call path. Revoke exposed test credentials, remove sensitive captures and keep the prior configuration available for rollback. No portal, application, provisioning service, account, credential, SIPIS path, device or call was tested for this diagnostic.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Acrobits Cloud Softphone provisioning introduction ↗
- Acrobits provisioning input parameters and Live/Editable versions ↗
- Acrobits external provisioning workflow ↗
- Acrobits Cloud Softphone Account XML reference ↗
- Acrobits Cloud Softphone command URIs ↗
- Acrobits SIP Instance Server architecture ↗
- Acrobits published-app configuration changes ↗
- Acrobits external-provisioning domain boundary ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.