Push Notifications allow you to receive calls or messages when the app is in the background or closed while using almost no battery. When the app goes to the background, or is closed completely, Acrobits’ SIPIS server will register the SIP account and will start listening for incoming calls. Any incoming call or message will then come to the server, allowing the app to sleep, consuming no battery power. When an incoming event is received, SIPIS wakes up the app by using Apple Push Notification Service (APNS) or Google Cloud Messaging (GCM) service. The user can then accept the incoming call as if it came to the device itself.
SIPIS server was designed to be compatible with all SIP proxies that follow SIP standards, no additional changes are required on the provider side. Turning the option on should be all that’s needed to make Push Notifications work with your service.
In order to be able to use Push Notifications, Acrobits’ SIPIS server must be able to register for incoming calls and therefore needs to know the user’s SIP credentials. These credentials are transferred over an encrypted connection and stored securely at the time Push Notifications are enabled. When the user disables Push Notifications or deletes the account completely, the SIP credentials are immediately deleted. In case we don’t hear from the device for over 7 days (which may happen if the device was destroyed, the user did a full reset or if the user didn’t open the app at least once within these 7 days), the credentials are deleted as well and push notifications disabled.
The security issues with storing of SIP user credentials can be eliminated by installing SIPIS server on premises of the VoIP provider. If you host your own SIPIS server for your customers, having access to their SIP credentials is not an issue, since you control the whole security chain anyway. Using External Provisioning also lets you create SIP username & passwords for your users and provision their app without giving them these details. By combining these features, Push Notifications can be made 100 % secure.
SIPIS servers are components which make Push Notifications work. They register SIP accounts and listen for incoming calls when the mobile app is not running. Acrobits hosts a cloud of SIPIS servers, which are immediately available and all you have to do to use them is to turn the feature on.
The design of Push Notification mechanism requires that SIPIS server knows SIP credentials of users. In case of security concerns, you can decide to host your own SIPIS server. We will provide SIPIS binary packages for Debian Linux, with some effort it should be possible to install it on other Linux distributions as well. You can then install, configure and maintain your own SIPIS server for your users. Post a comment under your app if you need help with setup.
With “normal” provisioning, the user enters SIP username and SIP password during provisioning (either by scanning a QR code or by entering them manually). External provisioning allows you to define a web service, which provides the actual SIP credentials. When the user enters “username” and “password”, this web service is called and passes this information as parameters. The web service then returns “SIP username” and “SIP password” (the real SIP credentials), which are then used for SIP registration. Example: You can have a user “alice” with password “12345” and assign it a SIP extension with SIP username “1001” and SIP password “54321”.
The user will not be able to see the actual SIP credentials, so you can also use external provisioning to prevent your users from knowing their SIP credentials, preventing them from using them with other SIP clients or devices.
External provisioning also gives you more control over the provisioning process. You can also provision other information, for example set the account title on per-user basis, enable/disable some features for specific users etc.
Due to the fact that sensitive information like passwords are transferred, the web service is required to use https: URI scheme, with a valid SSL certificate.
Detailed information on configuring external provisioning is available in the cloud softphone web portal in the provisioning options once you sign up for external provisioning in the features section. This can be tested (like all Cloud Softphone features) before spending a dime on the cloud softphone.
- Push Notifications
We will send Push Notifications on incoming calls allowing the app to sleep in the background or even be closed completely and still be able to receive calls. This option is the most battery efficient if you want to always be available for calls.
- Keep Device Awake
The application is always running and registered, even in the background. The device is prevented from sleeping. This option is most demanding on the battery life.
The application will sleep in the background and will only awake for significant events (e.g. incoming calls, reregistering, network changes etc.) This option requires the provider to use TCP as a transport protocol and the registration period must be 600 seconds or longer. This option is not as battery efficient as Push Notifications but much better than Keep Device Awake. But if you support TCP (or TLS), this may still be your preferred option since it does not rely on SIPIS for incoming call notifications.
- Foreground Only
The app will only register and receive calls when in the foreground.
- Push Notifications
We will send Push Notifications on incoming calls allowing the app to sleep in the background or even be closed completely and still be able to receive calls. This option is the most battery efficient if you want to always be available for calls.</dd>
- Keep Device Awake
The application is always running and registered, even in the background. The device is allowed some sleep but is waken up periodically. This option is most demanding on the battery life.
- Foreground Only
The app will only register and receive calls when in the foreground.
Cloud Softphone comes with a default, neutral graphics theme. If you provide your own graphics assets, they will replace the default ones. The logo image is shown in Settings, on the page where the user can edit SIP account details. This is the only piece of graphics which needs to be provided by you, you can keep the rest of the graphics default.
As for the SIP parameter customization, this depends on how many features you want to have enabled for your app. In the simple case, you should only need to provide the SIP domain.
No. Your users will download the “Cloud Softphone” application from the App Store and Google Play. Only after provisioning, either via QR code or by entering the Cloud Id, username and password manually, will the graphics design and provisioning options be downloaded and the app branded for your service.
You can customize most of the graphics in our web-based GUI editor. The elements which can’t be changed are: the application name (“Cloud Softphone”), icon and splash (login) screen.
In case you want to have your own application in App Store or Google Play, we have a white-label program which does exactly that. If you already have a Cloud Softphone application, we’ll deduct the Cloud Softphone setup fee from the white-label price. For more info please contact us at email@example.com
After the app is approved, it will change its state to “Live”. You are not allowed to make any changes to Live applications, it has to stay exactly as it was approved. However you can create an editable copy of this Live application and make your changes there. You can also test the changes you’ve made in the mobile devices by provisioning the apps using “EXAMPLE” QR codes or by entering your Cloud Id followed by an “*” (asterisk).
After you’re done with your changes, submit the app for review again. After it’s approved, the previously Live version is replaced by your new settings and all your users will be automatically updated. The app checks for a new update upon startup and then once every hour; in case an update is available, the new settings will be automatically applied, no user intervention is needed. Basic changes to settings or theme changes are done at no cost, only adding paid features that you didn’t have before will require any additional payments.
All features of your app can be fully tested before payment on both iOS and Android devices. Before you submit the app for review, you can use the QR codes with “EXAMPLE” stamps printed over them (they will be auto-generated when you fill in the test account information) or you can manually enter the Cloud Id of your app followed by an “*” (asterisk). For example, if your Cloud ID is “VOIP”, you can enter “VOIP*” to load the draft, editable version of your provisioning settings onto your device and test it.
The only limitation of the draft, “testing” version of your provisioning settings is the call duration, which is limited to 40 seconds. After 40 seconds, the call will be terminated and and an explanatory message shown.
We want to make sure that Cloud Softphone apps are configured correctly, work reliably with the provider’s backend and offer a great customer experience. Our review team can often spot minor issues that are easy to fix and possibly suggest improvements.
During review, we’ll scan through the app, make sure that provisioning works correctly and try to make a few short test calls between the two test accounts and/or to a landline number, to make sure codecs, NAT traversal and other components are working properly. In case your app can’t be tested like this (e.g. you are using a private PBX which is not accessible from the outside), drop us a note in the comments section at the bottom of the app page after you submit the app for review. We’ll just test what we can and leave the detailed testing to you.
The review process should typically not take more than 24 hours (business days only).
The QR codes are defined by standard and anyone can create them, you don’t need our help. We have a specific format for messages stored in the QR codes.
There are several options how to create your QR codes, which one to use depends on your needs:
If you only need QR code for your Cloud ID and don’t want to use username & password provisioning via QR code, you can simply download the QR code visible on your app detail page, in the “Download to device” box.
We provide a simple form which creates Cloud Softphone-branded QR codes. If you need a quick way to create several QR codes, this is the best option. The drawbacks are that creating a large number of QR codes will be quite inconvenient and in case you use QR codes with username & password, you’ll be sending them (over encrypted connection) to Acrobits server.
Use one of the many free online QR codes generators. They will do the job as well, but the QR codes won’t be Cloud Softphone-branded. Same drawbacks apply as in the previous point.
If you wish to create QR codes in your premises, you’ll need some QR code generator and probably some script which will get the usernames or passwords and use them in the process. There are many good libraries for various programming languages, for example
qrcodefor Python and many others.
There are also some apps for both Mac and Windows that can generate QR codes. Search the App Stores.
We have created a free PHP library which can create Cloud Softphone-branded QR codes. Post a comment under your app for more information.
There are two ways to enable support for G.729 codec in the app:
- in-app purchase
The codec will be locked initially, but the user will be able to purchase the codec within the app. After the payment is completed, the codec will be unlocked. When using this option, there is no charge for the provider, end users pay the codec price.
- post-paid licensing
In this case, the codec is available and unlocked for all users of the app. Acrobits will count licenses for unique users who used the codec at least once in a given month and send an invoice to you at the end of that month. Unique users are determined by unique SIP usernames. When using this option, end users don’t have to pay anything and have the codec available without having to do anything; the provider pays the codec price.
Yes, we support secure calls via SRTP/SDES. We currently don’t offer ZRTP for Cloud Softphone, but it is available for white-label applications. If you are interested in details, contact us at firstname.lastname@example.org
Yes, you can distribute your application through Microsoft Store. However, a developer account is required to do so. Go to partner.microsoft.com for more information.
Yes, you can use Microsoft Intune and APPX distribution to distribute your Windows applications. APPX distribution is used for sideloading and it requires a developer account. Go to partner.microsoft.com for more information.
No, MSI distribution is not supported for native Windows apps because the MSI format is considered obsolete.
Yes, an executable (EXE) distribution method can be used to perform a bulk installation. To do so, use this command:
installer_name.exe /S /AllUsers /D=<path>
/Sinstalls the application silently without prompts.
/AllUsersinstalls the application for all users with access to the folder specified by
/Dspecifies the destination path where the application is installed.
Yes, and the supported headsets are as follows:
EPOS/Sennheiser - EPOS Connect software needs to be installed.
Poly (formerly Plantronics) - Requires the installation of Plantronics Hub. It is not recommended to run Plantronics Hub and Poly Lens simultaneously.
Jabra - No third party software is required.
Yealink - No third party software is required.