2nd one. But, be current. Either way, the SBC is loosely tied to Aura releases. R8 SBC came out in the last few weeks, so there are plenty of 8.x Aura systems with 7.2 SBC. There are also plenty of 6.3 Aura systems with 7.2 SBC.

And generally you have entitlements for a release, and 7:1 users/sip trunks

So, if you ordered 700 Aura Core users at R7, you'd have an entitlement for 100 standard sessions of SBC. You buy advanced sessions for anything more than trunking, but they require a standard session first.

So, if you had 100 standard SBC sessions, you could have 100 SIP trunk calls up. If you had 100 advanced sessions as well, you could have 100 SIP trunk calls up and that's it because you have no more standard sessions for the advanced sessions to ride on top of. If you had 100 std+100adv, you could have 50 SIP trunk calls up and 50 remote workers.

Trunk calls use a license for the duration of the call. Remote worker sessions use a license for the duration of the registration even when they're not on a call :)

Most of my licenses are housed on SMGR, including another regions SBC. I was told by the BP that I could not separate another new set of SBC licenses on that SMGR and that they would just get combined with the other and I'd have to have another WebLM. Quite annoying. I found a standalone WebLM download on the support site under SMGR. Does that version matter in regards to the version of the SBC? Not really finding info on WebLM. Probably going to install SBC7.2.x and the WebLM version I found was 7.1.

That's fine. SBC 7.2 was out for a long time and is contemporary to SMGR/WebLM 7.1. You only get into trouble with "which WebLM" version when it's way older and some other security things change like how the licenses do their secret handshake and SSLv3 perhaps being offered by a old WebLM and new stuff outright rejecting to communicate with it.

I think the reason your BP said you need another is because the SBC is too stupid to use WebLM properly. It's smart enough to check and see that there's a license file for a SBC with 100 sessions but not smart enough to check those licenses out, so I can go in the lab and install 10 SBCs and point them all to the same WebLM and they'll all be happy.

Very vague question here. Remote worker is a nebulous phrase. Using 96xx/96x1 versus AAfD, VDI Communicator versus Equinox client for Windows, Android, iOS and MAC all have various nuances and it all depends on which specific services you are going to need/use.

As kyle555 notes, newer is better. 7.2.2.1 is stable and not too many one-off configuration issues. Relay services, Utility Services versus Avaya Aura Device Services, CES for Visual Voicemail on iOS/Andoid, EWS, etc. are all going to play into this.

Certificate requirements are not very clear. Previous versions of Utility Services obtained their web certificate from RFA. Now you can obtain the certificate from System Manager or other CA. for reverse proxy services the nginx instance on the SBC will need to validate the certificate so Subject Alternate Names and DNS are critical items to address.

I've been reading the 'Deploying Avaya Session Border Controller in VE' cover to cover and am a bit confused. Surprised? When deploying the SBC OVA and choosing SBC+EMS I'm not clear what the sequence of steps is after that. Is the install utility intuitive enough to take me through the EMS setup and then SBC? Then as far as the interfaces is it A1,A2,B1,B2, M1 (EMS) and then another mngt for the SBC? While the doc has a lot of information it's bloody confusing.

I can't remember, but sometimes vCenter doesn't pickup the provisioning template on OVA deploy, so you just push a dumb image, boot, open console, Welcome to SBC! Let's go thru first time setup!

IP/gateway/subnet/dns for the mgmt interface, get into the Web and that's where you "commission" the SBC software that's included in the image and get the rest of the menu options - like 'enabling' the A1/B1 networks and assigning them IPs and stuff
Find the fixweblm script on the support site - it'll always complain that it can't connect to WebLM when you punch it in the webpage the first time because it doesn't trust the HTTPS cert.
Run that script in the CLI and it'll import the cert and play nice with the license server.