SESSION BORDER CONTROLLER PLANNING AND SIZING WORKSHEET
Guide: https://yenra.com/session-border-controller/
Updated September 7, 2026

Purpose: request a supported SBC configuration for a defined workload and
test its normal and failure behavior. Complete with the platform, carrier
and SBC suppliers. All worked numbers below are fictional assumptions.
They are not product ratings, traffic forecasts or universal margins.

BOUNDARY AND OWNERS
Platform/PBX and release: __________ Carrier/service: ___________________
SBC model or virtual environment/release: _______________________________
Signaling path, addresses/zones and owner on each side: _________________
Media path and anchoring/bypass arrangement: ____________________________
Restricted management path/owner: ______________________________________
Supported interoperability evidence and date: ___________________________
TLS/SRTP legs, termination points and key/certificate owner: ______________

TRAFFIC INPUTS (include measurement period and units)
Peak concurrent calls: _______ Observation window/source: _______________
Chosen additional capacity and rationale: _______________________________
New attempts in five seconds: ______ One-second peak counts: ____________
Attempt counting method, including failures/retries: _____________________
Codec pairs and packetization: _________________________________________
Concurrent transcoding calls: _______ Concurrent recorded calls: _________
Overlap between features, encryption and recording method: _______________
Vendor definition of session/call leg/recording stream: __________________

FICTIONAL CALCULATION
240 peak calls x 1.25 = 300 planned concurrent calls.
90 new attempts / 5 seconds = 18 attempts per second over that interval.
Keep one-second data: a five-second average can hide a sharper burst.
300 x 30% = 90 simultaneous calls requiring the specified transcoding.
300 x 40% = 120 recorded calls. Transcoded and recorded groups may overlap.
Request support for the combined workload, not isolated feature maxima.

CAPACITY RESPONSE
Exact hardware/VM resources, release and hosting support: ________________
Session/transcoding/recording licenses and expiry: ________________________
Supported combined profile and supplier evidence: _______________________
Measured CPU, memory, media and signaling results at target load: _________
Additional dependencies, including recording server/storage: _____________

RESILIENCE
Mode and failure case: __________ Surviving-node requirement: ___________
For an active/standby pair in the fictional example, one surviving node
must support 300 calls if full planned capacity is required after failure.
New-call behavior requirement: _____ In-progress-call requirement: _______
Allowed interruption and approved test method: __________________________
Shared power, network, DNS, certificate and carrier dependencies: ________

ACCEPTANCE RECORD
Test inbound/outbound calls, identity, hold, transfer, keypad entry, long
calls, both media directions and recording where required. Use authorized
destinations and coordinated provider procedures for emergency routing.
In the scheduled failure test, record surviving calls, dropped calls,
successful new calls, alerts and recovery time. Confirm restored roles.
Test ID/time zone: ________ Expected/actual: ________ Evidence: __________
Open issue/owner: _________ Retest: __________ Decision/date: ____________

Source context: RFC 5853 describes SBC deployment functions and tradeoffs.
Platform certification, licenses and capacity depend on exact versions.
https://www.rfc-editor.org/rfc/rfc5853.html
https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan