All posts by craigr

Genesys Integration on The Wire (IOTW)

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 (




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).



Genesys Management 2.0

Hi – I’m back! Unfortunately, due to client confidentiality I’ve not been able to blog about Genesys work projects for a few years. Let’s change that ..

This post is about something I have been looking at for several years in the form of a shelved project which gets events from Genesys components via the PSDK and fires them into Esper for some complex event processing (CEP). But why get complex with PSDK code – why not just parse unstructured Genesys log files into structured data – let’s say in a JSON format?

Voxeo / Aspect went down this log processing route using Splunk but in the wider context using Splunk for Genesys log processing was not cost effective. However, the momentum of ELK (now the Elastic Stack) in the last 12 months has changed this significantly and I think it’s time for Genesys Management 2.0!

If you look at the current Genesys Management layer it’s not exactly fit for purpose. Yes, you can alarm and send SNMP traps but that just gets you into the Sh*t in Sh*t out (SISO) problem whereby too many alarms are sent meaning they just get ignored because “that is normal”. Worse still operational incidents occur for which there are no alarms – like SIP INVITEs not being received over a SIP trunk even though it is not OOS.

On top of Management 0.1 which has not changed for years, Genesys have added the Log File Management Tool (LFMT) and the Log Masking Tool which is just a couple of Java lines of code around Regex! Neither are aimed at operational excellence – just making life easier for Genesys Support.

Hence the reason for the post – using an ELK stack for Genesys Management 2.0. Surely a few Logstash Grok filters to parse out the following conf server log lines into events with metadata like the log message Id would without stealing the “Spotlight” would be quite valuable:

16:29:54.229 Std 24200 Object: [CfgFolder], name [Demands], DBID: [268] is created by client, type [SCE], name: [default], user: [default]
16:30:33.262 Std 24202 Object: [CfgFolder], name [Demands], DBID: [268] is deleted by client, type [SCE], name: [default], user: [default]
16:31:20.017 Std 24201 Object: [CfgRouteDN], name [RES Prepayment – Gas], DBID: [283] is changed by client, type [SCE], name: [default], user: [default]

grok {
match => { “message” => “%{TIME:timestamp} %{WORD:loglevel} %{WORD:logMsgId} %{GREEDYDATA:message}” }
break_on_match => false

Time to get Grok-ing.


Jaguar XJS V12 ECU

A pleasure to meet Ray and Roger again at AJ6 Engineering today and watch Roger do battle with some “old” electronics aka the Lucas 16CU from my XJS V12.

Those hand written notes and schematics could tell a story or two! NEC Ireland on the CPU … perhaps some commonality with the BMW E30 320?



Genesys INAP Integration

Firstly I hope you had a great Xmas 2014 and a very Happy New Year to you all.

In this blog post I want to share with you some of my experiences of INAP integration with Genesys. INAP stands for Intelligent Network Application Part. INAP is the signaling protocol used in Intelligent Networking and is part of the Signaling System 7 (SS7) protocol suite, typically layered on top of the Transaction Capabilities Application Part (TCAP).

An extended form of INAP is CAMEL (Customised Applications for Mobile Enhanced Logic). The CAMEL Application Part (CAP) provides mechanisms to support operator services beyond the standard GSM services for subscribers roaming within or outside the Home PLMN (HPLMN). CAP extends the IN framework to GSM/3G networks for implementing IN based services within GSM/3G networks.

CAMEL is used between the gsmSSF and the gsmSCF (for example Redknee / NSN IN@Vantage). All CAMEL service requests are directed to a gsmSCF. The gsmSCF is a functional entity where the CAMEL services reside. The node in which the gsmSCF resides is called the Service Control Point (SCP).


SEP = Signaling End Point (for example an SSP), SG = Signaling Gateway, IPSP = IP Signaling Point

OK – without boring you too much further let’s assume that we have a requirement to integrate Genesys into an IN network.

In this application INAP Assist Request Instructions (ARI), Prompt and Collect User Information (PCUI) and PCUI result operations will be used to pass IN information to Genesys and to control the call while still under IN control and on a temporary connection (for example to invoke a subsequent Disconnect Forward Connection (DFC) from the downstream Genesys environment where a SIP BYE is not permitted). The initial INVITE to Genesys SIP Server (SIPS) (or in this case my custom FreeSWITCH SG upstream of Genesys SIPS) will contain the SCP correlation Id used on the initial Assist Request Instructions (ARI) IN operation.

So how can this be done?

Well the easy (!) way is to build a custom solution based on the Dialogic® Distributed Signaling Interface (DSI) Protocol Stacks (

DSI consists of a range of hardware and software components for realisation of SS7, SIGTRAN and Diameter signaling nodes and applications. The DSI Protocol Stacks are software implementations of standards-based signaling protocol layers. In addition a suite of API functions is also supplied to provide a convenient interface for the user application as well as coding and decoding of INAP operations.

The DSI M3UA module is a software implementation of the IETF SIGTRAN SS7 MTP3 User Adaptation Layer (M3UA). The M3UA module uses the services provided by the Stream Control Transmission Protocol (SCTP) to exchange signaling messages with M3UA Signaling Gateway Processes (SGP), M3UA Application Server Processes (ASP) or M3UA IP Signaling Processes (IPSP). The M3UA module is intended to be used in conjunction with other DSI Signaling Protocols namely SCTP, ISUP and SCCP. When used as part of an ASP or IPSP, M3UA offers a primitive interface identical to that of MTP3. This allows M3UA to interface directly to protocols that interface with MTP3.

I chose to implement the solution as a separate SIP Signalling Gateway (SG) based on FreeSWITCH with custom dialplan (DP) applications written in Microsoft C# and called via mod_managed ( but there is no reason why this custom code could not be called directly from Genesys routing strategies and URS e.g. invoked as a Web Service.

The diagram below shows a high level overview of the solution. Essentially in this solution FreeSWITCH manages all the IN calls (INAP operations) via custom C# using DSI modules and INAP APIs and passes the required information to Genesys SIP Server (SIPS) in custom SIP headers:


OK – on to the technical implementation.

DSI API is C based so a C++ wrapper (DLL) is used to abstract the complexity. This handles the passing of messages between managed (C#) code and unmanaged (C++) code. For example the MSG message is a C data structure containing a fixed format header field and a buffer for variable length parameter data. The DSI INAP API functions are used to encode and decode INAP messages based on protocol required (such as CAMEL v3).

DSI C++ Wrapper


DSI C# Class



DSI Configuration

There are two configuration files – system.txt and config.txt. The selection of which protocol modules to run on the host is made by editing the system.txt configuration file. A software-only architecture may be configured using the appropriate Dialogic DSI SIGTRAN modules in place of MTP2 and/or MTP3. These modules provide the same interface to upper protocol modules and use the services of the Stream Control Transmission Protocol (SCTP) to transport SS7 signalling reliably over IP. There are two choices of SCTP module – SCTP (used with SCTPD) and SCTPN which utilises the ‘native’ SCTP stack provided by the host Operating System kernel.

Note: Windows does not provide a native SCTP stack!

For trial purposes, a mode of operation is supported that allows DSI Protocol Stacks to run for up to one hour without requiring a run-time license. Trial Mode is enabled by starting the protocol module with the -t option on the command line. For example, in order to start the M3UA module in trial mode using a FORK_PROCESS command in system.txt on a Windows system: