GPT-Live-1 kan nu uitbellen: wat de SIP GA echt mogelijk maakt, en wat het nog steeds niet doet

De nuttigste nieuwe mogelijkheid van een OpenAI-spraakagent is op 1 drukken. Sinds laat op 4 november 2026 kan een GPT-Live-1-sessie een uitgaand gesprek naar een echt telefoonnummer via een SIP-trunk opzetten, luisteren naar het menu dat opneemt, en toetstonen terug over de lijn sturen. Dat laatste onderdeel — bidirectionele DTMF — is het verschil tussen een spraakagent die praat en een spraakagent die door een telefonisch keuzemenu heen kan komen naar de afdeling die hij daadwerkelijk nodig heeft.

Het model zelf is niet nieuw. GPT-Live-1 zit sinds 8 juli 2026 in ChatGPT Voice en sinds 10 september 2026 in de API, voor $0,05 per minuut. Wat op 4 november veranderde, is de transportlaag. Justin Uberti van OpenAI kondigde aan dat de outbound telefonie-API "zojuist … naar GA was gepromoveerd", "waarmee ontwikkelaars telefonische oproepen kunnen doen vanuit hun Live-stemagent" via "elke SIP-trunkprovider (bijv. Telnyx of Twilio)"; Greg Brockman verbreidde het diezelfde nacht nog. In de aankondiging staat verder dat gesprekken HD Voice kunnen gebruiken en toetsaanslagen kunnen verzenden en ontvangen.

Dit is dus een verhaal over mogelijkheden, niet over een model, en het interessante materiaal staat in de documentatie in plaats van in de post. In de Telephony and SIP-gids van OpenAI staat nu dat uitgaand bellen "beschikbaar is voor alle organisaties via de Live API, niet via het call-creation-endpoint van de Realtime API" — twee zinnen die stilletjes een groot deel van de integraties uitsluiten die mensen zullen proberen te hergebruiken.

Wat "GA" veranderde, en wat niet

Vóór de promotie bestond uitgaand bellen al, maar was het niet algemeen beschikbaar — dat is wat "promoted" betekent. Het mechanisme was al gebouwd en de deur ging open. OpenAI's documentatie bevat nu de overeenkomstige zin, dat uitgaand SIP-bellen "beschikbaar is voor alle organisaties via de Live API", wat het dichtst in de buurt komt van een GA-verklaring op de pagina: de gids zelf bevat nergens een beta-, preview- of alfalabel.

Wat niet is veranderd, is het spraakmodel. Het uitgaande voorbeeld in de eigen documentatie van OpenAI stelt nog steeds model: "gpt-live-1" in, en de checklist voor partners vertelt integratoren nog steeds om te zoeken naar "een pakketversie die gpt-live-1 ondersteunt". Er is geen specifiek model voor uitgaande gesprekken, geen aparte prijs en geen telefonieniveau. Je betaalt dezelfde $0,05 per minuut voor de spraaklaag als in september; je mag het nu alleen besteden aan gesprekken die je server verlaten.

Eén operationeel voorbehoud schuilt in de gids in plaats van in de aankondiging: OpenAI vraagt je te bevestigen dat 'GPT-Live SIP-ondersteuning is ingeschakeld voor je project en dat de SIP-trunk van je provider naar dat project is gerouteerd voordat je deze flow gebruikt.' Een GA-label en een ingeschakelde projectinstelling zijn niet hetzelfde, en de eerste supportticket van de week zal afkomstig zijn van iemand die het een heeft zonder het ander.

De voorwaarden die bepalen of je trunk überhaupt werkt

OpenAI heeft SIP niet in de algemene zin overgenomen. Het heeft er een smalle, moderne deelverzameling van overgenomen, en een trunk die aan een van de volgende voorwaarden niet voldoet, maakt geen verbinding, wat de aankondiging ook beloofde over "elke SIP-trunkprovider".

Signaalgeving — TLS is verplicht, niet optioneel. Onversleutelde SIP via UDP of TCP is niet toegestaan.

• Media — SDES-SRTP is vereist, en SRTP moet bij de provider zijn ingeschakeld, niet alleen door de provider worden ondersteund.

