AI Summary: This article is for backend and API integration engineers evaluating how Cartesia AI fits into a telephony stack. Cartesia AI exposes real-time WebSocket endpoints for TTS and STT but provides no PSTN connectivity, phone numbers, or SIP transport. Cartesia’s realtime STT endpoint accepts raw audio in the encoding and sample rate you declare when connecting, including 16-bit PCM and μ-law at 8 kHz, so telephony audio can be sent without resampling. The article maps the full audio path, names the four integration patterns, and explains where Teler’s programmable voice API closes the carrier-to-model gap.
Scope: This walkthrough covers integrating Cartesia AI with a live PSTN call path, verified against Cartesia’s 2026 changelog and API version 2026-08-14 as documented in September 2026. It does not cover Cartesia Managed Agents or the Cartesia Agents API surface.
Quick Answer: Cartesia AI handles real-time speech synthesis and transcription over WebSocket, but it does not provide phone numbers, SIP trunking, or PSTN access. To put Cartesia AI on a phone call in 2026, you need a separate telephony layer that terminates the carrier audio and bridges the media stream over WebSocket to Cartesia, with the encoding and sample rate declared to match the call audio.
Cartesia AI is a real-time voice model platform that sits at the model layer, not the carrier layer. Connecting it to a phone call requires a telephony transport that handles PSTN termination, codec conversion, and media bridging before any Cartesia AI endpoint sees audio.
What is Cartesia AI?
Cartesia AI is an AI lab that builds real-time voice models and exposes them through WebSocket-based TTS and STT APIs. It occupies the model and inference layer of a voice stack, not the telephony transport layer. Cartesia does not provision phone numbers, does not connect to the Public Switched Telephone Network (PSTN), and does not speak Session Initiation Protocol (SIP). A developer who wants to reach a caller on a standard phone line must supply the carrier connectivity, the Real-time Transport Protocol (RTP) handling, the codec translation, and the call control logic themselves. Cartesia’s job starts once clean, correctly formatted audio arrives at its WebSocket endpoint.
Why does the telephony gap matter for Cartesia AI integrations?
The gap is not conceptual, it is a concrete format mismatch at the codec boundary. Narrowband telephony audio, defined in ITU-T G.711, runs at 8 kHz with mu-law or A-law encoding. Cartesia’s realtime STT endpoint takes raw binary audio whose format you declare with the encoding and sample_rate query parameters. Supported encodings include pcm_s16le, pcm_mulaw, and pcm_alaw, so 8 kHz telephony audio can be sent as is, as long as those parameters match it. A GitHub issue filed in February 2026 against a voice-call plugin confirms this directly: Cartesia outputs PCM and the audio must be converted to mu-law 8 kHz at the Twilio boundary before the call path works. That conversion step is not optional and it is not provided by Cartesia.
Beyond the codec, telephony introduces jitter. RFC 3550 defines RTP as the standard transport for real-time media, and RTP packets arrive with variable inter-packet delay. A jitter buffer absorbs that variance before audio reaches a speech model. Cartesia’s documented constraint is that realtime endpoints accept audio at 1x realtime, meaning one second of audio per second. Jitter that causes bursts or gaps violates that constraint and produces clipped words or false turn boundaries.
What does the full audio path look like from carrier to Cartesia AI?
Every hop in the path has a format owner. The table below maps each hop so you can see where the conversion work lives.
| Hop | Format | Sample rate | Transport | Owner |
|---|---|---|---|---|
| PSTN carrier to termination point | G.711 mu-law or A-law PCM | 8 kHz | RTP over UDP | Carrier or SIP trunk provider |
| Termination point to media bridge | G.711 or transcoded PCM | 8 kHz or 16 kHz | RTP or internal pipe | Media server or telephony API |
| Media bridge to Cartesia STT | Raw PCM, μ-law, or A-law, declared via encoding and sample_rate | 8 kHz accepted | WebSocket | Your application |
| Cartesia TTS to media bridge | PCM (raw audio) | Cartesia output rate | WebSocket | Your application |
| Media bridge to PSTN caller | G.711 mu-law or A-law | 8 kHz | RTP over UDP | Media server or telephony API |
Hops three and four are yours to build. If you declare the encoding and sample rate to match your telephony stream on the STT side, and request the same format for TTS output, neither hop needs conversion. The resampling library, the buffer size, and the error handling are decisions you make before a single byte reaches a Cartesia endpoint.
Prerequisites before integrating Cartesia AI with telephony
- A Cartesia account with an API key and access to the
/stt/turns/websocketor/stt/websocketendpoint - A telephony layer that exposes raw RTP or PCM audio over WebSocket: Teler, Twilio Media Streams, or a self-hosted media server
- A resampling library only if your STT or TTS settings don’t match the call audio. With Teler’s 16-bit PCM stream at 8 kHz, Cartesia can take and return audio in that format directly.
- Python 3.9 or later, or Node.js 18 or later, depending on which Cartesia SDK you use
- The official Cartesia Python SDK, installable from the
cartesia-pythonrepository at github.com/cartesia-ai/cartesia-python - Network reachability between your application server and both the Cartesia API host (
api.cartesia.ai) and your telephony provider’s WebSocket endpoint - A phone number provisioned through your telephony provider, pointed at a webhook or WebSocket URL your server controls
How to integrate Cartesia AI into a live phone call
The steps below use Teler as the telephony layer. Teler streams call audio over WebSocket as 16-bit linear PCM at 8k or 16k, base64-encoded in JSON messages. Chunk size is a multiple of 20 ms and defaults to 400 ms; Cartesia recommends sending audio in small chunks (around 100 ms), so lower it in your stream Call Flow. See the Teler documentation for the full WebSocket message schema.
Step 1: Open the Teler media stream and decode incoming audio
When a call arrives, Teler sends audio chunks over a WebSocket connection to your server. Each chunk is base64-encoded 16-bit PCM at the sample rate you configured. Connect to Cartesia with encoding=pcm_s16le and sample_rate set to the same rate, and you can forward the decoded bytes as is.
import asyncio
import websockets
import json
async def handle_teler_stream(websocket):
async for message in websocket:
event = json.loads(message)
if event["type"] == "audio":
# 16-bit PCM at your configured sample rate
audio_chunk = base64.b64decode(event["data"]["audio_b64"])
await forward_to_cartesia(audio_chunk)
Watch the type field: Teler sends one “start” message with stream metadata, then “audio” messages. There’s no end message; when the call ends, Teler closes the socket
Step 2: Open a Cartesia STT WebSocket session and stream audio
Cartesia’s /stt/turns/websocket endpoint uses automatic turn detection, which is the recommended starting point for voice agents. You open the WebSocket, send audio chunks as binary frames, and receive transcript events with an is_final flag. The Cartesia-Version header must match the API version you are targeting; the 2026 changelog introduced version 2026-08-14.
import os
import websockets
CARTESIA_STT_URL = (
"wss://api.cartesia.ai/stt/turns/websocket"
"?model=ink-2&encoding=pcm_s16le&sample_rate=8000"
)
async def open_cartesia_stt():
# additional_headers requires websockets 14+
return await websockets.connect(
CARTESIA_STT_URL,
additional_headers={
"Authorization": f"Bearer {os.environ['CARTESIA_API_KEY']}",
"Cartesia-Version": CARTESIA_VERSION,
},
)
async def forward_to_cartesia(cartesia_ws, audio_chunk: bytes):
# Raw binary frames; format must match encoding and sample_rate
await cartesia_ws.send(audio_chunk) Cartesia enforces a 1x realtime constraint: the endpoint accepts only one second of audio data per second. Sending a burst of buffered audio will cause the session to fall behind or drop frames.
Step 3: Run the LLM and stream TTS back into the call
When Cartesia returns a final transcript, pass it to your LLM, stream the text response into a Cartesia TTS WebSocket context using push(), and inject the resulting PCM audio back into the Teler stream. Teler accepts audio injected mid-call; send the {"type": "clear"} message to flush queued playback if the caller interrupts (barge-in). Teler targets sub-100ms packet delivery as a design specification, which matters here because TTS latency compounds with LLM latency.
async def stream_tts_to_call(text: str, teler_ws):
# Open a Cartesia TTS context and push LLM text
async with client.tts.websocket() as tts_ws:
ctx = tts_ws.context()
await ctx.push(text=text, voice_id="YOUR_VOICE_ID")
await ctx.no_more_inputs()
async for audio_event in ctx:
# Request pcm_s16le at 8000 Hz from Cartesia TTS so no conversion is needed
pcm_chunk = audio_event.audio
await teler_ws.send(json.dumps({
"type": "audio",
"audio_b64": base64.b64encode(pcm_chunk).decode(),
"chunk_id": uuid.uuid4().hex, # required, unique per stream
})) Note that the 2026 Cartesia changelog requires Voice ID on TTS WebSocket calls; passing embeddings directly is no longer supported after API version 2026-08-14.
For a working reference, the cartesia-python repository at github.com/cartesia-ai/cartesia-python contains the official Python SDK with WebSocket streaming examples. The LiveKit agents repository also merged Cartesia WebSocket support and speech continuation in a pull request from August 2024, which is a useful community reference for the session lifecycle pattern.
Most teams discover their latency problem is not the model, it is the resampling hop they added between the carrier and the STT engine. Get that conversion right first, then tune the chunk size.
– Subhash Kalluri, Founder & CEO, FreJun
What breaks in production when integrating Cartesia AI with telephony?
The failure modes below come from GitHub issues filed against real integrations. Frequency is stated honestly.
| Symptom | Root cause | Fix | Frequency |
|---|---|---|---|
WebSocket drops with no close frame received or sent after silence | Cartesia disconnects the WebSocket after inactivity; retry counter not reset after reconnect | Harden reconnect logic; reset retry counter after a successful connection | Reported twice (Pipecat, LiveKit agents) |
| 429 Too Many Requests when opening new WebSocket connections | Client-side pool did not cap concurrency; Cartesia provider limit hit during parallel sessions | Add client-side connection pooling and clean up dangling connections | Reported once (LiveKit agents) |
| PCM audio incompatible with Twilio call path | Cartesia outputs PCM; Twilio requires mu-law 8 kHz at the telephony boundary | Convert Cartesia PCM stream to mu-law 8 kHz before handing to the carrier | Reported once (openclaw issue #9165) |
| TTS WebSocket calls fail after API version upgrade | Cartesia deprecated embeddings on TTS WebSocket, bytes, and SSE endpoints; Voice ID now required | Migrate callers to Voice ID; pin or upgrade to API version 2026-08-14 | Reported in Cartesia 2026 changelog |
The idle-silence disconnect catches the most teams because it does not appear during short development sessions. A call that goes quiet for several minutes, a hold scenario or a slow user, will drop the Cartesia WebSocket. You need a reconnect loop with a reset counter before you go to production. The Pipecat project filed this issue in September 2024 and reported a reconnection-improvement follow-up; the LiveKit agents project filed a related issue in May 2025.
One honest limitation of Teler worth stating: Teler streams at 8k by default, and if you use OpenAI Realtime alongside Cartesia AI in the same stack, OpenAI Realtime operates at 24 kHz, which requires resampling at that boundary too. The Teler documentation notes this explicitly for the OpenAI Realtime integration path.
Which integration pattern fits your Cartesia AI telephony use case?
Four patterns exist. Each places the media termination point differently, and that placement determines your operational burden.
| Pattern | Media terminates at | Latency cost | Operational burden | Lock-in |
|---|---|---|---|---|
| Raw WebSocket media streaming | Your application | Lowest, no extra hop | High: you own transport, resampling, buffering, call control | None |
| SIP trunk into a media server | Media server you operate | One extra hop plus RTP jitter buffering | High: you run SIP infrastructure and codec translation | Low |
| WebRTC gateway | Gateway you or a vendor operates | NAT traversal and transcoding add variance | Medium: gateway handles browser audio; you handle the AI bridge | Medium |
| Provider-native telephony bridge (Teler) | Teler’s edge network | Sub-100ms packet delivery target; no resampling needed when Cartesia is set to 8 kHz 16-bit PCM | Low: carrier, number provisioning, and WebSocket streaming handled by the provider | Medium |
If you want maximum control over the media path and already run your own infrastructure, the raw WebSocket pattern is the right choice. If you need phone number provisioning in 50 or more countries, inbound and outbound call control, and a managed WebSocket stream without building carrier connectivity yourself, the provider-native pattern with Teler is the faster path. The condition under which the opposite choice is right: if you already operate a SIP media server and your team has RTP expertise, the SIP trunk pattern avoids adding another vendor dependency. See the guide on why programmable SIP is the backbone of voice infrastructure for AI agents for a deeper look at the SIP side of this decision.
For teams evaluating the broader landscape of telephony API providers in the US, the key differentiator is whether the provider exposes raw media streams over WebSocket or only higher-level call control. Cartesia AI requires raw media access, so providers that abstract the audio away entirely are not compatible without significant middleware.
Frequently asked questions
Does Cartesia AI support SIP or PSTN calling natively?
No. Cartesia AI does not provide SIP trunking, PSTN access, or phone number provisioning. It exposes WebSocket endpoints for real-time TTS and STT. SIP, defined in RFC 3261, is a separate signaling protocol that a telephony layer must handle before audio reaches Cartesia.
What audio format does Cartesia AI’s STT endpoint require?
Cartesia’s realtime STT endpoint takes raw binary audio, with the format declared via the encoding and sample_rate query parameters. Encodings include pcm_s16le, pcm_s32le, pcm_f16le, pcm_f32le, pcm_mulaw, and pcm_alaw, so 8 kHz telephony audio, whether μ-law or 16-bit PCM, can be sent without resampling.
Why does the Cartesia AI WebSocket drop during long silences?
Cartesia disconnects idle WebSocket sessions after a period of inactivity. Two separate GitHub issues, one against Pipecat in September 2024 and one against LiveKit agents in May 2025, confirm this behaviour. The fix is a reconnect loop that resets its retry counter after each successful connection, not just after the initial handshake.
Should I use SIP trunking or a WebSocket media stream to connect Cartesia AI to a phone call?
Use a WebSocket media stream if you want the lowest latency and are building from scratch. Use SIP trunking if you already operate a media server with RTP expertise. The SIP path adds a codec translation hop but avoids a new vendor dependency. Teler supports both patterns: SIP trunking with credential or IP authentication, and direct WebSocket media streaming.
What happens when concurrent Cartesia AI WebSocket connections exceed the provider limit?
Cartesia returns 429 Too Many Requests when the concurrency ceiling is reached. A LiveKit agents issue from April 2025 shows this happening when dangling connections accumulate in a connection pool that lacks a client-side cap. Add explicit concurrency limits and connection cleanup to your pool before load testing.
What must I build myself when using Cartesia AI for phone calls?
You must supply: PSTN or SIP transport, phone number provisioning, G.711 to PCM decoding, sample rate conversion, a jitter buffer, call control (hangup, mute, transfer), DTMF handling, and call recording. Cartesia provides none of these. Teler covers the carrier, number provisioning, WebSocket streaming, and call control. Resampling is only needed if your Cartesia settings don’t match the call audio.
Does the Cartesia AI 2026 API version change anything for existing integrations?
Yes. API version 2026-08-14 requires Voice ID on TTS WebSocket, bytes, and SSE endpoints. Passing embeddings directly is no longer supported. The changelog also sunsets Sonic-2, Sonic-turbo, and Sonic-3-2025-10-27 after October 20, 2026. Audit your integration against both changes before that date.
How does Teler handle barge-in when Cartesia AI is speaking?
Teler supports barge-in through a {"type": "clear"} message that flushes queued audio playback immediately. When Cartesia’s STT detects that the caller has started speaking, your application sends the clear message to Teler, stops the TTS stream, and begins a new STT turn. The guide on media streaming challenges in telephony systems covers the timing constraints in more detail.
What Cartesia AI telephony integration looks like when it works
Cartesia AI is a strong real-time voice model layer, and the integration path to a live phone call is well-defined once you accept that the telephony transport is your problem to solve. The one decision that matters most is where media terminates: if you choose a provider that exposes raw WebSocket audio, the resampling and buffering work is contained and testable. If you choose a provider that abstracts the audio, you lose the control that Cartesia AI’s 1x realtime constraint demands. For teams building Cartesia AI into production phone agents in 2026, Teler’s programmable voice API handles the carrier layer, leaving your application to own the codec boundary and the session lifecycle. Visit the Teler product page to see the full WebSocket media streaming specification.