Category Archives: UK Utility Company

GVP 7.6 License Keys

We are using GVP 7.6 as the IVR on this project and last week I managed to break one of our IPCS servers as a result of some network changes. GVP 7.6 is based on a product from Telera and as such the license keys are not based on FLEXlm as is the case for the rest of the Genesys suite.

For GVP 7.6 the license key is generated by the IPCS setup and is based on the MAC address of the NIC card in the server.

Image

In our case the MAC address had changed and therefore the license validation started to fail. Given that this could happen operationally due to a NIC card swap or NIC teaming failure (http://www.howtonetworking.com/Networking/nicteam1.htm) I asked Genesys how to regenerate the license key. “Reinstall” was their only answer (and still is!).

Since the original installation was a complete pain as well as the associated EMPS configuration I thought that I would try to find a solution other than a complete reinstall.

A hunt through the binaries seemed to reveal the answer in some VAR PHP code in the file ‘vwm_start_setup.php’ – the encryption is based on the DES algorithm using ECB as the cipher and a secrey key that can be found in plain text within that file.

A bit of C# .NET code worked both ways on the default VAR password ‘vareports’ which is encrpyted as ‘SaEhZ8yoqDYz02y5HxG8qA’:

Image

However, when I tried the same encryption on a MAC address I did not get the correct results. I also noticed that encrypted VAR passwords are 192 bits whereas encrypted license keys for IPCS are 160 bits. Damn!

Maybe the encrpytion routines are different between VAR and IPCS and were created by different developers at Telera? Back to the drawing board.

Next, I did some disassembly of the IPCS installation code in ‘CNSetup.dll’ and found that standard Microsoft Crypto API’s we being used:

Image

An RSA crypto provider is obtained and an MD5 hash created:

Image

The MAC address from the NIC is added to the hash:

Image

A session key is created based on the MD5 hash of the MAC address. The value ‘26625’ tells me that the algorithm is RC2:

Image

Finally, the data is encryped using the session key:

Image

OK, I now had all the information and tried it in some C# .NET code:

Image

It’s not quite working yet and think the expected result will be a string starting ‘TELERA’. Hopefully I can get it working next week and save myself a painful re-install. Will keep you posted.

Share

T-Library Protocol

Writing a T-Lib client using either the old (unsupported) T-library or newer Platform SDK is a fairly easy task and the complexity of the underlying wire protocol is not an issue.

However, what if you need to write a T-Lib server component?

You may ask why we might need to do this.

As part of this project we need to integrate Verint Impact 360 / Blue Pumpkin workforce management with Genesys to replace the existing integration via CMS. Out of the box Verint provide real-time adherence integration via their CSTI adapter for Genesys. However, the client already has an number of advisor activities defined based on the Avaya event stream and there is no 1:1 mapping for this to the T-server event stream.

As a workaround for the first phase of the project we have developed a custom Advisor desktop which allows us to set ACW codes via a ReasonCode in the extensions attribute of the Genesys CTI events. These are then picked up by some customisation in the Verint CSTI adapter.

However, in the next phase of the project we will be replacing the custom desktop with a vanilla SAP WebIC client and to set the ReasonCode would require major enhancements in SAP (and it not a good idea in terms of future releases).

Therefore, one alternative would be to develop a T-Lib server component that sits between the Verint CSTI adapter and the real T-Server component and ‘manipulates’ the CTI event stream accordingly based on an internal state machine (SCXML). This way we could use the standard Verint and SAP components OOTB.

As a proof of concept I decided to examine the T-library protocol based on some wireshark traces:

T-Lib

After some analysis and with reference to ‘tlibrary.h’ from the old C-based T-lib I think that I have worked out most of the protocol and put together some C# .NET code to test it:

Image

Image

The bottom line is (ignoring support and other commerical issues) that technically such a solution is possible. I’m not sure whether we will need to use this solution but thought that I would share my findings with you anyway.

Share

Avaya SIP Interoperability

For this client our target architecture is based on Avaya Communication Manager in an ESS configuration acting as a single logical switch. We are using Genesys 7.6 components for IVR and in-queue treatments. The Genesys side is all SIP based e.g. GVP and Stream Manager. Effectively the Avaya and Genesys sides are seperate switches and we use external routing between them.

We have been having numerous problems with calls being dropped after 32 seconds – the standard SIP session timeout. We have fixed most of these problems but a SIP trace using wireshark (http://www.wireshark.org/) reveals that SIP interoperability is not 100% correct and the biggest problem is that SIP T-Server stays in the signalling path even when the call has been routed to a target back on the Avaya switch. This means that all calls in progress are dropped if we lose SIP T-Server e.g. a single point of failure.

We has been running CM5.1 with SIP Server 7.6 and the recommendation from Avaya and Genesys is to upgrade to CM5.2 and SIP Server 8 respectively. For information to upgrade to SIP Server 8 new license features are required including 8.0 ISCC and HA.

This week we thought that we would start by upgrading to CM5.2. Having done this we could not even get calls onto the SIP trunks – SES logs showed nothing. The upgrade process seemed to work OK and we checked and double checked all the settings. Still no joy.

Eventually we managed to get Avaya support involved and the problem seems to be related to SIP domain names. Basically, the domain name we had been using was not a valid fully qualified domain name (FQDN) e.g. ‘mysipdomain.com’. Whilst it was OK in CM5.1 it looks as though additional validation has been added in CM5.2.

If you are planning to upgrade to CM5.2 make sure you check you current SIP domain name is the places shows below!

Image

Image

Image

Share

Avaya Login and Station Settings

We have been doing quite a bit of playing about this week to establish the best settings for auto answer given that we are using TSAPI and therefore ‘route-thru-queue’ is not supported 🙁

For now the best combination seems to be:

  • Agent logins – set Auto Answer = ‘all’
  • Stations – Answer = ‘acd’

A combination of the above seems to work the best but we still have a problem with a single ring before the call is answered. Looks like we need to modify the IP handset boot configuration to solve this.

Image

Image

Share