GPT-Live-1 kan nu ringa ut: vad SIP GA faktiskt möjliggör – och vad det fortfarande inte klarar av

Det mest användbara nya som en OpenAI-röstagent kan göra är att trycka på 1. Sedan sent den 4 november 2026 kan en GPT-Live-1session ringa ett utgående samtal till ett verkligt telefonnummer via en SIP-trunk, lyssna på menyn som svarar och skicka knapptoner tillbaka i linjen. Den sista delen – dubbelriktad DTMF – är skillnaden mellan en röstagent som pratar och en röstagent som kan ta sig igenom ett telefonmenysystem till den avdelning den faktiskt behöver.

Modellen i sig är inte ny. GPT-Live-1 har funnits i ChatGPT Voice sedan den 8 juli 2026 och i API:et sedan den 10 september 2026 för $0,05 per minut. Det som förändrades den 4 november är transporten. Justin Uberti på OpenAI meddelade att API:et för utgående telefoni hade ”nyligen befordrats … till GA”, ”vilket gör det möjligt för utvecklare att ringa samtal från sin Live-röstagent” via ”vilken SIP-trunkleverantör som helst (t.ex. Telnyx eller Twilio)”; Greg Brockman förstärkte det samma natt. Tillkännagivandet tillägger att samtal kan använda HD Voice och kan skicka och ta emot knappsatshändelser.

Det här är alltså en kapacitetshistoria, inte en modellhistoria, och det intressanta materialet finns i dokumentationen snarare än i inlägget. OpenAIs guide för Telephony och SIP anger nu att utgående samtal är "tillgängligt för alla organisationer via Live API, inte via Realtime API:s slutpunkt för att skapa samtal" – två meningar som i tysthet utesluter en stor del av de integrationer som folk kommer att försöka återanvända.

Vad "GA" förändrade, och vad det inte gjorde

Före promoveringen fanns funktionen för utgående samtal, men den var inte allmänt tillgänglig – det är vad ”promoted” betyder. Mekanismen var redan byggd, och dörren öppnades. OpenAIs dokumentation innehåller nu den motsvarande meningen, att utgående SIP-samtal ”är tillgängliga för alla organisationer via Live API”, vilket är det närmaste ett GA-uttalande som finns på sidan: själva guiden har ingen beta-, förhandsgransknings- eller alfaetikett någonstans.

Det som inte förändrades är röstmodellen. Det utgående exemplet i OpenAI:s egen dokumentation sätter fortfarande model: "gpt-live-1", och partnerchecklistan säger fortfarande till integratörer att leta efter "en paketversion som stöder gpt-live-1". Det finns ingen modell specifik för utgående samtal, inget separat pris och ingen telefontier. Du betalar samma $0,05 per minut för röstlagret som du betalade i september; du får helt enkelt nu tillåtelse att lägga det på samtal som lämnar din server.

Ett operativt förbehåll ligger gömt i guiden snarare än i tillkännagivandet: OpenAI uppmanar dig att bekräfta att "GPT-Live SIP-stöd är aktiverat för ditt projekt och att din leverantörs SIP-trunk är dirigerad till det projektet innan du använder det här flödet." En GA-märkning och en aktiverad projektinställning är inte samma sak, och veckans första supportärende kommer att vara någon som har det ena utan det andra.

Förutsättningarna som avgör om din trunk fungerar överhuvudtaget

OpenAI antog inte SIP i allmän bemärkelse. Det antog en snäv, modern del av det, och en trunk som misslyckas med något av följande kommer inte att ansluta, oavsett vad tillkännagivandet lovade om "vilken SIP-trunkleverantör som helst".

• Signalering – TLS är ett krav, inte valfritt. Vanlig SIP över UDP eller TCP är uteslutet.

• Media — SDES-SRTP krävs, och SRTP måste vara aktiverat hos leverantören, inte bara stödjas av den.

• Leverantörs-URL – en slutpunkt av typen sips: förväntas, med standardport 5061, utan autentiseringsuppgifter, sökväg eller URI-parametrar.

• Destination — ett E.164-nummer som till exempel +14155550123 och inget annat. SIP-URI:er stöds uttryckligen inte, så ett internt anknytningsschema är ingen genväg.

• Autentisering – digest, med ett SIP-användarnamn och lösenord, plus ett caller_number i E.164 som blir det nummer som den du ringer ser som nummerpresentation.

• Nätverkshygien – lokala värdnamn och literala privata IP-adresser avvisas, vilket utesluter en testrigg som pekar mot en labbmaskin.

• Ljudformat — lämna audio.format oinställt, eftersom SIP förhandlar det. Att ställa in det är en sådan där till synes hjälpsam parameter som bryter samtalet.

Notera vad detta innebär för påståendet "valfri leverantör". Alla leverantörer som talar TLS-signalering med SDES-SRTP-media fungerar; många billiga SIP-trunkar använder fortfarande UDP och vanlig RTP som standard, och de omfattas inte av den meningen. Kopplingen är att skapa en session i stället för en webhook: du POSTar till /v1/live/sessions med transport.type satt till sip, och guiden är tydlig med att "du behöver ingen webhook för inkommande samtal eller någon accept-begäran för ett utgående samtal."

