Call control from external apps in site-redundant PortaSwitch

You can provide reliable service for your customers when offering them applications with call control functionality (built in-house or by third parties).

Call control API that enables users to manage and monitor calls from external applications is available in site-redundant PortaSwitch.

This means that the applications that communicate with PortaSwitch via the call control API (for example, a web dialer developed in-house or a CRM system where you add the click-to-dial feature) can continue to function the same way even when the main site becomes unavailable.

Say a service provider, Panda Telecom, has a site-redundant installation that includes the main and secondary sites.

Panda Telecom develops its own web application that enables PBX users to manage calls. The application communicates with PortaSwitch via the call control API. Panda Telecom designs the application to automatically switch between the API servers on the main and the secondary site.

Application users can manage calls, e.g., transfer them or turn them into a conference. Also, the application receives notifications from PortaSwitch regarding call status changes, allowing users to monitor the status of other extensions in real-time. For example, a receptionist can see if a sales manager’s phone line is busy before transferring a call to them.

When the main site is down, e.g., due to a power outage, the secondary site activates the “stand-alone” mode. For the application to continue operating, the following behavior is expected:

1. The application gets disconnected from the API server on the main site. The application connects to the API server on the secondary site and logs in again.

2. After the re-login, the application re-subscribes to call state notifications and gets a new list of active calls.

   The users manage calls from the application in the same way as before. When a user makes a new call via the application, this call goes through the secondary site.

3. When the main site is back online, the API server on the secondary site starts rejecting requests, and the application switches back to the main site.

• The application should be designed to automatically switch to the other available API server when one of the API servers becomes unavailable. Also, the application should be designed to automatically re-login, resubscribe to the call status notifications, and get the active call list upon switching to another server.
• The originate_advanced_call method used with the state_callback parameter in the request is not available on the secondary site.