• Provider-URL — een sips: endpoint wordt verwacht, standaard op poort 5061, zonder inloggegevens, zonder pad en zonder URI-parameters.

• Bestemming — een E.164-nummer zoals +14155550123 en niets anders. SIP-URI's worden expliciet niet ondersteund, dus een intern extensieschema is geen snelkoppeling.

• Authenticatie — digest, met een SIP-gebruikersnaam en -wachtwoord, plus een caller_number in E.164 dat de caller-ID wordt die de gebelde te zien krijgt.

• Netwerkhygiëne — lokale hostnamen en letterlijke privé-IP-adressen worden geweigerd, waardoor een testopstelling die naar een labmachine wijst, uitgesloten is.

• Audioformaat — laat audio.format niet ingesteld, omdat SIP dit onderhandelt. Het instellen ervan is precies zo'n behulpzaam ogende parameter die het gesprek breekt.

Let op wat dit betekent voor de claim "elke provider". Elke provider die TLS-signalering met SDES-SRTP-media ondersteunt, werkt; heel veel goedkope SIP-trunks gebruiken standaard nog steeds UDP en gewone RTP, en die vallen niet onder die zin. De koppeling is een sessie-creatie in plaats van een webhook: je doet een POST naar /v1/live/sessions met transport.type ingesteld op sip, en de gids is expliciet: "je hebt geen inkomende-call-webhook of een accept-verzoek nodig voor een uitgaande oproep."

Wat je terugkrijgt is een session.id en een transporttype, en de documentatie is ongewoon bot over de kloof tussen dat en de realiteit: "Deze respons betekent niet dat de oproep is beantwoord." Rinkelen, beantwoorden en falen komen later binnen als transport.ringing, transport.answered en transport.failed-events op een sideband-WebSocket op /v1/live/sessions/{session_id}/attach. Koppel onmiddellijk — alleen de voorgaande drie seconden aan events worden opnieuw afgespeeld — en dedupliceer op event_id, want de gids waarschuwt dat dubbele leveringen normaal zijn.

De envelop: drie minuten om te bellen, twee uur om te praten

Twee harde cijfers in de gids zullen bepalen welke outbound use cases haalbaar zijn, en geen van beide stond in de aankondiging.

• Beltijdslimiet — drie minuten. Een oproep die tegen die tijd niet is beantwoord, is afgelopen.

Verbondenheidslimiet — twee uur, waarna de sessie eindigt, ongeacht wat er gebeurt.

• Controlevlak — overdragen via /v1/live/sessions/{id}/refer, ophangen via /v1/live/sessions/{id}/hangup, DTMF verzonden via de zijband met transport.dtmf.send.

• Faalwijzen — een slechte sessieconfiguratie faalt luid bij het aanmaken, transportopzet kan 502 retourneren, een initialisatie-timeout retourneert 504, en alles daarna arriveert asynchroon als transport.failed.

De ringtijd van drie minuten is prima voor outbound naar consumenten en onhandig voor bedrijfscentrales die gesprekken parkeren. Het plafond van twee uur is ruim, totdat je de agent op een supportwachtrij richt, waar een lange wachttijd plus een lang gesprek er aannemelijk tegenaan kunnen schuren. Geen van beide limieten is een verrassing in een realtime spraakproduct; beide zijn het soort dingen die je wilt weten voordat je een klant een campagne-SLA belooft.

Wat een oproep kost, eerlijk gezegd

OpenAI's prijzenpagina vermeldt GPT-Live-1-spraaksessies tegen $0,05 per minuut, "per seconde gefactureerd, zonder naar boven af te ronden naar een hele minuut." Dat is de volledige gepubliceerde prijs, en het is slechts een van de twee facturen die een uitgaand gesprek oplevert. De terminationkosten van de carrier zijn de andere, en die hangen af van de bestemming, het volume en welke trunkprovider je hebt gekozen. OpenAI behoudt audioverwerking en sessielogica; de provider bezit het PSTN-deel.

• Een beantwoorde oproep van één minuut — $0.050 van OpenAI, plus het per-minuuttarief van je provider.

