This brings back fond memories of my first job at ICL West Gorton Manchester.
Cutting it a bit close at 15:24!
Damn – another toy required. Please do not post this to Mrs. R!
Time to play!
Initial thoughts – the pairing mechanism using the iPhone camera is genius.
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?
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 (https://www.dialogic.com/products/signaling-and-ss7-components/download/dsi-interface-protocol-stacks.aspx).
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 (https://wiki.freeswitch.org/wiki/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
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:
FORK_PROCESS ./HSTBIN/m3ua.exe -t