Skip to main content
Normalized for Mintlify from knowledge-base/aiconnected-apps-and-modules/modules/aiConnected-voice/system-architecture.mdx.

Voice by aiConnected — System Architecture Overview \

Document Information \


Table of Contents \

Voice by aiConnected — System Architecture Overview Document Information Table of Contents 1. Introduction 1.1 Purpose 1.2 Scope 1.3 Architecture Principles 1.4 Terminology 2. System Overview 2.1 What the System Does 2.2 High-Level Architecture Diagram 2.3 Component Summary 3. Component Architecture 3.1 API Gateway 3.1.1 Overview 3.1.2 Responsibilities 3.1.3 Architecture 3.1.4 Key Endpoints 3.1.5 Configuration 3.2 WebRTC Bridge 3.2.1 Overview 3.2.2 Responsibilities 3.2.3 Architecture 3.2.4 Audio Flow 3.2.5 Call State Machine 3.2.6 Configuration 3.3 Agent Service 3.3.1 Overview 3.3.2 Responsibilities 3.3.3 Architecture 3.3.4 Voice Pipeline Detail 3.3.5 Configuration 3.4 Worker Service 3.4.1 Overview 3.4.2 Responsibilities 3.4.3 Architecture 3.4.4 Task Definitions 3.4.5 Configuration 3.5 Chatterbox TTS Service 3.5.1 Overview 3.5.2 Responsibilities 3.5.3 Architecture 3.5.4 API Endpoints 3.5.5 Configuration 4. Data Flow Architecture 4.1 Inbound Call Flow 4.2 Outbound Call Flow 4.3 Transfer Flow 4.4 Tool Calling Flow 5. Service Boundaries 5.1 Service Responsibility Matrix 5.2 Service Communication 5.3 Event Catalog 5.4 API Contracts Between Services 5.4.1 WebRTC Bridge → Agent Service 5.4.2 Agent Service → WebRTC Bridge 5.4.3 Agent Service → Chatterbox TTS 6. Network Topology 6.1 Network Diagram 6.2 Port Matrix 6.3 Firewall Rules 6.4 DNS Configuration 7. External Service Dependencies 7.1 Dependency Map 7.2 Service Level Objectives 7.3 Authentication and Credentials 7.4 Rate Limits 8. Internal Service Architecture 8.1 Service Template 8.2 Shared Libraries 8.3 Configuration Management 9. Data Architecture 9.1 Database Schema Overview 9.2 Core Tables tenants agents calls transcripts 9.3 Redis Data Structures 9.4 Data Retention Policy 10. Security Architecture 10.1 Security Layers 10.2 Authentication Flow 10.3 Data Encryption 11. Scalability Architecture 11.1 Horizontal Scaling Strategy 11.2 Capacity Planning 11.3 Auto-Scaling Configuration 12. Failure Modes and Recovery 12.1 Failure Scenarios 12.2 Circuit Breaker Configuration 12.3 Graceful Degradation Hierarchy 13. Monitoring and Observability 13.1 Metrics Architecture 13.2 Key Metrics 13.3 Logging Strategy 13.4 Alerting Rules 14. Deployment Architecture 14.1 Container Architecture 14.2 Dokploy Configuration 14.3 Environment Promotion 15. Architecture Decision Records ADR-001: Use GoToConnect for Telephony ADR-002: Use LiveKit for Real-Time Audio ADR-003: Self-Host TTS on RunPod ADR-004: Use Redis for Call State ADR-005: PostgreSQL for Persistent Data Appendix A: Glossary Appendix B: Document History

  1. Introduction \

1.1 Purpose \

This document provides a comprehensive technical overview of the Voice by aiConnected platform architecture. It serves as the authoritative reference for understanding how the system is structured, how components interact, and the rationale behind key architectural decisions. This document is intended for:
  • Engineers implementing the system
  • Technical reviewers evaluating the architecture
  • Operations teams deploying and maintaining the platform
  • Future maintainers who need to understand the system design

1.2 Scope \

This document covers:
  • High-level system architecture and component relationships
  • Detailed data flows for all major operations
  • Service boundaries and responsibilities
  • Network topology and communication patterns
  • Integration points with external services
  • Scalability and reliability considerations
This document does not cover:
  • Detailed API specifications (see Document ARCH-023: API Specification)
  • Implementation-level code design (see individual service documents)
  • Operational procedures (see Document OPS-025: Deployment Runbook)

1.3 Architecture Principles \

