Deploying VoiceBridge on Cloud vs On-Prem Infrastructure

Deploying VoiceBridge on Cloud vs On-Prem Infrastructure (What Actually Changes)

VoiceBridge is a real-time media service. It controls Asterisk using ARI (control plane) and moves live audio using RTP over UDP (media plane). That combination is what makes deployment decisions different from “normal web apps”.

Cloud vs on-prem is not a branding decision. It changes:

• RTP reachability (public IP, NAT, firewall, UDP port exposure)
• Latency and jitter (AI turn-taking and barge-in quality)
• Security boundaries (ARI exposure risk, RTP abuse risk, DB secrets)
• Operational control (debugging, packet capture, deterministic routing)
• Cost model (bandwidth, compute, scale-out behavior)

This article explains the intended production approaches for VoiceBridge deployments and how the repository design maps to both modes.

VoiceBridge repo:
https://github.com/mylinehub/omnichannel-crm/tree/main/mylinehub-voicebridge

Canonical architecture reference:
https://mylinehub.com/articles/mylinehub-voicebridge-architecture

What VoiceBridge Needs From Infrastructure (Non-Negotiables)

Before comparing cloud and on-prem, be clear on the minimum requirements. VoiceBridge needs:

• Stable ARI connectivity to Asterisk (HTTP/WebSocket, credentialed)
• Deterministic UDP reachability for RTP ports between Asterisk and VoiceBridge
• Per-call session stability (a call must stay pinned to the instance that owns its RTP sockets)
• Low jitter (voice quality collapses faster from jitter than from average latency)
• Safe secret handling (ARI creds, DB creds, AI keys)

The implementation places these responsibilities in clear components:

• ARI control and media graph creation: src/main/java/com/mylinehub/voicebridge/ari/impl/AriBridgeImpl.java
• ExternalMedia orchestration (RTP leg creation via ARI): src/main/java/com/mylinehub/voicebridge/ari/impl/ExternalMediaManagerImpl.java
• RTP port allocation strategy (limits per instance): src/main/java/com/mylinehub/voicebridge/rtp/RtpPortAllocator.java
• Symmetric RTP endpoint learning (NAT safety): src/main/java/com/mylinehub/voicebridge/rtp/RtpSymmetricEndpoint.java
• RTP header/timestamp discipline (real duplex correctness): src/main/java/com/mylinehub/voicebridge/rtp/RtpPacketizer.java
• Runtime knobs (bind ports, defaults): src/main/resources/application.properties

Deployment Topologies You Actually Use

In production you typically pick one of these topologies:

Topology A: On-Prem Asterisk + On-Prem VoiceBridge (lowest risk)

• Asterisk/FreePBX runs inside the customer LAN/DC
• VoiceBridge runs on the same LAN/DC (VM, bare metal, or container)
• RTP stays private (no internet UDP exposure)
• ARI stays private (no public control plane)

This is the most stable path for duplex voice because you remove public-internet RTP variability.

Topology B: On-Prem Asterisk + Cloud VoiceBridge (hybrid, hardest networking)

• Asterisk is in the customer site
• VoiceBridge is in cloud
• You must route RTP across WAN and handle NAT both directions
• You must expose a controlled UDP range at least one side

This works, but only when you are disciplined with ports, static public IPs, and firewall rules.

Topology C: Cloud Asterisk + Cloud VoiceBridge (cloud-native)

• Asterisk and VoiceBridge live in the same cloud VPC/subnet
• RTP is private inside the VPC
• Public exposure is limited to SIP ingress (and even that can be protected)

This is the cleanest cloud model because you avoid cross-network RTP.

Topology D: Multi-site On-Prem + Central Cloud VoiceBridge (enterprise hybrid)

• Multiple on-prem PBXs connect to a central VoiceBridge cluster
• Requires site-to-site VPN and deterministic RTP policies
• Better than “open RTP to internet”, but still WAN dependent

Cloud vs On-Prem: The Real Differences (RTP + Latency + Debugging)

1) RTP Reachability and Port Exposure

VoiceBridge is designed to allocate and bind RTP ports per session. The allocator is explicit: src/main/java/com/mylinehub/voicebridge/rtp/RtpPortAllocator.java.

On-prem advantage: you can keep RTP fully private (LAN) and restrict UDP tightly.

Cloud challenge: if RTP must cross the public internet, you must handle:

• UDP port range exposure (narrow, controlled)
• Static IPs / predictable routing
• Symmetric NAT quirks
• Firewall state and UDP timeouts

NAT-safe behavior is handled in: src/main/java/com/mylinehub/voicebridge/rtp/RtpSymmetricEndpoint.java. This is not optional in real networks.

2) Latency and Jitter: Cloud Is Not Always “Faster”

Duplex AI calling quality depends more on jitter and consistency than on a single average latency number. The RTP timing discipline is implemented in: src/main/java/com/mylinehub/voicebridge/rtp/RtpPacketizer.java.

On-prem usually wins for “human feel” because:

• RTP stays on LAN
• Jitter is low and predictable
• Barge-in cut-through is more reliable

Cloud can still be excellent when:

• Asterisk and VoiceBridge are in the same VPC
• You avoid cross-region traffic
• You don’t ship RTP over consumer-grade WAN links

3) Debugging and Packet Capture

When duplex breaks, you end up tracing RTP and confirming direction, SSRC changes, payload types, and timing drift. On-prem makes this easier:

• tcpdump is straightforward
• Wireshark capture is local
• You can isolate physical network issues faster

In cloud, debugging is still possible, but you must plan for:

