GPT-Live-1 peut désormais passer des appels sortants : ce que la disponibilité générale du SIP débloque réellement, et ce qu’il ne peut toujours pas faire

La chose nouvelle la plus utile qu’un agent vocal OpenAI puisse faire est d’appuyer sur 1. Depuis la fin de la soirée du 4 novembre 2026, une session GPT-Live-1 peut passer un appel sortant vers un vrai numéro de téléphone via un trunk SIP, écouter le menu qui répond et renvoyer des tonalités de clavier sur la ligne. Cette dernière partie — la DTMF bidirectionnelle — fait toute la différence entre un agent vocal qui parle et un agent vocal capable de traverser un arbre téléphonique pour atteindre le service dont il a réellement besoin.

Le modèle lui-même n’est pas nouveau. GPT-Live-1 est disponible dans ChatGPT Voice depuis le 8 juillet 2026 et dans l’API depuis le 10 septembre 2026, à 0,05 $ la minute. Ce qui a changé le 4 novembre, c’est le transport. Justin Uberti, d’OpenAI, a annoncé que l’API de téléphonie sortante avait été « tout juste promue … en GA », « permettant aux développeurs de passer des appels téléphoniques depuis leur agent vocal Live » via « n’importe quel fournisseur de trunk SIP (par ex. Telnyx ou Twilio) » ; Greg Brockman a relayé l’information le même soir. L’annonce ajoute que les appels peuvent utiliser HD Voice et envoyer et recevoir des événements de clavier.

C’est donc une histoire de capacité, pas une histoire de modèle, et l’essentiel de l’intérêt se trouve dans la documentation plutôt que dans l’article. Le guide Telephony and SIP d’OpenAI indique désormais que les appels sortants sont « disponibles pour toutes les organisations via l’API Live, et non via le point de terminaison de création d’appels de l’API Realtime » — deux phrases qui écartent discrètement une large partie des intégrations que les gens chercheront à réutiliser.

Ce que « GA » a changé, et ce qu’il n’a pas changé

Avant la promotion, les appels sortants existaient mais n’étaient pas disponibles de manière générale — c’est ce que signifie « promu ». Le mécanisme était déjà construit, et la porte s’est ouverte. La documentation d’OpenAI contient désormais la phrase correspondante, selon laquelle les appels sortants SIP « sont disponibles pour toutes les organisations via la Live API », ce qui ressemble le plus à une déclaration de GA sur la page : le guide lui-même ne porte nulle part d’étiquette bêta, preview ou alpha.

Ce qui n'a pas changé, c'est le modèle vocal. L'exemple sortant dans la documentation d'OpenAI elle-même définit toujours model: "gpt-live-1", et la liste de contrôle des partenaires indique toujours aux intégrateurs de rechercher « une version du package qui prend en charge gpt-live-1 ». Il n'y a pas de modèle spécifique aux appels sortants, pas de tarif séparé et pas de niveau de téléphonie. Vous payez les mêmes 0,05 $ par minute pour la couche vocale qu'en septembre ; vous êtes simplement désormais autorisé à le dépenser pour des appels qui quittent votre serveur.

Une mise en garde opérationnelle se cache dans le guide plutôt que dans l’annonce : OpenAI vous demande de confirmer que « la prise en charge de GPT-Live SIP est activée pour votre projet et que le trunk SIP de votre fournisseur est routé vers ce projet avant d’utiliser ce flux. » Un label GA et un paramètre de projet activé ne sont pas la même chose, et le premier ticket d’assistance de la semaine sera celui de quelqu’un qui a l’un sans l’autre.

Les prérequis qui déterminent si votre trunk fonctionne du tout

OpenAI n’a pas adopté SIP au sens général. Elle en a adopté une tranche étroite et moderne, et un trunk qui ne satisfait pas à l’un des critères suivants ne se connectera pas, quelles que soient les promesses de l’annonce concernant « n’importe quel fournisseur de trunk SIP ».

• Signalisation — TLS est obligatoire, pas facultatif. Le SIP en clair sur UDP ou TCP est exclu.

• Médias — SDES-SRTP est requis, et SRTP doit être activé chez le fournisseur, et pas seulement pris en charge par celui-ci.

