How Session Border Controllers Protect Voice Networks

Every SIP trunk, every IP-PBX, and every UCaaS connection that touches the public internet is an attack surface. Toll fraud alone costs the telecommunications industry more than $10 billion annually, according to the Communications Fraud Control Association (CFCA). Distributed denial-of-service (DDoS) attacks against VoIP infrastructure can knock an entire organization offline in minutes. And without encryption, voice traffic travels in cleartext, readable by anyone with a packet sniffer on the network path.

A Session Border Controller (SBC) is the network element designed to sit at the edge of a voice network and defend against exactly these threats. But “SBC security” is not a single feature. It is a stack of complementary defense layers that protect signaling, media, and the core network infrastructure from distinct categories of attack.

This guide breaks down the five security layers that a properly deployed SBC provides, explains why traditional firewalls cannot replace an SBC for voice traffic, and covers the configurable security capabilities that separate modern SBCs from legacy static-rule devices.

Why Voice Networks Need Dedicated Security

Voice over IP (VoIP) traffic uses a fundamentally different protocol architecture than web traffic. SIP handles signaling (call setup, teardown, registration), while RTP carries the actual audio media. These two protocols use different ports, different transport mechanisms, and different header structures, and both need protection.

Traditional network firewalls operate on the Network layer (IP addresses) and the Transport layer (TCP/UDP ports). They can block or allow traffic based on source/destination IP and port number, but they cannot inspect or understand the SIP messages passing through those ports. A firewall cannot tell the difference between a legitimate SIP INVITE and a flood of malicious REGISTER requests designed to overwhelm your registrar. It cannot detect that a SIP message is attempting to route a call to an international premium-rate number through your trunks.

Some firewalls offer a SIP Application Layer Gateway (ALG) feature, but SIP ALG is notorious for causing more problems than it solves: rewriting SIP headers in ways that break call flows, interfere with NAT traversal, and create unpredictable routing behavior. Most VoIP engineers disable SIP ALG as a first troubleshooting step.

The attack surface of a voice network spans three planes: the signaling plane (SIP messages), the media plane (RTP audio streams), and the management plane (web administration interfaces, APIs, SNMP). An SBC provides purpose-built security across all three.

The Five Security Layers of an SBC

Think of SBC security as a defense-in-depth architecture. Each layer addresses a specific threat category, and all five layers work together to create a comprehensive security posture.

Layer 1: Signaling Encryption with SIP over TLS

The Session Initiation Protocol (SIP) was designed without built-in encryption. By default, SIP messages travel over UDP or TCP in plaintext, exposing call metadata (who is calling whom, from which IP address, using which credentials) to anyone monitoring the network.

Transport Layer Security (TLS) encrypts the SIP signaling channel. When SIP runs over TLS, all signaling messages between the SBC and its peers are encrypted, preventing eavesdropping and man-in-the-middle attacks on call setup.

Mutual TLS (mTLS) takes this further by requiring both sides of the connection to present valid certificates. This prevents unauthorized devices from establishing SIP connections with your SBC, even if they know the correct IP address and port. Mutual TLS is particularly important for regulatory environments and for the majority of SIP telephony systems exposed to the public internet, including Microsoft Teams Direct Routing, which mandates TLS for all SBC connections.

ProSBC supports SIP over TLS (configurable per Network Access Point), enabling encrypted signaling for every trunk group independently. This means you can enforce TLS on peering connections while maintaining unencrypted SIP for internal endpoints that don’t support it.

Layer 2: Media Encryption with SRTP

Encrypting signaling protects call metadata, but the actual voice audio travels separately over the Real-time Transport Protocol (RTP). Without media encryption, an attacker who can capture RTP packets can reconstruct the entire conversation.

Secure RTP (SRTP) encrypts the media stream. An SBC that supports SRTP can operate in two modes: SRTP relay, where it passes encrypted media through without decrypting it (preserving end-to-end encryption), and RTP-to-SRTP conversion, where it accepts unencrypted RTP from one side and encrypts it as SRTP toward the other. This conversion capability is critical in mixed environments where some endpoints support SRTP and others do not.

ProSBC provides native SRTP support including both SRTP relay and RTP-to-SRTP conversion, allowing operators to enforce media encryption even when connecting legacy equipment that only supports RTP to modern infrastructure that requires SRTP.

Layer 3: Access Control and Traffic Filtering

Encryption protects the content of legitimate communications. Access control determines who is allowed to communicate at all.

