Sorry for the lack of updates

It has been quite some time since my last post. Things are really busy on the project as we prepare for Release 1 rollout. I am currently in the middle of performance testing and getting to grips with Empirix Call Master and Hammer.

Will put up some short posts covering stuff over the last few months.


I’ve won the Lotto!

Returned back home from the client site last night and found a very exciting letter in the post. Looks as though I have won the lotto!

Page 1

Have returned the letter requesting details of my bank account, sort code, date of birth and sample signature. Will let you know how I get on!

Page 2


Audio Streaming with Stream Manager

By default, Genesys Stream Manager uses the URL specified in a SIP INVITE message to determine which announcement to play. The format of the URL is normally:


However, the “play” parameters can also be specified in the format “play=http://<xxx>;mode=stream” which enables stream mode for announcements obtained through a HTTP interface. The specified URL is assumed to correspond to a real-time media streaming device that provides an endless stream. Stream Manager does not cache the received data (except for what is necessary to provide jitter buffer). When a new request comes for the same URL, it will receive media stream when it connects to Stream Manager and not from the beginning of media file as in case of regular mode.

The play parameters can be specified in the “Text” field on the “PROMPT” tab of a play announcement block as shown in the test strategy below:




The Real Time Streaming Protocol (RTSP) is a network control protocol designed for use in entertainment and communications systems to control streaming media servers. The protocol is used to establish and control media sessions between end points.

The transmission of streaming data itself is not a task of the RTSP protocol. Most RTSP servers use the Real-time Transport Protocol (RTP) for media stream delivery

The RTSP protocol has similarities to HTTP, but RTSP adds new requests. While HTTP is stateless, RTSP is a stateful protocol. A session identifier is used to keep track of sessions when needed; thus, no permanent TCP connection is required. RTSP messages are sent from client to server, although some exceptions exist where the server will send to the client.

Unfortunately, Stream Manager does not support RTSP at all. Rather, the Stream Manager HTTP interface works as follows:

  • When the first SIP request comes for the particular HTTP source, Stream Manager tries to open TCP/IP connection to the specified host and port
  • If the TCP/IP connection fails, Stream Manager responds with a 404 Not Found SIP message
  • If the TCP/IP connection is successful Stream Manager sends the following HTTP request on the opened connection:

GET /xxxxxxx HTTP/1.1 \r\n
Host: xxxxxx \r\n
Accept: text/html, audio/x-wav \r\n
Connection: close \r\n
User-Agent: StreamManager/ \r\n

  • In response, Stream Manager expects the following HTTP message (on receiving response with code different from 200 OK, it will translate the error code into correspondent SIP response code sent to requester and close TCP/IP to the media gateway):

HTTP/1.1 200 OK \r\n

Content-Type: audio/x-wav \r\n

Raw audio stream or Audio in WAV format

  • Any other HTTP header lines present in the response is printed into the Stream Manager log file, but otherwise ignored
  • Stream Manager expects audio stream be either a header-less audio stream or a stream formed according to the WAV format standard, i.e. with standard WAV header, although Stream Manager ignores size fields of group header and data chunk in stream mode
  • After getting the initial response, Stream Manger expects audio data coming at the appropriate rate (8000 bytes per second for G.711 codec). Alignment between audio frames and TCP/IP packet are not required, as Stream Manager uses internal jitter buffer between HTTP connection and RTP stream generator

The only known media server which works with the Genesys Stream Manager HTTP protocol is the Mayah Centauri product line (

The challenge therefore is how to make Stream Manager work with other Media Servers such as Windows Media Services.

Windows Media Services

Windows Media Services (WMS) is a streaming media server from Microsoft that allows an administrator to generate streaming media (audio/video). Only Windows Media, JPEG, and MP3 formats are supported.

Windows Media Services 9 Series is available as an optional, installable component in the Standard, Enterprise, and Datacenter editions of Windows Server 2003.
Windows Media Services supports three out of the box streaming types:

  • RTSP with TCP-based transport (RTSPT)
  • RTSP with UDP-based transport (RTSPU)
  • HTTP transport


The solution to this problem is some custom code which acts as a media stream proxy between Stream Manager instances and 3rd party media servers such as Windows Media Services which support the Real Time Streaming Protocol (RTSP).


The functionality of the media stream proxy is as follows:

  • On startup ping each media server to check its availability


  • Listen for HTTP requests from Stream Manager on a given port e.g. 9000


  • When a HTTP request is received, parse the incoming URL for the name of a Windows Media Services broadcast point


  • Connect to an available media server in priority order then send a “SETUP” request for the required broadcast point followed by a “PLAY” request


  • If an error occurs send back a HTTP internal server error response



Who changed that CME object?

The platform SDK makes it pretty easy for use to track changes to CME objects by means of a Conf Server Configuration instance, Protocol Management Service instance and an associated Event Broker instance to handle the following configuration server events:

  • EventObjectCreated
  • EventObjectUpdated
  • EventObjectDeleted

The only extra thing to do is to register for notifications as shown in the code snippet below:


By setting the property “UseDeltaOptimization” to true in the Conf Server Configuration object this can be used as the basis for a Genesys Configuration audit and tracking tool. Life is a bit more complicated in reality since “EventObjectDeleted” only tells us the database ID (DBID) of what has been deleted so we need to keep an internal object cache to have full auditing – more of that in a later post.

Unfortunately although configuration server events tell us ‘What’ has changed, they do not tell us ‘Who’ made the change!

Registering for permissions events using a “RequestRegisterPermissionsNotification” does not help us either.

The required information is however contained on the Configuration Server log when the log level is set to trace. This information is also available in Solution Control Server logs and the log database when network logging is enabled. However trying to parse log files is a) resource intensive and b) not supported by Genesys!

There is a thread on the Genesys Discussion Forum about this (

The answer to the problem is to configure alarm conditions in CME which match log events generated by Configuration Server. The relevant log events are 24200 (object created), 24201 (object changed) and 24202 (object deleted). These log events are defined in the ‘confserv.lms’ file in the configuration server installation folder:


The good news is that these are standard level log events and we can prove that we get alarms by creating some alarm conditions in CME. The steps required are:

  • Ensure that standard level network logging is enabled on Config Server:


  • Create alarm conditions for each of the log events (24200, 24201 and 24202):


Putting the pieces together we need create a SCS Configuration instance, Protocol Management Service instance and an associated Event Broker instance to handle SCS “EventAlarmInfo” events. We also need to subscribe to Alarm Conditions:


When the SCS “EventAlarmInfo” event fires we can then parse the log message text using regular expressions to extract the object Type, object DBID and username of the CME person who changed the object.

Here is an example of a log message and some C# code to parse out the data:

Description = “Object: [CfgPerson], name [readc06], DBID: [104] is changed by client, type [SCE], name: [ConfigManager], user: [readc06]”

// Regex out the data
string pattern = @”\[(.*?)\]”;
MatchCollection matches = Regex.Matches(eventAlarmInfo.AlarmDescription.LogMessageText,pattern);
string[] data = new string[matches.Count];
for (int i = 0; i < matches.Count; i++)
data[i] = “”;
Match match = matches[i];
data[i] = match.Groups[1].ToString();

if (data.Length >= 6)
objectType = data[0];
objectName = data[1];
DBID = Convert.ToInt32(data[2]);
clientType = data[3];
clientName = data[4];
username = data[5];


So that is it – well nearly. Solution Control Server is a bit too clever and will not raise additional alarms when there is an existing alarm condition and therefore we could lose log events relating to other configuration changes.

The Framework 8 Management User Guide states: “Once configured, an alarm condition automatically triggers an alarm in response to an occurrence of the log event on which the alarm condition is based. If the same log event occurs subsequently while the alarm is active, the clearance timeout is reset.”

I raised a support ticket to double check on this functionality and Genesys confimed that to disable this behaviour we would need to raise a new Feature Request.

The challenge therefore is to ensure that the cancel timeout on each alarm condition is high enough to see the log event and low enough not to miss new log events. The minimum we can set the cancel timeout is 1 second but to make the alarms fire reliability the cancel timeout needs to be 2 seconds which means we run the risk of losing events during bulk configuration changes for example when using configuration wizards.

This is something we can probably live with for now.


How to implement an ESP Server

ESP is a mechanism by which you can extend the functionality available in routing strategies. The Platform SDK provides the tools you need to write your own server component to listen for and respond to ESP requests. This is how.

The ESP server is developed in C# .NET using the Genesys Platform SDK.

  • An “ExternalServiceProtocolListener” instance is initialised and the service endpoint which specifies the port which the ESP server listens on is passed as a parameter. Note that this port number much match the port number configured on the CME application object (See below)
  • Create a new “RequestBrokerService” instance using the broker service factory
  • Register a request handler for ESP requests (Request3rdServer) with the request broker


  • Create a request handler to process the ESP request. The standard key names passed are “Service“, “Method” and “Parameters“:


  • Send back the response passing the results in a KeyValueCollection (responseParameters):


Having developed the ESP server the steps to invoke it are as follows:

  1. In CME, create a new template of type “Third Party Server”
  2. Create an application object named using the template to represent the ESP Server component. It is important that the host and port be configured properly as Interaction Server will use these to establish a connection with the ESP server
  3. On the connections tab of each primary Interaction server, add a connection to the ESP server application
  4. On the connections tab of each primary URS server, add a connection to the primary Interaction Server
  5. Write a strategy to call the ESP service using an ESP block

My test strategy does the following:

  1. Initialises strategy variables
  2. Calls a service and associated service method via the ESP server.
  3. Assigns the result from the KVP returned to the relevant strategy variables
  4. Attaches the results to the call








IVR and Routing Interfaces

What a busy month January was!

Following on from my previous post we now have GVP 8 running and configured to use Nuance ASR and TTS resources. We have started to prototype the speech recognition IVR applications for release 2 in Composer 8.0.2.

The release 2 IVR applications will need to interface to both SAP CRM and a third party payment service provider. Given the requirement to take payments the method of integration will obviously fall under PCI scrutiny.

To support the IVR integration work I have been developing a prototype which provides a generic interface between IVR applications and/or optionally Genesys Routing strategies and SAP CRM data services.

The prototype interface is implemented as a Window Communication Foundation (WCF) service host which can be deployed standalone as a Windows service or hosted under Microsoft Internet Information Services (IIS). The advantage of deploying the interface as a standalone Windows service is that we can create a Third Party Server application in CME and monitor the interface through SCI.

The primary function of the interface is to abstract the data services provided by SAP subsystems and to expose a simplified view of these services to the IVR applications and/or Genesys routing strategies. At the core of the interface is an object cache which manages the fetching and storage of SAP data entities in order to reduce any delays in providing responses back to the calling applications.

Security Considerations

The advantage of building the interface using WCF is that WCF implements many security standards and has a wide range of features available. One of the most important aspects of security is authentication. WCF can be configured to use many authentication methods:

  • Anonymous caller
  • User name and password
  • Certificate
  • Windows

The method of authentication is specified in Endpoint bindings. Therefore, the prototype interface can be configured to specify the required authentication method.

However, it is assumed that to meet PCI requirements the endpoints exposed by the interface will be configured in a message-based authentication mode with the use of mutual X.509 Digital Certificates.

Once certificates are setup and configured, the message exchange from the client to the interface service is digitally signed first by the client’s X.509 Digital Certificate (private-key) and then encrypted for the interface service with the service’s certificate (public-key). The interface is able to decrypt the message with its own private key and then validate that the message from the client is not tampered with via the client’s public key installed in its Trusted People certificate store. The message response from the interface to the client is then correspondingly signed first by the service and then encrypted for the client only by the public key found on the client’s X.509 Digital Certificate.

IVR Clients

For IVR applications developed in Genesys Composer the logical choice would be to expose the interface service by configuring a WCF endpoint using a standard Web HTTP Binding and to call it through either a Web Service Block or a Web Request Block.

The problem with this approach is that on the standard composer web blocks the Authentication Type property can only be set to anonymous or basic authentication (username and password). E.g. there is not support for certificate based authentication. In addition:

  • The Web Service block won’t work if the Web Service parameters are named double since URS considers it a reserved keyword
  • There are limitations on the WSDL definitions supported

Another big problem relates to being able to process Web Service results. When the “Map output values to variables” property is set to true, the Output Result property maps the Web Service response keys to AppState variables. If Map Output Values to Variables is set to false, the entire Web Service response will be assigned to a variable.

Therefore, it the web service result contains complex types we would end up with either lots of AppState variables to process or a variable containing the whole response to parse.

The alternative is the ECMAScript block which can be used to invoke JavaScript. This seems to be a better option. E.g. write a WCF client and instantiate it as a .NET object since we can then implement our choice of authentication and encryption.

Another advantage of this approach is that the WCF client if required can convert .NET objects in the response into a JavaScript Object Notation (JSON) string using standard .NET Framework 3.5 classes. JSON is the standard format used by Composer e.g. the data returned by the Web Service block is converted to JSON format.

Routing Clients

As I mentioned above the prototype interface provides services to both IVR applications and Genesys routing strategies.

We could use the same approach as above to access the interface from routing strategies (both for older strategies developed in IRD and for newer URS workflows developed in Composer).

However, Genesys provide an alterative approach using a custom server which implements the Genesys External Service Protocol (ESP). ESP is a mechanism by which you can extend the functionality available in routing strategies.

The Platform SDK provides the tools you need to write your own server component to listen for and respond to ESP requests. Therefore, in addition to supporting a routing interface via WCF e.g. HTTP bindings, my prototype interface also implements the functionality of an ESP server which allows the services exposed to be consumed via External Service blocks within a standard Genesys strategy.

I’ll cover off how this is done in a separate post.


Deployment of GVP 8.1.1

A long post to start off 2010 and to make up for the lack of recent posts!

For this client we have previously deployed GVP 7.6 to support the self service requirements of the Pilot phase which is fairly limited i.e. just basic call steering.

During future phases of the project we plan to deploy more advanced self service IVR applications including card payments. This means that the solution will fall within Payment Card Industry (PCI) regulation.

GVP 7.6 is not PCI compliant since it does not support secure HTTP between the VoiceXML interpreter (page collector) and the VoiceXML application server(s).

Therefore we propose to deploy GVP 8.1.1 which does support secure HTTP. In addition GVP 8.1.1 also supports SIPS and STRP for voice encryption which we may chose to deploy at a later date (although these protocols are not currently supported by SIP Server and Stream Manager which we have deployed as part of the wider architecture).

For a security perspective, GVP 8.1.1 supports:

  • Secure HTTP (HTTPS). The encryption of HTTP traffic either using Secure Socket Layer (SSL) protocol or the Transport Layer Security (TLS) protocol
  • Secure SIP (SIPS). SIP over the Transport Layer Security (TLS) protocol, for call-control and resource-management messaging
  • Secure RTP (SRTP). A profile of RTP that provides encryption and authentication of audio and video data in RTP stream

GVP 8.1 is also more closely integrated with Genesys framework components and all provisioning of IVR profiles / applications is through Genesys Administrator rather than the GVP 7.6 Element Management Provisioning System (EMPS). Therefore, Genesys Administrator (version is a prerequisite.


From an architectural perspective GVP 8.1 is completely different from GVP 7.6 which is not surprising since it is built from the VoiceGenie code base rather than the older Telera code base (although some Telera code seems to have incorporated of which the most notable inclusion is the GVP 7.6 VoiceXML interpreter aka the GVPi interpreter to support backwards compatibility with 7.6 applications developed in Genesys Studio).

GVP 8.1 comprises the following components:

  • Resource Manager (RM)
  • Media Control Platform (MCP)
  • Fetching Module (FM) and Squid
  • CTI Connector (CTIC)
  • Reporting Server (RS)
  • Call Control Platform (CCP) (optional component)
  • Supplementary Services Gateway (SSG) (optional component)

There is an installation package for each of these GVP 8.1 components. Each component is configured as an Application object in Genesys CME.

Here is a diagram of the overall architecture from the Genesys deployment guide:


Resource Manager (RM) components function as a SIP Proxy that controls access and routing to all resources in a GVP 8.1 deployment. The Resource Manager also functions as a SIP Registrar and monitors the health of GVP 8.1 resources in the deployment. In GVP 8.1, Resource Manager in conjunction with Genesys Administrator replaces the functionality provided by the Element Management Provisioning Solution (EMPS) in GVP 7.6.

The Media Control Platform (MCP) is the core component of GVP 8.1, because it executes the actual voice applications in the solution. The Next Generation Interpreter (NGI) and the Legacy GVP Interpreter (GVPi) are Voice Extensible Markup Language (VoiceXML) interpreter components on the Media Control Platform.

The Media Control Platform can run one or both VoiceXML interpreters (NGI and GVPi) and both are installed by default. Voice application / IVR Profile provisioning is used to determine which interpreter to use for a particular voice application. In GVP 8.1, Media Control Platform components replace the functionality provided by the IP Communication System (IPCS) in GVP 7.6.

Fetching Module (FM) components in conjunction with the Third Party Squid product is used to fetch content (such as audio files, VoiceXML pages, or CCXML pages) for the Media Control Platform and the Call Control Platform. In GVP 8.1, the Fetching Module components replace the functionality provided by the IPCS Page Collector in GVP 7.6.

CTI Connector (CTIC) components provide additional CTI functionality by connecting to existing IVR Server components through Media Control Platform components.

Reporting Server (RS) components store and summarises data and statistics submitted by Reporting Clients to provide near real-time reports by hour, day, week, and month. Reporting Clients on the Resource Manager, Media Control Platform, and Call Control Platform send call detail records (CDRs), Metrics, and Operational Reporting (OR) statistics to the Reporting Server. In GVP 8.1, the Reporting Server component in conjunction with Genesys Administrator replaces the functionality provided by the Voice Application Reporter (VAR) in GVP 7.6.

From a reporting perspective it should be noted that unlike GVP 7.6, the importing (ETL) of historical IVR data into Info Mart is currently not supported (and it is unlikely that it ever will).


Unlike GVP 7.6 I am pleased to report that the basic deployment is relatively painless. The deployment process is the same as any other Genesys component e.g. import the application templates, create the applications, add connections, review options and then run setup.exe!

There is a bit of work determining the options to be set on each component as well as creating resource groups for load balancing and IVR profiles in Genesys Administrator but other than that there is not much more to do.

In terms of routing calls to IVR applications this can be done on one or all of 3 ways:

  1. GVP is configured as a Trunk Group DN whereby the call arrives on the Trunk Group DN, where GVP is immediately given call control in order to start a standard VoiceXML application. For Standard VoiceXML applications, the call reaches GVP through a SIP Server Trunk Group DN and the MCP launches a VoiceXML application as mapped on the Resource Manager through IVR Profiles.
  2. GVP configured as a Voice over IP Service DN whereby the call arrives at a Routing Point DN, where a routing strategy uses a Play Application treatment to launch a “URS-centric” voice application.
  3. GVP is configured as a series of Voice Treatment Port DNs whereby the call arrives at a Routing Point DN. The strategy routes the call to a Place Group, where the individual Places are configured as a set of Voice Treatment Port DNs. When routed to this Place Group, SIP Server selects a port and forwards it to Resource manager. Resource Manager selects an IVR Profile for a particular VoiceXML application, based on the DNIS provided in the “To” header of the original INVITE.

We have actually configured DNs to support each of the 3 scenarios above but are currently only planning to use method 3 which is how we route calls to GVP 7.6 and is the standard deployment familiar to most of us. In the future we are planning to consider option 2 and deploy “URS-centric” voice applications with call control remaining with URS. A example of this would be to offer some self service options whilst in queue and then returning to the queue afterwards.

Co-existence with GVP 7.6

Since we have already deployed GVP 7.6 I was interested to see whether GVP 8.1 and GVP 7.6 components could co-exist on the same hardware. The good news is yes (with a bit of re-configuration).

The main area of conflict is (not surprisingly) the ports used for SIP and RTP. For GVP 7.6 (IPCS) we use port 5070 for SIP and ports 40000-49999 for RTP. These are configured in EMPS on the “SIP” tab of each Pop Gateway node and on the “General” tab of “MCU -> Media Controller -> NativeRTP” nodes as shown in the screenshots below:



To avoid any conflict therefore, for GVP 8.1 (MCP) I reconfigured the relevant options to use port 5080 for SIP and ports 50000-59999 for RTP. These are configured in CME application options in the “sip” and “MPC” sections on the relevant components as shown in the screenshots below:




Similarly, since we deployed GVP 8.1 Resource Manager components on the same servers as where SIP server components are installed (so that we could take advantage of Windows NLB clustering that was already in place for resilience) it was also necessary to change the SIP port range used by RM from 506x to 507x. Again these can be configured in CME options on the relevant component as shown in the screenshots below:




Finally, from a reporting perspective, the tables used by GVP 8.1 Reporting Server components are unique and therefore these can be installed on the same (existing) VAR database instance if required.