Amazon Connect, Twilio, NICE CXone e Avaya: quatro caminhos de mídia, dois lugares para pisar

Toda afirmação de especificação abaixo é citada da própria documentação publicada pelo fornecedor, com link. Onde não conseguimos confirmar algo, está marcado como não confirmado, em vez de preenchido, e há uma lista consolidada perto do fim. Este post também afia algo que já afirmamos forte demais sobre a Twilio; essa correção está em uma seção própria. Se qualquer parte disto estiver errada, ou mudar, nos avise e corrigiremos com uma data.

O post companheiro lê o AudioHook do Genesys Cloud da mesma maneira e encontra um protocolo que fixa a sua taxa de amostragem no sistema de tipos e um caminho de mídia sem ponto de inserção nenhum. Este cobre as outras quatro superfícies em que os nossos compradores realmente operam, e a resposta é menos uniforme do que esperávamos.

Uma pergunta, feita a cada plataforma:

Um terceiro pode receber o áudio da chamada, processá-lo e fazer com que o áudio processado seja o que o próprio bot, reconhecedor, gravação ou a outra ponta da plataforma consome?

Plataforma	Superfície	Áudio sai para você	Áudio processado de volta	Taxa documentada
Amazon Connect	Kinesis Video Streams	Sim	Não	8 kHz
Twilio	<Connect><Stream>	Sim	Sim	8000 Hz µ-law
Twilio	<Connect><ConversationRelay>	Não — apenas JSON	Não	não publicada
NICE CXone	Custom Agent Assist	Sim	Não	8 kHz µ-law
NICE CXone	Custom Virtual Agent	Sim	Apenas playback por turnos	G.711, taxa não declarada
Avaya Infinity	Real-time Contextual Media Streaming	Sim	Sim	8 kHz, ou 16 kHz em G.722

Duas dessas são posições genuínas de man-in-the-middle. O resto são taps, forks ou turnos de bot vestindo o mesmo vocabulário.

Amazon Connect: um fork de mão única, e duas coisas que todo mundo erra

Ele não é iniciado por uma API. StartContactStreaming é o candidato óbvio e é o errado — a própria referência dele diz que ele "inicia streaming de mensagens em tempo real para um novo contato de chat", e o seu único objeto de configuração é uma config de streaming de chat apontando para um endpoint SNS. É uma API de chat.

O streaming de mídia de voz é habilitado na instância e depois ligado dentro de um fluxo:

"Depois de habilitar o live media streaming, adicione os blocos Start media streaming e Stop media streaming ao seu fluxo." — habilitar live media streams

O bloco oferece duas opções — stream a partir do cliente, ou para o cliente — e se aplica apenas a voz; todo outro canal toma o ramo de erro. Até onde conseguimos encontrar, não há API pública para iniciar o streaming de mídia de voz, apenas o bloco de fluxo.

O formato é 8 kHz, e quase nada mais é publicado. Esta é a frase a citar:

"O media streaming usa o suporte multi-track do Kinesis Video Streams para que o que o cliente diz fique em uma track separada do que o cliente ouve. O áudio enviado ao Kinesis usa uma taxa de amostragem de 8 kHz." — planejar live media streams

As tracks são AUDIO_FROM_CUSTOMER e AUDIO_TO_CUSTOMER, e o guia do consumidor diz que um leitor "armazena esses dados como um arquivo PCM bruto".

Esse é todo o formato documentado. Fizemos grep nas quatro páginas de live media streaming por L16, endian, bit e codec e não obtivemos nada. O "audio/L16, 16-bit, little-endian, mono" comumente repetido não está na documentação do Amazon Connect. O único sinal de profundidade de bits em qualquer lugar do material da própria AWS é uma instrução de importação no Audacity em um repositório de demonstração — defina a codificação como PCM de 16 bits com sinal e a taxa de amostragem como 8000 Hz — o que te diz o que os bytes acabaram sendo, não qual é o contrato. Mono de dezesseis bits é fortemente implicado. Não está documentado, e não vamos escrevê-lo como se estivesse.

Note também que o Connect é o ponto fora da curva na codificação. Twilio e NICE te entregam G.711 µ-law com companding; o Connect te entrega PCM linear nos mesmos 8 kHz. Mesmo limite de banda, ruído de quantização diferente, e, se você está fazendo benchmark de um modelo contra um deles, não está fazendo benchmark contra o outro.

É mão única, e a AWS diz isso de forma oblíqua mas inconfundível. Todo verbo documentado é capturar ou consumir, não há caminho de escrita, e a página de planejamento contém isto:

"Recomendamos que você se abstenha de modificar os streams. Fazer isso pode causar comportamento inesperado."

É um stream ao vivo do qual você lê fragmentos, com uma retenção default curta. "Se você selecionar No data retention, os dados não são retidos e ficam disponíveis para consumo por apenas 5 minutos." O Connect entrega ao seu consumidor um cursor de fragmento via atributos de contato — StartFragmentNumber, StreamARN, StartTimestamp, StopTimestamp — então o seu leitor busca dentro do stream, em vez de assinar um socket. Essa é uma diferença arquitetural que vale planejar: é um pull, não um push, e o seu orçamento de latência inclui o que quer que o loop de polling do seu consumidor custe.

E as outras superfícies do Connect? Nós as checamos porque os nomes convidam à confusão:

• O Contact Lens em tempo real é transcrição, não áudio. Ele entrega segmentos Utterance por Kinesis Data Streams — "transcrições parciais... para atender a requisitos de latência ultrabaixa para assistir agentes em chamadas ao vivo". Texto, rio abaixo de um reconhecedor que você não controla.
• Os sistemas de voz externos ingerem no Contact Lens por SIPREC — a página de configuração nomeia o host que "receberá o áudio SIPREC". Isso é áudio fluindo para dentro do Connect a partir de uma plataforma de telefonia terceira, não para fora dele para processamento. A especificação de codec é deferida a guias do Amazon Chime SDK que não lemos, então o formato ali é não confirmado.
• O StartWebRTCContact retorna credenciais de reunião e de participante do Chime SDK — AudioHostUrl, SignalingUrl, JoinToken. É assim que um SDK de cliente entra na chamada como participante. Não é um cano de áudio bruto do lado do servidor.
• Os provedores de fala terceiros são o único lugar em que o Connect documenta o modelo de outra pessoa no caminho: "o Connect roteia o áudio para o provedor de speech-to-text terceiro escolhido", configurado por locale de bot, com a chave de API do provedor no Secrets Manager. Existem páginas companheiras para TTS de terceiros. Isso é seleção de fornecedor a partir de uma lista suportada, não um ponto de inserção para o seu próprio processamento.

Um alerta para qualquer um escrevendo sobre o Connect neste momento: o sumário da documentação agora carrega uma página de fim de suporte para o Amazon Connect Voice ID. Cheque o status dele antes de construir em cima.

Veredicto: não. O Kinesis Video Streams é um fork para o lado. Você pode ouvir tudo e mudar nada.

Twilio: o ponto de inserção de uso geral mais forte dos cinco

A Twilio publica o contrato de formato mais apertado de todos aqui, e verificamos estes lendo as strings, em vez de confiar em um resumo. Da referência de mensagens WebSocket:

"start.mediaFormat.encoding — A codificação dos dados no payload a seguir. O valor é sempre audio/x-mulaw. start.mediaFormat.sampleRate — O valor é sempre 8000. start.mediaFormat.channels — O valor é sempre 1."

Três "sempre". O áudio chega como base64 dentro de JSON, com um contador chunk a partir de 1 e um timestamp em milissegundos desde o início do stream. O mecanismo é um fork: "a Twilio bifurca o stream de áudio bruto da chamada e o transmite para o seu servidor WebSocket quase em tempo real", apenas sobre wss.

A seleção de track — inbound_track, outbound_track, both_tracks, com default inbound_track — pertence à forma unidirecional. Inbound é o que a Twilio recebe da outra parte; outbound é o que a Twilio gera em direção à chamada.

As duas formas são produtos diferentes com um substantivo só. Esta é a distinção que decide a sua arquitetura:

	<Start><Stream>	<Connect><Stream>
Direção	Apenas fork para fora	Bidirecional
Fluxo TwiML	"continua imediatamente com a próxima instrução TwiML"	Bloqueia: o TwiML seguinte roda apenas "depois que o seu servidor fecha a conexão WebSocket"
Criado via REST	Sim	Não
Seleção de track	Sim	Restrita à forma unidirecional na referência do substantivo

Na forma bidirecional, o áudio que você manda de volta é reproduzido na chamada:

"Media Streams bidirecionais são aqueles em que a sua aplicação WebSocket tanto recebe áudio da Twilio quanto pode enviar áudio para a Twilio, que então é reproduzido na chamada." — Media Streams

Com uma regra estrita de payload e uma armadilha dentro dela: "O payload deve ser codificado como audio/x-mulaw com taxa de amostragem de 8000 e deve ser codificado em base64", e "o media.payload não deve conter bytes de cabeçalho de tipo de arquivo de áudio. Fornecer bytes de cabeçalho faz a mídia ser transmitida incorretamente." Se você gera µ-law com uma biblioteca que escreve um cabeçalho WAV, você vai ouvir isso.

Você também ganha mark para rastrear a conclusão do playback e clear para descarregar o áudio em buffer — que é a primitiva de barge-in, e a razão de esta superfície poder suportar um modelo real de interrupção, em vez de só falar por cima de quem liga.

Veredicto: sim. O <Connect><Stream> é um man-in-the-middle genuíno: áudio de quem liga entrando, o seu áudio saindo, reproduzido na chamada, com controle de playback e de interrupção. O custo é que o <Connect> é terminal — ele é dono da chamada pela duração — então você não está decorando um fluxo, você está se tornando o fluxo.

Uma coisa que a Twilio não publica: o tamanho do frame. Procuramos especificamente, porque todo mundo cita 160 bytes e 20 ms. A Twilio documenta o contador chunk e o timestamp e não dá nenhum número de bytes por mensagem ou de milissegundos por frame em nenhuma das duas páginas de Media Streams. Se você precisa desse número, meça-o no seu próprio tráfego e rotule-o como observado.

A Twilio também não publica uma taxa de amostragem para a transcrição em tempo real. O substantivo <Transcription> documenta seleção de track e rótulos e nomeia Google ou Deepgram como engines; não encontramos taxa nenhuma na referência do substantivo nem no recurso REST.

A afirmação sobre a Twilio que vínhamos fazendo, declarada corretamente

Escrevemos, neste site, que o <ConversationRelay> da Twilio estruturalmente não pode rodar um fork de mídia <Stream> ao seu lado. Fomos procurar a frase que diz isso, e ela não existe. A correção importa mais para nós do que a conclusão, então aqui está exatamente o que a documentação contém e o que não contém.

O que o ConversationRelay é, confirmado. Ele "roteia uma chamada para o serviço Conversation Relay, fornecendo interações de voz avançadas movidas por IA". A própria Twilio executa o speech-to-text e o text-to-speech, e o seu WebSocket troca apenas JSON: na entrada, setup, prompt (carregando voicePrompt, texto já transcrito), dtmf, interrupt, error; na saída, tokens de texto, reprodução de mídia por URL, envio de dígitos, troca de idioma, fim de sessão. Nenhum áudio bruto cruza esse socket em direção alguma, e nenhum codec ou taxa de amostragem é publicado para ele em lugar nenhum que conseguimos encontrar.

O que a documentação não diz, e nós checamos com cuidado:

• Não há nenhuma regra de cardinalidade no <Connect>. A referência do substantivo documenta quatro substantivos e dois atributos e nunca declara que o <Connect> pode conter exatamente um.
• Não há nenhuma declaração de que o <Stream> é incompatível com o <ConversationRelay>. Fizemos grep na visão geral do ConversationRelay, na referência do substantivo, na página de onboarding e na referência do <Connect> por "cannot", "not supported", "limitation", "incompatible", "only one", "simultaneously" e "alongside". Todo resultado era chrome de navegação. Nenhum texto de corpo. Não há seção de limitações em nenhuma página do ConversationRelay.
• Se um fork <Start><Stream> iniciado antes de um <Connect><ConversationRelay> sobrevive é algo que não está documentado nem como funcionando nem como falhando. A Twilio simplesmente nunca aborda a combinação.

Então a afirmação precisa é uma inferência, e deveríamos tê-la rotulado como tal. O protocolo do ConversationRelay não carrega áudio, e o <Connect> é documentado como terminal, o que, juntos, significa que a Twilio precisa estar terminando e reoriginando a mídia por conta própria — não deixando nenhum lugar documentado para um processador terceiro entre quem liga e o reconhecedor. Esse raciocínio é sólido, e não é uma citação. Não rodamos o teste empírico de um <Start><Stream> precedente, e, até rodarmos, a forma honesta da afirmação é: a Twilio não documenta a combinação; a arquitetura implica que não há onde inserir um processador; nós não verificamos.

Se você rodou esse experimento em qualquer uma das direções, gostaríamos genuinamente do resultado, e o publicaremos com atribuição.

NICE CXone: a documentação não está onde você procuraria

O portal público de desenvolvedores lista dezoito famílias de API e nenhuma delas é áudio ao vivo. "Real-Time Data" é métricas. "Media Playback" é gravações. Pesquisar ali te leva a concluir que o CXone não tem superfície de áudio em tempo real, e essa conclusão está errada — a especificação vive na central de ajuda do administrador, sob integrações de agent assist.

Antes dos detalhes, um achado negativo que vale ter: não encontramos nenhum produto chamado CXone Real-Time Audio, RTMS, CXone Voice Streaming API ou CXone Open Agent Assist. Esses nomes aparecem em textos de terceiros. Eles não apareceram em uma varredura de seis mil URLs da documentação da própria NICE. Não construa uma busca sobre eles.

Custom Agent Assist Integrations é a superfície de áudio em tempo real, e a frase de formato dela é inequívoca:

"Os pacotes de áudio são codificados como áudio bruto G711 μlaw de 8 bits a 8000 kHz. Este é o mesmo formato de todo o áudio de telefonia do NiCE CXone." — recursos de agent assist

A unidade é um typo da própria NICE; 8000 Hz é claramente o que se quis dizer. A segunda metade dessa frase é a metade mais útil: este é o mesmo formato de todo o áudio de telefonia do CXone. A plataforma está te dizendo que a representação interna de mídia dela é G.711 de banda estreita, em todo lugar.

O modelo de canais é por conexão, em vez de por track, o que é incomum e fácil de errar:

"streamPerspective: RX — O áudio sendo transmitido pelo telefone do agente: o agente falando. TX — O áudio que o agente ouve: o contato falando... MIX — Contém os streams de áudio do agente e do contato. Uma conexão websocket individual contém áudio de apenas uma perspectiva."

Então uma visão estéreo de uma chamada são dois sockets, correlacionados por você, sem relógio compartilhado no payload — porque o payload não tem nada dentro além de áudio:

"Apenas dados binários fluem pelo webhook. Para interações de voz, os únicos dados enviados da chamada são bytes de áudio. Nenhum controle de chamada ou outro metadado é incluído."

Operacionalmente: pelo menos 2,000 requisições simultâneas suportadas, nenhuma expiração de conexão ou duração máxima, e um hold fecha o socket enquanto um resume abre um novo com handshake idêntico. Note também que a NICE permite um endpoint não seguro — "O endpoint de relay de áudio deve ser um websocket. Ele pode ser seguro (WSS) ou não seguro (WS)" — o que é uma escolha que você deveria fazer deliberadamente, em vez de copiando um exemplo.

Direção: apenas para fora. O que você retorna é texto e recursos renderizados na tela do agente. O áudio nunca reentra na chamada. O Agent Assist Hub, que intermedia essas integrações, portanto transmite áudio G.711 µ-law bruto para o terceiro e espera que o terceiro faça o seu próprio speech-to-text.

O Custom Virtual Agent é o mais perto que o CXone chega de retornar áudio, e ele é por turnos, em vez de streaming. Os enunciados chegam "seja como áudio no formato do codec G-711, seja como texto transcrito", e o schema de resposta carrega um campo chamado — com o erro de grafia da própria NICE intacto — base64EndcodedG711ulawWithWavHeader, descrito como o WAV codificado "a ser reproduzido no próximo turno". O transporte é REST sobre HTTPS. Isso é uma resposta de bot, não um filtro inline.