An SBC’s access control capabilities typically include IP-based Access Control Lists (ACLs) that whitelist or blacklist specific IP addresses and ranges, calling and called number filtering that blocks traffic to or from specific phone numbers, and registration controls that limit which devices can register through the SBC.

The granularity of these controls matters. An SBC that only supports global ACLs forces you to apply the same rules to every trunk. An SBC that supports per-trunk-group ACLs lets you apply different policies to different carriers, different customer segments, or different geographic regions.

ProSBC implements dynamic blacklisting with percentage-based greylisting. You can configure it to block 100% of calls from a known bad actor, or block a configurable percentage from a suspected source while you investigate. Its access control operates at both global and per-NAP (Network Access Point) scope, and it includes SIP registration scanning protection to detect and block registration flood attacks before they consume system resources.

Layer 4: DoS and DDoS Mitigation

A denial-of-service attack against a voice network does not need to be sophisticated to be effective. A SIP INVITE flood (thousands of call setup requests per second from spoofed IP addresses) can exhaust an SBC’s session capacity, a registrar’s memory, or an IP-PBX’s processing power.

SBC-level DoS and DDoS mitigation works by applying rate limits per source IP, per trunk group, and per message type. When an SBC detects that a source is sending SIP messages at a rate that exceeds configured thresholds, it can throttle, challenge, or blacklist that source, all without affecting legitimate traffic from other sources.

The key advantage of handling DoS at the SBC layer (rather than at the network firewall) is protocol awareness. The SBC understands that a burst of 500 SIP REGISTER messages from a single IP in 10 seconds is abnormal, even though each individual message is a valid SIP request that a firewall would pass without question.

ProSBC includes built-in DoS and DDoS protection rules that are configurable per trunk group (NAP). This per-NAP granularity means you can set aggressive thresholds on public-facing trunks while maintaining relaxed limits on trusted internal connections.

Layer 5: Toll Fraud and Spam Prevention

Toll fraud is the most financially damaging attack against voice networks. Attackers gain access to a SIP trunk or PBX (through stolen credentials, registration hijacking, or SIP message manipulation) and route calls through international premium-rate numbers that they control. The victim receives the bill; the attacker collects the revenue share from the premium-rate service.

An SBC combats toll fraud through multiple mechanisms: blocking calls to known premium-rate number ranges, enforcing concurrent call limits per trunk, detecting abnormal call patterns (such as a sudden spike in international traffic at 3 AM), and integrating with external fraud detection databases for real-time scoring.

Spam and robocall prevention follows a similar pattern: the SBC queries external reputation databases before admitting a call, and routes or blocks based on the risk score returned.

ProSBC addresses toll fraud and spam through several integrated capabilities. Its configurable Ruby routing API allows operators to implement custom fraud detection logic that inspects over 100 call parameters per call and executes before the call is routed. It integrates with SecureLogix for spam risk scoring, YouMail for robocall risk assessment, and TransNexus ClearIP for combined fraud detection and STIR/SHAKEN verification. The percentage-based greylisting feature allows operators to throttle suspicious traffic without completely blocking it, which is useful when a source is borderline and blocking all traffic would affect legitimate callers.

Topology Hiding: The SBC’s Silent Security Function

One of the most important security functions an SBC provides is also the least visible: topology hiding. Every SIP message contains Via headers, Contact headers, and Record-Route headers that reveal internal IP addresses, hostnames, and network architecture. Without topology hiding, an external attacker can map your internal network simply by examining SIP responses.

A Back-to-Back User Agent (B2BUA) architecture is the key enabler of effective topology hiding. Unlike a SIP proxy, which forwards SIP messages and adds its own Via header while preserving the original headers, a B2BUA fully terminates the SIP session on one side and originates a completely new session on the other. This means all internal network information is stripped and replaced before any SIP message leaves the network.

ProSBC implements full B2BUA architecture, providing complete topology hiding that conceals internal network IP addresses from external parties and vice versa. This is not a configurable option that can be accidentally left off. It is an inherent property of the B2BUA design.

Configurable Security: Why Static Rules Are Not Enough

Static access control lists and fixed rate limits were sufficient when VoIP threats were unsophisticated. Today’s toll fraud operations use rotating IP addresses, valid-looking SIP credentials, and call patterns designed to stay just below static detection thresholds.

A configurable SBC allows operators to implement adaptive security logic that queries external systems in real time, applies custom rules based on the full context of each call, and evolves as threats change, without requiring firmware updates or vendor support tickets.

