GPT-Live-1 ora può effettuare chiamate in uscita: cosa sblocca davvero il GA di SIP e cosa ancora non può fare

La novità più utile che un agente vocale di OpenAI può fare è premere 1. Dalla tarda serata del 4 novembre 2026, una sessione GPT-Live-1 può effettuare una chiamata in uscita verso un vero numero di telefono tramite un trunk SIP, ascoltare il menu che risponde e inviare toni di tastiera lungo la linea. Quest'ultima parte — il DTMF bidirezionale — è la differenza tra un agente vocale che parla e un agente vocale che riesce ad attraversare un albero telefonico fino al reparto di cui ha effettivamente bisogno.

Il modello in sé non è nuovo. GPT-Live-1 è disponibile in ChatGPT Voice dall'8 luglio 2026 e nell'API dal 10 settembre 2026 a 0,05 $ al minuto. Ciò che è cambiato il 4 novembre è il trasporto. Justin Uberti di OpenAI ha annunciato che l'API di telefonia in uscita era stata "appena promossa … a GA", "consentendo agli sviluppatori di effettuare chiamate telefoniche dal proprio agente vocale Live" tramite "qualsiasi provider di trunk SIP (ad es. Telnyx o Twilio)"; Greg Brockman l'ha rilanciato la stessa notte. L'annuncio aggiunge che le chiamate possono usare HD Voice e possono inviare e ricevere eventi del tastierino.

Quindi questa è una storia di capacità, non una storia di modello, e il materiale interessante si trova nella documentazione plutôt che nel post. La guida Telephony and SIP di OpenAI ora afferma che le chiamate in uscita sono «disponibili a tutte le organizzazioni tramite Live API, non tramite l'endpoint di creazione chiamate della Realtime API» — due frasi che escludono silenziosamente una larga fetta delle integrazioni che le persone cercheranno di riutilizzare.

Cosa ha cambiato "GA", e cosa no

Prima della promozione, le chiamate in uscita esistevano ma non erano generalmente disponibili — è questo che significa "promosso". Il meccanismo era già stato costruito, e la porta si è aperta. La documentazione di OpenAI ora riporta la frase corrispondente, ovvero che le chiamate SIP in uscita "sono disponibili per tutte le organizzazioni tramite la Live API", che è la cosa più vicina a una dichiarazione di GA presente nella pagina: la guida stessa non riporta da nessuna parte un'etichetta beta, preview o alpha.

Ciò che non è cambiato è il modello vocale. L'esempio per le chiamate in uscita nella documentazione di OpenAI stessa imposta ancora model: "gpt-live-1", e la checklist per i partner continua a indicare agli integratori di cercare «una versione del pacchetto che supporti gpt-live-1». Non esiste un modello specifico per le chiamate in uscita, né un prezzo separato, né un livello per la telefonia. Stai pagando gli stessi $0,05 al minuto per il livello vocale che pagavi a settembre; ora ti è semplicemente consentito spenderlo per chiamate che lasciano il tuo server.

Un'avvertenza operativa si nasconde nella guida anziché nell'annuncio: OpenAI ti dice di verificare che «il supporto SIP di GPT-Live sia abilitato per il tuo progetto e che il trunk SIP del tuo provider sia instradato verso quel progetto prima di usare questo flusso». Un'etichetta GA e un'impostazione di progetto abilitata non sono la stessa cosa, e il primo ticket di assistenza della settimana sarà di qualcuno che ha l'una senza l'altra.

I prerequisiti che determinano se il tuo trunk funziona affatto

OpenAI non ha adottato SIP in senso generale. Ne ha adottato una porzione ristretta e moderna, e un trunk che non soddisfa uno qualsiasi dei seguenti requisiti non si connetterà, indipendentemente da ciò che l'annuncio aveva promesso riguardo a "qualsiasi provider di trunk SIP".

• Segnalazione — TLS è obbligatorio, non opzionale. SIP in chiaro su UDP o TCP non è ammesso.

• Media — SDES-SRTP è obbligatorio, e SRTP deve essere attivato presso il provider, non solo supportato da quest'ultimo.