• URL du fournisseur — un sips: point de terminaison est attendu, avec le port 5061 par défaut, sans identifiants, sans chemin et sans paramètres d'URI associés.

• Destination — un numéro E.164 tel que +14155550123, et rien d’autre. Les URI SIP ne sont explicitement pas prises en charge, donc un schéma d’extension interne n’est pas un raccourci.

• Authentification — digest, avec un nom d'utilisateur et un mot de passe SIP, plus un caller_number au format E.164 qui devient l'identifiant d'appelant que voit votre correspondant.

• Hygiène réseau — les noms d’hôtes locaux et les adresses IP privées littérales sont rejetés, ce qui exclut un banc de test pointé vers une machine de laboratoire.

• Format audio — laissez audio.format non défini, car c'est SIP qui le négocie. Le définir est exactement le genre de paramètre qui semble utile mais qui casse l'appel.

Notez ce que cela implique pour l’affirmation « tout fournisseur ». Tout fournisseur qui parle signalisation TLS avec média SDES-SRTP fonctionnera ; un grand nombre de trunks SIP bon marché utilisent encore par défaut UDP et RTP en clair, et ils ne sont pas couverts par cette phrase. Le raccordement est une création de session plutôt qu’un webhook : vous faites un POST vers /v1/live/sessions avec transport.type défini sur sip, et le guide précise explicitement que « vous n’avez pas besoin d’un webhook d’appel entrant ni d’une requête d’acceptation pour un appel sortant. »

Ce que vous obtenez en retour, c'est un session.id et un type de transport, et la documentation est d'une franchise inhabituelle sur l'écart entre cela et la réalité : « Cette réponse ne signifie pas que l'appel a été décroché. » La sonnerie, la prise d'appel et l'échec arrivent plus tard, avec les événements transport.ringing, transport.answered et transport.failed sur un WebSocket sideband à /v1/live/sessions/{session_id}/attach. Attachez-vous immédiatement — seules les trois secondes d'événements qui précèdent sont rejouées — et dédupliquez par event_id, car le guide avertit que les livraisons en double sont normales.

L’enveloppe : trois minutes pour sonner, deux heures pour parler

Deux chiffres concrets dans le guide détermineront quels cas d’usage sortants sont viables, et aucun des deux n’apparaissait dans l’annonce.

• Durée maximale de sonnerie — trois minutes. Un appel qui n'a pas été décroché d'ici là prend fin.

• Plafond connecté — deux heures, après quoi la session se termine quoi qu’il se passe.

• Surface de contrôle — transfert via /v1/live/sessions/{id}/refer, raccrochage via /v1/live/sessions/{id}/hangup, DTMF envoyé via la bande latérale avec transport.dtmf.send.

• Modes de défaillance — une configuration de session incorrecte échoue explicitement dès la création, la configuration du transport peut renvoyer 502, un délai d’expiration d’initialisation renvoie 504, et tout ce qui survient ensuite arrive de manière asynchrone sous la forme de transport.failed.

Une sonnerie de trois minutes convient aux appels sortants grand public et s’avère peu pratique pour les standardistes d’entreprise qui mettent des appels en attente. Le plafond de deux heures est généreux jusqu’à ce que vous dirigiez l’agent vers une file d’attente de support, où une longue attente suivie d’une longue conversation peut plausiblement l’approcher. Aucune de ces limites n’est surprenante dans un produit vocal en temps réel ; ce sont deux choses qu’il vaut mieux savoir avant de promettre à un client un SLA de campagne.

Ce que coûte un appel, honnêtement

La page de tarification d'OpenAI indique les sessions vocales GPT-Live-1 à 0,05 $ par minute, « facturées à la seconde, sans arrondi à la minute entière ». C'est l'intégralité du prix publié, et ce n'est pourtant qu'une des deux factures générées par un appel sortant. Les frais de terminaison de l'opérateur constituent l'autre, et ils dépendent de la destination, du volume et du fournisseur de trunk choisi. OpenAI conserve le traitement audio et la logique de session ; le fournisseur prend en charge le segment PSTN.

• Un appel répondu d’une minute — 0,050 $ d’OpenAI, plus le tarif par minute de votre opérateur.

