Enter MRA users, concurrent calls, and redundancy — get the recommended Expressway VM profile, node count per pair, and a pre-cutover checklist tied to Cisco's published capacity matrix.
Expressway is usually oversold (single Large VM for 300 users) or undersold (single Small for 2,000 MRA users). Both fail differently: oversold wastes hypervisor capacity, undersold crashes during a snow-day or pandemic when everyone is remote at once. This calculator maps your three real numbers — registered MRA users, busy-hour concurrent calls, and B2B call rate — onto Cisco's published Small / Medium / Large VM ceilings, and returns the VM profile, number of -C and -E nodes, and how many of those nodes need to survive a single-node failure. It also flags the traps: Webex Edge Audio adds measurable call rate, B2B SIP calling takes a disproportionate share of call licenses, and a single-node deployment should never reach production.
Enter your counts, click Size my Expressway.
2 vCPU / 6 GB / ~100 MRA users, 50 concurrent calls. Labs and pilots only.
4 vCPU / 6 GB / ~2,500 MRA users, 100 concurrent calls per node. Most mid-market.
8 vCPU / 8 GB / ~5,000 MRA users, 500 concurrent calls per node. Clusters to 30,000 users.
Expressway capacity is published by Cisco in two dimensions: registered users and concurrent calls. The trap is that most orgs size on registered users alone, because that's the number IT knows off the top of their head. A 1,500-user org that sizes for 1,500 MRA users typically picks a single Medium pair — fits Cisco's 2,500-user Medium ceiling, done. Six months later, on the first bad-weather day or a pandemic, concurrent calls spike past the Medium node's 100-call ceiling and the traversal server starts rejecting new calls. Users see "unable to start call" and call TAC.
The right order is to size on the higher-pressure dimension. For knowledge-worker organizations, that's usually concurrent calls at 10–15% of registered users. For contact-center-heavy orgs, it can be 25% or more because agents are on call most of the day. For healthcare, it depends on whether clinicians use Webex App for patient communication (low call rate, high registration) or for bedside consults (high call rate). The calculator asks for both numbers and picks the profile that satisfies the tighter ceiling.
B2B SIP calling adds another axis. Each concurrent B2B call consumes a traversal license on -E and spends proportionally more CPU than an MRA call because of the SIP normalization and media processing. A 100-call MRA environment + 30 concurrent B2B calls is not a 130-call environment for sizing purposes — it's closer to 160. The calculator applies that multiplier automatically.
Webex Edge Audio is a third axis. Hybrid calling is a Cisco-recommended pattern for orgs that want CUCM to keep calling control while Webex does the meetings. The call rate stays on-prem through CUCM, but the media traverses Expressway-E when the remote leg is a Webex user. For capacity planning, a hybrid user with Webex Edge enabled represents roughly 0.3× an MRA user in call-rate terms — not zero, not one.
The final consideration is redundancy. A single -C / -E pair can run production if your users don't mind an hour of downtime for patches. Most organizations don't have that tolerance, which means at minimum a 2+2 cluster. Above 5,000 MRA users or 500 concurrent calls, go directly to 4+4 — clustering is easier to add up front than retrofit while users are connected.
A Medium pair handles ~2,500 MRA users; a Large pair handles ~5,000. For more, cluster.
No. Size on both — pick the profile that satisfies the tighter ceiling.
Yes, for MRA or B2B. Single-node is only suitable for test / pilot.
Each hybrid user ≈ 0.3× an MRA user for call-rate capacity planning.
Yes — values are kept in sync with the Expressway Capacity and Sizing Guide.
500 MRA users, 50 concurrent calls, light B2B, 2+2 cluster.
5,000 MRA users, 600 concurrent calls, medium B2B, 4+4 cluster.
200 MRA users, 30 concurrent calls, 60 concurrent B2B calls.
The Network & UC Health Assessment includes an Expressway load review: pulled from your -C and -E logs, not estimated. We confirm VM profile, cluster health, and patch level.