• URL del provider — è previsto un endpoint sips:, con porta predefinita 5061, senza credenziali, senza percorso e senza parametri URI.

• Destinazione — un numero E.164 come +14155550123 e nient'altro. Gli URI SIP non sono esplicitamente supportati, quindi uno schema di interni non è una scorciatoia.

• Autenticazione — digest, con nome utente e password SIP, più un caller_number in E.164 che diventa l'ID chiamante che il chiamato vede.

• Igiene della rete — i nomi host locali e gli indirizzi IP privati letterali vengono rifiutati, il che esclude un banco di prova puntato a una macchina di laboratorio.

• Formato audio — lascia audio.format non impostato, perché è SIP a negoziarlo. Impostarlo è quel tipo di parametro che sembra utile ma fa saltare la chiamata.

Nota cosa significa questo per l'affermazione "qualsiasi provider". Qualsiasi provider che utilizzi segnalazione TLS con media SDES-SRTP funzionerà; moltissimi trunk SIP economici usano ancora UDP e RTP in chiaro per impostazione predefinita, e non sono coperti da quella frase. Il collegamento è una creazione di sessione anziché un webhook: si invia una POST a /v1/live/sessions con transport.type impostato su sip, e la guida è esplicita nel dire che "non serve un webhook per le chiamate in entrata né una richiesta di accettazione per una chiamata in uscita".

Quello che ricevi indietro è un session.id e un tipo di trasporto, e la documentazione è insolitamente schietta riguardo al divario tra questo e la realtà: "Questa risposta non significa che la chiamata abbia ricevuto risposta." Squillo, risposta e fallimento arrivano più tardi come eventi transport.ringing, transport.answered e transport.failed su un WebSocket sideband a /v1/live/sessions/{session_id}/attach. Collegati immediatamente — vengono riprodotti solo i tre secondi precedenti di eventi — e deduplica per event_id, perché la guida avverte che le consegne duplicate sono normali.

La busta: tre minuti per squillare, due ore per parlare

Due numeri concreti nella guida decideranno quali casi d'uso outbound siano praticabili, e nessuno dei due è comparso nell'annuncio.

• Limite massimo di squillo — tre minuti. Una chiamata che non è stata risposta entro quel momento è conclusa.

• Limite di connessione: due ore, trascorse le quali la sessione termina indipendentemente da ciò che sta accadendo.

• Superficie di controllo — trasferimento tramite /v1/live/sessions/{id}/refer, riagganciare tramite /v1/live/sessions/{id}/hangup, DTMF inviato sulla banda laterale con transport.dtmf.send.

• Modalità di errore — una configurazione di sessione non valida fallisce in modo esplicito alla creazione, la configurazione del trasporto può restituire 502, un timeout di inizializzazione restituisce 504 e qualsiasi evento successivo arriva in modo asincrono come transport.failed.

Lo squillo di tre minuti va bene per l'outbound consumer ed è scomodo per i centralini aziendali che mettono le chiamate in parcheggio. Il tetto di due ore è generoso finché non indirizzi l'agente verso una coda di supporto, dove un'attesa lunga più una conversazione lunga possono plausibilmente sfiorarlo. Nessuno dei due limiti è una sorpresa in un prodotto vocale in tempo reale; entrambi sono il genere di cose che vuoi sapere prima di promettere a un cliente un SLA di campagna.

Quanto costa una chiamata, onestamente

La pagina dei prezzi di OpenAI indica le sessioni vocali GPT-Live-1 a 0,05 $ al minuto, «fatturate al secondo, senza arrotondamento al minuto intero». Questo è l'intero prezzo pubblicato, ed è solo una delle due voci di addebito generate da una chiamata in uscita. Il costo di terminazione dell'operatore è l'altra, e dipende dalla destinazione, dal volume e dal fornitore di trunk scelto. OpenAI mantiene l'elaborazione audio e la logica di sessione; il fornitore è proprietario della tratta PSTN.

