DEV Community

Cover image for Building an Open Source Session Border Controller with Kamailio and RTPengine
Jack Morris
Jack Morris

Posted on

Building an Open Source Session Border Controller with Kamailio and RTPengine

#opensource #devops #security #productivity

If you run VoIP at any real scale, you eventually need something sitting at the edge of your network doing the unglamorous work. Securing SIP traffic, hiding your internal topology, fixing NAT, keeping bad actors out. That something is a Session Border Controller, and the commercial ones (Oracle, Ribbon, AudioCodes) are excellent and eye-wateringly expensive.

The good news is you can build an open source session border controller from pieces that have been battle-tested for years. Here is what an SBC actually does, and how the open-source stack comes together.

What an SBC is actually for

People throw the term around loosely, so to be concrete, an SBC sits between your VoIP network and the outside world and handles a specific set of jobs:

Signaling security: TLS for SIP, plus protection against floods and malformed messages

Topology hiding: stopping the outside world from seeing your internal IPs and layout

NAT traversal: making calls work when endpoints sit behind routers that mangle SIP

Media handling: anchoring and relaying RTP, often with SRTP for encryption

Admission control: rate limiting and capping concurrent calls so nobody overruns you

Miss any of these and you get the classic symptoms. One-way audio, SIP scanning attacks, calls that work fine on the LAN and die the moment they hit the internet.

The stack: signaling and media are two different jobs
The key thing to understand about session border controller development is that signaling and media are separate problems, and you use separate tools for each.

Kamailio (or OpenSIPS) handles the SIP signaling. It is a high-performance SIP proxy that routes, secures, and rewrites signaling. RTPengine handles the media, the actual RTP audio and video, relaying and optionally encrypting it. Put together, the two do the job a commercial SBC does in one box.

Anchoring media through RTPengine
The media side is what fixes NAT and gives you a controllable RTP path. In Kamailio you call into RTPengine on the way through:

# Rewrite the SDP so media flows through RTPengine, not peer to peer
route[RELAY] {
    if (is_method("INVITE|UPDATE") && has_body("application/sdp")) {
        rtpengine_manage("replace-origin replace-session-connection");
    }
    t_relay();
}
Enter fullscreen mode Exit fullscreen mode

That one call rewrites the SDP so both sides send media to RTPengine instead of straight to each other. Now you control the media path, which is what makes NAT traversal and SRTP possible in the first place. Pass the right flags to rtpengine_manage and you get encrypted media without either endpoint having to negotiate it directly.

Hiding your topology

You do not want the far end reading your internal server addresses out of the Via, Record-Route, and Contact headers. Kamailio's topos module handles that by holding dialog state and rewriting those headers, so the outside world only ever sees the SBC:

loadmodule "topos.so"
modparam("topos", "storage", "redis")
Enter fullscreen mode Exit fullscreen mode

With that in place your internal routing stays invisible from outside, which is a genuine security win and one of the defining jobs of an SBC.

Keeping attackers out

Put a public SIP port on the internet and within hours you will see scanners hammering it. The pike module gives you basic flood protection by tracking request rates per source IP:

if (!pike_check_req()) {
    xlog("L_ALERT", "pike: blocking flood from $si\n");
    exit;
}
Enter fullscreen mode Exit fullscreen mode

Pair that with a sane firewall, fail2ban watching your SIP logs, and TLS so nothing travels in plaintext, and you have shut the door on the most common attacks.

Why this turns into real work

None of these pieces is exotic on its own. Wiring them into something that survives real carrier traffic is another matter entirely. You are suddenly dealing with dialog state at scale, failover, RTP capacity planning, SRTP interop quirks, and the endless edge cases of SIP in the wild. That gap between a working lab setup and a production SBC is exactly why custom session border controller solutions tend to get built by people who have already run one under load. If you want to see how that comes together in production, it is the kind of work we do at Hire VoIP Developer.

You do not need a six-figure appliance to get a real SBC. Kamailio for signaling, RTPengine for media, topos for topology hiding, pike and TLS for security, and you have an open source session border controller built from proven parts. The build is the easy 80 percent. Making it hold up in production is the part worth taking seriously.

Top comments (0)