Integration Via Communication Server

Using a centralized approach of integration via communication server ICS (Third-party Call Control) solves all the previously described issues (Integration Scenarios for a Communication System). In this scenario, our communication server tracks all the events, which is the most professional approach. It can work for both hosted and local deployments of the communication system.

URL / Application Pop-ups (ICC / ICS)

The simplest integration mode is to open a web service (like CRM) or an application and pass relevant parameters to it.

For example: https://www.somecrm.com/customer.php?number=123123123&direction=outgoing

or:

C:\\Applications\SomeCRM\popup.exe <number>

This kind of integration, if implemented as ICC (Integrations via Communication Client), is limited to a local softphone that must open the URL, or the local application passing specific parameters. The limitations are clear: Only a softphone can be used. If any other device is used, the integration will stop working.

This problem can be overcome by using an ICS approach, if the communication platform supports a client/server configuration for the delivery of events.

In this case, a local agent or UC application (which performs the integration) connects to the communication server and generates actions (for example, generates a call). It then waits for events (for example, a new incoming call), and, when needed, runs the required application or opens the requested URL.

An example of an agent implementation in Windows could involve a local TAPI driver that receives information from a remote communication server.

Using an ICS approach is important to make sure the integration works correctly, regardless of the phone device used (for example, a VoIP desk phone, a mobile app, or a softphone).  

UC Server Action URLs / Web Hooks

Depending on your application, it might be important to get information on events, even when the web CRM is not open in the user’s browser.

There are two strategies to achieve this goal. The first is to have the UC server send events to the web CRM in real-time via action URLs or web hooks.

The idea is that after receiving a web hook on a RESTful API HTTP interface, the CRM will store the information, or it will interact with the user to display a pop-up that contains call-related information.

Many VoIP SIP phones like Grandstream, Yealink, and Snom support this feature. Such devices can only send information related to telephony, like answer, hang up, pressed DTMF, etc.

A second, more efficient way is to implement this feature in the UC server or via an agent connected to the PBX. The advantages are numerous including:

• Only one endpoint should be able to reach the CRM to communicate events.
• Any phone device is supported.
• Devices can be installed in separate voice VLANs.
• CRM notifications regarding events can be repeated to ensure delivery.
• More precise information is stored, including:
  • Chat transcripts
  • Call recordings
  • DTMF dialed in an IVR
• Communicating changes in user presence / status.

Next time I will bring to notice  TAPI (Telephony Application Programming Interface) and Web API, as these technologies allow integrations with many applications.