Blog

Presence looks trivial — “is this person on a call?” — until you try to make it consistent. Is an agent ‘busy’ because of a live call, a wrap-up state, or a DND toggle? Does a colleague on another PBX node see the same thing? And does the state survive a restart?

RustPBX treats presence as platform state, not a desk-local guess.

Single-box PBX is easy. The hard part starts when you run two nodes and discover that “shared database” doesn’t make phones work together: a call lives on exactly one node, registrations land wherever the load balancer sends them, and the console you’re logged into may have no idea that the extension you want to transfer is being served by its neighbor.

RustPBX 0.5 closes that gap with a distributed session registry. Here’s what it changes in practice.

Compliance recording isn’t “turn recording on.” It’s being able to answer, months later, questions like: was this specific call recorded? why not? where is it now? can you produce it, and prove it wasn’t altered?

RustPBX’s recording pipeline is built to make those answers routine. Here’s the operational playbook.

Performance posts usually end in a benchmark table nobody can reproduce. This one is about something more useful: the shape of the performance, so you can plan capacity without surprises — and know where the real limits are.

Interconnecting with carriers is where good PBX software meets bad SIP. The other end has opinions: it rewrites numbers, rejects your codec order, sends private IPs in SDP, and insists on headers you’ve never heard of. A session border controller exists to absorb that.

When a call misbehaves, the CDR tells you what happened and the media counters tell you how it sounded. Neither tells you exactly what was on the wire. For that you need packet-level signaling — captured continuously, indexed by call, queryable weeks later, and cheap enough to leave on permanently.

That’s SipFlow.

Observability shouldn’t require standing up Prometheus, Grafana, and a log pipeline before you can answer “is it healthy?” — but it should scale to that when you’re ready. RustPBX takes both seriously, and 0.5 added the middle ground: useful telemetry with zero external dependencies.

Static IVR trees handle “press 1 for sales.” They don’t handle “look up this caller’s open tickets, read the balance, and route on both.” Step IVR hands each call step to your own service, which answers with the next action — dynamic logic with the PBX still owning media, recording, and CDRs.

“Who can see the billing page?” sounds like a one-line question. Answering it in a PBX means distinguishing four very different identity concepts that other platforms happily blur together. RustPBX keeps them separate, and knowing the difference prevents most access-control mistakes.

Multi-party calling has a bad reputation because it’s usually an IVR feature bolted onto a phone system: someone dials a magic number, everyone else fumbles with a PIN, and the room stays open forever after the last person leaves.

RustPBX treats conferences as first-class resources with lifecycle management.

The media plane is where a telephony platform earns its keep: pick the right codec, decide what gets transcoded, and manage every sound callers hear. RustPBX’s media engine is shared by SIP, WebRTC, queues, IVR, and recording — one pipeline, one set of behaviors.

Hand someone a browser and a headset and they’re on the phone — no install, no VPN, works from a hotel lobby. That’s the promise of WebRTC telephony, and the part that usually turns into a science project is everything around the codec: ICE, STUN/TURN, certificate handling, and the NAT scenarios that only fail on customer networks.

RustPBX treats browsers as first-class endpoints. Here’s what’s actually involved.

Transcription is usually bolted on after the fact: record the call, upload it somewhere, run ASR, reconcile the text back to the call id by filename. It works until someone asks “what did the customer say during the call?”

RustPBX puts transcription in the call path, per call, with the policy you specify.

The RWI (Real-time WebSocket Interface) is RustPBX’s control plane for external software: a command/event protocol over a single WebSocket that a CTI panel, CRM, or AI agent can hold open for the life of a shift. This is the practical guide — what the protocol looks like, what arrives on it, and the details that matter in production.

“Outbound calls have no audio, inbound is fine.” If you’ve run SIP for a week, you’ve met this sentence. It’s almost never the codec — it’s address advertisement: the PBX told the far end an IP it can’t reach.

RustPBX separates the three addresses that SIP/WebRTC care about, and lets you override each per deployment, per network profile, or per trunk.

Voicemail is an old feature, and that’s exactly why the rough edges matter: provisioning mailboxes one by one, lost messages, no notification chain. RustPBX’s Voicemail Pro addon was designed to be enabled once and then get out of the way.

Every business hits the same requirement in week one: calls arriving outside business hours need a story. Not a busy tone, not an infinite ring — a story. Maybe a voicemail box, maybe an emergency escalation for VIPs, maybe a “we’re closed, back at 9” prompt in three languages.

This post walks through the patterns RustPBX gives you for after-hours handling, from the simple to the fairly sophisticated.

Every PBX has an IVR. The differences that matter: how flows are authored, how they branch on time and data, and how easy it is to hand a call to an external brain when menus stop being enough. Here’s the RustPBX toolbox, inside-out.

“Record all calls” is how recording requirements start. Then legal arrives: some calls must not be recorded. Finance wants the billing segments separately. The auditor wants retention measured in years, storage in object buckets, and downloads that don’t melt the PBX. Here’s how RustPBX’s recording pipeline grows with you.

“So, how were calls this week?” — the question arrives weekly, and answering it should not require a data pipeline. RustPBX ships a reporting layer that reads your CDRs and answers in tables, charts, and CSVs, from both the console and an API.

Browsers won’t touch your WebRTC endpoints without TLS. Carriers increasingly demand SIP over TLS. And certificates that expire on a Saturday are how outages are born. RustPBX bakes the whole story in.

