Experiencia · Telefonía y contact center
Construimos la central: trunkes SIP, reglas de enrutamiento por horario, menús IVR leídos desde la base de datos, colas de espera, transferencia a una persona, grabación y análisis de las llamadas. La llamada se convierte en un registro con transcript y resumen, no en un recuerdo.
Ya construidoTres implementaciones propias, citadas abajo. (1) La capa Asterisk de la plataforma Kallina: 5.522 líneas de configuración de dialplan, scripts AGI y puentes de audio en `asterisk/`, más plantillas de trunk generadas automáticamente por número. (2) `asterisk-manager` — un servicio aparte que administra las colas, los trunks y el flujo RTP mediante la interfaz de gestión de la central. (3) El middleware para la central virtual de un operador, que se ejecutó en producción: el commit de reconciliación del 14 de julio de 2026 incorpora al repositorio código que se había ejecutado en el servidor y estaba con unos 40 días de adelanto respecto al git. La reserva, dicha antes de que preguntes: el host SIP por el que pasan nuestras líneas de prueba no responde — verificado hoy, 06.09.2026, sin respuesta al ping y sin respuesta por HTTP. No presentamos un número de demostración al que puedas llamar ahora, porque no podríamos levantarlo ante ti.
Entre tu operador de telefonía y quien responde realmente — una persona o un agente vocal — tiene que existir una capa que tome decisiones. Quién recibe la llamada a las 23:40. Qué ocurre si nadie responde. A dónde va la llamada cuando el cliente pide «una persona». Qué queda de la conversación después de que se cuelga. Esa capa es una central, y nosotros la construimos para que sea del negocio, no del proveedor de voz: si mañana cambias el motor del agente, las reglas de enrutamiento, las colas y el historial se quedan contigo.
Concretamente, qué hemos construido: doce archivos de dialplan — producción, IVR, cola, transferencia, voicemail, redirección, llamadas salientes con agente — cuatro scripts AGI en Python y dos puentes de audio, en total 5.522 líneas. El motor de IVR no tiene los menús escritos en el archivo: los lee de la base mediante un script AGI y devuelve una de seis decisiones — hacia un agente, hacia otro menú, hacia una cola, transferencia a un número externo, mensaje final, o cierre. Las colas se nombran según su identificador y no tienen miembros escritos en la configuración: se añaden y se quitan desde fuera, mediante la interfaz de gestión, lo que significa que un operador puede entrar o salir de la cola sin reiniciar la central.
El enrutamiento tiene reglas reales, no un solo «llama aquí»: horarios de atención y zona horaria, horario nocturno del tipo 22:00 → 06:00, y coincidencia por prioridad — el encabezado SIP `Diversion`, que lleva el número original desde el que se desvió la llamada, luego el número propio, luego la regla de reserva. Los trunks se generan por número, con un nombre construido a partir del proveedor y el número, por una función de configuración — no escritos a mano en cada nueva línea.
Lo que sale de la llamada es tan importante como la llamada. Para la línea vinculada a la central virtual de un operador construimos un middleware en Python que consulta la lista de registros cada minuto, con una reconciliación amplia cada seis horas para que un corte de red no pierda nada, y un escaneo cada tres minutos de las llamadas perdidas — esas no tienen registro y, de otro modo, serían completamente invisibles. Cada registro se descarga, se transcribe, se analiza y se refleja en el análisis de llamadas, y la llamada perdida se convierte en una alerta. La idempotencia está en un set de Redis, para que el mismo registro no se procese dos veces.
Qué incluye
Las plantillas de trunk están parametrizadas y completadas por una función de configuración, con nombre formado por el proveedor y el número. En la plantilla están escritos el transporte, los códecs permitidos, el tratamiento NAT, el modo DTMF y la autenticación. La consecuencia práctica: el décimo número se conecta igual que el primero, y las diferencias entre operadores están en un solo lugar.
Horarios de atención y zona horaria, horario nocturno del tipo 22:00 → 06:00, coincidencia por prioridad: el encabezado SIP `Diversion` (el número desde el que se desvió), luego el número propio, luego la regla de reserva. La búsqueda de la regla se hace mediante un script AGI que consulta la plataforma durante la llamada, con su propio tiempo de espera — así que una regla cambiada en la interfaz se aplica en la siguiente llamada, sin reinicio.
Hacia el agente vocal, el audio pasa por un puente que convierte el códec en ambos sentidos, `g711_ulaw` ↔ `PCM16`. Hacia las personas, la llamada entra en una cola administrada externamente. Y el transfer está al alcance de quien habla: transfer ciego con `##` y transfer asistido con `*2`, con la llamada aterrizando en un contexto escrito para eso, que distingue las extensiones internas de cuatro cifras de los números externos.
El motor de IVR recibe el identificador del menú y lo lee de la base mediante un script AGI. El resultado es una de seis decisiones: hacia un agente, hacia otro menú (recursivo), hacia una cola, transferencia externa, mensaje final, cierre. Los mensajes pueden sintetizarse o pueden ser archivos de audio grabados de antemano. Cambiar un menú significa cambiar una fila en la base, no editar un archivo de configuración en el servidor.
Cada cola lleva un nombre derivado de su identificador. Los miembros no se persisten en la configuración: se añaden y se eliminan durante el funcionamiento mediante la interfaz de gestión de la central, y está activado el posicionamiento simultáneo en varios sitios libres. En la práctica, un operador entra o sale de la cola sin que la central se reinicie y sin que las llamadas en espera se vean afectadas.
Un agente puede llamar él mismo a alguien de fuera y volver con la respuesta. El mecanismo está implementado con una tabla propia y estados explícitos — se llama, en curso, reintentar, finalizado, fallido, sin respuesta, expirado — con un máximo de tres intentos y una pausa de dos minutos entre ellos, y el resultado (incluido el tiempo estimado de llegada) se devuelve estructurado a la conversación que lo pidió. No es un concepto: son cinco funciones de servidor dedicadas, más una barrida de las llamadas que quedaron colgadas.
Un proceso programado lee la lista de registros cada minuto, con reconciliación amplia cada seis horas para que un corte no pierda nada. El registro se descarga en WAV, se transcribe, se analiza y se refleja en el análisis de llamadas junto con el audio. Por separado, cada tres minutos se leen las llamadas no atendidas — que no tienen registro y, de otro modo, no existirían en ninguna parte — y se convierten en alerta. Una llamada perdida es un cliente perdido; hacerla visible es la mejora más barata en un centro de llamadas.
El cliente que habla con la central del operador tiene su propio limitador de tasa, con bucket de tokens, y tratamiento explícito de errores. No es una precaución teórica: un middleware que consulta cada minuto y reconcilia cada seis horas puede, sin freno, golpear el límite del operador y quedar bloqueado justo cuando lo necesitas.
Qué aspecto tiene
Qué números existen, a qué operador, quién responde hoy por cada uno, en qué horario, y qué ocurre ahora cuando nadie responde. Parece burocracia; es la parte que evita sorpresas. Por nuestra experiencia, en un parque de números casi siempre hay líneas sobre las que la base dice una cosa y la central otra —y no se descubren en el lanzamiento, sino ahora.
El número entra por trunk, y las llamadas entrantes y salientes se prueban como dos cosas distintas, porque se rompen de forma distinta. Tenemos documentado un caso en el que las llamadas entrantes funcionaban perfectamente durante días, mientras que todas las llamadas salientes eran rechazadas por la central del operador con `403 Forbidden`, sin ningún cambio por nuestra parte. Una sola prueba de «llamó y funcionó» no cubre esto.
Las reglas de horario y prioridad, los menús, las colas y las rutas de transferencia se escriben como dialplan y como filas en la base, no como entendimiento verbal. Al final sabes exactamente qué ocurre con una llamada a las 23:40, el sábado, cuando el agente no entiende la solicitud.
El resultado de la llamada —transcript, resumen, sentimiento, dirección de la grabación, duración— se envía más adelante mediante un webhook firmado, y la organización se identifica por el número de teléfono. Donde existe un CRM, la llamada se vincula a la ficha y puede cambiar automáticamente el estado; sobre esta parte escribimos en la página de CRM y automatización de ventas.
Una centralita en un solo host es un único punto de fallo, y nosotros vivimos exactamente eso: cuando el host no responde, todas las líneas que pasan por él caen junto con él, por muy bien configurado que esté el agente. La firma del fallo es clara: la llamada devuelve “request timed out” con el identificador de llamada SIP vacío, es decir, la llamada SIP nunca se estableció. Por eso, en un proyecto real, la pregunta “qué pasa cuando cae el host” se plantea y se presupuesta al principio: un segundo host, monitorización que llama a una persona y una ruta de reserva hacia números normales.
Los datos
Las preguntas que hace cualquiera que tenga un delegado de protección de datos — hechas aquí antes de que las haga él.
Un caso
La situación
En un flujo de análisis de conversaciones, una parte de las llamadas llegaba al análisis y otra no. El patrón fue el que dio la causa: faltaban exactamente las llamadas largas. Un defecto que se reporta como «a veces no funciona» y se busca, erróneamente, en la transcripción.
Qué construimos
Había dos vías de transcripción y ambas fallaban, por motivos distintos. La vía multimodal enviaba el archivo de audio completo codificado en el cuerpo de la solicitud; por encima de cierto tamaño, el límite de cuerpo del servidor intermediario respondió con 413. La vía de reserva pedía un modelo de transcripción que la clave de acceso ya no permitía, así que respondía con 403. Ambas fallaban, el proceso informaba que todos los modelos de transcripción habían fallado, y la llamada se abandonaba. Las llamadas cortas quedaban por debajo del límite de cuerpo, así que pasaban — de ahí el patrón. La reparación fue: se salta la vía multimodal para los archivos WAV de más de 12 MB (umbral configurable desde el entorno), se reutiliza la transcripción ya calculada en lugar de transcribir una segunda vez, y la transcripción de último recurso se movió a un modelo permitido.
Qué salió
Verificado sobre la grabación que quedó bloqueada: una conversación de 21 minutos, archivo WAV de 41 MB — la vía multimodal evitada, transcripción tomada, análisis generado, fila y audio llegados al análisis de llamadas, cero fallos. La reconciliación confirmó después que ya no existen otras grabaciones bloqueadas.
Qué no dice el caso
El umbral de 12 MB es una propiedad del servidor intermediario, no de la llamada. Cuando cambian el gateway, la clave o el modelo, el umbral debe volver a verificarse — por eso lo hicimos configurable desde el entorno, no escrito en código.
Preguntas
No hoy, y preferimos decir eso antes que dar un número que suena en vacío. La parte del agente se puede escuchar en la página, de inmediato. La parte telefónica depende de un host SIP, y el host por el que pasan nuestras líneas de prueba no responde a la fecha de redacción — comprobado hoy, sin respuesta al ping y sin respuesta por HTTP. Para un proyecto tuyo, la telefonía se levanta sobre un host dedicado al proyecto, no sobre el de prueba.
Porque las reglas de enrutamiento, las colas, el transfer, el voicemail y el historial de llamadas son del negocio, no del proveedor de voz. Con una central propia puedes cambiar el motor del agente sin reescribir cómo se comporta tu teléfono, puedes enviar la misma llamada unas veces a un agente y otras a una persona, y puedes llevar el registro de llamadas contigo. Sin ella, quedas atado a lo que el proveedor decida exponer.
Caen todas las líneas que pasan por él. No es una hipótesis: es lo que vivimos nosotros, y la firma es fácil de reconocer — la llamada devuelve «request timed out» con el identificador de llamada SIP vacío, así que no es culpa del agente, del número ni del prompt. La conclusión que sacamos y que ahora ponemos en cada proyecto: la continuidad no es una función de la central, es una decisión de arquitectura y de presupuesto, tomada al inicio. Se resuelve con un segundo host y con una ruta de reserva hacia números normales, no con un ajuste.
No. Son dos cosas distintas, y el operador puede tratarlas de manera distinta. Tenemos documentado un caso en el que, con nuestra configuración sin cambios y con las llamadas entrantes funcionando, la central del operador empezó a rechazar todas las llamadas salientes con `403 Forbidden` — la prueba de que era del operador fue que una segunda cuenta, con configuración estructuralmente idéntica, seguía pudiendo llamar hacia afuera. Por eso no prometemos una campaña de llamadas salientes antes de una prueba de salida exitosa en tu número.
Sí, y lo hemos hecho: escribimos un middleware en Python sobre la API de una central virtual de operador, con cliente propio, limitador de tasa, descarga de grabaciones, transcripción, análisis y alertado, ejecutado en producción. Lo que hay que saber de antemano: el acceso a la API ampliada suele ser un servicio separado, contratado aparte, y las credenciales pueden no funcionar a la primera — en nuestro caso, el ciclo de aclaración de la especificación y de reinicio de la contraseña con el operador duró meses, con el servicio ya facturado. Por eso, en una oferta que depende de la API de un operador, ponemos explícitamente la condición: el trabajo comienza después de que la autenticación haya sido demostrada, no después de que haya sido prometida.
Se pueden grabar, transcribir y analizar. Permanecen vinculadas al espacio de trabajo de tu negocio, y el acceso requiere autenticación — no existe un depósito común entre clientes. Quién de tu equipo tiene derecho de escucha se define en la implementación. El aviso al interlocutor y la base de la grabación son decisiones tuyas como responsable del tratamiento; los escribimos en el сценарiu, no los suponemos.
Son el peor caso tratado en la mayoría de las empresas, porque no dejan rastro: no hay grabación, no hay transcripción, solo existe en el registro de llamadas. Con nosotros, un proceso lee el registro cada tres minutos, identifica las llamadas no atendidas y las convierte en alerta y en una fila visible. Para que quede claro de qué depende: las vemos solo en la medida en que el operador las expone en su registro.
Sí, y los menús viven en la base, no en archivos en el servidor. El motor lee la configuración del menú durante la llamada y decide una de seis vías: hacia un agente, hacia otro menú, hacia una cola, transferencia a un número externo, un mensaje final, o cierre. Los mensajes pueden sintetizarse o grabarse de antemano. En la práctica, un cambio de menú no requiere intervención en la central.
Mediante reconciliación, y es una pieza que construimos explícitamente. La consulta rápida tiene una ventana de unas decenas de horas, y encima de ella se ejecuta cada seis horas una reconciliación sobre una ventana de una semana, que vuelve a leer varias páginas de resultados. Cada registro procesado se marca, así que la relectura no duplica nada. Sin reconciliación, una caída de una hora significa un agujero permanente en los datos — y nadie lo observa.
22 de ellas son código y archivos de nuestros repositorios. No publicamos su nombre ni la línea: juntos, en una sola página, describirían con demasiada precisión cómo están construidos sistemas que no son solo nuestros. Los repasamos contigo, en el repositorio, a petición — la verificación sigue siendo posible, solo que se hace en una conversación.
Cuéntanos tu proceso. Juntos decidimos qué merece la pena construir, qué podemos conectar y cómo verificamos el resultado.