Telemetría SipPulse AI: cada parámetro explicado

La mayoría de los proveedores de agentes de voz no te muestra sus números. La razón es simple: los números usualmente no son buenos. La mediana de mercado de latencia de agentes de voz en 2026 está entre 1,4 y 1,7 segundos, con el 10 por ciento de las llamadas pasando los 3 segundos, mientras que la expectativa humana de conversación está más cerca de 200ms. La telemetría es la disciplina que hace visibles esos números. SipPulse AI emite cada evento de agente de voz como un webhook firmado, con latencia por etapa, contadores por llamada y payload estructurado, para que los clientes puedan canalizar los datos a cualquier stack de observabilidad y vean exactamente cómo se desempeñó cada llamada. Este post recorre cada tipo de evento, cada métrica y cómo consumirlos, con un visor de ejemplo público en nuestra página de telemetría.

Por qué la telemetría importa para agentes de voz

Un agente de voz tiene más modos de falla que un agente de chat. El usuario puede interrumpir en mitad de respuesta, la red puede perder un paquete, el STT puede reconocer mal una palabra, el LLM puede tomar 800ms más de lo esperado, el TTS puede tartamudear en una oración larga. Sin telemetría te enteras de cada uno por la queja del cliente, días después, sin capacidad de reproducir o depurar.

La observabilidad de agentes de voz da vuelta el modelo. Cada llamada emite eventos estructurados que capturan timing por etapa, identidad de modelo y estado de conversación. Agrégalos y verás tendencias. Inspecciona una sola llamada y verás exactamente qué etapa estuvo lenta. Los mismos datos alimentan dashboards de latencia, alertas sobre regresiones y pipelines de Auto QA que puntúan conversaciones después del hecho.

Cómo se entrega la telemetría: webhooks firmados

SipPulse AI no envía un dashboard incorporado al que tengas que hacer login. La telemetría se entrega como webhooks: cada evento de llamada hace POST de un payload JSON a un endpoint que tú configuras. Tú consumes los eventos en tu propio stack de observabilidad (Grafana, Datadog, un servicio personalizado, cualquier cosa que pueda recibir HTTP).

Los webhooks están firmados con HMAC usando un secreto compartido, con un guardia de timestamp contra ataques de replay. Si el timestamp es muy viejo o la firma no coincide, el evento se rechaza. Este es el patrón estándar de seguridad de webhooks y el mismo que tienes en Stripe o GitHub.

La elección arquitectónica (webhooks en lugar de una API por polling o un dashboard hospedado) es intencional. Los clientes quieren telemetría en su propio stack, con sus controles existentes de alertas, retención y acceso. Un dashboard de proveedor es un login más para el ingeniero de guardia. Un webhook es solo otra fuente de datos.

Tipos de evento: qué se dispara cuándo

Cada llamada genera un stream de eventos con estos tipos:

• voice.start_call: emitido cuando una llamada conecta. Incluye info del participante, ID de agente y timestamp
• voice.end_call: emitido cuando la llamada se desconecta. Incluye el resumen de uso por llamada con todos los agregados de latencia
• llm.completion: emitido para cada turno del LLM. Incluye prompt, respuesta, modelo, conteo de tokens y TTFT por turno
• stt.transcription: emitido a medida que los resultados de transcripción se transmiten. Incluye transcripciones parciales y finales
• tts.synthesis: emitido para cada solicitud de TTS. Incluye modelo de voz, texto y TTFB
• thread.created: emitido cuando un nuevo hilo de conversación comienza. Útil para agrupar llamadas en sesiones
• thread.closed: emitido cuando un hilo termina. Útil para análisis a nivel de sesión

El evento voice.end_call es donde vive la mayoría de la analítica agregada, porque carga el resumen de uso de la llamada completa. Los eventos granulares (llm.completion, stt.transcription, tts.synthesis) son donde ves comportamiento por turno para depurar.

Los parámetros de latencia que importan

Las métricas que vienen en el payload de voice.end_call (y en estadísticas agregadas) son las que importan para observabilidad de agentes de voz:

