Previously (Integration blog article), we have discussed possible integration scenarios. This time, I will introduce integration requirements and the technologies, methodologies that allow for the integration of a communication solution with external applications, achieving the partial or full automation of many processes.
Integrating the communications solution creates many advantages. Integration is a way to satisfy users and customers, but it also allows the company to maintain lean communications. Automating operations using integration is the key to reducing waste, as it allows users to achieve more with fewer resources.
It is important to understand that different solutions support completely different features. Thus, each solution can achieve completely different levels of integration.
The typical integration with a PBX involves adding click-to-call to facilitate call generation, sharing phonebook contacts from your application with the PBX, and opening call pop-ups during incoming and outgoing calls. These integrations are known as CTI (Computer Telephony Integration).
Using a modern communications solution, that also supports chat and other medias, increases the scope and value of the possible integrations. When building or choosing a new solution, it is advised that you strive for a full set of features.
All integrations are accomplished by communicating with the solution using a network protocol (or in the case of a legacy PBX, through other means like a serial interface).
Even when a library is provided to perform the integration, or if Windows TAPI is used, the library or driver will inevitably use a network protocol to communicate with the Unified Communications solution.
Integration Requirements
Network
This integration requirement is frequently overlooked, but can create serious issues later. A typical problem is that on the paper, the communications solution is integrated. However, it is impossible to access it outside of the office, because the protocol used does not work over the Internet.
If mobility is a key requirement for users, it is worthwhile to consider cloud-hosted services. For example, many PBX systems require a local LAN to work properly (or the equivalent via VPN).
When making a choice, the following factors must be considered:
- Terminal server: does the application run in a terminal server environment?
- Firewall: are there security policies which must be changed to use the integration protocol?
- Location: are the UC solution and integrated software on the same network?
- Bandwidth: how much bandwidth is used by the integration?
Services
In the list of integration requirements, we need to include which services will be integrated such as calls, chat functionality, history information, contacts lists, etc.
Application
What kind of application are we using and what do we want to integrate? From my experience, there are two main categories:
- Windows apps (client-only or with client-server architecture)
- Web apps (browser-as-a-client or web server-as-a-server)
We also need to consider which protocol to use, which language, and whether or not to add modules to the app.
For Windows applications that require a telephony integration, the reference standard is TAPI version 2 or 3.
For web applications, the integration can be performed using all the technologies we’ve previously discussed (SIP and XMPP standards, Introducing BOSH and WebSocket, SDP Protocol, RTP, RTCP and Jitter Buffer). Thanks to JS Libraries, for example, the UC solution can allow any web application to connect with it and exchange information in real-time.
UC solutions that are not web-friendly can still be integrated, performing basic operations like calls using browser extensions or call pop-ups. This is facilitated by having a local app open the browser and passing the call parameters via a URL.
Next time I will describe whether it is better to buy or develop an integration from scratch.
