There are two integration scenarios that can be used for the implementation of your integration. The first is by connecting to the solution’s server (the server is the call router and IM manager). The second is by connecting to the client (the endpoint where the user interacts with the system).
We’ll investigate these integration scenarios in more detail in the next blog articles. Let’s start by discussing what parameters can be integrated.
What parameters can be integrated?
The following are the typical parameters that can be passed between the UC server and the application:
Events (sent by the UC server to the application)
- Remote party (the person on the phone)
- Local user
- Incoming/outgoing communication
- Duration
- Type of event
- Message
- Call
- Call queued
- Call parked
- Chat queued
- Fax
- SMS
- Screen sharing
- History items
- SMS received
- Fax transmitted
- Call recorded
- Chat transcript
- Screen sharing
Actions (sent by the application to the UC)
- Generate call
- Answer / hang up
- Transfer / forward call
- Transfer chat
- Start / stop recording
- Log in / log off to the system
- Log in / log off to a help desk group
- Send fax
- Send SMS
Now let’s examine integration scenarios that allow customization of your requirements and can be adapted to meet your specific needs.
Integration via Communication Client ICC (First-party Call Control)
In this integration scenario, the integration is performed by the client (VoIP phone, softphone, or IM client), which manages the communication sessions (calls, chats, etc.). A connection between the client and the software allows for the exchange of information.
VoIP SIP phones (which function as standalone devices) can send event notifications to the application by, for example, opening an “action URL” for each event that occurs on the device, including a new call, a hang up, an answer, etc.
VoIP SIP softphones can also directly open the application or the CRM’s URL in a browser. For example, using a call popup that displays call details.
Clients can also perform actions, such as generating a call.
This integration scenario is usually the simplest to perform, but in reality, it has many drawbacks including:
- It controls only one device (for example, the user’s desk phone). If the call takes place over a mobile app, the integration will not work.
- There is a large amount of configuration time, as each client must be configured individually.
- There is a limited choice of devices. Many clients do not support this feature (for example, calls forwarded to a mobile or desk phone will not be tracked).
- It cannot work if the client is offline (for example, all events that occur when the softphone is closed cannot be tracked).
- There are reachability issues. The application client / server might not be reachable from the network where the VoIP SIP Phone is installed (different VLANs).
- There are security issues. All of the devices need to perform some form of authentication against an API on the server side. It is difficult to update these tokens and make sure that no man-in-the-middle attacks are executed.
- There is a lack of flow control. Following a minor downtime period, some events could get lost or be left pending (for example, a call started but never ended).
- There is a lack of full status after a downtime period. There is no way for the application client or server to “ask again” for a full status of current open communication sessions (calls, chat, etc.).
As you can see, the integration scenario has significant limitations. But they can be easily overcome using the integration via communication server. In the next blog article I will analyze this scenario and explain ways of its deployment.
