Good progress on both fronts this week!
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.
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.