WebRTC vs WebSocket per l'IA vocale in tempo reale

WebSocket e WebRTC tengono entrambi aperta una connessione, così l’audio scorre nei due sensi senza una nuova richiesta per ogni frammento. La differenza è ciò che succede quando la rete fa i capricci. Un WebSocket funziona su TCP, quindi ogni byte arriva in ordine, anche a costo di aspettare. WebRTC di solito funziona su UDP ed è pensato per i media, quindi scarta o maschera un pacchetto in ritardo e continua a riprodurre.

In un agente vocale, questa differenza decide dove va ciascuno. WebRTC serve per il tratto tra il dispositivo di una persona e i tuoi server, dove Wi-Fi e reti mobili perdono pacchetti. WebSocket serve per i tratti tra server, dove non li perdono, e per tutto ciò che richiede un flusso di messaggi semplice e ordinato. La maggior parte degli agenti vocali in produzione usa entrambi.

Questa guida è per gli ingegneri che scelgono il trasporto di un agente vocale o di una funzione vocale in tempo reale. Spiega come funziona ciascun protocollo, il confronto che conta per l’audio e le architetture che i team mettono davvero in produzione.

WebRTC vs WebSocket in sintesi

Come funziona un WebSocket

Un WebSocket inizia come una normale richiesta HTTP con un header Upgrade. Se il server accetta, la stessa connessione TCP resta aperta ed entrambi i lati possono inviare messaggi in qualsiasi momento. Il protocollo è definito nella RFC 6455, e ogni browser ha un’API WebSocket.

WebSocket non sa nulla di audio. Un messaggio è un frame di testo o binario, e l’applicazione decide che cosa contiene. Le API vocali di solito inviano eventi JSON con PCM codificato in base64, oppure frame binari grezzi. Il tuo codice acquisisce il microfono, codifica i frammenti, li invia e, dall’altra parte, mette in coda l’audio ricevuto per la riproduzione.

Il suo punto di forza è la semplicità. Un WebSocket passa attraverso la maggior parte dei proxy e dei load balancer, funziona da qualsiasi linguaggio ed è facile da debuggare: puoi leggere i messaggi. Il prezzo è la garanzia di consegna di TCP. Quando un pacchetto si perde, TCP lo ritrasmette, e nulla di ciò che lo segue raggiunge l’applicazione prima di allora. Per scaricare un file è esattamente la cosa giusta. Per la voce dal vivo, una ritrasmissione di 200 millisecondi significa 200 millisecondi di silenzio, seguiti da una raffica di audio che arriva tutta insieme.

Come funziona WebRTC

WebRTC è un insieme di standard (la panoramica è la RFC 8825) per inviare audio, video e dati tra peer in tempo reale. Il browser si occupa di quasi tutto il lavoro sui media:

• Codec. I browser devono supportare Opus e G.711 per l’audio (RFC 7874). Opus comprime bene la voce e adatta il bitrate alla rete.
• Trasporto. I media viaggiano su SRTP (RFC 3711), di solito su UDP, con chiavi negoziate tramite DTLS. La cifratura è obbligatoria.
• Jitter buffer e mascheramento delle perdite. Il ricevitore tiene qualche decina di millisecondi di audio per uniformare gli arrivi irregolari e riempie i piccoli vuoti invece di fermarsi.
• Attraversamento del NAT. ICE prova prima i percorsi diretti, usa STUN per scoprire gli indirizzi pubblici e ripiega su un relay TURN quando nient’altro passa.
• Cancellazione dell’eco e soppressione del rumore. I browser le applicano per impostazione predefinita alle chiamate WebRTC.

Ciò che WebRTC non definisce è il signaling: il modo in cui due peer si scambiano la descrizione della sessione e i candidati di rete prima che i media possano scorrere. Questa parte la costruisci tu, e molto spesso è un WebSocket. Per questo “WebRTC vs WebSocket” è un confronto un po’ strano. Molte app WebRTC contengono un WebSocket.

L’altro ostacolo è il lato server. WebRTC è stato progettato per chiamate da browser a browser. Quando l’altro “peer” è il tuo agente vocale, ti serve un server che parli WebRTC: un media server (una SFU) come LiveKit, o una piattaforma ospitata come Daily. Gestire i propri server TURN e media server è un vero lavoro di infrastruttura.

Quale conta per l’IA vocale

Un agente vocale ha almeno tre tratti di rete, e non serve lo stesso trasporto per tutti.

Dal dispositivo dell’utente ai tuoi server. È il tratto che passa per il Wi-Fi di casa, le reti aziendali e i telefoni sul treno. Qui la perdita di pacchetti e il jitter sono normali. WebRTC è nato per questo tratto: l’audio continua a scorrere anche se si perde un pacchetto, Opus abbassa il bitrate quando la banda cala e il browser rimuove la voce dell’agente dal microfono dell’utente. Se i tuoi utenti parlano con un agente da un browser o da un’app mobile, è qui che WebRTC ripaga il costo della configurazione.

Dai tuoi server ai modelli vocali. Il tuo agente invia audio a un modello di speech to text e testo a un modello di text to speech. Queste connessioni corrono tra data center, dove la perdita di pacchetti è rara, quindi la consegna ordinata di TCP non costa quasi nulla. In più ti serve ciò che offre WebSocket: eventi di testo e di controllo ordinati accanto all’audio, contesti di richiesta e un’autenticazione semplice. Per questo le API vocali, compresa quella di Cartesia, trasmettono su WebSocket.

