Contact Sync

Introduction

Contact Sync is an advanced, optional feature of Cloud Softphone which uploads contacts from a mobile device to Contacts server and keeps the server-side copy up-to-date.

The server-side copy of contacts allows users to see their mobile address books from Cloud Softphone WebRTC app and also makes Smart Contacts possible: The server checks which people from address book use the same service and offers on-net calls with extra features like video calls or file transfers for such contacts.

Requirements

Contacts server

The server which stores the contacts and provides APIs to clients to keep the contacts in sync. The server is available either as a binary for Linux, installable on premises of provider, or as a hosted solution by Acrobits.

SSO server

Single Sign On server, which validates SIP username&password using External Authentication web service and creates access tokens, which clients use to authenticate themselves. This server is also available either as a binary for Linux to be installed on premises of provider, or hosted by Acrobits.

Example workflows

Note

The workflows below are provided in an effort of making understanding of this functionality easier. The processes described here are implemented by Acrobits software and no additional work is needed to make them work.

Initial situation

Mobile Cloud Softphone app is provisioned with valid SIP account. Contact Sync is enabled and properly configured on Cloud Softphone portal.

WebRTC app is provisioned with the same SIP account and uses the same Cloud ID.

A. Mobile app obtains access token from SSO server

  1. Mobile app contacts SSO server via HTTPS request and passes SIP username, SIP password and Cloud ID

  2. SSO server contacts Cloud Softphone portal and gets web service definition for External Authentication web service

  3. SSO server makes External Authentication request. Since the SIP account credentials are valid, web service returns successful response code and a list of verified phone numbers for this user.

  4. SSO server creates a random string token if it doesn’t exist for a given SIP username and Cloud ID and remembers which verified phone numbers are linked to it

  5. SSO server sends this token back to Mobile app, which saves it securely on the device

Note

From now on, each request to Contacts server will contain token obtained from this step. Contacts server checks the token with SSO server to make sure its valid and can always get from SSO server SIP username, Cloud ID and list of verified phone numbers if needed.

B. Mobile app uploads its contacts

  1. Mobile app creates a new record for the current device where it’s running, if it doesn’t exist. Note that the mobile app can be installed on several devices, use the same SIP account and each device may have a different address book. This situation is fully supported.

  2. Mobile app asks Contacts server for checksums of currently stored contacts

  3. Mobile app compares the checksums with local address book and identifies which contacts need to be refreshed on the server

  4. Mobile app uploads contacts to Contacts server to make the server synchronized with local contacts

C. WebRTC app obtains access token

WebRTC will use exactly the same procedure to obtain access token as described in section A. The token will also be stored securely in browser storage.

D. WebRTC fetches contacts from Contacts server

  1. WebRTC app lists all devices which exist for the given SIP username and Cloud ID. It sends a request which contains access token, Contacts server will validate it and get SIP username and Cloud ID from SSO server and send list of all devices attached to them.

  2. WebRTC chooses one of these devices as master device. The selection can be changed later in WebRTC app settings.

  3. WebRTC requests all contacts. The request contains selected device ID and access token. Contacts server validates the token at SSO server, makes sure that device ID belongs to the SIP username and Cloud ID which owns this access token and send all contacts as a response.