Det du får tillbaka är ett session.id och en transporttyp, och dokumentationen är ovanligt rättfram om gapet mellan det och verkligheten: "Det här svaret betyder inte att samtalet har besvarats." Ringning, svar och misslyckande kommer senare som händelserna transport.ringing, transport.answered och transport.failed på en sidobands-WebSocket på /v1/live/sessions/{session_id}/attach. Anslut omedelbart – endast händelserna från de föregående tre sekunderna spelas upp – och deduplicera på event_id, eftersom guiden varnar för att dubbletter i leveranser är normala.

Kuvertet: tre minuter att ringa, två timmar att prata

Två hårda siffror i guiden kommer att avgöra vilka outbound-användningsfall som är gångbara, och ingen av dem förekom i tillkännagivandet.

• Ringningstid — tre minuter. Ett samtal som inte har besvarats då avslutas.

• Ansluten tidsgräns – två timmar, varefter sessionen avslutas oavsett vad som händer.

• Styryta — vidarekoppla via /v1/live/sessions/{id}/refer, lägg på via /v1/live/sessions/{id}/hangup, DTMF skickas över sidbandet med transport.dtmf.send.

• Felmoder – en felaktig sessionskonfiguration misslyckas tydligt vid skapandet, transportuppsättningen kan returnera 502, en initieringstimeout returnerar 504, och allt som inträffar senare anländer asynkront som transport.failed.

Tre minuters ringtid fungerar bra för utgående konsumentsamtal och är besvärlig för företagsväxlar som parkerar samtal. Taket på två timmar är generöst tills man riktar agenten mot en supportkö, där en lång väntetid plus ett långt samtal rimligen kan snudda vid det. Ingen av gränserna är en överraskning i en realtidsröstprodukt; båda är sådant man vill känna till innan man lovar en kund ett kampanj-SLA.

Vad ett samtal kostar, ärligt talat

OpenAIs prislista anger GPT-Live-1-röstsessioner till 0,05 USD per minut, "faktureras per sekund, utan avrundning uppåt till en hel minut." Det är hela det publicerade priset, och det är bara en av de två kostnaderna som ett utgående samtal genererar. Operatörens termineringsavgift är den andra, och den beror på destination, volym och vilken trunkleverantör du valde. OpenAI behåller ljudbearbetning och sessionslogik; leverantören äger PSTN-delen.

• Ett besvarat samtal på en minut – $0.050 från OpenAI, plus din operatörs minutpris.

• Ett fyraminuterssamtal – $0.200 från OpenAI, plus operatörsavgift.

• Tusen fyraminuterssamtal — 4 000 minuter, alltså $200 från OpenAI, plus operatör.

• En timmes uppkopplat samtal — $3.00 från OpenAI, plus operatör.

Två saker med den där mätaren förtjänar uppmärksamhet. För det första är faktureringsenheten sessionsminuten, och inget på prissidan skiljer tal från tystnad, så sekunderna din agent lyssnar på väntemusik räknas i samma takt som sekunderna den pratar. För det andra står det inte i guiden om ett samtal som ringer i tre minuter och aldrig besvaras är en fakturerbar session; det är en fråga värd att ställa till supporten innan du kör en dialer i stor omfattning, inte efteråt.

Användning av backendmodell och verktyg debiteras separat, enligt den modell du delegerade till. Om du dirigerar den delen via OrcaRouter gäller 0 % påslag och pass-through-prissättning där i stället för på röstminuten – så att en leverantörsprissänkning på resonemangsmodellen syns på din faktura samma dag, medan en sänkning på gpt-live-1 inte gör det.

Din Realtime-integration kommer inte att porteras över

Det enskilt dyraste misstag som är möjligt den här veckan är att anta att en fungerande Realtime API-telefonistack är en fungerande GPT-Live-stack. OpenAIs partnersida säger det rakt ut: "En Realtime-integration är inte automatiskt kompatibel med GPT-Live." Slutpunkten är annorlunda, sessionsmodellen är annorlunda, delegering är ett begrepp som Realtime inte har i samma form, och de ljudformat och avbrottssemantiker som guiden ber dig att kontrollera per partner förs inte över.

Partnerlistan komplicerar också tillkännagivandets formulering. OpenAI dokumenterar LiveKit för röstagenter; Twilio Agent Connect för "inkommande och utgående telefonsamtal"; Telnyx för "utgående samtalsupplevelser"; Bandwidth för "inkommande samtal" över SIP; och Daily/Pipecat för Live-tjänsten i allmänhet. Bandwidth dokumenteras med andra ord som en inkommande integration, och LiveKit och Pipecat dokumenteras utan någon samtalsriktning alls. "Vilken SIP-trunkleverantör som helst" är ett uttalande om protokollkompatibilitet, inte ett uttalande om vilken av OpenAIs fem partner som har släppt stöd för utgående samtal.

