Interconnecting carrier SIP trunks and enterprise IPBXs looks simple on paper. In practice, it is one of the most expensive friction points in a VoIP infrastructure: you have to secure the IPBX exposed to the Internet, juggle several operators in parallel, fail over when one goes down, normalise routing — all without blowing the budget on a closed, opaque proprietary SBC.

PK-SBC is an open source answer to that problem. A Session Border Controller built on Kamailio, RTP Engine, Redis and PostgreSQL, designed along the KISS principle — Keep It Simple, Stupid — and battle-tested in production since 2012.

The problem PK-SBC solves

Real-world SIP architectures pile up complexity: a carrier connecting its own upstream providers to its switching platform, a multi-site enterprise pooling trunks while isolating its subsidiaries, an integrator looking to industrialise SBC deployments across customers.

On these use cases, two approaches dominate the market, each with its limits:

  • Proprietary SBCs (Cisco, AudioCodes, Oracle ACME, Sangoma) are expensive, closed and often overdimensioned for the actual need. Adding a tenant or a routing rule requires expert intervention.
  • Raw Kamailio is powerful and free, but its configuration is an art: every deployment becomes a one-off project, hard to reproduce and expensive to maintain.

PK-SBC sits between the two: the power and maturity of Kamailio, with an administration and supervision layer that makes the SBC operable by an operator, not only by a Kamailio developer.

What PK-SBC is

PK-SBC is a SIP proxy for trunk ↔ IPBX interconnection, distributed under the AGPL v3 licence. Its engine relies on Kamailio for SIP signalling and RTP Engine for media, with Redis and PostgreSQL for state and configuration. Deployment runs in Docker containers, on a single virtual machine to get started.

A few factual markers on maturity:

  • In production since 2012, first as an internal project, then industrialised.
  • The largest known deployment is a wholesale VoIP operator that sustained 100,000 concurrent calls on the infrastructure.
  • On a standard VM (2 vCPU / 2 GB RAM), a single instance routinely handles over 1,000 concurrent calls.

Who it is for

PK-SBC targets players who need to industrialise SIP interconnection without locking themselves into a proprietary SBC:

  • Alternative telecom operators connecting their own third-party carriers to their switching platform.
  • Integrators and MSPs deploying and operating SBCs at customer sites who want a reproducible product.
  • CIOs of large enterprises with multi-site or multi-subsidiary setups pooling carrier trunks while isolating contexts.
  • VoIP resellers looking for a brandable, operable SBC building block.

Two real-world use cases

National operator: connecting carriers to a Class 4 platform

A national telecom operator uses PK-SBC as the single entry point to its Class 4 platform. Each third-party carrier is declared as a provider gateway, with its own concurrent-call and CPS (calls per second) limits. Routing rules direct outbound traffic to the right carrier based on the geographic prefix, and inbound traffic to the switching platform. The supervision cockpit lets the NOC team spot a MOS degradation or an answer-rate drop on a specific gateway in real time.

National enterprise: multi-site, multi-company

A large account uses PK-SBC to secure and route VoIP traffic across a multi-site, multi-company environment. Site IPBXs are declared as client gateways, each with its own tenant. Multi-tenant mode lets a single carrier trunk serve several IPBXs, distinguished by SIP header. Failover between primary and secondary IPBXs is handled by gateway list priorities. The immutable audit trail guarantees traceability of every configuration change — a requirement of security and compliance teams.

How it works

Engine and administration

PK-SBC cleanly separates the routing engine — Kamailio and RTP Engine, which handle signalling and media in real time — from the administration interface, which generates the PostgreSQL views consumed by Kamailio. Configuration changes are not applied hot: a reminder banner prompts the administrator to reload Kamailio, ensuring no partial change can alter routing in production.

Real-time supervision

The Cockpit is the main dashboard. It shows the number of active calls, answer rate, average MOS and throughput over the selected period, with configurable auto-refresh. Five tunable alerts (low MOS, low answer rate, failure spike, duration drop, missed-call surge) enable proactive incident detection. A per-gateway table completes the view to quickly spot the degraded gateway.

The Cockpit — real-time dashboard: active calls, answer rate, average MOS, configurable alerts and gateway table.

CDRs and audio quality

Every handled call produces a CDR (Call Detail Record) documenting caller and callee identities, source and destination gateways, the SIP hangup cause and — crucially — audio quality metrics: MOS, jitter, packet loss, negotiated codec. CDRs are read-only and form the source of truth for post-mortem analysis and reporting. A CSV export is available for analysis in a BI tool.

CDR — call history with audio quality (MOS, jitter, packet loss), source/destination gateways and hangup cause.

Declarative routing

Routing rests on three building blocks: gateways (SIP endpoints, operators or clients), routing groups (logical containers referencing an ordered list of gateways) and routing rules (match conditions on the called number). Four rule types cover common needs: standard, geographic (with automatic regional prefix generation), specialised and emergency (with per-country presets: France, Spain, Italy). An Inbound Wizard guides the administrator step by step to configure a complete inbound routing flow in a single pass, with automatic rollback on error.

Security

PK-SBC ships with the protections expected from an SBC: SIP scanner blocking, fraudulent connection attempt detection, SQL injection detection, SIP header validation. Call limits (max concurrent calls, max CPS) apply at gateway, routing group and tenant level — the most restrictive limit wins, protecting the infrastructure against traffic spikes and fraud. The administration interface supports local accounts and OIDC SSO (Keycloak, Okta, Microsoft Entra ID).

Traceability

Every configuration action — creation, modification, deletion, login — is recorded in an immutable audit log, with user identity, timestamp, IP address and a JSON diff of the changes. This traceability is designed for regulatory compliance and retroactive investigation of routing incidents.

Premium features

An AI Analytics feature is available under licence. It lets you ask natural-language questions about your call traffic (“How many calls failed on the Paris gateway last week?”) and get a summary with charts and detailed statistics. A second function analyses recent SIP logs to detect anomalies or understand an incident. The licence system is offline, no remote server connection is needed to validate a licence.

Going further

If you want to evaluate the solution on your use case — operator, integrator or enterprise — the best entry point is to request a demo from the Célea Consulting team, the publisher of PK-SBC, which has supported and developed the product since 2008.

Request a demo on celea.org →