Legacy PortaPhone mobile application

PortaPhone is a mobile SIP client for iOS and Android operating systems, powered by Acrobits and integrated with PortaSwitch. You can offer it as part of your service bundle and enable users from any country to sign up for the service with their smartphones. This way, you can extend your customer base and enlarge your market share. By using PortaPhone, you also save on purchasing hardware IP phones and their delivery to end users.

PortaPhone can be branded with a help of a dedicated web portal. You can customize the app and publish it on Google Play/Apple App Store under your own name as you have full control. Upload your logo, change the graphic design, manage the feature set available for customers, and you’re ready to launch your PortaPhone-based private-label mobile application.

PortaPhone supports app-to-app voice/video calls, instant messaging, off-net calls, SMS messaging, call recording, balance checkers, and customizable ringtones. It can be used with a Bluetooth headset.

Push notifications ensure that customers receive calls or messages while the app is running in the background (and uses very little battery) or isn’t launched.

You can offer PortaPhone to both corporate (cloud PBX) and individual users. Upon PortaPhone installation, users are authenticated using SMS or email. After an administrator creates accounts for corporate users, they can download the app and sign in using a one-time password received via email. Individual users who sign up using their mobile number receive a one-time password via SMS.

Users from all over the world can download PortaPhone from Google Play or the Apple App Store and sign up using their mobile number.

Let’s say John Doe downloads PortaPhone. On the sign-up page, he enters his mobile number, e.g., 12065552453, and the CAPTCHA code. PortaSIP sends John an SMS with a one-time password to authenticate John’s mobile number and prevent service abuse. PortaPhone communicates with the provisioning module in PortaBilling to verify the one-time password, create a SIP account, and provision it. John Doe can now make app-to-app calls and send instant messages.

1. When a user signs up for the app using their mobile number, their account in PortaBilling is automatically provisioned with a DID number (that serves as an account ID) that is associated with their mobile number.
   DID numbers must be previously uploaded to the DID/MSISDN inventory and assigned a specific pricing batch.
2. The DID number is used as a caller ID in both on-net (app-to-app) and off-net calls.
3. You can optionally configure the automated call forwarding from the DID number to the user’s mobile number. Therefore, if a call goes to the DID number, and the app is unavailable, e.g., no Internet connection, the call is automatically forwarded to the mobile phone number.
   When forwarding is enabled for a user, the user is charged for the call forwarded to their mobile number according to their tariff.

For a more detailed description of how to configure PortaPhone and provision it to customers, please refer to the Using the service from a Mobile Application handbook.

PortaPhone for cloud PBX solution

Your PBX customers can use PortaPhone for their PBX extensions. The PBX configuration (e.g., extension dialing, call transfer, call forwarding, voicemail) is done in PortaSwitch. When changes are made, they are automatically updated in PortaPhone.

Let’s say the ABC company wants to use the PBX service via PortaPhone. For each extension, the administrator creates an account:

• assigns a DID number as an account ID;
• adds an alias with the ID that looks as follows: mobile_number@pstn, e.g., 12065552453@pstn (uses either employees’ real mobile numbers or dummy numbers); and
• specifies email in the account information.

The DID numbers are used as a caller ID in all calls.

The numbers specified in the account aliases, e.g., 12065552453, are used for signing in.

For example, John Doe is an employee of ABC. The administrator has already created an account for John following the steps described above. Next, John downloads the PortaPhone app. To sign in, John enters his mobile number (e.g., 12065552453) and the CAPTCHA code. PortaSwitch sends a one-time password to John’s email. After entering the one-time password, John Doe signs in and can call his colleagues via PortaPhone.

PBX PortaPhone users see a list of their colleagues on the Contacts tab and can quickly find a colleague by name or phone number. Thus, they do not need to remember everyone’s extension or search for it elsewhere. This improves their user experience with your PBX solution.

Accounts in the PBX environment must have extensions assigned to them to appear in the contact list. PortaPhone displays the contact details based on the information specified for the account:

• By default, PortaPhone displays the first and last name defined for the account’s owner;
• If the first and last name fields are empty, PortaPhone displays the name of the extension;
• If the extension name field is empty, it displays the phone number.

The administrator can manage the contact list in PortaBilling, via the customer self-care interface.

For example, when customer ABC adds a new extension for Alice Smith, PortaPhone retrieves the updated list from PortaBilling via the API and displays it on the user’s phone. Thus, if John Doe opens PortaPhone and goes to the Contacts tab, he sees a list of his colleagues:

To ensure that the user’s contact list stays up-to-date, the app sends periodic API requests to PortaBilling to refresh it. You define the refresh period along with other parameters on the configuration web portal when you build the app image that you publish in Google Play/Apple App Store.

With PortaPhone, users can make both app-to-app and app-to-mobile calls. App-to-mobile means a call made via the app to another user’s mobile phone.

For example, John and Mary use the PortaPhone mobile app. Via the app, they can call each other for free using an Internet connection. If Mary has no Internet connection, John can’t reach her when making an app-to-app call, so John calls her mobile phone. To do that, he taps and holds Mary’s contact on his contact list. Next, he selects “Off-net call” in the pop-up menu to initiate an app-to-mobile call. The call goes through and Mary picks up the phone.

Thus, you can offer PortaPhone users to take advantage of on-net communications and be able to call each other off-net to their mobile phone numbers.

Corporate (PBX) users can make app-to-mobile calls if the administrator used the users’ real mobile numbers in account aliases (alias ID is mobile_number@pstn, e.g., 12065552453@pstn).

The Smart Contacts feature displays the contacts in the address book of those who use the same app and can be reached app-to-app. In the address book, PortaPhone users are indicated by color and icon.

All the PortaPhone users from an address book are listed separately in the Smart Contacts tab.

For example, let’s say that John installs the PortaPhone app, signs up, and opens the Smart Contacts tab to see which contacts he can now call for free. John sees that his friend Adam also uses PortaPhone, so with a single tap, John makes an app-to-app call to Adam. When someone from John’s address book starts using PortaPhone, their contact is automatically added to the Smart Contacts list and highlighted in the general address book.

The Smart Contacts tab is only available if at least one of the user’s contacts also uses PortaPhone.

This feature allows PortaPhone users to quickly see which of their contacts also use PortaPhone.

PortaPhone users can modify their service configuration from within the app without having to explicitly log into the PortaBilling self-care interface.

When they switch to the self-care tab in PortaPhone, they can:

• Configure follow-me lists and forwarding rules;
• Configure call recording; and
• Browse call history and listen to call records.

For the self-care portal to appear in PortaPhone, define the self-care URL when you build your app image on the configuration portal.

Any changes made on the self-care portal (e.g., updated forwarding rules) are pushed to PortaBilling via the API.

The global PBX configuration (e.g., call barring rules, service codes definition) remains centralized and is done via the customer self-care in PortaBilling.

To allow end users to manage their own service configurations, your administrator enables the Can be edited by end users check box for call forwarding and call recording service features within their product configurations.

PortaPhone supports push notifications to ensure that users receive incoming calls and/or messages while PortaPhone is either closed or in the background consuming little battery.

For push notifications to work, Acrobits SIPIS server is deployed in PortaSwitch. It is an active proxy which communicates with PortaPhone via the HTTPS protocol to obtain user SIP credentials for registration. It communicates with PortaSIP via the SIP protocol to register on behalf of the phone user and handle incoming calls and messages when PortaPhone is in the background.

Let’s have a closer look at how it works:

When PortaPhone is open and in the foreground, it is registered on PortaSIP and thus receives all calls and messages directly. When it is moved to the background, PortaPhone unregisters on PortaSIP and sends the HTTPS request with the user’s SIP credentials to SIPIS. SIPIS then registers on PortaSIP and begins to monitor for incoming calls and messages.

When there is an incoming call, PortaSIP sends it to SIPIS. SIPIS sends the push notification to the user’s phone via either an Android or iOS push service. This wakes up PortaPhone. Then SIPIS initiates the call with PortaPhone and once the call is established, it mediates the SIP signaling between the calling party and the user’s phone. The RTP stream flows directly between the phones. In such a way, the user receives the call as if the app had been running.

To configure SIPIS in PortaSwitch, create the SIPIS instance on the Configuration server and define the server’s hostname there. The system activates it automatically.

Push notification processing is a resource consuming task and highly dependent upon the number of anticipated users. Therefore, we recommend that you allocate a dedicated server for SIPIS, which must meet the following hardware requirements:

For testing purposes, you can run SIPIS on an existing PortaSwitch server. However, make sure its capacity is sufficient to process SIPIS registrations and consider the following conditions:

1. SIPIS cannot reside on the web servers as it listens to the 443 port.
2. SIPIS cannot reside on SIP servers since in this case PortaSIP cannot process SIPIS registrations correctly.

The SIPIS server requires a valid SSL certificate issued from a trusted Certificate Authority (e.g., LetsEncrypt) to make your push service compatible with iOS devices.