Amazon Connect, Twilio, NICE CXone y Avaya: cuatro rutas de medios, dos lugares donde apoyarse

Cada afirmación sobre especificaciones que aparece abajo está citada de la propia documentación publicada del proveedor y enlazada. Donde no pudimos confirmar algo, está marcado como no confirmado en lugar de rellenado, y hay una lista consolidada cerca del final. Este post también afina algo que anteriormente hemos afirmado con demasiada fuerza sobre Twilio; esa corrección tiene su propia sección. Si algo de esto está mal o cambia, dínoslo y lo corregiremos con fecha.

El post complementario lee Genesys Cloud AudioHook de la misma manera y encuentra un protocolo que fija su frecuencia de muestreo en el sistema de tipos y una ruta de medios sin ningún punto de inserción dentro. Este cubre las otras cuatro superficies en las que realmente operan nuestros compradores, y la respuesta es menos uniforme de lo que esperábamos.

Una pregunta, hecha a cada plataforma:

¿Puede un tercero recibir el audio de la llamada, procesarlo, y que el audio procesado sea lo que consume el propio bot, reconocedor, grabación o extremo remoto de la plataforma?

Plataforma	Superficie	Audio de salida hacia ti	Audio procesado de vuelta	Frecuencia documentada
Amazon Connect	Kinesis Video Streams	Sí	No	8 kHz
Twilio	<Connect><Stream>	Sí	Sí	8000 Hz µ-law
Twilio	<Connect><ConversationRelay>	No — solo JSON	No	no publicada
NICE CXone	Custom Agent Assist	Sí	No	8 kHz µ-law
NICE CXone	Custom Virtual Agent	Sí	Solo reproducción por turnos	G.711, frecuencia no declarada
Avaya Infinity	Real-time Contextual Media Streaming	Sí	Sí	8 kHz, o 16 kHz con G.722

Dos de estas son posiciones genuinas de man-in-the-middle. El resto son taps, bifurcaciones o turnos de bot vestidos con el mismo vocabulario.

Amazon Connect: una bifurcación unidireccional, y dos cosas en las que todo el mundo se equivoca

No se inicia con una API. StartContactStreaming es el candidato obvio y es el equivocado — su propia referencia dice que «inicia el streaming de mensajes en tiempo real para un nuevo contacto de chat», y su único objeto de configuración es una configuración de streaming de chat que apunta a un endpoint de SNS. Es una API de chat.

El streaming de medios de voz se habilita a nivel de instancia y luego se activa dentro de un flujo:

«Después de habilitar el streaming de medios en vivo, añade bloques Start media streaming y Stop media streaming a tu flujo.» — habilitar streams de medios en vivo

El bloque ofrece dos opciones — transmitir desde el cliente, o hacia el cliente — y aplica solo a voz; cualquier otro canal toma la rama de error. Hasta donde hemos podido encontrar, no hay ninguna API pública para iniciar el streaming de medios de voz, solo el bloque de flujo.

El formato es 8 kHz, y casi nada más está publicado. Esta es la frase que citar:

«El streaming de medios usa el soporte multipista de Kinesis Video Streams de modo que lo que el cliente dice va en una pista separada de lo que el cliente oye. El audio enviado a Kinesis usa una frecuencia de muestreo de 8 kHz.» — planificar streams de medios en vivo

Las pistas son AUDIO_FROM_CUSTOMER y AUDIO_TO_CUSTOMER, y la guía del consumidor dice que un lector «almacena estos datos como un fichero PCM crudo».

Ese es todo el formato documentado. Pasamos un grep por las cuatro páginas de streaming de medios en vivo buscando L16, endian, bit y codec y no obtuvimos nada. El «audio/L16, 16-bit, little-endian, mono» que tanto se repite no está en la documentación de Amazon Connect. La única señal de profundidad de bits en todo el material propio de AWS es una instrucción de importación de Audacity en un repositorio de demo — fija la codificación a PCM con signo de 16-bit y la frecuencia de muestreo a 8000 Hz — que te dice lo que los bytes resultaron ser, no cuál es el contrato. El mono de dieciséis bits está fuertemente implicado. No está documentado, y no vamos a escribirlo como si lo estuviera.