ProSBC’s Ruby routing API provides this configurability through a filter chain architecture. Routing scripts extend a base class and define before_filter, after_filter, and after_remap_filter methods that execute at different stages of call processing. Within these filters, operators can query external HTTP services (fraud databases, number reputation services, internal business logic systems), inspect any of the 100+ call parameters available to the routing engine, and make routing or blocking decisions based on the combined results.

This means a ProSBC operator can implement logic such as: “For every call from NAP ‘carrier-x’ with a destination matching international premium-rate patterns, query TransNexus ClearIP for a fraud score. If the score exceeds the configured threshold, block the call and log the event. If the score is moderate, route the call but set a maximum duration of 60 seconds.” This kind of context-aware, multi-source decision logic is impossible with static ACLs alone.

STIR/SHAKEN: Authenticating Caller Identity at the SBC

Caller ID spoofing is both a security threat and a regulatory concern. STIR/SHAKEN (Secure Telephone Identity Revisited / Signature-based Handling of Asserted information using toKENS) is the industry framework for cryptographically verifying that the calling party number has not been spoofed.

The SBC plays a central role in STIR/SHAKEN: as an originating SBC, it integrates with a signing service to attach a cryptographic Identity header to outgoing calls; as a terminating SBC, it verifies the Identity header on incoming calls and takes action based on the attestation level.

The three attestation levels indicate the originating provider’s relationship with the caller: Full Attestation (A) means the provider authenticated the calling party and they are authorized to use that number; Partial Attestation (B) means the provider knows where the call originated but cannot verify the caller’s right to use the number; Gateway Attestation (C) means the call entered the network from an untrusted source.

For a deeper dive into STIR/SHAKEN implementation, attestation levels, and FCC compliance requirements, see our dedicated STIR/SHAKEN guide.

SBC Security Checklist: Evaluating an SBC for Security

When evaluating an SBC for your network’s security requirements, use this checklist to ensure comprehensive coverage.

Security Requirement	What to Look For	ProSBC
SIP over TLS	TLS 1.2+ support, configurable per trunk, mutual TLS (mTLS) option	Per-NAP TLS
SRTP	Native SRTP support, RTP-to-SRTP conversion, SRTP relay mode	Relay + conversion
Access Control Lists	Per-trunk-group granularity, IP-based and number-based, dynamic updates	Per-NAP + greylisting
DoS/DDoS Protection	Built-in (not add-on), per-trunk configurable, SIP-aware rate limiting	Built-in per-NAP
Topology Hiding	Full B2BUA architecture (not SIP proxy), complete header rewrite	Full B2BUA
Toll Fraud Prevention	International call blocking, concurrent call limits, pattern detection	API + partner integrations
Configurability	Scripting API for custom routing/security logic, external system queries	Ruby routing API
STIR/SHAKEN	Signing and verification support, attestation level handling	Via signing service
Third-Party Integrations	Named, validated partner integrations for fraud/spam detection	SecureLogix, YouMail, TransNexus
High Availability	1+1 HA with no loss of service, security continuity during failover	ProSBC+ 1+1 HA

SBC Security vs. Traditional Firewall: Why You Need Both

A common question in network security planning is whether a firewall with SIP ALG capability can replace an SBC. The short answer is no. They serve complementary functions at different layers of the network stack.

Capability	Network Firewall	SBC
IP/port filtering	Global configuration, limited scalability	Per trunk group
SIP message inspection	SIP ALG only, without configurability	Full, application-layer aware
SIP header manipulation	No	Yes
RTP media handling	No	Yes
TLS termination for SIP	No	Yes
SRTP encryption/decryption	No	Yes
SIP-aware rate limiting	No	Yes
Toll fraud detection	No	Yes
Topology hiding (B2BUA)	No	Yes
Codec negotiation	No	Yes
STIR/SHAKEN	No	Yes

The recommended deployment is defense-in-depth: the network firewall handles volumetric network-level attacks and enforces broad IP access policies at the Network and Transport layers, while the SBC handles application-layer SIP/RTP security, traffic policy, and voice-specific threat detection. The firewall protects the SBC; the SBC protects the voice application.

Securing Your Voice Network Starts at the Edge

SBC security is not a single feature to check off a vendor comparison spreadsheet. It is a multi-layered defense architecture that protects signaling, media, network topology, and business revenue from distinct threat categories. The five layers (signaling encryption, media encryption, access control, DoS/DDoS mitigation, and toll fraud prevention) work together as a defense-in-depth stack that no traditional firewall can replicate.

Modern threats require more than static rules. A configurable SBC with real-time external system queries, per-call fraud scoring, and an extensible filter chain gives operators the ability to adapt their security posture as threats evolve, without waiting for vendor firmware updates.