From Retell or Vapi to FreeSWITCH and Kamailio

Moving a Voice AI product off Retell or Vapi is often described as a cost-saving project.

At enough volume, lower variable cost can absolutely be part of the case. Direct carrier relationships, infrastructure sized around the real workload and the freedom to choose each AI provider independently can change the unit economics.

But “replace the platform fee with a few servers” is not a migration plan.

A managed voice platform is carrying more responsibility than its API surface suggests: call setup, media bridging, retries, webhook normalization, interruption handling, provider integrations and dozens of awkward telephony edge cases. Replacing it means deciding which of those responsibilities belong in your product and which should remain external.

The real opportunity is not simply owning SIP infrastructure. It is owning the orchestration layer that decides what every call should do.

Start with the reason to own the stack

Retell and Vapi are useful because they compress time to market. A team can validate a workflow without first becoming a telecom operator. That is a good trade when the product is young, call volume is uncertain or the main question is whether customers want the service at all.

The trade changes when the platform becomes a constraint.

Typical reasons to consider an owned architecture include:

• voice cost has become a meaningful part of gross margin;
• the product needs routing or failover behavior the platform cannot express cleanly;
• call state must be coordinated with internal workflows in real time;
• the team needs deeper media and signalling evidence during incidents;
• different customers require different carriers, AI providers or regional paths;
• latency depends on controlling where media, STT and TTS sessions are created;
• provider abstraction has become part of the product strategy.

Those are stronger reasons than “FreeSWITCH is open source.”

Infrastructure is not free because the license is free. The business case has to survive carrier fees, compute, bandwidth, observability, engineering time, redundancy and somebody being responsible when calls fail at 03:00.

If volume is low or the workflow changes every week, a managed platform may still be the less expensive architecture.

Know what you are replacing

The first FreeSWITCH call is easy. The hundred small behaviors surrounding it are the migration.

Before designing the target system, document what the current platform does for one ordinary call:

API request
  -> destination validation
  -> carrier selection
  -> SIP originate
  -> early media
  -> answer detection
  -> AI session startup
  -> STT / LLM / TTS loop
  -> barge-in
  -> transfer or hangup
  -> recording
  -> terminal webhook
  -> billing and analytics

Then add the non-ordinary paths:

• the carrier rejects the call before a normal channel exists;
• the customer answers while the AI session is still connecting;
• early media contains speech;
• STT disconnects halfway through the call;
• the customer and application hang up simultaneously;
• a webhook is delayed, duplicated or delivered out of order;
• the transfer destination answers but the original leg disappears;
• answering-machine detection produces an uncertain result;
• the application retries a command after a timeout.

A migration that covers the happy path but not these transitions will look complete in a demo and become expensive in production.

The inventory should also distinguish product requirements from incidental platform behavior. If nobody needs a particular feature, do not rebuild it merely because the old provider had it.

Give every layer one clear job

A practical owned stack usually separates SIP routing, media processing and product orchestration.

PSTN carriers
      |
      v
  Kamailio edge
      |
      v
FreeSWITCH pool <----> STT / TTS / AI media services
      ^
      |
Call orchestration API
      |
      v
Product database, workflows and operator tools

Kamailio is the SIP edge. It can authenticate traffic, normalize carrier differences, apply routing policy, enforce admission limits and distribute calls across media nodes. It is very good at processing SIP messages. It should not become the application’s call-state database.

FreeSWITCH owns media sessions. It terminates or bridges call legs, handles RTP, plays audio, collects DTMF, records calls and connects media to the AI runtime. It should not be asked to own customer workflows, campaign rules or billing decisions.

The orchestration service owns product intent. It decides why a call exists, which workflow it belongs to, which AI configuration to use, whether a retry is allowed and what the final outcome means.

This boundary matters more than the exact deployment topology.

If business state is hidden inside dialplan variables, the product becomes difficult to test. If every SIP event directly mutates the database, late and duplicate events create impossible states. If Kamailio, FreeSWITCH and the API can all independently decide where a call goes next, nobody actually owns the call.

The orchestration layer is the product

Owning infrastructure becomes valuable when it gives the product one explicit model for calls across carriers and AI providers.

A small lifecycle might look like this:

requested     -> dialing
dialing       -> early_media
dialing       -> answered
early_media   -> answered
answered      -> ai_active
ai_active     -> transferring
transferring  -> completed
*             -> failed
*             -> terminated

The exact states will differ. The important part is that provider callbacks, SIP events and user actions become evidence requesting a transition. They are not allowed to invent state independently.

That makes several difficult behaviors manageable:

• repeated hangup events converge on one terminal outcome;
• a timed-out request can be retried without originating a second call;
• late media events cannot resurrect a completed workflow;
• an AI failure can trigger a fallback without losing call ownership;
• transfers have an explicit source leg, destination leg and completion rule;
• operators can see whether a call is waiting on SIP, media, AI or application state.

Barge-in is a good example. It sounds like an audio feature, but the product behavior spans several layers. Voice activity must be detected, current TTS playback must be stopped, buffered audio may need to be discarded and the conversation state must accept the new user turn. If each provider implements that policy differently, switching providers changes the product.

The same is true for answering-machine detection, silence timeouts, DTMF flows and transfer logic. Owning orchestration means these behaviors belong to your model, even when external services still provide parts of the signal.

Model the economics with real calls

The cost comparison should use the production workload, not a vendor headline and not the cost of one idle VM.

The existing all-in cost may include:

• managed platform usage;
• carrier or phone-number charges;
• STT, TTS and model usage;
• recording and log retention;
• failed attempts and short calls;
• support or enterprise commitments.

The owned path may include:

• direct carrier usage;
• Kamailio and FreeSWITCH compute;
• bandwidth and public IPs;
• STT, TTS and model providers;
• storage, metrics, traces and packet-capture tooling;
• standby capacity across regions or availability zones;
• engineering and on-call operations.

A useful first approximation is:

monthly contribution from migration
  = billable minutes
  × (current variable cost per minute - owned variable cost per minute)
  - additional fixed operating cost

That number should be calculated by call type. A short appointment-confirmation call, a seven-minute sales call and a transferred support call do not have the same media, AI or carrier cost.

Also model concurrency and calls per second. Average minutes determine much of the bill, while peak concurrency determines infrastructure size. Burst rate determines whether the system can start the calls at all.

Savings usually come from a combination of direct contracts, workload-aware sizing, provider choice and avoiding a platform margin on every minute. They can disappear just as quickly if the new stack requires excessive overprovisioning or constant manual operation.

Migrate the contract before the media

The safest migration begins above FreeSWITCH.

First, introduce an internal call model and a provider adapter around the current Retell or Vapi integration. The application should originate a call through its own interface and receive normalized events in its own vocabulary.

For example:

startCall()
cancelCall()
transferCall()
sendDtmf()
endCall()

call.progressing
call.answered
call.media_ready
call.transferring
call.completed
call.failed

Do not let the rest of the product depend directly on one vendor’s webhook names or payload shape.

This creates a stable boundary for the existing path and the owned path. It also exposes hidden assumptions before traffic is at risk.

Next, create canonical identifiers that survive every layer:

product_call_id
provider_call_id
sip_call_id
freeswitch_uuid
ai_session_id

A single correlated call should be traceable from the customer workflow to SIP signalling, media statistics and AI events. Without that correlation, comparing the old and new systems becomes mostly anecdotal.

Move traffic in boring stages

A staged migration is slower on a diagram and much faster during an incident.

Stage 1: Measure the current platform

Capture the baseline before changing architecture:

• call setup success by destination and carrier;
• time to first usable audio;
• STT and TTS latency;
• interruption and barge-in behavior;
• transfer success;
• dropped or one-way audio;
• terminal webhook delay;
• cost per attempted, connected and completed call.

The current system does not need to be perfect. It needs to be measurable.

Stage 2: Own the application contract

Put provider-specific APIs behind the internal orchestration interface. Normalize events, make commands idempotent and store the product lifecycle independently.

Traffic still uses the managed platform, but the application stops being structurally tied to it.

Stage 3: Build one narrow owned call path

Start with one region, one carrier, one call type and a simple workflow. Avoid choosing the most complicated production use case as the first proof.

Bring up the Kamailio edge, a small FreeSWITCH pool, media integration and the minimum operational dashboard required to explain a failed call.

Stage 4: Reproduce behavior, not API names

Port the product behaviors that matter: interruption policy, silence handling, transfers, DTMF, recording, AMD and terminal outcomes.

The new path does not need internal parity. It needs customer-visible parity.

Stage 5: Route a controlled traffic slice

Ramp by tenant, campaign, destination or explicit percentage. Keep the old path available as a rollback target while the new one proves itself under real timing and carrier behavior.

The routing decision should be recorded on every call so operators know which stack produced the result.

Stage 6: Retire dependencies deliberately

Remove the managed path only after the owned path has survived bursts, long calls, dependency failures and ordinary production incidents. Dual-running costs money, but a rushed cutover usually costs more.

Specific vendor features and SIP interconnection options change over time, so validate the current Retell or Vapi contract before selecting the exact transition topology.

Reliability is part of the financial model

A cheaper minute that produces more failed conversations is not cheaper.

The acceptance criteria should include correctness and customer experience:

originate acceptance and carrier rejection rate
p50 / p95 time to first audio
speech-to-response latency
audio gaps and concealed samples
barge-in stop latency
transfer completion rate
AMD precision and uncertain-result rate
duplicate or missing terminal outcomes
orphaned SIP and media sessions
event-processing lag under burst load

Test more than stable concurrency.

Use ramp tests for the active-call ceiling, burst tests for CPS, churn tests for state races, soak tests for leaks and degraded-dependency tests for slow STT, TTS, databases and carriers.

The rollback path should be exercised too. A fallback that only exists in architecture documentation is not a fallback.

Price the risks honestly

An owned platform introduces risks that managed services previously absorbed.

The team now needs to handle SIP fraud, carrier variation, certificate rotation, media-port capacity, NAT behavior, regional outages, codec negotiation and emergency operational access. Call recording and transcript policies may create additional compliance work. Observability must reach beyond application logs into SIP and RTP evidence.

Feature parity can also consume more time than expected. A workflow that looked like one API call may have depended on several undocumented timing behaviors.

None of this makes the migration a bad idea. It makes operational capability one of the inputs to the decision.

A permanent hybrid architecture is also valid. Some call types may justify an owned path while low-volume regions, experimental workflows or unusual languages remain on a managed platform.

The practical decision

Migrating from Retell or Vapi makes sense when three things are true:

1. The measured volume creates a credible economic advantage.
2. Owning orchestration unlocks product behavior or reliability that matters.
3. The team is prepared to operate telephony and media as a production system.

If only the first condition is true, the savings may be consumed by engineering and incidents. If only the second is true, a provider adapter or hybrid design may be enough. If the third is missing, infrastructure ownership becomes operational debt.

The migration should therefore begin with a canonical call model, correlated evidence and a traffic-routing boundary — not with a large FreeSWITCH cluster.

Servers are the easy part. The durable advantage is knowing exactly who owns the call, why it is in its current state and how to move it safely to the next one.