• Una chiamata con risposta di un minuto — $0,050 da OpenAI, più la tariffa al minuto del tuo operatore.

Una chiamata di quattro minuti — $0,200 da OpenAI, più costi dell'operatore.

• Mille chiamate da quattro minuti — 4.000 minuti, quindi 200 $ da OpenAI, più l'operatore.

• Un'ora di conversazione connessa — 3,00 $ da OpenAI, più le tariffe del gestore telefonico.

Due cose di quel contatore meritano attenzione. In primo luogo, l'unità di fatturazione è il minuto di sessione, e nulla nella pagina dei prezzi distingue il parlato dal silenzio, perciò i secondi che il tuo agente trascorre in ascolto della musica d'attesa maturano allo stesso ritmo dei secondi che trascorre parlando. In secondo luogo, la guida non specifica se una chiamata che squilla per tre minuti e non riceve mai risposta costituisca una sessione fatturabile; è una domanda da porre all'assistenza prima di avviare un dialer su larga scala, non dopo.

Il modello backend e l'utilizzo degli strumenti vengono fatturati separatamente, in base al modello a cui hai delegato. Se instradi quel segmento tramite OrcaRouter, il markup dello 0% e prezzi pass-through si applicano lì anziché al minuto vocale — quindi una riduzione di prezzo del provider sul modello di ragionamento compare sulla tua fattura lo stesso giorno, mentre una riduzione su gpt-live-1 no.

La tua integrazione Realtime non verrà trasferita.

L'errore singolo più costoso possibile questa settimana è presumere che uno stack di telefonia Realtime API funzionante sia uno stack GPT-Live funzionante. La pagina per i partner di OpenAI lo dice chiaramente: "Un'integrazione Realtime non è automaticamente compatibile con GPT-Live." L'endpoint è diverso, il modello di sessione è diverso, la delega è un concetto che Realtime non ha nella stessa forma, e i formati audio e le semantiche di interruzione che la guida ti chiede di verificare per ciascun partner non vengono trasferiti.

Anche la lista dei partner complica la formulazione dell'annuncio. OpenAI documenta LiveKit per gli agenti vocali; Twilio Agent Connect per "chiamate telefoniche in entrata e in uscita"; Telnyx per "esperienze di chiamata in uscita"; Bandwidth per "chiamate in entrata" su SIP; e Daily/Pipecat per il servizio Live in generale. In altre parole, Bandwidth è documentato come integrazione in entrata, mentre LiveKit e Pipecat sono documentati senza alcuna direzione di chiamata. "Qualsiasi provider di trunk SIP" è un'affermazione sulla compatibilità di protocollo, non un'affermazione su quale dei cinque partner di OpenAI abbia implementato il supporto in uscita.

Se sei su Twilio, la migrazione è quella che oggi dispone di un percorso outbound documentato. Se sei su Bandwidth per l'inbound, l'outbound tramite quell'integrazione non è ancora qualcosa che la documentazione promette.

La questione della versione che nessuno ha sollevato

C'è un'ambiguità irrisolta nel nome. GPT-Live-1.1 è stato integrato in ChatGPT Voice il 15 ottobre 2026 con nuove voci in sei lingue, e OpenAI non ha ancora pubblicato un ID del modello gpt-live-1.1 per i chiamanti API. Ogni esempio di chiamata in uscita nella guida alla telefonia usa gpt-live-1. Se un collega ti dice che l'agente in uscita sta eseguendo la 1.1 perché è quella che usa ChatGPT, sta descrivendo il prodotto consumer, non la configurazione della tua sessione.

In pratica: cita gpt-live-1 nel tuo piano, e considera qualsiasi disponibilità dell'API 1.1 come un evento separato da verificare nel giorno stesso.

Dove avviene il pensiero, e perché è la leva che controlli

GPT-Live è diviso esattamente a metà. La sintesi della documentazione stessa è che "delega il ragionamento e l'uso degli strumenti a un backend mentre gestisce la conversazione parlata". Il livello vocale gestisce i tempi, le interruzioni e la prosodia; un modello separato si occupa del ragionamento e chiama gli strumenti. Quel backend viene configurato per sessione nell'ambito della delega, in una delle due modalità.