• Un appel de quatre minutes — $0.200 d’OpenAI, plus l’opérateur.

• Mille appels de quatre minutes — 4 000 minutes, soit 200 $ d'OpenAI, plus l'opérateur.

• Une heure de conversation connectée — 3,00 $ d’OpenAI, plus les frais de l’opérateur.

Deux points concernant ce compteur méritent votre attention. Premièrement, l'unité de facturation est la minute de session, et rien sur la page tarifaire ne distingue la parole du silence ; ainsi, les secondes que votre agent passe à écouter de la musique d'attente sont décomptées au même rythme que les secondes qu'il passe à parler. Deuxièmement, le guide ne précise pas si un appel qui sonne pendant trois minutes sans jamais recevoir de réponse constitue une session facturable ; c'est une question à poser au support avant de lancer un autocomposeur à grande échelle, et non après.

L'utilisation du modèle backend et des outils est facturée séparément, au tarif du modèle auquel vous avez délégué le traitement. Si vous acheminez ce segment via OrcaRouter, la marge de 0 % et la tarification au prix coûtant s'appliquent à ce niveau plutôt qu'à la minute vocale — ainsi, une baisse de prix du fournisseur sur le modèle de raisonnement apparaît sur votre facture le jour même, tandis qu'une baisse sur gpt-live-1 ne s'y reflète pas.

Votre intégration Realtime ne sera pas transférée

L’erreur la plus coûteuse qu’il soit possible de commettre cette semaine est de supposer qu’une pile de téléphonie Realtime API fonctionnelle est une pile GPT-Live fonctionnelle. La page partenaire d’OpenAI le dit clairement : « Une intégration Realtime n’est pas automatiquement compatible avec GPT-Live. » Le point de terminaison est différent, le modèle de session est différent, la délégation est un concept que Realtime ne possède pas sous la même forme, et les formats audio ainsi que la sémantique d’interruption que le guide vous demande de vérifier pour chaque partenaire ne sont pas transposés.

La liste des partenaires complique aussi la formulation de l’annonce. OpenAI documente LiveKit pour les agents vocaux ; Twilio Agent Connect pour « les appels téléphoniques entrants et sortants » ; Telnyx pour « les expériences d’appels sortants » ; Bandwidth pour « les appels entrants » via SIP ; et Daily/Pipecat pour le service Live de manière générale. Bandwidth, autrement dit, est documenté comme une intégration entrante, et LiveKit et Pipecat sont documentés sans aucun sens d’appel. « Tout fournisseur de trunk SIP » est une affirmation sur la compatibilité des protocoles, pas une affirmation sur lequel des cinq partenaires d’OpenAI a livré une prise en charge des appels sortants.

Si vous êtes sur Twilio, la migration est celle qui dispose aujourd'hui d'un chemin sortant documenté. Si vous êtes sur Bandwidth pour l'entrant, le sortant via cette intégration n'est pas encore quelque chose que la documentation promet.

La question de la version que personne n'a posée

Il existe une ambiguïté persistante dans le nom. GPT-Live-1.1 a été intégré à ChatGPT Voice le 15 octobre 2026 avec de nouvelles voix dans six langues, et OpenAI n'a toujours pas publié d'gpt-live-1.1 identifiant de modèle pour les appelants de l'API. Chaque exemple sortant du guide de téléphonie utilise gpt-live-1. Si un collègue vous dit que l'agent sortant utilise la version 1.1 parce que c'est ce que ChatGPT utilise, il décrit le produit grand public, pas la configuration de votre session.

Concrètement : citez gpt-live-1 dans votre plan, et traitez toute disponibilité de l’API 1.1 comme un événement distinct à vérifier à sa propre date.

Là où se produit la réflexion, et pourquoi c’est le levier que vous contrôlez

GPT-Live est scindé en deux. Le résumé de la documentation indique lui-même qu’il « délègue le raisonnement et l’utilisation d’outils à un backend tandis qu’il gère la conversation parlée ». La couche vocale gère le timing, les interruptions et la prosodie ; un modèle distinct effectue la réflexion et appelle les outils. Ce backend est configuré par session sous delegation, selon l’un de deux modes.

