Skip to main content

CTI with Node + Redis

Summary

In this article I'll be discussing a way to implement call data passing between disparate telephony systems, i.e., Computer Telephony Integration (CTI).  The techniques I employ in this article (DNIS pooling, database storage of call data, etc) are nothing groundbreaking.  In fact, these techniques are as old as the hills (well, maybe not that old).  What will be new here is the use of current software architectures such as REST with highly-efficient run-time environments such as Node.js and Redis to realize an open data integration between 3rd party systems.
This article is the culmination of a series I've written on this topic.  In Part 1, REST calls from Genesys Routing Strategies, I discussed how to make REST web service calls from one particular vendor's CTI system (Genesys).  In Part 2, VXML and REST Web Services, I discussed REST web service execution from VXML applications.
I'll be leveraging information in this article that I've presented in the following previous articles:
Node/Basic Auth - HTTP Basic Auth on Node.js

Implementation

Figure 1 below depicts the overall architecture.  The 'RAM Cache' component is the focus of this article.  The overall use-case of that cache is to provide 3rd Party telephony systems, with proprietary-only integrations, an open standard method for passing call data between them.  Example:  call that is transferred between two disparate systems.  It would be preferable to retain any data that was gathered by the transferer and pass it to the transferee.
Figure 1
Figure 2 depicts the details of the transfer scenario mentioned above.  A caller calls Telephony System X, during the call System X gathers various pieces of information relevant to the caller, then System X transfers the call to System Y.  The RAM Cache provides the mechanism for call and data matching on that transfer.  The RAM Cache provides a target DNIS, from a pool of numbers assigned to System Y, for System X to transfer the call.  Additionally, the RAM Cache stores any caller data under a DB key that is the combination of the target DNIS and caller's ANI.  The combination of the two provides some additional protection from call/data collisions vs. systems based on either DNIS  or ANI alone.  System Y can subsequently match the call and data upon receipt of the transfer.
Figure 2
The RAM Cache architecture itself is depicted in Figure 3.  The Node runtime with various modules are utilized to implement: a.  HTTP server that provides the REST interface and b.  a client to the Redis database.  A static configuration file is utilized for all server information.  Redis provides a key/value store for the DNIS:ANI-keyed values.  Additionally, by configuring key expirations in Redis we can implement automatic expulsion of stale key/values.
Figure 3
Figure 4 depicts the REST interface I implemented here.  POST's insert data into the store (Create).  GET's fetch data from the store (Retrieve).  DELETE's both fetch the data and cause it to be deleted from the store (Delete).
Figure 4

Example Use

Below are some cURL examples on use of the REST interface.

POST


curl --user "username:password" -v -i -H "Content-Type:application/json" -X POST -d '{"value" : "12345678", "ani" : "1234567890"}' https://yourDomain.com/cticache/DNIS-ANI

HTTP/1.1 201 Created
< X-Powered-By: Express
X-Powered-By: Express
< Location: /cticache/DNIS-ANI/5551234568:1234567890
Location: /cticache/DNIS-ANI/5551234568:1234567890
< Content-Type: application/json; charset=utf-8
Content-Type: application/json; charset=utf-8
< Content-Length: 59
Content-Length: 59
< Date: Mon, 29 Sep 2014 00:19:53 GMT
Date: Mon, 29 Sep 2014 00:19:53 GMT
< Connection: keep-alive
Connection: keep-alive

* Connection #0 to host yourDomain.com left intact
{"dnis":"5551234568","ani":"1234567890","value":"12345678"}

GET


curl --user "username:password" -v -i https://yourDomain.com/cticache/DNIS-ANI/5551234568:1234567890

HTTP/1.1 200 OK
< X-Powered-By: Express
X-Powered-By: Express
< Content-Type: application/json; charset=utf-8
Content-Type: application/json; charset=utf-8
< Content-Length: 20
Content-Length: 20
< ETag: W/"14-2814665325"
ETag: W/"14-2814665325"
< Date: Mon, 29 Sep 2014 00:24:14 GMT
Date: Mon, 29 Sep 2014 00:24:14 GMT
< Connection: keep-alive
Connection: keep-alive

