A session border controller manages a SIP connection across a boundary between calling systems or networks. Start by drawing that boundary, identifying who operates each side, and deciding which signaling and media functions belong there. Then size and test the actual call mix.
This guide is for IT planners comparing an on-site appliance, virtual SBC or provider-managed service. Basic knowledge of SIP signaling and RTP audio is helpful. Capacity figures in the worked exercise are fictional planning inputs, not product ratings.
Draw the boundary and both paths
A common enterprise arrangement
PBX or calling platform ⇄ SBC ⇄ carrier SIP service
Management system → restricted SBC administration interface
Draw a signaling route and a media route separately. In a media-anchored design both traverse the SBC. Other supported designs send media along a different path. Label actual interfaces, network zones and owners on the implementation drawing.
The IETF’s RFC 5853 describes SBC deployment functions and their architectural tradeoffs. Common functions include policy enforcement, topology hiding, signaling interworking and media handling. An SBC may terminate one SIP dialog and originate another, so traces on opposite sides can have different identifiers and message details.
A useful drawing answers four questions: where does a new call enter, who authorizes its destination, where does audio cross networks, and who can change those rules? Include an analog or digital gateway separately when legacy telephone interfaces are involved, even if a single product provides both roles.
As one platform-specific example, Microsoft Teams Direct Routing planning guidance requires a supported, certified SBC and describes signaling, certificates, media connectivity and support boundaries. Use the current platform and carrier guidance together; a generic SIP feature list leaves important interoperability questions unanswered.
Turn each desired function into an observable requirement
Swipe horizontally, or focus the table and use the arrow keys.
| Function | Decision to document | Acceptance evidence |
|---|---|---|
| Routing and admission | Allowed sources, destinations and traffic limits. | Authorized calls succeed; controlled disallowed attempts are rejected and logged. |
| SIP interworking | Which headers, number formats and supplementary services require adaptation. | Inbound/outbound calls, caller ID, hold and transfers work across the boundary. |
| Media anchoring | Where audio should flow and why. | Observed media addresses and both audio directions match the diagram. |
| Transcoding | Required codec pairs and simultaneous conversion load. | Calls use the intended formats under the planned workload. |
| Encryption | Which legs use TLS and SRTP, and where keys or clear media exist. | Configuration and traces establish the intended protection on each leg. |
| Operations | Monitoring, certificates, updates and incident ownership. | Alerts arrive, logs correlate across legs, and recovery is rehearsed. |
Treat this table as an acceptance template. The chosen product and configuration determine which functions are available. Encryption on individual legs can involve decryption at the SBC; describe the complete trust boundary to anyone relying on confidentiality. A security feature requires maintained policy, credentials, software and monitoring to serve its purpose.
Size concurrency, bursts and media work separately
Concurrent sessions describe simultaneous call workload. Calls per second describe the arrival rate of new attempts. Long conversations can produce high concurrency with modest arrivals; a short burst of unsuccessful attempts can stress signaling with little sustained audio. Ask each supplier how it counts a session, a call leg, a recording stream and a rejected attempt.
Fictional design brief: 240 active calls
A site expects a busy-period peak of 240 concurrent external calls. Its planning team chooses 25% additional capacity for this exercise: 240 × 1.25 = 300 concurrent calls. The 25% is a local assumption to test, not an industry rule.
A measured scenario contains 90 new call attempts within five seconds: 90 ÷ 5 = 18 attempts per second on average over that interval. The team keeps one-second counts as well, because the five-second average can hide a sharper burst.
Assume 30% of the planned 300 calls require the specified codec conversion: 90 simultaneous transcoding calls. If 40% require recording, that is 120 recorded calls. Some calls belong to both groups; these requirements overlap and must be tested together.
Send the supplier the codec pairs, encryption on each leg, packetization, media anchoring, recording method and busiest burst trace. Request a supported configuration that can sustain that combined profile. Storage and recording-server capacity belong in the recording plan; additional SIPREC work at the SBC belongs in its load test.
Vendor documentation shows why one headline number is insufficient. AudioCodes’ Mediant 4000 specifications distinguish session capacities for different media-encryption combinations, while its OVOC 8.4 license documentation distinguishes SBC and transcoding entitlements. Obtain current limits for the exact hardware or virtual resources, release and licenses in the quotation.
For virtual deployments, include reserved compute resources, network interfaces and the hosting platform’s supported configuration. A nominal vCPU count alone leaves scheduling contention and other workloads unaccounted for. Ask the vendor to validate the proposed environment and collect its resource metrics during the representative test.
Test the surviving system at the required load
Suppose the fictional site uses a two-node active/standby arrangement and must support all 300 planned calls after losing one node. The surviving node and its entitlements must support that requirement. The combined capacity of two nodes would answer a different question.
Document separately what happens to new calls and calls already in progress. State synchronization, routing convergence and media handling determine the latter. Agree the permitted interruption, test method and acceptance result with the supplier. Include dependencies such as carrier routes, DNS, certificates, network paths and power; two appliances can still share one failing dependency.
In a scheduled test, start a representative mix, trigger the approved failure scenario, and record surviving calls, dropped calls, successful new calls and recovery time. Repeat only the distinct failure cases in the approved plan. Restore normal service and verify that monitoring shows both nodes in the intended roles.
Make the procurement answer reviewable
Ask for a diagram, interoperability evidence for both neighbors, a workload-specific capacity statement, the complete license list, lifecycle support dates and a named escalation path. The proposal should assign ownership for certificates, firmware, backups, fraud controls and carrier troubleshooting.
Before acceptance, run ordinary inbound and outbound calls plus transfer, hold, keypad interaction, long calls and recording where required. Use authorized test destinations. Preserve timestamps, call identifiers on each side, selected codecs and observed media routes. For emergency routing, use the provider’s coordinated validation process. A successful ordinary call covers only that tested route.
Download the SBC planning and sizing worksheet. It carries the fictional calculations, blanks for measured traffic, and separate acceptance fields for normal operation and failure recovery.