• VPC flow logs
• Node-level tcpdump (if Kubernetes)
• Security groups / NACL verification
• Cross-zone routing surprises

Security Model Differences: ARI and RTP Exposure

VoiceBridge security is fundamentally about preventing unwanted access to:

• ARI (control plane — can manipulate calls)
• RTP UDP range (media plane — can inject/flood)
• Database (contains runtime config, potentially ARI credentials)

On-Prem Security Posture (preferred)

• ARI stays on private IPs only
• RTP stays on private LAN, no public UDP
• DB stays private and close

Cloud Security Posture (must be explicit)

• ARI should still be private (VPC only, VPN only)
• RTP should be VPC-only whenever possible
• If RTP must be public, restrict by source IP and port range tightly
• Use separate security groups / NACLs for SIP vs ARI vs RTP vs DB

Where ARI is used inside the project:

• src/main/java/com/mylinehub/voicebridge/ari/AriWsClient.java (WebSocket ARI access)
• src/main/java/com/mylinehub/voicebridge/ari/impl/AriBridgeImpl.java (bridge control)
• src/main/java/com/mylinehub/voicebridge/ari/impl/ExternalMediaManagerImpl.java (ExternalMedia control)

If ARI is exposed publicly, the PBX control surface is exposed. In production: treat ARI like “root access to calls”.

Cost Model: Cloud vs On-Prem for Duplex AI Voice

Cost is not only “server price”. Duplex AI calls consume:

• Always-on CPU per call (RTP + AI streams + conversion)
• Bandwidth (RTP in + RTP out + AI streaming)
• Operational overhead (observability, scaling, failover, upgrades)

Cloud cost tends to increase with:

• High outbound bandwidth (especially cross-region)
• Peak concurrency bursts (autoscaling adds cost quickly)
• Managed load balancers / NAT gateways for UDP patterns

On-prem cost tends to increase with:

• Hardware provisioning and lifecycle
• Datacenter power/cooling
• On-call operations capability

A practical hybrid that often wins: keep RTP local (on-prem) and keep AI worker access outbound only (VoiceBridge connects outward to AI), rather than bringing RTP in from the internet.

Containerization: VoiceBridge as a Java Service

VoiceBridge is built to run cleanly as a containerized service (Spring Boot style). The repository includes:

• docker/Dockerfile (container image build)
• docker-compose.yml (local orchestration pattern)
• .env.example (environment variable approach)
• src/main/resources/application.properties (bind ports and defaults)

On-Prem Containerization (simple and effective)

• Run VoiceBridge in Docker on the same LAN as Asterisk
• Publish the UDP port range needed for RTP inside the LAN only
• Keep ARI restricted to VoiceBridge host/IP

Cloud Containerization (works, but UDP needs design)

• Run VoiceBridge in ECS/Kubernetes/VM containers
• Expose RTP carefully (prefer VPC-only)
• Use static pod/node IP strategies if Asterisk must reach RTP directly

The key point: “containerized” does not automatically mean “scalable”. You must still design UDP reachability and session pinning.

Kubernetes Deployment Considerations (Cloud or On-Prem K8s)

Kubernetes is excellent for managing replicas of a Java service, but RTP introduces constraints.

What Kubernetes helps with

• Running multiple VoiceBridge replicas
• Health checks and restarts
• Resource isolation (CPU/memory limits)
• Autoscaling based on real metrics

What you must design explicitly for RTP

• Calls must remain pinned to one pod (session ownership)
• Asterisk must be able to reach the pod’s UDP ports reliably
• You must avoid “random UDP load balancing” per packet

Practical patterns that actually work

• HostNetwork pods (simpler RTP, fewer layers, node-level port planning required)
• DaemonSet (one VoiceBridge per node, predictable UDP ranges)
• Static sharding (route certain trunks/DIDs to a specific VoiceBridge deployment)

Decision Guide: Which Deployment Should You Choose?

Choose On-Prem When:

• You need lowest latency and best barge-in feel
• You cannot safely expose UDP ranges to public internet
• You need strong privacy boundaries (recordings/transcripts stay local)
• Your telecom environment is already on-prem (FreePBX, SIP trunks, gateways)

Choose Cloud When:

• Asterisk is already in cloud (or can be moved into the same VPC)
• You have strong DevOps for VPC security and observability
• You need elastic scale (burst handling) and can keep RTP private
• You can guarantee stable routing and static addressing policies

Choose Hybrid When:

• You need centralized management but have multiple PBX sites
• You can use VPN/private links to keep ARI+RTP off the public internet
• You accept WAN jitter tradeoffs and design buffer/timing accordingly

Production Checklist (Cloud or On-Prem)

• Confirm RTP port range and capacity: rtp/RtpPortAllocator.java + application.properties
• Keep ARI private and restricted: ari/AriWsClient.java and firewall rules
• Verify symmetric RTP learning under NAT: rtp/RtpSymmetricEndpoint.java
• Validate timing discipline (no bursty send, no drift): rtp/RtpPacketizer.java
• Store secrets safely (do not bake into images): .env.example pattern
• Ensure call sessions are pinned per instance: session/CallSession.java architecture assumption

Summary

VoiceBridge can run both on cloud and on-prem because it is a Java service with clear configuration patterns and container support. The real deciding factor is not “where Java runs”. The deciding factor is: where RTP runs and how deterministic it is.

If you can keep Asterisk and VoiceBridge close (same LAN or same VPC), cloud deployments can be excellent. If RTP must cross the public internet, on-prem or VPN-based hybrid deployments are usually safer and more stable.

Repo: https://github.com/mylinehub/omnichannel-crm/tree/main/mylinehub-voicebridge