UStackUStack
OpenAI Realtime API icon

OpenAI Realtime API

Créez des expériences vocales temps réel et multimodales à faible latence avec l’OpenAI Realtime API : agents voix navigateur et transcription temps réel.

OpenAI Realtime API

Qu'est-ce que l'OpenAI Realtime API ?

L'OpenAI Realtime API permet une communication à faible latence entre votre application et des modèles prenant nativement en charge les interactions vocales vocales. Elle supporte également des entrées multimodales — audio, images et texte — et des sorties multimodales — audio et texte — ce qui la rend adaptée aux expériences vocales interactives.

Au-delà des agents vocaux, l'API Realtime peut être utilisée pour la transcription audio en temps réel en diffusant l'audio via une connexion WebSocket. La documentation met également en avant des points de départ recommandés (comme l'Agents SDK pour TypeScript) pour les workflows d'agents vocaux basés sur navigateur.

Fonctionnalités principales

  • Interactions vocales vocales à faible latence : Conçue pour des expériences audio conversationnelles en temps réel, et non uniquement pour des requêtes/réponses.
  • Entrées multimodales (audio, images, texte) : Permet à une session unique d'accepter différents types d'entrées selon le flux de l'application.
  • Sorties multimodales (audio et texte) : Prend en charge le retour d'audio, de texte ou des deux dans le cadre de l'interaction.
  • Méthodes de connexion multiples : Choisissez entre WebRTC (navigateur/côté client), WebSocket (côté serveur intermédiaire avec faible latence constante) et SIP (téléphonie VoIP).
  • Guides d'outils pour sessions et conversations : Inclut des conseils sur les invites, les événements du cycle de vie des conversations et la gestion du comportement des sessions côté serveur.
  • Transcription temps réel via WebSocket : Fournit un moyen de transcrire des flux audio en temps réel.

Comment utiliser l'OpenAI Realtime API

  1. Choisissez une méthode de connexion en fonction de l'environnement de votre application : WebRTC pour navigateur/client, WebSocket pour serveur/intermédiaire, ou SIP pour téléphonie VoIP.
  2. Démarrez avec une session. Pour les agents vocaux navigateur, les docs recommandent l'Agents SDK pour TypeScript, qui utilise WebRTC dans le navigateur et WebSocket sur le serveur.
  3. Créez et initialisez une session dans votre code, puis connectez-vous avec une clé API client (l'exemple utilise RealtimeAgent et RealtimeSession avec session.connect).
  4. Interagissez avec le modèle via des événements. Après connexion, utilisez les guides fournis pour les invites/orientation, la gestion du cycle de vie des conversations et (si nécessaire) le contrôle côté serveur via webhooks.

La documentation mentionne également les détails de migration GA (voir FAQ) qui affectent l'authentification des requêtes Realtime.

Cas d'usage

  • Agent vocal basé sur navigateur avec vocal-vocal : Utilisez WebRTC (souvent via l'Agents SDK pour TypeScript) pour connecter un microphone et une sortie audio en vue d'une conversation interactive.
  • Assistant temps réel avec serveur intermédiaire : Utilisez une connexion WebSocket depuis un niveau intermédiaire pour une réseau à faible latence constante et une gestion centralisée des sessions.
  • Intégration VoIP/téléphonie : Connectez-vous via SIP lorsque votre déploiement cible est un environnement de téléphonie plutôt qu'un navigateur web.
  • Transcription audio temps réel : Diffusez l'audio vers un flux de transcription Realtime via WebSocket pour recevoir les résultats de transcription pendant l'envoi de l'audio.
  • Interaction multimodale : Acceptez de l'audio avec des images et du texte dans une session temps réel unique, puis retournez audio, texte ou les deux.

FAQ

Ai-je besoin de l'en-tête beta avec l'API Realtime GA ?

Pour les requêtes GA, la documentation indique que l'en-tête OpenAI-Beta: realtime=v1 doit être supprimé. Si vous souhaitez conserver le comportement beta, continuez à inclure cet en-tête.

Comment générer des identifiants pour les sessions Realtime côté client (navigateur) ?

Dans l'interface GA, les docs décrivent un unique point de terminaison REST — POST /v1/realtime/client_secrets — pour générer des clés utilisées pour initialiser une connexion WebRTC ou WebSocket depuis les clients. L'exemple montre la création d'une configuration de session et son envoi à ce point de terminaison.

En quoi WebRTC et WebSocket diffèrent-ils en termes d'environnement d'exécution ?

La documentation positionne WebRTC comme idéal pour les interactions navigateur/côté client, tandis que WebSocket est idéal pour les applications serveur intermédiaires avec connexions réseau à faible latence constante.

Quelle est la modification d'URL pour la récupération SDP WebRTC ?

Lors de l'initialisation d'une session WebRTC dans le navigateur, les docs indiquent que l'URL pour obtenir les informations de session distante via SDP est désormais /v1/realtime/calls.

Puis-je utiliser l'API Realtime pour la transcription sans comportement complet d'agent vocal ?

Oui. La documentation met spécifiquement en avant la transcription audio temps réel en transcrivant des flux audio en temps réel via une connexion WebSocket.

Alternatives

  • Utilisez le SDK Agents pour TypeScript sans tout construire directement sur les primitives Realtime : Cela vous permet de vous concentrer sur l'orchestration des agents vocaux tout en exploitant Realtime en arrière-plan pour la connectivité navigateur (WebRTC) et serveur (WebSocket).
  • Construisez un pipeline de transcription requête/réponse au lieu du streaming : Si votre application ne nécessite pas de gestion audio temps réel, un flux de transcription non temps réel évite l'approche de session événementielle décrite pour Realtime.
  • Autres approches de communication temps réel pour la voix : Si vous avez besoin de flux spécifiques à la téléphonie, l'intégration basée sur SIP est une option parmi les méthodes de connexion Realtime ; sinon, choisissez entre WebRTC (navigateur) et WebSocket (serveur) selon le déploiement.
  • Chat multimodal avec des endpoints non temps réel : Si les exigences de latence sont moins strictes que la « communication à faible latence », une approche de chat multimodal non temps réel peut convenir, bien qu'elle ne suive pas le même flux de session streaming/événementiel décrit dans la doc Realtime.