@serve.zone/callrouter is the calling engine being built for serve.zone and social.io. It should be read less as a generic SIP router and more as the media/control boundary for calls that cross browsers, SIP trunks, LAN phones, voicemail, fax, and operator dashboards.

For social.io, the direction is explicit: @serve.zone/callrouter will solve calling by giving the product a Rust-backed media path and a TypeScript-owned operations layer. Browser WebRTC calls can live in the product surface, while trunk/device integration, call state, and media mixing stay in the service layer.

The project was already covered as part of the April 2026 code.foss.global update. The current 1.28.0 line makes the interesting part clearer: performance-sensitive media work is in Rust, call composition is hub-based, and the surrounding TypeScript service keeps the system configurable and operable.

Performance boundary: Rust owns the real-time path

The TypeScript side owns configuration, dashboard views, REST and WebSocket APIs, browser signaling, runtime status, and shutdown/reload orchestration. It does not parse raw SIP packets or process RTP audio.

The Rust proxy-engine owns SIP dialog handling, RTP I/O, WebRTC media sessions, codec boundaries, mixing, jitter handling, fax transport, and live call state. The two sides communicate through high-level commands and events over @push.rocks/smartrust, following the TypeScript/Rust split described in the foss.global bridge architecture note.

That matters for performance because the packet path does not depend on JavaScript timers, object churn, or application-level WebSocket handling once media is in the engine. No public benchmark numbers are documented, so the performance claim is architectural: real-time SIP/RTP/WebRTC work sits in the native process that owns the sockets and mixer.

The HiFi audio engine

The current media engine mixes calls on a 20 ms tick over a 48 kHz f32 internal bus. That is the right center of gravity for a service that has to bridge browser WebRTC and telephony codecs without treating every call as a lowest-common-denominator RTP relay.

Codec handling currently covers Opus, G.722, PCMU, and PCMA through codec-lib. The engine includes per-leg transcoding, resampling, adaptive jitter buffering, packet loss concealment, negotiated SDP payload handling, and denoising work from the recent Rust media updates.

HiFi here does not mean the public telephone network becomes lossless. It means @serve.zone/callrouter keeps an internal audio path that can normalize different codec, packet timing, and loss conditions before distributing mix-minus audio back to each participant.

Hub-based calls, not linear forwarding

@serve.zone/callrouter models a call as a hub with legs. Provider trunks, LAN SIP devices, browser WebRTC sessions, fax paths, recorders, TTS prompts, and tool legs can all be represented as participants in the same call structure.

Call hub
  provider leg: SIP/RTP trunk
  device leg: LAN SIP phone
  browser leg: WebRTC
  recorder/TTS/tool legs: call features
  fax leg: T.38/UDPTL-related paths

The mixer runs mix-minus output per leg, so each participant receives the call audio without its own contribution fed back into the stream. This is the difference between a router that forwards one SIP leg to another and a calling engine that can attach, remove, record, prompt, bridge, or extend legs around a single call state.

The REST surface reflects that model. Existing endpoints can originate calls, hang up calls, add registered device legs, add external dial-out legs, remove legs, start outbound fax jobs, list fax state, and manage voicemail messages. POST /api/transfer is present but still returns 501 not yet implemented, so transfer is not a finished workflow yet.

Pluggability around the call lifecycle

The useful spelling in prose is pluggability, and in @serve.zone/callrouter it is architectural rather than a public plugin marketplace. The service is built so call capabilities attach through typed commands, events, routes, and legs instead of being hardwired as one SIP-to-SIP path.

  • Browser clients plug in through WebRTC signaling on the dashboard WebSocket.
  • SIP providers plug in through provider registration, outbound proxy settings, digest auth, and route rules.
  • LAN phones plug in as registered SIP devices with explicit target matching.
  • Voicemail plugs in through voiceboxes, WAV storage, heard-state APIs, and call recording flows.
  • Fax plugs in through fax boxes, job tracking, inbox metadata, TIFF downloads, and T.38/UDPTL-related media paths.
  • Operations plug in through GET /api/status, WS /ws, dashboard views, and config reload paths.

That gives social.io a practical route to calling: browser-first calls can use the product UI, while @serve.zone/callrouter supplies the service-owned call engine underneath. If a call needs to leave the browser world, the same hub can bridge toward SIP trunks or devices instead of handing control to a separate PBX.

Ecosystem note. serve.zone services usually put operational control in TypeScript and move packet or media handling into Rust where latency, memory control, and protocol correctness matter. @serve.zone/callrouter applies that pattern to telephony.

The result is a focused calling layer: a high-fidelity Rust media engine, a hub-based leg model, and TypeScript-owned operations. That is why @serve.zone/callrouter is the right place to solve calling for social.io.