Was helping a friend's team evaluate Session Border Controller options recently, and the conversation reminded me how much weird, undocumented knowledge SBC work involves. Sharing some of it here because most of the public material out there is either marketing brochures or RFC walls of text.
This isn't an intro to what an SBC does. If you're reading this you probably already know it sits at the edge of a VoIP network and handles NAT, security, interop, and a few other things. The point of this post is the stuff that bites you only after you've actually deployed one.

1. "Just put an SBC in front of it" hides a lot of complexity
Half the SIP advice on the internet ends with "put an SBC in front of it" as if that's a one-step fix. It isn't. The SBC is the thing that does the hard work, which means all the complexity that was hiding in NAT, codec negotiation, and SIP normalization now lives inside the SBC config instead.

A poorly configured SBC will silently break calls in ways that look like softphone bugs, network issues, or even DNS problems. Spent two weeks once chasing a "softphone bug" that turned out to be the SBC stripping a SIP header that the downstream PBX needed.

Lesson: when something breaks weirdly, suspect the SBC first, not last.

2. SIP normalization is where most real-world deployments live
Different SIP devices, providers, and softphones implement SIP slightly differently. Polycom does one thing. Yealink does another. Some softphones add custom headers. Some carriers expect a very specific From header format. Some downstream PBXes choke on whitespace in odd places.

A serious chunk of SBC configuration is just "rewrite this SIP message into the format the next hop expects." It's not glamorous. It's not what the marketing slides talk about. But it's where 60% of real SBC tuning time goes.

If you're building or configuring one, get comfortable with header manipulation, URI rewriting, and SDP modification early.

3. Topology hiding is more than a buzzword
Every SBC vendor talks about topology hiding. What they mean in practice is: rewriting Via headers, Record-Route headers, From and To URIs so the other side can't see your internal infrastructure.
Important because:

Exposed internal IPs help attackers fingerprint your setup.
Some attackers specifically target SBCs they can identify by vendor banner.
Some downstream networks reject calls that show internal routing hops.

In production, every outgoing call should look like it's coming from the SBC's public IP and nothing else. If you're seeing internal IPs leak in production traffic, your topology hiding is broken regardless of what the config screen claims.

4. Fraud is real and it happens fast
The first time you put a public-facing SBC into production, you will see scan traffic within minutes. SIP scanners are constant, automated, and aggressive. They'll try every common extension, every default password, every well-known account name.

If you have a misconfigured registration endpoint or an open trunk, fraud calls can start within hours. International premium rate numbers. Calls to obscure country codes that nobody at the company has ever called. The bill arrives at the end of the month, and it's usually large.

Defenses that actually matter:

• Disable anonymous trunks completely
• Rate-limit registration attempts per source IP
• Block geographically (most fraud comes from specific country ranges)
• Block international dialing patterns by default and whitelist countries individually
• Monitor for unusual call patterns in real-time, not in monthly reports

Don't trust the vendor's defaults. Audit them yourself.

5. RTP is where the "interesting" performance problems live
SIP signaling is small. RTP is constant, real-time, and bandwidth-heavy. Most SBC performance issues at scale are actually RTP path issues.

Things that matter:

• Whether the SBC is doing media anchoring (relaying RTP) or just signaling
• Codec transcoding cost (Opus to G.711 conversion is CPU-expensive, do it sparingly)
• Jitter buffer behavior under load
• DTLS-SRTP handshake performance for WebRTC calls

A signaling-only SBC scales easily to thousands of concurrent registrations. The moment you start anchoring media or transcoding codecs, hardware budgets change drastically.

If you're sizing infrastructure, model your transcoding load carefully. It's the thing that most often surprises teams in production.

6. WebRTC support is harder than it looks
If your SBC needs to bridge WebRTC clients to traditional SIP, you're

• signing up for a different category of complexity.
• WebRTC uses DTLS-SRTP, traditional SIP usually uses plain SRTP or unencrypted RTP.
• ICE candidates need to be properly translated to/from SIP/SDP.
• Some browsers behave differently in edge cases.
• WebSocket connection management adds another layer of state to track.

A lot of older SBCs were retrofitted for WebRTC and it shows. If WebRTC matters to your deployment, test it explicitly with realistic scenarios, not just "it connected once."

7. Logs grow faster than you expect
An SBC at production volume will generate gigabytes of logs per day. SIP messages, RTP statistics, security events, performance counters. You need a real log pipeline.

• Send logs to a centralized system (ELK, Loki, Splunk - whatever your team already uses)
• Set retention policies before you fill up disks
• Be ready to capture full SIP traces selectively when something breaks, because debugging without traces is misery
• Watch your log levels - debug logging in production will crush both disk and CPU

The teams I've seen do this well treat the SBC like any other production service: monitoring, alerting, dashboards. The teams that don't, end up chasing problems blind.

8. Open source vs commercial isn't a binary choice
Common open-source SBC options: Kamailio (often configured as one), OpenSIPS, drachtio (programmable, Node.js-based). Commercial options: AudioCodes, Oracle (Acme Packet), Ribbon, Sansay, and several others.

The honest tradeoffs:

• Open source: total control, zero license cost, but you own all the operational burden
• Commercial: support contracts, certified hardware, but expensive and sometimes inflexible

A surprising number of large carriers run open-source SBCs in production. Kamailio in particular powers a huge amount of real-world VoIP infrastructure that you'd think runs on commercial gear.

Pick based on your team's expertise, not just the feature checklist.

Closing
SBC work is one of the more underrated parts of VoIP infrastructure. It's not glamorous, the documentation across the industry is patchy, and a lot of the real knowledge lives in the heads of engineers who've debugged enough production issues to know which questions to ask.
If you're getting started with SBC development or evaluation, the best advice I can give: don't trust the defaults, test under real network conditions, and assume fraud will find you within hours of going live.

If you've shipped SBC work and run into things I haven't covered, comments are open. Always interested in comparing notes on this stuff.