Veredicto: não para agent assist, e apenas playback por turnos para virtual agent. Você pode ouvir tudo, a 8 kHz µ-law, em sockets separados por perspectiva, e não pode mudar o que qualquer outra pessoa ouve.

Avaya: a surpresa, e o único codec de banda larga do conjunto

Esperávamos escrever que a superfície de áudio em tempo real da Avaya não é documentada publicamente. Ela é — em detalhe, sem login, e é o design mais explicitamente bidirecional dos cinco.

O Avaya Infinity publica o Real-time Contextual Media Streaming, atualizado pela última vez em 23 de julho de 2026:

"O Real-time Contextual Media Streaming é um protocolo aberto baseado em WebSocket que permite conectar os seus próprios serviços de IA diretamente ao Avaya Infinity... Nenhum SDK proprietário. Nenhum middleware. Apenas uma conexão WebSocket carregando áudio bidirecional e mensagens JSON estruturadas."

O contrato de mídia, literal:

"Codecs: PCMU (8 kHz), PCMA (8 kHz), G.722 (16 kHz) / Tamanho de frame: 20ms por default, configurável por sessão / Canais: áudio do cliente, áudio do agente, ou ambos — negociado na configuração da sessão"

Esse é o único codec de banda larga neste levantamento inteiro. Toda outra plataforma aqui, e a Genesys, documenta banda estreita e apenas banda estreita. A Avaya documentar G.722 a 16 kHz não significa que as suas chamadas serão banda larga — a perna da operadora ainda decide — mas significa que a plataforma não é a coisa que força o limite de banda, o que é uma situação diferente das outras quatro.

O modelo de direção é explícito e por serviço:

"Egress (saída) (Avaya Infinity → o seu servidor) — áudio ao vivo do endpoint, transmitido ao seu servidor para processamento... Ingress (entrada) (o seu servidor → Avaya Infinity) — áudio gerado pelo seu servidor, reproduzido para o endpoint." / "Um bot de Virtual Agent tipicamente usa os dois fluxos... Um serviço de gravação usa apenas egress. Um serviço de TTS usa apenas ingress. O seu servidor controla quais fluxos estão ativos por endpoint."

Dois modos de transporte são documentados — avaya-wss, frames binários sobre um WebSocket TLS, e avaya-wss-rtp, SRTP sobre UDP "para ambientes de latência ultrabaixa" — ambos usando JSON para controle e ambos suportando negociação dinâmica de codec. A Avaya é o cliente WebSocket e você é o servidor, então "nenhuma regra de firewall de entrada é exigida do seu lado"; a autenticação é um JWT assinado que o seu servidor valida; TLS 1.2 ou melhor, com certificados de CA pública. Um socket multiplexa vários endpoints, com frames etiquetados por ID de endpoint.

A ressalva que mantém isto honesto: apenas o Virtual Agent está no ar. A mesma página carrega uma tabela de "Coming Soon" listando Agent Assist, Recording, Text-to-Speech, Speech Recognition, Transcription e Translation como serviços futuros no mesmo protocolo. Então, hoje, o caminho bidirecional existe e a forma de usá-lo é ser o virtual agent. Não leia esta seção como "a Avaya permite inserir ASR ou gravação de terceiros hoje", porque o fornecedor não diz isso.

Mais duas notas de escopo. O Avaya Experience Platform não tem equivalente — o tratamento de mídia dele é upload e download assinados de arquivos, não áudio ao vivo; o streaming em tempo real está no Avaya Infinity, a plataforma mais nova. E não investigamos o Avaya Aura, o AES nem o Aura Media Server. Isso é uma pergunta em aberto neste post, não um achado negativo, e preferimos dizer isso a deixar o silêncio ser lido como ausência.

No que isso tudo dá

Duas conclusões independentes, e elas apontam em direções diferentes.