* Connection #0 to host yourDomain.com left intact
{"value":"12345678"}

DELETE


curl --user "username:password" -v -i -X DELETE https://yourDomain.com/cticache/DNIS-ANI/5551234568:1234567890

HTTP/1.1 200 OK
< X-Powered-By: Express
X-Powered-By: Express
< Content-Type: application/json; charset=utf-8
Content-Type: application/json; charset=utf-8
< Content-Length: 20
Content-Length: 20
< Date: Mon, 29 Sep 2014 00:26:35 GMT
Date: Mon, 29 Sep 2014 00:26:35 GMT
< Connection: keep-alive
Connection: keep-alive

* Connection #0 to host yourDomain.com left intact
{"value":"12345678"}

Comments

Popular posts from this blog

Merge AVHDX Hyper-V Checkpoints

When you create a snapshot of a virtual machine in Microsoft Hyper-V, a new file is created with the  .avhdx  file extension. The name of the file begins with the name of its parent VHDX file, but it also has a GUID following that, uniquely representing that checkpoint (sometimes called snapshots). You can see an example of this in the Windows Explorer screenshot below. Creating lots of snapshots will result in many  .avhdx  files, which can quickly become unmanageable. Consequently, you might want to merge these files together. If you want to merge the  .avhdx  file with its parent  .vhdx  file, it’s quite easy to accomplish. PowerShell Method Windows 10 includes support for a  Merge-VHD  PowerShell command, which is incredibly easy to use. In fact, you don’t even need to be running PowerShell “as Administrator” in order to merge VHDX files that you have access to. All you need to do is call  Merge-VHD  with the  -Path  parameter, pointing to the  .avhdx  file, and the  -Des

Openstack manila phần 4: Native GlusterFS Driver

Tiếp tục loạt bài về Openstack Manila hôm nay tôi sẽ cấu hình backend sử dụng GlusterFS Yêu cầu phiên bản GlusterFS >= 3.6. Với glusterfs nếu cluster của bạn không hỗ trợ snapshot thì trên manila cũng sẽ mất đi tính năng này. Để cấu hình snapshot ta sẽ cấu hình Thin Provision theo bài hướng dẫn link Với bài lab của mình có 2 node và chạy kiểu replicate. Mình sẽ tạo các thinly provisioned và tạo volume trên đó. Mô hình cài đặt Cài đặt glusterfs-v3.7 add-apt-repository ppa:gluster/glusterfs-3.7 -y apt-get update apt-get install glusterfs-server -y Tham khảo script tạo thin LV và gluster volume Script tạo thinly provisioned chạy trên 2 node apt-get install xfsprogs -y pvcreate /dev/sdb vgcreate myVG /dev/sdb lvcreate -L 8G -T myVG/thinpool for ((i = 1;i<= 5; i++ )) do mkdir -p /manila/manila-"$i" for (( j = 1; j<= 5; j++)) do lvcreate -V "${i}"Gb -T myVG/thinpool -n vol-"$i"-"$j" mkfs.xfs /dev/my

Zabbix, AWS and Auto Registration

One of the things I love the most with AWS is  auto-scaling . You choose an AMI, set some parameters and AWS will spin instances up and down whenever a threshold is breached. But with all these instances spinning up and down there are some unknowns. For example, what is the IP address of the new instance? Its host name? This can be critical when other components of your infrastructure are dependent on knowing these parameters. I had this problem when I started to use  Zabbix  as the monitoring system. At first it seemed like a complicated one, but Zabbix has a wonderful feature called  Auto Registration  which can be used exactly for this situation. I will try to show how to configure auto registration both on the client (EC2 instance running Ubuntu 14.04) and on the Zabbix server (Zabbix Server 2.4.2). Zabbix-agent Installation and Configuration Let’s start with installing zabbix-agent on the Ubuntu client: 1 2 $ sudo apt-get update $ sudo apt-get install -y zab