Courtement: non, ce n’est pas un comportement attendu. Deux “inputs” qui partent dans deux conversations distinctes surviennent généralement quand deux sessions sont lancées en parallèle.
Causes documentées les plus probables
Le widget est injecté deux fois sur la page (par exemple une fois globalement et une fois au niveau d’une page), ce qui crée deux instances donc deux sessions. La mise en œuvre officielle du widget montre explicitement un guard “si déjà chargé, ne rien refaire”. Vérifiez que vous n’intégrez pas le script/embed deux fois. (elevenlabs.io)
Votre code démarre la session deux fois. Chaque appel à Conversation.startSession ouvre une nouvelle connexion (WebRTC/WebSocket) et renvoie une instance de conversation distincte; utilisez endSession avant d’en démarrer une autre. (elevenlabs.io)
Deux connexions clientes sont actives en même temps (ex. WebRTC et WebSocket, ou la page ouverte dans deux onglets). Chaque connexion au point d’accès de conversation démarre une session propre. (elevenlabs.io)
Comment confirmer rapidement
Logguez l’ID de conversation côté client via conversation.getId pour voir si deux IDs différents sont générés. (elevenlabs.io)
Surveillez “Active Calls” dans le dashboard Agents pour vérifier qu’il y a bien deux sessions en parallèle. (elevenlabs.io)
Interrogez l’API Get Conversation pour chaque conversation_id et comparez les transcriptions. (elevenlabs.io)
Correctifs recommandés
Assurez‑vous qu’un seul embed du widget est présent (mettez un guard comme dans l’exemple officiel) et qu’un seul appel à startSession est effectué par interaction utilisateur. (elevenlabs.io)
N’utilisez qu’un seul type de connexion par session (webrtc ou websocket) et terminez toujours la session courante avec endSession avant d’en créer une nouvelle. (elevenlabs.io)
Note utile: si vous voyez des “doublons” dans une seule conversation, ce peut être les transcriptions “tentative” puis “finale” envoyées via onMessage; ce n
onyx arch
tropic ridge