Telemetria SipPulse AI: cada parâmetro explicado

A maioria dos vendors de agente de voz não mostra os números. A razão é simples: os números costumam não ser bons. A mediana de mercado de latência de agente de voz em 2026 fica em 1,4 a 1,7 segundos, com 10% das chamadas passando de 3 segundos, enquanto a expectativa humana de conversa é mais perto de 200ms. Telemetria é a disciplina que torna esses números visíveis. O SipPulse AI emite todo evento de agente de voz como webhook assinado, com latência por estágio, contadores por chamada e payload estruturado, para que clientes plugem os dados em qualquer stack de observabilidade e vejam exatamente como cada chamada se comportou. Este post caminha por todo tipo de evento, toda métrica e como consumir, com um visualizador público de exemplo na nossa página de telemetria.

Por que telemetria importa para agente de voz

Um agente de voz tem mais modos de falha que um agente de chat. O usuário pode interromper no meio da resposta, a rede pode perder pacote, o STT pode reconhecer errado, o LLM pode demorar 800ms a mais que o esperado, o TTS pode tropeçar numa frase longa. Sem telemetria você descobre cada um pelo email do cliente reclamando, dias depois, sem ter como reproduzir nem depurar.

Observabilidade de agente de voz inverte o modelo. Toda chamada emite eventos estruturados que capturam timing por estágio, identidade do modelo e estado da conversa. Agregue e você vê tendências. Inspecione uma chamada e vê exatamente qual estágio ficou lento. O mesmo dado alimenta dashboards de latência, alertas de regressão e pipelines de Auto QA que pontuam conversas depois.

Como a telemetria é entregue: webhooks assinados

O SipPulse AI não ship dashboard embutido em que você precisa logar. Telemetria é entregue como webhooks: todo evento de chamada faz POST de um payload JSON no endpoint que você configura. Você consome os eventos na sua própria stack de observabilidade (Grafana, Datadog, serviço próprio, qualquer coisa que receba HTTP).

Os webhooks são assinados com HMAC usando segredo compartilhado, com guarda de timestamp contra ataque de replay. Se o timestamp está velho ou a assinatura não bate, o evento é rejeitado. Esse é o padrão de segurança de webhook que você já vê no Stripe ou no GitHub.

A escolha arquitetural (webhooks em vez de API polled ou dashboard hospedado) é proposital. Clientes querem telemetria na stack deles, com alerta, retenção e controle de acesso já existentes. Dashboard de fornecedor é mais um login para o engenheiro de plantão. Webhook é só mais uma fonte de dado.

Tipos de evento: o que dispara quando

Toda chamada gera um stream de eventos com estes tipos:

• voice.start_call: emitido quando uma chamada conecta. Inclui info de participante, ID do agente e timestamp
• voice.end_call: emitido quando a chamada desconecta. Inclui o resumo de uso por chamada com todos os agregados de latência
• llm.completion: emitido para cada turno do LLM. Inclui prompt, resposta, modelo, contagem de tokens e TTFT por turno
• stt.transcription: emitido conforme resultados de transcrição streamam. Inclui transcrições parciais e finais
• tts.synthesis: emitido para cada requisição de TTS. Inclui modelo de voz, texto e TTFB
• thread.created: emitido quando uma nova thread de conversa começa. Útil para agrupar chamadas em sessão
• thread.closed: emitido quando a thread acaba. Útil para análise no nível de sessão

O evento voice.end_call é onde a maior parte da análise agregada vive, porque carrega o resumo de uso da chamada inteira. Os eventos granulares (llm.completion, stt.transcription, tts.synthesis) são onde você vê comportamento por turno para depurar.

Os parâmetros de latência que importam

As métricas que vêm no payload de voice.end_call (e nos agregados) são as que importam para observabilidade:

• llm_ttft_ms: TTFT médio do LLM ao longo da chamada. O número que puxa latência percebida. Alvo: abaixo de 400ms.
• llm_latency_ms: duração total média do LLM por turno. Maior que TTFT porque inclui geração completa. Importa para tempo total de turno.
• tts_latency_ms: TTFB médio do TTS. Tempo de "TTS requisitado" até "primeiro chunk de áudio disponível". Alvo: abaixo de 150ms.
• eou_latency_ms: latência de detecção de fim de fala. Tempo entre o usuário parar de falar e o agente decidir que o turno acabou. Alvo: abaixo de 300ms.
• conv_latency_ms: latência média de conversa, o round trip ponderado total ao longo da chamada. Alvo: abaixo de 800ms.
• session_duration: comprimento total da chamada em segundos. Denominador para custo e métricas de retenção.

Contadores por provedor completam o quadro: llm_requests e tts_requests contam quantas vezes cada modelo foi chamado na sessão. O campo model identifica qual LLM e TTS estavam em uso, o que importa quando você faz A/B test de modelos no mesmo fluxo.

Estatísticas agregadas e contadores de chamada

O visualizador de telemetria de exemplo mostra estatísticas agregadas sobre todas as chamadas recentes:

• total_events e total_calls para volume
• avg_llm_latency, avg_tts_latency, avg_conv_latency, avg_eou_latency, avg_llm_ttft para tendência de latência
• avg_duration para duração de sessão

Os agregados são calculados a partir dos mesmos payloads brutos de webhook. Na sua stack você calcularia em janela móvel (última hora, último dia, últimos 7 dias) e alertaria em regressão. O visualizador mostra janela fixa para visitantes verem as métricas no tráfego real da demo.

Segurança e retenção

A assinatura HMAC em todo webhook é validada no servidor. A guarda de timestamp rejeita eventos com mais de alguns minutos, prevenindo replay. O storage do visualizador de exemplo retém eventos por 72 horas e poda automaticamente o que é mais antigo, o que basta para depurar regressão recente sem virar repositório de longo prazo. Deployments de produção customizam retenção para casar com a postura de compliance (LGPD, GDPR, PCI conforme aplicável).

Para o próprio receptor de webhook, valem os mesmos padrões: TLS para transporte, verificação HMAC antes de processar e rate limiting contra payload mal formado.

Como consumir os webhooks

Nosso visualizador aberto de exemplo mostra como é consumir os webhooks de ponta a ponta. A página é um endpoint Next.js pequeno que:

1. Recebe o POST do webhook
2. Verifica a assinatura HMAC e o timestamp
3. Faz parse do payload e persiste o evento numa tabela SQLite local
4. Renderiza estatísticas agregadas e tabela de eventos recentes

A implementação é aberta. Trate como ponto de partida, não como dashboard de produção. A maioria dos clientes substitui pelo próprio pipeline que empurra eventos para Grafana, Datadog, BigQuery ou qualquer stack de observabilidade que já operam.

Para um caminho ainda mais rápido, aponte uma URL de webhook para qualquer receptor HTTP que você já tem, valide a assinatura, e os eventos começam a fluir.

Leia também

• Avaliando agentes de voz em produção: WER, MOS, latência
• Arquitetura de agentes de voz: STT, LLM, TTS e o orçamento de latência
• Turn detection, barge-in e tratamento de interrupções em agentes de voz

Conclusão

Telemetria de agente de voz é a linha entre o vendor que faz marketing de latência e o vendor que prova. O SipPulse AI entrega eventos por chamada na sua stack via webhooks assinados, com os parâmetros por estágio que de fato puxam experiência do cliente. Visite o visualizador de telemetria de exemplo para ver eventos ao vivo, teste a demo para gerar os seus, ou fale com o time para plugar telemetria no seu pipeline de observabilidade.