AEP-SM Load Balancing
Now, if that title doesn’t grab your attention, then I don’t know what will! Whilst it doesn’t sound like the most interesting news in 2020, this had a number of associates stumped so we figured it was worth a blog, with the added bonus of some nice pictures.
Public Service Announcement: IP address and phone numbers were changed to protect innocent!
Load-balance what?
The genesis of this blog was to meet a requirement I was tasked with around a new IVR deployment. Our customer had:
- Dual data centers with dual SBCs for PSTN access
- A new flagship speech-enabled IVR app we developed for their main business unit
- Avaya Experience Portal (AEP) and LumenVox ASR/TTS in each data center
- System Manager (SMGR)
- Session Managers (ASM) in each data center
- Carrier-managed SBCs
- Passing of UUI data to agents for screenpop – UUI in this case used a REFER method, which caused the carrier-managed SBCs some grief
What I needed to be sure we could do was:
Load balance the calls 90/10 across their primary and backup data centers on a sunny day, regardless of which SBC the call came in on
Change the load balancing from 110/0 or 0/100 or anywhere in-between; this would allow for planned maintenance, system upgrades, code drops, or for giggles during the busiest time of the busiest day
Grab individual DIDs and point them to each AEP – one in primary and one in backup Data Center, so we could throw calls at a specific AEP as needed
Additionally, make sure to have DIDs that terminate on each of the SBCs
Let’s summarize the places we had to visit, then dive in to each one:
- SMGR – Local Host Name Resolution (LHNR)
- SMGR – Entities for the new LHNR entries
- SMGR – Entity links
- AEP – VoIP Connections
- SMGR – Routing Policy
- SMGR -Dial Patterns
if you are wondering why I jumped to AEP at step 4 and didn’t finish in SMGR first, I get easily distra-SQUIRREL!
Local Host Name Resolution
Here I created entries in the Local Host Name Resolution table within SMGR.
“sitea.vt.local” has 2 entries:
SiteA MPP1 – 192.168.20.101 using TCP port 5060 with Weight of 50
SiteA MPP2 – 192.168.20.102 using TCP port 5060 with Weight of 50
“siteb.vt.local” has 2 entries:
SiteB MPP1 – 192.168.30.101 using TCP port 5060 with Weight of 50
SiteB MPP2 – 192.168.30.102 using TCP port 5060 with Weight of 50
“production.vt.local” has 4 entries:
SiteA MPP1 – 192.168.20.101 using TCP port 5080 with Weight of 45
SiteA MPP2 – 192.168.20.102 using TCP port 5080 with Weight of 45
SiteB MPP1 – 192.168.30.101 using TCP port 5080 with Weight of 5
SiteB MPP2 – 192.168.30.102 using TCP port 5080 with Weight of 5
In our solution, each AEP had two MPPs (MPP1 & MPP2). So routing calls to Site A (primary DC) meant sending them to each MPP load-balanced 50/50.
The production.vt.local – this is the main FQDN we will route our calls to in order to achieve 90/10 load balancing. As you can see, at Site A, both MPPs take 45% of calls, and at Site B both MPPs take 5% of calls.
Side note: Session Manager load-balancing is not an exact science. If I place ten calls, I would expect 9 to be handled by Site A and 1 by Site B. In reality, Session Manager will match this fairly closely, if you look over 100 calls, it might be nearly 90/10 but not exactly, if you look over 1000 calls it might be nearly 900/100, but not exactly. This is just how ASM works, there isn’t much we can do about it and it’s unlikely to get you fired.
This is how it looks in SMGR:

Entity and Entity Links
Navigating to Entities in SMGR, we now need to add each entity, this should be straightforward enough, so I will just show the summary screen:

For entity links, these again are straightforward, so here’s the summary screen from SMGR:

AEP VoIP Connections
Here we need to add 4 SIP Proxy Servers with the respective IP addresses and ports, see our example below:

Once you hit Save, you should see a summary screen like this:

Routing Policy
We need to build three routing policies:
– To Site A AEP
– To Site B AEP
– To Production AEP
Here is a detailed view of the Production AEP routing policy:

The summary of all three routing policies is shown here:

Dial Patterns
With all the various items correctly added, we now need to point our DIDs to each of the routing policies. In your situation, you may have Toll Frees instead of DIDs, but you hopefully are still following along! Add the dial pattern so it looks similar to the information below:
For Site A DID

For Site B DID

For Load-Balanced DID

So you are now set up with a load-balanced DID across to AEPs, and 2 additional DIDs that you can use to ensure you reach a specific AEP for testing purposes.
And finally…
AUTHOR

Carl is has worked in the Telecom space for a long time, and knows many different PBX systems really well. He’s an avid RTFMer, and more recently has started a new hobby of glamping.