Identify the platform and release artifact
Cloud Softphone is Acrobits' configurable application platform for generic and white-label apps. It is not the retail Acrobits Softphone or Groundwire app, a SIP service, or proof that a provider's PBX is compatible. Record the Cloud ID, generic or white-label product, store or distribution channel, app build, operating system, enabled feature set and SIP service before comparing behavior.
The Cloud ID is mandatory for provisioning. The generic app receives it as input, while a white-label build has it embedded. The portal can expose a production Live version and a separate Editable version; Acrobits documents the * suffix as the way to request Editable for testing. A result from Editable does not prove that production users received the same configuration.
Trace provisioning in merge order
On first launch, the documented sequence obtains base provisioning and graphics from the Cloud Softphone portal, then can call global external provisioning and account external provisioning. The provider's account service returns Account XML that is merged with portal defaults and can supply user-specific SIP credentials, codecs, messaging and other settings. Record every layer, response status, revision and timestamp before interpreting the final runtime.
Initial external provisioning receives first-screen inputs. Re-provisioning uses values already stored in Account XML and requires the documented %account[...]% placeholders rather than the initial %username% and %password% placeholders. A 200 OK with Account XML is merged; 304 Not Modified, a disabled interval, an open Settings page or an active call can produce different timing. A successful web request is not proof that the intended value won the merge or was applied.
Keep identity, credentials and domain ownership explicit
Treat the Cloud ID, application login, SIP username and password, install identifier, tenant or network identifier and device push token as distinct data. External provisioning can exchange sensitive inputs and return SIP credentials; restrict transport, logs, retention and operator access, rotate exposed values and prove server-side revocation. Do not publish a real Account XML response or provisioning URL containing reusable data.
The SIP host is also product- and entitlement-dependent. Acrobits says arbitrary hosts through Account XML require Open White Label, while the unlimited-subdomains option is restricted to the configured suffix; otherwise the portal's configured domain remains authoritative. A <host> element in a response is therefore not proof that the installed app can or did use it.
Separate push signaling from media
SIPIS maintains registration on behalf of a backgrounded mobile device, receives an inbound call, wakes the app through the platform notification service and relays SIP signaling after the app is ready. Acrobits states that SIP signaling always traverses SIPIS while RTP media does not. Record SIPIS ownership, registration source, push enrollment, APNs or Firebase delivery, wake-up, the app-to-SIPIS dialog and negotiated media as separate evidence.
A green foreground registration does not prove locked-screen delivery. A delivered notification does not prove that the app re-established signaling, answered, or received two-way media. Likewise, TLS on a signaling hop does not prove SRTP on the media path. Account XML exposes multiple incoming-call and secure-call controls; confirm the effective app settings and the failed behavior of an incompatible authorized test when protection is required.
Control change, promotion and rollback
Acrobits says most SIP-server, dialing, voicemail, messaging, push, Quick Dial and Dial Action changes can arrive through provisioning after a refresh or reprovision. Some branding, white-label option and platform changes may require a rebuild and mobile store review. Test the Editable copy on a dedicated account and device, preserve the previous Live revision, promote only the accepted change and verify both a target and a negative-control user.
The provisioning-update command triggers complete reprovisioning, while extprov-update requests only the external layer. Their availability does not authorize arbitrary external links or prove completion. Use an app-owned control or documented support path, confirm the resulting values and remove temporary diagnostics.
Run an acceptance test without overclaiming
For one authorized pilot, capture first activation, reprovision, restart, foreground and locked-screen registration, inbound and outbound calls, hangup, two-way audio, DTMF, network change and credential revocation. Include the exact app build, Live or Editable state, Cloud ID form, account, device, network, portal revision and external-service revision.
Confirm emergency calling and location only through the SIP provider's approved procedure. Do not infer feature availability, scale, battery life, store approval, PBX interoperability, support response or commercial terms from documentation. No Cloud Softphone deployment, account, push path, protected session, media stream, device or call was tested for this guide.
Product / generic or white-label build:
Cloud ID form / Live or Editable:
App build / OS / device:
Portal revision / external-service revision:
Final effective SIP host and account mode:
Push, signaling and media observations:
Revocation / rollback result: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.