Om du använder Twilio är migrationen den som har en dokumenterad utgående väg i dag. Om du använder Bandwidth för inkommande är utgående via den integrationen inte något som dokumentationen lovar ännu.

Versionsfrågan ingen ställde

Det råder en aktuell tvetydighet kring namnet. GPT-Live-1.1 rullades in i ChatGPT Voice den 15 oktober 2026 med nya röster på sex språk, och OpenAI har fortfarande inte publicerat ett gpt-live-1.1-modell-id för API-anropare. Alla utgående exempel i telefontiguiden använder gpt-live-1. Om en kollega säger att den utgående agenten kör 1.1 eftersom det är vad ChatGPT använder, beskriver de konsumentprodukten, inte din sessionskonfiguration.

I praktiken: citera gpt-live-1 i din plan, och behandla eventuell tillgänglighet för 1.1-API:et som en separat händelse som ska verifieras på sin egen dag.

Där tänkandet sker, och varför det är hävstången du styr

GPT-Live är delat på mitten. Dokumentationens egen sammanfattning är att det "delegerar resonemang och verktygsanvändning till en backend medan det hanterar det talade samtalet." Röstlagret hanterar tajming, avbrott och prosodi; en separat modell gör tänkandet och anropar verktygen. Den backenden konfigureras per session under delegering, i ett av två lägen.

• Responses-delegering — delegation.type: "responses" med en obligatorisk backend modell, plus instruktioner, verktyg, verktygsval, tokenbegränsningar och servicenivå. OpenAIs guide rekommenderar att börja med gpt-6-luna, eller gpt-6-sol för svårare arbete, och noterar att "du kan välja Responses-modellen oberoende av röstmodellen."

• Klientdelegering — delegation.type: "client", där din applikation själv kör backend. OpenAIs formulering är att detta tillåter "vilken modell, agent eller tjänst som helst som din applikation driver."

Det är här en outbound-agents kostnad och kvalitet faktiskt ligger, och det är det enda arkitekturvalet på sidan som verkligen är ditt. Röstmodellen är fast och råkar inte finnas i OrcaRouters katalog – GPT-Live-1 är en telefonifrontend du köper från OpenAI, och ingen routing-skicklighet i världen ändrar på det. Backend är en annan sak. Med klientdelegering är det ett vanligt modellanrop som din kod gör, vilket innebär ett API för 200+ modeller, en enda nyckel för de leverantörer du utvärderar, automatisk failover om en leverantör försämras mitt i en kampanj, och modellval per anropstyp: en billig modell för att ta sig igenom en IVR-meny, en starkare när en människa svarar.

Under Responses-delegering kör OpenAI den delen och fakturerar den enligt sina egna priser. Båda är legitima; de placerar bara beslutet på olika ställen. Om du vill att backend ska vara ett routingbeslut är klientdelegering det läge som ger dig det.

Vad tillkännagivandet utelämnade

För ett GA-inlägg är tillkännagivandet magert när det gäller det som avgör driftsättningar. Det säger ingenting om regional tillgänglighet, latens, samtidighetsgränser eller något SLA. Det säger ingenting om skyldigheter kring inspelning, informationsplikt eller samtycke — och utgående samtal är den enda platsen i den här produkten där de skyldigheterna inte är teoretiska. I USA är automatiserade samtal till konsumenter utan samtycke ett TCPA-problem innan det är ett ingenjörsproblem; i EU är inspelning av ett samtal utan att berätta det för personen i andra änden ett problem i sig. API:et ger dig ett caller_number och en endpoint för att lägga på. Efterlevnaden är din.

"HD Voice" är också värt att behandla som ett påstående snarare än en specifikation. OpenAIs dokumentation säger bara att SIP förhandlar om ljudformatet och listar inga kodekar, så bredbandsljudet i inlägget är ett leverantörspåstående som inte har kvantifierats någonstans offentligt. Testa det mot din egen operatör innan du sätter det i en presentation.

Vad man ska göra med detta, den här veckan

Om du redan kör en GPT-Live-röstagent på WebRTC är den utgående vägen en andra transport snarare än en omskrivning: en ny session som skapas med transport.type: "sip", en trunk som talar TLS och SDES-SRTP, och en sidobands-WebSocket för att bevaka ringning, svar och DTMF. Avsätt en dag för trunken, inte för agenten.

Om du använder Realtime ska du inte schemalägga migreringen utifrån antagandet att det är en konfigurationsändring. Läs avsnitten om delegering och sessioner först, bestäm om din backend ska vara OpenAIs eller din egen och välj först därefter en partner – eftersom partnern du redan använder för inkommande trafik kanske inte är den som har en dokumenterad väg för utgående trafik.

Om du fortfarande funderar på om utgående röst ens är värt att bygga, är siffran som spelar roll $3.00 per ansluten timme före operatörsavgifter, mot ett hårt tak på två timmar och en ringtid på tre minuter. Det är billigt nog att testa och dyrt nog att väntetid är ett designbeslut, inte en olyckshändelse. GA tog bort grinden. Det tog inte bort aritmetiken.