A Session Border Controller operates as a back-to-back user agent (B2BUA) at the edge of your enterprise network, terminating every inbound SIP session and re-originating a completely new one toward your internal IP-PBX. It’s the device that reconciles your private voice infrastructure with whatever the carrier sends you — different codecs, incompatible SIP headers, NAT-mangled addresses, and security threats embedded in signaling packets.
TL;DR: SBCs don’t just pass VoIP traffic through. They split every call into two independent legs — one facing the carrier, one facing your PBX — and translate between them. This B2BUA architecture is what makes NAT traversal, topology hiding, PSTN integration, and SIP normalization possible in a single device. Without it, your firewall is making decisions about voice traffic it fundamentally doesn’t understand.
How the B2BUA Architecture Processes a Call
The central mechanism that separates an SBC from a SIP-aware firewall is the B2BUA — back-to-back user agent. TelcoBridges documents this as the foundational architecture for any carrier-grade SBC. Where a SIP proxy forwards messages between endpoints, a B2BUA terminates the session entirely on one side and creates a brand new session on the other.
Here’s what that looks like mechanically. When a SIP INVITE arrives from your carrier — say PLDT or Globe — the SBC acts as the called party. It completes the SIP handshake (100 Trying, 180 Ringing, 200 OK) with the carrier as if it were the final destination. Then it generates a separate, independent SIP INVITE toward your internal IP-PBX, using completely different SIP headers, a different source IP, and potentially a different codec in the SDP body.
Two calls exist simultaneously: one between the carrier and the SBC’s external interface, and one between the SBC’s internal interface and your PBX. The SBC bridges the media (RTP audio streams) between them. If you understand how SIP call flow and registration work, the B2BUA adds a critical layer: the carrier never sees your internal PBX’s IP address, and your PBX never deals with the carrier’s quirks directly.
This two-leg architecture is what enables every other SBC function. NAT traversal, header manipulation, topology hiding, codec transcoding — all of these depend on the SBC owning both call legs independently.
Signaling Normalization Across SIP Trunk Boundaries
Why do SIP trunks from Philippine carriers so often fail to interoperate cleanly with enterprise PBX systems? Because SIP is a protocol with enormous room for vendor-specific interpretation. The SIP RFC (3261) defines the structure, but carriers and PBX manufacturers implement headers, parameters, and extensions differently. An SBC normalizes these differences at the signaling layer.
Consider a concrete example. Globe’s SIP trunk may send caller ID information in the P-Asserted-Identity header, while your Yeastar PBX system expects it in the From header’s display name field. Without an SBC, that call arrives with no caller ID on your handsets. The SBC’s SIP manipulation rules rewrite the header on-the-fly — extracting the number from P-Asserted-Identity on the carrier leg and injecting it into the From header on the PBX leg.
This extends to dozens of parameters. Supported codecs listed in the SDP body may need reordering. The SBC can strip unsupported SIP methods from the Allow header to prevent 501 errors. Session timers (RFC 4028) that the carrier enforces at 1,800-second intervals might conflict with your PBX’s default of 3,600 seconds — the SBC normalizes these to prevent mid-call disconnections.
For BPO call centers in Metro Manila handling 200 to 500 concurrent sessions, even a 2% SIP interoperability failure rate means 4 to 10 active calls dropping or failing to connect at any given moment. The SBC eliminates this class of problem entirely by ensuring each side of the B2BUA speaks exactly the SIP dialect the other expects.
NAT Traversal and Media Anchoring
NAT traversal is the problem that drives most Philippine enterprises to discover they need an SBC in the first place. If you’ve dealt with one-way audio or dropped calls caused by NAT, you’ve already encountered the symptom. The SBC is the purpose-built cure.
The core issue: SIP embeds IP addresses and port numbers inside the message body (the SDP section), not just in the IP packet headers. When a SIP INVITE passes through a NAT device — your firewall, your router — the packet’s source IP gets rewritten, but the SDP body still contains the original private IP address (192.168.x.x or 10.x.x.x). The remote carrier sends RTP media to the address listed in the SDP. That address is private, unreachable from the internet. Audio fails in one or both directions.
NAT traversal is a collection of technical solutions — STUN, TURN, ICE — designed to work around this. SBCs implement a more direct approach: media anchoring. Because the SBC terminates both call legs, it rewrites the SDP body on each leg with its own interface addresses. The carrier sends RTP to the SBC’s public IP on port ranges typically spanning 10000 through 20000. The PBX sends RTP to the SBC’s private interface IP. The SBC relays packets between the two.
This eliminates NAT traversal as a problem category. Your firewall doesn’t need SIP ALG (which frequently causes more problems than it solves). Your router doesn’t need special UDP timeout configurations to keep media pinholes open. The SBC’s external interface has a public IP; its internal interface sits on your LAN. RTP flows to known, fixed addresses on both sides.
Warning: SIP ALG on your enterprise firewall should be disabled when an SBC is deployed. Having both active creates conflicting NAT rewrites — the ALG modifies headers that the SBC has already corrected, resulting in call failures that are extremely difficult to diagnose from packet captures alone.
Topology Hiding as a Security Function
An access SBC sits between external networks and an enterprise’s internal voice infrastructure, protecting IP-PBX systems, unified communications platforms, and contact centers from the public internet. The B2BUA architecture makes this protection inherent rather than bolted on.
Because the SBC terminates the carrier-side call leg and originates a new internal leg, the carrier — and anyone intercepting traffic on the carrier side — sees only the SBC’s external IP address and its SIP identity. Your internal PBX’s IP address, your extension numbering plan, your internal subnet structure, the make and model of your IP-PBX (often revealed in the User-Agent SIP header) — none of this information reaches the public network.
This matters for Philippine enterprises more than the generic security argument suggests. The CVE-2026-20230 vulnerability in Cisco Unified Communications Manager demonstrated how attackers use SIP reconnaissance to identify specific PBX software versions before launching targeted exploits. An SBC strips or replaces the User-Agent header, the Server header, and any other identifying information before traffic leaves your network.
Beyond topology hiding, SBCs enforce signaling-layer security through TLS 1.2 or 1.3 for SIP transport (port 5061 rather than the unencrypted 5060) and SRTP for media encryption. They also implement rate limiting on SIP requests — blocking registration floods, INVITE floods, and OPTIONS scanning that would overwhelm an exposed PBX. For a government agency or hospital that can’t afford voice service interruption, these protections represent a meaningful security boundary.
The carrier never learns your internal PBX’s IP address, your extension numbering scheme, or your voice platform’s software version. The SBC replaces all of it with its own identity before any packet crosses the network border.
PSTN Fallback and Codec Transcoding
SBC VoIP gateway configuration becomes especially important in Philippine networks where PSTN integration remains a hard requirement. Government agencies under DICT often maintain analog lines for continuity. Hotels and hospitals keep PSTN trunks as failover paths. BPO operations need local DID numbers routed through carrier PSTN gateways.
AudioCodes documents PSTN fallback as a core SBC function — the SBC monitors SIP trunk health through keep-alive mechanisms (typically SIP OPTIONS pings sent every 30 to 60 seconds) and reroutes calls to a PSTN gateway when the primary trunk fails. The failover decision happens in under 3 seconds on most SBC platforms, compared to the 30 to 120 seconds a PBX-level failover typically takes to detect trunk failure and reroute.
Codec transcoding sits alongside this. Your internal PBX may run G.711 (64 kbps per call, excellent quality) across the LAN where bandwidth is cheap. But your carrier’s SIP trunk, especially over a Philippine DSL or fiber connection shared with data traffic, may negotiate G.729 (8 kbps per call) to conserve bandwidth. The SBC transcodes between them in real time — receiving G.711 from the PBX, encoding it as G.729 for the carrier leg, and reversing the process for incoming calls.
This transcoding load is meaningful. Each transcoded call consumes DSP (digital signal processor) resources on the SBC. A Makati BPO running 300 concurrent calls with full G.711-to-G.729 transcoding needs an SBC with DSP capacity for 300 simultaneous transcode sessions. If you’ve already done bandwidth budgeting for your VoIP migration, the SBC’s transcoding capability determines whether those bandwidth calculations hold up in production.
For sites that still maintain analog phones connected through ATAs, the SBC provides a clean integration point — the ATA speaks SIP to the SBC, and the SBC normalizes that traffic before passing it to the IP-PBX, handling any protocol quirks the ATA introduces.
Sizing an SBC for Philippine Enterprise Traffic
TechTarget recommends using current system statistics — specifically the number of packets passed — as the baseline for sizing SBC capacity. For Philippine enterprises, this translates into three concrete metrics: concurrent call sessions, calls per second (CPS), and whether transcoding is required.
| Deployment Type | Concurrent Sessions | Calls Per Second | Transcoding Required | Typical SBC Platform |
|---|---|---|---|---|
| Small office (20-50 users) | 10-25 | 2-5 | Rarely | Software SBC or VM appliance |
| Mid-size enterprise (100-300 users) | 50-150 | 10-30 | Often (G.711 to G.729) | Dedicated hardware SBC |
| BPO call center (500+ agents) | 200-500+ | 40-100+ | Almost always | High-capacity hardware SBC with DSP cards |
| Multi-site government agency | 100-400 across sites | 20-60 | Mixed | Centralized SBC with distributed SIP trunks |
Microsoft’s documentation on SBC deployment emphasizes configuring both IP interfaces — one for your internal network, one for the external connection — as the fundamental configuration requirement. This dual-homed setup requires proper structured cabling between your server room and network core, with the SBC’s external interface connecting to your WAN router or firewall’s DMZ, and the internal interface connecting to your voice VLAN.
Before deploying an SBC, a VoIP network readiness audit should capture your peak concurrent call volume, your carrier’s supported codecs and SIP parameters, and your current NAT topology. These three data points determine the SBC model, licensing tier, and configuration profile you need.
Tip: When sizing for a BPO deployment, don’t use average concurrent calls — use the 95th percentile from your busiest month. A 200-session SBC license that hits capacity during peak hours forces new calls to fail with SIP 503 (Service Unavailable) responses, which is worse than no SBC at all because the PBX can’t fall back to direct trunk registration.
Where the SBC Model Breaks Down
The B2BUA architecture introduces a single point through which all voice traffic must pass. If the SBC fails, every call in progress drops and no new calls connect. Hardware SBC appliances from AudioCodes, Ribbon, or Oracle (formerly Acme Packet) support high-availability pairs — active/standby configurations with sub-second failover — but the HA pair doubles your hardware cost and your configuration complexity.
Encryption creates another constraint. TLS for signaling and SRTP for media add CPU overhead. An SBC rated for 500 concurrent sessions in clear-text mode may handle only 350 to 400 sessions with full TLS/SRTP enabled. Philippine enterprises running Microsoft Teams Direct Routing, where TLS and SRTP are mandatory, need to size their SBC against the encrypted capacity rating, not the headline number.
Transcoding at scale is the third limitation. Each transcoded session consumes dedicated DSP resources that can’t be shared. A BPO center that grows from 300 to 450 concurrent calls doesn’t need 50% more SBC capacity — it may need a completely different hardware tier because DSP resources are allocated in fixed blocks.
And the SBC doesn’t solve problems that originate elsewhere. Jitter, packet loss, and latency caused by underprovisioned WAN links or missing QoS policies will pass through the SBC unchanged. The SBC can prioritize voice packets on its own interfaces, but it can’t fix a congested MPLS circuit between your Cebu branch and your Manila carrier POP. Those problems require QoS configuration at the router level across every hop in the path.
The SBC is the right tool for the network border — for reconciling incompatible SIP implementations, anchoring media across NAT boundaries, hiding your voice topology from the public network, and managing PSTN fallback. It is not a substitute for proper network design, adequate bandwidth, or end-to-end QoS. Treat it as the border device it is: powerful at the edge, invisible to everything behind it, and dependent on the infrastructure it sits on top of.