Nota también que Connect es la excepción en codificación. Twilio y NICE te entregan ambos G.711 µ-law compandido; Connect te entrega PCM lineal a los mismos 8 kHz. Mismo límite de banda, distinto ruido de cuantización, y si estás evaluando un modelo contra uno de ellos no lo estás evaluando contra el otro.

Es unidireccional, y AWS lo dice de forma oblicua pero inconfundible. Cada verbo documentado es capturar o consumir, no hay ruta de escritura, y la página de planificación contiene esto:

«Recomendamos que te abstengas de modificar los streams. Hacerlo puede causar comportamiento inesperado.»

Es un stream en vivo del que lees fragmentos, con una retención por defecto corta. «Si seleccionas Sin retención de datos, los datos no se retienen y están disponibles para consumirse durante solo 5 minutos.» Connect le entrega a tu consumidor un cursor de fragmento a través de los atributos del contacto — StartFragmentNumber, StreamARN, StartTimestamp, StopTimestamp — de modo que tu lector busca dentro del stream en lugar de suscribirse a un socket. Esa es una diferencia arquitectónica que conviene planificar: es un pull, no un push, y tu presupuesto de latencia incluye lo que cueste el bucle de sondeo de tu consumidor.

¿Qué hay de las otras superficies de Connect? Las comprobamos porque los nombres invitan a la confusión:

• Contact Lens en tiempo real son transcripciones, no audio. Entrega segmentos Utterance sobre Kinesis Data Streams — «transcripciones parciales... para cumplir requisitos de latencia ultrabaja para asistir a agentes en llamadas en vivo». Texto, aguas abajo de un reconocedor que no controlas.
• External voice systems ingiere hacia Contact Lens sobre SIPREC — la página de configuración nombra el host que «recibirá el audio SIPREC». Esto es audio que fluye hacia dentro de Connect desde una plataforma de telefonía de terceros, no hacia fuera para procesarlo. La especificación del códec se delega en guías del SDK de Amazon Chime que no leímos, así que el formato ahí queda sin confirmar.
• StartWebRTCContact devuelve credenciales de reunión y de asistente del Chime SDK — AudioHostUrl, SignalingUrl, JoinToken. Así es como un SDK de cliente se une a la llamada como participante. No es una tubería de audio crudo del lado del servidor.
• Third-party speech providers es el único lugar donde Connect documenta el modelo de otro en la ruta: «Connect enruta el audio al proveedor de speech-to-text de terceros elegido», configurado por locale del bot con la clave de API del proveedor en Secrets Manager. Existen páginas complementarias para TTS de terceros. Esto es selección de proveedor de una lista soportada, no un punto de inserción para tu propio procesamiento.

Una señal para cualquiera que escriba sobre Connect en este momento: la tabla de contenidos de la documentación lleva ahora una página de fin de soporte para Amazon Connect Voice ID. Comprueba su estado antes de construir sobre él.

Veredicto: no. Kinesis Video Streams es una bifurcación hacia un lado. Puedes escucharlo todo y no cambiar nada.

Twilio: el punto de inserción de propósito general más fuerte de los cinco

Twilio publica el contrato de formato más estricto de todos los de aquí, y lo verificamos leyendo las cadenas en lugar de fiarnos de un resumen. De la referencia de mensajes WebSocket:

«start.mediaFormat.encoding — La codificación de los datos del payload entrante. El valor es siempre audio/x-mulaw. start.mediaFormat.sampleRate — El valor es siempre 8000. start.mediaFormat.channels — El valor es siempre 1.»

Tres «siempre». El audio llega como base64 dentro de JSON, con un contador chunk desde 1 y un timestamp en milisegundos desde el inicio del stream. El mecanismo es una bifurcación: «Twilio bifurca el stream de audio crudo de la llamada y lo transmite a tu servidor WebSocket casi en tiempo real», solo sobre wss.

La selección de pista — inbound_track, outbound_track, both_tracks, con inbound_track por defecto — pertenece a la forma unidireccional. Inbound es lo que Twilio recibe de la otra parte; outbound es lo que Twilio genera hacia la llamada.

Las dos formas son productos distintos con un mismo sustantivo. Esta es la distinción que decide tu arquitectura:

	<Start><Stream>	<Connect><Stream>
