Following on from a previous post on Genesys Management 2.0 here I’ve been doing some additional work on integrating Genesys environments with Elasticsearch. The result is what I call Genesys Integration on The Wire (IOTW).
Integration on The Wire (IOTW) is a technology which enables system level integration based on a “zero touch” and “zero impact” basis. In the context of integration to Genesys based systems this enables integration without needing to purchase the Genesys Platform SDK (PSDK) and without the worry that PSDK type integrations might cause additional loading on the Genesys component and hence operationally destabilise the solution.
A custom SIP and Genesys IOTW instance is installed as a Windows Service on all servers which host Genesys components. This component enables capture of SIP and Genesys specific network traffic and thus provides a point of “Integration on The Wire”. During “discovery” each Genesys IOTW instance listens (captures) all IP traffic. Packet analysis enables self-documentation of the Genesys environment and associated audit e.g. Which Genesys components are deployed where? At which version? Who connects to what? Who uses what TCP port? Etc.
Once discovery is complete the IOTW configuration is updated and IOTW instances are run in “capture” mode. During capture, each instance starts forwarding SIP and Genesys related packets (containing Genesys Request and Event information) to an Amazon AWS Elasticsearch (ES) domain. The custom IOTW instance also supports the ELK (Elasticsearch Logstash Kibana) stack allowing events to be pushed into a standalone Elasticsearch cluster either through direct integration or via Logstash instances.
The following protocols are supported:
- HTTP and HTTPs (*)
- Session Initiation Protocol (SIP) and Secure SIP / SIPS (*)
- Genesys Configuration
- Genesys Management
- Genesys T-Library (SIP Server, T-Server and URS)
- Genesys Outbound
- Genesys Stat Server / RTME
- Genesys Interaction
- Genesys Contact
- Genesys WebMedia
* Where TLS handshake is captured on TCP connection
As soon as performance statistics, SIP and Genesys protocol events are captured and sent to Elasticsearch the IOTW platform becomes comparable to a Swiss Army knife since it allows you to find out what is really happening in a Genesys environment from every perspective – your business, your customers, your agents, your technology and IT. As such it supports many use cases:
- System Management and Support
- Load Test Monitoring
- Proactive queue notifications
- Customer value analysis
- Geolocation analysis
- Retrospective reporting
- Fraud and Forensics
Kibana gives you the freedom to select the way you give shape to your data. And you don’t always have to know what you’re looking for. With its interactive visualisations, start with one question and see where it leads you:
One of the most powerful features in Kibana is the Timelion which brings together totally independent data sources into a single interface, driven by a simple, one-line expression language combining data retrieval, time series combination and transformation, plus visualisation. There are 25 different expression functions, from simple arithmetic like addition and division to moving averages, cumulative sums and derivatives. Using simple functions such as subtract and offset it is possible to visualise differences in events on a day by day basis based on for example the previous week (offset=-7d):
IOTW automatically tags events with longitude and latitude information when applicable. For example on the voice channel SIP and Genesys T-Server events containing phone numbers are checked against a database of UK landline area (STD) codes in order to determine the area the call originated from. Equally CTI attached data is checked for UK postcode information and geotagged in the same way. On non voice channels IP addresses are checked against an IP geolocation database (https://www.iplocation.net/).
I’ll follow up with further posts about the IOTW Fireman which handles how the plaform auto scales by adding and removing Elasticsearch data nodes and also manages alerts based on configurable rules:
- Match where there are X events in Y time (frequency type).
- Match when the rate of events increases or decreases (spike type).
- Match when there are less than X events in Y time (flatline type).
- Match when a certain field matches a blacklist/whitelist” (blacklist and whitelist type).
- Match on any event matching a given filter” (any type).
- Match when a field has two different values within some time (change type).