How it works
- A telephony provider connects (WebSocket or LiveKit SDK)
- VoxCore fetches bot configuration from VoxBridge
- The pipeline runs: customer speech → STT → LLM → TTS → audio response
- On call end: recording uploads, post-call analysis runs, results webhook fires
Transports
VoxCore supports four transport modes:| Transport | Protocol | Audio | Use case |
|---|---|---|---|
| WebSocket | iCallMate WSS | 8kHz LINEAR16 | iCallMate telephony dialler |
| LiveKit SIP Inbound | LiveKit SDK | 16kHz | DID → LiveKit room → bot |
| LiveKit SIP Outbound | LiveKit SDK | 16kHz | VoxBridge-triggered outbound calls |
| Exotel | Exotel WebSocket | 8kHz LINEAR16 | Exotel Voicebot applet |
Tech stack
| Component | Technology |
|---|---|
| Runtime | Python 3.12, FastAPI, uvicorn |
| Pipeline framework | Pipecat 0.0.108 |
| STT | Deepgram Nova-3, Soniox |
| LLM | Google Gemini, OpenAI, Google Vertex AI |
| TTS | ElevenLabs, Sarvam, Tarang |
| VAD | Silero (ONNX) |
| Turn detection | SmartTurnV3 (ONNX) |
| Recording storage | DigitalOcean Spaces (S3-compatible) |
| Package manager | uv |
Statelessness
VoxCore is architecturally stateless. No business data persists between calls — transcripts, metrics, and pipeline state are all scoped to a single call and destroyed when it ends. The only cross-call state isCallTracker, an in-memory concurrency limiter. It tracks active call IDs (not call content) to enforce MAX_CONCURRENT_CALLS per worker, and cleans up when calls complete. Workers can be independently restarted without data loss.