The requirement behind half the AI-telephony pitches: “let an LLM answer the simple calls, and hand complex ones to a human — without throwing away the phone system we already run.” Most stacks make you choose between a bolt-on bot platform (its own SIP island, its own CDRs) and a rewrite. RustPBX treats the bot as a first-class resident instead. Here’s the architecture, and specifically how the human handoff stays clean.

This is part of a Basics series covering the everyday tasks of running a RustPBX instance. Start here: create extensions, get devices registered, and understand the options you’ll actually use.

No PBX stays stock. Sooner or later a call needs a CRM lookup, an event needs to reach another system, or a bot needs to hang up on command. RustPBX’s extension surface has three layers — choose by direction: decisions in, events out, and control both ways.

A PBX with a public IP gets scanned within minutes of going live. SipVicious and its cousins register-probe every open 5060 on the internet, hunting for default passwords they can turn into toll-fraud. Here’s the hardening checklist for the first 48 hours — all of it built in, none of it requiring external tooling.

A call detail record is only as useful as the questions it can answer. “Who called whom, when, and how long” is table stakes. The questions that actually matter at 2 AM are: why did it fail, which route did it take, was the audio bad on our side or the carrier’s, and did it transfer, and where. RustPBX CDRs are built to answer those without opening a PCAP.

“When a customer calls, we want their CRM record on the agent’s screen before they answer.” — the most common call-center integration request, and the one that breaks most often. The pop works on the first ring, dies on transfer #3, data sometimes never reaches the queue, and agents resort to manual search.

This post covers how RustPBX solves it, and why the details matter.

Call forwarding is the most-requested feature after basic calling, and the one with the most edge cases: what counts as “busy”? What if the destination is another extension? What if the carrier rejects the forwarded leg? Here’s how RustPBX handles all of it.

Queues are where callers decide whether your company has its act together. The ACD (Automatic Call Distribution) engine has to balance three promises: fairness (first come, first served), priority (VIPs really do go first), and escape (nobody waits forever). Here’s how RustPBX delivers each.

A contact center lives or dies by two moments: what happens when there’s no free agent, and what the supervisor sees when things go sideways. The latest RustPBX contact-center addon reworks both — plus a set of agent-facing features that close the gap between the PBX and the desk.

Three months of steady work went into RustPBX 0.5 — roughly two thousand commits since the 0.4.x series. The theme across all of them: when something goes wrong mid-call, the platform should already know why. This post walks through the changes that matter most for anyone running RustPBX in production, from a single box to a multi-node cluster.

Wholesale voice is a business run on spreadsheets and margins, so the platform running it should speak spreadsheet: exact route matches, predictable rounding, and a way to answer “why did this call route the way it did” without guesswork. The latest RustPBX wholesale addon update focuses on exactly that.

A contact center is more than a PBX with queues. It needs skill-based routing to send calls to the right agent, real-time monitoring for supervisors, wrap-up time for agents to finish notes, and overflow logic to prevent callers from waiting forever.

RustPBX’s CC (Contact Center) addon provides all of this out of the box. This post walks through setting up a functional call center – from skill groups to supervisor monitoring.

Debugging SIP calls usually means running tcpdump, downloading PCAP files, and opening Wireshark. It works, but it’s slow, requires server access, and doesn’t scale.

SipFlow is RustPBX’s built-in signaling capture system. It records every SIP message and RTP packet, stores them efficiently, and presents a visual timeline in the web console. Need a recording? Generate a WAV from the captured RTP data with one click. Need to debug a call from last week? Query it by call ID.

And when a single node isn’t enough, SipFlow supports cluster deployment with consistent hashing.

Running a telephony platform isn’t just about connecting calls. Day-to-day operations involve renewing TLS certificates before they expire, archiving old call records so the database doesn’t grow forever, and transcribing recordings for quality audits.

RustPBX bundles three addons that handle these chores automatically. Here’s how each one works.

Ride-hailing apps, delivery platforms, and marketplaces all share a common requirement: connect two parties on a phone call without revealing their real numbers. This is the classic privacy number (AX/NXA) use case.

RustPBX’s SBC addon includes a JSON-RPC router that makes this straightforward. Every incoming call can query your backend API, get the real destination, rewrite the numbers, and connect the call – all in real time.

Your team can call each other internally. Now you need to connect to the PSTN through a carrier, let customers call in from web browsers, and manage it all without spinning up a separate SBC appliance.

RustPBX’s SBC addon handles this in a single runtime – no Janus, no FreeSWITCH, no extra media servers.

Every PBX starts with the same basic need: let people inside the organization call each other. Whether your team uses desk phones, softphones, or web browsers, it all comes down to configuring extensions and getting them registered.

This post walks through setting up internal VoIP communication in RustPBX from scratch, using its web console.

In the world of real-time communication, performance is paramount. WebRTC has become the standard for peer-to-peer audio, video, and data transfer. While the browser implementations are well-known, server-side and native implementations are crucial for building scalable infrastructure, gateways, and high-performance clients.

This article presents a performance benchmark comparing three prominent WebRTC implementations, with the code available at restsend/rustrtc:

1. RustRTC: A pure Rust implementation of WebRTC (the project under test).
2. webrtc-rs: The most popular Rust implementation (a port of Pion).
3. Pion: The industry-standard Go implementation of WebRTC.