AI Summary: This article covers how to wire an n8n voice agent to a live phone call, written for backend and API integration engineers who need to understand the architectural boundary between workflow orchestration and real-time telephony. A critical constraint: n8n does not carry raw audio itself, so the media path must live in a dedicated telephony layer such as Teler, which streams 8 kHz or 16 kHz PCM over WebSocket. The reader must decide which layer owns call state and where barge-in handling lives. Teler handles carrier connectivity, audio streaming, and call control so n8n can focus on business logic triggered by webhook events.
Scope: This walkthrough covers connecting an n8n workflow to a live PSTN call via webhook-driven orchestration and Teler’s WebSocket media transport, verified against n8n 2.39.6 and Teler’s API as documented in September 2026. It does not cover SIP trunk configuration or n8n’s internal node credential setup beyond what is necessary to understand the integration boundary.
Quick Answer: An n8n voice agent works by pairing n8n’s webhook trigger with a telephony layer that owns the live audio path. In 2026, the practical pattern is: Teler terminates the call, streams 8 kHz PCM over WebSocket to your server, your server runs STT and LLM logic, and n8n handles the business workflow triggered by call events via HTTP webhooks.
Building an n8n voice agent means accepting one architectural fact early: n8n orchestrates workflow logic over HTTP, but a real phone call requires a persistent, stateful media connection that n8n was not designed to carry. The two layers must be composed deliberately.
What is n8n, and where does it stop?
n8n is a fair-code workflow automation platform that connects APIs, services, and business logic through a visual canvas backed by custom code, running either self-hosted or in the cloud. It occupies the orchestration layer: it receives events, routes data between nodes, calls external APIs, and triggers downstream actions. What it does not do is maintain a persistent audio session, carry raw PCM or Opus frames, or handle the sub-second turn-taking that a live voice call requires. The n8n docs confirm that audio operations are exposed at the node level through integrations such as the OpenAI node, which supports MP3, OPUS, AAC, FLAC, WAV, and PCM output formats with a 4,096-character text input limit. A developer building a phone-call agent must supply the transport layer, the carrier connectivity, the resampling path, and the call control logic themselves. n8n handles what happens after a call event arrives.
Why is wiring a workflow to a phone call hard?
The core problem is that HTTP and telephony operate on incompatible time scales. An HTTP round trip through n8n takes hundreds of milliseconds at minimum, while a natural voice conversation tolerates roughly 200 to 300 milliseconds of end-to-end latency before it starts to feel broken. Every extra hop, record, transcribe, call n8n, call LLM, synthesize, play, adds delay that compounds into a turn-based interaction rather than a live conversation.
Beyond latency, there is a format mismatch. PSTN carriers deliver audio as G.711 mu-law or a-law at 8 kHz, a narrowband codec defined in ITU-T G.711. Most LLM and TTS providers expect wideband audio at 16 kHz or higher. The resampling step between those two formats must happen in real time, inside the media path, not inside a workflow node. There is also the barge-in problem: if a caller speaks while the agent is playing audio, the system must detect that speech, flush queued playback, and restart the turn. That requires a stateful connection, not a stateless webhook.
What does the full audio path look like for an n8n voice agent?
The path from carrier to model and back has six distinct hops, each with its own owner, format, and latency contribution. Understanding which layer owns each hop is the prerequisite for debugging any production failure.
| Hop | Owner | Format | Transport | Latency concern |
|---|---|---|---|---|
| PSTN to telephony provider | Carrier / Teler | G.711 8 kHz | SIP / RTP | Network jitter, packet loss |
| Telephony provider to your server | Teler WebSocket | PCM 8 kHz or 16 kHz | WebSocket | Chunk size, buffering |
| Your server to STT | Developer | PCM or Opus | HTTP or WebSocket | Transcription latency |
| STT to LLM | Developer | Text | HTTP | Model inference time |
| LLM to n8n | Developer webhook | JSON | HTTP POST | n8n execution time |
| TTS audio back to caller | Teler WebSocket | 16-bit PCM, 8 kHz | WebSocket | Synthesis latency, resampling |
SIP (Session Initiation Protocol, defined in RFC 3261) handles call setup and teardown. RTP (Real-time Transport Protocol, defined in RFC 3550) carries the packetized audio. Teler abstracts both and exposes the audio as a WebSocket stream, which is where your application code connects. n8n sits at hop five: it receives a JSON webhook from your server and returns business logic results over HTTP. It never touches the audio frames directly.
Prerequisites for building an n8n voice agent
- A Teler account with a provisioned phone number (DID) in E.164 format and an API key from platform.frejun.ai
- An n8n instance, version 2.x or later, either self-hosted via Docker or on n8n Cloud, with a publicly reachable webhook URL
- A server process (Node.js 20+ or Python 3.11+) that can hold a WebSocket connection open for the duration of a call
- A streaming STT provider credential, such as Deepgram, that accepts 8 kHz input
- An LLM API key, GPT-4o or Claude Sonnet 4 are common choices
- A TTS provider that can return raw 16-bit PCM at 8 kHz (or a resampler), since audio sent back to Teler must be 8 kHz with no WAV header
- Network reachability: your WebSocket server must be reachable from Teler’s edge nodes, and your n8n webhook URL must be reachable from your server
How to implement an n8n voice agent step by step
Step 1: Configure the Teler inbound call webhook
When a call arrives at your Teler number, Teler fires a webhook to your server with call metadata. Configure this in the Teler dashboard or via the API. Your server responds with instructions that include the WebSocket URL Teler should connect to for media streaming. The call control webhook and the media WebSocket are separate connections: one is HTTP, one is persistent.
from teler import CallFlow
flow = CallFlow.stream(
ws_url="wss://your-server.example.com/media",
sample_rate="8k",
chunk_size=20,
)chunk_size is in milliseconds and must be a multiple of 20. The default is 400 ms, which delays every inbound chunk by that much, so use a small value for live conversation.
Step 2: Open the WebSocket and receive audio chunks
Your server accepts the WebSocket connection from Teler and begins receiving audio frames. Each frame is a JSON envelope containing a base64-encoded PCM chunk. Decode it and forward it to a streaming STT connection as it arrives. The WebSocket protocol is defined in RFC 6455.
import asyncio
import websockets
import json
import base64
async def handle_call(websocket):
stt_queue = asyncio.Queue()
# run_streaming_stt forwards chunks to your STT provider and calls
# handle_turn(websocket, transcript) when the provider signals end of turn
stt_task = asyncio.create_task(run_streaming_stt(stt_queue, websocket))
try:
async for message in websocket:
event = json.loads(message)
if event["type"] == "audio":
await stt_queue.put(base64.b64decode(event["data"]["audio_b64"]))
finally:
# No end message: Teler closes the socket when the call ends
await stt_queue.put(None)
await stt_taskLet the streaming STT provider decide when the caller has finished speaking. Transcribing fixed 500 ms slices cuts words in half and gives you no reliable end of turn.
Step 3: Call n8n via webhook for business logic
Once you have a transcript and an LLM response, your server posts to an n8n webhook node to trigger business logic: CRM lookups, calendar checks, database writes, or escalation routing. The n8n webhook node must be configured to use the “Respond to Webhook” node at the end of the workflow, not the default immediate response, so that n8n returns its result only after processing completes.
import httpx
async def call_n8n_workflow(transcript: str, call_id: str) -> dict:
payload = {
"callId": call_id,
"transcript": transcript,
"timestamp": "2026-09-17T00:00:00Z"
}
async with httpx.AsyncClient(timeout=5.0) as client:
response = await client.post(
"https://your-n8n-instance.example.com/webhook/voice-agent",
json=payload
)
response.raise_for_status()
return response.json()Set the HTTP timeout to match your acceptable turn latency. A 5-second timeout is a reasonable starting point, but any n8n execution that approaches that limit will make the conversation feel stalled.
Step 4: Synthesize audio and inject it back into the call
Take the text response from n8n, pass it to your TTS provider, and send the resulting PCM audio back over the Teler WebSocket. If the caller speaks while audio is playing, send a {"type": "clear"} message to flush Teler’s queued playback before injecting the new audio. This is the barge-in mechanism.
async def play_audio(websocket, pcm_bytes: bytes):
# pcm_bytes must be 16-bit PCM at 8 kHz
chunk_size = 3200 # 200 ms of 16-bit PCM at 8 kHz
for i in range(0, len(pcm_bytes), chunk_size):
await websocket.send(json.dumps({
"type": "audio",
"audio_b64": base64.b64encode(pcm_bytes[i:i + chunk_size]).decode(),
"chunk_id": uuid.uuid4().hex, # required, unique per stream
}))
async def on_barge_in(websocket):
# Call only when VAD detects the caller speaking during playback
await websocket.send(json.dumps({"type": "clear"}))If your TTS outputs 24 kHz audio, as OpenAI’s TTS does for PCM, resample to 8 kHz before sending it to Teler. Audio sent back must be 8 kHz regardless of the inbound sample rate. The resampling step belongs in your server process, not in n8n. See the Teler streaming documentation for the full message schema.
Step 5: Handle call-end events and post-call workflow
When the call ends, Teler closes the media WebSocket and sends a stream.completed webhook. Your server can use either signal to trigger a separate n8n workflow for post-call processing: transcript storage, CRM updates, or follow-up task creation. This is where n8n’s strength as an orchestration layer is most natural. The call is over, latency no longer matters, and n8n can take as long as it needs. The community reference implementation at Shay-Sh/n8n_voice_agent (last updated April 2026) demonstrates this pattern with ElevenLabs and Twilio as the telephony layer.
Most teams discover their latency problem is not the model inference time. It is the resampling hop they added between the carrier audio and the STT engine, combined with an n8n execution that blocks the response path. Keep the media loop tight and let n8n handle only what happens after the turn completes.
– Subhash Kalluri, Founder & CEO, FreJun
What breaks in production n8n voice agent deployments?
| Symptom | Root cause | Fix |
|---|---|---|
| Callers wait several seconds between turns | Full record-transcribe-LLM-TTS-play loop runs synchronously through n8n | Move STT and TTS into the media bridge; use n8n only for business logic after the turn |
| Interruption does not stop queued audio | n8n sees discrete call events, not streaming turn state, so barge-in has no hook | Handle barge-in in the telephony layer with {"type": "clear"}; let n8n react to start and end events only |
| Twilio or Teler cannot play the synthesized audio | Audio is stored as binary inside the workflow and is not publicly reachable | Host the audio on S3 or another public endpoint before returning the play instruction |
| Call flow stalls waiting for n8n to respond | Webhook node returns immediately before processing completes | Use the “Respond to Webhook” node at the end of the workflow, not the default trigger response |
The failure that catches most teams is the synchronous latency loop. When n8n sits in the critical path between the caller’s utterance and the agent’s reply, every node execution adds wall-clock time. A workflow that takes 800 ms to complete means the caller waits at least 800 ms on top of STT and TTS latency. One honest limitation of Teler’s approach: because Teler targets sub-100ms packet delivery as a specification rather than a guaranteed SLA, actual end-to-end latency still depends on your STT provider, your LLM, and your server’s geographic proximity to Teler’s edge nodes. The transport layer is not the only variable.
Which architecture should you choose for an n8n voice agent?
| Approach | Media owner | Latency cost | Operational burden | Lock-in |
|---|---|---|---|---|
| Teler WebSocket bridge + n8n webhooks | Teler | Low if n8n is off the media path | Medium: manage WebSocket server | Low: model-agnostic |
| Provider-native bridge (Vapi, ElevenLabs) | Provider | Low | Low: provider manages media | High: provider controls audio path |
| SIP trunk into Asterisk or FreeSWITCH | Your media server | Low if tuned | High: operate PBX and media server | Low: full control |
| Recording-first batch workflow | Recording storage | Very high: no real-time interaction | Low | Low |
| WebRTC gateway | Gateway | Low for web clients | Medium: operate signaling server | Medium |
The Teler WebSocket bridge with n8n webhooks is the right choice when you want model flexibility, you already have n8n running for other automation, and you are willing to operate a small WebSocket server process. Use a provider-native bridge instead when speed to production matters more than portability, and you are comfortable with the provider owning your audio path. Use the recording-first approach only when real-time interaction is not a requirement, such as post-call summarization or compliance monitoring. For teams evaluating voice API options more broadly, the Top 7 Best Voice APIs for n8n in the US covers the provider landscape in detail.
Frequently asked questions
Can n8n handle the live audio stream directly without a separate WebSocket server?
No. n8n processes events over HTTP and does not maintain persistent WebSocket connections for raw audio. The live media path must live in a separate process, such as a Node.js or Python WebSocket server, that connects to Teler’s streaming endpoint. n8n receives call events as HTTP webhooks from that server, not from the telephony provider directly.
What audio format does Teler stream, and does it match what STT providers expect?
Teler streams 16-bit linear PCM at 8 kHz or 16 kHz, set with the sample_rate parameter of the stream flow (the start message currently reports 8000 either way). Most STT providers accept both. Audio you send back must be 8 kHz, so resample any 24 kHz TTS output before sending it. The resampling step belongs in your server, not in n8n.
Why does the n8n webhook node need a “Respond to Webhook” step?
By default, n8n’s webhook node returns an immediate HTTP 200 before the workflow finishes executing. If your server waits for n8n’s response before playing audio to the caller, that default behaviour means you get an empty response before the business logic runs. The “Respond to Webhook” node delays the HTTP response until the workflow completes, so your server receives the actual result it needs to construct the agent’s reply.
What happens to the call if n8n is slow or unavailable?
If n8n times out or returns an error, your server must handle the failure gracefully: play a fallback audio message to the caller, log the failure, and optionally retry. Because n8n sits off the media path in this architecture, a slow workflow delays the agent’s reply but does not drop the call. Set a conservative HTTP timeout on the n8n webhook call, around 3 to 5 seconds, and build a fallback response path for when that threshold is exceeded.
Should I use SIP trunking or WebSocket streaming for this integration?
WebSocket streaming is the right choice for most n8n voice agent builds because it gives your application code direct access to audio frames without operating a SIP stack. SIP trunking, defined in RFC 3261, is the right choice when you need to connect to an existing PBX or when your carrier requires SIP authentication. Teler supports both: SIP trunking with credential or IP-based authentication, and WebSocket media streaming. For teams evaluating SIP options, the Top 9 Best SIP Trunking Providers in the US covers the provider landscape.
How does barge-in work, and does n8n need to know about it?
Barge-in, where a caller speaks while the agent is playing audio, is handled entirely in the media layer. Your WebSocket server detects incoming audio while playback is active, sends {"type": "clear"} to Teler to flush queued audio, and begins a new turn. n8n does not need to know about barge-in events unless your business logic requires tracking interruption counts or adjusting conversation state. Keep barge-in handling in the server process, not in the workflow.
What must I build myself that Teler does not provide?
Teler provides carrier connectivity, WebSocket audio streaming, call control, and phone number provisioning. You must build the WebSocket server that bridges Teler’s audio to your STT provider, the STT-to-LLM pipeline, the LLM-to-n8n webhook call, the TTS synthesis step, and the resampling logic if your TTS output sample rate differs from your configured stream rate. The Teler developer documentation covers the WebSocket message schema and call control API in detail.
Can I use n8n’s AI agent node instead of a separate LLM call?
Yes, but with a latency trade-off. n8n’s AI agent node can call an LLM and use tools within the workflow, which simplifies the architecture. The cost is that the entire LLM inference round trip runs inside the n8n execution, adding to the time your server waits before it can play audio. For low-latency voice interactions, running the LLM call in your server process and using n8n only for tool execution or post-turn logic is the more practical split.
Building a production n8n voice agent in 2026
An n8n voice agent is a viable production architecture when you treat n8n as the orchestration layer it was built to be, not as a real-time media transport. The decision that matters most is where you draw the boundary: keep the audio path in a dedicated telephony layer like Teler, and let n8n handle the business logic that runs after each turn or after the call ends. If your use case requires sub-200ms turn latency, move the LLM call into your server process and use n8n only for tool calls and post-call workflows.
For teams building more complex voice pipelines, the Top 9 Best Voice API Providers for AI Agents in India and the Top 5 Best AI Voice Agent Platforms in the US provide broader provider comparisons. The architecture described here gives you model flexibility, carrier-grade telephony, and the full power of n8n’s integration ecosystem without forcing any of those layers to do work they were not designed for.