Dirección	Solo bifurcación de salida	Bidireccional
Flujo TwiML	«continúa inmediatamente con la siguiente instrucción TwiML»	Bloquea: el TwiML posterior corre solo «después de que tu servidor cierre la conexión WebSocket»
Creable vía REST	Sí	No
Selección de pista	Sí	Limitada a la forma unidireccional en la referencia del noun

Para la forma bidireccional, el audio que devuelves se reproduce en la llamada:

«Los Media Streams bidireccionales son aquellos en los que tu aplicación WebSocket tanto recibe audio de Twilio como puede enviar audio a Twilio, que entonces se reproduce en la llamada.» — Media Streams

Con una regla estricta de payload y una trampa dentro: «El payload debe estar codificado como audio/x-mulaw con una frecuencia de muestreo de 8000 y debe estar codificado en base64», y «el media.payload no debe contener bytes de cabecera de tipo de fichero de audio. Proporcionar bytes de cabecera hace que los medios se transmitan incorrectamente.» Si generas µ-law con una biblioteca que escribe una cabecera WAV, lo oirás.

También tienes mark para el seguimiento de la finalización de la reproducción y clear para vaciar el audio acumulado — que es la primitiva del barge-in, y la razón de que esta superficie pueda soportar un modelo de interrupción real en lugar de simplemente hablar por encima del llamante.

Veredicto: sí. <Connect><Stream> es un man-in-the-middle genuino: audio del llamante hacia dentro, tu audio hacia fuera, reproducido en la llamada, con control de reproducción y de interrupción. El coste es que <Connect> es terminal — es dueño de la llamada mientras dure — así que no estás decorando un flujo, te estás convirtiendo en él.

Una cosa que Twilio no publica: el tamaño de frame. Lo buscamos específicamente, porque todo el mundo cita 160 bytes y 20 ms. Twilio documenta el contador chunk y el timestamp y no da ninguna cifra de bytes por mensaje ni de milisegundos por frame en ninguna de las dos páginas de Media Streams. Si necesitas ese número, mídelo en tu propio tráfico y etiquétalo como observado.

Twilio tampoco publica una frecuencia de muestreo para la transcripción en tiempo real. El noun <Transcription> documenta selección de pista y etiquetas y nombra a Google o Deepgram como motores; no encontramos ninguna frecuencia ni en la referencia del noun ni en el recurso REST.

La afirmación sobre Twilio que veníamos haciendo, enunciada correctamente

Hemos escrito, en este sitio, que el <ConversationRelay> de Twilio no puede, estructuralmente, ejecutar una bifurcación de medios <Stream> a su lado. Fuimos a buscar la frase que lo dice, y no existe. La corrección nos importa más que la conclusión, así que aquí está exactamente lo que la documentación contiene y lo que no.

Qué es ConversationRelay, confirmado. «Enruta una llamada al servicio Conversation Relay, proporcionando interacciones de voz avanzadas impulsadas por IA». Twilio realiza él mismo el speech-to-text y el text-to-speech, y tu WebSocket intercambia solo JSON: de entrada setup, prompt (que lleva voicePrompt, texto ya transcrito), dtmf, interrupt, error; de salida tokens de texto, reproducir medios por URL, enviar dígitos, cambiar de idioma, terminar la sesión. Ningún audio crudo cruza ese socket en ninguna dirección, y no se publica códec ni frecuencia de muestreo para él en ningún sitio que pudiéramos encontrar.

Lo que la documentación no dice, y lo comprobamos con cuidado:

• No hay ninguna regla de cardinalidad sobre <Connect>. La referencia del noun documenta cuatro nouns y dos atributos y nunca afirma que <Connect> pueda contener exactamente uno.
• No hay ninguna afirmación de que <Stream> sea incompatible con <ConversationRelay>. Pasamos un grep por la vista general de ConversationRelay, la referencia del noun, la página de onboarding y la referencia de <Connect> buscando «cannot», «not supported», «limitation», «incompatible», «only one», «simultaneously» y «alongside». Cada coincidencia era cromo de navegación. Nada de texto de cuerpo. No hay sección de limitaciones en ninguna página de ConversationRelay.
• Si una bifurcación <Start><Stream> iniciada antes de un <Connect><ConversationRelay> sobrevive no está documentado ni como que funciona ni como que falla. Twilio simplemente nunca aborda la combinación.

