Every SIP trunk connecting a Philippine enterprise PBX to an external carrier should pass through a Session Border Controller deployed in the network DMZ. Skipping this step exposes internal IP addresses, invites toll fraud, and removes the single enforcement point that governs call quality, encryption, and enterprise call routing between your voice network and the outside world.
TL;DR: A Session Border Controller belongs in the DMZ between your PBX and your SIP trunk provider. Deploy it in an active/standby or active/active pair for VoIP failover architecture, enforce TLS and SRTP at the border, and plan separate SBC instances for each carrier interconnect. This article covers placement models, failover patterns, and vendor considerations for Philippine enterprises.
Why the DMZ Is the Only Correct Placement
The SBC sits in-line between a company’s VoIP network and the external voice network. When a call is made, the SBC establishes signaling protocols between the enterprise and the carrier that will carry the voice traffic, as described in Mushroom Networks’ SBC primer. This in-line position makes the DMZ the natural and necessary home.
Placing the SBC inside the DMZ achieves three things. First, topology hiding: the SBC rewrites SDP headers so external parties never see internal IP addresses. Second, media anchoring: RTP streams pass through the SBC, which enables SRTP encryption and NAT traversal. Third, policy enforcement: the SBC applies rate limits, codec rules, and access controls before any SIP traffic reaches the PBX.
A common mistake in Philippine deployments is placing the SBC behind the firewall on the same VLAN as the PBX. This defeats the purpose. The SBC needs at least two network interfaces: one facing the carrier (the external leg) and one facing the internal PBX (the trust leg). Ribbon’s deployment documentation describes configurations where each SBC is set up on two different networks plus a management network, with each network on a separate untagged access interface. Separating these interfaces prevents a compromise on one leg from reaching the other.
For organizations that also run Fortinet security solutions at the perimeter, the SBC should sit in a separate DMZ segment from web-facing servers. Voice traffic has strict latency requirements (under 150 ms one-way for acceptable call quality), and sharing a firewall inspection zone with HTTP traffic introduces unpredictable jitter.
Three Deployment Models for Multi-Site Enterprises
Philippine enterprises with offices in Metro Manila, Cebu, and Davao face a fundamental design decision: centralize the SBC at one data center, distribute SBCs to each branch, or run a hybrid of both. Each model trades cost against call quality and resilience.
Centralized core SBC. All SIP trunks terminate at a single SBC cluster in a primary data center. Branch offices send voice traffic over MPLS or SD-WAN links to the core. This model costs less in licensing (fewer SBC instances) and simplifies management. The tradeoff: every call from a Cebu agent to a local Cebu number hairpins through Manila, adding 20 to 40 ms of round-trip latency depending on WAN conditions. For enterprises handling under 500 concurrent calls across all sites, this is often acceptable.
Distributed edge SBC. Each major site runs its own SBC instance with a local SIP trunk from the regional carrier. A Cebu office’s calls to Cebu landlines stay local, with latency dropping to under 5 ms. The cost: you’re licensing and managing 3, 5, or 10 SBC instances instead of 1. This model suits BPO operations where call quality directly affects client SLAs.
Hybrid model. A core SBC handles inter-site routing and centralized carrier interconnects while lightweight edge SBCs at branches handle local breakout and provide survivability if the WAN link to the core fails. This is the pattern most Philippine banks and hospital networks are adopting, especially when consolidating multiple PBX systems across sites.
| Model | Max Concurrent Sessions | Local Call Latency | SBC Instances Needed | Best For |
|---|---|---|---|---|
| Centralized Core | Up to 100,000 (Oracle Acme Packet cluster) | 20–40 ms via WAN | 1–2 | Mid enterprises, under 500 concurrent calls |
| Distributed Edge | 60,000 per server (TelcoBridges ProSBC) | Under 5 ms | 3–10+ | BPOs, call centers with local carrier trunks |
| Hybrid | Varies by tier | Under 5 ms local, 20–40 ms inter-site | 2–5 | Banks, hospitals, multi-branch government |
Active/Standby vs. Active/Active Failover
VoIP failover architecture for SBCs follows two primary patterns. Which one fits your environment determines whether calls drop during a hardware failure.
Active/Standby (1+1). One SBC handles all traffic. A second unit monitors the primary through heartbeat messages. If the primary fails, the standby takes over within 2 to 5 seconds. Sangoma’s clustering documentation describes node states including ACTIVE, STANDBY, and UNMONITORED, where the standby node’s clustermon service isn’t running and failover cannot occur. The critical detail is stateful failover: the standby unit must preserve active calls during switchover. Without stateful replication, every in-progress call drops when the primary goes down. Cisco CUBE and Ribbon SBC 5400 both support stateful 1+1 failover.
Active/Active (N+N). Both SBCs process traffic simultaneously. A load balancer or DNS-based distribution splits incoming SIP registrations and calls across nodes. Oracle Acme Packet clusters support over 100,000 concurrent sessions using health-score-based failover, with sub-second recovery when one node degrades. This model works best when your enterprise handles more than 5,000 registrations per second, which is common after building-wide power restorations when every IP phone re-registers at once.
For most Philippine enterprises running 200 to 2,000 concurrent calls, active/standby provides sufficient protection at lower cost. Organizations running contact centers with 5,000 or more concurrent sessions should invest in active/active.
Geographic redundancy adds another layer. Placing SBC pairs in two separate data center facilities ensures continuity during localized disasters. Session state replication between sites keeps active calls alive even if an entire facility goes offline. This matters in the Philippines, where typhoons can knock out a single data center for hours or days. We’ve covered the broader principles behind intelligent failover design in a previous deep-dive.
SIP Trunk Security at the Session Border
The Session Border Controller is the primary enforcement point for SIP trunk security. Every call from an external carrier enters through the SBC, which means it’s the right place to block attacks before they reach the PBX.
Nextiva’s SIP trunking guide recommends that enterprises “use encrypted SIP trunks, enable security features like firewall protections, authentication, and data encryption, and implement cybersecurity practices” at the trunk level. In practice, this means the SBC should enforce TLS 1.2 or 1.3 for SIP signaling and SRTP for media on every trunk.
Rate limiting is the second critical function. A SIP flood attack can send thousands of INVITE messages per second to exhaust PBX resources. The SBC should cap INVITE rates per source IP. A common threshold is 50 to 100 INVITEs per second per trunk. Anything above that threshold gets dropped. This stops toll fraud attempts where attackers send rapid-fire calls to premium international numbers.
Warning: Philippine enterprises saw 624,400 leaked accounts in Q1 2026 alone, a 76.8% year-over-year surge. SIP credentials exposed in these breaches can be used for toll fraud within minutes. Your SBC’s access control lists and SIP authentication policies are the last line of defense. We’ve written separately about [defending against VoIP network-layer threats](/blog/voip-network-layer-attacks-defense).
STIR/SHAKEN caller ID authentication is gaining traction globally. Leading SBCs from Oracle and Ribbon now include built-in REST clients that validate SIP INVITE messages against certificate authorities in real time. The Philippines has no NTC mandate for STIR/SHAKEN adoption yet. But enterprises dealing with inbound call spoofing, especially banks and government hotlines, benefit from enabling it on SBCs that support the protocol.
The SBC is where you draw the line between trusted internal voice traffic and everything outside your network. Every encryption requirement, every rate limit, every access control list enforces at this single point.
Carrier Interconnect and Codec Handling
Early SBC deployments focused on the borders between two service provider networks in a peering environment, according to the Wikipedia entry on SBCs. That role has expanded. Philippine enterprises now use SBCs to manage carrier interconnect with multiple SIP trunk providers simultaneously.
A typical Manila enterprise might run one SIP trunk from PLDT for local PSTN calls, a second trunk from Globe for mobile termination, and a third from an international carrier for overseas routing. The SBC manages all three trunks and applies routing rules: local landline calls go to PLDT (lower per-minute cost), mobile calls route through Globe, and international calls use the overseas carrier with the best rate for each destination country.
TelcoBridges recommends the “trunk-by-trunk migration” approach when setting up these interconnects: convert one PRI circuit at a time, validate call quality and routing, then proceed to the next. This prevents a botched cutover from taking down all voice services simultaneously.
The SBC also handles codec transcoding between carriers. Your internal PBX might run G.711 at 64 kbps per call (best quality) while a mobile carrier prefers G.729 at 8 kbps (bandwidth-efficient). The SBC transcodes between them in real time. Hardware-accelerated transcoding on platforms like AudioCodes Mediant keeps latency under 10 ms per transcoding hop. Without the SBC, you’d need the PBX itself to handle transcoding, draining CPU capacity that should be serving SIP call signaling.
Ecosmob’s 2026 SBC architecture guide advises enterprises to “create a detailed design of the SBC architecture, considering its placement and interaction with IMS components,” including defining the network topology and identifying all interfaces and protocols before any deployment begins. Skipping this design phase is how enterprises end up with SBCs that work for one carrier but break when a second trunk is added.
| Vendor | Max Sessions per Server | Primary Use Case | UCaaS Integration |
|---|---|---|---|
| AudioCodes Mediant | Up to 100,000 | Microsoft Teams Direct Routing, Zoom | Native Teams/Zoom certified |
| Cisco CUBE | Varies by ISR router model | Cisco-heavy environments | Webex native |
| TelcoBridges ProSBC | 60,000 | High-density ITSPs and carriers | API-based |
| Ribbon SBC 5400 | 100,000+ | Large carrier interconnect | Teams certified |
Tier-1 carrier relationships ensure optimal call quality and reliability, per SIP.US. When selecting SBC hardware or software, confirm that the vendor has tested interoperability with your specific Philippine carriers. PLDT, Globe, and Converge each have their own SIP trunk implementations with quirks in header handling, DTMF relay methods, and codec negotiation. An SBC that passes interoperability testing with all three saves weeks of troubleshooting after deployment.
The Open Threads
Cloud-native SBCs running on Kubernetes are the clear direction for new deployments. But Philippine enterprises face a practical gap: most local carriers still deliver SIP trunks over dedicated circuits or MPLS, not over the public internet. That means the SBC still needs a physical or virtual presence at a co-location facility near the carrier’s point of presence, even if the PBX itself runs in AWS or Azure.
AI-driven routing and anomaly detection are appearing in vendor roadmaps from Oracle, Ecosmob, and AudioCodes. These features promise to detect toll fraud patterns and signaling storms automatically. Real-world effectiveness in Philippine traffic patterns, with their high mobile termination volumes and variable international routing, remains unproven at scale.
IPv6 readiness is another unresolved question. NTC has encouraged IPv6 adoption, but most Philippine SIP trunk providers still deliver service over IPv4. Enterprises buying SBCs today should confirm dual-stack support, but shouldn’t expect to run IPv6-only SIP trunks for several years.
And the question of local vendor support persists. AudioCodes and Ribbon maintain APAC support centers, but response times for Philippine-specific issues (carrier interop failures, NTC compliance questions) can lag behind those in larger APAC markets like Singapore or Australia. Enterprises should negotiate SLA terms that specify 4-hour response times for severity-1 voice outages, not the default 8-hour window many vendors offer in this region. Getting that commitment in writing before signing a purchase order gives you recourse when a trunk goes down at 2 AM and your BPO floor has 3,000 agents waiting for dial tone.