• Een gesprek van vier minuten — $0.200 van OpenAI, plus provider.

• Duizend gesprekken van vier minuten — 4.000 minuten, dus $200 van OpenAI, plus telecomoperator.

• Een uur lang een verbonden gesprek — $3.00 van OpenAI, plus provider.

Twee dingen aan die meter verdienen aandacht. Ten eerste is de facturatie-eenheid de sessieminuut, en niets op de prijspagina onderscheidt spraak van stilte, dus de seconden die je agent naar wachtmuziek luistert, lopen tegen hetzelfde tarief op als de seconden die hij pratend doorbrengt. Ten tweede zegt de handleiding niet of een oproep die drie minuten overgaat en nooit wordt beantwoord, een factureerbare sessie is; dat is een vraag die je de supportafdeling beter kunt stellen voordat je een dialer op grote schaal inzet, niet erna.

Backendmodel- en toolgebruik worden apart gefactureerd, tegen het tarief van het model waaraan je hebt gedelegeerd. Als je dat deel via OrcaRouter laat lopen, gelden de 0% opslag en pass-through-prijzen daar en niet voor de spraakminuut — dus een prijsverlaging van een provider voor het reasoningmodel is dezelfde dag op je factuur zichtbaar, en een verlaging voor gpt-live-1 niet.

Je Realtime-integratie wordt niet overgezet

De duurste fout die je deze week kunt maken, is aannemen dat een werkende Realtime API-telefoniestack een werkende GPT-Live-stack is. De partnerpagina van OpenAI zegt het ronduit: "Een Realtime-integratie is niet automatisch compatibel met GPT-Live." Het endpoint is anders, het sessiemodel is anders, delegatie is een concept dat Realtime niet in dezelfde vorm kent, en de audioformaten en onderbrekingssemantiek die de gids je per partner vraagt te controleren, worden niet meegenomen.

De partnerlijst compliceert ook de formulering van de aankondiging. OpenAI documenteert LiveKit voor spraakagenten; Twilio Agent Connect voor "inkomende en uitgaande telefoongesprekken"; Telnyx voor "ervaringen met uitgaand bellen"; Bandwidth voor "inkomende gesprekken" via SIP; en Daily/Pipecat voor de Live-service in het algemeen. Met andere woorden, Bandwidth wordt gedocumenteerd als een inbound-integratie, en LiveKit en Pipecat worden gedocumenteerd zonder enige gespreksrichting. "Elke SIP-trunkprovider" is een uitspraak over protocolcompatibiliteit, niet over welke van OpenAI's vijf partners ondersteuning voor uitgaand bellen heeft geleverd.

Als je op Twilio zit, is dat de migratie met op dit moment een gedocumenteerd uitgaand pad. Als je Bandwidth gebruikt voor inkomend verkeer, is uitgaand verkeer via die integratie nog niet iets wat de documentatie belooft.

De versievraag die niemand stelde

Er is een actuele dubbelzinnigheid in de naam. GPT-Live-1.1 is op 15 oktober 2026 in ChatGPT Voice opgenomen met nieuwe stemmen in zes talen, en OpenAI heeft nog steeds geen gpt-live-1.1 model-id voor API-aanroepers gepubliceerd. Elk uitgaand voorbeeld in de telefoniegids gebruikt gpt-live-1. Als een collega je vertelt dat de uitgaande agent 1.1 draait omdat ChatGPT dat gebruikt, dan beschrijft diegene het consumentenproduct, niet je sessieconfiguratie.

Praktisch: citeer gpt-live-1 in je plan, en behandel elke beschikbaarheid van de 1.1 API als een afzonderlijke gebeurtenis die op zijn eigen dag moet worden geverifieerd.

Waar het denken plaatsvindt, en waarom dat de hefboom is die jij beheerst

GPT-Live is in twee helften verdeeld. De eigen samenvatting van de documentatie luidt dat het "redeneren en toolgebruik delegeert naar een backend terwijl het het gesproken gesprek beheert". De spraaklaag regelt timing, onderbrekingen en prosodie; een apart model doet het denkwerk en roept de tools aan. Die backend wordt per sessie geconfigureerd onder delegation, in een van twee modi.