The Voice by aiConnected architecture is guided by the following principles: 1. Latency is King Every architectural decision prioritizes minimizing end-to-end latency. Voice conversations require sub-second response times to feel natural. We stream everything, avoid batching, and minimize network hops. 2. Graceful Degradation The system must continue operating when components fail. Each service has fallback behaviors, and partial functionality is preferred over complete failure. 3. Horizontal Scalability The system scales by adding instances, not by making instances larger. State is externalized to shared stores (PostgreSQL, Redis) so any instance can handle any request. 4. Tenant Isolation Multiple businesses share the same infrastructure, but their data and configurations are strictly isolated. A failure or misconfiguration for one tenant must not affect others. 5. Observable by Default Every component emits metrics, logs, and traces. We can understand system behavior in production without deploying debugging code. 6. Infrastructure Ownership Where It Matters We own infrastructure for components where it provides cost or capability advantages (TTS), but use managed services where operational burden outweighs benefits (telephony routing, real-time audio).

1.4 Terminology \


  1. System Overview \

2.1 What the System Does \

Voice by aiConnected is a multi-tenant Voice AI platform that enables businesses to deploy AI agents capable of handling phone conversations. The system:
  1. Receives phone calls via integration with GoToConnect PBX
  2. Transcribes speech using Deepgram’s streaming STT
  3. Generates responses using Anthropic’s Claude LLM
  4. Synthesizes speech using self-hosted Chatterbox TTS
  5. Executes actions via webhook-based tool calling
  6. Transfers calls to human agents when appropriate
  7. Tracks usage for billing and analytics

2.2 High-Level Architecture Diagram \

2.3 Component Summary \


  1. Component Architecture \

3.1 API Gateway \

3.1.1 Overview \

The API Gateway is the public-facing entry point for all HTTP traffic. It handles authentication, request routing, rate limiting, and serves as the control plane for tenant and agent management.

3.1.2 Responsibilities \

  • Authentication: Validate API keys, issue and verify JWT tokens
  • Authorization: Enforce tenant-scoped access control
  • Request Routing: Direct requests to appropriate internal services
  • Rate Limiting: Protect against abuse and ensure fair resource allocation
  • Request Validation: Validate payloads against OpenAPI schemas
  • Response Formatting: Ensure consistent API response structure
  • Audit Logging: Record all API operations for compliance

3.1.3 Architecture \

3.1.4 Key Endpoints \

3.1.5 Configuration \


3.2 WebRTC Bridge \

3.2.1 Overview \

The WebRTC Bridge is the critical component that connects the traditional telephone network (via GoToConnect) to the real-time AI processing infrastructure (via LiveKit). It handles bidirectional audio streaming, protocol translation, and call lifecycle management.

3.2.2 Responsibilities \

  • WebRTC Signaling: Handle SDP offer/answer exchange with GoToConnect
  • Audio Reception: Receive audio frames from GoToConnect WebRTC connection
  • Audio Transmission: Send synthesized audio back to GoToConnect
  • LiveKit Integration: Publish and subscribe to audio tracks in LiveKit rooms
  • Call Control: Execute transfers, holds, and other call control operations
  • State Management: Maintain call state and handle state transitions

3.2.3 Architecture \

3.2.4 Audio Flow \

3.2.5 Call State Machine \

3.2.6 Configuration \


3.3 Agent Service \

3.3.1 Overview \

The Agent Service hosts the AI agents that participate in phone conversations. It uses the LiveKit Agents SDK to manage the voice pipeline (STT → LLM → TTS) and handles conversation logic, tool calling, and transfer decisions.

3.3.2 Responsibilities \

  • Agent Lifecycle: Spawn, manage, and terminate AI agent instances
  • Voice Pipeline: Orchestrate STT, LLM, and TTS components
  • Conversation Management: Maintain conversation context and history
  • Tool Execution: Handle function calling and webhook dispatch
  • Transfer Logic: Determine when and how to transfer to humans
  • Interruption Handling: Manage barge-in and conversation flow

3.3.3 Architecture \

3.3.4 Voice Pipeline Detail \

3.3.5 Configuration \


3.4 Worker Service \

3.4.1 Overview \

The Worker Service handles asynchronous background jobs that don’t need to happen in real-time. This includes usage aggregation, transcript processing, webhook retries, and scheduled tasks.

3.4.2 Responsibilities \

  • Usage Aggregation: Compile per-tenant usage statistics for billing
  • Transcript Processing: Post-process and store call transcripts
  • Webhook Delivery: Retry failed webhook deliveries
  • Scheduled Tasks: Execute periodic maintenance jobs
  • Report Generation: Generate usage reports and analytics

3.4.3 Architecture \

3.4.4 Task Definitions \

3.4.5 Configuration \


3.5 Chatterbox TTS Service \

3.5.1 Overview \

The Chatterbox TTS Service runs on a dedicated GPU instance (RunPod RTX A5000) and provides speech synthesis for all agents. It exposes a simple HTTP API that the Agent Service calls to convert text to audio.

3.5.2 Responsibilities \

  • Speech Synthesis: Convert text to natural-sounding speech
  • Voice Management: Load and cache voice models
  • Streaming Output: Support chunked audio output for low latency
  • Paralinguistics: Process tags like [laugh], [cough]

3.5.3 Architecture \

3.5.4 API Endpoints \

3.5.5 Configuration \


  1. Data Flow Architecture \

4.1 Inbound Call Flow \

This section details the complete data flow for an inbound phone call, from the moment it arrives at GoToConnect to when the conversation ends.

4.2 Outbound Call Flow \

4.3 Transfer Flow \

4.4 Tool Calling Flow \


  1. Service Boundaries \

5.1 Service Responsibility Matrix \

5.2 Service Communication \

5.3 Event Catalog \

5.4 API Contracts Between Services \

5.4.1 WebRTC Bridge → Agent Service \

5.4.2 Agent Service → WebRTC Bridge \

5.4.3 Agent Service → Chatterbox TTS \


  1. Network Topology \

6.1 Network Diagram \

6.2 Port Matrix \

6.3 Firewall Rules \

6.4 DNS Configuration \


  1. External Service Dependencies \

7.1 Dependency Map \

7.2 Service Level Objectives \

7.3 Authentication and Credentials \

7.4 Rate Limits \


  1. Internal Service Architecture \

8.1 Service Template \

All internal services follow a consistent structure:

8.2 Shared Libraries \

8.3 Configuration Management \


  1. Data Architecture \

9.1 Database Schema Overview \

9.2 Core Tables \

tenants \

agents \

calls \

transcripts \

9.3 Redis Data Structures \

9.4 Data Retention Policy \


  1. Security Architecture \

10.1 Security Layers \

10.2 Authentication Flow \

10.3 Data Encryption \


  1. Scalability Architecture \

11.1 Horizontal Scaling Strategy \

11.2 Capacity Planning \

11.3 Auto-Scaling Configuration \


  1. Failure Modes and Recovery \

12.1 Failure Scenarios \

12.2 Circuit Breaker Configuration \

12.3 Graceful Degradation Hierarchy \


  1. Monitoring and Observability \

13.1 Metrics Architecture \

13.2 Key Metrics \

13.3 Logging Strategy \

13.4 Alerting Rules \


  1. Deployment Architecture \

14.1 Container Architecture \

14.2 Dokploy Configuration \

14.3 Environment Promotion \


  1. Architecture Decision Records \

Status: Accepted Context: We need a telephony provider for PSTN connectivity and call control. Decision: Use GoToConnect because:
  • Existing grandfathered unlimited plan at $17/user
  • Full WebRTC API with call control
  • No per-minute charges
Consequences:
  • Locked into GoToConnect infrastructure
  • Need to build custom WebRTC bridge
  • Dependent on GoToConnect API stability

Status: Accepted Context: We need infrastructure for real-time audio routing between the phone bridge and AI agents. Decision: Use LiveKit Cloud because:
  • Purpose-built Agents SDK for voice AI
  • Handles WebRTC complexity
  • Scalable managed infrastructure
Consequences:
  • Monthly LiveKit costs (~$0.01/min)
  • Dependent on LiveKit availability
  • Need to integrate with their SDK

Status: Accepted Context: TTS is a significant per-minute cost at scale. Decision: Self-host Chatterbox on RunPod RTX A5000 because:
  • Zero per-minute cost after fixed infrastructure
  • MIT license, full control
  • Competitive quality with paralinguistics
Consequences:
  • Operational overhead for GPU management
  • Need fallback provider (Resemble)
  • Slightly higher latency than Cartesia

Status: Accepted Context: Call state needs to be accessible from any service instance with low latency. Decision: Use Redis because:
  • Sub-millisecond access
  • Built-in pub/sub for events
  • Ephemeral data doesn’t need durability
Consequences:
  • State lost on Redis failure (acceptable for call state)
  • Need to handle reconnection gracefully
  • Memory limits on state size

Status: Accepted Context: We need a database for tenant configuration, call history, and billing data. Decision: Use PostgreSQL because:
  • Relational model fits our data
  • Excellent JSON support for flexible schemas
  • Managed offering available on DigitalOcean
Consequences:
  • Need to manage migrations
  • Horizontal scaling more complex than NoSQL
  • Connection pooling required



End of Document