Telefonate. Chi chiama da una linea telefonica ti raggiunge tramite la rete telefonica, poi SIP e RTP, o il flusso media di un provider. Twilio Media Streams, per esempio, inoltra l’audio della chiamata al tuo server su un WebSocket in μ-law a 8 kHz. Né WebRTC né WebSocket sono dal lato di chi chiama. Se stai scegliendo il trasporto per agenti telefonici, leggi piuttosto la guida sul trunk SIP.

Quindi la domanda utile è dove si trova la rete inaffidabile. Metti WebRTC su quel tratto e usa WebSocket ovunque altrove.

Quando basta un WebSocket sul client

WebRTC non è necessario per ogni funzione vocale nel browser. Un WebSocket diretto dal client è una scelta ragionevole quando:

• La rete è prevedibile. Strumenti interni, chioschi, app desktop su reti aziendali e demo.
• Stai prototipando. Una connessione, nessun media server, nessun TURN, e puoi registrare ogni evento.
• L’audio non è conversazionale. Text to speech in streaming per la lettura ad alta voce, o dettatura in cui un breve blocco non rompe una conversazione.
• Il client è un server. Un backend o una funzione edge che inoltra audio da un’altra parte.

Se scegli questa strada, invia frammenti audio piccoli, tieni un buffer di riproduzione corto e ferma la riproduzione appena l’utente interrompe. Prova su una rete con perdite prima del rilascio. Gli strumenti per sviluppatori del browser possono limitare banda e latenza ma non scartare pacchetti, quindi usa un network conditioner a livello di sistema operativo o un hotspot dal telefono.

Architetture che funzionano

Front end WebRTC, back end WebSocket. La configurazione di produzione più comune. Il browser o l’app dell’utente entra in una stanza WebRTC su LiveKit o Daily. Il tuo agente gira su un server, entra nella stessa stanza e trasmette ai modelli vocali su WebSocket. LiveKit Agents e Pipecat funzionano così, ed entrambi i loro plugin Cartesia aprono un WebSocket verso Cartesia dal server. LiveKit e Daily, l’azienda dietro Pipecat, sono entrambi clienti Cartesia. Il CEO di Daily, Kwindla Hultman, l’ha detto così: “Cartesia Sonic is the best voice model today for real-time multimodal use cases.”

WebSocket da un capo all’altro. Il browser invia l’audio al tuo server su un WebSocket, e anche il tuo server parla con i modelli vocali su WebSocket. È lo stack più semplice e funziona bene per prototipi e reti controllate. Anche i Cartesia Managed Agents accettano una connessione WebSocket diretta, quindi un server fidato o un browser con un token di accesso di breve durata può parlare con un agente ospitato senza eseguire codice dell’agente.

Telefono in ingresso, WebSocket all’interno. Per gli agenti telefonici, la chiamata arriva via SIP o tramite un provider di telefonia, e le connessioni dell’agente ai modelli vocali restano su WebSocket. I Managed Agents gestiscono per te il lato telefonico, con numeri Cartesia, Twilio o il tuo trunk SIP.

Trasmettere audio a Cartesia su WebSocket

Le API in tempo reale di Cartesia trasmettono su WebSocket:

• Text to speech: wss://api.cartesia.ai/tts/websocket riceve il testo man mano che arriva dal tuo LLM e restituisce frammenti audio. Una connessione può portare più contesti, e le continuazioni permettono a Sonic di pronunciare una frase prima che l’LLM finisca la risposta.
• Speech to text: Ink-2 trascrive un flusso di PCM grezzo su WebSocket e gestisce nativamente il rilevamento del turno.
• Managed Agents: wss://api.cartesia.ai/v1/agents/websocket/{agent_id} collega un’applicazione a un agente ospitato. Invii eventi audio_input con audio in base64 a frammenti di 20-100 millisecondi e riproduci gli eventi audio_output. Quando l’utente inizia a parlare sopra l’agente, Cartesia invia audio_output_clear e il tuo client ferma la riproduzione.

Il WebSocket dell’agente accetta audio mono senza header in pcm_16000, pcm_24000, pcm_44100 o mulaw_8000, e restituisce audio nello stesso formato:

{
	"type": "session_create",
	"audio": {
		"input_format": "pcm_16000",
		"output_delivery": "speaking_pace"
	}
}

Da un browser, non mettere mai una chiave API nel codice client. I browser non possono impostare header WebSocket, quindi il tuo server genera un token di accesso di breve durata e il client lo passa come parametro di query. La guida all’API WebSocket contiene un esempio di sessione completo.

Per provarlo, crea un agente nel playground di Cartesia, oppure ottieni una chiave API e trasmetti il tuo primo audio con la guida rapida al text to speech.

Guide correlate

• Crea un agente vocale con Pipecat e Cartesia
• Cos’è un trunk SIP e come usarlo con l’IA vocale
• Rilevamento dell’attività vocale: VAD per agenti vocali
• Agente vocale IA: cos’è e come crearne uno
• Sintesi vocale in JavaScript con SpeechSynthesis