• Responses-delegatie — delegation.type: "responses" met een vereist backend-model, plus instructies, tools, toolkeuze, tokenlimieten en serviceniveau. De gids van OpenAI raadt aan te beginnen met gpt-6-luna, of gpt-6-sol voor moeilijker werk, en merkt op dat "je het Responses-model onafhankelijk van het spraakmodel kunt kiezen."

• Clientdelegatie — delegation.type: "client", waarbij je applicatie zelf de backend draait. Volgens OpenAI maakt dit "elk model, agent of service dat je applicatie exploiteert" mogelijk.

Hier liggen daadwerkelijk de kosten en de kwaliteit van een outboundagent, en dit is de enige architectuurkeuze op de pagina die echt van jou is. Het spraakmodel ligt vast en staat toevallig niet in de catalogus van OrcaRouter — GPT-Live-1 is een telefonie-frontend die je bij OpenAI koopt, en hoe slim je ook routeert, dat verandert daar niets aan. De backend is een ander verhaal. Bij clientdelegatie is het een gewone modelaanroep die je code doet, wat betekent één API voor 200+ modellen, één sleutel voor alle leveranciers die je evalueert, automatische failover als een provider midden in een campagne verslechtert, en modelkeuze per oproeptype: een goedkoop model om een IVR-menu te doorlopen, een sterker model zodra een mens opneemt.

Bij Responses-delegatie voert OpenAI dat deel uit en factureert het tegen zijn eigen tarieven. Beide zijn legitiem; ze plaatsen de beslissing alleen op verschillende plekken. Als je wilt dat de backend een routeringsbeslissing is, is clientdelegatie de modus die je dat geeft.

Wat de aankondiging niet vermeldde

Voor een GA-bericht is de aankondiging mager over de zaken die de uitrol bepalen. Er staat niets in over regionale beschikbaarheid, latentie, concurrencylimieten of een SLA. Er staat niets in over verplichtingen rond opnemen, openbaarmaking of toestemming — en uitgaande gesprekken zijn binnen dit product juist de plek waar die verplichtingen niet theoretisch zijn. In de Verenigde Staten is het plegen van geautomatiseerde oproepen naar consumenten zonder toestemming een TCPA-probleem voordat het een engineeringprobleem is; in de EU is een gesprek opnemen zonder de persoon aan de andere kant daarover te informeren op zichzelf al een probleem. De API geeft je een caller_number en een hangup-endpoint. Compliance is aan jou.

"HD Voice" kun je ook beter als een bewering dan als een specificatie behandelen. In de documentatie van OpenAI staat alleen dat SIP het audioformaat onderhandelt en er worden geen codecs genoemd, dus de breedbandaudio in het bericht is een uitspraak van de leverancier die nergens openbaar is gekwantificeerd. Test het bij je eigen provider voordat je het in een presentatie zet.

Wat te doen met dit, deze week

Als je al een GPT-Live-spraakagent op WebRTC draait, is het uitgaande pad een tweede transport in plaats van een herschrijving: een nieuwe sessie aangemaakt met transport.type: "sip", een trunk die TLS en SDES-SRTP spreekt, en een sideband-WebSocket om op te letten op ringing, beantwoorden en DTMF. Trek een dag uit voor de trunk, niet voor de agent.

Als je op Realtime zit, plan de migratie dan niet op basis van de aanname dat het een configuratiewijziging is. Lees eerst de secties over delegatie en sessies, beslis of je backend die van OpenAI of die van jou moet zijn, en kies pas daarna een partner — want de partner die je al gebruikt voor inbound is mogelijk niet degene met een gedocumenteerd outbound-pad.

Als je nog steeds afweegt of outbound voice überhaupt de moeite waard is om te bouwen, is het getal dat ertoe doet $3,00 per verbonden uur vóór kosten van de telecomprovider, tegen een harde limiet van twee uur en een ringtijd van drie minuten. Dat is goedkoop genoeg om te testen en duur genoeg dat wachttijd een ontwerpbeslissing is, geen toeval. De GA heeft de poort verwijderd. De rekensom is niet verdwenen.