Identify the exact Acrobits product
Acrobits Softphone is the vendor’s retail SIP client for Android and iOS. It is not a VoIP service, and the vendor says there is no native Windows or macOS version of this retail app. A user still needs a compatible SIP account from a provider or PBX. Keep this record separate from Groundwire, the more feature-rich retail client, and from Cloud Softphone, the managed and white-label product family.
The vendor’s current comparison describes Softphone as the basic voice, video and messaging option, while assigning advanced business call management to Groundwire. Confirm the exact store listing, operating system, build and entitlement before making a workflow promise. Shared branding, a common SIP core or a similar settings page does not establish identical transfer, conference, voicemail or administrative capabilities.
Map account setup and administrative control
The documented initial setup asks the user to choose a listed provider or enter a SIP username, password and domain, then exposes account-specific transport, proxy, NAT, codec and incoming-call settings. A green service icon represents registration state, not a completed inbound or outbound call test. Multiple configured accounts remain separate identities and routing paths.
This retail workflow does not establish Cloud Softphone fleet provisioning, branded configuration or an administrative portal. Record who creates the SIP credentials, how configuration reaches the handset, where secrets are stored, and how a lost device or departing user is revoked. Test deletion and replacement rather than assuming removal from the phone invalidates the server credential or its SIPIS copy.
Keep signaling and media controls separate
The Softphone security page exposes TLS for signaling plus separate SDES-SRTP, ZRTP and DTLS-related media controls. These choices must match the SIP service, certificate handling and negotiated call leg. A visible control, an optional ZRTP entitlement or a secure-marketing statement is not evidence that a provider accepts the mode or that a call used it.
Define the required failure behavior before deployment. If encrypted signaling or media is mandatory, confirm that an authorized incompatible test fails instead of silently falling back. A protected mobile-to-PBX leg does not prove protection beyond the PBX. TURN can relay media through symmetric NAT but does not establish registration, confidentiality or peer identity. Device screen lock, application access and exported SIP logs remain separate data-protection controls.
Choose push or standard registration deliberately
Acrobits documents that push mode registers the SIP account on its SIP Instance Server, SIPIS, while the app is backgrounded or closed. SIPIS receives the INVITE, triggers the platform notification and participates in the signaling path after answer; the vendor describes media as going directly to the device. That creates service, credential and metadata trust outside the sleeping handset.
Standard mode keeps registration on the device and is the documented alternative for provider restrictions, private-network reachability, a VPN or special security requirements. Global and per-account incoming-call settings can differ. Record the selected mode, permitted registration sources, credential scope and revocation path, then test locked-screen delivery, app termination, reboot, Wi-Fi and mobile data separately. A registered SIPIS account does not prove notification delivery or usable audio.
Control iOS Web Access and recording exports
Acrobits documents an optional iOS Web Access feature for both retail clients. When enabled, a browser on the same Wi-Fi network can view call history and download recorded calls while the app is open and the device remains awake. This is a local administrative and data-export surface, not a call-media transport or a cloud retention service. Do not expose it on an untrusted or shared network.
The first-party instructions identify admin and 1234 as the documented default credentials and describe changing the password as optional. Treat replacement of that default as mandatory before enabling the feature, use a device-specific secret, limit the activation window, and turn Web Access off after the authorized export. Confirm the listener is no longer reachable. A recording control, a created recording, a browser-visible history row, a downloaded file, a device backup and a retained business record are separate states. Define recording authorization, notice, storage, access, retention and deletion with the responsible policy owner for the applicable location; do not infer legal permission from an application feature.
Run a bounded mobile pilot
Record the app build, operating system, device, SIP service and network for every observation. Verify registration, inbound and outbound calling, two-way audio, DTMF, required video or messaging, network changes, background delivery and hangup. On iOS, Acrobits documents CallKit coordination with native calls; Android integration varies by handset, so test interruption, switching and audio focus separately. SIP SIMPLE messaging still depends on provider support and does not inherit reliability, retention or push behavior from voice registration.
Test emergency location and permitted destinations through the provider-approved procedure rather than placing an ordinary call and inferring emergency behavior. Compare Softphone with Groundwire only on required workflows and current documentation. Do not infer transfer, conference, voicemail, fleet administration, battery performance, interoperability, availability or commercial terms from the shared vendor. No Acrobits Softphone app, SIPIS service, PBX, provider, device, registration, notification, protected-media leg, message or call was tested for this guide.
Product: Acrobits Softphone
App build / OS / device:
SIP provider or PBX:
Registration mode: Push (SIPIS) or Standard
Signaling / media policy:
Inbound, outbound and background-call observations:
Network-change observation:
Revocation and rollback result:Do not apply Cloud Softphone administration to this retail client
The Cloud Softphone platform guide covers Cloud IDs, Live and Editable portal versions, external Account XML and white-label release boundaries. Those controls do not establish fleet administration for this retail Acrobits Softphone app, even where both products use SIPIS.
Keep device removal separate from registration revocation
If a removed or wrong handset still reacts to calls, use the Acrobits device-lifecycle diagnostic. Deleting a local account, removing a PBX contact, cleaning a SIPIS instance and revoking a shared credential are distinct actions with different evidence and rollback.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Acrobits Softphone user guide ↗
- Acrobits Softphone initial SIP-account setup ↗
- Acrobits Softphone security settings ↗
- Acrobits push-notification architecture ↗
- Acrobits push and standard registration modes ↗
- Acrobits incoming-call mode settings ↗
- Acrobits iOS CallKit and Android call integration boundary ↗
- Acrobits TURN media-relay guidance ↗
- Acrobits SIP SIMPLE messaging setup ↗
- Acrobits Softphone and Groundwire differences ↗
- Acrobits retail-app platform boundary ↗
- Acrobits iOS Web Access for history and recording export ↗
- 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 ↗
- Acrobits SIPIS incoming-call handling ↗
- Acrobits SIPIS push-status indication ↗
- Acrobits SIPIS instance cleanup ↗
- Groundwire incoming-call settings ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.