Deep Dive · Centralita Virtual

Arquitectura de una centralita virtual: qué hay detrás del panel

9 de mayo de 2026 · 8 min de lectura

Cuando un usuario de BPhone arrastra un bloque de «IVR» al editor visual y lo conecta con una cola de atención, ve algo sencillo e intuitivo. Lo que no ve es la cantidad de piezas que tienen que encajar para que eso funcione cuando alguien llama por teléfono. Hoy quiero levantar la alfombra y enseñar lo que hay debajo.

Esto es un recorrido técnico de lo que pasa desde que un número de teléfono suena hasta que alguien descuelga. Si no te interesa la fontanería de las telecomunicaciones, este artículo probablemente no es para ti. Pero si eres de los que se pregunta «cómo funciona esto por dentro», bienvenido.

Paso 1: Llega la llamada (SIP INVITE)

Todo empieza con un SIP INVITE. Cuando alguien marca tu número, el operador de telefonía (que nos entrega las llamadas vía trunk SIP) envía un paquete SIP INVITE a nuestro Session Border Controller (SBC). Este es el portero de nuestra infraestructura: valida que la llamada viene de un trunk autorizado, inspecciona las cabeceras SIP para prevenir fraude, y aplica políticas de rate limiting.

El SBC normaliza el INVITE — porque cada operador tiene su propia interpretación «creativa» del estándar SIP, algo que cualquiera que haya trabajado con múltiples carriers sabe de sobra — y lo reenvía al motor de enrutamiento.

Paso 2: Enrutamiento (a quién va esta llamada)

El motor de enrutamiento consulta PostgreSQL para determinar a qué cuenta pertenece el número llamado y cuál es el flujo de llamadas configurado. Aquí es donde el editor visual del panel se convierte en lógica ejecutable.

Internamente, cada flujo se almacena como un grafo dirigido en JSON. Los nodos son acciones (reproducir audio, IVR, cola, transferir, colgar, lanzar agente IA…) y las aristas son las condiciones de transición (tecla pulsada, timeout, horario, etc.). El motor recorre este grafo en tiempo real según avanza la llamada.

Es un diseño que decidimos tras considerar varias alternativas. La primera versión de BPhone generaba dialplan de Asterisk dinámicamente. Funcionaba, pero el debugging era una pesadilla — tenías un dialplan generado por máquina que cambiaba con cada edición del usuario. Pasamos a un motor de ejecución propio y fue de las mejores decisiones arquitectónicas que tomamos.

Paso 3: Negociación de media (SDP y codecs)

En paralelo con la señalización, hay una negociación de media. El SIP INVITE incluye un cuerpo SDP (Session Description Protocol) que dice: «hola, soy capaz de recibir audio con estos codecs, en esta IP, en estos puertos».

Nuestro media server responde con su propio SDP aceptando los codecs que soporta. En la mayoría de casos, esto es G.711 alaw (el estándar en Europa) para llamadas externas y Opus para llamadas WebRTC internas.

Una vez ambas partes acuerdan los parámetros, se establecen los flujos RTP (Real-time Transport Protocol). Son paquetes UDP que llevan el audio codificado, típicamente uno cada 20 milisegundos. El media server gestiona estos flujos: los mezcla en conferencias, los graba si está configurado, los transcodifica cuando hay endpoints con codecs diferentes, y los redirige según la lógica del flujo de llamadas.

Paso 4: La ejecución del flujo

Digamos que el flujo configurado es: saludo de bienvenida → IVR (pulse 1 para ventas, 2 para soporte) → cola de atención → agente humano.

El motor de ejecución:

1. Envía el audio de bienvenida al stream RTP (un archivo Ogg previamente grabado, transcodificado a G.711 al vuelo).
2. Activa la detección DTMF para capturar la tecla pulsada. Los tonos DTMF pueden venir in-band (dentro del audio) o como eventos RFC 2833. Soportamos ambos porque nunca sabes qué va a mandar el operador.
3. Según la tecla, avanza al nodo correspondiente del grafo.
4. Si llega a una cola, la llamada entra en espera con música (otro stream de audio mezclado) y el sistema empieza a buscar agentes disponibles consultando el estado de presencia en Redis.
5. Cuando un agente está disponible, se genera un nuevo SIP INVITE hacia su endpoint (teléfono IP, softphone, app móvil, WebRTC) y se puentean ambos flujos RTP.

Todo esto sucede en milisegundos. El usuario solo percibe que pulsa una tecla y le atienden.

Paso 5: Durante la llamada

Mientras la llamada está activa, hay varias cosas corriendo en paralelo:

• Grabación: si está activada, un proceso fork del stream RTP escribe los paquetes a un archivo. Grabamos en Ogg Vorbis para optimizar almacenamiento (mucho más compacto que WAV).
• Métricas en tiempo real: calculamos MOS estimado, jitter, pérdida de paquetes. Si la calidad degrada, generamos alertas.
• CDR (Call Detail Record): registramos cada evento — inicio, transferencias, tiempos de espera, fin — para facturación y análisis.
• Eventos webhook: si el usuario tiene integraciones configuradas, disparamos eventos HTTP en tiempo real (llamada iniciada, llamada respondida, llamada finalizada).

La infraestructura que sostiene todo

Todo esto corre sobre Kubernetes. Cada componente (SBC, motor de enrutamiento, media server, API, WebSocket server) es un servicio independiente que escala horizontalmente. El media server es el más delicado porque maneja audio en tiempo real y es sensible a la latencia — no puedes meter un media server en un pod que el scheduler de Kubernetes mueva alegremente entre nodos.

Usamos nodos dedicados con afinidad para los media servers, con network policies que priorizan el tráfico UDP. Es el tipo de infraestructura que parece sencilla en un diagrama de arquitectura pero que lleva meses de ajustes en producción hasta que funciona de forma fiable. Recuerdo semanas enteras debugueando problemas de audio intermitente que resultaron ser por cómo el CNI (Container Network Interface) de Kubernetes manejaba los paquetes UDP.

Es mucha maquinaria para que un teléfono suene. Pero es exactamente la complejidad que queremos que nuestros usuarios no tengan que ver. Ellos arrastran bloques en un editor visual, y todo esto se encarga de que funcione.

Antonio Gutiérrez — Desarrollador e ingeniero informático en Baxilio