Performance Test Update

Just a quick update – we are very nearly there!

In the last test we have managed to get to 10 calls per second (CPS). This was achieved by injecting calls directly into a seperate Avaya SES server.

The issue we now see is that the Avaya S8730 Media Server (aka ACM main brain!) hits high CPU (occupancy) which slows everything down and results in new calls being rejected. The resulting behaviour is normal in so much as CPU proriity is given to call processing (CALPRO process) rather than administrator and maintenance processes.

Analysis by Avaya support suggests that the problem is down to the number of AES / CTI links we have to other adjunct systems such as Verint Voice Recording.

CM Service Pack 5 has been suggested as this gives approx. 20% better CPU utilisation on a S8730. However, the root cause will need further investigation e.g. stop non-Genesys adjunct links and re-test. Also we will try increasing the Avaya T-Server query timer from 3 seconds to 10 seconds.


Genesys Test Utility (GTU)

Finally got round to adding a GUI to my Genesys Test Utility (GTU).

GTU is a simple Microsoft Windows application which allows telephony commands to be executed either on a single extension or ACD login or concurrently on a group of extensions or ACD logins.

Test Advisors are configured in the “agents.xml” configuration file. The format of this file is exactly the same as for Empirix VAS (Virtual Agent Simulator).

Also took the opportunity to add some new features such as:

  • View attached data (CAD)
  • Query DN state
  • Configurable Test profiles


Here are some more screenshots:





OAT and Performance Test Update

Good progress on both fronts this week!

Default Routing

We had a defect when testing a failure scenario with URS down. Basically calls were not being (Avaya) default routed.

We had SIP T-server options default-dn and router-timeout both configured. After 10 seconds, (router-timeout) response status “302 Moved Temporarily” is sent back to SES. However, a TAC trace on ACM showed that the call is not re-routed and the channel goes IDLE. This is the preferred solution but for some reason Avaya CM does not process “302 Moved Temporarily” correctly.

As an alternative solution we configured Look Ahead Routing (LAR) set to “next” on the Avaya route pattern which puts the call on to a SIP trunk to Genesys in the first place. With this configuration, after no response on SIP Server after 2 seconds and before the Genesys router-timeout expires, ACM cancels the call and tries another Trunk Group.

Once all the trunks configured in the route pattern have been tried the call now drops into the next vector step and is default (Avaya) routed. In our configuration with have 4 Trunk Groups so the call is now default routed after 8-9 seconds.

SES Crashes

During an Empirix performance test this week we managed to crash SES. This was resolved by installing Service Pack SP4a on top of the current version (SES 5.2.0 SP2a).

SIP Trunk Utilisation

We did some tweaking of Trunk Group members and SES Media Server address maps this week.

In our configuration, a SES Media Server address map exists for each Media Server (CLAN interface). Each CLAN interface is associated with an ACM signaling group and trunk group on a 1:1 basis. Each trunk was defined as two-way and each had 250 members.

Even though a CLAN interface can technically support 400+ SIP trunks (channels) it is only possible to configure up to 255 members in each trunk group. Therefore we needed to add some additional “shadow” trunk groups configured with the same Near-end node name e.g. CLAN interface to be able to increase the number of channels assigned to that CLAN.

On the SES end, Address Map Priorities assign a priority to each address map. This priority determines the order in which the proxy tries to match an incoming call pattern to an address map pattern. For example, if an incoming call pattern matched 4 address map patterns, the proxy would route the call to the address map with the higher priority. This does not take into account the utilisation of the underlying Media Server (CLAN). Therefore the first matching address map will always be used.

To allow for this during Empirix performance testing whereby we are injecting calls directly in SES we needed split out the address maps into different number ranges and assign each of these maps to a separate CLAN interface.

This is the final configuration we came up with:


UPDATE: Further testing has shown a problem with this configuration and we are now moving to a configuration with a completely separate / standalone SES server to inject Empirix calls in to.