[+] 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! \u00bfC\u00f3mo puedo ayudarte hoy? Si tiene que ver con tecnolog\u00eda de voz o un buen ch'\u2026
WS >> {\"command\": \"text\", \"text\": \"Hey there! \u00bfC\u00f3mo puedo ayudarte hoy?...\", \"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 la pena conocer dos aspectos de ese registro antes de tu primera llamada. El mensaje connect<\/code> incluye interruptionsEnabled<\/code>: true, que es donde puedes confirmar el valor predeterminado de interrupci\u00f3n en lugar de tomarlo de la referencia de configuraci\u00f3n. Adem\u00e1s, la conexi\u00f3n se cierra con el c\u00f3digo 1006<\/code> cuando quien llama cuelga; esto parece un cierre anormal, pero es el aspecto de un cuelgue normal en este contexto.<\/p>\n\n\n\nAparece un interrupt<\/code> con reason=speech-detected<\/code> en cada turno, ya que Sinch env\u00eda uno cada vez que escucha a la persona que llama. Su posici\u00f3n es lo que nos da la informaci\u00f3n: si aparece despu\u00e9s de textPlaybackStop<\/code> solo marca el inicio del turno de la persona que llama, mientras que si est\u00e1 entre textPlaybackStart<\/code> y textPlaybackStop<\/code> se trata de una intervenci\u00f3n (barge-in). Cuando habl\u00e9 por encima de una respuesta, la reproducci\u00f3n se detuvo y la siguiente transcripci\u00f3n reflej\u00f3 lo que yo hab\u00eda dicho por encima:<\/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\nSe trata de una interfaz de voz frente a un agente de IA basado en texto, sin que t\u00fa tengas que gestionar ni una sola trama de audio.<\/p>\n\n\n\n
D\u00f3nde se sit\u00faa tu aplicaci\u00f3n<\/h2>\n\n\n\n
Sinch y el servidor WebSocket intercambian un peque\u00f1o protocolo JSON, con un comando por mensaje, y server.py<\/code> lo gestiona por ti. Las correcciones de las transcripciones son la parte que vale la pena entender antes de seguir construyendo sobre el ejemplo.<\/p>\n\n\n\nSinch env\u00eda una transcripci\u00f3n inicial y luego puede enviar una corregida para la misma declaraci\u00f3n con isCorrection: true<\/code>; el texto corregido incluye el texto anterior en lugar de reemplazar solo la parte modificada. Ocurri\u00f3 una vez cada tres llamadas: Thank you.<\/code> fue seguido por Thank you.\\nOh<\/code>, that's nice.<\/code>, y ambos fueron al modelo, por lo que el agente respondi\u00f3 a la misma declaraci\u00f3n dos veces. Decide si vas a esperar a una correcci\u00f3n, cancelar la solicitud en curso o ignorar las correcciones por completo.<\/p>\n\n\n\nEl l\u00edmite de la aplicaci\u00f3n tiene este aspecto:<\/p>\n\n\n