• llm_ttft_ms: TTFT promedio del LLM a lo largo de la llamada. El número que impulsa la latencia percibida. Objetivo: por debajo de 400ms.
• llm_latency_ms: duración total promedio del LLM por turno. Mayor que TTFT porque incluye la generación completa. Importa para tiempo total de turno.
• tts_latency_ms: TTFB promedio del TTS. El tiempo desde "TTS solicitado" hasta "primer chunk de audio disponible". Objetivo: por debajo de 150ms.
• eou_latency_ms: latencia de detección de fin de habla. Cuánto tiempo después de que el usuario deja de hablar antes de que el agente decida que el turno terminó. Objetivo: por debajo de 300ms.
• conv_latency_ms: latencia promedio de conversación, el ida y vuelta total ponderado a lo largo de la llamada. Objetivo: por debajo de 800ms.
• session_duration: duración total de la llamada en segundos. El denominador para métricas de costo y retención.

Los contadores por proveedor completan el cuadro: llm_requests y tts_requests cuentan cuántas veces se llamó a cada modelo en la sesión. El campo model identifica qué LLM y TTS estaban en uso, lo que importa cuando haces A/B test de modelos sobre los mismos flujos.

Estadísticas agregadas y contadores de llamada

El visor de telemetría de ejemplo expone estadísticas agregadas de todas las llamadas recientes:

• total_events y total_calls para volumen
• avg_llm_latency, avg_tts_latency, avg_conv_latency, avg_eou_latency, avg_llm_ttft para tendencias de latencia
• avg_duration para duración de sesión

Los agregados se calculan a partir de los mismos payloads crudos de webhook. En tu propio stack los calcularías sobre una ventana móvil (última hora, último día, últimos 7 días) y alertarías sobre regresiones. El visor muestra una ventana fija para que los visitantes vean las métricas sobre tráfico real de demo.

Seguridad y retención

La firma HMAC en cada webhook se aplica del lado del servidor. El guardia de timestamp rechaza eventos de más de unos minutos, previniendo replay. El almacenamiento subyacente del visor de ejemplo retiene eventos por 72 horas y poda automáticamente lo más viejo, lo que alcanza para depurar una regresión reciente sin volverse un almacén de datos a largo plazo. Los deployments de producción personalizan la retención para coincidir con su postura de cumplimiento (LGPD, GDPR, PCI según aplique).

Para el receptor de webhook en sí, aplican los mismos estándares: TLS para transporte, verificación HMAC antes de procesar y rate limiting contra payloads malformados.

Cómo consumir los webhooks

Nuestro visor abierto de ejemplo muestra cómo se ve consumir los webhooks de punta a punta. La página es un endpoint Next.js pequeño que:

1. Recibe el POST del webhook
2. Verifica la firma HMAC y el timestamp
3. Parsea el payload y persiste el evento en una tabla SQLite local
4. Renderiza estadísticas agregadas y una tabla de eventos recientes

La implementación es abierta. Trátalo como punto de partida, no como dashboard de producción. La mayoría de los clientes lo reemplaza con su propio pipeline que empuja eventos a Grafana, Datadog, BigQuery o cualquier stack de observabilidad que ya operan.

Para un camino aún más rápido, apunta una URL de webhook a cualquier receptor HTTP que ya tengas, valida la firma, y los eventos empiezan a fluir.

Lee también

• Evaluando agentes de voz en producción: WER, MOS, latencia
• Arquitectura de agentes de voz: STT, LLM, TTS y el presupuesto de latencia
• Turn detection, barge-in y manejo de interrupciones en agentes de voz

Conclusión

La telemetría de agentes de voz es la línea entre un proveedor que hace marketing de latencia y un proveedor que la prueba. SipPulse AI entrega eventos por llamada a tu stack vía webhooks firmados, con los parámetros por etapa que de hecho impulsan la experiencia del cliente. Visita nuestro visor de telemetría de ejemplo para ver eventos en vivo, prueba la demo para generar los tuyos o habla con el equipo para conectar telemetría a tu pipeline de observabilidad.