Grok Voice: superfici e protocolli
Una guida concettuale alle superfici vocali documentate da xAI e ai confini fra conversazione in tempo reale, integrazione e telefonia.
In breve
Sezione intitolata “In breve”In questa wiki, “Grok Voice” è una scorciatoia editoriale per le superfici vocali xAI; il nome canonico della capacità realtime è Speech to Speech API. La documentazione ufficiale descrive streaming bidirezionale di audio e testo tramite WebSocket; le pagine collegate coprono anche applicazioni multimediali e telefonia SIP. «Voce» non identifica quindi una singola funzione: identifica una catena in cui client, trasporto, sessione e canale umano hanno responsabilità differenti.
Due topologie, non una demo
Sezione intitolata “Due topologie, non una demo”microfono → client → WebSocket/WebRTC → sessione realtime → audio/testotelefono → rete SIP → chiamata realtime → agente → eventuale operatoreNel primo caso il client gestisce acquisizione audio, eventi, riproduzione e interruzioni. Nel secondo entrano anche routing telefonico, identità del chiamante, disclosure e trasferimento. Condividere il modello conversazionale non rende equivalenti le due topologie.
Contratto della sessione
Sezione intitolata “Contratto della sessione”Una sessione utile deve rendere osservabili almeno quattro eventi: apertura confermata, input accettato, risposta in corso e chiusura o errore. Lo streaming riduce il tempo prima del primo segnale, ma introduce stati intermedi: una risposta può essere interrotta, un input può arrivare mentre l’agente parla e una disconnessione può lasciare il client senza esito finale.
Per questo il turno di parola non va trattato come un dettaglio dell’interfaccia. Il prodotto deve decidere chi può interrompere, quando un input è considerato concluso e come recuperare da audio incompleto. La compatibilità documentata con la forma dell’API OpenAI Realtime facilita alcuni adattamenti, ma la matrice xAI degli eventi compatibili resta l’autorità sulle differenze: compatibilità non significa parità totale.
Scelta del trasporto
Sezione intitolata “Scelta del trasporto”| Superficie | Quando è adatta | Responsabilità che rimane al prodotto |
|---|---|---|
| WebSocket diretto | Backend o client controllato con eventi espliciti | autenticazione, reconnect, buffer e stato UI |
| WebRTC | Esperienza browser con media realtime | negoziazione, rete, permessi del microfono |
| SIP | Telefonia e infrastrutture esistenti | consenso, routing, handoff e conservazione dati |
La documentazione SIP prova che il collegamento telefonico è una superficie supportata; non dimostra che una specifica applicazione sia pronta alla produzione. Un prototipo che completa una chiamata non ha ancora dimostrato disclosure, fallback verso una persona o comportamento in caso di caduta.
Caso limite: risposta fluida, decisione sbagliata
Sezione intitolata “Caso limite: risposta fluida, decisione sbagliata”La voce naturale rende facile sovrastimare l’affidabilità. Se l’agente interpreta male un dato ma continua a parlare senza esitazione, la qualità percepita può nascondere l’errore. L’interfaccia deve quindi consentire di interrompere, chiedere conferma, correggere e passare a un canale alternativo. Nei domini sensibili, un limite esplicito vale più di una conversazione perfettamente fluida.
Claim che invecchiano
Sezione intitolata “Claim che invecchiano”Trasporti e primitive sono relativamente stabili; alias di modello, regioni, quote e condizioni commerciali no. Questi ultimi non vanno incorporati nella voce senza data e fonte corrente. La regola discende dalle invarianti di fiducia: una pagina enciclopedica descrive il contratto verificato, non lo stato privato di un account.
Questa voce non è una guida di implementazione né un’attestazione di disponibilità. Prima di distribuire un agente vocale servono test di latenza e interruzione, threat model del canale, requisiti legali del contesto e verifica corrente delle policy xAI.