xphone
A Rust library for embedding real phone calls into any application. No PBX. No Twilio. No per-minute fees. Just clean PCM audio, in and out.
xphone handles SIP signaling, RTP media, codecs, and call state so you can focus on what your application actually does with the audio — whether that's feeding frames to a speech model, recording to disk, or building a full softphone.
Rust port of xphone-go, with the same event-driven API design.
Why xphone?
Building anything that needs to make or receive real phone calls is surprisingly painful. Your options are usually:
- Twilio / Vonage / Telnyx SDKs — easy to start, but you're paying platform fees per minute, your audio routes through their cloud, and the media pipeline is a black box.
- Raw SIP libraries — full control, but you wire everything yourself: signaling, RTP sessions, jitter buffers, codec negotiation, call state machines. Weeks of work before you can answer a call.
- Asterisk / FreeSWITCH via AMI/ARI — mature and powerful, but now you're running and operating a PBX just to make a call from your application.
xphone sits in the middle: a high-level, event-driven Rust API that handles all the protocol complexity and hands you clean PCM audio frames — ready to pipe into Whisper, Deepgram, or any audio pipeline you choose. Your audio never leaves your infrastructure unless you choose to send it somewhere.
What can you build with it?
AI Voice Agents
Connect a real phone number directly to your LLM pipeline. No cloud telephony platform required.
DID (phone number)
+-- SIP Trunk (Telnyx, Twilio SIP, Vonage...)
+-- xphone
|-- pcm_reader -> Whisper / Deepgram (speech-to-text)
+-- pcm_writer <- ElevenLabs / TTS (text-to-speech)
Your bot gets a real phone number, registers directly with a SIP trunk provider, and handles calls end-to-end — no Asterisk, no middleman, no per-minute platform fees.
Softphones & Click-to-Call
Embed a SIP phone into any Rust application. Accept calls, dial out, hold, transfer — all from code. Works against any SIP PBX (Asterisk, FreeSWITCH, 3CX, Cisco) or directly to a SIP trunk.
Call Recording & Monitoring
Tap into the PCM audio stream on any call and write it to disk, stream it to S3, or run real-time transcription and analysis.
Outbound Dialers
Programmatically dial numbers, play audio, detect DTMF responses — classic IVR automation without the IVR infrastructure.
Unit-testable Call Flows
MockPhone and MockCall provide the full Phone and Call APIs. Test every branch of your call logic — accept, reject, hold, transfer, DTMF, hangup — without a real SIP server or network. This is a first-class design goal, not an afterthought.
No PBX required
A common misconception: you don't need Asterisk or FreeSWITCH to use xphone. A SIP trunk is just a SIP server — xphone registers with it directly, exactly like a desk phone would.
let phone = new;
That's it. Your application registers with the SIP trunk, receives calls on your DID, and can dial out — no additional infrastructure.
A PBX only becomes relevant when you need to route calls across multiple agents or extensions. For single-purpose applications — a voice bot, a recorder, a dialer — xphone + SIP trunk is all you need.
Self-hosted vs cloud telephony
Most cloud telephony SDKs are excellent for getting started, but come with tradeoffs that matter at scale or in regulated environments:
| xphone + SIP Trunk | Cloud Telephony SDK | |
|---|---|---|
| Cost | SIP trunk rates only | Per-minute platform fees on top |
| Audio privacy | Media stays on your infrastructure | Audio routed through provider cloud |
| Latency | Direct RTP to your server | Extra hop through provider media servers |
| Control | Full access to raw PCM / RTP | API-level access only |
| Compliance | You control data residency | Provider's data policies apply |
| Complexity | You manage the SIP stack | Provider handles it |
xphone is the right choice when cost, latency, privacy, or compliance make self-hosting the media pipeline worth it.
SIP trunk providers (Telnyx, Twilio SIP, Vonage, Bandwidth, and many others) offer DIDs and SIP credentials at wholesale rates — typically $0.001-$0.005/min, with no additional platform markup when you bring your own SIP client.
Quick Start
Install
Add to your Cargo.toml:
[]
= "0.1"
Requires Rust 1.87+.
Build an AI voice agent in ~40 lines
use Arc;
use ;
PCM format: Vec<i16>, mono, 8000 Hz, 160 samples per frame (20ms) — the standard input format for most speech-to-text APIs.
Make an outbound call
use DialOptions;
use Duration;
let opts = DialOptions ;
let call = phone.dial?;
// Stream audio in and out.
if let Some = call.pcm_reader
Dial accepts a full SIP URI or just the number — if no host is given, your configured SIP server is used.
Features
| Feature | Status |
|---|---|
| SIP Registration (auth, keepalive, auto-reconnect) | Done |
| Inbound & outbound calls | Done |
| Hold / Resume (re-INVITE) | Done |
| Blind transfer (REFER) | Done |
| DTMF send/receive (RFC 4733) | Done |
| Session timers (RFC 4028) | Done |
| Mute / Unmute | Done |
| G.711 u-law (PCMU), G.711 A-law (PCMA) | Done |
| G.722 wideband codec | Done |
PCM audio frames (Vec<i16>) and raw RTP access |
Done |
| Jitter buffer | Done |
| SRTP (encrypted media, AES_CM_128_HMAC_SHA1_80) | Done |
| TCP and TLS SIP transport | Done |
| Early media (183 Session Progress) | Done |
| STUN NAT traversal (RFC 5389) | Done |
| MockPhone & MockCall for unit testing | Done |
| Attended transfer | Planned |
| Opus codec | Planned |
Configuration
use ;
use Duration;
// Direct struct construction:
let phone = new;
// Or use the builder:
let phone = new
.credentials
.rtp_ports
.build;
NAT Traversal (STUN)
If your application runs behind NAT (most deployments), configure a STUN server so xphone can discover your public IP and advertise it correctly in SIP and SDP:
let phone = new;
// Or with the builder:
let phone = new;
When stun_server is set, xphone sends a STUN Binding Request at startup to learn your external IP. If the STUN server is unreachable, it falls back to local IP detection automatically.
Common public STUN servers:
stun.l.google.com:19302stun1.l.google.com:19302stun.cloudflare.com:3478
Call States
Idle -> Ringing (inbound) or Dialing (outbound)
-> RemoteRinging -> Active <-> OnHold -> Ended
call.on_state;
call.on_ended;
Working with Audio
xphone exposes audio as a stream of PCM frames through crossbeam channels. Understanding the frame format and channel behaviour is key to building anything on top of the library.
Frame format
Every frame is a Vec<i16> with these fixed properties:
| Property | Value |
|---|---|
| Encoding | 16-bit signed PCM |
| Channels | Mono |
| Sample rate | 8000 Hz |
| Samples per frame | 160 |
| Frame duration | 20ms |
This is the native format expected by most speech-to-text APIs (Whisper, Deepgram, Google STT) and easily converted to f32 for audio processing pipelines.
Reading inbound audio
call.pcm_reader() returns a crossbeam_channel::Receiver<Vec<i16>>. Each receive gives you one 20ms frame of decoded audio from the remote party:
if let Some = call.pcm_reader
Important: Read frames promptly. The inbound buffer holds 256 frames (~5 seconds). If you fall behind, the oldest frames are silently dropped.
Writing outbound audio
call.pcm_writer() returns a crossbeam_channel::Sender<Vec<i16>>. Send one 20ms frame at a time to transmit audio to the remote party:
if let Some = call.pcm_writer
Important: Send frames at the natural 20ms pace. If you send faster than real-time, the outbound buffer fills and frames are dropped.
Silence frame
let silence = vec!; // zero-value is silence
pcm_tx.send.unwrap;
Converting to f32 (for ML pipelines)
Many audio and ML libraries expect Vec<f32> normalized to [-1.0, 1.0]:
Raw RTP access
For lower-level control — sending pre-encoded audio, implementing a custom codec, or inspecting RTP headers — use rtp_reader() and rtp_writer() instead of the PCM channels:
// Read raw RTP packets (post-jitter buffer, pre-decode)
if let Some = call.rtp_reader
// Write raw RTP packets (bypasses pcm_writer entirely)
if let Some = call.rtp_writer
Note:
rtp_writerandpcm_writerare mutually exclusive — if you write tortp_writer,pcm_writeris ignored for that call.
Media Pipeline
Inbound:
SIP Trunk -> RTP/UDP -> Jitter Buffer -> Codec Decode -> pcm_reader (Vec<i16>)
Outbound:
pcm_writer (Vec<i16>) -> Codec Encode -> RTP/UDP -> SIP Trunk
rtp_writer -> RTP/UDP -> SIP Trunk (raw mode)
All channels are buffered (256 entries). Inbound drops oldest on overflow; outbound drops newest. Each frame is 160 samples at 8000 Hz = 20ms of audio.
The media pipeline runs on a dedicated std::thread (not async), bridged to the rest of the application via crossbeam-channel.
Call Control
// Hold & resume
call.hold?;
call.resume?;
// Blind transfer
call.blind_transfer?;
// Mute (suppresses outbound audio, inbound still flows)
call.mute?;
call.unmute?;
// DTMF
call.send_dtmf?;
call.on_dtmf;
Testing
MockPhone and MockCall provide the same API as the real types — no real SIP server needed.
use MockPhone;
let phone = new;
phone.connect.unwrap;
phone.on_incoming;
phone.simulate_incoming;
assert_eq!;
use MockCall;
let call = new;
call.accept.unwrap;
call.send_dtmf.unwrap;
assert_eq!;
call.simulate_dtmf;
Integration Tests
Tests against a Docker Asterisk instance:
Or using the Makefile:
Logging
xphone uses the tracing crate for structured logging:
// Enable debug logging
fmt
.with_max_level
.init;
All SIP messages, RTP stats, media events, and call state transitions are instrumented with tracing spans and events.
Example App
examples/sipcli is a fully interactive terminal SIP client — registration, inbound/outbound calls, hold, resume, DTMF, mute, transfer, echo mode, and system speaker output:
# Using a profile from ~/.sipcli.yaml
# Direct flags
Stack
| Layer | Implementation |
|---|---|
| SIP Signaling | Custom (message parsing, digest auth, transactions, UDP/TCP/TLS, STUN) |
| RTP / SRTP | Custom (std::net::UdpSocket, AES_CM_128_HMAC_SHA1_80) |
| G.711 / G.722 | Built-in (PCMU, PCMA, G.722) |
| Jitter Buffer | Built-in |
| TUI (sipcli) | ratatui + cpal |
No external SIP or RTP crate dependencies — the entire SIP stack is implemented from scratch.
Known Limitations
This library is actively developed but not yet feature-complete. The gaps below are worth understanding before committing to it for a production deployment.
Security
SRTP is implemented but not yet hardened. The AES_CM_128_HMAC_SHA1_80 cipher suite is supported with SDES key exchange. Replay protection, key material zeroization, SRTCP encryption, and per-SSRC crypto state tracking are not yet implemented. DTLS-SRTP key exchange is not supported (SDES only). Evaluate accordingly for high-security environments.
Codec coverage
Opus is not yet supported. G.711 (PCMU/PCMA) and G.722 are implemented. Opus is the dominant codec in WebRTC and modern VoIP — its absence limits interoperability with those platforms.
G.729 is not supported. G.729 remains widely deployed in enterprise PBX environments (Cisco, Avaya, Mitel). If your SIP trunk or PBX requires G.729, xphone cannot currently interoperate with it.
PCM sample rate is fixed at 8 kHz (narrowband) or 16 kHz (G.722 wideband). There is no configurable sample rate — codec selection determines the rate.
Call control
Attended (consultative) transfer is not implemented. Only blind transfer via REFER is supported. Attended transfer requires coordinating two simultaneous call legs with a REFER/Replaces header.
DTMF is RFC 4733 (RTP telephone-events) only. Some legacy PBXes use SIP INFO (RFC 2976) for DTMF instead. If your system requires SIP INFO DTMF, tones may not be received.
No call forwarding (302). Incoming 302 Moved Temporarily responses are not followed automatically.
No call parking. Park/retrieve functionality (common in office deployments) is not implemented.
Enterprise features
No MWI (Message Waiting Indicator). SIP SUBSCRIBE/NOTIFY for the message-summary event package (RFC 3842) is not implemented. Applications cannot detect voicemail presence.
No presence or BLF. SIP SUBSCRIBE/NOTIFY for presence (RFC 3856) and dialog state (RFC 4235 — Busy Lamp Field) are not implemented.
No SIP MESSAGE (RFC 3428). Instant messaging over SIP is not supported.
Network & NAT
STUN is supported for NAT-mapped address discovery. Configure stun_server to use a public STUN server (e.g. stun.l.google.com:19302) for discovering your external IP. STUN should only be used when the SIP server is on the public internet — do not enable it when connecting via VPN or private network, as the STUN-mapped address will be unreachable from the server.
No TURN or ICE. TURN relay (RFC 5766) and full ICE (RFC 5245) are not implemented. In environments with symmetric NAT (common in cloud VMs and corporate firewalls), STUN alone may not be sufficient and RTP media may fail to flow.
Media
No video. Only audio media (single m=audio line in SDP) is supported. H.264, VP8, and other video codecs are not implemented.
No RTCP. RTP Control Protocol feedback (jitter reports, packet loss, round-trip time) is not sent or processed.
Project maturity
This is an early-stage project (v0.1.x). The API may change between releases. Evaluate accordingly for critical production workloads.
Roadmap
- SRTP hardening — replay protection, DTLS-SRTP, key zeroization
- Opus codec
- Attended (consultative) transfer
- SIP INFO DTMF (RFC 2976) for legacy PBX compatibility
- TURN relay and full ICE for symmetric NAT
- RTCP support
- MWI (voicemail notification)
Changelog
See CHANGELOG.md.
License
MIT