• Délégation Responses — delegation.type: "responses" avec un model backend obligatoire, ainsi que des instructions, des outils, le choix des outils, des limites de tokens et un niveau de service. Le guide d'OpenAI recommande de commencer par gpt-6-luna, ou gpt-6-sol pour les tâches plus difficiles, et précise que « vous pouvez choisir le modèle Responses indépendamment du modèle vocal ».

• Délégation client — delegation.type: "client", où votre application exécute elle-même le backend. Selon la formulation d'OpenAI, cela autorise « tout modèle, agent ou service exploité par votre application. »

C'est là que résident réellement le coût et la qualité d'un agent sortant, et c'est le seul choix d'architecture de la page qui vous appartienne véritablement. Le modèle vocal est figé et, en l'occurrence, absent du catalogue d'OrcaRouter — GPT-Live-1 est un front-end téléphonique que vous achetez à OpenAI, et aucune prouesse de routage n'y changera rien. Le backend est une autre histoire. Dans le cadre de la délégation client, il s'agit d'un simple appel de modèle effectué par votre code, ce qui signifie une API pour plus de 200 modèles, une seule clé pour tous les fournisseurs que vous évaluez, un basculement automatique si un fournisseur se dégrade en cours de campagne, et un choix de modèle par type d'appel : un modèle économique pour parcourir un menu SVI, un modèle plus performant dès qu'un humain décroche.

Avec la délégation Responses, OpenAI exécute ce volet et le facture à ses propres tarifs. Les deux approches sont légitimes ; elles placent simplement la décision à des endroits différents. Si vous voulez que le backend soit une décision de routage, la délégation client est le mode qui vous l'offre.

Ce que l’annonce a omis

Pour un article annonçant la GA, l’annonce manque de détails sur ce qui détermine les déploiements. Elle ne dit rien de la disponibilité régionale, de la latence, des limites de concurrence ni d’un SLA. Elle ne dit rien des obligations d’enregistrement, de divulgation ou de consentement — et l’appel sortant est le seul endroit de ce produit où ces obligations ne sont pas théoriques. Aux États-Unis, passer des appels automatisés à des consommateurs sans leur consentement constitue un problème au titre du TCPA avant même d’être un problème d’ingénierie ; dans l’UE, enregistrer un appel sans en informer la personne à l’autre bout du fil est un problème en soi. L’API vous fournit un caller_number et un point de terminaison de raccrochage. La conformité vous incombe.

« HD Voice » mérite aussi d’être traité comme une allégation plutôt qu’une spécification. La documentation d’OpenAI indique seulement que SIP négocie le format audio et ne liste aucun codec ; l’audio large bande mentionné dans l’article est donc une déclaration du fournisseur qui n’a été quantifiée nulle part publiquement. Testez-le avec votre propre opérateur avant de l’intégrer à une présentation.

Que faire avec ceci, cette semaine

Si vous exécutez déjà un agent vocal GPT-Live sur WebRTC, le chemin sortant est un second transport plutôt qu'une réécriture : une nouvelle session créée avec transport.type: "sip", un trunk qui prend en charge TLS et SDES-SRTP, et un WebSocket sideband pour surveiller la sonnerie, la réponse et le DTMF. Prévoyez une journée pour le trunk, pas pour l'agent.

Si vous êtes sur Realtime, ne planifiez pas la migration en partant du principe qu’il s’agit d’un simple changement de configuration. Lisez d’abord les sections sur la délégation et les sessions, déterminez si votre backend doit être celui d’OpenAI ou le vôtre, et seulement ensuite choisissez un partenaire — car le partenaire que vous utilisez déjà pour le trafic entrant n’est peut-être pas celui qui dispose d’un chemin sortant documenté.

Si vous hésitez encore à savoir si la voix sortante vaut la peine d’être développée, le chiffre qui compte est de 3,00 $ par heure connectée avant les frais de l’opérateur, face à un plafond strict de deux heures et une sonnerie de trois minutes. C’est assez bon marché pour être testé et assez cher pour que le temps d’attente soit une décision de conception, pas un accident. La GA a supprimé la barrière. Elle n’a pas supprimé l’arithmétique.