[+] 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\nVale a pena saber duas coisas sobre esse log antes da sua primeira chamada. A mensagem connect<\/code> carrega interruptionsEnabled<\/code>: true, que \u00e9 onde voc\u00ea pode confirmar o padr\u00e3o de interrup\u00e7\u00e3o em vez de tir\u00e1-lo da refer\u00eancia de configura\u00e7\u00e3o. E a conex\u00e3o \u00e9 fechada com o c\u00f3digo 1006<\/code> quando a pessoa que ligou desliga a chamada, o que parece um fechamento anormal, mas \u00e9 como um desligamento normal aparece aqui.<\/p>\n\n\n\nUma interrup\u00e7\u00e3o (interrupt<\/code>) com reason=speech-detected<\/code> aparece em todos os turnos, porque a Sinch envia uma sempre que ouve quem est\u00e1 ligando. \u00c9 a posi\u00e7\u00e3o dela que diz algo a voc\u00ea: depois de textPlaybackStop<\/code>, ela apenas marca o in\u00edcio do turno de quem ligou, enquanto entre textPlaybackStart<\/code> e textPlaybackStop<\/code>, ela \u00e9 uma interven\u00e7\u00e3o (barge-in). Quando eu falei por cima de uma resposta, a reprodu\u00e7\u00e3o parou e a transcri\u00e7\u00e3o seguinte foi o que eu havia dito por cima:<\/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\nIsso \u00e9 uma interface de voz na frente de um agente de IA baseado em texto, sem que voc\u00ea precise lidar com um \u00fanico quadro de \u00e1udio.<\/p>\n\n\n\n
Onde o seu aplicativo fica<\/h2>\n\n\n\n
A Sinch e o servidor WebSocket trocam um pequeno protocolo JSON, com um comando por mensagem, e o server.py<\/code> lida com isso para voc\u00ea. As corre\u00e7\u00f5es de transcri\u00e7\u00e3o s\u00e3o a parte que vale a pena entender antes de voc\u00ea avan\u00e7ar em cima do exemplo.<\/p>\n\n\n\nA Sinch envia uma transcri\u00e7\u00e3o antecipada e, depois, pode enviar uma corrigida para a mesma fala com isCorrection: true<\/code>. O texto corrigido inclui o texto anterior em vez de substituir apenas a parte alterada. Isso aconteceu uma vez em tr\u00eas chamadas: Thank you.<\/code> foi seguido por Thank you.\\nOh<\/code>, that's nice.<\/code>, e ambos foram para o modelo, de modo que o agente respondeu \u00e0 mesma fala duas vezes. Decida se vai aguardar uma corre\u00e7\u00e3o, cancelar a solicita\u00e7\u00e3o em andamento ou ignorar as corre\u00e7\u00f5es totalmente.<\/p>\n\n\n\nA fronteira do aplicativo \u00e9 mais ou menos assim:<\/p>\n\n\n