Na taxa de amostragem, a cunha se sustenta e é ligeiramente mais estreita do que vínhamos dizendo. Quatro das cinco superfícies documentam 8 kHz e nada mais, e a NICE diz com todas as letras que o G.711 de banda estreita é "o mesmo formato de todo o áudio de telefonia do NiCE CXone". Esse é o canal em que o dinheiro chega, e essencialmente todo modelo de aprimoramento de fala (speech enhancement) do mercado é treinado em banda larga — o DNS Challenge, a série de benchmarks contra a qual a maioria dos removedores de ruído publicados é ajustada, nunca teve uma trilha de banda estreita. Mas devíamos parar de escrever "é 8 kHz µ-law em todo lugar": o Amazon Connect é PCM linear, não companded, e a Avaya documenta G.722 a 16 kHz. Duas exceções em seis superfícies não é erro de arredondamento.

Na superfície de integração, o campo se divide de forma limpa, e não é a divisão que o marketing sugere. Toda plataforma destas te deixa ouvir. Duas delas — o <Connect><Stream> da Twilio e o RCMS do Avaya Infinity — documentam uma forma de colocar áudio de volta no caminho de mídia ao vivo. Genesys, Amazon Connect e NICE CXone não documentam, e, nas superfícies que de fato retornam áudio, estão te pedindo para ser o bot, não o filtro: o áudio que você envia vai para o humano, não para o reconhecedor de outra pessoa.

Essa distinção é a que se deve levar para uma decisão de construção. "Posso processar o áudio de quem liga antes que o reconhecedor de fala da plataforma o ouça?" é uma pergunta diferente de "posso enviar áudio para dentro desta chamada?", e apenas uma delas tem um sim em algum lugar deste levantamento — nas plataformas onde você também é dono do reconhecedor.

E é aí que as medições se tornam a restrição, em vez da plataforma. Nas nossas sete condições de telefonia, nenhum aprimorador que testamos produziu melhora significativa sobre o áudio não processado, e vários o degradaram em cinco a dez pontos de taxa de erro de palavras (WER). Os pontos de inserção são a parte fácil. Ter algo que valha a pena inserir é a parte que ninguém cujos números possamos checar resolveu — que é exatamente a lacuna para dentro da qual estamos construindo.

O que não conseguimos confirmar

• Amazon Connect: profundidade de bits, endianness e contagem de canais. 8 kHz e "raw PCM" são todo o formato publicado. Mono de dezesseis bits é implicado pelo material de demonstração da própria AWS e não é documentado.
• Amazon Connect: qualquer número de latência. Nenhum publicado em página alguma que lemos.
• Amazon Connect: o perfil de codec da ingestão SIPREC. Deferido pela AWS a guias de configuração do Amazon Chime SDK, que não lemos.
• Twilio: bytes ou milissegundos por mensagem de mídia. Não publicado. Os 160 bytes / 20 ms amplamente citados não estão na documentação da Twilio.
• Twilio: formato de áudio e taxa de amostragem do ConversationRelay. Não publicados em lugar nenhum que conseguimos encontrar, incluindo a página de configuração de voz, que cobre provedores de TTS e configurações de prosódia e nenhum codec.
• Twilio: se um fork <Start><Stream> sobrevive a um <Connect><ConversationRelay> subsequente. Não documentado em nenhuma das direções, e não testado por nós.
• Twilio: a taxa de amostragem da transcrição em tempo real. Não publicada.
• NICE CXone: a taxa de amostragem do áudio do Custom Virtual Agent. O codec é declarado como G.711 µ-law; a taxa não é declarada na página do schema.
• NICE CXone: os formatos por provedor atrás do Agent Assist Hub. A página de integrações não os reafirma; a única especificação de formato está nas páginas de integração custom.
• Avaya: a especificação do protocolo em nível de fio. A Avaya publica um PDF de especificação do protocolo, versão 1.1, que não baixamos — então o ciclo de vida de sessão e as definições de mensagens não estão verificados aqui.
• Avaya Aura, AES e Avaya Aura Media Server. Não investigados. Pergunta em aberto, não um achado negativo.

Uma nota sobre o método, porque ela muda quanto peso estes achados carregam: este levantamento foi feito percorrendo os índices de documentação dos próprios fornecedores e lendo as páginas diretamente, não por busca. Isso é mais confiável para confirmar o que um documento diz e menos confiável para provar que um documento não existe. Todo "não documentado" acima significa "não o encontramos rastreando o índice do próprio fornecedor", o que é uma afirmação mais fraca do que "o fornecedor não documenta" — e mais fraca ainda do que as citações confirmadas, que são literais.