[+] Connected: ('127.0.0.1', 65438)
WS << {"callHeaders":{},"callId":"01M25YACD3G61GH4Y0NQNWR4WD","interruptionsEnabled":true,...}
connect callId=01M25YACD3G61GH4Y0NQNWR4WD serviceId=YOUR_SERVICE_ID
WS >> {\"command\": \"answer\"}
WS >> {\"command\": \"text\", \"text\": \"Hello!\", \"isLast\": true, \"isInterruptible\": true}
WS << {"batchSequence":0,"command":"textPlaybackStart"}
WS << {"batchSequence":0,"command":"textPlaybackStop"}
WS << {"reason":"speech-detected","command":"interrupt"}
WS << {"sttLanguage":"en-US","text":"Hi.","isCorrection":false,"command":"text"}
STT \u2192 'Hi.'
LLM \u2190 'Hey there! How can I assist you today? If it involves voice tech or a good dad j'\u2026
WS >> {\"command\": \"text\", \"text\": \"Hey there! How can I assist you today?...\", \"isLast\": true}
WS << {"batchSequence":1,"command":"textPlaybackStart"}
WS << {"batchSequence":1,"command":"textPlaybackStop"}
[-] Connection closed (1006):
[-] Session ended callId=01M25YACD3G61GH4Y0NQNWR4WD<\/code><\/p><\/div>\r\n <\/div>\r\n\n\n\nZwei Dinge in diesem Protokoll sind vor Ihrem ersten Anruf wichtig. Die connect<\/code>-Nachricht enth\u00e4lt interruptionsEnabled<\/code>: true. Hier k\u00f6nnen Sie den Standardwert f\u00fcr Unterbrechungen \u00fcberpr\u00fcfen, anstatt ihn aus der Konfigurationsreferenz zu entnehmen. Und die Verbindung wird mit dem Code 1006<\/code> geschlossen, wenn die anrufende Person auflegt. Dies sieht wie eine abnormale Schlie\u00dfung aus, ist hier aber das normale Verhalten beim Auflegen.<\/p>\n\n\n\nEin interrupt<\/code> mit reason=speech-detected<\/code> erscheint bei jedem Wechsel, da Sinch einen sendet, sobald die anrufende Person geh\u00f6rt wird. Seine Position ist aussagekr\u00e4ftig: Nach textPlaybackStop<\/code> markiert er lediglich den Beginn des Sprechanteils der anrufenden Person, w\u00e4hrend er zwischen textPlaybackStart<\/code> und textPlaybackStop<\/code> ein Dazwischenreden darstellt. Als ich w\u00e4hrend einer Antwort gesprochen habe, wurde die Wiedergabe gestoppt. Das n\u00e4chste Transkript enthielt das, was ich dazwischengerufen hatte:<\/p>\n\n\n \r\n\r\n
WS << {"batchSequence":5,"command":"textPlaybackStart"}
WS << {"reason":"speech-detected","command":"interrupt"}
WS << {"batchSequence":5,"command":"textPlaybackStop"}
WS << {"sttLanguage":"en-US","text":"I'm going to stop you right there.",...,"command":"text"}<\/code><\/p><\/div>\r\n <\/div>\r\n\n\n\nDas ist ein Voice-Interface vor einem textbasierten KI-Agenten, ohne dass Sie selbst auch nur einen einzigen Audio-Frame verarbeiten m\u00fcssen.<\/p>\n\n\n\n
Wo sich Ihre Anwendung befindet<\/h2>\n\n\n\n
Sinch und der WebSocket-Server tauschen ein kleines JSON-Protokoll mit einem Befehl pro Nachricht aus, was die server.py<\/code> f\u00fcr Sie \u00fcbernimmt. Transkriptkorrekturen sind der Teil, den Sie verstehen sollten, bevor Sie auf dem Beispiel aufbauen.<\/p>\n\n\n\nSinch sendet ein fr\u00fches Transkript und m\u00f6glicherweise danach ein korrigiertes Transkript f\u00fcr dieselbe \u00c4u\u00dferung mit isCorrection: true<\/code>. Der korrigierte Text enth\u00e4lt den fr\u00fcheren Text, anstatt nur den ge\u00e4nderten Teil zu ersetzen. Es passierte einmal bei drei Anrufen: Auf Thank you.<\/code> folgte Thank you.\\nOh<\/code>, that's nice.<\/code>, und beide wurden an das Modell gesendet, sodass der Agent auf dieselbe \u00c4u\u00dferung zweimal antwortete. Entscheiden Sie, ob Sie auf eine Korrektur warten, die laufende Anfrage abbrechen oder Korrekturen vollst\u00e4ndig ignorieren.<\/p>\n\n\n\nDie Anwendungsgrenze sieht so aus:<\/p>\n\n\n