Así que la afirmación exacta es una inferencia, y deberíamos haberla etiquetado como tal. El protocolo de ConversationRelay no transporta audio, y <Connect> está documentado como terminal, lo que en conjunto significa que Twilio tiene que estar terminando y reoriginando los medios él mismo — sin dejar ningún lugar documentado para un procesador de terceros entre el llamante y el reconocedor. Ese razonamiento es sólido y no es una cita. No hemos corrido la prueba empírica de un <Start><Stream> previo, y hasta que lo hagamos, la forma honesta de la afirmación es: Twilio no documenta la combinación; la arquitectura implica que no hay dónde insertar un procesador; no lo hemos verificado.

Si has corrido ese experimento en cualquiera de los dos sentidos, nos gustaría genuinamente conocer el resultado, y lo publicaremos con atribución.

NICE CXone: la documentación no está donde la buscarías

El portal público de desarrolladores lista dieciocho familias de API y ninguna de ellas es audio en vivo. «Real-Time Data» son métricas. «Media Playback» son grabaciones. Buscar ahí te lleva a concluir que CXone no tiene superficie de audio en tiempo real, y esa conclusión es errónea — la especificación vive en el centro de ayuda del administrador, bajo las integraciones de asistencia al agente.

Antes de los detalles, un hallazgo negativo que conviene tener: no encontramos ningún producto llamado CXone Real-Time Audio, RTMS, CXone Voice Streaming API ni CXone Open Agent Assist. Esos nombres aparecen en textos de terceros. No aparecieron en un barrido de seis mil URLs de la propia documentación de NICE. No construyas una búsqueda sobre ellos.

Custom Agent Assist Integrations es la superficie de audio en tiempo real, y su frase de formato es inequívoca:

«Los paquetes de audio están codificados como audio crudo G711 μlaw de 8-bit a 8000 kHz. Este es el mismo formato que todo el audio de telefonía de NiCE CXone.» — recursos de agent assist

La unidad es una errata de la propia NICE; claramente se quiere decir 8000 Hz. La segunda mitad de esa frase es la mitad más útil: este es el mismo formato que todo el audio de telefonía de CXone. La plataforma te está diciendo que su representación interna de medios es G.711 de banda estrecha, en todas partes.

El modelo de canales es por conexión y no por pista, lo que es inusual y fácil de hacer mal:

«streamPerspective: RX — El audio que transmite el teléfono del agente: el agente hablando. TX — El audio que el agente oye: el contacto hablando... MIX — Contiene los streams de audio del agente y del contacto. Una conexión websocket individual solo contiene audio de una perspectiva.»

Así que una vista estéreo de una llamada son dos sockets, correlacionados por ti, sin reloj compartido en el payload — porque el payload no tiene nada dentro salvo audio:

«Por el webhook solo fluyen datos binarios. Para las interacciones de voz, los únicos datos enviados desde la llamada son bytes de audio. No se incluye control de llamada ni ningún otro metadato.»

Operativamente: al menos 2,000 peticiones concurrentes soportadas, sin expiración de conexión ni duración máxima, y una retención (hold) cierra el socket mientras que una reanudación abre uno nuevo con un handshake idéntico. Nota también que NICE permite un endpoint sin asegurar — «El endpoint de relé de audio debe ser un websocket. Puede ser seguro (WSS) o no seguro (WS)» — que es una elección que deberías tomar deliberadamente y no copiando un ejemplo.

Dirección: solo salida. Lo que devuelves es texto y recursos renderizados en la pantalla del agente. El audio nunca vuelve a entrar en la llamada. El Agent Assist Hub, que hace de intermediario de estas integraciones, transmite por tanto audio G.711 µ-law crudo al tercero y espera que el tercero haga su propio speech-to-text.

Custom Virtual Agent es lo más cerca que CXone llega de devolver audio, y es por turnos y no en streaming. Los enunciados llegan «bien como audio en el formato del códec G-711 o bien como texto transcrito», y el esquema de respuesta lleva un campo llamado — con la falta de ortografía de la propia NICE intacta — base64EndcodedG711ulawWithWavHeader, descrito como el WAV codificado «para reproducirse en el siguiente turno». El transporte es REST sobre HTTPS. Eso es una respuesta de bot, no un filtro en línea.