• Delegazione Responses — delegation.type: "responses" con un backend obbligatorio modello, oltre a istruzioni, strumenti, scelta degli strumenti, limiti di token e livello di servizio. La guida di OpenAI consiglia di iniziare con gpt-6-luna, oppure gpt-6-sol per lavori più complessi, e osserva che "puoi scegliere il modello Responses indipendentemente dal modello vocale."

• Delegazione al client — delegation.type: "client", in cui la tua applicazione esegue essa stessa il backend. Secondo la formulazione di OpenAI, ciò consente "qualsiasi modello, agente o servizio gestito dalla tua applicazione".

Qui risiedono davvero il costo e la qualità di un agente outbound, ed è l'unica scelta architetturale della pagina che sia genuinamente tua. Il modello vocale è fisso e, per inciso, non è nel catalogo di OrcaRouter: GPT-Live-1 è un front end telefonico che acquisti da OpenAI, e nessuna astuzia nel routing può cambiarlo. Il backend è un'altra questione. Con la delega lato client è una normale chiamata al modello effettuata dal tuo codice, il che significa un'unica API per oltre 200 modelli, una sola chiave per tutti i fornitori che valuti, failover automatico se un provider peggiora a metà campagna, e scelta del modello per tipo di chiamata: un modello economico per navigare un menu IVR, uno più potente quando risponde una persona.

Con la delega Responses, OpenAI gestisce quel segmento e lo fattura alle proprie tariffe. Entrambe sono legittime; semplicemente collocano la decisione in punti diversi. Se vuoi che il backend sia una decisione di routing, la delega client è la modalità che te lo consente.

Cosa ha omesso l'annuncio

Per un post GA, l'annuncio è scarno su ciò che determina i deployment. Non dice nulla su disponibilità regionale, latenza, limiti di concorrenza o SLA. Non dice nulla sugli obblighi di registrazione, informativa o consenso — e le chiamate in uscita sono l'unico ambito di questo prodotto in cui tali obblighi non sono teorici. Negli Stati Uniti, effettuare chiamate automatizzate ai consumatori senza consenso è un problema TCPA prima ancora che un problema di ingegneria; nell'UE, registrare una chiamata senza informare l'interlocutore è un problema a sé. L'API ti fornisce un caller_number e un endpoint per terminare la chiamata. La conformità è a tuo carico.

"HD Voice" vale la pena di essere trattato anch'esso come un'affermazione anziché come una specifica. La documentazione di OpenAI afferma solo che SIP negozia il formato audio e non elenca alcun codec, quindi l'audio a banda larga nel post è una dichiarazione del fornitore che non è stata quantificata in alcuna sede pubblica. Verificalo con il tuo operatore prima di inserirlo in una presentazione.

Cosa fare con questo, questa settimana

Se gestisci già un agente vocale GPT-Live su WebRTC, il percorso in uscita è un secondo trasporto anziché una riscrittura: una nuova sessione creata con transport.type: "sip", un trunk che parla TLS e SDES-SRTP e un WebSocket sideband per monitorare squillo, risposta e DTMF. Metti in conto una giornata per il trunk, non per l'agente.

Se utilizzi Realtime, non pianificare la migrazione presupponendo che si tratti di una modifica di configurazione. Leggi prima le sezioni sulla delega e sulle sessioni, decidi se il tuo backend debba essere quello di OpenAI o il tuo, e solo allora scegli un partner — perché il partner che già usi per il traffico in entrata potrebbe non essere quello con un percorso documentato per il traffico in uscita.

Se stai ancora decidendo se valga la pena costruire del tutto la voce in uscita, il numero che conta è $3,00 per ora connessa prima dei costi dell'operatore, rispetto a un tetto massimo rigido di due ore e a un squillo di tre minuti. È abbastanza economico da testare e abbastanza costoso da rendere il tempo di attesa una decisione progettuale, non un caso. La GA ha rimosso il gate. Non ha rimosso l'aritmetica.