Veredicto: no para agent assist, y solo reproducción por turnos para virtual agent. Puedes oírlo todo, a 8 kHz µ-law, en sockets separados por perspectiva, y no puedes cambiar lo que cualquier otro oye.

Avaya: la sorpresa, y el único códec de banda ancha del conjunto

Esperábamos escribir que la superficie de audio en tiempo real de Avaya no está documentada públicamente. Lo está — en detalle, sin login, y es el diseño más explícitamente bidireccional de los cinco.

Avaya Infinity publica Real-time Contextual Media Streaming, actualizado por última vez el 23 de julio de 2026:

«Real-time Contextual Media Streaming es un protocolo abierto basado en WebSocket que te permite conectar tus propios servicios de IA directamente a Avaya Infinity... Sin SDKs propietarios. Sin middleware. Solo una conexión WebSocket que transporta audio bidireccional y mensajes JSON estructurados.»

El contrato de medios, literal:

«Códecs: PCMU (8 kHz), PCMA (8 kHz), G.722 (16 kHz) / Tamaño de frame: 20ms por defecto, configurable por sesión / Canales: audio del cliente, audio del agente, o ambos — negociado al establecer la sesión»

Ese es el único códec de banda ancha de todo este estudio. Todas las demás plataformas de aquí, y Genesys, documentan banda estrecha y solo banda estrecha. Que Avaya documente G.722 a 16 kHz no significa que tus llamadas vayan a ser de banda ancha — la pata del operador sigue decidiendo — pero significa que la plataforma no es la cosa que fuerza el límite de banda, lo que es una situación distinta de la de las otras cuatro.

El modelo de dirección es explícito y por servicio:

«Egress (salida) (Avaya Infinity → tu servidor) — audio en vivo desde el endpoint, transmitido a tu servidor para su procesamiento... Ingress (entrada) (tu servidor → Avaya Infinity) — audio generado por tu servidor, reproducido hacia el endpoint.» / «Un bot de Virtual Agent típicamente usa ambos flujos... Un servicio de grabación usa solo egress. Un servicio de TTS usa solo ingress. Tu servidor controla qué flujos están activos por endpoint.»

Se documentan dos modos de transporte — avaya-wss, frames binarios sobre un WebSocket TLS, y avaya-wss-rtp, SRTP sobre UDP «para entornos de latencia ultrabaja» — ambos usando JSON para el control y ambos soportando negociación dinámica de códec. Avaya es el cliente WebSocket y tú eres el servidor, así que «no se requieren reglas de firewall de entrada de tu lado»; la autenticación es un JWT firmado que tu servidor valida; TLS 1.2 o mejor con certificados de CA pública. Un solo socket multiplexa múltiples endpoints con frames etiquetados por ID de endpoint.

La salvedad que mantiene esto honesto: solo Virtual Agent está en vivo. La misma página lleva una tabla de «Coming Soon» que lista Agent Assist, Recording, Text-to-Speech, Speech Recognition, Transcription y Translation como servicios futuros sobre el mismo protocolo. Así que hoy, la ruta bidireccional existe y la manera de usarla es ser el agente virtual. No leas esta sección como «Avaya te deja insertar ASR o grabación de terceros hoy», porque el proveedor no dice eso.

Dos notas más de alcance. Avaya Experience Platform no tiene equivalente — su manejo de medios es subida y descarga firmadas de ficheros, no audio en vivo; el streaming en tiempo real está en Avaya Infinity, la plataforma más nueva. Y no investigamos en absoluto Avaya Aura, AES ni Aura Media Server. Eso es una pregunta abierta de este post, no un hallazgo negativo, y preferimos decirlo antes que dejar que el silencio se lea como ausencia.

Lo que esto suma

Dos conclusiones independientes, y apuntan en direcciones distintas.

Sobre la frecuencia de muestreo, la cuña se sostiene y es ligeramente más estrecha de lo que veníamos diciendo. Cuatro de las cinco superficies documentan 8 kHz y nada más, y NICE dice sin rodeos que el G.711 de banda estrecha es «el mismo formato que todo el audio de telefonía de NiCE CXone». Ese es el canal por el que llega el dinero, y prácticamente todos los modelos de mejora de voz (speech enhancement) del mercado están entrenados en banda ancha — el DNS Challenge, la serie de benchmarks contra la que se afinan la mayoría de los supresores publicados, nunca tuvo una pista de banda estrecha. Pero deberíamos dejar de escribir «es 8 kHz µ-law en todas partes»: Amazon Connect es PCM lineal, no compandido, y Avaya documenta G.722 a 16 kHz. Dos excepciones de seis superficies no son un error de redondeo.

Sobre la superficie de integración, el campo se divide limpiamente, y no es la división que el marketing sugiere. Todas y cada una de estas plataformas te dejarán escuchar. Dos de ellas — el <Connect><Stream> de Twilio y el RCMS de Avaya Infinity — documentan una manera de devolver audio a la ruta de medios en vivo. Genesys, Amazon Connect y NICE CXone no, y en las superficies que sí devuelven audio se te está pidiendo que seas el bot, no el filtro: el audio que envías va al humano, no al reconocedor de otro.

Esa distinción es la que hay que llevarse a una decisión de construcción. «¿Puedo procesar el audio del llamante antes de que lo oiga el reconocedor de voz de la plataforma?» es una pregunta distinta de «¿puedo enviar audio a esta llamada?», y solo una de ellas tiene un sí en algún lugar de este estudio — en las plataformas donde además eres dueño del reconocedor.

Que es donde las mediciones se convierten en la restricción, en lugar de la plataforma. En nuestras siete condiciones de telefonía, ningún mejorador que probamos produjo una mejora significativa sobre el audio sin procesar, y varios lo degradaron en cinco a diez puntos de tasa de error de palabras (WER). Los puntos de inserción son la parte fácil. Tener algo que valga la pena insertar es la parte que nadie cuyos números podamos comprobar ha resuelto — que es exactamente la brecha hacia la que estamos construyendo.

Lo que no pudimos confirmar

• Amazon Connect: profundidad de bits, endianness y número de canales. 8 kHz y «PCM crudo» es todo el formato publicado. El mono de dieciséis bits está implicado por el propio material de demo de AWS y no está documentado.
• Amazon Connect: alguna cifra de latencia. Ninguna publicada en ninguna página que leímos.
• Amazon Connect: el perfil de códec de la ingesta SIPREC. Delegado por AWS a guías de configuración del Amazon Chime SDK, que no leímos.
• Twilio: bytes o milisegundos por mensaje de medios. No publicado. Los 160 bytes / 20 ms que tanto se citan no están en la documentación de Twilio.
• Twilio: el formato de audio y la frecuencia de muestreo de ConversationRelay. No publicados en ningún sitio que pudiéramos encontrar, incluida la página de configuración de voz, que cubre proveedores de TTS y ajustes de prosodia y ningún códec.
• Twilio: si una bifurcación <Start><Stream> sobrevive a un <Connect><ConversationRelay> posterior. Sin documentar en ambos sentidos, y sin probar por nuestra parte.
• Twilio: la frecuencia de muestreo de la transcripción en tiempo real. No publicada.
• NICE CXone: la frecuencia de muestreo del audio de Custom Virtual Agent. El códec se declara como G.711 µ-law; la frecuencia no se declara en la página del esquema.
• NICE CXone: los formatos por proveedor detrás del Agent Assist Hub. La página de integraciones no los reitera; la única especificación de formato está en las páginas de integración custom.
• Avaya: la especificación del protocolo a nivel de cable. Avaya publica un PDF de especificación del protocolo, versión 1.1, que no descargamos — así que el ciclo de vida de sesión y las definiciones de mensajes quedan aquí sin verificar.
• Avaya Aura, AES y Avaya Aura Media Server. No investigados. Pregunta abierta, no hallazgo negativo.

Una nota sobre el método, porque cambia cuánto peso cargan estos hallazgos: este estudio se hizo recorriendo los índices de documentación propiedad de los proveedores y leyendo las páginas directamente, no buscando. Eso es más fiable para confirmar lo que un documento dice y menos fiable para demostrar que un documento no existe. Cada «no documentado» de arriba significa «no lo encontramos rastreando el índice propio del proveedor», que es una afirmación más débil que «el proveedor no lo documenta» — y más débil todavía que las citas confirmadas, que son literales.