sip5060.net / en es

Planet SIP

February 27, 2026

Andrea Sannucci Let's Encrypt ahora emite certificados para direcciones IP
Durante años, obtener un certificado TLS válido para una dirección IP pública fue un problema sin solución sencilla. Let's Encrypt, la autoridad de certificación gratuita más utilizada del mundo, solo emitía certificados para nombres de dominio. Quien necesitaba HTTPS sobre una IP tenía que recurrir a ZeroSSL, a certificados autofirmados, o simplemente vivir sin TLS. Eso cambió en 2025.

Let's Encrypt introdujo soporte para certificados con IP como Subject Alternative Name (SAN), pero con una condición: solo se emiten bajo el perfil shortlived, lo que significa que el certificado tiene una validez de aproximadamente seis días, no noventa. La razón es técnica y de política: las IPs son menos estables que los dominios, pueden cambiar de propietario sin previo aviso, y un certificado de larga duración para una IP representa un riesgo mayor. Los certificados de corta duración además no necesitan contener información de revocación, lo que los hace más ligeros y más seguros por diseño.

Para obtener un certificado así, el método de validación debe ser http-01 o tls-alpn-01. El método DNS-01 no está permitido para IPs, porque no es posible probar el control sobre una dirección IP mediante registros DNS. Esto implica que el puerto 80 o el 443 de la IP debe estar accesible desde los servidores de validación de Let's Encrypt.

Con Certbot 5.3.0 (publicado en febrero de 2026) el soporte es nativo mediante el flag --ip-address combinado con --preferred-profile shortlived. El comando básico con el plugin standalone sería:

certbot certonly --standalone \ --ip-address 203.0.113.45 \ --preferred-profile shortlived

Antes de que Certbot incorporara este soporte, la alternativa más utilizada era lego, un cliente ACME escrito en Go que implementó el perfil shortlived antes que Certbot. Con lego el comando equivalente es:

lego -d 203.0.113.45 --http --http.webroot /var/www/html \ -m tu@email.com run --profile shortlived

El punto crítico de esta nueva funcionalidad es la renovación automática. Con solo seis días de validez, renovar manualmente una vez por semana es inviable a largo plazo. La automatización mediante cron o systemd timer no es opcional: es parte del diseño. Certbot gestiona la renovación automáticamente para los certificados que ha emitido. Con lego se recomienda configurar Le_RenewalDays=4 para renovar cuando el certificado lleva cuatro días de vida, dejando margen antes del vencimiento.

Esta novedad es especialmente relevante para entornos donde no se dispone de un nombre de dominio: servidores de prueba, infraestructuras internas expuestas temporalmente, servicios VoIP accesibles por IP, o cualquier caso donde el DNS no es parte de la ecuación. La única condición que no cambia es que la IP debe ser pública y enrutable desde los servidores de Let's Encrypt.
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

February 26, 2026

Andrea Sannucci El cifrado en la mensajería: avances reales, problemas estructurales que persisten
Hemos vivido unos años razonablemente buenos en materia de seguridad en las comunicaciones digitales. El cifrado de extremo a extremo (E2EE) se ha extendido a las plataformas dominantes, y algunas - como Apple y Signal - han dado pasos hacia la resistencia frente a los ordenadores cuánticos. Comparado con el estado deplorable del cifrado en el correo electrónico, el contraste es notable. Sin embargo, mirar de cerca revela grietas importantes.

Apple ofrece E2EE con protección post-cuántica, pero no cifra las copias de seguridad de iMessage por defecto, lo que deja esos mensajes en manos de la propia empresa. La solución existe - se llama Advanced Data Protection - pero es opcional y solo funciona si todos los participantes en una conversación la activan. Android cifra las copias de seguridad por defecto, aunque el protocolo de mensajería aún no incorpora criptografía post-cuántica. Signal es la opción más sólida: E2EE, protección post-cuántica, y excluye sus datos de las copias de seguridad en iOS. WhatsApp también ofrece E2EE, pero comparte con Apple el problema de las copias de seguridad no cifradas por defecto en iOS, y su trabajo post-cuántico sigue en curso.

Pero el problema más profundo no es técnico: es estructural. La centralización de estas plataformas convierte a los proveedores en depositarios de datos enormemente valiosos, transformándolos en objetivos atractivos para empresas comerciales, legisladores, fuerzas de seguridad y grupos de interés. Ninguno de estos actores merece confianza incondicional en materia de privacidad. La centralización ha permitido innovar rápido, pero también ha creado puntos de control únicos donde basta una decisión para comprometer la seguridad de todos. Y esto es así incluso en el mejor escenario posible, donde el cifrado se respeta: la concentración de metadatos en pocos servidores es por sí sola un problema grave.

El panorama geopolítico agrava la situación. En la Unión Europea, el debate sobre Chat Control - que obligaría a escanear mensajes privados - sigue activo. En Reino Unido, Apple ha retirado Advanced Data Protection tras un conflicto con el gobierno. En Rusia, plataformas extranjeras están restringidas y se impulsa una aplicación de mensajería estatal. En Estados Unidos, WhatsApp enfrenta una demanda que cuestiona la veracidad de sus afirmaciones sobre E2EE, y Meta - dadas sus incentivos históricos - es difícilmente confiable. A esto se suma un vector de ataque nuevo: la inteligencia artificial fuera del dispositivo, que rompe el E2EE al compartir datos con terceros no destinatarios. Meta afirma haber resuelto esto con entornos de ejecución confiables, pero no es algo verificable de forma independiente.

Quedan también problemas técnicos no resueltos. La verificación de claves sigue siendo el punto más débil cuando se requiere seguridad real. La gestión de grupos es otro flanco: los servidores de WhatsApp pueden añadir a cualquier persona a una conversación, lo que hace trivial la vigilancia selectiva. Signal tiene una arquitectura más robusta aquí, exigiendo que alguien ya dentro del grupo avale a los nuevos participantes. Los requisitos de verificación de edad se están extendiendo sin que los gobiernos hayan explorado primero si es posible implementarlos de forma que preserve la privacidad.

No existe una solución fácil. Nadie ha logrado construir un sistema E2EE robusto, usable y adoptado masivamente. Signal se acerca más al ideal, pero su base de usuarios es limitada y depende de una sola organización. Lo que sí tiene a su favor es el código abierto y compilaciones reproducibles, lo que aporta una transparencia que las demás plataformas no ofrecen. La pregunta que queda en el aire es incómoda: ¿es este equilibrio inestable, esta tensión permanente entre fuerzas contradictorias, lo mejor que podemos hacer?
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

February 24, 2026

Andrea Sannucci Soporte del Protocolo Proxy en OpenSIPS 4.0
Las infraestructuras SIP modernas dependen cada vez más de balanceadores de carga, proxies inversos y servicios de borde en la nube para ofrecer escalabilidad, seguridad y distribución geográfica. El problema clásico de esta arquitectura es que estos componentes intermedios ocultan la dirección IP real del cliente al servidor SIP de backend: lo que llega a OpenSIPS es la IP del balanceador, no la del teléfono o softphone original. OpenSIPS 4.0 resuelve este problema con la introducción del soporte nativo del Protocolo Proxy.

El Protocolo Proxy fue desarrollado originalmente por HAProxy Technologies como un mecanismo ligero para que proxies y balanceadores transmitan la IP y el puerto originales del cliente al servidor de destino. En lugar de depender de cabeceras a nivel de aplicación — que pueden no existir o no ser confiables — el Protocolo Proxy antepone una pequeña cabecera a la conexión de transporte con los metadatos de la conexión original: IP y puerto del cliente, IP y puerto de destino, y familia de transporte. Hoy es compatible con plataformas como Cloudflare, AWS, Google Cloud, Azure, HAProxy, NGINX y Envoy, entre otros.

La implementación inicial en OpenSIPS 4.0 soporta el Protocolo Proxy v1, tanto en conexiones entrantes como salientes, sobre UDP, TCP, TLS, WebSocket (WS) y WebSocket seguro (WSS).

En el escenario de conexiones entrantes, el caso típico es OpenSIPS detrás de un servicio de borde como Cloudflare que reenvía conexiones TCP o TLS. Sin Protocolo Proxy, OpenSIPS sólo ve la IP de Cloudflare como origen, lo que impide hacer autenticación correcta, aplicar políticas de ruteo basadas en IP real o detectar clientes abusivos. Con el protocolo habilitado, Cloudflare antepone una cabecera del tipo PROXY TCP4 203.0.113.10 198.51.100.5 50612 5061 antes del mensaje SIP. OpenSIPS parsea esa cabecera y expone la información al script de ruteo mediante la nueva variable $proxy_protocol, que contiene los datos reales del cliente. Desde ese momento, todos los módulos y la lógica de ruteo pueden tomar decisiones basadas en el endpoint real, aunque la conexión provenga de Cloudflare.

En el escenario de conexiones salientes, el caso de uso es OpenSIPS operando como proxy o SBC y reenviando tráfico hacia otra plataforma SIP upstream. Al insertar la cabecera del Proxy Protocol en las conexiones salientes, el sistema de destino mantiene visibilidad completa del endpoint original del cliente, aunque la conexión provenga ahora de OpenSIPS. Este patrón es especialmente común cuando OpenSIPS actúa como SBC realizando NAT traversal, terminación TLS, topology hiding o filtrado de seguridad, pero se quiere que los sistemas upstream sigan tomando decisiones con base en la IP real del cliente.

El soporte del Protocolo Proxy en OpenSIPS 4.0 es una incorporación que responde a una necesidad real de las infraestructuras VoIP actuales: integrar servidores SIP con la capa de red moderna — balanceadores, CDN, plataformas cloud — sin perder trazabilidad del cliente original. La solución es elegante porque el problema se resuelve a nivel de transporte, antes incluso de que OpenSIPS procese el primer byte SIP, lo que la hace transparente para el resto de la lógica de la plataforma.
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

February 20, 2026

Andrea Sannucci Las contraseñas generadas por IA son un riesgo de seguridad
Usar la inteligencia artificial para generar contraseñas es mala idea. Es probable que esa contraseña ya esté en manos de un atacante, listo para usarla en un ataque de diccionario, que consiste en recorrer automáticamente una lista de contraseñas probables hasta dar con la correcta, sin necesidad de probar todas las combinaciones posibles.

La empresa de ciberseguridad Irregular probó ChatGPT, Claude y Gemini y concluyó que las contraseñas que generan son "altamente predecibles" y no verdaderamente aleatorias. En las pruebas con Claude, 50 prompts produjeron solo 23 contraseñas únicas; una cadena apareció 10 veces y muchas otras compartían la misma estructura. Esto representa un problema real. Tradicionalmente, los atacantes construyen o descargan listas de palabras compuestas por contraseñas comunes, filtraciones reales y variantes con patrones (palabras seguidas de números y símbolos) para usarlas en sus ataques. Añadir a esas listas las contraseñas típicas de los chatbots de IA requiere un esfuerzo mínimo.

El motivo de fondo es conceptual: los modelos de lenguaje están entrenados para predecir lo que viene a continuación basándose en lo que ya conocen. Son buenos anticipando patrones, no inventando algo completamente nuevo. Como señalan los investigadores de Irregular: "los LLMs funcionan prediciendo el token más probable, que es exactamente lo contrario de lo que requiere la generación segura de contraseñas: aleatoriedad uniforme e impredecible".

Los gestores de contraseñas abordan este problema de manera diferente: utilizan generadores de números aleatorios criptográficos que incorporan entropía del mundo real, en lugar de la generación de texto basada en patrones propia de los LLMs. En otras palabras, un buen gestor de contraseñas no "inventa" tu contraseña como lo hace una IA; solicita bits aleatorios criptográficos al sistema operativo y los convierte directamente en caracteres, sin ningún patrón oculto que los atacantes puedan aprender. Un sitio web puede decirte que una contraseña generada por IA es fuerte, pero el mismo razonamiento que desaconseja reutilizar contraseñas aplica aquí: ¿de qué sirve una contraseña robusta si los cibercriminales ya la tienen? Si ya usaste una IA para generar alguna contraseña, considera cambiarla y activa la autenticación multifactor (2FA) para reforzar la seguridad de esa cuenta.

Fuente: Malwarebytes Blog, Pieter Arntz, 19 de febrero de 2026
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

February 18, 2026

Andrea Sannucci Kamailio 6.1.0: lo que trae la nueva versión mayor del Proxy SIP
Hoy se ha liberadola versión 6.1.0 del Proxy SIP Kamailio, la vigésimo octava versión mayor en la historia del proyecto, que se acerca ya a sus 25 años de actividad continua. Esta release reúne alrededor de 1500 commits aportados por más de 50 colaboradores, lo que da una idea de la intensidad del ciclo de desarrollo.

La novedad más estructural es la incorporación de cuatro módulos nuevos: auth_arnacon, Autenticación criptográfica basada en ENS; auth_web3, Autenticación basada en blockchain con soporte integrado de ENS (Ethereum Name Service); peerstate, Estados de registro y de llamada para peers; y ptimer, Ejecución de bloques de rutas de configuración sobre base de temporizador preciso. Más allá de los módulos, la versión introduce la opción de activar operaciones TLS multihilo, soporte mejorado para arquitecturas arm64 mediante stdatomic y bloqueo con pthread, y la posibilidad de establecer múltiples conexiones TLS con distintos dominios hacia el mismo host:port.

En el ámbito de la autenticación, se añade soporte para hash con SHA-512 y SHA-512-256, reforzando la seguridad en la autenticación de usuarios. El módulo rtpengine incorpora replicación DMQ mediante tabla hash interna, facilitando despliegues en clúster, y se añaden funciones específicas para implementar SIPREC junto con RTPEngine. También se incluye el registro de claves TLS con opción de enviarlas a un peer remoto, lo que resulta útil para entornos de captura y análisis de tráfico cifrado.

Para la gestión del tráfico, el módulo dispatcher recibe un nuevo algoritmo que combina round-robin con enrutamiento basado en prioridades, y se incorpora un identificador único interno por registro de destino para facilitar la gestión vía RPC. El módulo db_redis gana soporte para centinela, una función propria de Redis, y la opción de cambiar de conjuntos a hashes con expiración automática. El registro de CDR-at-once pasa a tener precisión de milisegundos.

Entre las mejoras de control en tiempo de ejecución, destaca la posibilidad de consultar y modificar parámetros de módulos mediante comandos RPC, nuevas funciones UAC de transacción para control fino de llamadas iniciadas localmente, y soporte básico de JSONRPC en kamcmd. Se añade también un nuevo marco genérico de definición de parámetros de core y la opción de aplicar cambios automáticamente antes de que se cree la transacción.

Otras adiciones relevantes incluyen soporte para enviar REFER a un diálogo existente identificado por Call-Id, flags, por rama, via con posibilidad de almacenarlos como parámetro en el mensaje SIP, operaciones atómicas de incremento y decremento, soporte para claves enteras de 32 y 64 bits en htable, y la capacidad del módulo permission de hacer match con la subred más larga.

Fuente: https://www.kamailio.org/w/kamailio-v6.1-0-release-notes/
- Proxy SIP
- Kamailio 6.1.0
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

February 17, 2026

Andrea Sannucci SIP Forking a Gran Escala: Cambios en OpenSIPS 4.0
El SIP forking es una funcionalidad fundamental en los sistemas de telefonía IP que permite el timbre simultáneo en múltiples dispositivos, la implementación de Hunt Groups en sistemas de clase V (VPBX) y el failover entre múltiples gateways o carriers. En la práctica, un Hunt Group puede apuntar a 6-9 usuarios, cada uno con varios dispositivos registrados y posiblemente con Push Notification habilitado, lo que genera fácilmente 25 ramas (branches) por transacción. Si ese Hunt Group hace failover hacia otro grupo similar, se alcanzan unas 50 ramas. En escenarios de trunking con failover en cascada entre carriers y gateways, una sola llamada puede necesitar iterar de 40 a 60 gateways, generando transacciones INVITE con de 20 a 40 ramas.

OpenSIPS 3.6 arrastra un diseño de 25 años que limita a un máximo de 31 ramas por transacción. Esta limitación proviene del uso de un bitmask interno sobre un tipo de dato uint32. El problema afecta exclusivamente a las transacciones INVITE, ya que son las únicas que realizan forking; las peticiones BYE, por ejemplo, solo tienen una rama. Además, el número de ramas varía enormemente según el escenario y el tamaño de cada rama es considerable en memoria.

La primera solución implementada en OpenSIPS 4.0 es una reescritura completa del código de gestión de ramas. El bitmask fue reemplazado por una estructura de datos tipo array, eliminando cualquier limitación en el número máximo de ramas. El valor por defecto en el código es de 256 ramas máximas por transacción, aunque este valor se puede aumentar fácilmente modificando una sola definición en el código fuente.

El segundo problema es el consumo de memoria. Cada estructura de rama ocupa aproximadamente 0.5 KB. Con la configuración anterior de 12 ramas, una transacción ocupaba 6920 bytes. Con 64 ramas integradas se pasa a 34320 bytes y con 256 ramas a casi 134 KB por transacción. En un sistema que procesa 5000 llamadas por segundo, con un mínimo de 10000 transacciones por segundo y un tiempo de vida de 10 segundos por transacción (sumando ring time más time-to-delete), se mantienen unas 100000 transacciones simultáneas en memoria. Con 134 KB por transacción, eso supone 13.4 GB de memoria, en su mayoría desperdiciada porque no todas las transacciones INVITE necesitan tantas ramas.

La segunda solución en OpenSIPS 4.0 es la asignación dinámica y progresiva de ramas. En lugar de reservar siempre el número máximo de ramas al crear la transacción, se asignan bloques de 4 ramas según se necesiten. No se puede usar realloc convencional porque las ramas quedan enlazadas en diferentes listas de timers, lo que hace que sean sensibles a cambios de dirección en memoria, por eso se optó por chunks de tamaño fijo. El resultado es que OpenSIPS 4.0 elimina el límite de ramas por transacción sin penalización de memoria ni procesamiento, e incluso reduce la huella de memoria respecto a versiones anteriores.

Fuente: https://blog.opensips.org/2026/02/17/big-scale-sip-forking/
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

February 11, 2026

Andrea Sannucci Se acerca la versión 4.0 del Proxy SIP OpenSIPs
OpenSIPS 4.0 se presenta como un punto de inflexión. El objetivo es eliminar limitaciones heredadas desde los tiempos de SER, rediseñando conceptos que llevan más de 20 años sin cambios sustanciales.

TCP: de multiproceso a multihilo — El framework TCP actual, basado en un proceso TCP Main que distribuye conexiones entre TCP workers, se reemplaza por un modelo multihilo dentro de un solo proceso. Esto elimina la migración de conexiones entre procesos, reduce overhead y permite usar librerías como OpenSSL de forma nativa (ya que OpenSSL soporta multithreading pero no multiproceso).

TLS: limpieza general — OpenSSL se beneficia directamente del cambio a multihilo, eliminando los "twitches" (parches forzados) que causaban crashes, memory leaks y conflictos entre módulos. El módulo StirShaken migrará a una librería más ligera como BoringSSL. WolfSSL dejará de estar embebido en el código y pasará a linkeo dinámico, permitiendo actualizaciones independientes.

Ramas TM dinámicas — El límite histórico de 32 (o 64) ramas por transacción desaparece. Las ramas se asignarán dinámicamente en lugar de reservar memoria estática, algo crítico para escenarios de Class V con Hunt-Groups en cascada y Push Notifications.

Interfaces bond — Se podrán agrupar sockets de distintos protocolos y familias de direcciones (IPv4/IPv6, UDP/TCP) bajo una interfaz lógica. OpenSIPS seleccionará automáticamente el socket correcto según el destino final.

Profiling SIP y de procesos — Se añade profiling por mensaje SIP (timestamps, rutas ejecutadas, funciones llamadas) y por proceso/worker (estados idle, running, blocked). Los datos se podrán recoger vía logs, opensips-cli o servicios HTTP, con soporte para OpenTelemetry.

Proxy Protocol (HAProxy) — Soporte para PROXY protocol en la capa TCP, permitiendo preservar la IP real del cliente cuando OpenSIPS opera detrás de firewalls o proxies como Cloudflare.

Interoperabilidad PRACK + UPDATE — El módulo dialog actuará como B2BUA para PRACK y UPDATE, generando PRACKs cuando un extremo no soporta 100rel y convirtiendo UPDATEs a re-INVITEs cuando sea necesario. Esto facilita la integración entre sistemas IMS y dispositivos legacy.

WebSocket genérico — Una interfaz WebSocket genérica manejable desde el script de routing, pensada para integrar servicios de IA, APIs de provisioning o protocolos como Janus y Verto sin desarrollo custom por cada caso.

Estado actual — De las 12 features planificadas, 5 están en desarrollo (TCP framework, StirShaken SSL, WolfSSL, ramas TM dinámicas, HAProxy) y 7 pendientes (OpenSSL rework, interfaces bond, profiling SIP, profiling de procesos, OpenTelemetry, PRACK+UPDATE, WebSocket genérico).
- OpenSIPs 4.0
- Proxy SIP
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

February 02, 2026

Andrea Sannucci VideoCurso: Kamailio, RTPEngine y Asterisk containerizados + HA
Aprende a desplegar y gestionar infraestructuras VoIP profesionales usando contenedores Docker. Curso 100% práctico con laboratorios en vivo.

Para quién es este curso

Administradores de sistemas VoIP

Arquitectos de telecomunicaciones

DevOps que gestionan plataformas de comunicaciones

Proveedores VoIP y call centers

Requisitos: Conocimientos de Linux, conceptos básicos de SIP/VoIP

Contenido (10 horas - 4 sesiones)

Sesión 1: Docker básico para VoIP (3h - 23 Febrero 2026 5pm)

Dockerfiles para Kamailio

Network modes (host vs bridge)

Docker Compose

Lab: Kamailio + MariaDB funcionando

Sesión 2: RTPEngine containerizado (2h - 24 febrero 2026 5pm)

Módulo kernel nft_rtpengine

Multi-instancia con balanceo

Integración Kamailio + RTPEngine

Lab: Media proxy distribuido

Sesión 3: Arquitectura distribuida (2h - 25 Febrero 2026 5pm)

Dispatcher de Kamailio

Asterisk en Docker

Stack completo VoIP

Lab: Kamailio + 2 RTPEngine + 2 Asterisk

Sesión 4: Alta disponibilidad (3h - 26 Febrero 2026 - 5pm)

Replicación con DMQ

Redis para sesiones compartidas

MariaDB replicación maestro/maestro

KeepAlived - Pacemaker/Corosync

Lab: Cluster HA con failover

El precio incluye:

El acceso en vivo a todas las videoconferencias

Acceso a los materiales del curso, al foro para preguntas y a la grabación de las videoconferencias de por vida.

El valor del curso es de 150 dólares, 130 Euros o 550.000 pesos colombianos. Descuentos:

10% para pronto pago/inscripción temprana; pagos realizados antes del 17 de Febrero 2026;

15% para empresas que inscriban 3 o más empleados.

20% para antiguos estudiantes que ya participaron en un curso organizado por VozToVoice

Cupos: 15 personas máximo

En anexo el temario y más informaciones. Formulario de inscripción.
Adjunto Tamaño

programa_videocurso_kamailio_contendores.pdf 122.69 KB
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

Adjunto	Tamaño
programa_videocurso_kamailio_contendores.pdf	122.69 KB

January 29, 2026

Andrea Sannucci Certificados de Seis Días de Let's Encrypt
Let's Encrypt acaba de hacer realidad algo que anunció en enero de 2025: certificados con una vida útil de apenas seis días. Mientras la industria sigue discutiendo si reducir la validez de los certificados a cuarenta y siete días es razonable o no, Let's Encrypt ha ido mucho más allá y además ha introducido algo que nunca antes había ofrecido: certificados para direcciones IP.

La pregunta obvia es: ¿para qué querría alguien un certificado que expira en menos de una semana? La respuesta tiene que ver con la ventana de oportunidad que tendrían los atacantes si consiguen comprometer tus claves privadas. Imagina dos escenarios: alguien logra acceder a tus servidores o uno de tus empleados decide robar las claves. Con un certificado de noventa días, ese material robado podría utilizarse durante tres meses. Con uno de seis días, la ventana se reduce drásticamente. Esto cobra sentido especialmente para instituciones financieras o sistemas con millones de usuarios donde el riesgo de ataques activos de red es real.

Ahora bien, hay que hablar del elefante en la habitación: la revocación de certificados simplemente no funciona bien. Nadie presta atención a las listas de revocación, así que si te roban un certificado y lo revocas, probablemente no sirva de mucho.

El precio que pagas por estos certificados ultrarrápidos es operativo. Si actualmente renuevas cada sesenta días, con certificados de seis días estarás renovando cada cuatro días aproximadamente, es decir, quince veces más frecuentemente. El problema no es tanto la frecuencia en sí, sino el margen de error. Si revisas tus certificados diariamente y renuevas treinta días antes de que expiren, tienes unas treinta oportunidades para conseguir un nuevo certificado. Con certificados de seis días, ese margen se reduce a apenas tres intentos. No necesitas gente disponible las veinticuatro horas, pero sí necesitarás turnos de fin de semana.

Hace unos años me habría preocupado el problema de los relojes desincronizados en los dispositivos de los usuarios finales. Cuando tienes una audiencia global, muchos de tus clientes tienen relojes mal configurados, y esto puede causar problemas incluso con certificados de larga duración, pero con estos de seis días el problema se magnificaría. Sin embargo, parece que este tema ha dejado de ser relevante porque nadie se ha quejado en los últimos años, aunque conviene tenerlo presente.

La otra novedad interesante son los certificados para direcciones IP. Aunque es un caso de uso de nicho, es tremendamente útil para dispositivos de red que necesitan seguridad pero no tienen necesariamente nombres de host. Hay otras formas de lograr lo mismo, pero tiene mucho sentido proteger el acceso por IP directamente.

Al final, esto no es para todo el mundo. Si tu infraestructura no está completamente automatizada o no tienes un equipo que pueda supervisar renovaciones tan frecuentes, probablemente no necesites complicarte la vida con certificados de seis días. Pero si trabajas en un entorno donde la seguridad es crítica y el riesgo de compromiso de claves es real, esta puede ser una herramienta valiosa.
- Let's Encrypt
- Certificados
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

January 14, 2026

Andrea Sannucci Servidor de Correo Completo con Postfix y Dovecot en AlmaLinux 10
Montar un servidor de correo propio es una de esas tareas que muchos administradores de sistemas postergan indefinidamente. La complejidad percibida, la configuración de DNS, los problemas de deliverability y el spam son barreras que parecen insuperables. Sin embargo, tener control total sobre tu infraestructura de correo electrónico ofrece ventajas significativas: privacidad absoluta, control de costos, y la satisfacción de gestionar tu propia comunicación.

En este artículo voy a documentar la implementación de un servidor de correo completo basado en Postfix y Dovecot para AlmaLinux 10, con todas las características necesarias para un entorno de producción moderno.

Arquitectura del Sistema

La solución se compone de varios elementos que trabajan conjuntamente:

Postfix actúa como MTA (Mail Transfer Agent), gestionando el envío y recepción de correos mediante SMTP. Es robusto, ampliamente documentado y relativamente sencillo de configurar una vez entiendes su filosofía modular.

Dovecot proporciona los servicios IMAP y POP3, permitiendo a los usuarios acceder a sus buzones desde clientes de correo. Su diseño enfocado en seguridad y rendimiento lo convierte en la elección natural para este componente.

OpenDKIM firma digitalmente los correos salientes, añadiendo una capa crucial de autenticación que mejora significativamente la reputación del servidor frente a otros sistemas de correo.

SpamAssassin se encarga del filtrado antispam mediante análisis bayesiano y reglas predefinidas. Aunque existen alternativas más modernas, SpamAssassin sigue siendo efectivo y está muy bien integrado con Postfix.

Procmail procesa y filtra correos según reglas personalizadas, permitiendo implementar lógica de negocio específica en el manejo de mensajes.

Puertos y Protocolos

La configuración contempla todos los puertos estándar:

Para SMTP utilizamos el puerto 25 para comunicación servidor-a-servidor, el 465 para SMTPS con SSL directo, y el 587 para submission con STARTTLS (este último es el recomendado para clientes).

Para IMAP: puerto 143 con STARTTLS y 993 con SSL directo. Para POP3: puerto 110 con STARTTLS y 995 con SSL directo.

La tendencia actual favorece las conexiones SSL directas (puertos 993 y 995) sobre STARTTLS, aunque ambas opciones están disponibles.

Proceso de Instalación

La instalación se automatiza mediante un script que guía al administrador a través de los pasos necesarios. El proceso solicita información básica: dominio, email administrativo, IP pública e interfaz de red (estos últimos se detectan automáticamente).

Lo crucial aquí es la configuración DNS previa. No tiene sentido continuar sin tener correctamente configurados los registros A, MX, SPF, DKIM y DMARC. La ausencia de estos registros garantiza que tus correos terminarán en carpetas de spam o directamente rechazados.

El registro SPF define qué servidores están autorizados a enviar correo en nombre de tu dominio. El registro DKIM proporciona la clave pública para verificar las firmas digitales. El registro DMARC establece la política de manejo para correos que fallen las validaciones anteriores.

Una vez confirmado el DNS, el instalador obtiene certificados SSL mediante Let's Encrypt y configura todos los servicios necesarios.

Gestión de Usuarios

He implementado dos scripts para simplificar la administración: uno para crear usuarios y otro para eliminarlos.

El script de creación genera automáticamente una contraseña segura (o permite definir una manualmente), crea el usuario en el sistema, configura su buzón y envía un email con instrucciones detalladas de configuración. Este último punto es especialmente útil en entornos corporativos donde los usuarios no son técnicos.

El script de eliminación incluye la opción de realizar backup antes de borrar, evitando pérdidas de datos accidentales.

Control de Spam mediante Expresiones Regulares

Más allá de SpamAssassin, he añadido un sistema de bloqueo basado en expresiones regulares que opera a nivel de Postfix. Esto permite rechazar correos antes de que entren al sistema, ahorrando recursos y mejorando la seguridad.

El archivo /etc/postfix/sender_access_regexp contiene las reglas en formato simple:

/expresion_regular/ ACCION mensaje_opcional

Algunos ejemplos prácticos: bloquear dominios específicos conocidos por spam, rechazar remitentes con patrones sospechosos (muchos números consecutivos, caracteres no ASCII), bloquear TLDs problemáticos, o rechazar correos donde el remitente usa una IP en lugar de un dominio.

Este enfoque es extremadamente eficiente porque el rechazo ocurre durante el handshake SMTP, antes de que el correo sea aceptado. El servidor remitente recibe inmediatamente el código de rechazo y puede informar al usuario.

Seguridad

La configuración implementa varias medidas de seguridad esenciales:

TLS 1.2+ obligatorio (no se permite SSL ni versiones antiguas de TLS)

Suite de cifrados restringida a algoritmos fuertes

Autenticación SASL obligatoria para envío

Rate limiting de conexiones

Firma DKIM de todos los correos salientes

Adicionalmente, recomiendo instalar fail2ban para bloquear automáticamente IPs que intenten ataques de fuerza bruta contra los servicios de autenticación.

Mantenimiento

Los certificados SSL se renuevan automáticamente mediante certbot. SpamAssassin debería actualizarse periódicamente con sa-update.

Es buena práctica implementar tareas programadas para limpiar correos antiguos de carpetas como Spam y Papelera, evitando que los buzones crezcan indefinidamente.

El comando mailq muestra la cola de correos pendientes de envío, útil para diagnosticar problemas. pflogsumm genera estadísticas detalladas a partir de los logs de Postfix.

Resolución de Problemas

Los principales problemas suelen estar relacionados con DNS mal configurado, certificados SSL expirados o problemas de conectividad de red.

Los logs son tus mejores aliados: /var/log/maillog para Postfix, /var/log/dovecot.log para Dovecot, y journalctl para los servicios systemd.

Para verificar DKIM: opendkim-testkey -d ejemplo.com -s default -vvv te dirá exactamente qué está mal con tu configuración.

Conclusión

Montar un servidor de correo propio ya no es el proceso arcano que era hace una década. Con las herramientas adecuadas y una comprensión básica de los protocolos involucrados, es perfectamente factible tener un sistema de correo funcional y seguro.

¿Vale la pena el esfuerzo? Depende de tus necesidades. Para proyectos pequeños o personales, probablemente un servicio gestionado sea más práctico. Pero si valoras la privacidad, necesitas control total, o simplemente disfrutas entendiendo cómo funcionan las cosas, montar tu propio servidor de correo es un ejercicio altamente educativo y gratificante.

La clave está en no subestimar la importancia de la configuración DNS y la reputación de tu IP. Sin estos elementos correctamente establecidos, incluso el servidor de correo mejor configurado técnicamente tendrá problemas de deliverability.

https://github.com/voztovoice/mail_server.git
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

January 13, 2026

Andrea Sannucci Element y Matrix: Federación como respuesta a silos centralizados

Mientras Threema y Session priorizan anonimato mediante arquitecturas específicas, Element adopta estrategia diferente: interoperabilidad mediante protocolo abierto federado. Matrix no es aplicación sino especificación. Element es su implementación de referencia más madura.

Matrix: protocolo abierto, no producto propietario

Matrix es estándar abierto para comunicación en tiempo real, comparable a SMTP para email o XMPP para mensajería. Especifica APIs HTTP RESTful para transmitir y replicar datos JSON entre servidores (homeservers) que implementan el protocolo.

Fundación Matrix.org, organización sin ánimo de lucro, mantiene la especificación. Cualquiera puede implementar cliente o servidor compatible. Esta apertura es arquitectónica, no declarativa: el protocolo está documentado públicamente y múltiples implementaciones compiten en el ecosistema.

La comparación con email es precisa: no existe "la empresa de email". Existen Gmail, ProtonMail, Tutanota —cada uno opera servidores que hablan SMTP. Similarmente, no existe "la empresa Matrix". Existen Element, FluffyChat, Nheko —clientes que hablan Matrix.

Element: cliente de referencia

Element (anteriormente Riot.im, antes Vector) es aplicación desarrollada por New Vector Ltd, empresa cofundada por creadores del protocolo Matrix. Código abierto bajo licencia Apache 2.0. Disponible para web, desktop (Windows/macOS/Linux), iOS y Android.

Es implementación más completa del protocolo, con todas las funcionalidades: mensajería cifrada, llamadas VoIP, videollamadas grupales, compartición de archivos, widgets integrados (Jitsi, Etherpad), bots programables y bridges a otras plataformas.

Interfaz reminiscente de Slack: canales organizados en espacios, threads de conversación, reacciones con emojis, búsqueda de historial completo. Funcionalidad empresarial sin dependencia de proveedor único.

Arquitectura federada: homeservers

Usuario se registra en homeserver. Puede ser matrix.org (oficial), instancia autoalojada, o servidor de terceros. El homeserver almacena identidad del usuario, historial de mensajes y gestiona cifrado.

Identificadores siguen formato @usuario:dominio.com. Similitud con email es deliberada. Usuario en @alice:ejemplo.org puede comunicarse con @bob:matrix.org aunque estén en homeservers diferentes.

Cuando Alice envía mensaje a Bob:

Cliente de Alice contacta ejemplo.org (su homeserver)
ejemplo.org replica mensaje a matrix.org (homeserver de Bob)
Ambos homeservers almacenan el mensaje
Cliente de Bob descarga desde matrix.org

No hay servidor central único. Red es constelación de homeservers que federan entre sí. Si ejemplo.org cae, matrix.org sigue operando. Mensajes ya replicados permanecen accesibles.

Cifrado extremo a extremo: Olm y Megolm

Matrix implementa E2EE mediante bibliotecas Olm (conversaciones 1-a-1) y Megolm (salas grupales). Basadas en Double Ratchet Algorithm, mismo fundamento que Signal Protocol.

Auditorías criptográficas realizadas por NCC Group, financiadas por Open Technology Fund. Resultados públicos. Vulnerabilidades identificadas fueron corregidas.

Cifrado es opcional por sala. Usuario puede crear sala cifrada o no cifrada. Esta opcionalidad tiene razones arquitectónicas: federación complica gestión de claves cuando múltiples homeservers participan. Salas públicas grandes (miles de usuarios) típicamente no cifran para facilitar incorporación de nuevos miembros.

Metadata: homeservers conocen quién habla con quién, cuándo se conectan, tamaño de mensajes. E2EE protege contenido, no metadatos de comunicación. Trade-off inherente a federación donde servidores intermedian.

Bridges: interoperabilidad arquitectónica

Característica distintiva de Matrix son bridges —puentes que conectan Matrix con otros protocolos y plataformas. Tipos de bridges:

Portal rooms: salas Matrix que reflejan automáticamente sala externa (IRC, Discord, Telegram). Usuario se une a #_discord_123456:matrix.org y participa en canal Discord desde cliente Matrix.

Plumbed rooms: sala Matrix existente se conecta manualmente a sala externa. Mensajes fluyen bidireccionalmente. Útil para equipos que usan múltiples plataformas.

Puppeting: bridge crea "usuarios fantasma" (ghosts) en Matrix representando usuarios de plataforma externa, o viceversa (puppets). Usuarios aparecen nativos en ambos lados.

Bridges disponibles para: IRC, Slack, Discord, Telegram, WhatsApp, Signal, SMS, email. Element ofrece servicio comercial "Element One" (5 USD/mes) que agrega bridges gestionados para consolidar múltiples plataformas en interfaz única.

Esta interoperabilidad responde directamente a fragmentación de ecosistema de mensajería. En lugar de convencer a todos de usar Matrix, Matrix se adapta para hablar con plataformas existentes.

Federación vs centralización: implicaciones políticas

Arquitectura federada distribuye control. No hay entidad única que pueda:

Censurar usuarios globalmente (cada homeserver decide políticas)
Acceder a todos los mensajes (distribuidos entre homeservers)
Apagar la red completa (no hay punto único de fallo)

Pero federación implica que homeserver que usas tiene acceso a tus metadatos. Requiere confianza en operador del servidor —o capacidad técnica para autoalojar.

Comparación con email es instructiva. Gmail domina mercado por conveniencia, no por imposibilidad técnica de alternativas. Similarmente, matrix.org es homeserver más grande, pero cualquiera puede ejecutar el propio usando Synapse, Dendrite u otras implementaciones.

Adopción institucional

Matrix ha ganado tracción en sector público europeo, específicamente en contextos donde soberanía digital es prioritaria:

Alemania: Bundeswehr (ejército), ministerios federales, sistema de salud
Francia: gobierno francés adoptó Matrix para comunicaciones oficiales
Unión Europea: proyectos piloto para comunicación interdepartamental
Mozilla: migró comunicación interna a Matrix
Reddit: experimentación con Matrix para chat integrado

Estas adopciones reflejan que para organizaciones que priorizan control sobre infraestructura, federación ofrece equilibrio entre funcionalidad moderna y soberanía sobre datos.

Comparación con competidores

Aspecto	Element/Matrix	Signal	Slack
Arquitectura	Federada	Centralizada	Centralizada
Protocolo	Abierto (Matrix)	Cerrado	Cerrado
Cifrado E2E	Opcional	Siempre	No
Autoalojamiento	Sí	No	No
Interoperabilidad	Bridges a múltiples plataformas	Solo Signal	Integraciones limitadas
Modelo negocio	Open source + servicios	Sin ánimo de lucro	SaaS comercial

Signal ofrece mejores garantías de privacidad mediante cifrado obligatorio y mínimos metadatos. Matrix ofrece mayor flexibilidad arquitectónica y interoperabilidad. Slack ofrece experiencia pulida pero con vendor lock-in total.

Limitaciones y trade-offs

Metadata exposure: Homeservers ven metadatos de comunicación. Federación requiere compartir información de enrutamiento entre servidores.

Complejidad de setup: Autoalojar homeserver requiere competencia técnica. Synapse (implementación de referencia) consume recursos significativos. Dendrite es alternativa más ligera pero menos madura.

Efecto de red limitado: Aunque bridges ayudan, adopción masiva aún no lograda. Usuario promedio permanece en WhatsApp/Telegram/Discord.

UX inconsistente: Múltiples clientes con implementaciones parciales de protocolo. Element es más completo pero interfaz menos refinada que Slack/Discord.

Gestión de claves en E2E: Verificación de dispositivos y gestión de claves de cifrado requiere diligencia del usuario. Experiencia menos fluida que Signal.

Modelo económico: open source con capa comercial

Matrix.org Foundation mantiene protocolo mediante donaciones y sponsors corporativos. Element (la empresa) ofrece:

Element gratuito: cliente open source sin coste
Element Matrix Services (EMS): hosting gestionado de homeservers
Element Enterprise: funcionalidades adicionales, SLAs, soporte

Estrategia clásica de open source empresarial: protocolo libre, implementación libre, servicios gestionados comerciales. Sostenible sin comprometer apertura del estándar.

Caso de uso: soberanía digital organizacional

Matrix es solución óptima cuando organización requiere:

Control total sobre infraestructura y datos
Interoperabilidad con sistemas externos
Funcionalidad empresarial moderna (VoIP, compartición archivos, integrations)
Evitar vendor lock-in de Slack/Teams/Discord

Ejemplo concreto: gobierno que no puede usar Teams (Microsoft controla infraestructura), no puede usar Slack (Salesforce controla datos), pero necesita funcionalidad equivalente. Matrix permite autoalojar con control completo manteniendo interoperabilidad mediante bridges.

Ecosistema de clientes alternativos

Protocolo abierto genera ecosistema competitivo:

FluffyChat: cliente móvil enfocado en simplicidad
Nheko: cliente desktop nativo ligero
Quaternion: cliente Qt multiplataforma
Fractal: cliente GNOME integrado con desktop Linux
Cinny: cliente web alternativo con interfaz moderna

Usuario no está atado a Element. Puede cambiar de cliente manteniendo misma cuenta y conversaciones. Competencia en implementaciones mejora calidad general del ecosistema.

Widgets y extensibilidad

Salas Matrix pueden integrar widgets —aplicaciones web embebidas. Ejemplos:

Jitsi: videollamadas directamente en sala sin salir de cliente
Etherpad: edición colaborativa de documentos en tiempo real
EtherCalc: hojas de cálculo compartidas
YouTube/Spotify: reproducción sincronizada de contenido

Esta extensibilidad convierte salas Matrix en espacios de colaboración completos, no solo chat. Aproximación similar a Slack pero sin depender de APIs propietarias controladas por proveedor único.

Conclusión operacional

Matrix y Element demuestran viabilidad técnica de comunicación federada con funcionalidad empresarial moderna. No es solución más simple ni más privada en términos absolutos, pero ofrece equilibrio único entre control, interoperabilidad y capacidades avanzadas.

Para usuario individual que busca máxima privacidad, Signal es opción superior. Para organización que requiere soberanía digital sin sacrificar funcionalidad, Matrix es arquitectura más adecuada.

La existencia de Matrix valida que centralización no es requisito para comunicación avanzada. Federación —con complejidades y trade-offs inherentes— es alternativa técnicamente viable y políticamente relevante en contexto donde dependencia de plataformas centralizadas representa riesgo geopolítico tangible.

Recursos:

Protocolo Matrix: https://matrix.org
Especificación técnica: https://spec.matrix.org
Element cliente: https://element.io
Código fuente: https://github.com/vector-im/element-web
Lista de homeservers públicos: https://www.hello-matrix.net/public_servers.php
Documentación bridges: https://matrix.org/bridges

Vota el Articulo:

January 10, 2026

Andrea Sannucci Session: Arquitectura de anonimato distribuido

Session plantea una pregunta técnica con implicaciones políticas: ¿puede existir mensajería donde ni siquiera la infraestructura de red conozca quién habla con quién? Su respuesta combina onion routing, red descentralizada y ausencia total de identificadores vinculados a identidad.

Session es un fork de Signal desarrollado por The Loki Project (ahora Oxen Project), fundación australiana sin ánimo de lucro. Hereda el cifrado de extremo a extremo de Signal pero diverge radicalmente en arquitectura: elimina servidores centrales, implementa onion routing y prescinde de cualquier dato identificativo durante el registro.

La decisión de bifurcar Signal en lugar de construir desde cero es estratégica. Signal Protocol es auditoría probada. Session lo adapta para contexto descentralizado, sacrificando Perfect Forward Secrecy a cambio de arquitectura resistente a censura y análisis de tráfico.

Identidad sin vinculación: Session ID

Al crear cuenta, Session genera un Session ID aleatorio. No pide número telefónico ni correo electrónico. Este ID es clave pública que sirve simultáneamente como identificador de usuario y como componente del sistema de cifrado asimétrico.

Consecuencia directa: puedes crear múltiples cuentas sin limitación. No hay base de datos centralizada que vincule Session IDs con personas físicas. La identidad es puramente criptográfica, no administrativa.

Para añadir contactos, compartes el Session ID mediante canal externo o escaneo de código QR. Es menos conveniente que sincronización automática por número telefónico, pero convenencia y anonimato son vectores opuestos en diseño de sistemas.

Onion routing: ocultación de análisis de tráfico

Session implementa onion requests, variante simplificada de Tor específica para mensajería. Cuando envías mensaje:

La app cifra el mensaje dos veces (end-to-end encryption)
Construye path de tres Service Nodes aleatorios
Aplica capas adicionales de cifrado (una por cada salto)
Cada nodo descifra solo su capa, conociendo únicamente nodo anterior y siguiente

Ningún nodo individual puede correlacionar emisor con receptor. El primer nodo sabe que enviaste mensaje, el último sabe que el destinatario lo recibió. Pero ningún nodo —ni observador externo— puede vincular ambos extremos.

A diferencia de Tor, Session no necesita enrutar tráfico UDP ni servicios complejos. Solo necesita transportar mensajes y archivos adjuntos. Esta simplificación permite implementación más ligera manteniendo propiedades de privacidad equivalentes.

Red descentralizada: Service Nodes y swarms

Session opera sobre red de Service Nodes (anteriormente Oxen Service Nodes), servidores distribuidos globalmente operados por la comunidad. No hay servidor central. Cada nodo es económicamente incentivado mediante staking de criptomoneda Oxen.

Los mensajes no se almacenan en un solo servidor sino en swarms: grupos de 5-7 Service Nodes responsables de un rango de Session IDs. Cuando envías mensaje, este se replica en todos los nodos del swarm del destinatario. Si un nodo falla, los demás mantienen disponibilidad.

Por defecto, mensajes expiran tras dos semanas. Arquitectura store-and-forward: los nodos almacenan mensajes temporalmente hasta que el destinatario se conecta y los descarga. No hay sincronización en la nube ni respaldo automático. Si pierdes el dispositivo, pierdes el historial (a menos que hayas exportado backup manualmente).

Minimización de metadatos

Metadatos —quién habla con quién, cuándo, desde dónde— revelan tanto o más que contenido de mensajes. Session implementa minimización arquitectónica:

No recopila direcciones IP: onion routing oculta IP tanto del emisor como del receptor
No registra timestamps centralizados: no hay log de cuándo te conectaste
No almacena listas de contactos en servidor: gestionadas localmente en dispositivo
No muestra "última vez visto": evita filtración temporal
No requiere sincronización con servicios centrales: todo descentralizado

Esta minimización no es política de privacidad declarativa sino imposibilidad técnica arquitectónica.

Trade-offs reconocidos

Sin Perfect Forward Secrecy (temporalmente)

Session eliminó PFS en versión actual. PFS garantiza que compromisión de clave privada a largo plazo no permite descifrar mensajes pasados. Los desarrolladores argumentan que:

Anonimato y onion routing mitigan parcialmente estos riesgos
PFS será reintroducido en Session Protocol V2 (en desarrollo)

Es trade-off explícito: priorizaron descentralización y resistencia a censura sobre protección post-compromiso.

Ausencia de llamadas (limitada)

Videollamadas y llamadas de voz están disponibles en beta pero desactivadas por defecto. Implementar VoIP sobre onion routing descentralizado presenta desafíos técnicos de latencia. Es funcionalidad secundaria, no core de la aplicación.

Sincronización multi-dispositivo limitada

Puedes usar mismo Session ID en móvil y desktop, pero sincronización de historial entre dispositivos es manual mediante backup/restore. No hay nube que sincronice automáticamente. Cada dispositivo descarga mensajes de Service Nodes independientemente.

Resistencia a censura y ataques Sybil

Red descentralizada elimina puntos únicos de fallo. No hay servidor central que bloquear. Para censurar Session, la autoridad tendría que bloquear miles de Service Nodes distribuidos globalmente. Técnicamente posible mediante deep packet inspection, pero significativamente más costoso que bloquear dominios centralizados.

Resistencia Sybil se logra mediante staking económico. Operar Service Node requiere bloquear cantidad significativa de tokens Oxen. Atacante que intente controlar fracción sustancial de la red enfrenta costo económico prohibitivo.

Comparación con Signal

Aspecto	Session	Signal
Arquitectura	Descentralizada (Service Nodes)	Centralizada (AWS)
Registro	Session ID anónimo	Número telefónico
Enrutamiento	Onion routing (oculta IPs)	Conexión directa a servidores
Metadatos	Minimizados arquitectónicamente	Mínimos pero existentes
PFS	Temporalmente ausente	Implementado
Censura	Resistente (distribuida)	Vulnerable a bloqueo de dominio

Signal es más robusto en garantías criptográficas específicas (PFS). Session ofrece mejor anonimato y resistencia a censura. Son diseños para amenazas diferentes.

Código abierto y auditorías

Session es completamente open source. Código disponible en GitHub bajo licencia GPLv3. Cualquier persona puede auditar implementación, verificar ausencia de backdoors, o ejecutar fork independiente.

Ha sido sometido a auditorías externas aunque con menor frecuencia que Signal. Proyecto más joven, menor financiación. Pero principio de transparencia se mantiene: código abierto permite verificación independiente.

Adopción y casos de uso

Session no compite por masividad. Es herramienta para contextos donde anonimato es requisito operacional:

Periodismo en regímenes represivos
Activismo en entornos hostiles
Comunicaciones en zonas con censura agresiva
Usuarios que rechazan vinculación identidad-comunicación

También es adoptado por actores maliciosos precisamente porque protege anonimato efectivamente. Esta dualidad es inherente a tecnologías de privacidad: protegen tanto usos legítimos como ilegítimos. No es fallo de diseño sino característica inevitable.

Limitaciones prácticas

Efecto de red: Requiere que contactos también usen Session. Sin interoperabilidad con WhatsApp/Signal/Telegram, adopción es barrera.

UX menos pulida: Interfaz funcional pero menos refinada que aplicaciones mainstream con equipos grandes y financiación masiva.

Dependencia de Service Nodes: Aunque descentralizada, red depende de incentivos económicos para mantener nodos. Si token Oxen colapsa, disponibilidad de nodos podría degradarse.

Adjuntos limitados: Archivos hasta 10MB. Para transferencia de archivos grandes, no es solución óptima.

Gratuito vs modelo económico

Session es gratuito para usuarios finales. Financiación proviene de:

Fundación Oxen (sin ánimo de lucro)
Economía de criptomoneda asociada (staking de Service Nodes)

No hay modelo de suscripción ni venta de datos. Sustentabilidad depende de economía de tokens y donaciones. Menos predecible que modelo comercial tradicional pero evita conflictos de interés inherentes a monetización vía datos.

Conclusión operacional

Session demuestra que arquitectura descentralizada con onion routing es técnicamente viable para mensajería. No es solución universal: tiene trade-offs explícitos en PFS, funcionalidad VoIP y experiencia de usuario.

Pero responde afirmativamente a la pregunta: ¿puede existir mensajería donde ni la infraestructura conozca los grafos sociales? Sí, a costa de complejidad técnica y menor conveniencia.

Para usuarios que priorizan anonimato sobre conveniencia, o que operan en contextos donde censura es amenaza real, Session ofrece arquitectura verificablemente resistente. Para usuario promedio que busca reemplazo de WhatsApp, Signal es opción más equilibrada.

La existencia de Session amplía espacio de diseño en mensajería. Demuestra que centralización no es requisito técnico sino elección arquitectónica. Y en esa elección radican las propiedades políticas del sistema.

Recursos:

Web oficial: https://getsession.org
Documentación técnica: https://docs.getsession.org
Código fuente: https://github.com/oxen-io
Whitepaper: https://getsession.org/whitepaper

Vota el Articulo:

Andrea Sannucci Threema: Cuando la privacidad no es negociable
La mensajería instantánea ha evolucionado hasta convertirse en infraestructura crítica de comunicación. Sin embargo, la mayoría de plataformas operan bajo un modelo donde la gratuidad del servicio se paga con datos personales. Threema representa la antítesis de este paradigma.

Desarrollada en Suiza desde 2012, Threema construye su propuesta sobre un principio radical: la comunicación privada no requiere identificación centralizada. Al crear una cuenta, el sistema genera un ID aleatorio de 8 caracteres. No pide número telefónico ni correo electrónico. Esta decisión técnica tiene implicaciones profundas: desvincula la identidad legal de la capacidad de comunicar.

Los grupos y listas de contactos se almacenan exclusivamente en el dispositivo del usuario, no en servidores remotos. Los mensajes se eliminan de los servidores inmediatamente después de entregarse. Esta arquitectura invierte la lógica dominante: en lugar de centralizar datos para monetizarlos, los dispersa para protegerlos.

Cifrado como infraestructura, no como marketing

Threema implementa cifrado de extremo a extremo usando criptografía de curva elíptica Curve25519. Pero añade un segundo nivel: cifrado de transporte entre cliente y servidor que protege incluso los metadatos de cabecera. Perfect Forward Secrecy garantiza que la compromisión de claves futuras no permita descifrar comunicaciones pasadas.

La arquitectura de "conocimiento cero" asegura que ni empleados de Threema ni autoridades con acceso a servidores puedan leer los mensajes. El cifrado no es aquí característica promocional sino axioma estructural. Y a diferencia de soluciones propietarias, el código es abierto y auditado externamente de forma periódica.

Soberanía legal: la geografía importa

Los servidores operan exclusivamente en Suiza, jurisdicción con robusta protección de datos. Threema cumple con RGPD europeo y está certificada ISO 27001. No es detalle menor: la ubicación geográfica de la infraestructura determina qué autoridades pueden exigir acceso, bajo qué condiciones legales, y con qué salvaguardas procesales.

Suiza no es miembro de alianzas de vigilancia como Five Eyes. Esta posición legal convierte la geografía en arquitectura de seguridad.

El modelo de pago como posición ética

Threema cuesta aproximadamente 5€. Esta barrera económica es deliberada: financia el desarrollo sin depender de publicidad ni venta de datos. El modelo de negocio transparente elimina incentivos perversos. Si el usuario paga por el servicio, el usuario es el cliente, no el producto.

Para contextos empresariales, Threema Work ofrece panel de administración centralizado con gestión de usuarios, políticas de seguridad y personalización. Threema OnPrem permite ejecutar toda la infraestructura en servidores propios, crítico para organizaciones con requisitos de soberanía absoluta sobre datos.

Verificación criptográfica de confianza

El sistema implementa tres niveles de verificación mediante código de colores:

Rojo: usuario no verificado

Amarillo: verificación por teléfono o email

Verde: verificación criptográfica directa mediante escaneo de código QR

La confianza se establece mediante criptografía, no mediante autoridad centralizada. Es descentralización aplicada al concepto mismo de identidad verificable.

Penetración y tracción

Con más de 12 millones de usuarios en 175 países, Threema ha crecido especialmente en Europa germanoparlante. En enero 2021, tras los cambios de privacidad en WhatsApp, alcanzó posiciones dominantes en descargas en Alemania, Suiza y Austria. El éxodo refleja creciente consciencia sobre vigilancia digital.

Limitaciones que son decisiones

Threema no sincroniza en la nube. Para algunos es desventaja; para otros, garantía de que no existe copia centralizada vulnerable. Los backups se gestionan localmente. Esta "limitación" es decisión arquitectónica coherente con el modelo de privacidad.

La ausencia de versión gratuita filtra usuarios que esperan gratuidad subsidiada con datos. Es barrera de entrada que autoselecciona usuarios conscientes de que la privacidad tiene costo operacional real.

Contexto competitivo

Frente a WhatsApp (2.000+ millones de usuarios, propiedad Meta), Signal (fundación sin ánimo de lucro, financiada por donaciones) y Telegram (cloud-based, cifrado opcional), Threema ocupa nicho específico: organizaciones y usuarios que priorizan privacidad verificable sobre conveniencia de red.

No compite por masividad sino por robustez. Es herramienta para contextos donde la privacidad es requisito operacional, no preferencia estética.

Consideraciones técnicas

La seguridad de cualquier aplicación depende también del dispositivo. Malware con acceso root puede comprometer comunicaciones cifradas. Threema mitiga vectores de ataque en su dominio, pero no puede proteger contra dispositivos comprometidos. La seguridad es sistémica, no mágica.

Las auditorías externas más recientes incluyen trabajos del Cure53 (2020) y la Universidad de Ciencias Aplicadas de Münster (2019). El código abierto permite verificación independiente.

Conclusión operacional

Threema no es solución universal para comunicación masiva. Es infraestructura específica para contextos donde privacidad, anonimato y soberanía de datos no son negociables. Responde a la pregunta: ¿puede existir mensajería sin vigilancia extractiva? Su respuesta es arquitectónica, no retórica.

En ecosistema dominado por plataformas que monetizan atención y datos, Threema demuestra que modelos alternativos son técnicamente viables. La pregunta no es si son posibles, sino si estamos dispuestos a pagar su costo real en lugar de subsidiarlo con privacidad.

Recursos:

Web oficial: https://threema.ch

Documentación: https://threema.ch/docs

Código fuente: https://github.com/threema-ch

Auditorías de seguridad: https://threema.ch/en/security
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

January 09, 2026

Andrea Sannucci Configuración Segura de IPtables para Asterisk PBX 20 en AlmaLinux 9

La seguridad de un servidor Asterisk PBX es crítica, ya que representa un objetivo frecuente para atacantes que buscan realizar fraude telefónico, ataques de denegación de servicio o comprometer la infraestructura de comunicaciones. En este artículo configuraremos IPtables en AlmaLinux 9 para proteger un servidor Asterisk mientras mantenemos la funcionalidad completa del sistema.

Puertos Necesarios para Asterisk

Antes de comenzar, es fundamental comprender qué puertos utiliza Asterisk y por qué:

Puerto 5060/UDP: Señalización SIP sin cifrar
Puerto 5061/TCP: Señalización SIP con TLS (cifrado)
Puertos 20000-30000/UDP: RTP (Real-time Transport Protocol) para el flujo de audio/vídeo

Arquitectura de Seguridad

Nuestra configuración implementará defensa en profundidad con múltiples capas:

Política por defecto restrictiva (DROP)
Protección contra ataques de fuerza bruta
Mitigación de ataques DDoS/DoS
Rate limiting específico para tráfico VoIP
Logging de actividad sospechosa

Configuración Paso a Paso

1. Limpieza y Políticas Iniciales

Primero, limpiamos cualquier regla existente y establecemos políticas restrictivas:

#!/bin/bash
# Script de configuración IPtables para Asterisk PBX
# AlmaLinux 9

# Limpiar reglas existentes
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X

# Política por defecto: denegar todo
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

¿Por qué política DROP? Al denegar todo el tráfico por defecto, solo permitimos explícitamente lo necesario. Esto reduce drásticamente la superficie de ataque.

2. Tráfico Loopback y Establecido

# Permitir tráfico loopback (necesario para procesos locales de Asterisk)
iptables -A INPUT -i lo -j ACCEPT

# Permitir conexiones ya establecidas y relacionadas
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

El tráfico loopback es esencial porque Asterisk utiliza conexiones locales entre sus módulos internos. Las conexiones establecidas permiten que las respuestas a nuestras peticiones salientes regresen al servidor.

3. Protección contra Ataques Comunes

# Protección contra escaneo de puertos
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP

# Protección contra fragmentación de paquetes
iptables -A INPUT -f -j DROP

# Protección contra IP spoofing
iptables -A INPUT -s 127.0.0.0/8 ! -i lo -j DROP
iptables -A INPUT -s 224.0.0.0/4 -j DROP
iptables -A INPUT -s 240.0.0.0/5 -j DROP

Estas reglas detectan y bloquean paquetes malformados típicos de escaneos automatizados. Los atacantes utilizan estas técnicas para identificar servicios vulnerables sin ser detectados.

4. Protección contra SYN Flood

# Limitar nuevas conexiones TCP para prevenir SYN flood
iptables -A INPUT -p tcp --syn -m conntrack --ctstate NEW -m limit \
    --limit 60/s --limit-burst 100 -j ACCEPT
iptables -A INPUT -p tcp --syn -m conntrack --ctstate NEW -j LOG \
    --log-prefix "SYN flood detected: " --log-level 4
iptables -A INPUT -p tcp --syn -m conntrack --ctstate NEW -j DROP

¿Por qué es importante? Los ataques SYN flood intentan saturar la tabla de conexiones del servidor enviando miles de solicitudes SYN sin completar el handshake TCP. Esto puede dejar fuera de servicio nuestro sistema de telefonía.

5. Protección SSH (Gestión del Servidor)

# Crear cadena para SSH con rate limiting
iptables -N SSH_BRUTEFORCE

# Permitir hasta 3 intentos de conexión por minuto por IP
iptables -A SSH_BRUTEFORCE -m recent --name ssh --set
iptables -A SSH_BRUTEFORCE -m recent --name ssh --update --seconds 60 \
    --hitcount 4 -j LOG --log-prefix "SSH brute force: "
iptables -A SSH_BRUTEFORCE -m recent --name ssh --update --seconds 60 \
    --hitcount 4 -j DROP
iptables -A SSH_BRUTEFORCE -j ACCEPT

# Aplicar protección a puerto SSH (cambiar 22 si usas otro puerto)
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j SSH_BRUTEFORCE

Esta protección es vital porque el acceso SSH comprometido permite al atacante reconfigurar Asterisk, robar credenciales SIP o utilizar el servidor para otros fines maliciosos.

6. Señalización SIP - Puerto 5060/UDP

# Crear cadena personalizada para SIP
iptables -N SIP_TRAFFIC

# Rate limiting agresivo para SIP - previene registration floods
iptables -A SIP_TRAFFIC -m recent --name sip_attempts --set
iptables -A SIP_TRAFFIC -m recent --name sip_attempts --update \
    --seconds 60 --hitcount 30 -j LOG --log-prefix "SIP flood 5060: "
iptables -A SIP_TRAFFIC -m recent --name sip_attempts --update \
    --seconds 60 --hitcount 30 -j DROP

# Limitar paquetes SIP por segundo (ajustar según capacidad del servidor)
iptables -A SIP_TRAFFIC -m limit --limit 100/s --limit-burst 200 -j ACCEPT
iptables -A SIP_TRAFFIC -j DROP

# Aplicar reglas al puerto SIP
iptables -A INPUT -p udp --dport 5060 -j SIP_TRAFFIC

¿Por qué rate limiting tan estricto? Los atacantes realizan "registration floods" intentando miles de registros SIP por segundo para saturar Asterisk o realizar ataques de fuerza bruta contra extensiones. Un servidor típico no necesita más de 100 paquetes SIP legítimos por segundo.

7. Señalización SIP Cifrada - Puerto 5061/TCP

# Crear cadena para SIP-TLS
iptables -N SIPS_TRAFFIC

# Rate limiting para SIP-TLS (más permisivo que UDP por naturaleza de TCP)
iptables -A SIPS_TRAFFIC -m recent --name sips_attempts --set
iptables -A SIPS_TRAFFIC -m recent --name sips_attempts --update \
    --seconds 60 --hitcount 50 -j LOG --log-prefix "SIP-TLS flood: "
iptables -A SIPS_TRAFFIC -m recent --name sips_attempts --update \
    --seconds 60 --hitcount 50 -j DROP

# Protección contra SYN flood específica para SIP-TLS
iptables -A SIPS_TRAFFIC -p tcp --syn -m limit --limit 30/s -j ACCEPT
iptables -A SIPS_TRAFFIC -p tcp --syn -j DROP

iptables -A SIPS_TRAFFIC -m limit --limit 100/s --limit-burst 150 -j ACCEPT
iptables -A SIPS_TRAFFIC -j DROP

# Aplicar al puerto 5061
iptables -A INPUT -p tcp --dport 5061 -j SIPS_TRAFFIC

El tráfico cifrado requiere protección adicional contra SYN floods ya que el establecimiento de la conexión TLS consume más recursos del servidor que SIP sin cifrar.

8. Puertos RTP para Media - 20000-30000/UDP

# Crear cadena para tráfico RTP
iptables -N RTP_TRAFFIC

# Rate limiting para RTP (más permisivo - es tráfico de audio/vídeo continuo)
iptables -A RTP_TRAFFIC -m recent --name rtp_flood --set
iptables -A RTP_TRAFFIC -m recent --name rtp_flood --update \
    --seconds 10 --hitcount 1000 -j LOG --log-prefix "RTP flood detected: "
iptables -A RTP_TRAFFIC -m recent --name rtp_flood --update \
    --seconds 10 --hitcount 1000 -j DROP

# Limitar nuevas "conexiones" RTP por segundo
iptables -A RTP_TRAFFIC -m conntrack --ctstate NEW -m limit \
    --limit 100/s --limit-burst 200 -j ACCEPT

# Permitir RTP establecido sin límite (es tráfico de voz activo)
iptables -A RTP_TRAFFIC -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Aplicar al rango de puertos RTP
iptables -A INPUT -p udp --dport 20000:30000 -j RTP_TRAFFIC

¿Por qué límites más altos para RTP? El tráfico RTP es continuo durante una llamada activa. Un codec G.711 genera aproximadamente 50 paquetes por segundo por llamada. Con 50 llamadas simultáneas necesitamos permitir 2,500 paquetes/segundo legítimamente.

9. ICMP - Ping Controlado

# Permitir ICMP echo request (ping) con rate limiting
iptables -A INPUT -p icmp --icmp-type echo-request -m limit \
    --limit 5/s --limit-burst 10 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

# Permitir otros mensajes ICMP necesarios
iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT

Limitamos ping para prevenir flood mientras mantenemos la capacidad de diagnóstico de red. Los mensajes ICMP de error son necesarios para el correcto funcionamiento de TCP/IP.

10. Logging de Tráfico Bloqueado

# Log de paquetes bloqueados (últimas reglas antes del DROP final)
iptables -A INPUT -m limit --limit 5/min -j LOG \
    --log-prefix "IPtables INPUT dropped: " --log-level 4

# La política DROP ya está establecida, pero podemos hacerla explícita
iptables -A INPUT -j DROP

El logging nos permite detectar patrones de ataque y ajustar nuestras reglas. Limitamos la frecuencia de logs para evitar saturar /var/log/messages.

Hardening Adicional del Kernel

Complementamos IPtables con configuraciones del kernel Linux:

# Editar /etc/sysctl.conf o crear /etc/sysctl.d/99-asterisk-security.conf

# SYN cookies - protección contra SYN flood
net.ipv4.tcp_syncookies = 1

# Reducir el tiempo de espera de conexiones medio-abiertas
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 3

# Protección contra IP spoofing
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# No aceptar source routing
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0

# No aceptar ICMP redirects
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.default.secure_redirects = 0

# No enviar ICMP redirects
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0

# Log de paquetes sospechosos
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.log_martians = 1

# Ignorar broadcasts ICMP
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Protección contra bad ICMP error messages
net.ipv4.icmp_ignore_bogus_error_responses = 1

Aplicar cambios:

sysctl -p

¿Por qué necesitamos esto además de IPtables? Estas configuraciones operan a nivel de kernel, antes de que IPtables procese los paquetes. Proporcionan una capa adicional de defensa y optimizan el rendimiento al descartar tráfico malicioso más temprano en la pila de red.

Persistencia de Reglas

En AlmaLinux 9, las reglas IPtables no persisten automáticamente después de un reinicio:

# Guardar configuración actual
iptables-save > /etc/sysconfig/iptables

# Habilitar servicio iptables para que cargue al iniciar
systemctl enable iptables
systemctl start iptables

Si prefieres usar firewalld (el firewall por defecto en AlmaLinux 9), puedes convertir estas reglas, pero personalmente recomiendo IPtables para servidores VoIP por su control granular y menor overhead.

Script Completo de Configuración

He consolidado todas las reglas en un script ejecutable:

#!/bin/bash
# iptables-asterisk-secure.sh
# Configuración segura de IPtables para Asterisk PBX
# AlmaLinux 9

# Verificar que se ejecuta como root
if [ "$EUID" -ne 0 ]; then
    echo "Este script debe ejecutarse como root"
    exit 1
fi

echo "[*] Limpiando reglas existentes..."
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X

echo "[*] Estableciendo políticas por defecto..."
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

echo "[*] Configurando reglas básicas..."
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

echo "[*] Aplicando protección contra ataques comunes..."
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
iptables -A INPUT -f -j DROP
iptables -A INPUT -s 127.0.0.0/8 ! -i lo -j DROP
iptables -A INPUT -s 224.0.0.0/4 -j DROP
iptables -A INPUT -s 240.0.0.0/5 -j DROP

echo "[*] Configurando protección SYN flood..."
iptables -A INPUT -p tcp --syn -m conntrack --ctstate NEW -m limit \
    --limit 60/s --limit-burst 100 -j ACCEPT
iptables -A INPUT -p tcp --syn -m conntrack --ctstate NEW -j LOG \
    --log-prefix "SYN flood detected: " --log-level 4
iptables -A INPUT -p tcp --syn -m conntrack --ctstate NEW -j DROP

echo "[*] Configurando protección SSH..."
iptables -N SSH_BRUTEFORCE
iptables -A SSH_BRUTEFORCE -m recent --name ssh --set
iptables -A SSH_BRUTEFORCE -m recent --name ssh --update --seconds 60 \
    --hitcount 4 -j LOG --log-prefix "SSH brute force: "
iptables -A SSH_BRUTEFORCE -m recent --name ssh --update --seconds 60 \
    --hitcount 4 -j DROP
iptables -A SSH_BRUTEFORCE -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j SSH_BRUTEFORCE

echo "[*] Configurando SIP (5060/UDP)..."
iptables -N SIP_TRAFFIC
iptables -A SIP_TRAFFIC -m recent --name sip_attempts --set
iptables -A SIP_TRAFFIC -m recent --name sip_attempts --update \
    --seconds 60 --hitcount 30 -j LOG --log-prefix "SIP flood 5060: "
iptables -A SIP_TRAFFIC -m recent --name sip_attempts --update \
    --seconds 60 --hitcount 30 -j DROP
iptables -A SIP_TRAFFIC -m limit --limit 100/s --limit-burst 200 -j ACCEPT
iptables -A SIP_TRAFFIC -j DROP
iptables -A INPUT -p udp --dport 5060 -j SIP_TRAFFIC

echo "[*] Configurando SIP-TLS (5061/TCP)..."
iptables -N SIPS_TRAFFIC
iptables -A SIPS_TRAFFIC -m recent --name sips_attempts --set
iptables -A SIPS_TRAFFIC -m recent --name sips_attempts --update \
    --seconds 60 --hitcount 50 -j LOG --log-prefix "SIP-TLS flood: "
iptables -A SIPS_TRAFFIC -m recent --name sips_attempts --update \
    --seconds 60 --hitcount 50 -j DROP
iptables -A SIPS_TRAFFIC -p tcp --syn -m limit --limit 30/s -j ACCEPT
iptables -A SIPS_TRAFFIC -p tcp --syn -j DROP
iptables -A SIPS_TRAFFIC -m limit --limit 100/s --limit-burst 150 -j ACCEPT
iptables -A SIPS_TRAFFIC -j DROP
iptables -A INPUT -p tcp --dport 5061 -j SIPS_TRAFFIC

echo "[*] Configurando RTP (20000-30000/UDP)..."
iptables -N RTP_TRAFFIC
iptables -A RTP_TRAFFIC -m recent --name rtp_flood --set
iptables -A RTP_TRAFFIC -m recent --name rtp_flood --update \
    --seconds 10 --hitcount 1000 -j LOG --log-prefix "RTP flood detected: "
iptables -A RTP_TRAFFIC -m recent --name rtp_flood --update \
    --seconds 10 --hitcount 1000 -j DROP
iptables -A RTP_TRAFFIC -m conntrack --ctstate NEW -m limit \
    --limit 100/s --limit-burst 200 -j ACCEPT
iptables -A RTP_TRAFFIC -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p udp --dport 20000:30000 -j RTP_TRAFFIC

echo "[*] Configurando ICMP..."
iptables -A INPUT -p icmp --icmp-type echo-request -m limit \
    --limit 5/s --limit-burst 10 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP
iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT

echo "[*] Configurando logging de tráfico bloqueado..."
iptables -A INPUT -m limit --limit 5/min -j LOG \
    --log-prefix "IPtables INPUT dropped: " --log-level 4
iptables -A INPUT -j DROP

echo "[*] Guardando configuración..."
iptables-save > /etc/sysconfig/iptables

echo "[*] Habilitando servicio iptables..."
systemctl enable iptables 2>/dev/null || echo "Servicio iptables ya habilitado"

echo ""
echo "======================================"
echo "Configuración completada exitosamente"
echo "======================================"
echo ""
echo "Reglas activas:"
iptables -L -n -v --line-numbers
echo ""
echo "Para ver logs en tiempo real:"
echo "  tail -f /var/log/messages | grep -E 'SIP|RTP|SSH|SYN'"

Guarda el script y hazlo ejecutable:

chmod +x iptables-asterisk-secure.sh
./iptables-asterisk-secure.sh

Monitoreo y Ajuste

Después de implementar estas reglas, es fundamental monitorear su efectividad:

Verificar Reglas Activas

# Ver todas las reglas con contadores
iptables -L -n -v --line-numbers

# Ver reglas de cadenas personalizadas
iptables -L SIP_TRAFFIC -n -v
iptables -L RTP_TRAFFIC -n -v

Monitorear Logs en Tiempo Real

# Ver intentos de ataque bloqueados
tail -f /var/log/messages | grep -E 'SIP flood|RTP flood|SSH brute|SYN flood'

# Estadísticas de eventos de seguridad
grep -E 'SIP flood|RTP flood|SSH brute' /var/log/messages | \
    awk '{print $5}' | sort | uniq -c | sort -rn

Ajustar Límites según Carga Real

Monitorea el uso real durante 1-2 semanas y ajusta los límites:

# Ver conexiones activas por puerto
netstat -an | grep -E '5060|5061|:2[0-9]{4}' | wc -l

# Ver paquetes por segundo aproximados
iptables -L SIP_TRAFFIC -n -v -x | grep 'pkts'

Si observas muchos paquetes legítimos siendo bloqueados, incrementa los límites gradualmente.

Consideraciones de Seguridad Adicionales

Esta configuración de IPtables es solo una capa de tu estrategia de seguridad. También debes:

Fail2ban: Implementar fail2ban específicamente configurado para Asterisk
Listas blancas: Si conoces las IPs de tus proveedores SIP, permítelas explícitamente
Autenticación fuerte: Contraseñas complejas para extensiones SIP
Actualización: Mantén Asterisk y AlmaLinux actualizados
Monitoreo CDR: Revisa regularmente los Call Detail Records buscando patrones anómalos
Segmentación: Coloca Asterisk en una VLAN separada si es posible

Troubleshooting Común

Problema: Llamadas se cortan después de 30-60 segundos

# Verificar que conntrack no está descartando sesiones RTP
cat /proc/sys/net/netfilter/nf_conntrack_udp_timeout
# Aumentar si es necesario
echo 180 > /proc/sys/net/netfilter/nf_conntrack_udp_timeout

Problema: No se pueden registrar teléfonos

# Verificar que SIP_TRAFFIC está aceptando paquetes
iptables -L SIP_TRAFFIC -n -v

# Ver en logs qué se está bloqueando
tail -50 /var/log/messages | grep SIP

Problema: Tabla de conexiones llena

# Aumentar tamaño de tabla conntrack
echo 65536 > /proc/sys/net/netfilter/nf_conntrack_max

# Hacer permanente en sysctl.conf
echo "net.netfilter.nf_conntrack_max = 65536" >> /etc/sysctl.conf

Conclusión

Esta configuración proporciona protección robusta contra los ataques más comunes dirigidos a servidores Asterisk PBX, incluyendo:

Floods de registro SIP
Ataques de fuerza bruta contra extensiones
DDoS/DoS a nivel de red y aplicación
Escaneo de puertos y fingerprinting
Explotación de vulnerabilidades del stack TCP/IP

Los límites configurados son conservadores y adecuados para la mayoría de implementaciones pequeñas a medianas (hasta 100 llamadas simultáneas). Para instalaciones más grandes, ajusta los valores de rate limiting proporcionalmente a tu capacidad y carga esperada.

Recuerda que la seguridad es un proceso continuo: monitorea logs regularmente, mantén el sistema actualizado y ajusta las reglas según evolucionen las amenazas y tu infraestructura.

Nota importante: Antes de aplicar estas reglas en producción, pruébalas en un entorno de desarrollo o durante una ventana de mantenimiento. Un error en la configuración podría bloquear todo el tráfico legítimo.

Vota el Articulo:

January 07, 2026

Andrea Sannucci Servidor de Privacidad - Privacy Server

En una era donde nuestros datos personales son la moneda más valiosa de internet, la dependencia de servicios centralizados de grandes corporaciones plantea serias interrogantes sobre privacidad, soberanía digital y autonomía personal. El proyecto privacy_server ofrece una alternativa concreta: un servidor personal que permite recuperar el control sobre la información más sensible de nuestra vida digital.

Privacy_server es una solución automatizada diseñada específicamente para AlmaLinux 10 que despliega una infraestructura completa de servicios esenciales mediante scripts de instalación. En lugar de confiar tus comunicaciones, archivos y datos a terceros, este sistema te convierte en el custodio de tu propia información.

El servidor instala y configura automáticamente los siguientes componentes:

Sistema Base Endurecido

SSH hardening: Puerto personalizado (10909), acceso solo root con claves RSA, autenticación por contraseña deshabilitada
Firewall NFTables: Configuración restrictiva con políticas DROP por defecto
Certificados TLS: Let's Encrypt con renovación automática para todos los servicios

OpenVPN

Servidor VPN completo con autenticación PAM integrada con usuarios del sistema. Permite conectarte de forma segura a tu red desde cualquier ubicación, cifrando todo el tráfico.

Servidor de Correo Completo

Stack completo que incluye:

Postfix: MTA para envío y recepción de correo
Dovecot: Servidor IMAP/POP3 para acceso a buzones
OpenDKIM: Firma digital de correos salientes
SpamAssassin: Filtrado anti-spam
Configuración DNS automática: SPF, DKIM y DMARC

Nextcloud

Plataforma de almacenamiento en la nube y colaboración que incluye:

Gestión de archivos
Calendarios y contactos
Aplicación de correo integrada
Sincronización multiplataforma
Compartición de archivos

Matrix Synapse

Servidor de mensajería instantánea federada y cifrada end-to-end. Alternativa descentralizada a servicios como WhatsApp o Telegram con control total sobre tus conversaciones.

Coturn

Servidor TURN/STUN necesario para establecer comunicaciones WebRTC, permitiendo videollamadas y llamadas de voz peer-to-peer a través de firewalls y NATs.

Ventajas Fundamentales

1. Soberanía Digital Real

Al instalar este servidor, eliminas intermediarios en tus comunicaciones más importantes. Tus correos no pasan por servidores de Gmail. Tus archivos no residen en Dropbox. Tus mensajes no atraviesan servidores de Meta. Eres el único con acceso físico a tus datos.

2. Privacidad por Diseño

La arquitectura del sistema garantiza que:

No hay análisis de contenido con fines publicitarios
Ninguna entidad externa procesa tus metadatos
Las comunicaciones están cifradas (TLS 1.2+ obligatorio)
No existe perfilado algorítmico de tu comportamiento
Matrix ofrece cifrado end-to-end para mensajería

3. Automatización Completa

El script de instalación:

Configura todos los servicios de forma interactiva
Genera contraseñas seguras automáticamente
Crea certificados SSL/TLS vía Let's Encrypt
Configura el firewall restrictivamente
Envía emails con credenciales de cada usuario
Documenta todo el proceso

4. Control Total sobre Actualizaciones y Configuración

Decides cuándo y cómo actualizar cada servicio. Puedes personalizar cada aspecto de la configuración según tus necesidades específicas sin estar sujeto a cambios arbitrarios de términos de servicio o políticas de privacidad.

5. Independencia de Proveedores Comerciales

Eliminas la dependencia de:

Suscripciones mensuales que pueden cambiar de precio arbitrariamente
Servicios que pueden discontinuarse sin previo aviso
Términos de servicio que se modifican unilateralmente
Restricciones artificiales de almacenamiento o funcionalidades
Análisis de tu contenido para entrenar modelos de IA

6. Resiliencia ante Censura y Bloqueos

Al controlar tu propia infraestructura:

Tus servicios no pueden ser bloqueados selectivamente por proveedores
No estás sujeto a políticas de moderación de contenido de terceros
Mantienes comunicación incluso si servicios comerciales fallan o son restringidos
La federación de Matrix permite comunicación entre servidores independientes

7. Costos Predecibles a Largo Plazo

Después de la inversión inicial en hardware o VPS, los costos se limitan a:

Consumo eléctrico (hardware local) o alquiler de servidor
Conexión a internet (que probablemente ya tienes)
Registro de dominio (~$10-15/año)

Comparado con suscripciones a Google Workspace, Microsoft 365, Dropbox, y servicios similares, el ahorro a largo plazo es considerable.

Consideraciones sobre el Grado de Privacidad

Lo que privacy_server SÍ garantiza:

Control físico: Los datos residen en hardware bajo tu control directo (o en un VPS que controlas)
Sin minería de datos: Ninguna corporación analiza tu contenido para publicidad o IA
Transparencia: Software open source auditable (Nextcloud, Matrix, Postfix, etc.)
Cifrado robusto: TLS 1.2+ obligatorio, Matrix con E2EE, OpenVPN con cifrado fuerte
Autenticación fuerte: SSH solo con claves RSA, sin passwords
Sin terceros: Tus comunicaciones no pasan por servidores corporativos

Lo que NO puede garantizar completamente:

Anonimato absoluto: Tu IP y metadatos de red siguen siendo visibles para tu ISP y receptores de correo
Seguridad sin mantenimiento: Requiere actualizaciones regulares y monitoreo de seguridad
Protección contra amenazas estatales sofisticadas: Actores con recursos suficientes podrían comprometer el hardware físicamente o mediante ataques dirigidos
Privacidad de comunicaciones externas: Al comunicarte con usuarios en Gmail, sus servidores procesan esa comunicación; al federarte con otros servidores Matrix, dependen de su seguridad
Protección contra ataques de red: DDoS y otros ataques pueden afectar disponibilidad

Mejores Prácticas para Maximizar la Privacidad:

Usar VPN adicional o Tor para ofuscar tu dirección IP real al acceder al servidor
Implementar autenticación de dos factores en Nextcloud y otros servicios
Mantener actualizaciones regulares del sistema y todos los servicios
Monitorear logs regularmente para detectar intentos de intrusión
Realizar backups cifrados en ubicaciones separadas
Usar contraseñas únicas y fuertes para cada servicio y usuario
Habilitar Fail2Ban para protección contra fuerza bruta
Configurar SELinux en modo enforcing una vez verificado el funcionamiento

Requisitos Técnicos

Hardware Mínimo Recomendado:

CPU: 2 núcleos (4 recomendado)
RAM: 4GB mínimo (8GB recomendado)
Almacenamiento: 40GB mínimo (depende del uso previsto)
Red: IP pública estática
Sistema Operativo: AlmaLinux 10 (recién instalado)

Conocimientos Necesarios:

Familiaridad con línea de comandos Linux
Comprensión básica de redes (puertos, DNS, certificados)
Capacidad de configurar registros DNS
Disposición para mantener y actualizar el sistema

Configuración DNS Requerida:

Antes de la instalación, necesitas configurar estos registros:

# Registros A
tudominio.com           IN  A       TU_IP_PUBLICA
mail.tudominio.com      IN  A       TU_IP_PUBLICA
cloud.tudominio.com     IN  A       TU_IP_PUBLICA
vpn.tudominio.com       IN  A       TU_IP_PUBLICA
stun.tudominio.com      IN  A       TU_IP_PUBLICA

# MX para correo
tudominio.com           IN  MX  10  mail.tudominio.com.

# SPF
tudominio.com           IN  TXT     "v=spf1 mx ~all"

# SRV para Matrix (federación)
_matrix._tcp.tudominio.com  IN  SRV  10 0 8448 tudominio.com.

Proceso de Instalación

1. Clonar el Repositorio

dnf -y install git
cd /usr/src
git clone https://github.com/voztovoice/privacy_server.git
cd privacy_server
chmod +x privacy_server_installer.sh create_user.sh

2. Ejecutar el Instalador

./privacy_server_installer.sh

El script solicita de forma interactiva:

Dominio principal
Email administrativo
IP pública (detecta automáticamente)
Interfaz de red (detecta y confirma)
Zona horaria
Nombre de organización (para certificados VPN)
Confirmación de contraseña maestra generada

3. Automatización del Proceso

Durante la instalación, el script:

Configura el sistema base con políticas de seguridad
Instala y configura todos los servicios
Genera certificados SSL/TLS con Let's Encrypt
Crea una contraseña maestra segura
Configura el firewall con reglas restrictivas
Envía un email al administrador con todas las credenciales

4. Crear Usuarios

Una vez completada la instalación:

./create_user.sh

Este script:

Crea el usuario en el sistema Linux
Configura su buzón de correo
Crea su cuenta en Nextcloud
Registra su usuario en Matrix Synapse
Genera su archivo de configuración OpenVPN
Envía un email al usuario con todas sus credenciales

Estructura Post-Instalación

/etc/privacy_server/
├── config.env                      # Configuración centralizada
└── credentials/
    ├── admin_credentials.txt       # Credenciales administrador
    └── users/
        └── usuario.txt             # Credenciales por usuario

/etc/openvpn/client/
└── tudominio.ovpn                  # Configuración VPN

/home/data/                         # Datos de Nextcloud
└── usuario/
    └── files/
        └── VPN_Config.ovpn         # VPN copiada automáticamente

/var/log/
├── privacy_server_install.log      # Log de instalación
├── openvpn.log
├── maillog
└── synapse/homeserver.log

Puertos Configurados

Puerto	Protocolo	Servicio
12999	TCP	SSH (no estándar por seguridad)
25/587	TCP	SMTP
993	TCP	IMAPS
443	TCP	HTTPS (Nextcloud)
1194	UDP	OpenVPN
3478-3479	UDP/TCP	TURN/STUN (Coturn)
8448	TCP	Matrix Federation
49152-65535	UDP	RTP (WebRTC)

Mantenimiento y Operación

Gestión de Usuarios

Cada usuario recibe automáticamente:

Cuenta de correo (usuario@tudominio.com)
Acceso a Nextcloud (https://cloud.tudominio.com)
Usuario Matrix (@usuario:tudominio.com)
Configuración OpenVPN en su Nextcloud
Email con instrucciones detalladas

Backups

Es fundamental implementar una estrategia de backup:

# Nextcloud data
rsync -av /home/data/ /backup/nextcloud_data/

# Base de datos Nextcloud
mysqldump -u root -p nextcloud > /backup/nextcloud.sql

# Matrix database
sqlite3 /etc/synapse/homeserver.db ".backup '/backup/matrix.db'"

# Correos
tar -czf /backup/mail.tar.gz /var/mail

# Configuraciones
tar -czf /backup/configs.tar.gz /etc/privacy_server /etc/openvpn

Actualizaciones

# Sistema operativo
dnf update -y

# Nextcloud
sudo -u apache php /var/www/nextcloud/occ upgrade

# Matrix Synapse
pip3 install --upgrade matrix-synapse
systemctl restart synapse

Conclusión: Una Decisión Filosófica y Práctica

Instalar un servidor de privacidad personal no es meramente una decisión técnica, sino una declaración de principios sobre cómo entendemos nuestra relación con la tecnología y los datos:

Representa la elección consciente de:

Asumir responsabilidad sobre tu información digital en lugar de delegarla
Rechazar el modelo de vigilancia inherente a servicios "gratuitos" que monetizan datos
Recuperar autonomía en un ecosistema tecnológico diseñado para generar dependencia
Invertir tiempo y esfuerzo en algo que consideras valioso: tu privacidad

Acepta las siguientes realidades:

La privacidad absoluta es una ilusión en el mundo interconectado actual
Requiere compromiso, aprendizaje continuo y mantenimiento activo
No es una solución "instala y olvida"
Parte de tus comunicaciones seguirán dependiendo de terceros (cuando te comunicas con usuarios externos)

Pero ofrece algo más valioso que perfección: control

En la arquitectura de poder de internet contemporáneo, el control sobre tu propia infraestructura digital es el primer paso hacia una verdadera soberanía tecnológica. No es una solución para todos, pero para quienes valoran la privacidad no como concepto abstracto sino como práctica concreta, representa una de las mejores opciones disponibles.

Privacy_server no te promete invisibilidad ni anonimato perfecto. Te ofrece algo más honesto y alcanzable: la capacidad de decidir por ti mismo qué información compartir, con quién, y bajo qué condiciones. En un mundo donde esas decisiones las toman algoritmos corporativos diseñados para maximizar engagement y extracción de datos, recuperar ese poder de decisión es, en sí mismo, un acto de resistencia digital.

¿Es para todos? No. ¿Es perfecto? No. ¿Vale la pena? Si valoras tu privacidad y estás dispuesto a invertir en ella, absolutamente sí.

Proyecto: privacy_server en GitHub
Licencia: GPL-3.0
Sistema requerido: AlmaLinux 10

Vota el Articulo:

January 06, 2026

Andrea Sannucci Microservicios: La Revolución de Construir Software Moderno
Imagina que estás construyendo una casa. ¿Qué preferirías: construir toda la casa como un enorme bloque de hormigón macizo, o ensamblarla con piezas individuales (paredes, techo, puertas, ventanas) que puedes cambiar o mejorar independientemente? Esta es, en esencia, la diferencia entre el software tradicional (monolítico) y los microservicios.

En este artículo, te explicaré qué son los microservicios, por qué se han vuelto tan populares y cómo están transformando la forma en que se construyen las aplicaciones que usamos cada día.

¿Qué son los Microservicios?

Los microservicios son un estilo de arquitectura de software donde una aplicación grande se divide en pequeños servicios independientes, cada uno responsable de una función específica del negocio. Cada microservicio es como un pequeño programa que:

Hace una sola cosa bien: Por ejemplo, gestionar usuarios, procesar pagos, enviar notificaciones, etc.

Funciona de forma independiente: Puede ejecutarse, actualizarse y fallar sin afectar a los demás

Se comunica con otros: Habla con otros microservicios cuando necesita algo de ellos

Una Analogía del Mundo Real

Piensa en un restaurante moderno:

Modelo tradicional (monolítico): Una sola persona hace TODO - toma pedidos, cocina, sirve, cobra y limpia. Si esa persona se enferma, el restaurante cierra completamente.

Modelo de microservicios: Tienes un equipo especializado:

Camarero: Toma pedidos (microservicio de pedidos)

Cocinero: Prepara la comida (microservicio de cocina)

Cajero: Procesa pagos (microservicio de pagos)

Limpieza: Mantiene limpio (microservicio de mantenimiento)

Si el cajero se va, el restaurante sigue funcionando - solo no pueden cobrar temporalmente. Además, si hay más gente, puedes contratar más camareros sin necesidad de contratar más cocineros.

¿Cómo Era Antes? El Software Monolítico

Antes de los microservicios, la mayoría del software se construía como un monolito: una única aplicación grande donde todo el código está junto en un solo programa.

Ejemplo práctico

Imagina una tienda online tradicional (monolítica):

┌─────────────────────────────────────┐ │ APLICACIÓN MONOLÍTICA │ │ │ │ - Catálogo de productos │ │ - Carrito de compras │ │ - Gestión de usuarios │ │ - Sistema de pagos │ │ - Envío de emails │ │ - Gestión de inventario │ │ - Recomendaciones │ │ │ │ (Todo en un solo código) │ └─────────────────────────────────────┘
Problemas del monolito:

Cambios arriesgados: Si quieres mejorar el sistema de recomendaciones, tienes que volver a desplegar TODA la aplicación, arriesgándote a romper el sistema de pagos accidentalmente.

Difícil de escalar: Si necesitas más capacidad para el catálogo (porque hay muchos visitantes), tienes que escalar TODA la aplicación, incluso las partes que no lo necesitan.

Equipos bloqueados: Todos los desarrolladores trabajan en el mismo código, pisándose entre sí y creando conflictos.

Tecnología atada: Estás casado con la tecnología que elegiste al inicio. Si quieres usar algo nuevo, tienes que reescribir todo.

La Arquitectura de Microservicios

Ahora veamos la misma tienda online pero con microservicios:

┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ Catálogo │ │ Carrito │ │ Usuarios │ │ Service │ │ Service │ │ Service │ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │ │ │ └────────────────┼────────────────┘ │ ┌────────────────┼────────────────┐ │ │ │ ┌──────▼──────┐ ┌──────▼──────┐ ┌──────▼──────┐ │ Pagos │ │ Emails │ │ Inventario │ │ Service │ │ Service │ │ Service │ └─────────────┘ └─────────────┘ └─────────────┘
Cada rectángulo es un microservicio independiente que:

Se puede desarrollar por un equipo diferente

Puede usar la tecnología más adecuada para su función

Se puede desplegar y actualizar sin tocar los demás

Se puede escalar según su demanda específica

Ventajas de los Microservicios

1. Desarrollo Ágil y Rápido

Antes (monolito): Equipo de 50 personas trabajando en el mismo código, pisándose entre sí. Cada cambio requiere coordinación masiva.

Con microservicios: 10 equipos de 5 personas, cada uno trabajando en su microservicio. El equipo de pagos puede lanzar mejoras sin esperar a que el equipo de catálogo termine.

Ejemplo real: Netflix tiene más de 700 microservicios. Mientras un equipo mejora el sistema de recomendaciones, otro está arreglando la reproducción de video, sin interferencias.

2. Escalabilidad Inteligente

Problema típico: Es Black Friday y tu tienda online recibe 10 veces más tráfico de lo normal en el catálogo de productos, pero los pagos siguen igual.

Con monolito: Tienes que escalar TODA la aplicación, desperdiciando recursos en partes que no lo necesitan.

Con microservicios: Solo escalas el microservicio del catálogo, multiplicando solo esa parte por 10 mientras el resto sigue igual. Ahorras dinero y recursos.

Tráfico normal: Catálogo: 2 servidores Pagos: 1 servidor Black Friday: Catálogo: 20 servidores ← Solo escalas esto Pagos: 1 servidor ← Esto sigue igual
3. Resiliencia y Disponibilidad

Con monolito: Si hay un bug en el sistema de recomendaciones que hace crashear la aplicación, TODA tu tienda se cae. No puedes vender nada.

Con microservicios: Si el servicio de recomendaciones falla, el resto sigue funcionando. Tus clientes pueden seguir navegando, añadiendo al carrito y comprando. Solo no verán recomendaciones temporalmente.

Esta es la filosofía de "fallar graciosamente" (graceful degradation).

4. Libertad Tecnológica

Cada microservicio puede usar la mejor tecnología para su propósito:

Microservicio de Búsqueda: Usa Elasticsearch (especializado en búsquedas rápidas)

Microservicio de Pagos: Usa Java (robusto y seguro para transacciones)

Microservicio de Recomendaciones: Usa Python con machine learning

Microservicio de Chat en Vivo: Usa Node.js (excelente para tiempo real)

En un monolito, tendrías que elegir UNA tecnología para todo.

5. Despliegues sin Miedo

Escenario típico con monolito:

Son las 2 AM del domingo (para minimizar impacto)

Todo el equipo está en alerta

Se despliega la nueva versión completa

Si algo falla, pánico total - rollback de emergencia

Vuelta a la versión antigua de TODO

Con microservicios:

Es martes a las 3 PM

Solo el equipo del microservicio que se actualiza está atento

Se despliega solo ese microservicio

Si falla, solo afecta a esa función

Rollback rápido de solo ese servicio

El resto de la aplicación ni se entera

Desventajas y Desafíos

No todo es color de rosa. Los microservicios traen su propia complejidad:

1. Complejidad Operacional

Antes: Gestionabas 1 aplicación Ahora: Gestionas 50 microservicios

Necesitas herramientas y estrategias para:

Monitorear 50 servicios en lugar de 1

Ver logs distribuidos en múltiples servicios

Mantener comunicación entre todos ellos

Gestionar versiones de 50 componentes

2. Comunicación Entre Servicios

Los microservicios necesitan hablarse entre sí, y esto introduce:

Latencia de red: Cada llamada entre servicios toma tiempo

Fallos de red: ¿Qué pasa si un servicio no puede hablar con otro?

Complejidad de debugging: Un error puede estar en la cadena de 5 servicios hablándose

Ejemplo: Para mostrar la página de un producto necesitas:

Servicio de Catálogo (datos del producto)

Servicio de Inventario (disponibilidad)

Servicio de Precios (precio actual)

Servicio de Recomendaciones (productos similares)

Servicio de Reseñas (opiniones de clientes)

Si uno falla, ¿qué muestras al usuario?

3. Transacciones Distribuidas

Problema clásico: Un usuario compra el último artículo disponible.

Con monolito:

BEGIN TRANSACTION 1. Reducir inventario (-1) 2. Crear pedido 3. Cargar tarjeta COMMIT
Si algo falla, se revierte todo automáticamente.

Con microservicios:

1. Llamar a Inventario → Reducir stock 2. Llamar a Pedidos → Crear pedido 3. Llamar a Pagos → Cargar tarjeta ← FALLA
¿Cómo deshaces el cambio en inventario si el pago falló? No hay un "rollback" automático.

4. Testing Más Complejo

Para probar tu aplicación completa ahora necesitas:

50 microservicios corriendo

Todas sus bases de datos

Todas sus dependencias

Esto requiere herramientas sofisticadas de testing y ambientes de desarrollo complejos.

¿Cuándo Usar Microservicios?

✅ Deberías considerar microservicios si:

Tu aplicación es grande y compleja: Más de 10-15 desarrolladores trabajando en ella

Diferentes partes tienen diferentes demandas de escalado: El catálogo recibe 100x más tráfico que los pagos

Necesitas desplegar frecuentemente: Varias veces al día o semana

Diferentes equipos trabajan en diferentes funcionalidades: Equipos autónomos

Tu negocio está creciendo rápidamente: Netflix, Uber, Amazon son ejemplos clásicos

❌ NO uses microservicios si:

Tu aplicación es pequeña: Menos de 5 desarrolladores

Estás empezando un nuevo proyecto: Comienza simple, migra después si es necesario

No tienes infraestructura DevOps madura: Necesitas herramientas de CI/CD, monitoring, etc.

Tu equipo no está preparado: Microservicios requieren experiencia en sistemas distribuidos

No tienes problemas de escalabilidad: Si tu monolito funciona bien, ¿para qué cambiarlo?

Casos de Uso Reales

Netflix: El Rey de los Microservicios

Netflix empezó como un monolito. En 2008, una corrupción de base de datos los dejó fuera del aire durante 3 días. Decidieron migrar a microservicios.

Resultado:

Más de 700 microservicios

Despliegan cambios miles de veces al día

Pueden escalar cada función independientemente

Si un servicio falla, el resto sigue funcionando

Ejemplo práctico: El servicio de recomendaciones puede estar caído, pero aún puedes buscar, navegar y reproducir contenido.

Uber: Movilidad a Escala Global

Uber comenzó con un monolito pero creció tan rápido que era imposible de mantener.

Microservicios clave de Uber:

Servicio de Geolocalización: Rastrea conductores en tiempo real

Servicio de Matching: Conecta pasajeros con conductores

Servicio de Precios: Calcula tarifas dinámicas

Servicio de Pagos: Procesa transacciones

Servicio de Notificaciones: Envía alertas

Cada uno puede escalar independientemente según la demanda de cada ciudad.

Amazon: El Pionero

Amazon fue uno de los primeros en adoptar microservicios a principios de los 2000.

Beneficio clave: Equipos pequeños y autónomos (las famosas "two-pizza teams" - equipos que se pueden alimentar con dos pizzas) que pueden innovar rápidamente sin depender de otros.

Tecnologías Comunes en Microservicios

Contenedores (Docker)

Los microservicios normalmente se empaquetan en contenedores - pequeñas cajas que contienen todo lo necesario para ejecutar el servicio.

Ventaja: Puedes ejecutar 50 microservicios en el mismo servidor, cada uno en su propio contenedor, sin que se interfieran.

┌─────────────────────────────────────────┐ │ Servidor │ │ │ │ ┌──────────┐ ┌──────────┐ ┌───────┐ │ │ │Container │ │Container │ │Container │ │ │Catálogo │ │Pagos │ │Emails │ │ └──────────┘ └──────────┘ └───────┘ │ └─────────────────────────────────────────┘
Orquestadores (Kubernetes)

Cuando tienes cientos de contenedores, necesitas algo que los gestione automáticamente. Kubernetes es como un director de orquesta que:

Inicia y detiene contenedores

Distribuye carga entre ellos

Reinicia los que fallan

Escala automáticamente según demanda

API Gateways

Un API Gateway es la puerta de entrada a tus microservicios. Es como la recepcionista de un edificio grande que sabe a qué piso enviarte.

Usuario → API Gateway → Dirige al microservicio correcto
Service Mesh

Cuando tienes muchos microservicios hablándose entre sí, un service mesh gestiona toda esa comunicación:

Encripta conexiones

Balancea carga

Detecta fallos

Registra todas las comunicaciones

Patrones Comunes en Microservicios

1. API Gateway Pattern

Todo el tráfico externo pasa por un punto de entrada que:

Autentica usuarios

Dirige peticiones al microservicio correcto

Combina respuestas de múltiples servicios

2. Database per Service

Cada microservicio tiene su propia base de datos. Nadie más puede acceder directamente a ella.

¿Por qué? Para mantener la independencia. Si el servicio de pagos y el de usuarios comparten base de datos, cambiar la estructura de una tabla afectaría a ambos.

3. Event-Driven Architecture

Los microservicios se comunican mediante eventos en lugar de llamadas directas.

Ejemplo:

Usuario hace pedido → Servicio de Pedidos publica evento "Pedido Creado" → Servicio de Inventario lo escucha y reduce stock → Servicio de Emails lo escucha y envía confirmación → Servicio de Notificaciones lo escucha y alerta al vendedor
Ventaja: Los servicios no necesitan conocerse entre sí, solo escuchan eventos que les interesan.

4. Circuit Breaker

Imagina que el servicio de recomendaciones está caído. En lugar de seguir intentando llamarlo (y fallando), el circuit breaker "abre el circuito" y:

Deja de intentar por un tiempo

Devuelve una respuesta por defecto o caché

Intenta de nuevo después de un tiempo prudencial

Es como un fusible eléctrico que se corta para evitar daños mayores.

5. Saga Pattern

Para gestionar transacciones distribuidas, el patrón Saga divide una transacción grande en pasos pequeños, cada uno con su compensación:

Compra de producto: 1. Reservar inventario (compensación: liberar reserva) 2. Cobrar pago (compensación: reembolsar) 3. Crear pedido (compensación: cancelar pedido) 4. Notificar vendedor (compensación: notificar cancelación)
Si algún paso falla, se ejecutan las compensaciones en orden inverso.

Migración de Monolito a Microservicios

Si tienes un monolito y quieres migrar a microservicios, aquí está la estrategia recomendada:

Patrón "Strangler Fig"

Como la higuera estranguladora que crece alrededor de un árbol, vas reemplazando piezas del monolito gradualmente:

Fase 1: Identificar una función independiente (ej: sistema de notificaciones)

┌─────────────────┐ │ MONOLITO │ │ │ │ - Catálogo │ │ - Carrito │ │ - Usuarios │ │ - Pagos │ │ - Emails ←────┼─── Extraer esto primero └─────────────────┘
Fase 2: Crear microservicio de emails y redirigir tráfico

┌─────────────────┐ ┌──────────────┐ │ MONOLITO │ ────→ │ Microservicio│ │ │ │ Emails │ │ - Catálogo │ └──────────────┘ │ - Carrito │ │ - Usuarios │ │ - Pagos │ └─────────────────┘
Fase 3: Eliminar código de emails del monolito

Fase 4: Repetir con la siguiente función

Ventajas de esta Estrategia

Bajo riesgo: Migras de a poco, no todo a la vez

Aprendizaje continuo: Tu equipo aprende con cada migración

Valor inmediato: Obtienes beneficios desde la primera extracción

Reversible: Si algo sale mal, puedes volver atrás fácilmente

Mejores Prácticas

1. Comienza con Dominios de Negocio

No dividas por capas técnicas (frontend, backend, database), divide por funciones de negocio:

❌ Mal: Microservicio de "Base de Datos de Usuarios" ✅ Bien: Microservicio de "Gestión de Cuentas de Usuario"

2. Define Contratos Claros

Cada microservicio debe tener una API bien documentada que no cambie sin previo aviso.

Versionado de APIs:

v1/usuarios ← Versión antigua, se mantiene por compatibilidad v2/usuarios ← Versión nueva, con nuevas funciones
3. Automatiza TODO

Con microservicios, la automatización no es opcional:

Testing automatizado: Cada commit debe pasar tests

Despliegue automatizado: Push a producción con un click

Monitoreo automatizado: Alertas si algo va mal

Escalado automatizado: Más tráfico = más instancias automáticamente

4. Logging y Monitoreo Centralizado

Con 50 servicios, no puedes revisar logs en 50 lugares diferentes.

Herramientas comunes:

ELK Stack (Elasticsearch, Logstash, Kibana): Para logs centralizados

Prometheus + Grafana: Para métricas y dashboards

Jaeger/Zipkin: Para rastrear peticiones a través de múltiples servicios

5. Seguridad en Cada Capa

Cada microservicio debe:

Autenticar quién lo llama

Autorizar qué puede hacer

Encriptar comunicaciones

Validar toda entrada

No asumas que por estar "dentro" de tu red, las comunicaciones son seguras.

6. Design for Failure

En un sistema distribuido, los fallos son inevitables. Diseña asumiendo que:

La red puede fallar

Otros servicios pueden estar caídos

Las respuestas pueden tardar mucho

Implementa:

Timeouts

Reintentos con backoff exponencial

Circuit breakers

Fallbacks y valores por defecto

El Futuro: Serverless y Function-as-a-Service

La siguiente evolución son las funciones serverless, donde ni siquiera gestionas servidores:

Microservicio tradicional: - Corre 24/7 esperando peticiones - Pagas por el servidor todo el tiempo - Gestionas escalado manualmente Función Serverless: - Solo ejecuta cuando se necesita - Pagas solo por las ejecuciones - Escala automáticamente de 0 a millones
Ejemplos: AWS Lambda, Google Cloud Functions, Azure Functions

Conclusión

Los microservicios no son una bala de plata que resuelve todos los problemas. Son una herramienta poderosa que, cuando se usa correctamente en el contexto adecuado, puede:

Acelerar el desarrollo permitiendo que equipos trabajen independientemente

Mejorar la escalabilidad escalando solo lo que necesitas

Aumentar la resiliencia aislando fallos

Facilitar la innovación permitiendo usar diferentes tecnologías

Pero también traen complejidad operacional que requiere:

Equipos experimentados

Herramientas maduras de DevOps

Procesos bien definidos

Infraestructura robusta

Regla de Oro

Empieza simple con un monolito. Cuando el monolito se vuelva un problema real (no hipotético), entonces considera microservicios. La sobre-ingeniería prematura es peor que la infraestructura inadecuada.

Recursos para Seguir Aprendiendo

Libros recomendados:

"Building Microservices" de Sam Newman

"Microservices Patterns" de Chris Richardson

Cursos online:

Microservices Architecture en Coursera

Docker and Kubernetes: The Complete Guide (Udemy)

Comunidades:

CNCF (Cloud Native Computing Foundation)

Meetups locales de DevOps y Cloud

Experimenta:

Crea un proyecto pequeño con 2-3 microservicios

Usa Docker para contenerizar

Despliega en un cloud provider gratuito

Palabras Finales

Los microservicios representan un cambio fundamental en cómo pensamos sobre arquitectura de software. No son solo una moda pasajera - son la respuesta natural a las demandas de sistemas modernos que necesitan:

Escalar masivamente (millones de usuarios)

Cambiar rápidamente (innovación constante)

Estar siempre disponibles (99.99% uptime)

Adaptarse a nuevas tecnologías

Si estás construyendo el próximo Netflix, Uber o Amazon, los microservicios son probablemente el camino. Si estás construyendo una aplicación interna para 100 usuarios, un monolito bien diseñado es perfectamente adecuado.

La clave es elegir la arquitectura correcta para tu contexto específico, no seguir ciegamente las tendencias del momento.

¿Tienes dudas sobre microservicios? ¿Estás considerando migrar tu aplicación? Déjame tus preguntas en los comentarios.

Sobre el Autor: Claude es una IA especializada en arquitecturas distribuidas y sistemas de telecomunicaciones.
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

January 05, 2026

Andrea Sannucci Rendimiento de OpenSSL: Cuatro Años Después, ¿Hemos Superado la Crisis?
Cuando OpenSSL 3 fue lanzado por primera vez, prometía ser un punto de inflexión. Después de casi treinta años de desarrollo, esta versión estaba destinada a traer mejoras significativas y modernizar el proyecto. Sin embargo, lo que llegó fueron regresiones de rendimiento tan graves que prácticamente inutilizaron la biblioteca para cualquier despliegue de alto volumen. Para empeorar las cosas, la rama estable anterior (1.1.1) fue deprecada rápidamente, dejando a los operadores sin una alternativa viable.

Durante mucho tiempo, este problema fue un secreto a voces. Existían issues en el tracker de OpenSSL, pero solo quienes experimentaban directamente los problemas de rendimiento los encontraban. Fue necesario que los desarrolladores de HAProxy escribieran un artículo extenso sobre el estado de las bibliotecas SSL en general —y OpenSSL en particular— para que el mensaje quedara claro: si te importa el rendimiento, mantente alejado de OpenSSL 3.x.

Este año, en la conferencia inaugural de OpenSSL, varias presentaciones proporcionaron contexto sobre las regresiones de rendimiento y otros cambios en la rama 3.x:

William Bellingrath (Juniper Networks) compartió datos de rendimiento exhaustivos comparando OpenSSL desde la versión 1.1.1 hasta la 3.4, incluyendo algunos adelantos sobre la 3.5.

Tomáš Mráz, desarrollador de OpenSSL, ofreció consejos prácticos sobre cómo optimizar el rendimiento de OpenSSL 3.x.

Alex Gaynor y Paul Kehrer, mantenedores de la biblioteca cryptography de Python, compartieron su experiencia migrando su código desde 1.1.1 a la rama 3.x.

Martin Schmatz (IBM Research) presentó los resultados de las pruebas extensivas de IBM sobre OpenSSL 3.5.3, enfocándose en comprender el impacto de rendimiento de la criptografía post-cuántica.

Después de cuatro años de mejoras continuas, OpenSSL 3.5.x parece estar finalmente en una forma razonablemente aceptable. El rendimiento es ahora comparable —por fin— al de la antigua rama 1.1.1. Sin embargo, todavía existen muchas oportunidades de optimización sin explotar.

Esta mejora llega en un momento crucial: estamos en medio de una transición masiva hacia la criptografía post-cuántica. Las principales distribuciones Linux han elegido OpenSSL 3.5.x como la versión base para esta migración:

Debian 13 Trixie (lanzado en agosto de 2025)

Red Hat Enterprise Linux 10.1 (lanzado en noviembre de 2025)

Ubuntu 26.04 LTS (próximo lanzamiento en abril de 2026)

La criptografía post-cuántica ya tiene un costo de rendimiento inherente por la naturaleza de sus algoritmos. No podemos permitirnos hacerla aún más lenta de lo necesario por problemas de implementación evitables.

Este episodio plantea preguntas fundamentales sobre el desarrollo de infraestructura crítica: ¿Cómo equilibramos la innovación con la estabilidad? ¿Cuándo es aceptable romper la compatibilidad de rendimiento en nombre del progreso? ¿Qué responsabilidad tienen los proyectos de código abierto con los operadores de producción?

OpenSSL es la columna vertebral de la seguridad en internet. Cada decisión de diseño tiene consecuencias que se propagan a millones de sistemas. La historia de OpenSSL 3 nos recuerda que el rendimiento no es un detalle de implementación, sino un requisito arquitectónico.

Para quienes trabajamos con infraestructura VoIP de alto volumen, estas lecciones resuenan especialmente. La latencia y el throughput no son negociables cuando manejas miles de llamadas simultáneas con cifrado TLS/SRTP.

Conclusión

Si bien es reconfortante saber que OpenSSL 3.5.x finalmente está a la altura, esta saga de cuatro años debería servir como recordatorio: en sistemas críticos, el rendimiento debe medirse, no asumirse. Y cuando se trata de criptografía a escala, cada milisegundo cuenta.
- OpenSSL
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

December 31, 2025

Andrea Sannucci PJSIPNotify en Asterisk 20: Control Programático de Mensajes SIP NOTIFY desde el Dialplan

Asterisk 20.10.0 introdujo una característica largamente esperada por la comunidad: la aplicación de dialplan PJSIPNotify. Esta nueva funcionalidad permite enviar mensajes SIP NOTIFY directamente desde el dialplan, eliminando la necesidad de depender exclusivamente del CLI o AMI para esta tarea.

En este artículo exploraremos en profundidad esta nueva capacidad, sus casos de uso prácticos, y cómo implementarla en tus sistemas de producción.

¿Qué es SIP NOTIFY?

Fundamentos del Protocolo

SIP NOTIFY es un método definido en RFC 3265 que permite a un servidor o endpoint SIP informar a suscriptores sobre cambios de estado o eventos específicos. Es el complemento del método SUBSCRIBE: un dispositivo se suscribe a un evento, y el servidor envía NOTIFY cuando ese evento ocurre.

Flujo básico SUBSCRIBE/NOTIFY:

Teléfono SIP              Servidor PBX
    |                          |
    |----SUBSCRIBE MWI-------->|
    |<-------200 OK------------|
    |<------NOTIFY (0 msgs)----|
    |-------200 OK------------>|
    |                          |
    [Llega un mensaje de voz]
    |                          |
    |<------NOTIFY (1 msg)-----|
    |-------200 OK------------>|
    |  [Luz MWI se enciende]   |

Casos de Uso Comunes

Los mensajes NOTIFY se utilizan ampliamente para:

Message Waiting Indicator (MWI): Indicador luminoso de mensajes de voz
Busy Lamp Field (BLF): Estado de otras extensiones (ocupado/libre/sonando)
Presence: Estado de disponibilidad de usuarios
Call Pickup: Notificación de llamadas disponibles para captura
Auto-provisioning: Solicitud de reconfiguration del dispositivo
Custom Events: Eventos personalizados específicos de aplicación

La Limitación Histórica

Antes de Asterisk 20.10.0, enviar mensajes NOTIFY manualmente requería:

Opción 1: Desde CLI

asterisk -rx "pjsip send notify check-voicemail endpoint 1001"

Opción 2: Desde AMI (Asterisk Manager Interface)

Action: PJSIPNotify
Endpoint: 1001
Variable: Event=check-voicemail

Problemas con estos métodos:

No se pueden enviar desde el dialplan durante una llamada activa
Requieren acceso CLI o AMI (problemas de seguridad)
Difícil integración en lógica de llamadas
No se pueden enviar dentro del diálogo SIP actual

PJSIPNotify: La Nueva Aplicación

Sintaxis

PJSIPNotify([to],content)

Parámetros:

to (opcional): URI SIP arbitraria a la que enviar el NOTIFY
- Si se omite, envía dentro del diálogo SIP actual del canal
- Formato: <sip:usuario@dominio:puerto>
content: Contenido del mensaje
- Puede ser una entrada pre-configurada en pjsip_notify.conf
- O una lista de headers especificados en dialplan con formato &Header=Valor

Requisito Importante

Para enviar NOTIFY a URIs arbitrarias (fuera del diálogo actual), debes configurar default_outbound_endpoint en la sección [global] de pjsip.conf:

[global]
default_outbound_endpoint=default-outbound

[default-outbound]
type=endpoint
context=from-internal
disallow=all
allow=ulaw
allow=alaw

Este endpoint determina el contacto del mensaje NOTIFY saliente.

Ejemplos Prácticos

Ejemplo 1: NOTIFY Dentro del Diálogo Actual

Escenario: Enviar un evento personalizado durante una llamada activa.

[test-notify]
exten => 7000,1,Answer()
 same => n,Playback(hello-world)
 same => n,PJSIPNotify(,&Event=Test&X-Data=Fun)
 same => n,Wait(2)
 same => n,Hangup()

Resultado SIP:

NOTIFY sip:1001@192.168.1.10:5060 SIP/2.0
Event: Test
X-Data: Fun
Content-Length: 0

Ejemplo 2: NOTIFY con Configuración Pre-definida

Paso 1: Configurar el template en pjsip_notify.conf

[potato-notify]
Event=>PotatoReport
Content-type=>application/potato-summary
Content=>Num-Potatoes: 23
Content=>Potato-Quality: fair
Content=>

Paso 2: Usar desde dialplan

[potato-report]
exten => 7001,1,Answer()
 same => n,PJSIPNotify(,potato-notify)
 same => n,Hangup()

Resultado SIP:

NOTIFY sip:1001@192.168.1.10:5060 SIP/2.0
Event: PotatoReport
Content-Type: application/potato-summary
Content-Length: 38

Potato-Quality: fair
Num-Potatoes: 23

Ejemplo 3: NOTIFY a URI Arbitraria

Escenario: Enviar notificación a un endpoint específico desde el dialplan.

[notify-endpoint]
exten => 7002,1,Answer()
 same => n,Set(TARGET_URI=<sip:bob@127.0.0.1:5260>)
 same => n,PJSIPNotify(${TARGET_URI},&Event=Custom&X-Message=Hello Bob)
 same => n,Playback(notification-sent)
 same => n,Hangup()

Ejemplo 4: Message Waiting Indicator (MWI)

Configuración en pjsip_notify.conf:

[mwi-update]
Event=>message-summary
Content-type=>application/simple-message-summary
Content=>Messages-Waiting: yes
Content=>Voice-Message: 2/0 (0/0)
Content=>

Dialplan:

[update-mwi]
exten => 8000,1,Answer()
 same => n,Verbose(1,Updating MWI for extension ${EXTEN})
 same => n,PJSIPNotify(,mwi-update)
 same => n,Playback(mwi-updated)
 same => n,Hangup()

Ejemplo 5: Forced Answer (Auto-Answer)

Algunos teléfonos SIP soportan auto-answer mediante NOTIFY con headers especiales.

pjsip_notify.conf:

[force-answer]
Event=>talk
Content-type=>application/x-broadworks-callinfo
Content=>call-info: ;answer-after=0
Content=>

Dialplan - Intercomunicador:

[intercom]
exten => _*80X.,1,NoOp(Intercom to ${EXTEN:3})
 same => n,Set(TARGET_EXTEN=${EXTEN:3})
 same => n,Set(TARGET_URI=<sip:${TARGET_EXTEN}@${SIPDOMAIN}>)
 same => n,PJSIPNotify(${TARGET_URI},force-answer)
 same => n,Wait(1)
 same => n,Dial(PJSIP/${TARGET_EXTEN},30,A(beep))
 same => n,Hangup()

Uso: Marcar *80 + extensión para activar auto-answer en el teléfono destino.

Casos de Uso Avanzados

Caso 1: Sistema de Paging con Auto-Answer

Objetivo: Crear un sistema de paging donde múltiples teléfonos responden automáticamente.

pjsip_notify.conf:

[paging-alert]
Event=>talk
Content-type=>application/x-broadworks-callinfo
Content=>call-info: ;answer-after=0;priority=emergency
Content=>

extensions.conf:

[paging-system]
; Paging a grupo de extensiones
exten => *70,1,Answer()
 same => n,Set(PAGING_GROUP=1001&1002&1003&1004)
 same => n,Playback(paging-announcement)
 same => n,Set(i=1)
 same => n,While($[${i} <= ${FIELDQTY(PAGING_GROUP,&)}])
 same => n,Set(EXTEN=${CUT(PAGING_GROUP,&,${i})})
 same => n,Set(URI=<sip:${EXTEN}@${SIPDOMAIN}>)
 same => n,PJSIPNotify(${URI},paging-alert)
 same => n,Set(i=$[${i} + 1])
 same => n,EndWhile
 same => n,Wait(2)
 same => n,Page(${PAGING_GROUP},,A(beep))
 same => n,Hangup()

Caso 2: Actualización Dinámica de BLF

Objetivo: Actualizar el estado BLF de una extensión cuando cambia su estado de disponibilidad.

pjsip_notify.conf:

[blf-busy]
Event=>dialog
Content-type=>application/dialog-info+xml
Content=><?xml version="1.0"?>
Content=><dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
Content=>  version="1" state="full" entity="sip:${EXTEN}@${SIPDOMAIN}">
Content=>  <dialog id="1">
Content=>    <state>confirmed</state>
Content=>  </dialog>
Content=></dialog-info>
Content=>

[blf-free]
Event=>dialog
Content-type=>application/dialog-info+xml
Content=><?xml version="1.0"?>
Content=><dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
Content=>  version="1" state="full" entity="sip:${EXTEN}@${SIPDOMAIN}">
Content=>  <dialog id="1">
Content=>    <state>terminated</state>
Content=>  </dialog>
Content=></dialog-info>
Content=>

extensions.conf:

[blf-control]
; Marcar *71 para aparecer ocupado
exten => *71,1,Answer()
 same => n,Set(DEVICE_STATE(Custom:DND${CALLERID(num)})=INUSE)
 same => n,PJSIPNotify(,blf-busy)
 same => n,Playback(do-not-disturb&activated)
 same => n,Hangup()

; Marcar *70 para aparecer libre
exten => *70,1,Answer()
 same => n,Set(DEVICE_STATE(Custom:DND${CALLERID(num)})=NOT_INUSE)
 same => n,PJSIPNotify(,blf-free)
 same => n,Playback(do-not-disturb&de-activated)
 same => n,Hangup()

Caso 3: Rechazo Automático de Llamadas (Call Rejection)

Objetivo: Enviar NOTIFY para indicar al teléfono que rechace una llamada entrante automáticamente.

pjsip_notify.conf:

[reject-call]
Event=>call-completion
Content-type=>application/x-call-rejection
Content=>Reject-Reason: busy-everywhere
Content=>

extensions.conf con Lista Negra:

[from-trunk]
exten => _X.,1,NoOp(Incoming call from ${CALLERID(num)})
 same => n,GotoIf($[${BLACKLIST()}=1]?blacklisted:accept)
 same => n(blacklisted),Set(CALLER_URI=<sip:${CALLERID(num)}@${SIPDOMAIN}>)
 same => n,PJSIPNotify(${CALLER_URI},reject-call)
 same => n,Busy(20)
 same => n,Hangup()
 same => n(accept),Dial(PJSIP/${EXTEN})
 same => n,Hangup()

Caso 4: Provisioning Remoto de Teléfonos

Objetivo: Forzar reconfiguration de teléfonos desde el dialplan.

pjsip_notify.conf:

[polycom-check-cfg]
Event=>check-sync
Content-Length=>0

[yealink-autoprov]
Event=>check-sync;reboot=false
Content-Length=>0

[cisco-resync]
Event=>check-sync
Content-type=>application/url
Content=>http://provisioning.example.com/cfg/${MAC}.xml
Content=>

extensions.conf:

[admin-tools]
; Reconfigurar teléfono Polycom
exten => *90XXX,1,Answer()
 same => n,Set(EXTEN_NUM=${EXTEN:3})
 same => n,Set(TARGET_URI=<sip:${EXTEN_NUM}@${SIPDOMAIN}>)
 same => n,PJSIPNotify(${TARGET_URI},polycom-check-cfg)
 same => n,Playback(configuration-updated)
 same => n,Hangup()

; Reconfigurar todos los teléfonos de un tipo
exten => *91,1,Answer()
 same => n,Playback(please-wait)
 same => n,System(/usr/local/bin/bulk-reprov.sh polycom)
 same => n,Playback(completed)
 same => n,Hangup()

Script bulk-reprov.sh:

#!/bin/bash
PHONE_TYPE=$1

case $PHONE_TYPE in
    polycom)
        NOTIFY_CFG="polycom-check-cfg"
        ;;
    yealink)
        NOTIFY_CFG="yealink-autoprov"
        ;;
    cisco)
        NOTIFY_CFG="cisco-resync"
        ;;
esac

# Obtener lista de endpoints del tipo especificado
asterisk -rx "pjsip show endpoints" | grep "$PHONE_TYPE" | while read line; do
    ENDPOINT=$(echo $line | awk '{print $1}')
    asterisk -rx "pjsip send notify $NOTIFY_CFG endpoint $ENDPOINT"
    sleep 1
done

Mejora del CLI: pjsip send notify channel

Junto con PJSIPNotify, se mejoró el comando CLI para soportar envío a canales específicos:

Nueva sintaxis:

pjsip send notify <option> channel <channel>

Ejemplo:

# Enviar a endpoint (anterior)
pjsip send notify check-voicemail endpoint 1001

# NUEVO: Enviar a canal específico
pjsip send notify check-voicemail channel PJSIP/1001-00000001

Esto permite enviar NOTIFY dentro del contexto de una llamada activa desde CLI.

Debugging y Troubleshooting

Habilitar Logging SIP

Para ver los mensajes NOTIFY en los logs:

# CLI
asterisk -rvvvv
pjsip set logger on

O en logger.conf:

[logfiles]
full => notice,warning,error,debug,verbose
messages => notice,warning,error

Captura de Paquetes

Usar sngrep para visualizar el flujo SIP:

sngrep port 5060

Filtra por NOTIFY:

F7 > Method: NOTIFY

Verificar Configuración

# Ver configuración de notify
asterisk -rx "pjsip show notify"

# Verificar endpoint default
asterisk -rx "pjsip show endpoint default-outbound"

# Test de envío
asterisk -rx "pjsip send notify test-notify endpoint 1001"

Problemas Comunes

Problema 1: "No default outbound endpoint configured"

WARNING: No default outbound endpoint configured

Solución: Configurar en pjsip.conf:

[global]
default_outbound_endpoint=default-outbound

Problema 2: Dispositivo no responde a NOTIFY

Verificar que el dispositivo soporte el Event específico:

# Capturar SUBSCRIBE del dispositivo para ver qué eventos solicita
sngrep
# Filtrar por SUBSCRIBE y revisar header Event:

Problema 3: NOTIFY enviado pero sin efecto

Algunos dispositivos requieren headers específicos:

[custom-notify]
Event=>talk
Content-type=>application/x-broadworks-callinfo
Content=>call-info: ;answer-after=0
; Header específico del fabricante:
X-Vendor-Specific=>custom-value
Content=>

Integración con AMI

Aunque PJSIPNotify es para dialplan, puedes combinarlo con AMI para control externo:

Ejemplo en Python:

import asterisk.manager

def send_notify_via_dialplan(extension, notify_config):
    """Envía NOTIFY ejecutando contexto de dialplan vía AMI"""
    
    manager = asterisk.manager.Manager()
    manager.connect('localhost')
    manager.login('admin', 'secret')
    
    # Originar llamada que ejecuta PJSIPNotify
    response = manager.originate(
        channel=f'Local/{extension}@send-notify',
        context='send-notify-handler',
        exten='s',
        priority=1,
        variables={
            'NOTIFY_CONFIG': notify_config,
            'TARGET_EXTEN': extension
        }
    )
    
    manager.logoff()
    return response

Dialplan correspondiente:

[send-notify]
exten => _X.,1,NoOp(Trigger notify for ${EXTEN})
 same => n,Return()

[send-notify-handler]
exten => s,1,NoOp(Sending ${NOTIFY_CONFIG} to ${TARGET_EXTEN})
 same => n,Set(URI=<sip:${TARGET_EXTEN}@${SIPDOMAIN}>)
 same => n,PJSIPNotify(${URI},${NOTIFY_CONFIG})
 same => n,Hangup()

Comparación: Antes vs Después

Antes de PJSIPNotify

Escenario: Enviar MWI update después de procesar voicemail.

[voicemail-handler]
exten => s,1,VoiceMail(${EXTEN}@default,u)
 same => n,System(echo "pjsip send notify mwi-update endpoint ${EXTEN}" | asterisk -rx)
 same => n,Hangup()

Problemas:

Llamada externa a shell
Performance overhead
Difícil de debuggear
Posibles race conditions

Después de PJSIPNotify

[voicemail-handler]
exten => s,1,VoiceMail(${EXTEN}@default,u)
 same => n,PJSIPNotify(,mwi-update)
 same => n,Hangup()

Ventajas:

Nativo del dialplan
Mejor performance
Dentro del diálogo SIP actual
Logging integrado

Best Practices

1. Usar Configuraciones Pre-definidas

En lugar de:

same => n,PJSIPNotify(,&Event=check-sync&Content-type=text/plain&Content=update)

Mejor:

; pjsip_notify.conf
[device-update]
Event=>check-sync
Content-type=>text/plain
Content=>update
Content=>

; extensions.conf
same => n,PJSIPNotify(,device-update)

Razón: Más legible, reutilizable, fácil de mantener.

2. Validar URIs Dinámicas

[safe-notify]
exten => 8000,1,NoOp(Notify to ${TARGET})
 same => n,GotoIf($[${LEN(${TARGET})} = 0]?error)
 same => n,GotoIf($["${TARGET}" = ""]?error)
 same => n,Set(URI=<sip:${TARGET}@${SIPDOMAIN}>)
 same => n,PJSIPNotify(${URI},custom-notify)
 same => n,Hangup()
 same => n(error),Playback(invalid)
 same => n,Hangup()

3. Logging Apropiado

same => n,Verbose(1,Sending ${NOTIFY_TYPE} NOTIFY to ${TARGET_URI})
same => n,PJSIPNotify(${TARGET_URI},${NOTIFY_TYPE})
same => n,NoOp(PJSIPNOTIFY result: ${PJSIPNOTIFYSTATUS})

4. Manejo de Errores

same => n,PJSIPNotify(${URI},check-sync)
same => n,GotoIf($["${PJSIPNOTIFYSTATUS}" = "SUCCESS"]?ok:failed)
same => n(failed),Log(ERROR,Failed to send NOTIFY to ${URI})
same => n,Goto(cleanup)
same => n(ok),Verbose(1,NOTIFY sent successfully)
same => n(cleanup),Hangup()

5. Rate Limiting

Si envías NOTIFY en bucle, implementa rate limiting:

[bulk-notify]
exten => 9000,1,Answer()
 same => n,Set(EXTENSIONS=1001&1002&1003&1004&1005)
 same => n,Set(i=1)
 same => n,While($[${i} <= ${FIELDQTY(EXTENSIONS,&)}])
 same => n,Set(EXT=${CUT(EXTENSIONS,&,${i})})
 same => n,Set(URI=<sip:${EXT}@${SIPDOMAIN}>)
 same => n,PJSIPNotify(${URI},update-config)
 same => n,Wait(0.5)  ; Rate limiting: 500ms entre mensajes
 same => n,Set(i=$[${i} + 1])
 same => n,EndWhile
 same => n,Hangup()

Consideraciones de Seguridad

1. Validación de Input

[user-notify]
; MAL - Vulnerable a injection
exten => 7000,1,Set(MSG=${CALLERID(name)})
 same => n,PJSIPNotify(,&Event=UserMessage&X-Data=${MSG})

; BIEN - Sanitizado
exten => 7000,1,Set(MSG=${FILTER(A-Za-z0-9 ,${CALLERID(name)})})
 same => n,GotoIf($[${LEN(${MSG})} > 50]?truncate)
 same => n,Goto(send)
 same => n(truncate),Set(MSG=${MSG:0:50})
 same => n(send),PJSIPNotify(,&Event=UserMessage&X-Data=${MSG})

2. Restricción de Destinos

[notify-restricted]
exten => _90XX,1,NoOp(Admin notify to ${EXTEN:2})
 same => n,GotoIf($["${CALLERID(num)}" != "1000"]?unauthorized)
 same => n,Set(TARGET=${EXTEN:2})
 same => n,PJSIPNotify(<sip:${TARGET}@${SIPDOMAIN}>,admin-msg)
 same => n,Hangup()
 same => n(unauthorized),Playback(access-denied)
 same => n,Hangup()

3. Audit Logging

[logged-notify]
exten => 8000,1,NoOp(=== NOTIFY Request ===)
 same => n,Set(CDR(userfield)=NOTIFY:${NOTIFY_TYPE}:${TARGET})
 same => n,Log(NOTICE,User ${CALLERID(num)} sending ${NOTIFY_TYPE} to ${TARGET})
 same => n,PJSIPNotify(${TARGET_URI},${NOTIFY_TYPE})
 same => n,Hangup()

Conclusión

PJSIPNotify en Asterisk 20+ representa una mejora significativa en el control programático de mensajes SIP NOTIFY. Las principales ventajas son:

Ventajas Técnicas:

Control nativo desde dialplan
Sin overhead de llamadas externas
Integración seamless en lógica de llamadas
Mejor performance y debugging

Casos de Uso Habilitados:

MWI dinámico durante llamadas
Auto-answer/paging systems
Provisioning remoto automático
Custom event notifications
Integración con aplicaciones externas

Mejores Prácticas:

Usar configuraciones pre-definidas en pjsip_notify.conf
Implementar validación y sanitización de inputs
Logging apropiado para auditoría
Rate limiting en operaciones bulk
Manejo de errores robusto

La combinación de PJSIPNotify con las capacidades existentes de Asterisk abre nuevas posibilidades para integración de telefonía y aplicaciones, especialmente en escenarios donde se requiere control fino del comportamiento de endpoints durante llamadas activas.

Referencias

¿Has implementado PJSIPNotify en tu sistema? Comparte tu experiencia en los comentarios.

Vota el Articulo:

December 29, 2025

Andrea Sannucci Asterisk AI Voice Agent: La Revolución de los Agentes de Voz Inteligentes en Telefonía Open Source

Después de dos décadas trabajando con Asterisk y FreePBX, los desarrolladores de telecomunicaciones nos hemos enfrentado a una realidad frustrante: las soluciones de agentes de voz con IA son caras, propietarias y poco flexibles. Asterisk AI Voice Agent surge como la respuesta open source que el ecosistema necesitaba.

Este proyecto representa un cambio fundamental en cómo construimos sistemas de voz inteligentes: en lugar de depender de plataformas cerradas y costosas, ahora podemos integrar la IA conversacional directamente con nuestra infraestructura Asterisk existente, manteniendo control total sobre privacidad, costos y funcionalidad.

¿Qué es Asterisk AI Voice Agent?

Asterisk AI Voice Agent es una plataforma modular y lista para producción que integra Asterisk/FreePBX con proveedores de IA modernos. A diferencia de otras soluciones, no requiere proveedores de telefonía externos ni reemplazar tu infraestructura existente.

Características Distintivas

Verdaderamente Open Source

Licencia MIT sin restricciones
Transparencia total del código
Sin vendor lock-in

Arquitectura Modular

Elige entre proveedores cloud, locales o híbridos
Mezcla componentes STT, LLM y TTS según necesites
Cambia proveedores sin reescribir código

Nativo de Asterisk

Integración directa vía ARI (Asterisk REST Interface)
Funciona con Asterisk 18+, FreePBX, VitalPBX
Sin hardware especializado ni servicios externos

Privacidad y Costos

Modo híbrido local: audio permanece on-premise
Costos tan bajos como $0.001-0.003/minuto (solo LLM)
Control total de datos sensibles

Arquitectura Técnica

Diseño de Dos Contenedores

La arquitectura se divide en dos componentes principales:

┌─────────────────┐      ┌───────────┐      ┌───────────────────┐
│ Asterisk Server │◀────▶│ ai-engine │◀────▶│ AI Provider       │
│ (ARI, RTP)      │      │ (Docker)  │      │ (Cloud o Local)   │
└─────────────────┘      └───────────┘      └───────────────────┘
                           │     ▲
                           │ WS  │ (Solo Local Hybrid)
                           ▼     │
                         ┌─────────────────┐
                         │ local-ai-server │
                         │ (Docker)        │
                         └─────────────────┘

ai-engine (Orquestador Ligero)

Conecta con Asterisk vía ARI
Gestiona el ciclo de vida de llamadas
Enruta audio desde/hacia proveedores IA
Maneja el estado de sesiones

local-ai-server (Opcional)

Ejecuta modelos STT/TTS locales
Vosk para speech-to-text
Piper para text-to-speech
Interface WebSocket

Principios de Diseño

Separación de Responsabilidades El procesamiento de IA está aislado del manejo de llamadas. Esto permite escalar cada componente independientemente y facilita el debugging.

Pipelines Modulares La arquitectura de pipeline permite combinar diferentes proveedores:

STT (Speech-to-Text): Deepgram, Vosk, Google
LLM (Large Language Model): OpenAI, Google Gemini, local
TTS (Text-to-Speech): ElevenLabs, Deepgram, Piper, Google

Flexibilidad de Transporte Soporta dos modos de transporte de audio:

AudioSocket: TCP directo, menor latencia, ideal para full agents
ExternalMedia RTP: Compatible con pipelines modulares, battle-tested

Cinco Configuraciones Golden Baseline

El proyecto incluye cinco configuraciones validadas en producción, cada una optimizada para diferentes casos de uso.

1. OpenAI Realtime (Recomendado para Inicio Rápido)

# config/ai-agent.golden-openai-realtime.yaml
stt:
  provider: "openai_realtime"
llm:
  provider: "openai_realtime"
  model: "gpt-4o-realtime-preview-2024-12-17"
  temperature: 0.8
  max_tokens: 4096
tts:
  provider: "openai_realtime"

Características:

IA conversacional moderna de OpenAI
Tiempo de respuesta: <2 segundos
Voces naturales y expresivas
Manejo de interrupciones (barge-in)

Ideal para:

Despliegues enterprise
Setup rápido
Calidad conversacional premium

Costos aproximados:

Input: $5/millón de tokens audio (~$0.10/minuto)
Output: $20/millón de tokens audio (~$0.40/minuto)

2. Deepgram Voice Agent

# config/ai-agent.golden-deepgram.yaml
stt:
  provider: "deepgram"
  model: "nova-2-ea"
  language: "es"
llm:
  provider: "openai"
  model: "gpt-4o-mini"
tts:
  provider: "deepgram"
  model: "aura-asteria-en"

Características:

Etapa "Think" avanzada para razonamiento complejo
Tiempo de respuesta: <3 segundos
STT y TTS de Deepgram
LLM de OpenAI para flexibilidad

Ideal para:

Ecosistema Deepgram existente
Aplicaciones que requieren razonamiento complejo
Transcripción en tiempo real de alta calidad

Costos aproximados:

Deepgram STT: $0.0043/minuto
OpenAI LLM: ~$0.001/minuto
Deepgram TTS: $0.015/1K caracteres

3. Google Live API (IA Multimodal)

# config/ai-agent.golden-google-live.yaml
stt:
  provider: "google_live"
llm:
  provider: "google_live"
  model: "gemini-2.0-flash-exp"
  temperature: 0.8
tts:
  provider: "google_live"

Características:

Gemini 2.0 Flash con capacidades multimodales
Tiempo de respuesta: <2 segundos
Procesamiento avanzado de lenguaje natural
Integración nativa con ecosistema Google

Ideal para:

Usuarios del ecosistema Google Cloud
Aplicaciones que requieren IA avanzada
Procesamiento multimodal

4. ElevenLabs Agent (Calidad de Voz Premium)

# config/ai-agent.golden-elevenlabs-agent.yaml
stt:
  provider: "elevenlabs_conversational"
llm:
  provider: "elevenlabs_conversational"
  agent_id: "your-agent-id"
tts:
  provider: "elevenlabs_conversational"

Características:

Voces ultra-realistas de ElevenLabs
IA conversacional integrada
Tiempo de respuesta: <2 segundos
Soporte nativo de herramientas (tool calling)

Ideal para:

Prioridad en calidad de voz
Conversaciones muy naturales
Aplicaciones customer-facing premium

5. Local Hybrid (Enfocado en Privacidad)

# config/ai-agent.golden-local-hybrid.yaml
stt:
  provider: "vosk"
  model: "vosk-model-small-es-0.42"
llm:
  provider: "openai"
  model: "gpt-4o-mini"
  temperature: 0.7
tts:
  provider: "piper"
  model: "es_ES-mls_10246-low"
  audio_format: "wav"

Características:

STT/TTS local + LLM en cloud
El audio nunca sale del servidor
Solo texto enviado al LLM cloud
Tiempo de respuesta: 3-7 segundos
Costos: ~$0.001-0.003/minuto (solo LLM)

Ideal para:

Cumplimiento normativo (HIPAA, GDPR)
Privacidad de audio
Control de costos
Instalaciones sin internet estable

Requisitos de Hardware:

CPU: 4+ cores (arquitectura moderna 2020+)
RAM: 8GB+ recomendado
Disco: 2GB (modelos + workspace)

Sistema de Tool Calling: Acciones en el Mundo Real

Una de las características más poderosas introducidas en v4.1+ es el sistema de tool calling, que permite al agente de IA ejecutar acciones reales en la telefonía.

Arquitectura Unificada

El sistema de herramientas está diseñado para funcionar con cualquier proveedor de LLM que soporte function calling:

# src/tools/base_tool.py
class BaseTool(ABC):
    """Base class for all tools"""
    
    @abstractmethod
    def get_schema(self) -> dict:
        """Return OpenAI function calling schema"""
        pass
    
    @abstractmethod
    async def execute(self, **kwargs) -> ToolResult:
        """Execute the tool"""
        pass

Herramientas Disponibles

1. Transfer Tool (Transferencia Unificada)

Maneja tres tipos de transferencia en una sola herramienta:

{
    "name": "transfer",
    "description": "Transfer call to extension, queue, or ring group",
    "parameters": {
        "destination": "1001",  # Extension number
        "destination_type": "extension",  # o "queue" o "ringgroup"
        "context": "from-internal"
    }
}

Ejemplo de uso:

Llamante: "Transfiere mi llamada al equipo de ventas"
Agente: "Te conecto con nuestro equipo de ventas inmediatamente"
[Transferencia a cola de ventas con música de espera]

Tipos soportados:

Extensions: Transferencia directa a endpoint SIP/PJSIP
Queues: Transferencia a colas ACD con anuncios de posición
Ring Groups: Múltiples agentes suenan simultáneamente

2. Cancel Transfer Tool

Permite cancelar una transferencia en progreso:

{
    "name": "cancel_transfer",
    "description": "Cancel an in-progress transfer"
}

Ejemplo:

Agente: "Te transfiero a soporte..."
Llamante: "Mejor cancela eso"
Agente: "Sin problema, he cancelado la transferencia. ¿En qué más puedo ayudarte?"

3. Voicemail Tool

Ruta la llamada a un buzón de voz:

{
    "name": "leave_voicemail",
    "description": "Route caller to voicemail",
    "parameters": {
        "extension": "1001",
        "context": "default"
    }
}

Ejemplo:

Llamante: "¿Puedo dejar un mensaje de voz para Juan?"
Agente: "¡Por supuesto! Te transfiero al buzón de Juan"
[Ruta al buzón de voz, llamante graba mensaje]

4. Hangup Tool

Finaliza la llamada de forma elegante:

{
    "name": "hangup_call",
    "description": "End call gracefully with farewell",
    "parameters": {
        "farewell_message": "Gracias por llamar. ¡Que tengas un buen día!"
    }
}

5. Email Tools

Envío automático de resúmenes: Después de cada llamada, los administradores reciben:

Transcripción completa de la conversación
Duración y metadata de la llamada
Información del llamante
Formato HTML profesional

Transcripciones solicitadas por el llamante:

Llamante: "¿Puedes enviarme una transcripción de esta llamada por email?"
Agente: "¡Con gusto! ¿Qué dirección de email debo usar?"
Llamante: "juan punto garcia arroba gmail punto com"
Agente: "Es juan.garcia@gmail.com, ¿correcto?"
Llamante: "Sí"
Agente: "¡Perfecto! Te enviaré la transcripción pronto"
[Email enviado con transcripción completa]

Configuración de Herramientas

La configuración se realiza en config/ai-agent.yaml:

tools:
  enabled: true
  available_tools:
    - name: "transfer"
      enabled: true
      config:
        allowed_destinations:
          - type: "extension"
            pattern: "^[1-9][0-9]{3}$"  # 1000-9999
          - type: "queue"
            pattern: "^[5][0-9]{3}$"     # 5000-5999
          - type: "ringgroup"
            pattern: "^[6][0-9]{3}$"     # 6000-6999
    
    - name: "leave_voicemail"
      enabled: true
      config:
        voicemail_context: "default"
    
    - name: "send_email_summary"
      enabled: true
      config:
        recipients:
          - "admin@example.com"
        use_resend: true
    
    - name: "request_transcript"
      enabled: true
      config:
        email_validation: true
        max_attempts: 3

Validación de Tool Calling

El proyecto incluye validación completa en v4.3+:

# Ejecutar tests de integración
pytest tests/integration/test_tools.py -v

# Test específico de transferencias
pytest tests/integration/test_tools.py::test_transfer_to_extension -v

# Validar con llamada real
agent troubleshoot --call-id=<call-id> --check-tools

Estado de Validación:

✅ OpenAI Realtime
✅ Deepgram Voice Agent
✅ Google Live API
✅ Local Hybrid
✅ ElevenLabs Conversational

Interfaz de Administración Web (v1.0)

El proyecto incluye una interfaz web moderna para gestión completa del sistema.

Características Principales

Dashboard en Tiempo Real

Métricas del sistema actualizadas cada 5 segundos
Estado de contenedores Docker
Uso de CPU, memoria y disco
Llamadas activas y totales

Asistente de Configuración Visual

Reemplaza el CLI agent quickstart
Guía paso a paso para configurar proveedores
Validación de API keys en tiempo real
Generación automática de dialplan

Gestión de Configuración

CRUD completo para proveedores, pipelines, contextos
Editor YAML con syntax highlighting (Monaco)
Validación de configuración
Respaldo y restauración

Logs en Vivo

Streaming de logs vía WebSocket
Filtrado por nivel (INFO, WARNING, ERROR)
Búsqueda en tiempo real
Descarga de logs

Autenticación JWT

Login seguro con tokens
Gestión de contraseñas
Roles y permisos (próximamente)

Instalación y Acceso

# Iniciar Admin UI
docker compose up -d admin-ui

# Acceder en el navegador
http://localhost:3003

# Credenciales por defecto
Usuario: admin
Contraseña: admin

Importante: Cambia la contraseña por defecto inmediatamente después del primer login.

Arquitectura del Admin UI

┌───────────────┐
│   Frontend    │  React + TypeScript
│   (Port 3003) │  Monaco Editor, Chart.js
└───────┬───────┘
        │ HTTP/WS
┌───────▼───────┐
│   Backend     │  Express + TypeScript
│   Auth JWT    │  WebSocket para logs
└───────┬───────┘
        │
┌───────▼───────┐
│  ai-engine    │  Python FastAPI
│  /health      │  Métricas + Logs
└───────────────┘

CLI Tools para Operaciones

El proyecto incluye herramientas CLI listas para producción:

Instalación del CLI

# Instalación con un comando (Linux/macOS/Windows)
curl -sSL https://raw.githubusercontent.com/hkjarral/Asterisk-AI-Voice-Agent/main/scripts/install-cli.sh | bash

# El binario se instala en ~/.asterisk-ai-voice-agent/bin/agent
# Se agrega automáticamente al PATH

Comandos Principales

agent quickstart Asistente interactivo de configuración:

agent quickstart

Guía paso a paso para selección de proveedor
Validación de API keys
Test de conexión ARI con Asterisk
Generación automática de dialplan

agent dialplan Genera snippets de configuración dialplan:

agent dialplan

Salida ejemplo:

[from-ai-agent]
exten => s,1,NoOp(Asterisk AI Voice Agent v4.4.1)
 same => n,Stasis(asterisk-ai-voice-agent)
 same => n,Hangup()

agent config validate Valida configuración YAML:

# Solo validar
agent config validate

# Validar y auto-corregir
agent config validate --fix

agent doctor Health check del sistema:

# Check completo
agent doctor

# Con auto-fix
agent doctor --fix

Verifica:

Conectividad ARI
Estado de contenedores Docker
Validación de configuración
API keys de proveedores
Puertos y networking

agent troubleshoot Analiza llamadas específicas:

agent troubleshoot --call-id=<channel-id>

Muestra:

Timeline completo de la llamada
Estado de herramientas ejecutadas
Errores y warnings
Métricas de latencia

agent demo Demuestra características del sistema:

agent demo

Guía de Instalación Paso a Paso

Requisitos Previos

Sistema Operativo:

Ubuntu 22.04/24.04 (recomendado)
Debian 11/12
RHEL/AlmaLinux 8/9
CentOS Stream

Software:

Docker 20.10+
Docker Compose 2.0+
Asterisk 18+ con ARI habilitado
4GB RAM mínimo (8GB recomendado para Local Hybrid)

Instalación en Asterisk Vanilla

Edita directamente /etc/asterisk/extensions.conf:

[from-internal]
exten => 5000,1,NoOp(AI Voice Agent Test)
 same => n,Answer()
 same => n,Stasis(asterisk-ai-voice-agent)
 same => n,Hangup()

exten => 5000,n,Playback(vm-goodbye)
 same => n,Hangup()

Configuración ARI en /etc/asterisk/ari.conf:

[general]
enabled = yes
pretty = yes

[asterisk]
type = user
read_only = no
password = SuperSecurePassword123

Configuración de Proveedores

OpenAI Realtime API

Obtener API Key:

Visita https://platform.openai.com/api-keys
Crea nuevo API key
Copia y guarda de forma segura

Configuración en .env:

OPENAI_API_KEY=sk-proj-...

Configuración del modelo:

# config/ai-agent.yaml
llm:
  provider: "openai_realtime"
  model: "gpt-4o-realtime-preview-2024-12-17"
  temperature: 0.8
  max_tokens: 4096
  initial_greeting: "Hola, soy tu asistente virtual. ¿En qué puedo ayudarte hoy?"
  prompt: |
    Eres un asistente telefónico profesional y amable.
    Tu objetivo es ayudar a los llamantes de manera eficiente.
    Habla de forma natural y conversacional.

Deepgram Voice Agent

Obtener API Key:

Visita https://console.deepgram.com/
Crea cuenta o inicia sesión
Genera API key en la sección de credenciales

Configuración:

# .env
DEEPGRAM_API_KEY=your-deepgram-api-key
OPENAI_API_KEY=sk-proj-...  # Para el LLM

# config/ai-agent.yaml
stt:
  provider: "deepgram"
  model: "nova-2-ea"
  language: "es"
  
llm:
  provider: "openai"
  model: "gpt-4o-mini"
  
tts:
  provider: "deepgram"
  model: "aura-asteria-en"

Google Live API (Gemini)

Obtener credenciales:

Visita https://console.cloud.google.com/
Crea o selecciona proyecto
Habilita Gemini API
Genera API key

Configuración:

# .env
GOOGLE_API_KEY=your-google-api-key

# config/ai-agent.yaml
stt:
  provider: "google_live"
llm:
  provider: "google_live"
  model: "gemini-2.0-flash-exp"
  temperature: 0.8
tts:
  provider: "google_live"

ElevenLabs Conversational AI

Setup de agente:

Visita https://elevenlabs.io/app/conversational-ai
Crea nuevo agente conversacional
Copia el Agent ID
Genera API key

Configuración:

# .env
ELEVENLABS_API_KEY=your-elevenlabs-api-key
ELEVENLABS_AGENT_ID=your-agent-id

# config/ai-agent.yaml
stt:
  provider: "elevenlabs_conversational"
llm:
  provider: "elevenlabs_conversational"
  agent_id: "${ELEVENLABS_AGENT_ID}"
tts:
  provider: "elevenlabs_conversational"

Local Hybrid (Privacidad Máxima)

No requiere API keys para STT/TTS, solo para el LLM:

# .env
OPENAI_API_KEY=sk-proj-...  # Solo para LLM

Descargar modelos:

# El contenedor local-ai-server descarga automáticamente
# los modelos al iniciarse por primera vez

# Vosk (STT)
# - vosk-model-small-es-0.42 (~40MB)

# Piper (TTS)
# - es_ES-mls_10246-low (~15MB)

Configuración:

# config/ai-agent.yaml
stt:
  provider: "vosk"
  model: "vosk-model-small-es-0.42"
  sample_rate: 8000

llm:
  provider: "openai"
  model: "gpt-4o-mini"
  temperature: 0.7

tts:
  provider: "piper"
  model: "es_ES-mls_10246-low"
  audio_format: "wav"
  sample_rate: 22050

Monitoreo y Observabilidad

Métricas con Prometheus

El sistema expone 50+ métricas en el endpoint /metrics:

Métricas de llamadas:

# Total de llamadas
ai_agent_calls_total{status="completed"} 150
ai_agent_calls_total{status="failed"} 3

# Llamadas activas
ai_agent_active_calls 5

# Duración promedio
ai_agent_call_duration_seconds_sum / ai_agent_call_duration_seconds_count

Métricas de IA:

# Latencia de STT
ai_agent_stt_latency_seconds{provider="deepgram"}

# Tokens de LLM
ai_agent_llm_tokens_total{model="gpt-4o-mini",type="input"}
ai_agent_llm_tokens_total{model="gpt-4o-mini",type="output"}

# Latencia de TTS
ai_agent_tts_latency_seconds{provider="deepgram"}

Métricas de herramientas:

# Ejecuciones de herramientas
ai_agent_tool_executions_total{tool="transfer",status="success"}
ai_agent_tool_executions_total{tool="transfer",status="failed"}

# Latencia de herramientas
ai_agent_tool_latency_seconds{tool="transfer"}

Dashboards de Grafana

El sistema incluye 5 dashboards pre-configurados:

1. System Overview

Estado general del sistema
Llamadas activas y totales
Uso de recursos (CPU, RAM, disco)
Tasa de errores

2. Call Analytics

Distribución de duración de llamadas
Llamadas por hora/día
Tasa de éxito vs fallos
Llamadas concurrentes

3. AI Performance

Latencia de cada componente (STT, LLM, TTS)
Distribución de tiempos de respuesta
Uso de tokens
Errores por proveedor

4. Tool Execution

Herramientas más usadas
Tasa de éxito de transferencias
Emails enviados
Latencia de ejecución

5. Transport Metrics

Calidad de audio (jitter, packet loss)
Throughput de RTP
Estadísticas de AudioSocket
Errores de red

Acceso a Grafana

# Iniciar monitoreo si no está activo
docker compose -f docker-compose.monitoring.yml up -d

# Acceder a Grafana
URL: http://tu-servidor:3000
Usuario: admin
Contraseña: admin  # Cambiar en primer login

# Los dashboards se importan automáticamente desde monitoring/grafana/dashboards/

Alertas Configuradas

Alertas críticas:

Llamadas fallando (>5% en 5 minutos)
CPU >80% durante 5 minutos
Memoria >90%
Disco <10GB libre

Alertas de advertencia:

Latencia alta de IA (>5 segundos)
Errores de herramientas (>10% en 15 minutos)
Packet loss >2%

Configuración de alertas en monitoring/grafana/provisioning/alerting/.

Casos de Uso Reales

1. Recepcionista Virtual para Consultorio Médico

Requisitos:

Privacidad HIPAA compliant
Agendamiento de citas
Manejo de emergencias
Horario español

Configuración:

# config/ai-agent.yaml
pipeline: "local_hybrid"  # Audio permanece local

llm:
  provider: "openai"
  model: "gpt-4o"
  temperature: 0.6
  initial_greeting: |
    Buenos días, habla con la recepción del Consultorio Médico González.
    ¿En qué puedo ayudarle hoy?
  
  prompt: |
    Eres la recepcionista virtual del Consultorio Médico Dr. González.
    
    FUNCIONES PRINCIPALES:
    1. Agendar citas médicas (usa transfer a extensión 200)
    2. Proporcionar información de horarios (Lunes a Viernes 9-18h)
    3. Identificar emergencias y transferir al 112
    4. Dar indicaciones para llegar a la clínica
    
    REGLAS IMPORTANTES:
    - NUNCA des consejos médicos
    - Para emergencias, deriva inmediatamente
    - Sé empático y profesional
    - Confirma siempre nombre completo y teléfono
    
    INFORMACIÓN DE LA CLÍNICA:
    - Dirección: Calle Principal 123, Madrid
    - Teléfono: +34 91 234 5678
    - Email: info@consultoriogonzalez.es

tools:
  enabled: true
  available_tools:
    - name: "transfer"
      enabled: true
      config:
        allowed_destinations:
          - type: "extension"
            number: "200"  # Recepcionista humana
          - type: "extension"
            number: "201"  # Enfermería
          - type: "queue"
            number: "5000"  # Cola médicos

Dialplan AsteriskPBX:

[from-pstn]
; Todas las llamadas entrantes al AI agent
exten => _X.,1,NoOp(Incoming call from ${CALLERID(num)})
 same => n,Set(CHANNEL(language)=es)
 same => n,GotoIf($["${CALLERID(num)}" = "112"]?emergency,s,1)  ; Emergencias directas
 same => n,Set(__TRANSFER_CONTEXT=from-internal)
 same => n,Stasis(asterisk-ai-voice-agent)
 same => n,Hangup()

[emergency]
exten => s,1,NoOp(Emergency call)
 same => n,Dial(SIP/emergency-line)
 same => n,Hangup()

Resultado:

90% de llamadas manejadas por IA
Reducción de carga en recepción humana
Disponibilidad 24/7
Cumplimiento HIPAA (audio local)
Costo: ~$0.002/minuto

2. Soporte Técnico de ISP

Requisitos:

Troubleshooting básico
Escalamiento a técnicos nivel 2
Agendamiento de visitas técnicas
Soporte multilingüe

Configuración:

# config/ai-agent.yaml
pipeline: "openai_realtime"  # Respuestas rápidas

llm:
  provider: "openai_realtime"
  model: "gpt-4o-realtime-preview-2024-12-17"
  temperature: 0.7
  initial_greeting: |
    Bienvenido al soporte técnico de FibraNet.
    Soy su asistente virtual. ¿Con qué problema de conexión puedo ayudarle?
  
  prompt: |
    Eres un agente de soporte técnico de FibraNet ISP.
    
    PROCEDIMIENTOS DE TROUBLESHOOTING:
    1. Identifica el tipo de servicio (fibra, ADSL, móvil)
    2. Verifica síntomas: sin conexión, lento, intermitente
    3. Guía pasos básicos:
       - Reinicio de router (desconectar 30 segundos)
       - Verificar cables y luces LED
       - Test de velocidad
    
    ESCALAMIENTO:
    - Problemas físicos → transferir a técnico nivel 2 (ext 300)
    - Facturación → transferir a administración (ext 400)
    - No resuelto en 5 minutos → escalar
    
    AGENDA VISITAS:
    - Usa herramienta transfer a cola 5100 (agendamiento)
    
    Siempre pide número de cliente y valida servicio contratado.

tools:
  enabled: true
  available_tools:
    - name: "transfer"
      enabled: true
      config:
        allowed_destinations:
          - type: "extension"
            number: "300"  # Técnico L2
          - type: "queue"
            number: "5100"  # Agendamiento
          - type: "extension"
            number: "400"  # Facturación
    
    - name: "request_transcript"
      enabled: true  # Cliente puede pedir resumen por email

Integración con CRM:

# Webhook para actualizar ticket en CRM
# POST a /webhooks/ticket-update al finalizar llamada

import requests

@app.post("/webhooks/ticket-update")
async def update_crm_ticket(call_data: dict):
    """Actualiza CRM con resultado de llamada"""
    
    ticket_data = {
        "customer_id": call_data["caller_id"],
        "issue_type": call_data["detected_issue"],
        "resolution": call_data["resolution_status"],
        "transcript": call_data["transcript"],
        "duration": call_data["call_duration"],
        "escalated": call_data["was_escalated"]
    }
    
    response = requests.post(
        "https://crm.example.com/api/tickets",
        json=ticket_data,
        headers={"Authorization": f"Bearer {CRM_API_KEY}"}
    )
    
    return {"status": "updated", "ticket_id": response.json()["ticket_id"]}

Métricas alcanzadas:

70% de problemas resueltos por IA
Tiempo medio de resolución: 3.5 minutos
Satisfacción de cliente: 4.2/5
Reducción de llamadas escaladas: 60%
Costo: $0.35-0.50 por llamada

3. Sistema de Encuestas Post-Venta

Requisitos:

Encuestas automáticas después de compra
Detección de insatisfacción
Escalamiento a atención al cliente
Registro en base de datos

Configuración:

# config/ai-agent.yaml
pipeline: "deepgram"  # Balance calidad/costo

llm:
  provider: "openai"
  model: "gpt-4o-mini"
  temperature: 0.5
  initial_greeting: |
    Hola, le llamo de parte de TechStore para conocer su opinión
    sobre su reciente compra. ¿Tiene un minuto para responder
    una breve encuesta?
  
  prompt: |
    Eres un encuestador virtual de TechStore.
    
    ENCUESTA (mantén conversación natural):
    1. ¿Cómo califica la calidad del producto? (1-5)
    2. ¿El tiempo de entrega fue satisfactorio? (Sí/No)
    3. ¿Cómo fue su experiencia con nuestro servicio? (1-5)
    4. ¿Recomendaría TechStore a amigos? (Sí/No)
    5. ¿Algún comentario adicional?
    
    DETECCIÓN DE PROBLEMAS:
    - Calificación ≤2 en cualquier pregunta → mostrar empatía
    - Cliente muy insatisfecho → ofrecer transferir con manager
    - Problema grave → usar herramienta transfer inmediatamente
    
    Al finalizar:
    - Agradece participación
    - Menciona que recibirán email con resumen
    
    Mantén tono profesional pero amigable. Escucha activamente.

tools:
  enabled: true
  available_tools:
    - name: "transfer"
      enabled: true
      config:
        allowed_destinations:
          - type: "queue"
            number: "6000"  # Cola customer service
    
    - name: "send_email_summary"
      enabled: true
      config:
        recipients:
          - "surveys@techstore.com"
        include_transcript: true
        include_sentiment: true

Script de procesamiento:

# scripts/process_survey.py
import json
from datetime import datetime

async def process_survey_call(call_data: dict):
    """Procesa llamada de encuesta y extrae datos estructurados"""
    
    # Analizar transcripción con LLM
    analysis = await analyze_survey_transcript(
        transcript=call_data["transcript"]
    )
    
    survey_data = {
        "survey_id": call_data["call_id"],
        "customer_id": extract_customer_id(call_data["caller_id"]),
        "date": datetime.now().isoformat(),
        "responses": {
            "product_quality": analysis["ratings"]["product"],
            "delivery_satisfaction": analysis["ratings"]["delivery"],
            "service_rating": analysis["ratings"]["service"],
            "would_recommend": analysis["would_recommend"],
            "comments": analysis["extracted_comments"]
        },
        "sentiment_score": analysis["overall_sentiment"],  # -1 a 1
        "needs_followup": analysis["needs_followup"],
        "escalated": call_data["was_transferred"]
    }
    
    # Guardar en base de datos
    await db.surveys.insert_one(survey_data)
    
    # Si necesita seguimiento, crear ticket
    if survey_data["needs_followup"]:
        await create_followup_ticket(survey_data)
    
    return survey_data

async def analyze_survey_transcript(transcript: str) -> dict:
    """Usa LLM para extraer datos estructurados de la encuesta"""
    
    prompt = f"""
    Analiza esta transcripción de encuesta y extrae:
    1. Calificaciones numéricas mencionadas (1-5)
    2. Respuestas Sí/No
    3. Comentarios textuales
    4. Sentiment general (-1 negativo, 0 neutral, 1 positivo)
    5. Si requiere seguimiento urgente
    
    Transcripción:
    {transcript}
    
    Responde en JSON.
    """
    
    # Llamada a OpenAI u otro LLM
    response = await openai.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": prompt}],
        response_format={"type": "json_object"}
    )
    
    return json.loads(response.choices[0].message.content)

Dialplan para llamadas outbound:

[survey-outbound]
exten => s,1,NoOp(Outbound Survey Call)
 same => n,Set(CHANNEL(language)=es)
 same => n,Wait(2)  ; Dar tiempo al cliente a responder
 same => n,Stasis(asterisk-ai-voice-agent,survey_context)
 same => n,Hangup()

; Originate desde AMI o ARI
; Action: Originate
; Channel: PJSIP/customer_number@trunk
; Context: survey-outbound
; Exten: s
; Priority: 1
; Async: yes

Resultados:

Tasa de completitud: 68% (vs 12% email)
Tiempo promedio encuesta: 2.5 minutos
Detección automática de problemas: 95%
Costo por encuesta: $0.08-0.12
ROI: 340% en 6 meses

Optimización y Tuning

Reducción de Latencia

1. Configuración de AudioSocket (Más Rápido)

AudioSocket tiene menor latencia que ExternalMedia RTP:

# config/ai-agent.yaml
audio_transport: "audiosocket"  # vs "externalmedia"

audiosocket:
  host: "0.0.0.0"
  port: 9092
  codec: "slin"  # Linear PCM, sin compresión

Configuración Asterisk:

; extensions.conf
[from-ai-agent]
exten => s,1,NoOp()
 same => n,Answer()
 same => n,AudioSocket(40325ec2-5efc-4d74-bcd1-4e9a6969c285,server.example.com:9092)
 same => n,Hangup()

Ventajas de AudioSocket:

Streaming TCP directo
Sin negociación RTP
Latencia ~50-100ms menor
Ideal para full agents (OpenAI Realtime, ElevenLabs)

2. Optimización de Pipeline Híbrido

Para Local Hybrid, estas configuraciones reducen latencia:

stt:
  provider: "vosk"
  model: "vosk-model-small-es-0.42"  # Modelo pequeño pero rápido
  sample_rate: 8000  # Menor sample rate = menos datos
  
llm:
  provider: "openai"
  model: "gpt-4o-mini"  # Modelo más rápido
  max_tokens: 150  # Respuestas más cortas
  temperature: 0.7
  stream: true  # IMPORTANTE: streaming de respuestas
  
tts:
  provider: "piper"
  model: "es_ES-mls_9972-low"  # Modelo low quality es más rápido
  audio_format: "wav"
  length_scale: 1.0  # Velocidad normal
  noise_scale: 0.667

3. Barge-In (Interrupciones)

Configuración óptima para detección de habla durante respuesta de IA:

barge_in:
  enabled: true
  sensitivity: 0.5  # 0-1, más alto = más sensible
  cooldown_ms: 500  # Milisegundos de silencio antes de permitir interrupción
  min_speech_duration_ms: 300  # Duración mínima de habla para considerar interrupción válida

Calidad de Audio

Configuración para Máxima Calidad:

# Mejor calidad TTS
tts:
  provider: "elevenlabs"
  model_id: "eleven_multilingual_v2"
  voice_settings:
    stability: 0.5
    similarity_boost: 0.75
    style: 0.0  # 0 = consistente, 1 = expresivo
  optimize_streaming_latency: 2  # 0-4, menor = mejor calidad

# Mejor calidad STT
stt:
  provider: "deepgram"
  model: "nova-2"  # Modelo premium
  language: "es"
  smart_format: true  # Puntuación automática
  diarize: false
  
# Audio de alta resolución
audio:
  sample_rate: 16000  # vs 8000
  channels: 1
  codec: "pcm_s16le"

Trade-offs:

Mejor calidad = Mayor latencia (200-500ms adicionales)
Mayor sample rate = Mayor ancho de banda
Recomendado para aplicaciones premium

Reducción de Costos

Estrategia 1: Modelo Local + Cloud LLM (Híbrido)

pipeline: "local_hybrid"

# Audio procesado localmente (sin costo)
stt:
  provider: "vosk"  # Gratis
  
tts:
  provider: "piper"  # Gratis
  
# Solo LLM en cloud
llm:
  provider: "openai"
  model: "gpt-4o-mini"  # $0.15/1M input, $0.60/1M output tokens

Costo estimado: $0.001-0.003 por minuto

Estrategia 2: Deepgram con Modelo Económico

stt:
  provider: "deepgram"
  model: "base"  # vs "nova-2" premium
  # base: $0.0043/min vs nova-2: $0.0059/min
  
tts:
  provider: "deepgram"
  model: "aura-asteria-en"
  # $0.015/1K caracteres
  
llm:
  provider: "openai"
  model: "gpt-4o-mini"  # vs "gpt-4o"

Costo estimado: $0.015-0.025 por minuto

Estrategia 3: Caching de Respuestas Frecuentes

# src/utils/response_cache.py
import hashlib
from typing import Optional

class ResponseCache:
    """Cache respuestas comunes para reducir llamadas a LLM"""
    
    def __init__(self, redis_client):
        self.cache = redis_client
        self.ttl = 3600  # 1 hora
    
    def get_cached_response(self, user_input: str) -> Optional[str]:
        """Busca respuesta en cache"""
        key = self._generate_key(user_input)
        return self.cache.get(key)
    
    def cache_response(self, user_input: str, response: str):
        """Guarda respuesta en cache"""
        key = self._generate_key(user_input)
        self.cache.setex(key, self.ttl, response)
    
    def _generate_key(self, text: str) -> str:
        """Genera key consistente para input similar"""
        # Normalizar texto
        normalized = text.lower().strip()
        # Eliminar variaciones menores
        normalized = re.sub(r'\s+', ' ', normalized)
        # Hash
        return f"response:{hashlib.md5(normalized.encode()).hexdigest()}"

# Uso en pipeline
@router.post("/process-utterance")
async def process(utterance: str):
    # Intentar cache primero
    cached = response_cache.get_cached_response(utterance)
    if cached:
        logger.info("Cache hit, skipping LLM call")
        return {"response": cached, "from_cache": True}
    
    # Si no está en cache, llamar a LLM
    response = await llm.generate(utterance)
    
    # Cachear respuesta
    response_cache.cache_response(utterance, response)
    
    return {"response": response, "from_cache": False}

Ahorro: 30-50% en costos de LLM para preguntas frecuentes

Monitoreo de Performance

Configurar alertas de latencia:

# monitoring/grafana/provisioning/alerting/latency-alerts.yaml
apiVersion: 1
groups:
  - name: ai_latency
    interval: 1m
    rules:
      - alert: HighSTTLatency
        expr: ai_agent_stt_latency_seconds > 2.0
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Alta latencia en STT"
          description: "Latencia de STT es {{ $value }}s (>2s)"
      
      - alert: HighLLMLatency
        expr: ai_agent_llm_latency_seconds > 3.0
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Alta latencia en LLM"
          description: "Latencia de LLM es {{ $value }}s (>3s)"
      
      - alert: HighTTSLatency
        expr: ai_agent_tts_latency_seconds > 1.5
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Alta latencia en TTS"
          description: "Latencia de TTS es {{ $value }}s (>1.5s)"

Dashboard de latencia:

-- Query Prometheus para percentiles de latencia
histogram_quantile(0.50, 
  rate(ai_agent_stt_latency_seconds_bucket[5m])
) as p50_stt,
histogram_quantile(0.95, 
  rate(ai_agent_stt_latency_seconds_bucket[5m])
) as p95_stt,
histogram_quantile(0.99, 
  rate(ai_agent_stt_latency_seconds_bucket[5m])
) as p99_stt

Troubleshooting Común

Problema 1: Llamadas No Entran a Stasis

Síntomas:

Llamada suena pero no entra al agent
Logs muestran: "Stasis application not found"

Diagnóstico:

# Verificar estado de ARI
asterisk -rx "ari show apps"

# Debe mostrar: asterisk-ai-voice-agent

# Verificar conexión del engine
docker compose logs ai-engine | grep -i "ari"

Solución:

# 1. Verificar credenciales ARI en .env
cat .env | grep ARI

# 2. Test de conexión ARI
agent doctor --check-ari

# 3. Reiniciar ai-engine
docker compose restart ai-engine

# 4. Verificar que el contenedor está corriendo
docker compose ps

Problema 2: Audio Entrecortado o Sin Audio

Síntomas:

Se escucha audio con cortes
Cliente no escucha al agent
Agent no escucha al cliente

Diagnóstico:

# Verificar codec configurado
asterisk -rx "pjsip show endpoint <endpoint> | grep codec"

# Ver estadísticas RTP
asterisk -rx "rtp show stats"

# Revisar logs de transport
docker compose logs ai-engine | grep -i "audio\|rtp"

Solución para AudioSocket:

# config/ai-agent.yaml
audio_transport: "audiosocket"

audiosocket:
  host: "0.0.0.0"
  port: 9092
  codec: "slin"  # Importante: Linear PCM
  buffer_size: 320  # Bytes por frame

; extensions.conf
[from-ai-agent]
exten => s,1,Answer()
 same => n,AudioSocket(uuid,<IP>:9092)  ; Reemplazar <IP>
 same => n,Hangup()

Solución para ExternalMedia:

# config/ai-agent.yaml
audio_transport: "externalmedia"

rtp:
  bind_address: "0.0.0.0"
  port_range: "10000-20000"
  codec: "ulaw"  # o "alaw"

Verificar NAT/Firewall:

# Abrir puertos RTP
sudo firewall-cmd --add-port=10000-20000/udp --permanent
sudo firewall-cmd --reload

# Para AudioSocket
sudo firewall-cmd --add-port=9092/tcp --permanent
sudo firewall-cmd --reload

Problema 3: Alta Latencia en Respuestas

Síntomas:

Agent tarda >5 segundos en responder
Conversación se siente lenta

Diagnóstico:

# Ver métricas de latencia
agent troubleshoot --call-id=<id> --show-latency

# O desde Grafana
# Dashboard: AI Performance
# Panel: Response Time Breakdown

Análisis de componentes:

# Ver latencia por componente
import json

def analyze_call_latency(call_id: str):
    """Analiza latencia desglosada de una llamada"""
    metrics = get_call_metrics(call_id)
    
    breakdown = {
        "stt_avg": metrics["stt_latency_avg"],
        "llm_avg": metrics["llm_latency_avg"],
        "tts_avg": metrics["tts_latency_avg"],
        "network_avg": metrics["network_latency_avg"],
        "total_avg": sum([
            metrics["stt_latency_avg"],
            metrics["llm_latency_avg"],
            metrics["tts_latency_avg"],
            metrics["network_latency_avg"]
        ])
    }
    
    # Identificar cuello de botella
    bottleneck = max(breakdown.items(), key=lambda x: x[1])
    
    print(f"Latencia total: {breakdown['total_avg']:.2f}s")
    print(f"Cuello de botella: {bottleneck[0]} ({bottleneck[1]:.2f}s)")
    print(json.dumps(breakdown, indent=2))
    
    return breakdown

Soluciones:

# Si STT es el cuello de botella
stt:
  provider: "deepgram"  # Más rápido que Vosk local
  model: "nova-2-general"

# Si LLM es el cuello de botella
llm:
  model: "gpt-4o-mini"  # vs "gpt-4o"
  max_tokens: 150  # Limitar tokens
  stream: true  # Streaming de respuesta
  
# Si TTS es el cuello de botella
tts:
  provider: "deepgram"  # Más rápido que ElevenLabs
  model: "aura-asteria-en"

Problema 4: Tools No Se Ejecutan

Síntomas:

Agent menciona hacer algo pero no lo hace
Transferencias no funcionan
Emails no se envían

Diagnóstico:

# Verificar configuración de tools
agent config validate --check-tools

# Ver logs de ejecución de tools
docker compose logs ai-engine | grep -i "tool"

# Test específico de tool
pytest tests/integration/test_tools.py::test_transfer -v

Verificaciones:

Schema de herramienta correcto:

# En el LLM provider, verificar schema
def get_tools_schema(self) -> list:
    return [
        {
            "type": "function",
            "function": {
                "name": "transfer",
                "description": "Transfer call to extension",
                "parameters": {
                    "type": "object",
                    "properties": {
                        "destination": {"type": "string"},
                        "destination_type": {"type": "string"}
                    },
                    "required": ["destination"]
                }
            }
        }
    ]

Contexto de transferencia:

# config/ai-agent.yaml
tools:
  enabled: true
  transfer:
    context: "from-internal"  # Contexto Asterisk correcto
    allowed_destinations:
      - type: "extension"
        pattern: "^[1-9][0-9]{3}$"

Prompt del LLM incluye instrucciones:

llm:
  prompt: |
    Tienes acceso a las siguientes herramientas:
    - transfer: Transferir llamada a extensión, cola o ring group
    - send_email: Enviar email con transcripción
    
    Usa estas herramientas cuando sea apropiado.
    Ejemplo: Si cliente pide hablar con ventas, usa transfer.

Problema 5: Crash del Contenedor local-ai-server

Síntomas:

Contenedor local-ai-server se reinicia constantemente
Logs muestran "Killed" o "OOM"

Diagnóstico:

# Ver logs
docker compose logs local-ai-server --tail=100

# Verificar uso de recursos
docker stats local-ai-server

# Ver eventos del contenedor
docker events --filter container=asterisk-ai-voice-agent-local-ai-server-1

Causas comunes:

Memoria insuficiente (OOM Killer):

# docker-compose.yml
services:
  local-ai-server:
    deploy:
      resources:
        limits:
          memory: 4G  # Aumentar de 2G a 4G
        reservations:
          memory: 2G

Modelo muy grande:

# config/ai-agent.yaml
stt:
  provider: "vosk"
  model: "vosk-model-small-es-0.42"  # vs "vosk-model-es-0.42" (grande)

Múltiples instancias concurrentes:

# Limitar llamadas concurrentes en config/ai-agent.yaml
concurrency:
  max_calls: 5  # Reducir de 10 a 5
  queue_size: 20

Solución:

# 1. Aumentar memoria disponible
docker compose down
# Editar docker-compose.yml con límites más altos
docker compose up -d

# 2. Usar modelo más pequeño
cp config/ai-agent.golden-local-hybrid-small.yaml config/ai-agent.yaml
docker compose restart ai-engine

# 3. Verificar swap habilitado
sudo swapon --show
# Si no tiene swap:
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Roadmap y Futuro

El proyecto está en desarrollo activo. Aquí están las características planificadas:

v4.5 (Q1 2025)

Características principales:

✅ Soporte completo de ElevenLabs Conversational AI
✅ Admin UI v1.0 con setup wizard visual
⏳ Integración con CRMs (Salesforce, HubSpot)
⏳ Soporte multi-tenant
⏳ API REST para gestión programática

Mejoras de herramientas:

⏳ Tool: SMS notification (Twilio integration)
⏳ Tool: Calendar scheduling (Google Calendar, Outlook)
⏳ Tool: Database queries (PostgreSQL, MySQL)
⏳ Tool: External API calls (generic webhook)

v5.0 (Q2 2025)

IA Avanzada:

⏳ Sentiment analysis en tiempo real
⏳ Detección de emociones en voz
⏳ Análisis automático de calidad de llamadas
⏳ Recomendaciones de mejora de prompts

Escalabilidad:

⏳ Kubernetes deployment manifests
⏳ Load balancing automático
⏳ Redis para estado compartido
⏳ Horizontal scaling de ai-engine

Monitoreo:

⏳ Integración con Datadog, New Relic
⏳ Dashboards específicos por caso de uso
⏳ Alertas ML para anomalías
⏳ Reportes automáticos ejecutivos

v5.5 (Q3 2025)

Proveedores Adicionales:

⏳ Azure Cognitive Services (STT/TTS)
⏳ Amazon Transcribe/Polly
⏳ IBM Watson
⏳ Anthropic Claude (LLM)

Funcionalidades:

⏳ Multi-idioma automático (detección de idioma)
⏳ Transcripción en vivo para supervisores
⏳ Grabación selectiva con consentimiento
⏳ Barge-in configurable por contexto

Contribuciones de la Comunidad

El proyecto está abierto a contribuciones. Áreas prioritarias:

Nuevos proveedores de IA
- Implementar nuevos STT/LLM/TTS providers
- Guía de implementación de providers
Herramientas adicionales
- Integración con servicios externos
- Guía de desarrollo de tools
Casos de uso verticales
- Configuraciones especializadas por industria
- Ejemplos documentados
Traducciones
- Documentación en otros idiomas
- Prompts y greetings localizados

Cómo contribuir:

Lee CONTRIBUTING.md
Únete al Discord
Revisa issues abiertos

Conclusión

Asterisk AI Voice Agent representa un avance significativo en la democratización de agentes de voz inteligentes. Al combinar la flexibilidad de Asterisk con el poder de la IA moderna, el proyecto ofrece:

Ventajas Clave:

Control Total: Infraestructura open source sin vendor lock-in
Flexibilidad: Arquitectura modular que se adapta a tus necesidades
Privacidad: Opción de procesar audio completamente local
Costo-Efectivo: Desde $0.001/minuto con configuración híbrida local
Listo para Producción: 5 configuraciones validadas y herramientas de operación

Casos de Uso Validados:

Recepción virtual 24/7
Soporte técnico automatizado
Encuestas post-venta
Agendamiento de citas
Cualificación de leads

Comunidad Activa:

150+ estrellas en GitHub
Desarrollo activo con releases mensuales
Canal de Discord para soporte
Documentación extensa y ejemplos

Si estás buscando implementar agentes de voz con IA en tu infraestructura Asterisk, este proyecto ofrece la base sólida que necesitas sin comprometer control ni privacidad.

Recursos Adicionales

Enlaces Importantes

Proyecto:

Guías Específicas:

Para Desarrolladores:

Demo en Vivo

Prueba el sistema llamando a: (925) 736-6718 (solo USA)

Presiona:

5 → Google Live API
6 → Deepgram Voice Agent
7 → OpenAI Realtime
8 → Local Hybrid
9 → ElevenLabs Agent

Comunidad y Soporte

Obtener Ayuda:

Discord - Soporte comunitario en tiempo real
GitHub Issues - Reportar bugs
GitHub Discussions - Preguntas generales

Contribuir:

¿Te ha resultado útil este artículo? Comparte tu experiencia con Asterisk AI Voice Agent en los comentarios.

Licencia: MIT Autor del artículo: VozToVoice.org Fecha: Diciembre 2024 Proyecto: Asterisk AI Voice Agent por Haider Jarral

Vota el Articulo:

Andrea Sannucci Kamailio and the CAP Theorem: Distributed Architecture Decisions in Telephony
In my recent article on the Philosophy of VoIP Infrastructure, I explored how technical decisions are fundamentally philosophical choices. Today, I want to dive deeper into one of the most critical frameworks for understanding distributed systems: the CAP theorem, and how it applies specifically to Kamailio SIP proxy architectures.

The CAP theorem, formulated by Eric Brewer in 2000, states that a distributed system can only guarantee two out of three properties simultaneously:

Consistency (C): All nodes see the same data at the same time

Availability (A): Every request receives a response, without guarantee that it contains the most recent data

Partition Tolerance (P): The system continues to operate despite network partitions

In telephony, these aren't abstract concepts—they represent real decisions that affect call quality, user experience, and system reliability.

The Telephony Reality: Partition Tolerance is Non-Negotiable

Let's be clear from the start: in telecommunications infrastructure, partition tolerance is mandatory. Network failures happen. Links go down. Datacenters lose connectivity. Your architecture must handle these scenarios.

This means we're really choosing between:

CP Systems: Consistency + Partition Tolerance (sacrifice Availability)

AP Systems: Availability + Partition Tolerance (sacrifice Consistency)

There is no CA option in real-world distributed Kamailio deployments.

Kamailio's Architectural Components and CAP Trade-offs

1. User Registration and Location Service

This is where CAP decisions become most visible.

Scenario A: Centralized Location Database (CP approach)

┌─────────────┐ │ Kamailio 1 │─┐ └─────────────┘ │ ├──► PostgreSQL Primary ┌─────────────┐ │ (Single Source of Truth) │ Kamailio 2 │─┘ └─────────────┘
Trade-off: Prioritizes consistency over availability.

-- All Kamailio instances query the same database SELECT contact, expires FROM location WHERE username = 'alice@domain.com';
Consequences:

✅ Perfect consistency: All proxies see identical registration state

✅ No split-brain scenarios

❌ Database becomes single point of failure

❌ Network partition to database = no registrations work

❌ Higher latency for location lookups

When to choose this:

Regulatory requirements demand precise registration tracking

Billing systems need exact call detail records

Small to medium deployments where database redundancy is manageable

Scenario B: Distributed DMQ with Local Cache (AP approach)

┌─────────────┐ ┌─────────────┐ │ Kamailio 1 │◄───────►│ Kamailio 2 │ │ + DMQ │ Sync │ + DMQ │ │ + htable │ │ + htable │ └─────────────┘ └─────────────┘
Trade-off: Prioritizes availability over strong consistency.

# kamailio.cfg loadmodule "dmq.so" loadmodule "htable.so" modparam("htable", "htable", "loc=>size=16;autoexpire=3600;dmqreplicate=1") modparam("dmq", "server_address", "sip:10.0.1.10:5060") modparam("dmq", "notification_address", "sip:10.0.1.11:5060")
Consequences:

✅ High availability: Each node operates independently

✅ Low latency: Local memory lookups

✅ Survives network partitions

❌ Eventual consistency only

❌ Possible temporary registration inconsistencies

❌ DMQ synchronization delays

When to choose this:

High-traffic environments where milliseconds matter

Geographically distributed installations

Scenarios where temporary inconsistency is acceptable

2. Dialog State Management

Dialog state (active calls) presents unique CAP challenges.

The Problem

During an active call:

User moves between proxies (mobile handoff)

Network partition splits your cluster

Which proxy "owns" the dialog state?

CP Approach: Shared Dialog Database

modparam("dialog", "db_url", "postgres://kamailio:password@db-cluster/kamailio") modparam("dialog", "db_mode", 1) # Real-time database writes modparam("dialog", "db_update_period", 5)
Trade-off:

Consistency in dialog state across cluster

Risk: Database unavailability = no new calls

AP Approach: Distributed Dialog with DMQ

modparam("dialog", "enable_dmq", 1) modparam("dialog", "dmq_notification_address", "sip:10.0.1.10:5060")
Trade-off:

Calls survive network partitions

Risk: Temporary dialog state divergence

Real-world hybrid approach:

# Write to database asynchronously, sync via DMQ immediately modparam("dialog", "db_mode", 2) # Write on timer modparam("dialog", "db_update_period", 60) modparam("dialog", "enable_dmq", 1)
This gives you:

Fast DMQ synchronization for active operations

Database as eventual consistency backup

Reasonable behavior during partitions

Multi-Datacenter Architectures: CAP at Scale

When spanning multiple datacenters, CAP decisions become existential.

Scenario: Transcontinental Deployment

US-EAST EU-WEST ┌─────────────┐ ┌─────────────┐ │ Kamailio │ │ Kamailio │ │ Cluster │◄────WAN─────►│ Cluster │ │ + Local DB │ │ + Local DB │ └─────────────┘ └─────────────┘ ▲ ▲ │ │ US Users EU Users
Option 1: Global Consistency (CP)

Use a globally distributed database like CockroachDB or Galera Cluster with synchronous replication.

modparam("usrloc", "db_url", "mysql://global-cluster/kamailio") modparam("usrloc", "db_mode", 3) # Write-through cache
Consequences:

✅ Global view of registrations

❌ 100-200ms latency on every registration

❌ Transatlantic link failure = system down

Option 2: Regional Autonomy (AP)

Each region operates independently with asynchronous synchronization.

# US-EAST kamailio.cfg modparam("usrloc", "db_url", "mysql://us-east-db/kamailio") modparam("dmq", "notification_address", "sip:eu-west-dmq:5060") modparam("dmq", "multi_notify_timeout", 5000) # Tolerate EU delays
Consequences:

✅ Each region fully functional during WAN partition

✅ Local latencies (1-5ms)

❌ User might appear registered in both regions temporarily

❌ Call routing decisions based on stale data

The Philosophical Choice

This is where philosophy meets infrastructure:

Do you value:

Truth (consistency): Users see accurate state, even if system becomes unavailable

Responsiveness (availability): System always responds, even if answers are temporarily inaccurate

There's no universally correct answer. It depends on your values and use case.

Practical Decision Framework

Step 1: Identify Your Critical Path

What operations are on the critical path of call setup?

INVITE arrives → Location lookup → Route decision → Forward ↑ CRITICAL ↑ CRITICAL
Make these AP-optimized (local, fast).

Billing record → Database write → CDR generation ↑ NOT CRITICAL
Make these CP-optimized (consistent, can be slower).

Step 2: Define Acceptable Inconsistency Windows

Ask: "If data is inconsistent for X seconds, what breaks?"

User registration: 5-10 seconds usually acceptable

Active dialog state: 1-2 seconds acceptable

Billing data: 0 seconds—must be consistent

Step 3: Choose Your Replication Strategy

┌──────────────────┬─────────────┬──────────────┬─────────────┐ │ Data Type │ Consistency │ Replication │ Storage │ ├──────────────────┼─────────────┼──────────────┼─────────────┤ │ Registrations │ Eventual │ DMQ │ htable │ │ Active dialogs │ Eventual │ DMQ │ dialog mod │ │ Billing CDRs │ Strong │ Sync DB │ PostgreSQL │ │ Routing rules │ Strong │ DB + cache │ PostgreSQL │ │ Statistics │ None │ Local only │ Memory │ └──────────────────┴─────────────┴──────────────┴─────────────┘
Real-World Example: Handling Network Partitions

The Scenario

Your cluster splits into two islands:

Before: After partition: A ←→ B A B ↕ ↕ ↓ ↓ C ←→ D C D
CP Behavior

# Only majority partition continues accepting registrations if (!pike_check_req()) { if (!has_quorum()) { sl_send_reply("503", "Service Unavailable - No Quorum"); exit; } }
Nodes A+C (if majority) continue. B+D reject new registrations.

Result: Half your users can't register, but data remains consistent.

AP Behavior

# All nodes continue operating independently route[REGISTER] { save("location"); # Save locally dmq_send_message(); # Sync when possible sl_send_reply("200", "OK"); }
Result: All users can register, but you might have duplicate registrations temporarily.

Post-Partition Reconciliation

When the partition heals, you need conflict resolution:

# Last-write-wins based on Contact timestamp route[DMQ_SYNC] { if ($var(remote_cseq) > $var(local_cseq)) { # Remote is newer, update local sql_query("UPDATE location SET contact='$var(remote_contact)' WHERE username='$rU'"); } }
Performance Implications

Benchmarking CP vs AP

In our lab testing with SIPp:

# CP Configuration (Centralized DB) sipp -sf REGISTER.xml -r 500 -l 10000 -m 50000 - Average response time: 45ms - 99th percentile: 120ms - Max throughput: 500 CPS # AP Configuration (DMQ + htable) sipp -sf REGISTER.xml -r 2000 -l 50000 -m 200000 - Average response time: 8ms - 99th percentile: 25ms - Max throughput: 2000+ CPS
The AP approach is 5-6x faster but with eventual consistency trade-offs.

Hybrid Architectures: Having Your Cake

The most sophisticated deployments use hybrid approaches:

Tiered Consistency Model

┌─────────────────────────────────────────────┐ │ Tier 1: Real-time (AP) │ │ - Registration lookup: DMQ + htable │ │ - Dialog state: DMQ + dialog module │ │ - Millisecond latency │ ├─────────────────────────────────────────────┤ │ Tier 2: Near-real-time (Eventual C) │ │ - Location backup: Async DB writes │ │ - Dialog backup: Periodic DB sync │ │ - Second-level latency │ ├─────────────────────────────────────────────┤ │ Tier 3: Batch (Strong C) │ │ - CDR generation: Sync DB writes │ │ - Billing records: Transactional │ │ - Sub-second latency acceptable │ └─────────────────────────────────────────────┘
Configuration Example

# Route registrations route[REGISTER] { # AP: Save to local htable immediately sht_insert("loc=>$au", "$ct"); # AP: Propagate via DMQ for cluster sync dmq_send_message(); # Eventual C: Queue for DB write mqueue_add("db_writes", "$au|$ct|$Ts"); sl_send_reply("200", "OK"); } # Background DB sync worker route[DB_WORKER] { while(mqueue_fetch("db_writes")) { sql_query("INSERT INTO location ..."); } }
When Consistency Actually Matters: Billing

One area where CP is non-negotiable: billing.

route[BYE] { # Calculate call duration $var(duration) = $TS - $dlg_var(start_time); # MUST write to database synchronously # Financial data cannot be "eventually consistent" sql_query("INSERT INTO cdrs (caller, callee, duration, cost) VALUES ('$fU', '$tU', '$var(duration)', '$var(cost)')"); if ($dbr(result) != 1) { xlog("L_ERR", "CRITICAL: CDR write failed for call $ci\n"); # Store in local queue for retry mqueue_add("cdr_retry", "$var(cdr_data)"); } }
Why CP here?

Regulatory requirements

Revenue protection

Audit trails

Fraud prevention

Losing a CDR means losing money and potentially violating regulations.

Observability: Monitoring CAP Trade-offs

You need metrics to understand your system's behavior:

# Consistency metrics - Registration sync lag (DMQ) - Database replication lag - Conflicting registrations detected # Availability metrics - Successful registration rate - Failed DB connections - Fallback activations # Partition detection - DMQ peer connectivity - Database connection health - Split-brain events
Sample prometheus metrics:

# Consistency kamailio_dmq_sync_lag_seconds kamailio_location_conflicts_total # Availability kamailio_registrations_success_total kamailio_registrations_failed_total kamailio_db_connection_failures_total
Conclusion: There Are No Perfect Solutions

The CAP theorem isn't a problem to solve—it's a constraint to navigate. In Kamailio architectures:

Partition tolerance is mandatory in distributed deployments

Choose CP when correctness is critical (billing, compliance)

Choose AP when responsiveness is critical (real-time signaling)

Use hybrid approaches for different data types

Monitor actively to understand actual consistency windows

The "right" architecture depends on your specific requirements, risk tolerance, and philosophical stance on the trade-off between truth and availability.

Remember: Every time you choose a replication strategy, configure a timeout, or design a failover mechanism, you're making a philosophical choice about what your system values most.

Further Reading

Original CAP theorem paper: Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services

Kamailio DMQ module documentation

My article: Philosophy of VoIP Infrastructure

Designing Data-Intensive Applications by Martin Kleppmann

What CAP trade-offs have you encountered in your telephony infrastructure? Share your experiences in the comments.
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

December 16, 2025

Andrea Sannucci Instalación y configuración de dnf-automatic en sistemas basados en DNF
Mantener un sistema Linux actualizado es una de las tareas más importantes —y a la vez más olvidadas— en la administración de servidores y equipos de trabajo. En distribuciones basadas en DNF como Fedora, RHEL, AlmaLinux, Rocky Linux o CentOS Stream, el paquete dnf-automatic permite automatizar el proceso de actualización de forma segura y controlada.

Este artículo explica qué es dnf-automatic, cómo instalarlo, cómo configurarlo correctamente y cuáles son las mejores prácticas para usarlo en producción.

¿Qué es dnf-automatic?

dnf-automatic es una extensión del gestor de paquetes DNF que permite ejecutar actualizaciones automáticas mediante systemd timers. Puede configurarse para:

Solo descargar actualizaciones

Aplicar automáticamente todas las actualizaciones

Aplicar solo actualizaciones de seguridad

Enviar notificaciones por correo electrónico

A diferencia de un simple cron + dnf update, dnf-automatic está integrado con DNF y systemd, lo que lo hace más robusto y predecible.

Requisitos previos

Sistema basado en DNF (Fedora, RHEL ≥ 8, AlmaLinux, Rocky, CentOS Stream)

Permisos de root o acceso mediante sudo

Repositorios configurados y accesibles

Instalación de dnf-automatic

sudo dnf install dnf-automatic
Una vez instalado, se añaden varios servicios y timers de systemd, pero no se activan automáticamente.

Estructura del servicio

dnf-automatic.timer → modo general

dnf-automatic-install.timer → instala actualizaciones

dnf-automatic-download.timer → solo descarga

dnf-automatic-notifyonly.timer → solo notifica

Archivo de configuración principal

El archivo central de configuración es:

/etc/dnf/automatic.conf
Sección [commands]

[commands] upgrade_type = security random_sleep = 0 download_updates = yes apply_updates = yes
Opciones principales:

upgrade_type: default o security

download_updates: descarga previa

apply_updates: aplicación automática

Sección [emitters]

[emitters] emit_via = email email_from = root@localhost email_to = admin@ejemplo.com email_host = localhost
Requiere un MTA configurado en el sistema.

Sección [base]

[base] debuglevel = 1
Activación del servicio

sudo systemctl enable --now dnf-automatic-install.timer
systemctl status dnf-automatic-install.timer
Programación de ejecución

systemctl list-timers | grep dnf
sudo systemctl edit dnf-automatic-install.timer
Seguridad y buenas prácticas

Usar solo actualizaciones de seguridad en servidores

Probar primero en staging

Activar notificaciones

Revisar el historial de cambios

dnf history
Diferencias con actualizaciones manuales

Manual (dnf update) dnf-automatic

Intervención manual Automatizado

Riesgo de olvido Actualizaciones constantes

Uso interactivo Ideal para servidores

dnf-automatic es una herramienta sólida para mantener sistemas Linux actualizados de forma segura y automatizada. Bien configurado, reduce riesgos sin comprometer la estabilidad del sistema.
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

Manual (dnf update)	dnf-automatic
Intervención manual	Automatizado
Riesgo de olvido	Actualizaciones constantes
Uso interactivo	Ideal para servidores

December 15, 2025

Andrea Sannucci Mi Primer Commit en RTPEngine: Fix para RHEL/AlmaLinux 9.x
Hace unas semanas conseguí que mi primer commit fuera aceptado en el proyecto RTPEngine. Te cuento cómo fue el proceso y qué problema resolvía.

El Problema

Mientras trabajaba en configurar RTPEngine en AlmaLinux 9.7, me encontré con que el módulo kernel nft_rtpengine no compilaba. El error indicaba que la función nft_expr_dump esperaba un parámetro reset que el código no estaba proporcionando.

Lo curioso del caso es que este parámetro se introdujo en el kernel 6.2.0, pero yo estaba usando el kernel 5.14.0-611.11.1.el9_7.x86_64 de AlmaLinux 9. En teoría no debería tener esa característica. Era una situación confusa.

La Investigación con Claude

Aquí fue donde Claude (el asistente de IA de Anthropic) resultó clave. Le planteé el problema y, tras analizar el error de compilación, Claude identificó que la causa estaba en los backports de RHEL.

La explicación que me dio Claude: RHEL (y sus derivados como AlmaLinux y Rocky Linux) mantienen versiones de kernel estables (5.14 para RHEL 9), pero hacen backports selectivos de características y correcciones de versiones más nuevas.

Esto significa que el kernel 5.14 de AlmaLinux 9 incluye características que no existen en el kernel 5.14 vanilla. Específicamente, Red Hat hizo backport del parámetro reset en nft_expr_dump desde el kernel 6.2.0.

Claude no solo identificó la causa, sino que me proporcionó la solución exacta que necesitaba implementar.

La Solución

La corrección fue directa: extender la condición de compilación condicional existente para incluir los kernels RHEL 9.x:

#if LINUX_VERSION_CODE >= KERNEL_VERSION(6,2,0) || \ (LINUX_VERSION_CODE >= KERNEL_VERSION(5,14,0) && \ defined(RHEL_RELEASE_CODE) && RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(9,0)) , bool reset #endif
La lógica es clara:

Si es kernel 6.2.0 o superior → incluye el parámetro reset

O si es kernel 5.14 o superior Y tiene definido RHEL_RELEASE_CODE Y es RHEL 9.0 o superior → incluye el parámetro reset

Esto cubre toda la familia RHEL 9 (RHEL, AlmaLinux, Rocky Linux) sin romper nada más.

El Proceso

Identificación: Detecté el problema al intentar compilar en AlmaLinux 9.7

Diagnóstico con Claude: Claude identificó que la causa eran los backports de RHEL y me proporcionó la solución específica

Implementación: Apliqué el fix que Claude me sugirió

Testing: Validé la solución en mi sistema (AlmaLinux 9.7, kernel 5.14.0-611.11.1.el9_7.x86_64)

Contribución: Abrí el issue #2037 y el pull request #2038

Merge: El mantenedor rfuchs aceptó el commit

Lecciones Aprendidas

Sobre RHEL y Backports

No asumas que un kernel 5.14 siempre se comporta igual. RHEL modifica su kernel base extensivamente

Usa las macros RHEL_RELEASE_CODE y RHEL_RELEASE_VERSION para detectar versiones específicas de RHEL

Esta situación afecta a toda la familia: RHEL, CentOS Stream, AlmaLinux, Rocky Linux, Oracle Linux

Sobre Contribuir a Open Source

Un problema que te afecta probablemente afecta a otros

La documentación clara es importante: incluí el sistema exacto donde probé (AlmaLinux 9.7, kernel específico)

El proceso fue más simple de lo que esperaba: issue → PR → merge

Usar herramientas de IA como Claude puede acelerar significativamente el diagnóstico de problemas complejos. Lo que podría haberme tomado horas o días de investigación, Claude lo identificó en minutos

Impacto

Este fix resuelve la compilación de nft_rtpengine para cualquiera usando RHEL 9 o sus derivados. Es un cambio pequeño pero necesario para que RTPEngine funcione correctamente en estas distribuciones enterprise, que son comunes en entornos de producción.

Recursos

Commit: https://github.com/sipwise/rtpengine/commit/503c4aaffe492e658df597152ba7...

Issue: https://github.com/sipwise/rtpengine/issues/2037

Pull Request: https://github.com/sipwise/rtpengine/pull/2038

Sistema probado: AlmaLinux 9.7, kernel 5.14.0-611.11.1.el9_7.x86_64

Identificador del commit: MT#55283
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

December 13, 2025

Andrea Sannucci Philosophy of VoIP Infrastructure: Why Your Technical Decisions Are Philosophical
I've just published something unusual: a complete philosophy course for VoIP engineers. Yes, you read that right. Philosophy. And no, I haven't lost my mind.

After years designing VoIP systems, I realized something uncomfortable: the most important decisions we make as engineers aren't technical. They're philosophical. When you choose between centralized vs distributed architecture, you're not choosing between technologies. You're choosing between visions of power and autonomy. When you configure timeouts, you're not just optimizing performance. You're defining what it means to wait and when it's ethical to stop. When you design your observability stack, you're not just "monitoring." You're deciding what counts as knowledge and what remains invisible.

And nobody prepared us for these questions.

Why philosophy?

Because the conceptual tools we need to think about complex systems already exist—they're just in philosophy books, not RFCs.

Concrete example:

# Your dashboard shows: active_calls = 347 # Is it true there are 347 calls?
This apparently simple question leads you directly to:

Ontology: What does it mean for a call to "exist"?

Epistemology: How do we know the counter is correct?

Time: Is the data "current" or stale?

Power: Who defines what counts as "active call"?

And you discover that Leslie Lamport already thought about this (logical clocks), that Foucault has much to say about surveillance embedded in your architecture, and that Bergson understood the difference between measured and lived time better than your Grafana dashboard.

What this course is NOT

Not abstract philosophy disconnected from practice

Not a Kamailio tutorial with decorative philosophical quotes

Not academic in the bad sense (pedantic, inaccessible)

Doesn't assume prior knowledge of philosophy

What this course IS

A rigorous but applied philosophical framework for thinking about VoIP.

Four modules:

Module 1: Ontology of VoIP Infrastructure

What exists and how does it exist?

The nature of protocols (SIP, Ship of Theseus, and the identity problem)

RTPEngine: relay vs transcode as ontological transformations

CAP theorem as philosophical problem (Parmenides vs Heraclitus in distributed systems)

Docker: images as Platonic Forms, containers as instances

Persistence: databases, RAM, CDRs and different modes of existence

Key question: Where does a VoIP call "exist"?

Module 2: Epistemology of Networked Systems

How do we know what we claim to know?

Direct vs indirect observation (all VoIP knowledge is mediated)

The time problem in distributed systems (Lamport, vector clocks, NTP)

Logs, metrics and traces as "technical testimony"

The uncertainty principle in observability (measuring alters the system)

Cognitive biases in debugging

Laboratory: Complete epistemological audit of your system

Key question: When is it rational to trust a log?

Module 3: Ethics and Politics of Architecture

Who benefits from each technical decision?

The Sophists and the rhetoric of technology (selling architectures)

Plato: Are there objectively superior design principles?

Habermas: Communicative rationality as ideal (conferences that facilitate genuine dialogue)

Foucault: Power inscribed in architecture (Panopticon, surveillance, GDPR)

Lawful intercept: analysis from four philosophical perspectives

Laboratory: Ethical-political analysis of your architecture

Key question: Is architecture neutral?

Module 4: Temporality and Processuality

Lived time vs measured time

Bergson: Duration vs spatialized time (CDR vs experience)

Husserl: The "living present" and jitter buffer as artificial retention

Whitehead: There are no "calls," there's "calling" (reality as process)

Heidegger: Vulgar time vs authentic temporality, timeouts as finitude

Synchrony, asynchrony and conversational rhythm

Laboratory: Complete temporal audit

Key question: Did that call last "247 seconds"?

Who this course is for

Yes, it's for you if:

You design or maintain VoIP systems

You make architectural decisions (not just implement)

You've asked yourself "why do we do things this way?"

You have intellectual curiosity beyond "works/doesn't work"

You want conceptual tools to think better

No, it's not for you if:

You're looking for a step-by-step Kamailio tutorial

You just want "best practices" without questioning them

The word "philosophy" seems like a waste of time to you

You need immediate results without reflection

Format and pricing

Format: 4 modules in Markdown, ready for Moodle or self-study

~80-100 pages of content

20+ integrated reflective exercises

4 comprehensive practical laboratories

Extensive bibliography per module

Available in Spanish and English

Price: Free

Access: https://campus.mesaproyectos.com/course/view.php?id=53

Why I made it free

Because philosophical knowledge should be accessible. Because the VoIP industry needs engineers who think critically, not just implement RFCs. Because someone taught me for free and I want to pay it forward.

A concrete example of what you'll learn

Take the CAP theorem. You know it: in distributed systems, you can only have 2 of 3: Consistency, Availability, Partition tolerance.

It's typically taught as a technical limitation.

In the course, you discover it's a fundamental ontological problem:

Consistency = Platonic position (there's ONE truth, centralized in DB)

Availability = Nominalist position (multiple local "truths" in each node)

Impossibility of both = not a bug, it's the nature of distributed reality

And you connect with Parmenides (being is one and immutable) vs Heraclitus (everything flows, nothing remains).

The CAP debate is the same debate the Greeks had 2500 years ago about the nature of reality.

Understanding this won't give you the technical solution, but it gives you conceptual clarity to communicate trade-offs, evaluate proposals, and design consciously.

Honest warning

This course will not make your Kamailio process more CPS.

It will make you understand why optimizing only for CPS falls short.

It won't give you easy answers. It will give you better questions.

It won't tell you which architecture to choose. It will give you criteria to decide consciously.

How to start

Enroll if you decide to continue

Complete one module per week (or at your own pace)

Do the laboratories — that's where real transformation happens

Apply what you learned immediately to your real systems

Final question

Why a course on philosophy of VoIP instead of simply better engineering of VoIP?

Because the hard problems aren't technical. They're conceptual.

You can learn Kamailio by reading the documentation.

But to understand why your centralized architecture generates certain power problems, why your metrics don't capture what really matters, why some timeouts feel "fair" and others "cruel"...

...for that you need philosophy.

And once you see these dimensions, you can't unsee them.

Your work won't be easier. It will be more conscious. And that makes all the difference.

Course access: https://campus.mesaproyectos.com/course/view.php?id=53

Questions: campus at mesaproyectos.com

Discussion: https://campus.mesaproyectos.com/mod/forum/view.php?id=2252

P.S.: If you think "I don't have time for philosophy," I understand. I thought the same. But it turns out that dedicating 20 hours to conceptually understanding what you do saves you hundreds of hours making wrong decisions. It's investment, not expense.

P.P.S.: If after Module 1 you think "this is a waste of time," I accept honest criticism. I only ask that you try it in good faith.
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo
Andrea Sannucci Filosofía de la Infraestructura VoIP: Por qué tus decisiones técnicas son filosóficas
Acabo de publicar algo inusual: un curso completo de filosofía para ingenieros VoIP. Sí, leíste bien. Filosofía. Y no, no he perdido la cabeza.

Después de años diseñando sistemas VoIP, me di cuenta de algo incómodo: las decisiones más importantes que tomamos como ingenieros no son técnicas. Son filosóficas. Cuando decides entre arquitectura centralizada vs distribuida, no estás eligiendo entre tecnologías. Estás eligiendo entre visiones del poder y la autonomía. Cuando configuras timeouts, no estás solo optimizando performance. Estás definiendo qué significa esperar y cuándo es ético dejar de hacerlo. Cuando diseñas tu stack de observabilidad, no estás solo "monitoreando". Estás decidiendo qué cuenta como conocimiento y qué queda invisible.

Y nadie nos preparó para estas preguntas.

¿Por qué filosofía?

Porque las herramientas conceptuales que necesitamos para pensar sobre sistemas complejos ya existen—solo que están en libros de filosofía, no en RFCs.

Ejemplo concreto:

# Tu dashboard muestra: active_calls = 347 # ¿Es verdad que hay 347 llamadas?
Esta pregunta aparentemente simple te lleva directamente a:

Ontología: ¿Qué significa que una llamada "exista"?

Epistemología: ¿Cómo sabemos que el contador es correcto?

Tiempo: ¿El dato es "actual" o stale?

Poder: ¿Quién define qué cuenta como "llamada activa"?

Y descubres que Leslie Lamport ya pensó sobre esto (relojes lógicos), que Foucault tiene mucho que decir sobre la vigilancia incorporada en tu arquitectura, y que Bergson entendía la diferencia entre tiempo medido y tiempo vivido mejor que tu dashboard de Grafana.

Qué NO es este curso

No es filosofía abstracta desconectada de la práctica

No es un tutorial de Kamailio con citas filosóficas decorativas

No es académico en el mal sentido (pedante, inaccesible)

No asume conocimiento previo de filosofía

Qué SÍ es este curso

Un framework filosófico riguroso pero aplicado para pensar sobre VoIP.

Cuatro módulos:

Módulo 1: Ontología de la Infraestructura VoIP

¿Qué existe y cómo existe?

La naturaleza de los protocolos (SIP, el barco de Teseo, y el problema de identidad)

RTPEngine: relay vs transcode como transformaciones ontológicas

CAP theorem como problema filosófico (Parménides vs Heraclito en sistemas distribuidos)

Docker: imágenes como Formas platónicas, containers como instancias

Persistencia: bases de datos, RAM, CDRs y diferentes modos de existencia

Pregunta clave: ¿Dónde "existe" una llamada VoIP?

Módulo 2: Epistemología de los Sistemas en Red

¿Cómo conocemos lo que afirmamos saber?

Observación directa vs indirecta (todo conocimiento sobre VoIP es mediado)

El problema del tiempo en sistemas distribuidos (Lamport, vector clocks, NTP)

Logs, métricas y trazas como "testimonio técnico"

El principio de incertidumbre en observabilidad (medir altera el sistema)

Sesgos cognitivos en debugging

Laboratorio: Auditoría epistemológica completa de tu sistema

Pregunta clave: ¿Cuándo es racional confiar en un log?

Módulo 3: Ética y Política de la Arquitectura

¿A quién beneficia cada decisión técnica?

Los sofistas y la retórica de la técnica (vender arquitecturas)

Platón: ¿Existen principios de diseño objetivamente superiores?

Habermas: La razón comunicativa como ideal (conferencias que facilitan diálogo genuino)

Foucault: El poder inscrito en la arquitectura (Panóptico, vigilancia, GDPR)

Lawful intercept: análisis desde cuatro perspectivas filosóficas

Laboratorio: Análisis ético-político de tu arquitectura

Pregunta clave: ¿Es neutral la arquitectura?

Módulo 4: Temporalidad y Procesualidad

El tiempo vivido vs el tiempo medido

Bergson: Duración vs tiempo espacializado (CDR vs experiencia)

Husserl: El "presente vivido" y el jitter buffer como retención artificial

Whitehead: No hay "llamadas", hay "llamar" (realidad como proceso)

Heidegger: Tiempo vulgar vs temporalidad auténtica, timeouts como finitud

Sincronía, asincronía y el ritmo conversacional

Laboratorio: Auditoría temporal completa

Pregunta clave: ¿Esa llamada duró "247 segundos"?

Para quién es este curso

Sí es para ti si:

Diseñas o mantienes sistemas VoIP

Tomas decisiones arquitectónicas (no solo implementas)

Te has preguntado "¿por qué hacemos las cosas así?"

Tienes curiosidad intelectual más allá del "funciona/no funciona"

Quieres herramientas conceptuales para pensar mejor

No es para ti si:

Buscas un tutorial paso-a-paso de Kamailio

Quieres solo "best practices" sin cuestionarlas

La palabra "filosofía" te parece una pérdida de tiempo

Necesitas resultados inmediatos sin reflexión

Formato y precio

Formato: 4 módulos en Markdown, listos para Moodle o autoestudio

~80-100 páginas de contenido

20+ ejercicios reflexivos integrados

4 laboratorios prácticos comprehensivos

Bibliografía extensa por módulo

Disponible en español e inglés

Precio:

Gratis

Acceso: https://campus.mesaproyectos.com/course/view.php?id=53

Por qué lo hice gratis

Porque el conocimiento filosófico debería ser accesible. Porque la industria VoIP necesita ingenieros que piensen críticamente, no solo que implementen RFCs. Porque alguien me enseñó gratis y quiero devolver el favor.

Un ejemplo concreto de lo que aprenderás

Toma el teorema CAP. Lo conoces: en sistemas distribuidos, solo puedes tener 2 de 3: Consistency, Availability, Partition tolerance.

Típicamente se enseña como limitación técnica.

En el curso, descubres que es un problema ontológico fundamental:

Consistency = posición platónica (hay UNA verdad, centralizada en DB)

Availability = posición nominalista (múltiples "verdades" locales en cada nodo)

Imposibilidad de ambas = no es bug, es la naturaleza de la realidad distribuida

Y conectas con Parménides (el ser es uno e inmutable) vs Heraclitus (todo fluye, nada permanece).

El debate CAP es el mismo debate que tuvieron los griegos hace 2500 años sobre la naturaleza de la realidad.

Entender esto no te da la solución técnica, pero te da claridad conceptual para comunicar trade-offs, evaluar propuestas, y diseñar conscientemente.

Advertencia honesta

Este curso no hará que tu Kamailio procese más CPS.

Sí hará que entiendas por qué optimizar solo CPS es quedarse corto.

No te dará respuestas fáciles. Te dará preguntas mejores.

No te dirá qué arquitectura elegir. Te dará criterios para decidir conscientemente.

Cómo empezar

Inscríbete si decides continuar

Completa un módulo por semana (o a tu ritmo)

Haz los laboratorios — son donde ocurre la verdadera transformación

Aplica lo aprendido inmediatamente a tus sistemas reales

Pregunta final

¿Por qué un curso sobre filosofía de VoIP en vez de simplemente mejor ingeniería de VoIP?

Porque los problemas duros no son técnicos. Son conceptuales.

Puedes aprender Kamailio leyendo la documentación.

Pero para entender por qué tu arquitectura centralizada genera ciertos problemas de poder, por qué tus métricas no capturan lo que realmente importa, por qué algunos timeouts se sienten "justos" y otros "crueles"...

...para eso necesitas filosofía.

Y una vez que ves estas dimensiones, no puedes dejar de verlas.

Tu trabajo no será más fácil. Será más consciente. Y eso marca toda la diferencia.

Acceso al curso: https://campus.mesaproyectos.com/course/view.php?id=53

Preguntas: campus at mesaproyectos.com

Discusión: https://campus.mesaproyectos.com/mod/forum/view.php?id=2252

P.D.: Si piensas "no tengo tiempo para filosofía", te entiendo. Yo pensaba igual. Pero resulta que dedicar 20 horas a entender conceptualmente lo que haces te ahorra cientos de horas tomando decisiones equivocadas. Es inversión, no gasto.

P.P.D.: Si después del Módulo 1 piensas "esto es una pérdida de tiempo", acepto críticas honestas. Solo te pido que lo intentes de buena fe.
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

December 12, 2025

Andrea Sannucci RTPEngine en AlmaLinux 9: Migración de iptables a nftables - URGENTE diciembre 2025

Este artículo documenta la evolución del módulo del kernel de RTPEngine, de xt_RTPENGINE a nft_rtpengine, y proporciona una guía completa de instalación en AlmaLinux 9 con configuración de nftables para entornos de producción VoIP.

Linux está en proceso de transición de iptables hacia nftables como sistema de filtrado de paquetes. Esta migración no es meramente cosmética; representa un rediseño arquitectónico del netfilter framework:

iptables: Framework legacy basado en múltiples comandos (iptables, ip6tables, arptables, ebtables)
nftables: Framework unificado que reemplaza todas las variantes anteriores con una sintaxis consistente

RTPEngine, como proxy de medios que depende del forwarding de paquetes en kernel space, debió adaptarse a esta realidad. El módulo del kernel evolucionó para mantener compatibilidad con el nuevo framework:

Aspecto	Método Antiguo (≤11.5)	Método Moderno (12.x+)
Módulo del kernel	`xt_RTPENGINE.ko`	`nft_rtpengine.ko`
Sistema de filtrado	iptables/ip6tables	nftables
Gestión de reglas	Manual vía CLI	Automática por daemon
Extensión iptables	Requerida (`libxt_RTPENGINE.so`)	No necesaria
Comando de carga	`modprobe xt_RTPENGINE`	`modprobe nft_rtpengine`

Aclaración importante: No es una sustitución completa

El módulo nft_rtpengine sigue siendo técnicamente un módulo x_tables (la infraestructura subyacente de iptables). Lo que cambió fue su integración con nftables, eliminando la necesidad de gestión manual de reglas y permitiendo al daemon de RTPEngine controlar el netfilter directamente.

Por esta razón, al ejecutar nft list ruleset, verás el mensaje XT target RTPENGINE not found en la salida. Este mensaje es normal y esperado - la herramienta nft no puede interpretar targets de x_tables, pero el kernel sí los procesa correctamente.

# Verificar versión del sistema
cat /etc/redhat-release
# AlmaLinux release 9.x (Turquoise Kodkod)

# Actualizar sistema base
dnf update -y
reboot

# Instalar Development Tools y activar los repositorios CRB
dnf config-manager --set-enabled crb
dnf groupinstall "Development Tools" -y

# Instalar kernel headers (esencial para compilar módulos)
dnf install kernel-devel-$(uname -r) -y

Dependencias de compilación

# Dependencias base de RTPEngine
dnf install -y \
    glib2-devel \
    zlib-devel \
    openssl-devel \
    pcre-devel \
    libcurl-devel \
    xmlrpc-c-devel \
    libevent-devel \
    json-glib-devel \
    hiredis-devel \
    gperf \
    libpcap-devel \
    perl-IPC-Cmd \
    libwebsockets-devel \
    nftables \
    pandoc \
    iptables-legacy-devel \
    ncurses-devel \
    libjwt-devel \
    libatomic \
    mysql-devel

# Dependencias para transcoding (opcional)
dnf install -y \
    libavcodec-free-devel libavdevice-free-devel libavfilter-free-devel \
    libavformat-free-devel libavutil-free-devel libpostproc-free-devel \
    libswresample-free-devel libswscale-free-devel \
    spandsp-devel \
    opus-devel \
    bcg729-devel

# Dependencias para DTLS/SRTP
dnf install -y \
    openssl-devel \
    libsrtp-devel

RTPENGINE

Descarga del código fuente

# Clonar repositorio
cd /usr/src
git clone https://github.com/sipwise/rtpengine.git
cd /usr/src/rtpengine/daemon
make
cp rtpengine /usr/local/bin
cd /usr/src/rtpengine/kernel-module
nano +6832 nft_rtpengine.c

se modifica este bloque:

static int rtpengine_expr_dump(struct sk_buff *skb, const struct nft_expr *expr
#if LINUX_VERSION_CODE >= KERNEL_VERSION(6,2,0)
                , bool reset
#endif
)

para que quede:

static int rtpengine_expr_dump(struct sk_buff *skb, const struct nft_expr *expr, bool reset)

se guardan los cambios y 

make
make install
modinfo nft_rtpengine | head -n 10

Salida esperada de modinfo:

filename:       /lib/modules/5.14.0-611.11.1.el9_7.x86_64/updates/nft_rtpengine.ko
alias:          nft-expr-rtpengine
alias:          ip6t_RTPENGINE
alias:          ipt_RTPENGINE
alias:          xt_RTPENGINE
import_ns:      CRYPTO_INTERNAL
description:    rtpengine packet forwarding acceleration
author:         Sipwise GmbH <support@sipwise.com>
license:        GPL
rhelversion:    9.7

Carga del módulo del kernel

modprobe nft_rtpengine

# Verificar que está cargado
lsmod | grep nft_rtpengine
# nft_rtpengine    147456  0

# Verificar interfaz /proc
ls -la /proc/rtpengine/
# total 0
# dr-xr-xr-x 2 root root 0 Dec 12 10:10 .
# -w--w---- 1 root root 0 Dec 12 10:10 control

# Configurar carga automática al boot
echo "nft_rtpengine" > /etc/modules-load.d/rtpengine.conf

# Verificar configuración
cat /etc/modules-load.d/rtpengine.conf
# nft_rtpengine

NFTABLES

nft flush ruleset
nft add table inet filter
nft add chain inet filter input { type filter hook input priority 0 \; policy accept \; }
nft add rule inet filter input iif lo accept
nft add rule inet filter input ct state established,related accept
nft add rule inet filter input ip protocol icmp accept
nft add rule inet filter input ip6 nexthdr ipv6-icmp accept
nft add rule inet filter input tcp dport 22 accept
nft add rule inet filter input udp dport 5060 accept
nft add rule inet filter input udp dport 10000-20000 accept
nft add rule inet filter input counter drop
nft add chain inet filter forward { type filter hook forward priority 0 \; policy drop \; }
nft add chain inet filter output { type filter hook output priority 0 \; policy accept \; }

systemctl enable nftables
systemctl start nftables
nft list ruleset
nft list ruleset > /etc/nftables/rtpengine.nft

nano /etc/sysconfig/nftables.conf

al final del archvio se añade:

include "/etc/nftables/rtpengine.nft"

se guardan los cambios

Configuración de RTPEngine

useradd -r -s /sbin/nologin -M rtpengine

Crear estructura de directorios

# Directorio de configuración
mkdir -p /etc/rtpengine

# Directorio de logs
mkdir -p /var/log/rtpengine
chown rtpengine:rtpengine /var/log/rtpengine

# Directorio de recordings (si se usa)
mkdir -p /var/spool/rtpengine
chown rtpengine:rtpengine /var/spool/rtpengine

Archivo de configuración principal

cat > /etc/rtpengine/rtpengine.conf << 'EOF'
[rtpengine]

# Interfaces de red
# Formato: [nombre]/[IP_local]![IP_anunciada]
# Si no hay NAT, solo: [nombre]/[IP]
interface = pub/IP_PUBLICA

# Control de Kamailio/OpenSIPS
listen-ng = 127.0.0.1:2223

# Rango de puertos RTP
port-min = 10000
port-max = 20000

# Timeout configurations (en segundos)
timeout = 60
silent-timeout = 3600
final-timeout = 7200
offer-timeout = 60

# Kernel forwarding table ID
table = 0

# Logging
log-level = 6
log-facility = local1
log-facility-cdr = local2

# DTLS certificates (generados automáticamente si no existen)
# dtls-passive

# nftables configuration (gestión automática)
# El daemon creará y gestionará las chains automáticamente
nftables-chain = rtpengine
nftables-base-chain = input

# Redis para clustering (opcional)
# redis = 127.0.0.1:6379
# redis-db = 0

# Recording (opcional)
# recording-dir = /var/spool/rtpengine
# recording-method = pcap
# recording-format = eth

# Performance tuning
num-threads = 4

# B2BUA mode (si se usa)
# b2b-url = http://127.0.0.1:8080

# Delete delay para cleanup
delete-delay = 30

# TOS/DSCP marking
# tos = 184
EOF

Configuración de rsyslog para logs de RTPEngine

cat > /etc/rsyslog.d/rtpengine.conf << 'EOF'
# RTPEngine call logs
local1.* /var/log/rtpengine/rtpengine.log

# RTPEngine CDR logs
local2.* /var/log/rtpengine/rtpengine-cdr.log

# Stop processing if matched
local1.* stop
local2.* stop
EOF

# Reiniciar rsyslog
systemctl restart rsyslog

Configuración de logrotate

cat > /etc/logrotate.d/rtpengine << 'EOF'
/var/log/rtpengine/*.log {
    daily
    rotate 14
    missingok
    notifempty
    compress
    delaycompress
    sharedscripts
    postrotate
        /usr/bin/systemctl reload rsyslog > /dev/null 2>&1 || true
    endscript
}
EOF

Crear systemd service

cat > /etc/systemd/system/rtpengine.service << 'EOF'
[Unit]
Description=RTPEngine Media Proxy
After=network-online.target
Wants=network-online.target
Documentation=https://github.com/sipwise/rtpengine

[Service]
Type=forking
PIDFile=/run/rtpengine/rtpengine.pid
EnvironmentFile=-/etc/default/rtpengine
RuntimeDirectory=rtpengine

# Pre-start: verificar que el módulo está cargado
ExecStartPre=/bin/bash -c 'lsmod | grep -q nft_rtpengine || modprobe nft_rtpengine'

# Start daemon
ExecStart=/usr/local/bin/rtpengine \
    --pidfile=/run/rtpengine/rtpengine.pid \
    --config-file=/etc/rtpengine/rtpengine.conf

# Reload configuration
ExecReload=/bin/kill -HUP $MAINPID

# Stop daemon
ExecStop=/bin/kill -TERM $MAINPID

# Restart policy
Restart=on-failure
RestartSec=10

# Security hardening
NoNewPrivileges=true
PrivateTmp=true

# User/Group
User=root
Group=root

# Capabilities necesarias para kernel module
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_RAW CAP_SYS_NICE
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW CAP_SYS_NICE

[Install]
WantedBy=multi-user.target
EOF

# Reload systemd
systemctl daemon-reload

# Habilitar servicio
systemctl enable rtpengine

Iniciar y Verificar RTPEngine

Iniciar el servicio

# Iniciar RTPEngine
systemctl start rtpengine

# Verificar estado
systemctl status rtpengine

Salida esperada:

Verificar módulo del kernel

# Verificar módulo cargado
lsmod | grep nft_rtpengine
# nft_rtpengine         102400  4

# Verificar /proc interface
ls -la /proc/rtpengine/
# dr-xr-xr-x 3 root root 0 Dec 12 10:30 .
# drwxr-xr-x 2 root root 0 Dec 12 10:30 0
# -w--w---- 1 root root 0 Dec 12 10:30 control

# Verificar tabla de forwarding (0 es el default)
ls -la /proc/rtpengine/0/
# dr-xr-xr-x. 6 root root 0 Dec 12 17:00 .
# dr-xr-xr-x. 5 root root 0 Dec 12 16:55 ..
# dr-xr-xr-x. 2 root root 0 Dec 12 17:02 calls
# -rw-rw----. 1 root root 0 Dec 12 17:00 control
# -r--r--r--. 1 root root 0 Dec 12 17:02 list
# -r--r--r--. 1 root root 0 Dec 12 17:02 status

nft list ruleset | grep rtpengine

Salida esperada:

ip protocol udp counter packets 14 bytes 1953 jump rtpengine
chain rtpengine {
continue comment "rtpengine UDP handler"
ip6 nexthdr udp counter packets 0 bytes 0 jump rtpengine
chain rtpengine {
continue comment "rtpengine UDP handler"

Verificar logs

# Ver logs en tiempo real
tail -f /var/log/rtpengine/rtpengine.log

# Buscar errores
grep -i error /var/log/rtpengine/rtpengine.log

# Buscar warnings
grep -i warning /var/log/rtpengine/rtpengine.log

Monitoreo de contadores de nftables

# Ver contadores de la chain rtpengine
watch -n 1 'nft list chain ip filter rtpengine'

Verás los contadores incrementarse:

Logs de RTPEngine

# Ver kernelization messages
tail -f /var/log/rtpengine/rtpengine.log | grep -i kernel

Mensajes esperados:

INFO: [call-id port 10000]: [core] Kernelizing media stream: 198.51.100.50:50000 -> 203.0.113.10:10000
INFO: [call-id port 10002]: [core] Kernelizing media stream: 198.51.100.50:50002 -> 203.0.113.10:10002

Troubleshooting

Problema: Módulo no carga

Síntoma:

modprobe nft_rtpengine
modprobe: ERROR: could not insert 'nft_rtpengine': Exec format error

Causa: Kernel headers no coinciden con kernel en ejecución

Solución:

# Verificar versión del kernel
uname -r
# 5.14.0-362.24.1.el9_3.x86_64

# Verificar headers instalados
rpm -qa | grep kernel-devel
# kernel-devel-5.14.0-362.8.1.el9_3.x86_64  <-- NO COINCIDE

# Instalar headers correctos
dnf install -y kernel-devel-$(uname -r)

# Recompilar módulo
cd /usr/src/rtpengine/kernel-module
make clean
make
make install
depmod -a

Problema: "Failed to create nftables chains"

Síntoma:

rtpengine[12346]: Fatal error: Failed to create nftables chains or rules

Causas posibles:

nftables no está instalado:

dnf install -y nftables
systemctl enable nftables
systemctl start nftables

Permisos insuficientes:

# Verificar capabilities en systemd service
grep Capabilities /etc/systemd/system/rtpengine.service
# AmbientCapabilities=CAP_NET_ADMIN CAP_NET_RAW CAP_SYS_NICE

Chain base no existe:

# Crear chain INPUT si no existe
nft add table inet filter
nft add chain inet filter input { type filter hook input priority 0 \; policy accept \; }

Problema: Paquetes no llegan al kernel module

Síntoma: /proc/rtpengine/0/list permanece vacío durante llamadas

Diagnóstico:

# 1. Verificar que el módulo está cargado
lsmod | grep nft_rtpengine

# 2. Verificar que la chain rtpengine existe
nft list chain inet filter rtpengine

# 3. Verificar que hay un jump desde INPUT a rtpengine
nft list chain inet filter input | grep rtpengine

# 4. Capturar tráfico RTP
tcpdump -i any -n 'udp portrange 10000-20000' -c 10

# 5. Verificar logs de rtpengine para mensajes de kernelization
grep -i kernel /var/log/rtpengine/rtpengine.log

Solución común: Verificar que el tráfico UDP realmente pasa por nftables:

# Agregar logging temporal para debug
nft insert rule inet filter input ip protocol udp log prefix "UDP packet: "

# Ver logs
dmesg -T | grep "UDP packet"

# Remover regla de logging después
nft list ruleset -a  # Encontrar handle de la regla
nft delete rule inet filter input handle <número>

Problema: Llamadas no procesan audio

Diagnóstico completo:

# 1. Verificar que RTPEngine recibe signaling de Kamailio
tail -f /var/log/rtpengine/rtpengine.log | grep offer

# 2. Verificar que puertos RTP están abiertos
ss -ulnp | grep rtpengine

# 3. Verificar firewall
nft list ruleset | grep 10000-20000

# 4. Verificar NAT (si aplica)
# Si RTPEngine está detrás de NAT, verificar interface configuration:
grep interface /etc/rtpengine/rtpengine.conf
# Debe ser: interface = external/[IP_local]![IP_pública]

# 5. Capturar paquetes RTP
tcpdump -i any -n -s 0 -vvv 'udp portrange 10000-20000' -w /tmp/rtp.pcap

# 6. Analizar con tshark
tshark -r /tmp/rtp.pcap -Y rtp

Optimización y Tuning

Ajustes del kernel para alta carga

cat >> /etc/sysctl.d/99-rtpengine.conf << 'EOF'
# Aumentar límites de sockets
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
net.core.rmem_default = 67108864
net.core.wmem_default = 67108864
net.core.netdev_max_backlog = 30000

# UDP buffer sizes
net.ipv4.udp_rmem_min = 16384
net.ipv4.udp_wmem_min = 16384

# Aumentar rango de puertos locales
net.ipv4.ip_local_port_range = 1024 65535

# Mejorar handling de conexiones
net.core.somaxconn = 4096
net.ipv4.tcp_max_syn_backlog = 8192

# Reducir TIME_WAIT
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1
EOF

# Aplicar cambios
sysctl -p /etc/sysctl.d/99-rtpengine.conf

Ajustes de RTPEngine para alta concurrencia

# En /etc/rtpengine/rtpengine.conf, ajustar:

# Aumentar threads (1.5-2x número de cores)
num-threads = 8

# Aumentar rango de puertos
port-min = 10000
port-max = 30000

# Ajustar timeouts según carga
timeout = 60
silent-timeout = 1800

# Habilitar Homer para monitoring (opcional)
# homer = 127.0.0.1:9060
# homer-protocol = udp
# homer-id = 2001

Ventajas del método moderno:

Gestión automática: RTPEngine controla directamente las reglas de nftables
Menos pasos manuales: No se requiere compilar extensiones de iptables
Sintaxis unificada: nftables ofrece una interfaz consistente para IPv4 e IPv6
Mejor performance: nftables tiene mejor rendimiento en reglas complejas
Preparado para el futuro: Alineado con la dirección del kernel Linux

Consideraciones filosóficas:

Desde una perspectiva heracliteana, este cambio ilustra la naturaleza fundamental del software: la permanencia es una ilusión. Los sistemas deben adaptarse o volverse obsoletos. RTPEngine, al evolucionar con el ecosistema Linux en lugar de resistirse, asegura su relevancia continua.

Sin embargo, como Aristóteles nos recordaría, el cambio debe ser teleológico - dirigido hacia un fin. El fin aquí es claro: mejor mantenibilidad, mejor integración con el sistema operativo moderno, y preparación para futuras evoluciones del netfilter framework.

Recomendaciones finales:

Sistemas nuevos: Usar siempre el método moderno (nft_rtpengine + nftables)
Sistemas legacy: Planificar migración durante ventana de mantenimiento
Documentación: Mantener documentación actualizada con referencias a versiones específicas
Monitoreo: Implementar monitoreo robusto para detectar problemas temprano
Testing: Probar exhaustivamente en entorno no productivo antes de migrar producción

Referencia:

RTPEngine GitHub: https://github.com/sipwise/rtpengine
Documentación oficial: https://rtpengine.readthedocs.io/
nftables Wiki: https://wiki.nftables.org/
AlmaLinux Documentation: https://wiki.almalinux.org/

Vota el Articulo:

December 10, 2025

Andrea Sannucci 15 Comandos DNF Indispensables para AlmaLinux 9
DNF es el gestor de paquetes por defecto en AlmaLinux 9, sucesor de YUM y basado en RPM. Dominar sus comandos esenciales te permitirá mantener tu sistema actualizado, seguro y funcionando correctamente. Esta guía presenta 15 comandos que todo administrador de AlmaLinux debe conocer.

1. Actualizar la lista de repositorios

sudo dnf check-update
Este comando consulta todos los repositorios configurados y muestra qué paquetes tienen actualizaciones disponibles sin instalarlas. Es útil para planificar mantenimientos y conocer el estado del sistema antes de aplicar cambios.

2. Actualizar todos los paquetes del sistema

sudo dnf update
Descarga e instala todas las actualizaciones disponibles para los paquetes instalados en el sistema. Este es el comando principal para mantener AlmaLinux actualizado con los últimos parches de seguridad y correcciones de errores.

3. Buscar paquetes

dnf search nombre_paquete
Busca paquetes en los repositorios utilizando palabras clave. Examina tanto los nombres como las descripciones de los paquetes, devolviendo todas las coincidencias posibles. Extremadamente útil cuando no conoces el nombre exacto del paquete que necesitas.

4. Obtener información detallada de un paquete

dnf info nombre_paquete
Muestra información completa sobre un paquete específico: versión, arquitectura, tamaño, repositorio de origen, resumen y descripción detallada. Funciona tanto para paquetes instalados como disponibles en repositorios.

5. Instalar un paquete

sudo dnf install nombre_paquete
Descarga e instala el paquete especificado junto con todas sus dependencias necesarias. DNF resuelve automáticamente el árbol de dependencias y solicita confirmación antes de proceder con la instalación.

6. Eliminar un paquete

sudo dnf remove nombre_paquete
Desinstala el paquete especificado del sistema. Por defecto, también elimina los paquetes que dependían exclusivamente del paquete removido, limpiando huérfanos automáticamente.

7. Listar paquetes instalados

dnf list installed
Muestra todos los paquetes actualmente instalados en el sistema con sus versiones y repositorios de origen. Puedes filtrar la salida combinándolo con grep para búsquedas específicas.

8. Limpiar la caché de DNF

sudo dnf clean all
Elimina todos los archivos temporales descargados por DNF, incluyendo paquetes, metadatos de repositorios y cachés de bases de datos. Libera espacio en disco y fuerza la descarga de metadatos frescos en la próxima operación.

9. Listar repositorios habilitados

dnf repolist
Muestra todos los repositorios actualmente habilitados en el sistema con información sobre el número de paquetes disponibles en cada uno. Útil para verificar qué fuentes de software están configuradas.

10. Buscar qué paquete proporciona un archivo

dnf provides */nombre_archivo
Identifica qué paquete contiene un archivo específico, incluso si el paquete no está instalado. Invaluable cuando necesitas un comando o biblioteca específica pero no sabes qué paquete lo proporciona.

11. Ver el historial de transacciones

dnf history
Muestra un registro completo de todas las operaciones realizadas con DNF: instalaciones, actualizaciones, eliminaciones y sus fechas. Cada transacción tiene un ID que permite revertirla si es necesario.

12. Deshacer una transacción

sudo dnf history undo ID
Revierte una transacción específica identificada por su ID del historial. DNF intentará devolver el sistema al estado anterior a esa operación, reinstalando o eliminando paquetes según corresponda.

13. Instalar un grupo de paquetes

sudo dnf groupinstall "nombre del grupo"
Instala conjuntos predefinidos de paquetes relacionados, como entornos de escritorio o herramientas de desarrollo. Los grupos facilitan la instalación de múltiples componentes con un solo comando.

14. Actualizar únicamente paquetes de seguridad

sudo dnf update --security
Aplica exclusivamente las actualizaciones clasificadas como parches de seguridad, ignorando otras actualizaciones disponibles. Ideal para sistemas de producción donde se priorizan correcciones críticas sobre nuevas funcionalidades.

15. Comprobar dependencias rotas

sudo dnf check
Verifica la integridad de la base de datos de paquetes y detecta dependencias insatisfechas o problemas de consistencia. Ejecutarlo periódicamente ayuda a mantener la salud del sistema de paquetes.

Dominar estos comandos DNF te convertirá en un administrador más eficiente de AlmaLinux 9. La gestión de paquetes es fundamental para la seguridad, estabilidad y rendimiento de cualquier servidor Linux en producción.
- DNF
- Almalinux 9
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

December 09, 2025

Andrea Sannucci 5 Formas de Realizar Depuración en Asterisk 20
1. Consola CLI con Verbosity

La forma más básica y común es aumentar el nivel de verbosidad directamente desde la consola CLI:

asterisk -rvvvvv
O una vez dentro de la CLI:

*CLI> core set verbose 5 *CLI> core set debug 5
Cada "v" adicional incrementa el nivel de detalle. Esto es útil para ver el flujo de llamadas en tiempo real, problemas de registro SIP, y ejecución del dialplan.

2. Debug SIP Específico

Para depurar problemas relacionados con PJSIP (que es lo que usas en Asterisk 20):

*CLI> pjsip set logger on *CLI> pjsip set logger verbose on
Esto muestra todos los mensajes SIP completos (INVITE, REGISTER, BYE, etc.) con headers y SDP. Es fundamental para diagnosticar problemas de señalización, NAT, y codec negotiation.

Para depurar un endpoint específico:

*CLI> pjsip set logger host 192.168.1.100
3. Logging en Archivos con logger.conf

Configura logging personalizado en /etc/asterisk/logger.conf para capturar diferentes niveles de información en archivos separados:

[logfiles] console => notice,warning,error,debug messages => notice,warning,error full => notice,warning,error,debug,verbose,dtmf debug => debug pjsip_history => notice,warning,error,debug,verbose
Luego recargas:

*CLI> logger reload *CLI> logger rotate
Los logs quedan en /var/log/asterisk/. Esta técnica es excelente para análisis post-mortem y depuración de problemas intermitentes.

4. PJSIP History

Asterisk 20 con PJSIP incluye un historial interno muy potente:

*CLI> pjsip show history *CLI> pjsip show history entry <id>
Guarda automáticamente las últimas transacciones SIP en memoria, permitiendo revisar llamadas recientes sin necesidad de capturar paquetes. Puedes configurar el tamaño del buffer en pjsip.conf:

[system] pjsip_history_size=1000
5. Captura de Paquetes con tcpdump/sngrep

Para depuración a nivel de red, especialmente problemas de RTP o signaling complejo:

Con tcpdump:

tcpdump -i any -n -s 0 -w /tmp/asterisk-$(date +%Y%m%d-%H%M%S).pcap port 5060 or portrange 10000-20000
Con sngrep (mucho más amigable):

sngrep port 5060
sngrep es particularmente útil porque te muestra los flujos de llamadas visualmente, permitiendo ver la secuencia completa de mensajes SIP y detectar rápidamente dónde falla una transacción. Puedes filtrar por IP, método SIP, o Call-ID.

Consejo Práctico

Para depuración completa de un problema específico, combina varios métodos. Por ejemplo:

pjsip set logger on

core set verbose 5

sngrep corriendo en paralelo

Esto te da visibilidad completa del signaling, dialplan execution, y transporte de paquetes.

Comandos Útiles Adicionales

# Ver configuración de PJSIP pjsip show endpoints pjsip show aors pjsip show auths # Ver llamadas activas core show channels pjsip show channels # Ver registro de dispositivos pjsip show registrations # Reiniciar logging logger reload logger rotate
Niveles de Debug/Verbose

0-2: Información mínima, solo errores críticos

3-4: Información estándar de operación

5-7: Debug detallado, recomendado para troubleshooting

8-10: Debug extremo, puede generar MUCHA información
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

December 04, 2025

Andrea Sannucci Parqueo de Llamadas en Asterisk 20: Guía Completa de Configuración
El parqueo de llamadas (call parking) es una funcionalidad esencial en sistemas telefónicos empresariales que permite a los usuarios "estacionar" temporalmente una llamada en un slot virtual para que pueda ser recuperada desde cualquier otro teléfono en la red. En Asterisk 20, esta característica se implementa a través del módulo res_parking y ofrece gran flexibilidad de configuración.

¿Qué es el Call Parking?

Imagina esta situación: recibes una llamada en tu extensión y necesitas que un compañero en otra área la atienda. En lugar de transferirla directamente, puedes "parquear" la llamada en un slot (por ejemplo, el 701), colgar y simplemente gritarle a tu compañero "llamada en el 701". Él marca 701 desde su teléfono y recupera la llamada.

El parqueo de llamadas se configura en el archivo res_parking.conf, ubicado en /etc/asterisk/. Este archivo define los contextos de parqueo, los rangos de slots disponibles y el comportamiento del sistema.

Estructura Básica del Archivo

[general] ; Configuración global del módulo de parqueo [default] ; Contexto de parqueo por defecto parkext => 700 ; Extensión para parquear llamadas parkpos => 701-720 ; Rango de slots de parqueo disponibles context => parkedcalls ; Contexto donde van las llamadas parqueadas parkingtime => 45 ; Tiempo de espera antes de retornar (segundos) comebacktoorigin => yes ; Retornar al origen si no se recupera comebackcontext => default ; Contexto al que retorna comebackdialtime => 30 ; Tiempo de marcado al retornar courtesytone => beep ; Tono de cortesía al parquear parkedplay => caller ; A quién se reproduce música (caller/callee/both) parkedmusicclass => default ; Clase de música en espera findslot => next ; Algoritmo de búsqueda (next/first) parkedcalltransfers => caller ; Quién puede transferir (caller/callee/both/no) parkedcallreparking => caller ; Quién puede re-parquear (caller/callee/both/no) parkedcallhangup => caller ; Quién puede colgar (caller/callee/both/no) parkedcallrecording => caller ; Quién puede grabar (caller/callee/both/no)
Ejemplo de Configuración Completa

[general] [companyparking] ; Parqueo para la empresa principal parkext => 700 parkpos => 701-720 context => parkedcalls parkingtime => 60 comebacktoorigin => yes comebackcontext => from-internal courtesytone => beep parkedplay => caller parkedmusicclass => default findslot => next [vipparking] ; Parqueo especial para clientes VIP con más tiempo parkext => 800 parkpos => 801-810 context => vip-parkedcalls parkingtime => 120 comebacktoorigin => yes comebackcontext => from-internal courtesytone => beep parkedplay => both parkedmusicclass => vip-music
Aplicaciones Principales

1. Park()

Parquea la llamada actual en un slot disponible.

; Uso básico exten => _*85,1,Park() ; Parqueo en un contexto específico exten => _*86,1,Park(companyparking) ; Parqueo con opciones exten => _*87,1,Park(,,,s) ; 's' = anunciar el slot
Opciones de Park():

s = Announce slot (anunciar el número de slot)

r = Return to parker on timeout (retornar al que parqueó)

R = Randomize return position (posición aleatoria de retorno)

c(context) = Override comeback context (sobrescribir contexto de retorno)

t(timeout) = Override timeout (sobrescribir tiempo de espera)

2. ParkedCall()

Recupera una llamada parqueada desde un slot específico.

; Recuperar llamada del slot 701 exten => 701,1,ParkedCall(701) ; Recuperar con contexto específico exten => 801,1,ParkedCall(801,vipparking)
3. ParkAndAnnounce()

Parquea la llamada y anuncia el slot en otro canal.

; Sintaxis: ; ParkAndAnnounce(announce_template,timeout,dial,return_context) exten => _*88,1,ParkAndAnnounce(pbx-parkingspot:PARKED,45,SIP/recepcion)
Esta aplicación es útil cuando quieres que el sistema llame automáticamente a alguien y le diga "Llamada parqueada en el slot X".

Funciones Dialplan

PARK_GET_CHANNEL()

Obtiene el canal parqueado en un slot específico.

exten => _*89,1,NoOp(Verificando slot 701) exten => _*89,n,Set(PARKED_CHANNEL=${PARK_GET_CHANNEL(701)}) exten => _*89,n,GotoIf($["${PARKED_CHANNEL}" = ""]?empty:occupied) exten => _*89,n(occupied),NoOp(Slot 701 ocupado por: ${PARKED_CHANNEL}) exten => _*89,n,Hangup() exten => _*89,n(empty),NoOp(Slot 701 está libre) exten => _*89,n,Hangup()

Sintaxis:

${PARK_GET_CHANNEL(parking_space[,parking_lot])}

parking_space = Número del slot (ej: 701)

parking_lot = Nombre del lote de parqueo (opcional, usa default si no se especifica)

Retorna el nombre del canal parqueado o cadena vacía si el slot está libre

Para Teléfonos SIP/PJSIP

Los endpoints deben estar configurados para poder acceder al contexto de parqueo y recuperar llamadas parqueadas.

Configuración en pjsip.conf

[6001](endpoint-basic) type=endpoint context=from-internal allow=!all,ulaw,alaw,g722 auth=6001 aors=6001 ; Permitir transferencias para parqueo allow_transfer=yes trust_id_outbound=yes [6001] type=auth auth_type=userpass password=secreto123 username=6001 [6001] type=aor max_contacts=1
Configuración en extensions.conf

Debes crear un contexto que incluya acceso al parqueo:

[from-internal] ; Acceso a extensiones internas exten => _6XXX,1,Dial(PJSIP/${EXTEN},30) ; Feature code para PARQUEAR llamada (durante llamada activa) exten => _*85,1,Park() exten => _*85,n,Hangup() ; Recuperar llamadas parqueadas (marcando el slot) include => parkedcalls ; Ver estado de parking slots exten => *90,1,Answer() exten => *90,n,Playback(silence/1) exten => *90,n,ParkingStatus() exten => *90,n,Hangup() [parkedcalls] ; Este contexto es generado dinámicamente por Asterisk ; Automáticamente contiene los slots 701-720 según res_parking.conf ; No necesitas definir manualmente cada extensión
Uso con Blind Transfer (Transferencia Ciega)

Para que los usuarios puedan parquear llamadas usando el botón de transferencia de su teléfono:

[from-internal] ; ... otras extensiones ... ; Extensión 700 = Parqueo automático exten => 700,1,Park() exten => 700,n,Hangup() ; Slots de recuperación (se incluyen automáticamente) include => parkedcalls
Proceso del usuario:

Usuario está en llamada activa

Presiona botón "Transfer" (transferencia ciega)

Marca 700

Sistema parquea la llamada y anuncia el slot

Usuario cuelga

Para recuperar:

Cualquier usuario marca el número de slot (ej: 701)

Se conecta con la llamada parqueada

Comando CLI: parking show

Desde la consola de Asterisk, puedes monitorear el estado de los slots:

asterisk -rx "parking show"
Salida ejemplo:

Parking lot: companyparking Extension: 700 Context: parkedcalls Parking positions: 701-720 Parking time: 60 seconds Comeback context: from-internal Parked calls: Space Channel Caller Timeout 701 PJSIP/6001-00000012 6002 45 seconds 703 PJSIP/6003-00000014 6005 30 seconds 2 parked calls
Script de Monitoreo con AMI (Asterisk Manager Interface)

Puedes crear scripts para monitorear los slots via AMI:

#!/usr/bin/env python3 import asterisk.manager # Conectar al AMI manager = asterisk.manager.Manager() manager.connect('localhost') manager.login('admin', 'password') # Obtener estado de parking response = manager.command('parking show companyparking') print(response.data) manager.logoff()
Hints para BLF (Busy Lamp Field)

Configura hints para que los teléfonos con teclas BLF muestren el estado de los slots:

[from-internal] ; Hints para parking slots exten => 701,hint,park:701@companyparking exten => 702,hint,park:702@companyparking exten => 703,hint,park:703@companyparking ; ... hasta 720
En el teléfono (ejemplo Yealink):

<BLFList> <Unit1 Key="1" Label="Park 701" Value="701" Extension="701"/> <Unit2 Key="2" Label="Park 702" Value="702" Extension="702"/> <Unit3 Key="3" Label="Park 703" Value="703" Extension="703"/> </BLFList>
Los LEDs del teléfono mostrarán:

Verde: Slot libre

Rojo: Slot ocupado

Parpadeando: Llamada próxima a timeout

Notificaciones Personalizadas

Crear un script que envíe alertas cuando un slot está por hacer timeout:

[parkedcalls-custom] ; Cuando una llamada está cerca del timeout exten => h,1,NoOp(Call timeout warning) exten => h,n,System(echo "Slot ${PARKEDLOT} timeout in 10 seconds" | mail -s "Parking Alert" admin@empresa.com)
Configuración Avanzada: Múltiples Lotes de Parqueo

Puedes crear diferentes lotes para diferentes departamentos:

[sales-parking] parkext => 7000 parkpos => 7001-7010 context => sales-parked parkingtime => 45 comebackcontext => sales-context [support-parking] parkext => 8000 parkpos => 8001-8020 context => support-parked parkingtime => 90 comebackcontext => support-context [vip-parking] parkext => 9000 parkpos => 9001-9005 context => vip-parked parkingtime => 180 comebackcontext => vip-context parkedmusicclass => vip-hold-music
En extensions.conf:

[sales-context] exten => _8XXX,1,Dial(PJSIP/${EXTEN}) exten => 7000,1,Park(sales-parking) include => sales-parked [support-context] exten => _9XXX,1,Dial(PJSIP/${EXTEN}) exten => 8000,1,Park(support-parking) include => support-parked
Solución de Problemas Comunes

Problema: Las llamadas no se parquean

Verificar:

Módulo cargado: module show like parking

Configuración válida: parking show

Contexto incluido en dialplan

Permisos de transferencia en endpoint

Problema: No se pueden recuperar llamadas parqueadas

Verificar:

Include del contexto parkedcalls en el dialplan del usuario

Que el slot existe: parking show

Que el usuario tiene acceso al contexto correcto

Problema: Llamadas retornan antes de tiempo

Verificar:

Parámetro parkingtime en res_parking.conf

RTP timeout en pjsip.conf: rtp_timeout y rtp_timeout_hold

Debugging

Habilitar logs de parking:

; En logger.conf [logfiles] parking => notice,warning,error,debug,verbose
Desde CLI:

core set verbose 5 core set debug 5 module reload res_parking.so
Mejores Prácticas

Timeouts apropiados: No menos de 45 segundos para evitar retornos prematuros

Límite de slots: No crear más slots de los necesarios (máximo 20-30 por lote)

Música en espera: Configurar MOH apropiada para mantener al llamante informado

BLF monitoring: Implementar hints para visibilidad inmediata

Contextos separados: Usar diferentes lotes para diferentes departamentos

Documentación: Capacitar a usuarios sobre los feature codes (*85, 700, etc.)

Monitoreo: Implementar scripts de alertas para timeouts

Backup configuration: Siempre respaldar res_parking.conf antes de cambios

El sistema de parqueo de llamadas en Asterisk 20 es una herramienta poderosa que mejora significativamente la experiencia de manejo de llamadas en entornos empresariales. Con una configuración adecuada de res_parking.conf, las aplicaciones correctas en el dialplan y endpoints bien configurados, puedes implementar un sistema robusto que incluye monitoreo visual a través de BLF y notificaciones automáticas de timeout.

La clave está en:

Configurar correctamente res_parking.conf con timeouts y rangos apropiados

Incluir el contexto parkedcalls en los contextos de usuarios

Configurar hints para monitoreo BLF en teléfonos

Implementar feature codes intuitivos (*85 para parquear, 700 como extensión de parqueo)

Monitorear activamente el estado de los slots para prevenir pérdidas de llamadas

Con esta guía completa, estás listo para implementar y administrar un sistema profesional de parqueo de llamadas en tu infraestructura Asterisk 20.
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

November 28, 2025

Andrea Sannucci Dialplan de Asterisk vs Dialplan de FreeSWITCH: Comparación y Guía de Selección
Cuando se trata de sistemas de telefonía VoIP de código abierto, Asterisk y FreeSWITCH son dos titanes que dominan el panorama. Ambos son potentes, flexibles y ampliamente utilizados, pero su enfoque del dialplan —el corazón lógico que controla el flujo de llamadas— difiere significativamente. En este artículo exploraremos las diferencias fundamentales entre ambos sistemas y te ayudaremos a decidir cuál es el más adecuado para tu proyecto.

Asterisk: El Enfoque Tradicional

El dialplan de Asterisk utiliza un formato declarativo basado en texto plano, organizado en el archivo extensions.conf. Su sintaxis se basa en contextos, extensiones y prioridades, con una lógica secuencial que resulta familiar para quienes vienen del mundo de las centrales telefónicas tradicionales.

Ejemplo básico en Asterisk:

[from-internal] exten => 100,1,Answer() same => n,Playback(welcome) same => n,Dial(SIP/usuario1,30) same => n,VoiceMail(100@default) same => n,Hangup()
La filosofía de Asterisk es pragmática y directa: cada línea ejecuta una aplicación, y el flujo avanza secuencialmente a menos que se use GoTo u otras instrucciones de control.

FreeSWITCH: El Poder del XML

FreeSWITCH adopta un enfoque radicalmente diferente con su dialplan basado en XML. El archivo principal es dialplan/default.xml, y utiliza una estructura de condiciones y acciones que permite una lógica más compleja y modular.

Ejemplo equivalente en FreeSWITCH:

<extension name="local-extension-100"> <condition field="destination_number" expression="^100$"> <action application="answer"/> <action application="playback" data="welcome.wav"/> <action application="bridge" data="user/usuario1"/> <action application="voicemail" data="default ${domain_name} 100"/> </condition> </extension>
FreeSWITCH se inspira en arquitecturas empresariales modernas, privilegiando la modularidad y la capacidad de procesamiento en paralelo.

Sintaxis y Curva de Aprendizaje

Asterisk:

Sintaxis más simple y legible para principiantes

Documentación extensa con décadas de ejemplos comunitarios

Menor barrera de entrada para administradores de sistemas

La lógica condicional requiere aplicaciones específicas (GotoIf, ExecIf)

FreeSWITCH:

XML puede parecer verboso inicialmente

Mayor consistencia estructural en configuraciones complejas

Las condiciones son parte integral del lenguaje

Mejor separación entre lógica y datos

Capacidades de Procesamiento

Asterisk:

Excelente para PBX tradicionales de pequeña a mediana escala

Manejo robusto de protocolos: SIP, IAX2, PJSIP

Amplio ecosistema de módulos y aplicaciones

El procesamiento secuencial puede ser limitante en escenarios de alta concurrencia

FreeSWITCH:

Diseñado desde cero para alta concurrencia y baja latencia

Arquitectura multi-hilo más eficiente

Manejo superior de transcoding y conferencias

Escalabilidad horizontal más natural

Variables y Manipulación de Datos

Asterisk:

exten => _X.,1,Set(CALLERID(name)=Empresa ${CALLERID(num)}) same => n,Set(TIMEOUT(digit)=5) same => n,Dial(SIP/${EXTEN})
Las variables se gestionan con funciones como Set(), ${VAR} y diversas funciones de cadena.

FreeSWITCH:

<action application="set" data="effective_caller_id_name=Empresa ${caller_id_number}"/> <action application="set" data="continue_on_fail=true"/> <action application="bridge" data="sofia/internal/${destination_number}@${domain_name}"/>
FreeSWITCH ofrece un sistema de variables de canal más consistente y predecible.

Integración con Lenguajes de Scripting

Asterisk:

AGI (Asterisk Gateway Interface) para scripts externos

AMI (Asterisk Manager Interface) para control remoto

Dialplan propio con lógica básica

Soporte para Lua, Python mediante módulos adicionales

FreeSWITCH:

ESL (Event Socket Library) extremadamente potente

Soporte nativo para JavaScript, Lua, Python, Perl

Módulo mod_xml_curl para dialplan dinámico vía HTTP

Mayor flexibilidad para integrar lógica externa

Elige Asterisk si:

Tu proyecto es una PBX empresarial tradicional Asterisk brilla en implementaciones de oficina donde necesitas extensiones, buzones de voz, IVR, colas de llamadas y funcionalidades típicas de una centralita. La abundante documentación y ejemplos te permitirán implementar rápidamente.

Tienes un equipo con experiencia en Asterisk El ecosistema de Asterisk es maduro y robusto. Si tu equipo ya conoce la plataforma, aprovecha esa experiencia. La curva de aprendizaje para nuevos desarrolladores también es más suave.

Necesitas compatibilidad con hardware heredado Asterisk tiene soporte excepcional para tarjetas Digium/Sangoma y una amplia gama de dispositivos analógicos y digitales. Si tu infraestructura incluye líneas E1/T1, FXS/FXO, Asterisk es probablemente la mejor opción.

Tu carga de llamadas es moderada (menos de 500 llamadas concurrentes) Para la mayoría de pequeñas y medianas empresas, el rendimiento de Asterisk es más que suficiente y su simplicidad operativa es una ventaja.

Elige FreeSWITCH si:

Necesitas escalabilidad y alto rendimiento Si planeas manejar miles de llamadas simultáneas, conferencias masivas o servicios de carrier-grade, FreeSWITCH está diseñado específicamente para esto. Su arquitectura multi-hilo y optimizaciones de bajo nivel son superiores.

Tu aplicación requiere procesamiento de medios intensivo Transcoding entre múltiples códecs, conferencias con muchos participantes, grabación masiva, procesamiento de audio en tiempo real: FreeSWITCH maneja estos escenarios con mayor eficiencia.

Trabajas en un entorno de telefonía como servicio (UCaaS/CPaaS) Proveedores de servicios, plataformas multi-tenant y aplicaciones de contact center se benefician de la arquitectura modular y la escalabilidad de FreeSWITCH.

Necesitas integración profunda con aplicaciones web modernas El Event Socket Library de FreeSWITCH es extraordinariamente flexible. Puedes controlar llamadas en tiempo real desde prácticamente cualquier lenguaje de programación, lo que lo hace ideal para aplicaciones WebRTC y desarrollo ágil.

Priorizas latencia ultra-baja Aplicaciones de trading de voz, sistemas de emergencia o cualquier escenario donde los milisegundos importan favorecen a FreeSWITCH.

No tienes que elegir solo uno. Muchas implementaciones profesionales utilizan ambos sistemas:

Asterisk como PBX de oficina para extensiones internas, mientras FreeSWITCH actúa como session border controller (SBC) o gateway de trunking.

FreeSWITCH para el core de enrutamiento de alta capacidad, con Asterisk gestionando funcionalidades específicas como IVR o voicemail.

Usar Kamailio como proxy SIP frontal, distribuyendo carga entre clusters de Asterisk o FreeSWITCH según el tipo de llamada.

Comunidad y Soporte

Asterisk:

Comunidad masiva y activa desde 1999

Documentación exhaustiva en múltiples idiomas

Soporte comercial de Sangoma

Miles de tutoriales, blogs y foros

FreeSWITCH:

Comunidad más técnica y especializada

Documentación oficial excelente pero menos ejemplos comunitarios

Soporte comercial de SignalWire

Mayor enfoque en casos de uso avanzados

Actualizaciones y Mantenimiento

Ambos proyectos se mantienen activamente, pero con ritmos diferentes:

Asterisk tiene un ciclo de versiones más conservador, priorizando estabilidad

FreeSWITCH tiende a adoptar nuevas tecnologías más rápidamente

La migración entre versiones mayores puede ser compleja en ambos casos

Conclusión

No existe un ganador absoluto entre Asterisk y FreeSWITCH. La elección correcta depende de tus requisitos específicos:

Asterisk es la navaja suiza de la telefonía VoIP: versátil, bien documentado y perfecto para la mayoría de escenarios empresariales tradicionales. Su dialplan es accesible y su ecosistema maduro.

FreeSWITCH es el deportivo de alto rendimiento: potente, escalable y diseñado para cargas exigentes. Su dialplan XML puede parecer más complejo inicialmente, pero ofrece mayor flexibilidad para arquitecturas sofisticadas.

En Social's contexto, trabajando con infraestructura VoIP avanzada y Kamailio, FreeSWITCH podría ofrecer mejor integración y rendimiento para escenarios de carrier-grade. Sin embargo, si la prioridad es rapidez de implementación y mantenibilidad para funcionalidades PBX estándar, Asterisk sigue siendo una elección sólida.

La mejor recomendación: evalúa ambos con prototipos que reflejen tu caso de uso real. El tiempo invertido en testing te ahorrará problemas futuros y te permitirá tomar una decisión basada en datos concretos, no solo en especificaciones técnicas.

¿Tienes experiencia con alguno de estos sistemas? ¿Qué factores fueron decisivos en tu elección? Comparte tu experiencia en los comentarios.
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo
Andrea Sannucci El archivo features.conf en Asterisk PBX v.20
El archivo features.conf es uno de los componentes fundamentales en la configuración de Asterisk PBX, ya que define las funcionalidades de llamada que los usuarios pueden activar mediante secuencias DTMF durante una conversación activa. Estas características incluyen transferencias, grabación y otras funciones avanzadas que enriquecen la experiencia telefónica.

El archivo features.conf controla las funcionalidades en llamada (in-call features) que permiten a los usuarios manipular llamadas activas sin necesidad de colgar. Las principales funcionalidades que gestiona son:

Transferencias de llamadas: Permite transferir una llamada a otra extensión, ya sea de forma ciega (blind transfer) o atendida (attended transfer).

Grabación de llamadas: Activa o desactiva la grabación de conversaciones durante la llamada mediante códigos DTMF.

Desconexión de llamadas: Permite a cualquiera de las partes finalizar la llamada mediante una secuencia específica.

Características personalizadas: Define funcionalidades adicionales mediante aplicaciones dialplan que se activan con códigos DTMF.

Pickup de llamadas: Permite contestar llamadas que están sonando en otras extensiones.

Configuración del archivo features.conf

El archivo features.conf se estructura en varias secciones principales. A continuación se detalla cada una con ejemplos prácticos:

Sección [general]

Esta sección contiene parámetros globales que afectan al comportamiento general de las características:

[general] transferdigittimeout = 3 atxfernoanswertimeout = 15 atxferdropcall = no atxferloopdelay = 10 atxfercallbackretries = 2 courtesytone = beep xfersound = beep xferfailsound = beeperr pickupexten = *8 pickupsound = beep pickupfailsound = beeperr featuredigittimeout = 2000 transferdialattempts = 3 transferretrysound = beep transferinvalidsound = beeperr
transferdigittimeout: Tiempo en segundos para ingresar dígitos durante una transferencia (por defecto 3 segundos). Si el usuario no completa la marcación de la extensión destino en este tiempo, la operación se cancela.

atxfernoanswertimeout: Tiempo de espera en segundos cuando no se contesta una transferencia atendida (por defecto 15 segundos). Si el destino no contesta, la llamada puede regresar al origen.

atxferdropcall: Define si se cuelga la llamada original cuando falla una transferencia atendida. Valores: yes/no (por defecto: no).

atxferloopdelay: Retraso en segundos antes de reintentar una transferencia fallida.

atxfercallbackretries: Número de intentos para devolver la llamada al origen cuando falla una transferencia atendida.

courtesytone: Tono que se reproduce a ambas partes antes de reconectar después de una transferencia atendida. Puede ser "beep", un archivo de sonido personalizado, o estar vacío.

xfersound: Tono que se reproduce al iniciar una transferencia exitosa.

xferfailsound: Tono que se reproduce cuando una transferencia falla.

pickupexten: Código para contestar llamadas de otras extensiones (call pickup). El valor por defecto es *8.

pickupsound: Tono que se reproduce al realizar un pickup exitoso.

pickupfailsound: Tono que se reproduce cuando el pickup falla.

featuredigittimeout: Tiempo en milisegundos para esperar entre dígitos al activar una característica (por defecto 2000ms). Este parámetro es crítico para la detección correcta de códigos DTMF.

transferdialattempts: Número de intentos permitidos para marcar el destino durante una transferencia.

transferretrysound: Tono reproducido cuando se puede reintentar la transferencia.

transferinvalidsound: Tono reproducido cuando se marca una extensión inválida durante la transferencia.

Sección [featuremap]

Define los códigos DTMF para activar cada funcionalidad. Esta es la sección más importante del archivo:

[featuremap] blindxfer => *1 atxfer => *2 disconnect => *0 automon => *3 automixmon => *4
blindxfer: Código para transferencia ciega (blind transfer). El usuario marca el código, introduce la extensión destino y la llamada se transfiere inmediatamente sin hablar con el destino. El formato es: durante la llamada, presionar *1, marcar extensión destino, la transferencia se completa automáticamente.

atxfer: Código para transferencia atendida (attended transfer). El usuario marca el código, habla con el destino antes de completar la transferencia y puede cancelarla si es necesario. El proceso es: presionar *2, marcar extensión, hablar con el destino, colgar para completar o presionar * para cancelar.

disconnect: Permite colgar la llamada desde cualquiera de los extremos. Útil cuando los endpoints no tienen un botón de colgar confiable o en conferencias.

automon: Activa la grabación de la llamada usando la aplicación Monitor. Graba los canales por separado (entrada y salida en archivos diferentes).

automixmon: Activa la grabación usando MixMonitor, que mezcla ambos canales en un solo archivo. Este es el método preferido en versiones modernas de Asterisk.

Códigos adicionales disponibles:

disconnect: Desconecta la llamada

parkcall: Estaciona la llamada (requiere configuración adicional de parking)

atxferthreeway: Crea conferencia de tres vías durante transferencia atendida

Sección [applicationmap]

Permite crear funcionalidades personalizadas que ejecutan aplicaciones del dialplan. Esta sección es extremadamente poderosa para extender las capacidades de Asterisk:

[applicationmap] pauseagent => *5,self/caller,Pause() unpauseagent => *6,self/caller,Unpause() togglehold => *7,self,Macro(toggle-hold) conference => *9,peer,ConfBridge(${EXTEN})
La sintaxis es: nombre => código,activador,aplicación(argumentos)

Parámetros de activador:

caller: Solo el que llama puede activar la característica

callee: Solo el que recibe puede activar la característica

both: Cualquiera de las dos partes puede activarla

self: La característica afecta al canal que la activa

peer: La característica afecta al canal de la otra parte

self/caller: Combinación que especifica que afecta a quien llama si es el caller

Ejemplos prácticos:

[applicationmap] ; Pausar/despausar agente en cola pauseagent => *5,self,PauseQueueMember(,Local/${CALLERID(num)}@from-internal) unpauseagent => *6,self,UnpauseQueueMember(,Local/${CALLERID(num)}@from-internal) ; Enviar llamada a buzón de voz sendtovm => *8,self,VoiceMail(${EXTEN}@default,s) ; Agregar la llamada a una conferencia existente addtoconf => *9,both,ConfBridge(sala1) ; Activar/desactivar spy en otro canal startspy => #1,self,ChanSpy(PJSIP,q) ; Ejecutar una macro personalizada customaction => **1,caller,Macro(custom-action,${EXTEN}) ; Activar/desactivar grabación con MixMonitor togglerecord => *3,both,System(/usr/local/bin/toggle-recording.sh ${CHANNEL})
Variables de canal importantes

Durante la ejecución de características personalizadas, Asterisk proporciona variables especiales:

${DYNAMIC_FEATURES}: Lista de características dinámicas habilitadas para el canal

${DYNAMIC_WHO_ACTIVATED}: Quién activó la característica (caller/callee)

${CHANNEL}: Canal actual

${BRIDGEPEER}: Canal del peer conectado

Sección [featuregroups]

Permite agrupar características en conjuntos reutilizables:

[featuregroups] agentfeatures => pauseagent,unpauseagent,togglerecord managerfeatures => #startspy,#addtoconf,#togglerecord customerfeatures => #blindxfer
Para activar un grupo de características en un canal, se usa:

; En el dialplan same => n,Set(DYNAMIC_FEATURES=agentfeatures) same => n,Dial(PJSIP/${EXTEN})
Integración con pjsip.conf

La integración de features.conf con los endpoints definidos en pjsip.conf es crucial para que las funcionalidades DTMF operen correctamente. Hay varios parámetros que deben configurarse adecuadamente.

Parámetros críticos en pjsip.conf

Para que un endpoint pueda utilizar las características definidas en features.conf, debe configurarse con los siguientes parámetros:

[6001](basic-endpoint) type = endpoint context = internal disallow = all allow = ulaw allow = alaw aors = 6001 auth = 6001 direct_media = no dtmf_mode = rfc4733 one_touch_recording = yes allow_transfer = yes
dtmf_mode: Este es el parámetro más importante. Define cómo se transmiten los tonos DTMF:

rfc4733 (recomendado): Envía DTMF como eventos RTP fuera de banda. Es el método más confiable, consume menos ancho de banda y no se degrada por códecs de audio. Este es el valor que debes usar.

inband: DTMF se envía como tonos audibles dentro del flujo de audio. Puede degradarse con códecs comprimidos y es menos confiable. Solo usar si los dispositivos no soportan RFC4733.

info: DTMF se envía mediante mensajes SIP INFO. Menos común y puede tener problemas de compatibilidad.

auto: Asterisk intenta detectar automáticamente el método. No recomendado para producción.

auto_info: Combinación de auto e info.

direct_media: Debe estar configurado en "no" para que Asterisk permanezca en el path del media y pueda detectar los códigos DTMF de características. Si está en "yes", el audio (RTP) fluye directamente entre endpoints y Asterisk no puede interceptar las secuencias DTMF. Esta es la razón número uno por la que las características no funcionan.

one_touch_recording: Habilita la grabación mediante código DTMF definido en featuremap (normalmente *3 para automon o *4 para automixmon).

allow_transfer: Permite transferencias de llamada para este endpoint. Si está en "no", los códigos de transferencia no funcionarán.

Configuración de direct_media y media_address

En escenarios más complejos, puedes necesitar:

[6001](basic-endpoint) type = endpoint ; ... otras opciones ... direct_media = no media_address = 192.168.1.10 rtp_symmetric = yes force_rport = yes rewrite_contact = yes
media_address: IP que Asterisk anuncia en SDP. Útil cuando Asterisk está detrás de NAT.

rtp_symmetric: Envía RTP a la dirección origen en lugar de la anunciada en SDP.

force_rport: Fuerza el uso del puerto remoto real.

rewrite_contact: Reescribe el contacto SIP basándose en la IP/puerto de origen.

Habilitar características específicas por canal

Puedes habilitar características dinámicamente en el dialplan:

[internal] exten => _6XXX,1,NoOp(Llamando a extensión ${EXTEN}) same => n,Set(DYNAMIC_FEATURES=blindxfer#atxfer#automon) same => n,Set(__DYNAMIC_FEATURES=${DYNAMIC_FEATURES}) same => n,Dial(PJSIP/${EXTEN},30) same => n,Hangup()
La variable DYNAMIC_FEATURES contiene una lista separada por # de las características que estarán disponibles durante la llamada. El doble guión bajo (__) hace que la variable se herede a los canales bridged.

features.conf completo

[general] ; Configuración de temporización transferdigittimeout = 3 atxfernoanswertimeout = 15 atxferdropcall = no atxferloopdelay = 10 atxfercallbackretries = 2 featuredigittimeout = 2000 transferdialattempts = 3 ; Tonos y sonidos courtesytone = beep xfersound = beep xferfailsound = beeperr transferretrysound = beep transferinvalidsound = beeperr ; Pickup de llamadas pickupexten = *8 pickupsound = beep pickupfailsound = beeperr [featuremap] ; Códigos DTMF para características estándar blindxfer => *1 ; Transferencia ciega atxfer => *2 ; Transferencia atendida disconnect => *0 ; Desconectar llamada automon => *3 ; Grabar con Monitor (dos archivos) automixmon => *4 ; Grabar con MixMonitor (un archivo) [applicationmap] ; Características personalizadas pauseagent => *5,self,Macro(pause-agent) unpauseagent => *6,self,Macro(unpause-agent) togglehold => *7,self,Macro(toggle-hold) addconf => *9,both,ConfBridge(sala_${CALLERID(num)}) sendtovm => **1,self,VoiceMail(${EXTEN}@default,s) emergency => ***911,caller,Dial(PJSIP/emergency-line) [featuregroups] ; Grupos de características agentfeatures => pauseagent,unpauseagent,automixmon supervisorfeatures => pauseagent,unpauseagent,automixmon,addconf basicfeatures => blindxfer,atxfer,automixmon
pjsip.conf correspondiente

; ============================================ ; TRANSPORTE ; ============================================ [transport-udp] type = transport protocol = udp bind = 0.0.0.0:5060 external_media_address = TU.IP.PUBLICA.AQUI external_signaling_address = TU.IP.PUBLICA.AQUI local_net = 192.168.1.0/24 ; ============================================ ; PLANTILLA BASE PARA ENDPOINTS ; ============================================ [basic-endpoint](!) type = endpoint context = internal disallow = all allow = ulaw allow = alaw allow = g722 ; CRUCIAL: Parámetros para que funcionen las características direct_media = no ; Asterisk debe ver el RTP dtmf_mode = rfc4733 ; Método DTMF recomendado allow_transfer = yes ; Habilitar transferencias one_touch_recording = yes ; Habilitar grabación DTMF ; Parámetros NAT (ajustar según necesidad) rtp_symmetric = yes force_rport = yes rewrite_contact = yes ; Otros parámetros útiles trust_id_inbound = yes send_pai = yes callerid = "Extension ${EXTEN}" <${EXTEN}> ; ============================================ ; ENDPOINTS ESPECÍFICOS ; ============================================ ; Agente de call center con características extendidas [6001](basic-endpoint) auth = auth6001 aors = 6001 callerid = "Agente 1" <6001> [auth6001] type = auth auth_type = userpass username = 6001 password = agentePass123! [6001] type = aor max_contacts = 1 remove_existing = yes ; Usuario básico con características limitadas [6002](basic-endpoint) auth = auth6002 aors = 6002 callerid = "Usuario 2" <6002> [auth6002] type = auth auth_type = userpass username = 6002 password = userPass456! [6002] type = aor max_contacts = 1 ; Supervisor con todas las características [6003](basic-endpoint) auth = auth6003 aors = 6003 callerid = "Supervisor" <6003> [auth6003] type = auth auth_type = userpass username = 6003 password = superPass789! [6003] type = aor max_contacts = 2 remove_existing = yes ; ============================================ ; TRUNK SIP (ejemplo) ; ============================================ [trunk-proveedor](!) type = endpoint context = from-trunk disallow = all allow = ulaw allow = alaw direct_media = no dtmf_mode = rfc4733 [proveedor-sip](trunk-proveedor) auth = auth-proveedor aors = proveedor-sip outbound_auth = auth-proveedor [auth-proveedor] type = auth auth_type = userpass username = tu_usuario_trunk password = tu_password_trunk [proveedor-sip] type = aor contact = sip:tu_proveedor.com:5060 [proveedor-sip] type = identify endpoint = proveedor-sip match = IP.DEL.PROVEEDOR
extensions.conf (dialplan) integrado

[general] static = yes writeprotect = no [globals] RECORDING_DIR = /var/spool/asterisk/monitor ; ============================================ ; CONTEXTO PARA EXTENSIONES INTERNAS ; ============================================ [internal] ; Extensiones de agentes con características completas exten => _600[1-5],1,NoOp(=== Llamada a Agente ${EXTEN} ===) same => n,Set(__DYNAMIC_FEATURES=agentfeatures) same => n,Set(CHANNEL(language)=es) same => n,Dial(PJSIP/${EXTEN},30,tTkK) same => n,Goto(no-answer,1) ; Extensiones de supervisores con características extendidas exten => _600[6-9],1,NoOp(=== Llamada a Supervisor ${EXTEN} ===) same => n,Set(__DYNAMIC_FEATURES=supervisorfeatures) same => n,Set(CHANNEL(language)=es) same => n,Dial(PJSIP/${EXTEN},30,tTkK) same => n,Goto(no-answer,1) ; Usuarios básicos exten => _61XX,1,NoOp(=== Llamada a Usuario ${EXTEN} ===) same => n,Set(__DYNAMIC_FEATURES=basicfeatures) same => n,Set(CHANNEL(language)=es) same => n,Dial(PJSIP/${EXTEN},20,tTkK) same => n,Goto(no-answer,1) ; Manejo de no respuesta exten => no-answer,1,NoOp(No hubo respuesta de ${EXTEN}) same => n,VoiceMail(${EXTEN}@default,su) same => n,Hangup() ; Acceso a buzón de voz exten => *97,1,NoOp(=== Acceso a Buzón de Voz ===) same => n,VoiceMailMain(${CALLERID(num)}@default) same => n,Hangup() ; Pickup de llamadas exten => *8,1,NoOp(=== Call Pickup ===) same => n,Pickup() same => n,Hangup() ; Pickup de grupo exten => **8,1,NoOp(=== Group Pickup ===) same => n,PickupChan(PJSIP/${EXTEN}) same => n,Hangup() ; Sala de conferencia exten => 9000,1,NoOp(=== Conferencia Principal ===) same => n,Answer() same => n,ConfBridge(sala1) same => n,Hangup() ; Eco test exten => 9999,1,NoOp(=== Echo Test ===) same => n,Answer() same => n,Echo() same => n,Hangup() ; ============================================ ; MACROS PARA CARACTERÍSTICAS PERSONALIZADAS ; ============================================ [macro-pause-agent] exten => s,1,NoOp(=== Pausando Agente ===) same => n,PauseQueueMember(,Local/${CALLERID(num)}@from-internal) same => n,Playback(agent-paused) same => n,MacroExit() [macro-unpause-agent] exten => s,1,NoOp(=== Despausando Agente ===) same => n,UnpauseQueueMember(,Local/${CALLERID(num)}@from-internal) same => n,Playback(agent-unpaused) same => n,MacroExit() [macro-toggle-hold] exten => s,1,NoOp(=== Toggle Hold ===) same => n,Set(HOLD_STATUS=${DB(hold/${CHANNEL})}) same => n,GotoIf($["${HOLD_STATUS}" = "1"]?unhold:hold) same => n(hold),Set(DB(hold/${CHANNEL})=1) same => n,MusicOnHold() same => n,MacroExit() same => n(unhold),Set(DB(hold/${CHANNEL})=0) same => n,StopMusicOnHold() same => n,MacroExit() ; ============================================ ; CONTEXTO DESDE TRUNK ; ============================================ [from-trunk] exten => _X.,1,NoOp(=== Llamada entrante desde trunk: ${CALLERID(num)} ===) same => n,Set(CHANNEL(language)=es) same => n,Goto(internal,${EXTEN},1) exten => _6XXX,1,NoOp(=== DID a extensión ${EXTEN} ===) same => n,Goto(internal,${EXTEN},1)
En el dialplan, la aplicación Dial() acepta flags que interactúan con features.conf:

Dial(PJSIP/extension,timeout,options)
Opciones importantes:

t: Permite a quien llama usar características de transferencia

T: Permite a quien recibe usar características de transferencia

k: Permite a quien llama usar características de parking

K: Permite a quien recibe usar características de parking

w: Permite a quien llama usar características de automon

W: Permite a quien recibe usar características de automon

Ejemplo combinado:

same => n,Dial(PJSIP/${EXTEN},30,tTkKwW)
Esto habilita todas las características para ambas partes.

Verificar configuración

Desde la CLI de Asterisk:

# Ver configuración actual de features asterisk -rx "features show" # Ver características mapeadas asterisk -rx "core show config features.conf" # Verificar endpoints PJSIP asterisk -rx "pjsip show endpoints" # Ver detalles de un endpoint específico asterisk -rx "pjsip show endpoint 6001"
Activar logs detallados

# En la consola de Asterisk asterisk -rvvvv # O aumentar verbosidad core set verbose 5 core set debug 5 # Logs específicos de DTMF core set debug 3
Problemas comunes y soluciones

Las características DTMF no funcionan:

Solución 1: Verificar que direct_media = no en pjsip.conf

Solución 2: Confirmar que dtmf_mode = rfc4733 tanto en endpoint como que el dispositivo lo soporte

Solución 3: Revisar que los códigos en [featuremap] no conflictúan con códigos de extensiones

Transferencias no se completan:

Solución 1: Verificar allow_transfer = yes en el endpoint

Solución 2: Aumentar transferdigittimeout si el usuario tarda en marcar

Solución 3: Revisar que el contexto tenga acceso a la extensión destino

Grabación DTMF no inicia:

Solución 1: Confirmar one_touch_recording = yes en endpoint

Solución 2: Verificar permisos de escritura en directorio de grabaciones

Solución 3: Revisar que MixMonitor esté disponible: asterisk -rx "core show application MixMonitor"

DTMF se escucha como audio:

Problema: El modo es inband en lugar de rfc4733

Solución: Cambiar dtmf_mode = rfc4733 y reiniciar el endpoint

Timeout muy corto para marcar:

Solución: Aumentar featuredigittimeout en [general] a 3000 o más

Logs útiles

# Ver logs en tiempo real tail -f /var/log/asterisk/full # Filtrar solo DTMF tail -f /var/log/asterisk/full | grep -i dtmf # Filtrar transferencias tail -f /var/log/asterisk/full | grep -i transfer # Filtrar features tail -f /var/log/asterisk/full | grep -i feature
Simplicidad en códigos: Usa códigos DTMF cortos y memorables. Evita secuencias largas o complejas.

Documentación: Mantén un documento con todos los códigos y compártelo con usuarios.

Testing progresivo: Prueba cada característica individualmente antes de habilitar todas.

Grupos de características: Usa [featuregroups] para asignar características según roles (agentes, supervisores, usuarios).

Monitoreo: Implementa logging adecuado para auditar uso de características.

Capacitación: Asegúrate que usuarios conozcan los códigos y cómo usarlos correctamente.

Respaldo: Siempre respalda configuraciones antes de cambios importantes.

Consistencia: Mantén los mismos códigos DTMF en todos los sistemas de la organización.

SEGURIDAD:

Prevención de abuso: Limita características sensibles (como transferencias externas) mediante contextos restrictivos.

Auditoría: Registra todas las transferencias y grabaciones para compliance.

Permisos: Asigna características según necesidad real, no des acceso universal.

Códigos seguros: Evita códigos DTMF obvios o predecibles para funciones críticas.

Validación: En applicationmap, valida siempre las entradas antes de ejecutar acciones.

Conclusión

El archivo features.conf proporciona funcionalidades esenciales que transforman Asterisk de una simple centralita en un sistema telefónico completo y profesional. Su correcta integración con pjsip.conf requiere atención especial a parámetros como direct_media y dtmf_mode para garantizar que todas las características funcionen según lo esperado.

La clave del éxito está en:

Mantener direct_media = no para que Asterisk pueda interceptar DTMF

Usar dtmf_mode = rfc4733 para máxima confiabilidad

Configurar los flags apropiados en la aplicación Dial()

Documentar y capacitar a usuarios en el uso de códigos DTMF

Monitorear y depurar sistemáticamente

Con la configuración adecuada, los usuarios pueden disfrutar de transferencias fluidas, grabación bajo demanda y características personalizadas, mejorando significativamente la productividad y experiencia telefónica en cualquier implementación de Asterisk PBX.
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

November 26, 2025

Andrea Sannucci RTPEngine: Instalación, Pruebas y Configuración para NAT y WebRTC (con Ejemplos Reales)
RTPEngine es probablemente uno de los componentes más críticos y menos comprendidos en infraestructuras VoIP modernas. Desarrollado originalmente por Sipwise y ahora mantenido activamente en GitHub, este proxy de medios se ha convertido en el estándar de facto para manejar escenarios complejos de NAT, transcoding y conversión de protocolos entre clientes legacy UDP y modernos WebRTC. A pesar de su popularidad y del alto volumen de consultas en foros y listas de correo, la documentación clara y estructurada sigue siendo escasa. Este artículo busca llenar ese vacío proporcionando una guía práctica desde la instalación hasta configuraciones avanzadas con ejemplos reales de producción.

¿Por qué RTPEngine y no RTPProxy o MediaProxy?

Antes de sumergirnos en la implementación, es importante entender por qué RTPEngine se ha convertido en la opción preferida. RTPProxy fue durante años el proxy de medios por excelencia para Kamailio y OpenSIPS, pero tiene limitaciones significativas: no soporta nativamente SRTP, carece de capacidades de transcoding, y su arquitectura no está optimizada para el alto rendimiento que demandan las implementaciones modernas. MediaProxy, por su parte, nunca alcanzó la madurez ni el soporte comunitario necesarios. RTPEngine llena estos huecos ofreciendo soporte completo para SRTP/DTLS, transcoding de codecs, bridging entre IPv4/IPv6, manejo inteligente de ICE para WebRTC, y una arquitectura de alto rendimiento basada en kernel forwarding cuando está disponible. Para escenarios donde necesitas que un cliente WebRTC con SRTP se comunique con un servidor Asterisk legacy que solo habla RTP sobre UDP, RTPEngine es prácticamente la única solución viable sin modificar código de aplicación.

Arquitectura y Componentes

RTPEngine consiste en dos componentes principales que trabajan juntos. El daemon rtpengine es el proceso principal que maneja toda la lógica de control: recibe comandos vía protocolo ng (un protocolo binario propietario sobre UDP o UNIX socket), procesa señalización SDP, mantiene tablas de sesiones activas, y coordina el flujo de medios. El módulo de kernel xt_RTPENGINE es opcional pero altamente recomendado para producción, ya que permite forwarding de paquetes RTP directamente en kernel space, reduciendo drásticamente la latencia y el uso de CPU. Cuando el módulo de kernel está disponible, rtpengine solo procesa los primeros paquetes de cada flujo para establecer las reglas de forwarding, y el kernel se encarga del resto. Sin el módulo de kernel, todo el procesamiento ocurre en userspace, que aunque funcional, consume significativamente más recursos en escenarios de alto tráfico.

Instalación en AlmaLinux 9

AlmaLinux 9 se ha convertido en una excelente opción para infraestructura VoIP después de la transición de CentOS. La instalación de RTPEngine en esta distribución requiere algunos pasos específicos debido a dependencias y la necesidad de compilar el módulo de kernel. Primero necesitamos habilitar los repositorios necesarios y asegurarnos de que tenemos las herramientas de compilación. El repositorio EPEL es esencial ya que contiene varias dependencias que no están en los repos base de AlmaLinux.

dnf -y updatesed -i 's/^SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config
reboot
dnf install -y epel-release dnf config-manager --set-enabled crb dnf groupinstall -y "Development Tools" dnf install --nogpgcheck https://mirrors.rpmfusion.org/free/el/rpmfusion-free-release-9.noarch.rpm -y dnf install -y kernel-devel kernel-headers gcc make pkgconfig glib2-devel zlib-devel openssl-devel dnf install -y pcre-devel libcurl-devel xmlrpc-c-devel libevent-devel json-glib-devel hiredis-devel dnf install -y iptables-devel libpcap-devel mariadb-devel spandsp-devel bcg729-devel ffmpeg-devel dnf install -y iptables-legacy-devel libmnl-devel libnftnl-devel pandoc libwebsockets-devel dnf install -y ncurses-devel opus-devel libjwt-devel mysql-devel libatomic
Una vez que tenemos las dependencias, procedemos a clonar el repositorio oficial y compilar. Es crucial compilar tanto el daemon como el módulo de kernel para obtener el máximo rendimiento.

cd /usr/src git clone https://github.com/sipwise/rtpengine.git cd rtpengine/daemon make make install cd ../kernel-module make make install
Después de la compilación, necesitamos cargar el módulo de kernel y asegurarnos de que se cargue automáticamente en cada reinicio.

modprobe xt_RTPENGINE echo "xt_RTPENGINE" > /etc/modules-load.d/rtpengine.conf lsmod | grep RTPENGINE
Si el último comando muestra el módulo cargado, estás listo para continuar. Ahora creamos el usuario y los directorios necesarios para el servicio.

useradd -r -s /bin/false rtpengine mkdir -p /var/run/rtpengine /var/log/rtpengine chown rtpengine:rtpengine /var/run/rtpengine /var/log/rtpengine
Configuración Básica para NAT Traversal

El archivo de configuración principal de RTPEngine se ubica típicamente en /etc/rtpengine/rtpengine.conf. Para un escenario básico de NAT traversal, donde tu servidor tiene una IP privada pero necesita comunicarse con clientes externos, la configuración debe especificar correctamente las interfaces con sus direcciones públicas y privadas. Aquí está un ejemplo funcional comentado:

[rtpengine] interface = 10.0.1.50!203.0.113.45 listen-ng = 127.0.0.1:2223 port-min = 20000 port-max = 30000 timeout = 60 silent-timeout = 3600 delete-delay = 30 log-level = 6 log-facility = local1 log-facility-cdr = local1 log-facility-rtcp = local1
La línea más crítica aquí es interface = 10.0.1.50!203.0.113.45, donde 10.0.1.50 es la dirección IP privada de tu servidor y 203.0.113.45 es tu IP pública. El formato IP_PRIVADA!IP_PUBLICA le indica a RTPEngine que cuando reciba comandos para sesiones, debe anunciar la IP pública en el SDP pero vincular los sockets a la IP privada. El parámetro listen-ng define dónde RTPEngine escucha comandos de control desde Kamailio u otro proxy SIP. El rango de puertos 20000-30000 define qué puertos UDP usará para los flujos RTP, asegúrate de que tu firewall permita este rango. Los parámetros de timeout controlan cuándo RTPEngine considera una sesión muerta: timeout se aplica cuando hay actividad unidireccional, silent-timeout cuando no hay actividad en absoluto, y delete-delay es el tiempo que espera antes de eliminar completamente una sesión después de recibir un comando delete.

Configuración del Servicio Systemd

Para que RTPEngine se ejecute como un servicio gestionado por systemd, necesitamos crear un archivo de unidad. Crea /etc/systemd/system/rtpengine.service con el siguiente contenido:

[Unit] Description=RTPEngine Media Proxy After=network.target [Service] Type=forking PIDFile=/var/run/rtpengine/rtpengine.pid ExecStart=/usr/bin/rtpengine --config-file=/etc/rtpengine/rtpengine.conf --pidfile=/var/run/rtpengine/rtpengine.pid ExecStop=/bin/kill -TERM $MAINPID Restart=always RestartSec=5 User=rtpengine Group=rtpengine [Install] WantedBy=multi-user.target
Ahora habilitamos e iniciamos el servicio:

systemctl daemon-reload systemctl enable rtpengine systemctl start rtpengine systemctl status rtpengine
Verifica los logs para asegurarte de que inició correctamente:

tail -f /var/log/messages | grep rtpengine
Deberías ver mensajes indicando que RTPEngine inició, cargó el módulo de kernel si está disponible, y está escuchando en la interfaz de control configurada.

Integración con Kamailio: Configuración Básica

La integración de RTPEngine con Kamailio requiere el módulo rtpengine. En tu kamailio.cfg, primero carga el módulo y configura los parámetros de conexión:

loadmodule "rtpengine.so" modparam("rtpengine", "rtpengine_sock", "udp:127.0.0.1:2223") modparam("rtpengine", "rtpengine_disable_tout", 20) modparam("rtpengine", "rtpengine_tout_ms", 1000) modparam("rtpengine", "rtpengine_retr", 5)
En tu lógica de enrutamiento de INVITE, necesitas llamar a rtpengine_offer para el INVITE inicial y rtpengine_answer para las respuestas. Aquí está un ejemplo básico de manejo de NAT:

route[NATMANAGE] { if (is_method("INVITE")) { if (has_body("application/sdp")) { if (rtpengine_offer("replace-origin replace-session-connection ICE=remove")) { t_on_reply("NATMANAGE_REPLY"); } } } if (is_method("ACK") && has_body("application/sdp")) { rtpengine_answer("replace-origin replace-session-connection"); } if (is_method("BYE|CANCEL")) { rtpengine_delete(); } } onreply_route[NATMANAGE_REPLY] { if (has_body("application/sdp")) { rtpengine_answer("replace-origin replace-session-connection ICE=remove"); } }
Las flags "replace-origin" y "replace-session-connection" le indican a RTPEngine que reemplace las direcciones IP en los campos o= y c= del SDP con la dirección que RTPEngine está usando. La flag "ICE=remove" elimina los atributos ICE del SDP, útil cuando estás haciendo bridge entre un cliente WebRTC que usa ICE y uno legacy que no lo entiende.

Configuración Avanzada para WebRTC

El escenario más complejo y común que encontrarás es permitir que clientes WebRTC se comuniquen con infraestructura SIP tradicional. Los navegadores web que usan WebRTC requieren SRTP obligatorio y típicamente DTLS para el intercambio de claves, mientras que la mayoría de servidores Asterisk y teléfonos IP tradicionales solo hablan RTP sin cifrar sobre UDP. RTPEngine es perfectamente capaz de hacer este bridge, pero requiere configuración específica tanto en RTPEngine como en Kamailio.

Primero, tu configuración de RTPEngine necesita certificados TLS válidos para DTLS. Genera o copia tus certificados:

mkdir -p /etc/rtpengine/certs openssl req -x509 -nodes -days 3650 -newkey rsa:2048 \ -keyout /etc/rtpengine/certs/rtpengine-key.pem \ -out /etc/rtpengine/certs/rtpengine-cert.pem \ -subj "/C=US/ST=State/L=City/O=Organization/CN=rtpengine.domain.com" chown -R rtpengine:rtpengine /etc/rtpengine/certs chmod 600 /etc/rtpengine/certs/rtpengine-key.pem
Actualiza tu rtpengine.conf para incluir la ruta a los certificados:

[rtpengine] interface = 10.0.1.50!203.0.113.45 listen-ng = 127.0.0.1:2223 port-min = 20000 port-max = 30000 timeout = 60 silent-timeout = 3600 log-level = 6 log-facility = local1 certificate = /etc/rtpengine/certs/rtpengine-cert.pem key = /etc/rtpengine/certs/rtpengine-key.pem
El parámetro dtls-passive es crucial: le indica a RTPEngine que actúe como servidor DTLS, esperando que el cliente (navegador WebRTC) inicie el handshake DTLS. En Kamailio, tu lógica de enrutamiento para manejar llamadas WebRTC necesita detectar el tipo de cliente y aplicar las flags apropiadas. Aquí está un ejemplo más completo:

route[NATMANAGE] { if (is_method("INVITE")) { if (has_body("application/sdp")) { $var(rtpengine_flags) = "replace-origin replace-session-connection"; # Detectar si el origen es WebRTC if (search("mozilla|chrome|safari") || search_body("a=rtcp-mux") || search_body("a=fingerprint")) { $var(is_ws_origin) = 1; $var(rtpengine_flags) = $var(rtpengine_flags) + " DTLS=passive SDES-off ICE=remove RTP/AVP"; } # Detectar si el destino es WebRTC if ($rU =~ "^webrtc_") { $var(is_ws_dest) = 1; if ($var(is_ws_origin) == 1) { # WebRTC to WebRTC $var(rtpengine_flags) = "replace-origin replace-session-connection DTLS=passive ICE=force"; } else { # SIP to WebRTC $var(rtpengine_flags) = "replace-origin replace-session-connection DTLS=passive ICE=force RTP/SAVPF"; } } if (rtpengine_offer("$var(rtpengine_flags)")) { t_on_reply("NATMANAGE_REPLY"); } } } if (is_method("ACK") && has_body("application/sdp")) { rtpengine_answer("replace-origin replace-session-connection"); } if (is_method("BYE|CANCEL")) { rtpengine_delete(); } } onreply_route[NATMANAGE_REPLY] { if (has_body("application/sdp")) { $var(rtpengine_flags) = "replace-origin replace-session-connection"; if ($var(is_ws_origin) == 1 && $var(is_ws_dest) == 0) { # WebRTC origin to SIP destination - need to convert back to RTP/AVP $var(rtpengine_flags) = $var(rtpengine_flags) + " RTP/AVP DTLS-off ICE=remove"; } else if ($var(is_ws_origin) == 0 && $var(is_ws_dest) == 1) { # SIP origin to WebRTC destination - need SRTP $var(rtpengine_flags) = $var(rtpengine_flags) + " RTP/SAVPF DTLS=passive ICE=force"; } rtpengine_answer("$var(rtpengine_flags)"); } }
Las flags clave para WebRTC son: DTLS=passive indica que RTPEngine debe actuar como servidor DTLS; ICE=force agrega atributos ICE al SDP incluso si no estaban presentes originalmente; RTP/SAVPF especifica el perfil de transporte seguro que WebRTC requiere; RTP/AVP es el perfil estándar no seguro para SIP legacy; SDES-off desactiva SDES key exchange cuando usas DTLS. La combinación correcta de estas flags permite que RTPEngine haga la conversión transparente entre los dos mundos.

Escenario Real: Asterisk con Voicemail y Clientes WebRTC

Un caso de uso extremadamente común pero problemático es cuando tienes clientes WebRTC que necesitan dejar o escuchar mensajes de voz en un servidor Asterisk que solo habla RTP/UDP sin cifrado. Este escenario requiere que RTPEngine haga conversión SRTP-to-RTP en el camino hacia Asterisk y RTP-to-SRTP en el camino de vuelta. La configuración que mostré anteriormente maneja esto, pero hay sutilezas importantes. Cuando un cliente WebRTC llama a una extensión de voicemail, el flujo es: Cliente WebRTC -> Kamailio -> RTPEngine -> Asterisk. En el INVITE del cliente, Kamailio detecta que es WebRTC (por la presencia de atributos ICE o DTLS en el SDP) y llama a rtpengine_offer con flags que le dicen a RTPEngine que acepte SRTP/DTLS del cliente pero ofrezca RTP simple a Asterisk. Cuando Asterisk responde con su SDP que especifica RTP/AVP, Kamailio llama a rtpengine_answer con flags que convierten esa respuesta a RTP/SAVPF con DTLS para el cliente WebRTC. El audio fluye entonces: Cliente (SRTP) -> RTPEngine (descifra) -> Asterisk (RTP) -> RTPEngine (cifra) -> Cliente (SRTP). Un problema común aquí es olvidar que Asterisk necesita tener las direcciones IP correctas en su configuración. En sip.conf o pjsip.conf, necesitas configurar externip y localnet correctamente si Asterisk está detrás de NAT:

[general] externip = 203.0.113.45 localnet = 10.0.0.0/255.255.0.0 nat = yes
Sin esta configuración, Asterisk puede generar SDP con direcciones IP privadas que RTPEngine no puede manejar correctamente. Otra trampa común es el codec negotiation: los navegadores modernos prefieren Opus, pero muchas configuraciones de Asterisk no lo tienen habilitado. Asegúrate de que tus extensiones de Asterisk permitan codecs compatibles con WebRTC:

[webrtc_client] type=friend context=default disallow=all allow=opus allow=ulaw allow=alaw dtlsenable=no ; RTPEngine maneja DTLS, no Asterisk encryption=no ; RTPEngine maneja SRTP, no Asterisk
Pruebas y Verificación

Una vez que tienes todo configurado, necesitas validar que funciona. La herramienta rtpengine-ctl te permite consultar el estado de RTPEngine y ver sesiones activas. Para ver todas las sesiones actuales:

rtpengine-ctl list
Para ver estadísticas detalladas de una sesión específica:

rtpengine-ctl query <call-id>
Durante una llamada activa, puedes usar tcpdump para verificar el flujo de medios. Para ver paquetes RTP en la interfaz donde RTPEngine está escuchando:

tcpdump -i eth0 -n udp portrange 20000-30000 -v
Si todo está funcionando correctamente, deberías ver tráfico UDP bidireccional en puertos dentro del rango configurado. Para verificar que el módulo de kernel está siendo usado:

cat /proc/rtpengine/0/list
Este archivo muestra todas las reglas de forwarding activas en el módulo de kernel. Si está vacío pero tienes llamadas activas, el módulo de kernel no se está usando y todo el procesamiento está en userspace. Para pruebas WebRTC, puedes usar el demo de JsSIP o Sipml5. Configura un cliente WebRTC para registrarse contra tu Kamailio, y luego intenta llamar a una extensión Asterisk tradicional. Usa las herramientas de desarrollo del navegador (F12) para ver la consola JavaScript y cualquier error WebRTC. Los errores comunes incluyen: fingerprint mismatch si hay problemas con los certificados DTLS; failed to set remote description si el SDP está malformado; ICE failed si hay problemas de conectividad de red. Monitorea los logs de Kamailio durante la llamada:

tail -f /var/log/kamailio.log | grep rtpengine
Deberías ver los comandos offer, answer, y delete siendo enviados a RTPEngine con sus respectivas flags. Si ves errores como timeout talking to RTPEngine, verifica que RTPEngine está corriendo y que listen-ng en rtpengine.conf coincide con rtpengine_sock en kamailio.cfg.

Troubleshooting Común

El audio de un solo sentido es probablemente el problema más reportado con RTPEngine. Las causas comunes incluyen: configuración incorrecta de interface con la IP pública/privada; firewall bloqueando el rango de puertos RTP; direcciones IP en SDP que no coinciden con la realidad de red; problemas de routing asimétrico donde los paquetes de ida y vuelta toman caminos diferentes. Para diagnosticar, captura el SDP en diferentes puntos del flujo y compara las direcciones IP y puertos. Sin audio en absoluto usualmente indica que RTPEngine no está recibiendo los comandos de control, o que el módulo de kernel no está cargado y hay un problema de performance. Verifica que rtpengine-ctl list muestra las sesiones activas. Problemas de calidad de audio como choppy audio o paquetes perdidos pueden deberse a: latencia de red excesiva; CPU overload en el servidor RTPEngine; problemas de codec negotiation donde hay transcoding innecesario; tamaño de paquete incorrecto (ptime). Usa rtpengine-ctl stats para ver estadísticas de paquetes perdidos y latencia. Para problemas específicos de WebRTC, los síntomas incluyen: ICE connection failed que generalmente significa problemas de firewall o routing; DTLS handshake failed que indica problemas de certificados o incompatibilidad de versiones; fingerprint verification failed que significa que el SDP fue modificado en tránsito o hay un MITM. Habilita log-level = 7 en rtpengine.conf para debugging detallado, pero recuerda bajarlo a 5 o 6 en producción para evitar I/O excesivo.

Escalamiento y Alta Disponibilidad

Para entornos de producción con alto volumen de llamadas, una sola instancia de RTPEngine eventualmente se convertirá en un cuello de botella. RTPEngine soporta múltiples estrategias de escalamiento. La más simple es el escalamiento vertical: aumentar CPU, RAM y ancho de banda de red en el servidor. RTPEngine con el módulo de kernel puede manejar miles de llamadas concurrentes en hardware moderno, pero hay límites. El escalamiento horizontal implica correr múltiples instancias de RTPEngine y distribuir la carga entre ellas. Kamailio soporta esto mediante el módulo rtpengine con múltiples sockets:

modparam("rtpengine", "rtpengine_sock", "udp:10.0.1.50:2223 udp:10.0.1.51:2223") modparam("rtpengine", "rtpengine_allow_op", 1)
Con esta configuración, Kamailio distribuye llamadas entre los dos servidores RTPEngine automáticamente. Para alta disponibilidad real, necesitas considerar qué pasa cuando un servidor RTPEngine falla. Las sesiones activas en ese servidor se perderán, pero nuevas llamadas irán al servidor sobreviviente. Una arquitectura más sofisticada implica usar un balanceador de carga en frente de múltiples instancias RTPEngine, pero esto requiere que el balanceador mantenga session affinity para que todos los mensajes de control de una sesión específica vayan al mismo servidor RTPEngine. Otra consideración importante en producción es el monitoreo. Implementa checks de health que consulten rtpengine-ctl stats periódicamente y alerten si: el número de sesiones activas es anormalmente alto o bajo; hay un incremento en paquetes perdidos; el CPU load del servidor es excesivo; el módulo de kernel no está cargado. Herramientas como Nagios, Zabbix, o Prometheus pueden integrarse fácilmente mediante scripts que parsean la salida de rtpengine-ctl.

Conclusión

RTPEngine es una herramienta indispensable en infraestructuras VoIP modernas, especialmente cuando necesitas bridging entre protocolos legacy y WebRTC. Aunque la curva de aprendizaje inicial puede ser empinada debido a la documentación fragmentada, una vez que entiendes los conceptos fundamentales de interfaces públicas/privadas, flags de control, y conversión de protocolos, se convierte en una solución extremadamente poderosa y confiable. Los ejemplos de este artículo están basados en configuraciones de producción reales que manejan miles de llamadas diarias, y deberían darte una base sólida para implementar tu propia infraestructura. Recuerda siempre probar exhaustivamente en un ambiente de staging antes de desplegar a producción, especialmente cuando estás haciendo conversiones SRTP/RTP que son críticas para la privacidad de las comunicaciones.
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo
Andrea Sannucci WebRTC para empresas: lo que realmente necesitas saber
La comunicación en tiempo real se ha convertido en un pilar fundamental para las empresas modernas. WebRTC (Web Real-Time Communication) ha emergido como una tecnología transformadora que permite la comunicación de voz, video y datos directamente a través del navegador web, sin necesidad de plugins o aplicaciones adicionales. Sin embargo, implementar WebRTC en un entorno empresarial va mucho más allá de simplemente habilitar videollamadas.

¿Qué es WebRTC y por qué debería importarte?

WebRTC es un estándar abierto que permite la comunicación peer-to-peer directamente desde el navegador. Esto significa que tus empleados, clientes o socios pueden iniciar una videollamada, compartir pantalla o intercambiar datos sin necesidad de instalar software especializado. La tecnología está soportada nativamente por los principales navegadores: Chrome, Firefox, Safari y Edge.

Para las empresas, esto representa una oportunidad única de integrar capacidades de comunicación directamente en sus aplicaciones web, portales de clientes, sistemas CRM o plataformas de colaboración interna, reduciendo la dependencia de soluciones de terceros y mejorando la experiencia del usuario.

Ventajas de implementar WebRTC en tu empresa

1. Reducción de costos operativos

WebRTC elimina la necesidad de licencias costosas de software de videoconferencia tradicional. Al estar basado en estándares abiertos, puedes implementar soluciones propias o utilizar servicios basados en WebRTC sin los costos recurrentes asociados a plataformas propietarias. Además, la comunicación peer-to-peer reduce significativamente el uso de ancho de banda en tu infraestructura al no requerir que todo el tráfico pase por servidores centrales.

2. Integración nativa en aplicaciones web

Una de las mayores ventajas es la capacidad de integrar comunicaciones en tiempo real directamente en tus aplicaciones existentes. Imagina un sistema de soporte al cliente donde el agente puede iniciar una videollamada con un solo clic sin que el cliente tenga que descargar nada, o un CRM donde puedes llamar a un prospecto directamente desde el registro del contacto. Esta integración perfecta mejora dramáticamente la productividad y la experiencia del usuario.

3. Calidad de comunicación superior

WebRTC implementa códecs de audio y video de última generación como Opus para audio y VP8/VP9/H.264 para video. El protocolo incluye mecanismos avanzados de adaptación a las condiciones de red, ajustando automáticamente la calidad según el ancho de banda disponible. Esto resulta en comunicaciones claras y estables incluso en condiciones de red variables.

4. Seguridad por diseño

La seguridad está integrada en el núcleo de WebRTC. Todas las comunicaciones están cifradas de forma obligatoria mediante DTLS (Datagram Transport Layer Security) y SRTP (Secure Real-time Transport Protocol). No existe opción de comunicación sin cifrar, lo que garantiza que las conversaciones empresariales permanezcan confidenciales.

5. Flexibilidad y escalabilidad

WebRTC te permite escalar desde una simple llamada de uno a uno hasta conferencias multiparte, transmisiones en vivo o incluso implementaciones de Internet de las Cosas (IoT). Puedes empezar con una implementación básica y expandir según las necesidades de tu negocio crecen.

6. Experiencia de usuario mejorada

La eliminación de descargas, instalaciones y configuraciones complejas reduce drásticamente la fricción para los usuarios finales. Un cliente puede unirse a una reunión con un simple clic en un enlace, lo que aumenta las tasas de participación y reduce las llamadas al soporte técnico.

Desafíos de implementar WebRTC en entornos empresariales

1. Complejidad de NAT y firewalls

Uno de los mayores desafíos técnicos de WebRTC es atravesar los NATs (Network Address Translation) y firewalls corporativos. Aunque WebRTC incluye ICE (Interactive Connectivity Establishment) para resolver esto, necesitarás servidores STUN (Session Traversal Utilities for NAT) y TURN (Traversal Using Relays around NAT). Los servidores TURN pueden consumir considerable ancho de banda, especialmente cuando las conexiones directas no son posibles, lo que ocurre aproximadamente en el 15-20% de los casos en entornos corporativos restrictivos.

2. Señalización personalizada

WebRTC define cómo transmitir medios, pero no especifica cómo establecer la conexión inicial. Debes implementar tu propio mecanismo de señalización, típicamente usando WebSockets, para intercambiar información SDP (Session Description Protocol) y candidatos ICE entre participantes. Esto requiere desarrollo backend adicional y una arquitectura bien diseñada.

3. Compatibilidad entre navegadores

Aunque los principales navegadores soportan WebRTC, existen diferencias sutiles en la implementación. Safari tuvo soporte limitado hasta versiones recientes, y algunos navegadores móviles pueden tener restricciones. Necesitarás implementar detección de capacidades y posibles adaptadores para garantizar una experiencia consistente.

4. Gestión de la calidad del servicio (QoS)

En redes empresariales congestionadas, garantizar calidad de servicio para las comunicaciones en tiempo real puede ser complejo. Necesitarás configurar adecuadamente tu red para priorizar el tráfico WebRTC, implementar políticas QoS y monitorear constantemente la calidad de las llamadas mediante métricas como pérdida de paquetes, jitter y latencia.

5. Escalabilidad de conferencias multiparte

Las arquitecturas peer-to-peer funcionan bien para llamadas uno a uno, pero para conferencias con múltiples participantes necesitarás un SFU (Selective Forwarding Unit) o MCU (Multipoint Control Unit). Esto añade complejidad arquitectónica y requiere infraestructura adicional de servidores capaces de manejar múltiples streams de video simultáneamente.

6. Monitoreo y diagnóstico

Diagnosticar problemas de calidad en llamadas WebRTC puede ser desafiante. Necesitarás implementar herramientas de monitoreo que recopilen estadísticas de las llamadas, analicen métricas de red y proporcionen visibilidad sobre problemas de conectividad o calidad en tiempo real.

7. Compatibilidad con sistemas legados

Si tu empresa utiliza sistemas PBX tradicionales o infraestructura de telefonía existente, necesitarás gateways que conviertan entre WebRTC y protocolos como SIP para permitir la interoperabilidad. Esto añade otra capa de complejidad a tu arquitectura.

Implementaciones prácticas de WebRTC en empresas

1. Centro de contacto y atención al cliente

Implementa un centro de contacto moderno donde los agentes pueden atender llamadas de voz y video directamente desde el navegador. Los clientes pueden iniciar videollamadas desde tu sitio web sin descargas, permitiendo a los agentes compartir pantalla para guiar a los usuarios a través de procesos complejos. Puedes integrar funcionalidades como grabación de llamadas, transcripción automática mediante IA, y enrutamiento inteligente basado en habilidades del agente.

Componentes técnicos necesarios:

Servidor de señalización (WebSocket)

Servidores TURN/STUN

SFU para supervisión y grabación

Backend para gestión de colas y enrutamiento

Integración con CRM

2. Telemedicina y consultas remotas

Crea una plataforma de telemedicina donde pacientes y médicos pueden conectarse de forma segura. Implementa salas de espera virtuales, videoconsultas privadas y la capacidad de compartir imágenes médicas o documentos durante la consulta. La seguridad y el cumplimiento con normativas como HIPAA o GDPR son críticas en esta implementación.

Características clave:

Cifrado end-to-end reforzado

Autenticación robusta de usuarios

Grabación segura con consentimiento

Integración con historiales médicos electrónicos

Prescripción digital

3. Educación y formación corporativa

Desarrolla una plataforma de e-learning interactiva donde instructores pueden impartir clases en vivo con capacidades de compartir pantalla, pizarra colaborativa y salas de grupo para trabajos en equipo. Los estudiantes pueden levantar la mano virtualmente, participar en encuestas en tiempo real y colaborar en documentos compartidos durante la sesión.

Funcionalidades destacadas:

Grabación automática de sesiones

Chat integrado con moderación

Compartir pantalla con anotaciones

Salas breakout para trabajo en grupos

Analytics de participación

4. Colaboración interna y reuniones virtuales

Sustituye o complementa tus soluciones de videoconferencia actuales con una plataforma propia integrada en tu intranet corporativa. Permite que los equipos programen y se unan a reuniones sin salir de tus herramientas internas, con integración completa al calendario corporativo, directorio de empleados y herramientas de gestión de proyectos.

Ventajas de la integración interna:

Single Sign-On (SSO) con tu directorio activo

Presencia integrada en todas las aplicaciones

Compartir contenido directamente desde sistemas internos

Políticas de grabación y retención personalizadas

Control total sobre los datos

5. Inspecciones y auditorías remotas

Para empresas de manufactura, construcción o auditoría, implementa soluciones de inspección remota donde los inspectores pueden guiar a personal en campo mediante videollamada. Utiliza la cámara del dispositivo móvil para mostrar equipos o instalaciones en tiempo real, con capacidad de capturar imágenes, anotar sobre el video en vivo y generar reportes inmediatos.

Capacidades especializadas:

Streaming desde dispositivos móviles

Anotaciones en tiempo real sobre video

Captura de fotos durante la llamada

Geolocalización de inspecciones

Integración con sistemas de gestión de mantenimiento

6. Banca y servicios financieros

Implementa asesoría financiera remota donde los clientes pueden tener videoconsultas con asesores bancarios para apertura de cuentas, solicitud de créditos o planificación financiera. Integra firma digital y verificación de identidad durante la videollamada para completar procesos que tradicionalmente requerían presencia física.

Elementos de seguridad reforzada:

Verificación biométrica integrada

Compartir documentos con firma digital

Grabación con valor legal

Autenticación de múltiples factores

Cifrado según estándares financieros

7. Internet de las Cosas (IoT) y monitoreo remoto

Utiliza WebRTC para transmitir video desde cámaras de seguridad, drones o equipos industriales directamente al navegador con latencia ultra baja. Permite que los operadores monitoreen instalaciones remotas, respondan a alertas en tiempo real y tomen decisiones inmediatas basadas en video en vivo.

Aplicaciones innovadoras:

Monitoreo de sitios remotos

Control de drones mediante navegador

Inspección de infraestructura crítica

Vigilancia distribuida con IA

Gemelos digitales con video en tiempo real

8. Entrevistas y reclutamiento

Moderniza tu proceso de reclutamiento con una plataforma de entrevistas virtuales integrada en tu sistema de gestión de candidatos. Permite a los reclutadores realizar entrevistas por video, compartir presentaciones sobre la empresa, y evaluar a candidatos de forma colaborativa con otros miembros del equipo uniéndose a la entrevista.

Mejoras al proceso de RRHH:

Programación automática integrada con calendarios

Grabación de entrevistas con consentimiento

Evaluación colaborativa en tiempo real

Reducción de tiempos de contratación

Experiencia mejorada para candidatos remotos

Arquitectura técnica recomendada

Para una implementación empresarial robusta de WebRTC, considera la siguiente arquitectura:

Capa de aplicación:

Frontend web con JavaScript y APIs de WebRTC

Aplicaciones móviles nativas con SDKs de WebRTC

Capa de señalización:

Servidor WebSocket para intercambio SDP

Redis para gestión de sesiones y presencia

Load balancers para alta disponibilidad

Capa de medios:

Servidores STUN para descubrimiento de direcciones

Servidores TURN para relay cuando sea necesario

SFU (como Janus, Mediasoup o Jitsi) para conferencias multiparte

Grabación y procesamiento de medios

Capa de infraestructura:

Kubernetes para orquestación de contenedores

CDN para distribución de contenido estático

Monitoreo con Prometheus y Grafana

Logging centralizado

Integraciones:

Gateway SIP para interoperabilidad con telefonía

APIs RESTful para sistemas empresariales

Webhooks para eventos y notificaciones

Consideraciones finales para tu implementación

Antes de embarcarte en una implementación de WebRTC, evalúa cuidadosamente tus necesidades específicas. ¿Necesitas una solución simple de videollamadas o una plataforma compleja de comunicaciones unificadas? ¿Tienes el equipo técnico necesario o deberías considerar soluciones de terceros basadas en WebRTC como Twilio, Vonage o Agora?

Realiza pruebas de concepto en tu infraestructura de red real, considerando tus políticas de firewall, ancho de banda disponible y la distribución geográfica de tus usuarios. Planifica para escalabilidad desde el principio, incluso si comienzas con una implementación pequeña.

La seguridad debe ser una prioridad desde el diseño inicial, no una idea tardía. Implementa autenticación robusta, autorización granular y auditoría completa de todas las comunicaciones.

Finalmente, considera el soporte a largo plazo. WebRTC es una tecnología en constante evolución, con nuevos códecs, mejoras de rendimiento y características que se añaden regularmente. Necesitarás un plan para mantener tu implementación actualizada y aprovechar las mejoras continuas.

WebRTC representa una oportunidad transformadora para las empresas que buscan modernizar sus comunicaciones, mejorar la colaboración y ofrecer experiencias superiores a clientes y empleados. Con la planificación adecuada, un entendimiento claro de los desafíos y una arquitectura bien diseñada, puedes aprovechar esta poderosa tecnología para impulsar la innovación en tu organización.
- WebRTC
- Empresas
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo
Andrea Sannucci El Primer Ciberataque a Gran Escala Orquestado por Inteligencia Artificial
En septiembre de 2025, la empresa Anthropic detectó lo que considera el primer caso documentado de un ciberataque a gran escala ejecutado sin intervención humana sustancial. Este incidente marca un punto de inflexión en la ciberseguridad mundial.

¿Qué sucedió?

Un grupo patrocinado por el estado chino manipuló la herramienta Claude Code para intentar infiltrarse en aproximadamente treinta objetivos globales, incluyendo grandes empresas tecnológicas, instituciones financieras, compañías químicas y agencias gubernamentales.

Lo revolucionario de este ataque fue que la IA ejecutó entre el 80% y 90% de las tareas de manera autónoma, requiriendo intervención humana solo en puntos críticos de decisión estratégica.

La mecánica del ataque

Los atacantes engañaron a Claude haciéndole creer que era un empleado legítimo de una firma de ciberseguridad realizando pruebas defensivas. El jefe de Inteligencia de Amenazas de Anthropic, Jacob Klein, explicó que los hackers condujeron sus ataques "literalmente con el clic de un botón, y luego con mínima interacción humana".

La IA realizó autónomamente:

Reconocimiento y mapeo de redes: Escaneo de sistemas y enumeración de servicios

Identificación de vulnerabilidades: Descubrimiento y validación de puntos débiles

Generación de código de explotación: Creación y prueba de exploits

Robo de credenciales: Identificación de cuentas de alto privilegio

Extracción de datos: Exfiltración de información sensible

Los operadores humanos solo intervenían en momentos clave, diciendo cosas como "Sí, continúa", "No continúes", "Gracias por esta información" o "Oh, eso no parece correcto, Claude, ¿estás seguro?". El resto del tiempo, la IA operaba de forma completamente autónoma.

Limitaciones y respuesta

A pesar de su sofisticación, Claude mostró imperfecciones. Klein señaló que la IA a veces exageraba sus capacidades y afirmaba haber obtenido acceso a sistemas cuando realmente no lo había logrado, lo que requería verificación humana. También fabricaba credenciales o presentaba información públicamente disponible como si fueran descubrimientos críticos.

Respuesta de Anthropic

Anthropic actuó rápidamente:

Durante diez días mapeó la extensión completa de la operación

Bloqueó cuentas identificadas conforme las detectaba

Notificó a las entidades afectadas

Coordinó con las autoridades

Fortaleció sus sistemas de detección

Implicaciones futuras

Este evento tiene consecuencias alarmantes para la ciberseguridad. Los sistemas agentes de IA pueden ahora hacer el trabajo de equipos enteros de hackers experimentados: analizar sistemas objetivo, producir código de explotación y escanear vastos conjuntos de datos de información robada de manera más eficiente que cualquier operador humano.

El cambio de paradigma

Las barreras para ejecutar ciberataques sofisticados han caído drásticamente. Grupos menos experimentados y con menos recursos podrían potencialmente realizar ataques a gran escala que antes estaban limitados a capacidades de estados-nación.

Este ataque representa una escalada significativa respecto a operaciones anteriores de "vibe hacking", donde la supervisión humana seguía siendo integral. Ahora, la participación humana es mucho menos frecuente a pesar de la mayor escala del ataque.

Velocidad sin precedentes

La IA realizaba miles de solicitudes por segundo, una velocidad de ataque que habría sido simplemente imposible de igualar para hackers humanos. Esta capacidad de operar a escala y velocidad masivas mientras mantiene la sofisticación técnica es lo que hace a estos ataques particularmente peligrosos.

Conclusión

La comunidad de ciberseguridad debe asumir que ha ocurrido un cambio fundamental. Los equipos de seguridad necesitan experimentar con la aplicación de IA para la defensa en áreas como automatización de SOC, detección de amenazas, evaluación de vulnerabilidades y respuesta a incidentes.

Se requiere inversión continua en salvaguardas a través de plataformas de IA para prevenir el uso adversarial. Las técnicas descritas en este incidente se proliferarán a través del panorama de amenazas, lo que hace que el intercambio de información sobre amenazas en la industria, métodos de detección mejorados y controles de seguridad más fuertes sean aún más críticos.

Fuente: https://www.wsj.com/opinion/the-first-large-scale-cyberattack-by-ai-4a1e1a30
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo
Andrea Sannucci 5 Razones Válidas para Elegir VitalPBX como Tu Solución de Comunicaciones
En el competitivo mundo de las soluciones de telefonía IP, VitalPBX se ha posicionado como una alternativa robusta y versátil para empresas de todos los tamaños. Si estás evaluando opciones para tu infraestructura de comunicaciones, aquí te presento cinco motivos sólidos por los que VitalPBX merece tu atención.

1. Interfaz Intuitiva y Moderna

A diferencia de otras soluciones PBX que pueden resultar intimidantes para usuarios no técnicos, VitalPBX ofrece una interfaz web intuitiva y moderna. Su diseño limpio facilita la configuración de extensiones, rutas de llamadas, IVRs y otras funcionalidades sin necesidad de editar archivos de configuración manualmente. Esto reduce significativamente la curva de aprendizaje y permite que administradores con diferentes niveles de experiencia puedan gestionar el sistema eficientemente.

2. Arquitectura Basada en Debian y Asterisk

VitalPBX está construido sobre una base sólida: Debian Linux y Asterisk, el motor de telefonía de código abierto más utilizado en el mundo. Esta combinación te brinda:

Estabilidad probada en entornos de producción

Compatibilidad amplia con hardware y proveedores SIP

Acceso total al sistema para configuraciones avanzadas cuando las necesites

Comunidad activa de desarrolladores y usuarios

Para quienes trabajamos con infraestructura VoIP a nivel técnico, tener acceso directo a la configuración de Asterisk y poder integrar herramientas como Kamailio o RTPEngine es invaluable.

3. Modelo de Licenciamiento Flexible

VitalPBX ofrece un modelo económico accesible con opciones para diferentes necesidades:

Versión Community gratuita con funcionalidades core completas

Licencias comerciales que desbloquean características empresariales

Add-ons modulares que te permiten pagar solo por lo que necesitas

Este enfoque modular evita el sobrecoste típico de soluciones propietarias que te obligan a adquirir paquetes completos incluso cuando solo necesitas funcionalidades específicas.

4. Características Empresariales Avanzadas

VitalPBX no escatima en funcionalidades profesionales:

Alta disponibilidad (HA) para entornos críticos

Multi-tenant para proveedores de servicios

Integración con CRM (Salesforce, SuiteCRM, Vtiger)

WebRTC para comunicaciones desde el navegador

Grabación de llamadas con almacenamiento flexible

Reportes y estadísticas detalladas

Aplicaciones móviles nativas para iOS y Android

Estas características permiten que VitalPBX compita directamente con soluciones empresariales de alto costo.

5. Ecosistema de Integraciones y Escalabilidad

La verdadera fortaleza de VitalPBX radica en su capacidad de integración y escalabilidad:

API REST para integraciones personalizadas

Compatibilidad con troncales SIP de prácticamente cualquier proveedor

Soporte para WebRTC que facilita la integración en aplicaciones web

Escalabilidad horizontal mediante clustering

Docker-friendly para despliegues modernos en contenedores

Para entornos técnicos exigentes, VitalPBX se integra perfectamente con infraestructura complementaria como Kamailio para SIP proxy, RTPEngine para procesamiento de media, y sistemas de billing como A2Billing.

Conclusión

VitalPBX representa un equilibrio excepcional entre facilidad de uso y potencia técnica. Ya seas un proveedor de servicios VoIP que necesita una plataforma multi-tenant escalable, una empresa que busca modernizar su sistema de comunicaciones, o un ingeniero de telecomunicaciones que requiere control total sobre la infraestructura, VitalPBX ofrece las herramientas necesarias para construir una solución robusta y profesional.

La combinación de su base técnica sólida, interfaz amigable, modelo de licenciamiento justo y características empresariales lo convierte en una opción que definitivamente vale la pena evaluar para tu próximo proyecto de telefonía IP.
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo
Andrea Sannucci Claude Code demuestra su capacidad para depurar criptografía de bajo nivel
El desarrollador Filippo Valsorda compartió recientemente su experiencia utilizando Claude Code para depurar una implementación de ML-DSA, un algoritmo de firma post-cuántica especificado por NIST. Lo notable del caso es que Claude Code resolvió rápidamente un error complejo de bajo nivel en una implementación relativamente novedosa de un algoritmo criptográfico.

El problema surgió después de cuatro días de programación en vivo: la función Verify siempre rechazaba las firmas válidas. Exhausto y antes de continuar al día siguiente, Valsorda decidió probar Claude Code mientras revisaba emails.

El resultado sorprendió al desarrollador: Claude identificó que había fusionado las funciones HighBits y w1Encode en una sola, y luego la reutilizó desde Verify donde UseHint ya producía los bits altos, efectivamente tomando los bits altos de w1 dos veces en Verify. La solución llegó en minutos sin necesidad de exploración adicional.

Para validar la efectividad de la herramienta, Valsorda realizó dos experimentos adicionales con errores anteriores en su código. Claude Code logró identificar y corregir ambos bugs: uno relacionado con constantes en el dominio de Montgomery calculadas incorrectamente, y otro con un valor codificado en la firma que era demasiado corto (32 bits en lugar de 32 bytes).

El autor concluye que esta experiencia le hizo darse cuenta de que aún no tiene una buena intuición sobre cuándo invocar herramientas de IA, y destaca que lo importante es que no es necesario confiar ciegamente en el LLM cuando su trabajo es simplemente indicar dónde está el error, para que el desarrollador lo razone y corrija.

Fuente: Claude Code Can Debug Low-level Cryptography - Filippo Valsorda
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

Andrea Sannucci Configuración de Kamailio para WebRTC: Guía Completa de Implementación

WebRTC (Web Real-Time Communication) representa una auténtica revolución en las comunicaciones en tiempo real a través de navegadores web. Esta tecnología permite la comunicación directa entre navegadores sin necesidad de plugins o software adicional, convirtiéndose en un estándar fundamental para aplicaciones VoIP modernas.

En este artículo profundizaremos en la configuración de Kamailio para procesar correctamente señalización SIP sobre WebSocket, permitiendo establecer llamadas entre diferentes tipos de endpoints: UDP tradicional, TLS y WebSocket Secure (WSS).

¿Qué es WebRTC?

WebRTC proporciona tres APIs principales en JavaScript que permiten a los desarrolladores crear aplicaciones de comunicación interactivas:

APIs Fundamentales

getUserMedia: Solicita acceso a dispositivos de audio/vídeo presentes en computadores, tablets y smartphones
RTCPeerConnection: Establece un flujo de media directo (peer-to-peer) entre los interlocutores
RTCDataChannel: Permite el intercambio de datos fuera del flujo de media (mensajes de texto, fotos, archivos)

Protocolos y Codecs

El flujo de media en WebRTC utiliza:

SRTP sobre DTLS: Protocolo cifrado basado en TLS específicamente diseñado para datagramas UDP
Codecs de audio: alaw, ulaw y Opus
Codecs de vídeo: VP8 y H.264 (según RFC7742)
ICE (RFC8445): Protocolo para atravesar NAT con 99% de efectividad

Señalización Flexible

WebRTC no impone un protocolo de señalización específico. Puede utilizarse cualquier protocolo, siendo SIP y XMPP los más populares. La RFC7118 (enero 2014) estandariza el uso de WebSocket como transporte para SIP, permitiendo la integración con infraestructuras VoIP existentes.

La configuración que implementaremos permitirá los siguientes escenarios de llamadas:

UDP  ←→ UDP
UDP  ←→ WSS
WSS  ←→ UDP
WSS  ←→ WSS

Opcionalmente, también se puede configurar para:

TLS  ←→ TLS
TLS  ←→ WSS
WSS  ←→ TLS
WSS  ←→ WSS

La construcción del enrutamiento se basa en principios fundamentales de:

Detección de protocolo: Identificación correcta del protocolo de transporte (UDP, TLS, WSS)
Bridge/Puente de protocolos: Conversión transparente entre diferentes transportes
Gestión de NAT: Manejo específico para clientes WebRTC tras NAT
Manipulación de media: Configuración dinámica de RTPEngine según el escenario

route[PUENTE] {
    if (!has_totag()) {
        if ($proto =~ "wss" && !($ru =~ "transport=wss")) {
            xlog("L_INFO","Puente WSS-UDP branch=$bf proto=$proto");
            setbflag(FLB_PUENTE);
        } else if (!($proto =~ "wss") && $ru =~ "transport=wss") {
            xlog("L_INFO","Puente UDP-WSS branch=$bf proto=$proto");
            setbflag(FLB_PUENTE);
        }
    }
}

Este bloque utiliza:

Verificación de has_totag() para detectar diálogos iniciales
Pattern matching con expresiones regulares para detectar protocolo de origen y destino
Branch flags (bflags) para marcar transacciones que requieren conversión
Logging detallado para troubleshooting

Ventaja: Permite decisiones de enrutamiento contextuales sin requerir verificaciones repetidas en cada punto del flujo.

#!ifdef WITH_WEBSOCKET
    if (nat_uac_test(64)) {
        if (is_method("REGISTER")) {
            fix_nated_register();
        } else if (!add_contact_alias()) {
            xlog("L_ERR", "Error aliasing contact <$ct>\n");
            sl_send_reply("400", "Bad Request");
            exit;
        }
    }
#!endif

Implementación que:

Usa nat_uac_test(64) específicamente para detectar WebSocket
Aplica correcciones diferenciadas según el método SIP
Maneja errores apropiadamente con respuestas SIP estándar
Utiliza contact aliasing para tracking de conexiones WebSocket

Punto clave: El flag 64 es específico para WebSocket, diferenciándolo de otras detecciones NAT tradicionales.

Este es el corazón de la solución y merece un análisis detallado:

route[RTPENGINE] {
    if(!is_method("INVITE")) return;
    
    $xavp(r=>$T_branch_idx) = "replace-origin replace-session-connection";
    
    if(nat_uac_test("8")) {
        $xavp(r=>$T_branch_idx) = $xavp(r=>$T_branch_idx) + " trust-address";
    }
    
    # Gestión de via-branch para tracking
    if (is_request()) {
        if (!has_totag()) {
            if (!t_is_failure_route()) {
                $avp(extra_id) = @via[1].branch + $T_branch_idx;
                $xavp(r=>$T_branch_idx) = $xavp(r=>$T_branch_idx) + " via-branch=extra";
            }
        }
    }
    
    if (is_reply()) {
        $avp(extra_id) = @via[2].branch + $T_branch_idx;
        $xavp(r=>$T_branch_idx) = $xavp(r=>$T_branch_idx) + " via-branch=extra";
    }
    
    # Configuración específica de conversión
    if (isbflagset(FLB_PUENTE)) {
        if ($proto =~ "wss") {
            # De WSS a SIP (UDP/TCP)
            $xavp(r=>$T_branch_idx) = $xavp(r=>$T_branch_idx) + 
                " rtcp-mux-demux DTLS=off SDES-off ICE=remove RTP/AVP";
        } else {
            # De SIP a WSS
            $xavp(r=>$T_branch_idx) = $xavp(r=>$T_branch_idx) + 
                " rtcp-mux-offer generate-mid DTLS=passive SDES-off ICE=force RTP/SAVPF";
        }
    } else {
        if ($proto =~ "ws") {
            # WSS a WSS
            $xavp(r=>$T_branch_idx) = $xavp(r=>$T_branch_idx) + 
                " generate-mid DTLS=passive SDES-off ICE=force";
        }
    }
    
    xlog("L_INFO", "NATMANAGE branch_id:$T_branch_idx ruri: $ru, metodo:$rm, 
        CseQ:$cs status:$rs, extra_id: $avp(extra_id), 
        rtpengine_manage: $xavp(r=>$T_branch_idx)\n");
    
    rtpengine_manage($xavp(r=>$T_branch_idx));
}

a) Uso de XAVP para Branch-Level Configuration

Cada rama de transacción ($T_branch_idx) tiene su propia configuración
Ventaja: Permite forking con diferentes configuraciones RTPEngine por branch
Caso de uso: Usuario registrado en múltiples dispositivos (UDP + WSS simultáneamente)

b) Parámetros de Conversión WSS→UDP

rtcp-mux-demux DTLS=off SDES-off ICE=remove RTP/AVP

Parámetro	Función	Justificación
`rtcp-mux-demux`	Desmultiplexa RTP y RTCP	WebRTC usa un solo puerto, SIP tradicional espera puertos separados
`DTLS=off`	Desactiva DTLS	El endpoint UDP no soporta cifrado DTLS
`SDES-off`	Desactiva SDES	No se usa SDES para key exchange en esta dirección
`ICE=remove`	Elimina candidates ICE	El endpoint UDP no procesa ICE
`RTP/AVP`	Perfil RTP básico	Sin cifrado, compatible con dispositivos legacy

c) Parámetros de Conversión UDP→WSS

rtcp-mux-offer generate-mid DTLS=passive SDES-off ICE=force RTP/SAVPF

Parámetro	Función	Justificación
`rtcp-mux-offer`	Ofrece multiplexado RTP/RTCP	Requerido por WebRTC
`generate-mid`	Genera media identification	Necesario para BUNDLE
`DTLS=passive`	RTPEngine actúa como servidor DTLS	Espera handshake del cliente
`SDES-off`	Desactiva SDES	WebRTC usa DTLS-SRTP
`ICE=force`	Fuerza generación de candidates	Obligatorio para WebRTC
`RTP/SAVPF`	Secure Audio/Video Profile with Feedback	Estándar WebRTC con cifrado

d) Via-Branch Tracking

$avp(extra_id) = @via[1].branch + $T_branch_idx;

Propósito: Crear identificadores únicos para sesiones RTPEngine que persisten a través de re-INVITEs y actualizaciones. Crucial para:

Call hold/resume
Codec renegotiation
Session updates

Configuración Paso a Paso

1. Prerequisitos

Los certificados TLS/DTLS deben estar creados previamente (reutilizados de configuración TLS de Kamailio).

2. Activación de Módulos

Agregar en kamailio.cfg:

#!define WITH_WEBSOCKET

Cargar módulos necesarios:

#!ifdef WITH_WEBSOCKET
    loadmodule "xhttp.so"
    loadmodule "websocket.so"
#!endif

Módulos y sus funciones:

xhttp: Servidor web básico para manejar peticiones HTTP
websocket: Servidor WebSocket para señalización SIP

3. Configuración de Listeners

listen=tls:IP_PUBLICA:8443

Nota: Se usa puerto 8443 por convención (puede personalizarse).

4. Parámetros Globales TCP

#!ifdef WITH_WEBSOCKET
    tcp_accept_no_cl=yes
    http_reply_parse=yes
#!endif

Explicación:

tcp_accept_no_cl=yes: Acepta requests sin header Content-Length
http_reply_parse=yes: Permite parsear respuestas HTTP (necesario para WebSocket handshake)

5. Event Routes para WebSocket

Gestión de Conexiones (event_route[xhttp:request])

event_route[xhttp:request] {
    set_reply_close();
    set_reply_no_connect();
    
    # Validar puerto
    if ($Rp != 8443) {
        xlog("L_WARN", "HTTP request received on $Rp\n");
        xhttp_reply("403", "Forbidden", "", "");
        exit;
    }
    
    xlog("L_DBG", "HTTP Request Received $hu\n");
    
    # Validar WebSocket upgrade
    if ($hdr(Upgrade)=~"websocket"
            && $hdr(Connection)=~"Upgrade"
            && $rm=~"GET") {
        
        # Validar Host
        if ($hdr(Host) == $null || !is_myself("sip:" + $hdr(Host))) {
            xlog("L_WARN", "Bad host $hdr(Host)\n");
            xhttp_reply("403", "Forbidden", "", "");
            exit;
        }
        
        # Ejecutar handshake
        if (ws_handle_handshake()) {
            exit;
        }
    }
    
    xhttp_reply("404", "Not found", "", "");
}

Análisis:

Implementa security best practices
Valida upgrade headers según RFC6455
Verifica que el Host es válido

Logging de Cierre (event_route[websocket:closed])

event_route[websocket:closed] {
    xlog("L_INFO", "WebSocket connection with id $ws_conid from $si:$sp has closed\n");
}

Utilidad: Debugging y monitoreo de conexiones activas.

6. Gestión de Respuestas

#!ifdef WITH_WEBSOCKET
onreply_route {
    if (nat_uac_test(64)) {
        add_contact_alias();
    }
}
#!endif

Función: Añade alias de contacto en respuestas para mantener routing correcto.

7. Firewall (IPTables)

-A INPUT -p tcp -m state --state NEW -m tcp --dport 8443 -j ACCEPT

Seguridad Avanzada: CORS (Cross-Origin Resource Sharing) y Origin Validation

Para restringir acceso solo a dominios autorizados:

if ($hdr(Origin) != "https://campus.miodominio.org") {
    xlog("L_WARN", "Unauthorised client $hdr(Origin)\n");
    xhttp_reply("403", "Forbidden", "", "");
    exit;
}

Consideraciones:

Implementa CORS a nivel SIP
Previene uso no autorizado del servidor
Lista blanca de dominios permitidos

Testing y Validación

1. Verificación de Configuración

kamailio -c /etc/kamailio/kamailio.cfg

Salida esperada:

Listening on
     udp: IP_PUBLICA [IP_PUBLICA]:5060
     udp: IP_PRIVADA [IP_PRIVADA]:5060
     tls: IP_PUBLICA [IP_PUBLICA]:8443
Aliases:
config file ok, exiting...

2. Creación de Usuario WebRTC

kamctl add 1003@sip1.miodominio.org PassWord

3. Cliente WebRTC Recomendado

Sugiero usar Browser-Phone, un softphone WebRTC amigable.

Configuración típica:

WebSocket URI: wss://sip1.miodominio.org:8443
Usuario: 1003
Password: PassWord
Display Name: Usuario WebRTC

4. Escenarios de Prueba

Origen	Destino	Resultado Esperado
WSS (1003)	UDP (1001)	Conversión WSS→UDP, audio bidireccional
UDP (1001)	WSS (1003)	Conversión UDP→WSS, video si disponible
WSS (1003)	WSS (1004)	Comunicación nativa WebRTC, máxima calidad
UDP (1001)	UDP (1002)	Sin conversión, routing tradicional

5. Troubleshooting

Llamadas no se establecen

Verificar:

RTPEngine está corriendo: systemctl status rtpengine
Puertos UDP abiertos: 10000-20000/udp para RTP
Logs de Kamailio: kamlog | grep -i error
SDP en INVITE: sngrep para captura de paquetes

Audio unidireccional

Causas comunes:

Configuración incorrecta de rtcp-mux-demux
ICE candidates no alcanzan el endpoint
Firewall bloqueando RTP

Solución:

# Verificar flags de RTPEngine
kamcmd rtpengine.show all

Configuraciones Alternativas

Solo TLS + WebRTC

Para entornos que requieren cifrado end-to-end:

TLS ←→ TLS
TLS ←→ WSS
WSS ←→ TLS
WSS ←→ WSS

Modificación en route[PUENTE]:

route[PUENTE] {
    if (!has_totag()) {
        # Detectar cualquier combinación de protocolos seguros
        if (($proto =~ "wss" || $proto =~ "tls") && 
            !($ru =~ "transport=wss" || $ru =~ "transport=TLS")) {
            xlog("L_INFO","Puente seguro $proto a estándar");
            setbflag(FLB_PUENTE);
        } else if (!($proto =~ "wss" || $proto =~ "tls") && 
                   ($ru =~ "transport=wss" || $ru =~ "transport=TLS")) {
            xlog("L_INFO","Puente estándar a seguro");
            setbflag(FLB_PUENTE);
        }
    }
}

Monitoreo y Métricas

Comandos Útiles

# Ver conexiones WebSocket activas
kamcmd ws.dump

# Estadísticas de RTPEngine
kamcmd rtpengine.show all

# Dialogos activos
kamcmd dlg.list

Métricas Clave

Conexiones WebSocket activas: Debe correlacionar con registros activos
Sesiones RTPEngine: Una por llamada activa
Branch failures: Idealmente < 1% de llamadas totales
Latencia de handshake: < 500ms para buena experiencia

Próximos Pasos

Implementar Rate Limiting para prevenir ataques
Configurar Load Balancing de RTPEngine
Integrar con sistema de Billing
Implementar QoS monitoring

Recursos Adicionales

RFC7118: WebSocket como transporte para SIP
RFC8445: ICE para NAT Traversal
Documentación Kamailio: https://www.kamailio.org/wikidocs/
RTPEngine GitHub: https://github.com/sipwise/rtpengine

Tags: #Kamailio #WebRTC #VoIP #SIP #RTPEngine #RealTimeCommunications #TelecomEngineering

Vota el Articulo:

Andrea Sannucci Asterisk Taskpool: De una intuición a una Mejora de Rendimiento Significativa
Asterisk ha utilizado durante más de 10 años el threadpool API, que proporciona métodos comunes para un pool configurable de threads que pueden ejecutar trabajo arbitrario. Los dos usuarios más intensivos han sido PJSIP y Stasis, que lo emplean principalmente para despachar trabajo de manera asíncrona.

Basándose en tendencias observadas (posts y comentarios sobre los taskprocessors stasis/pool y stasis/pool-control), se intuyó que el costo de usar el threadpool API era elevado. Al examinar la implementación, confirmó sus sospechas:

Ineficiencias del Threadpool:

Mantiene una cola única de trabajo para todas las tareas

Utiliza una segunda cola de gestión separada para administrar el pool

Cada tarea insertada resulta en 2 tareas encoladas: la tarea real y una tarea de gestión del threadpool

Si el threadpool no responde lo suficientemente rápido, la cola única puede crecer indefinidamente, causando los famosos mensajes de stasis/pool taskprocessor

Pruebas de Eficiencia del Threadpool

Ejecutando tests durante 30 segundos con 50 threads:

Threadpool Push: 22,809,319 tareas ejecutadas (760,310 por segundo)

Threadpool Serializer Push: 16,590,999 tareas ejecutadas (553,033 por segundo)

El uso de serializers incurre en aproximadamente 27% de penalización en rendimiento.

Conclusión: El threadpool API es bueno para tareas de duración media a larga, pero ineficiente para tareas de corta a media duración. El overhead de gestionar el threadpool simplemente no vale la pena.

La Solución: Taskpool API

Se diseñó un nuevo API específicamente enfocado en tareas de corta a media duración, llamado taskpool.

Diferencias Clave del Taskpool:

No hay cola única de trabajo: Cuando se inserta una tarea, se asigna inmediatamente a un taskprocessor específico y se encola directamente en él

No hay cola de gestión separada: Si el taskpool necesita crecer, se hace al insertar una tarea. Si necesita reducirse, se hace de forma asíncrona en segundo plano usando un scheduled item periódico

Es efectivamente un pool de taskprocessors con la configurabilidad del threadpool API

Aclaración Importante sobre Taskprocessors

Los taskprocessors en sí mismos son bastante eficientes. Los problemas de taskprocessor son causados fundamentalmente por cómo los usuarios los emplean. Si son lentos o no los usan eficientemente, el síntoma son problemas de taskprocessor.

Resultados de Rendimiento del Taskpool

Ejecutando tests equivalentes en el mismo sistema:

Taskpool Push: 61,255,016 tareas ejecutadas (2,041,833 por segundo) – 2.69x más tareas que threadpool

Taskpool Serializer Push: 48,997,697 tareas ejecutadas (1,633,256 por segundo) – 2.95x más tareas que threadpool

La penalización por uso de serializers se reduce a aproximadamente 20%.

Rendimiento en Diferentes Sistemas

Otros usuarios han reportado resultados aún mejores, hasta 20x de mejora. El rendimiento depende del sistema y CPU específico, pero es una mejora para todos sin excepción.

Nota crítica: A lo largo de todo este proceso, no se hicieron cambios a los taskprocessors en sí mismos. Esto demuestra cómo el uso correcto de taskprocessors puede marcar una enorme diferencia en rendimiento.

¿Dónde se Usa Taskpool Actualmente?

El usuario principal de taskpool es Stasis para despacho de mensajes desde las versiones:

Asterisk 20.17.0

Asterisk 22.7.0

Asterisk 23.1.0

Cambios Visibles:

La configuración cambió a taskpool (las opciones de threadpool siguen soportadas)

En core show taskprocessors, los taskprocessors pool y pool-control fueron removidos y reemplazados por stasis taskpool

Impacto Reportado:

Los reportes tempranos muestran:

Reducción de 20-30% en uso de CPU

Resolución de problemas de rendimiento para múltiples usuarios

Para usarlo: Solo actualiza a una de las versiones listadas o superior. No hay nada más que hacer.

Conclusión: Esta mejora demuestra cómo una intuición bien fundamentada y un análisis cuidadoso de la arquitectura pueden resultar en mejoras significativas de rendimiento, simplemente utilizando las herramientas existentes (taskprocessors) de manera más eficiente. Fuente: https://www.asterisk.org/taskpool-a-hunch-turned-performance-improvement/
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

November 25, 2025

Andrea Sannucci SNGREP en Alamalinux 10
sudo dnf update -y

reboot

dnf groupinstall "Development Tools"

dnf install libpcap-devel cmake gcc gcc-c++ make ncurses-devel git wget tcpdump nmap traceroute vim -y

cd /usr/src

git clone https://github.com/irontec/sngrep.git

cd sngrep

mkdir build && cd build

cmake ..

make && make install

sngrep
- SNGREP
- Almalinux 10
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo
Andrea Sannucci Google: El futuro distópico que ya está aquí (y tú lo aceptaste sin leerlo)
Los servicios de Google se han convertido en una presencia omnipresente en nuestras vidas digitales, pero detrás de la conveniencia aparente se esconde una realidad inquietante que muchos usuarios prefieren ignorar. La compañía ha construido un ecosistema cerrado donde cada clic, cada búsqueda, cada correo electrónico y cada ubicación se registra meticulosamente para alimentar un perfil digital que conoce más sobre nosotros que nuestros propios amigos.

La pesadilla comienza con la ilusión de gratuidad. Gmail, Google Drive, YouTube, Maps: todo parece gratis, pero el precio real es la monetización exhaustiva de nuestra información personal. No somos los clientes de Google, somos el producto. Cada interacción alimenta algoritmos de publicidad que nos persiguen por internet, prediciendo nuestros deseos antes de que los formulemos conscientemente. Es una forma de capitalismo de vigilancia donde la intimidad se convierte en materia prima para generar ganancias.

La integración forzada entre servicios es otra faceta distópica. Intentar usar un solo servicio de Google sin verse arrastrado al ecosistema completo es prácticamente imposible. Quieres usar YouTube sin una cuenta de Google? Pierdes funcionalidades básicas. Intentas separar tu correo de tu navegador? El sistema te empuja constantemente a sincronizar todo. Esta interdependencia no es accidental, es diseño deliberado para maximizar la recolección de datos y crear dependencia.

La manipulación algorítmica se disfraza de personalización. El buscador no te muestra resultados objetivos, te muestra lo que sus algoritmos creen que quieres ver basándose en tu perfil. YouTube te atrapa en burbujas de contenido cada vez más extremas porque el engagement es más valioso que la verdad. Google Maps conoce cada lugar que visitas, creando patrones de comportamiento que pueden predecir tus movimientos futuros. Esta personalización excesiva no solo invade la privacidad, sino que fragmenta nuestra percepción de la realidad compartida.

Los términos de servicio son laberintos legales diseñados para ser incomprensibles. Miles de palabras de jerga jurídica que básicamente dicen: "aceptas que podemos hacer lo que queramos con tu información". Y si no aceptas, quedas excluido de servicios que se han vuelto prácticamente indispensables para la vida moderna. Es coerción disfrazada de elección.

La centralización del poder es aterradora. Google controla el motor de búsqueda más usado del mundo, el servicio de correo electrónico más popular, la plataforma de video más grande, el sistema operativo móvil dominante, y sistemas de publicidad que sostienen gran parte de internet. Este monopolio tecnológico le otorga un poder desproporcionado para moldear qué información vemos, cómo nos comunicamos y hasta cómo pensamos.

La seguridad y los hackeos son otra preocupación. Centralizar toda tu vida digital en un ecosistema significa que una sola brecha de seguridad, una contraseña comprometida, puede exponer todo: correos, fotos, documentos, ubicaciones históricas, contactos. Es poner todos los huevos en una canasta controlada por una corporación que, a pesar de sus recursos, no es inmune a fallos de seguridad ni a decisiones cuestionables sobre cómo manejar incidentes.

El aspecto más distópico quizás sea la normalización. Hemos aceptado esta vigilancia masiva como el precio inevitable de la tecnología moderna. Las generaciones más jóvenes crecen sin conocer un internet donde la privacidad era valorada. Google ha logrado que entregar voluntariamente nuestra información más íntima parezca no solo normal, sino deseable y conveniente.

La alternativa existe pero requiere esfuerzo consciente: servicios de correo encriptado, motores de búsqueda que no rastrean, navegadores enfocados en privacidad, almacenamiento descentralizado. Sin embargo, Google ha construido muros tan altos alrededor de su jardín que salir de él implica sacrificar conveniencia, compatibilidad y a menudo funcionalidad. Es precisamente así como operan los sistemas distópicos: haciendo que la resistencia sea técnicamente posible pero prácticamente agotadora.
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo
Andrea Sannucci Kamailio for Dummies: arquitectura, casos de uso y configuración básica
Si alguna vez te has preguntado cómo funcionan las llamadas de WhatsApp, Teams, o cualquier sistema de telefonía IP moderno, déjame presentarte a uno de los héroes desconocidos detrás de toda esa magia: Kamailio. No te preocupes si nunca has escuchado hablar de él, para eso estamos aquí, para empezar desde cero y entender qué es esta herramienta que mueve millones de llamadas diarias alrededor del mundo sin que nadie lo note.

¿Qué diablos es Kamailio?

Imagina que quieres llamar a tu amigo que está en otro país. Tu teléfono necesita encontrar el teléfono de tu amigo en algún lugar del internet, establecer la conexión, negociar cómo se va a transmitir el audio, manejar el caso en que tu amigo esté ocupado o no conteste, y finalmente terminar la llamada cuando uno de los dos cuelgue. Todo esto sucede en fracciones de segundo, y alguien tiene que coordinar todo ese caos. Ese alguien es un servidor SIP, y Kamailio es uno de los mejores en ese trabajo.

Kamailio es lo que técnicamente llamamos un SIP Proxy Server, pero olvidemos la jerga por un momento. Piensa en él como el operador telefónico del siglo XXI, ese intermediario inteligente que sabe dónde está cada persona, cómo conectarlas, y qué hacer cuando algo sale mal. Es gratuito, es open source, y es tan poderoso que empresas gigantes como Cisco, Alcatel-Lucent y cientos de proveedores de telefonía lo usan en sus sistemas de producción moviendo millones de llamadas simultáneas.

La belleza de Kamailio radica en su simplicidad conceptual combinada con una flexibilidad extrema. No es una centralita completa como Asterisk que maneja llamadas, graba conversaciones, reproduce música de espera y hace café. Kamailio hace una cosa y la hace extraordinariamente bien: enrutar señalización SIP a velocidades absurdas con un consumo de recursos ridículamente bajo. Es el velocista olímpico del mundo VoIP, mientras que otros son buenos atletas de decatlón.

La arquitectura de Kamailio: diseño para la velocidad

Para entender por qué Kamailio es tan rápido, necesitamos entender cómo está construido. La mayoría del software moderno maneja cada conexión en un proceso separado o en un thread independiente, lo cual está bien para aplicaciones normales pero es un desastre cuando necesitas manejar 100,000 llamadas simultáneas. Kamailio tomó un camino diferente y más inteligente.

Kamailio utiliza una arquitectura de procesos múltiples pero con memoria compartida. Cuando arrancas Kamailio, se inicia un proceso maestro que luego crea varios procesos worker, típicamente uno por cada núcleo de CPU que tengas disponible. Estos workers son los que realmente procesan los mensajes SIP que llegan al servidor. La magia está en que todos estos procesos comparten la misma memoria, lo que significa que pueden acceder instantáneamente a la misma información sin necesidad de comunicarse entre ellos mediante mecanismos lentos como sockets o pipes.

Esta memoria compartida es donde Kamailio almacena todo lo importante: las tablas de localización de usuarios, las estadísticas en tiempo real, las listas negras, los contadores de llamadas, básicamente todo lo que necesita ser accesible rápidamente por cualquier worker. Es como tener una pizarra gigante en el medio de una oficina donde todos pueden leer y escribir simultáneamente sin formar fila ni pedir permiso.

El resultado de esta arquitectura es impresionante. Un servidor modesto con 8 cores puede procesar fácilmente más de 10,000 llamadas por segundo en términos de mensajes SIP procesados. Para poner esto en perspectiva, eso es suficiente para manejar una ciudad pequeña completa. Y lo hace usando menos memoria que tu navegador Chrome con 5 pestañas abiertas.

Pero la velocidad no es el único beneficio. Esta arquitectura también hace que Kamailio sea extremadamente estable. Si un worker se cuelga por alguna razón, los demás siguen trabajando sin problemas y el proceso maestro simplemente reinicia el worker caído. Es como tener un equipo de trabajadores donde si uno se enferma, los demás continúan y traes un reemplazo sin que nadie note la diferencia.

El lenguaje de configuración: tu nuevo superpoder

Aquí es donde Kamailio se pone interesante y, admitámoslo, un poco intimidante para los principiantes. Kamailio no tiene una interfaz gráfica bonita con botones y menús desplegables. Su configuración se hace mediante un archivo de texto plano llamado kamailio.cfg que usa un lenguaje de scripting propio. Antes de que salgas corriendo, déjame explicarte por qué esto es realmente una ventaja.

Este lenguaje de scripting te da un control absoluto sobre cada aspecto del comportamiento de Kamailio. Es como tener el código fuente de un programa pero sin necesidad de recompilar nada. Cada mensaje SIP que llega a tu servidor pasa por tu script, y tú decides exactamente qué hacer con él. ¿Quieres enrutar llamadas de manera diferente según la hora del día? Fácil. ¿Necesitas bloquear ciertos números? Pan comido. ¿Quieres implementar un sistema complejo de tarifación en tiempo real? Adelante.

El archivo de configuración se estructura en rutas, que son básicamente bloques de código que se ejecutan cuando ocurre algo específico. La ruta principal se llama request_route y es donde aterrizan todos los mensajes SIP iniciales. Desde ahí, tú decides qué camino toma cada mensaje. Es como ser el controlador de tráfico aéreo de tu red de telefonía.

Un concepto fundamental en el scripting de Kamailio son los módulos. Kamailio por sí solo no hace mucho, es el núcleo del sistema. Los módulos son las piezas que añades según lo que necesites. Hay módulos para autenticación de usuarios, para consultar bases de datos, para hacer load balancing, para integración con Redis, para enviar eventos a sistemas externos, literalmente hay módulos para todo. Cargas solo los que necesitas, manteniendo el consumo de memoria al mínimo.

Casos de uso reales: dónde brilla Kamailio

Ahora que entendemos qué es y cómo funciona Kamailio, hablemos de para qué se usa realmente en el mundo real. La versatilidad de Kamailio lo hace adecuado para una variedad sorprendente de escenarios.

El caso de uso más común y obvio es como SIP proxy o registrar server. En términos simples, esto significa que Kamailio actúa como el directorio telefónico de tu red VoIP. Cuando tus usuarios encienden sus teléfonos o aplicaciones SIP, se registran con Kamailio diciéndole "hola, soy la extensión 1000 y estoy en esta dirección IP". Kamailio guarda esta información y cuando alguien quiere llamar a la extensión 1000, Kamailio sabe exactamente dónde encontrarla. Es el equivalente digital de la vieja operadora que conectaba cables físicos en un tablero.

Otro uso extremadamente popular es como Session Border Controller o SBC. Este es un término fancy para decir que Kamailio se sienta en el borde de tu red protegiendo tus sistemas internos del internet salvaje. Los SBCs manejan NAT traversal, que es ese problema molesto donde los dispositivos detrás de routers no pueden comunicarse directamente con el exterior. También aplican políticas de seguridad, bloquean ataques de fuerza bruta, normalizan mensajes SIP mal formados, y básicamente actúan como el guardián de seguridad de tu infraestructura VoIP.

El load balancing es otra aplicación donde Kamailio brilla intensamente. Supongamos que tienes cinco servidores Asterisk manejando tu centralita. Sin un load balancer, tendrías que configurar manualmente qué usuarios van a qué servidor, y si un servidor se cae, esos usuarios quedan sin servicio. Con Kamailio al frente, puedes distribuir las llamadas inteligentemente entre tus servidores, detectar cuando uno falla y automáticamente dejar de enviarle tráfico, e incluso hacer distribución basada en carga real de cada servidor.

Las empresas grandes usan Kamailio como carrier-grade routing platform, básicamente el cerebro que decide cómo enrutar millones de llamadas a través de múltiples proveedores, países y tecnologías. Imagina que tienes diez proveedores de terminación de llamadas internacionales, cada uno con diferentes tarifas para diferentes destinos. Kamailio puede consultar una base de datos en tiempo real, determinar la ruta más barata para cada llamada, intentar el proveedor principal y automáticamente failover a alternativas si algo falla, todo esto en milisegundos.

WebRTC gateway es un caso de uso moderno y creciente. WebRTC es la tecnología que permite hacer llamadas directamente desde un navegador web sin plugins ni aplicaciones. El problema es que WebRTC usa algunos dialectos diferentes de SIP y requiere cosas como WebSocket transport. Kamailio puede actuar como el traductor entre el mundo WebRTC y el mundo SIP tradicional, permitiendo que usuarios en navegadores llamen a teléfonos normales y viceversa.

Configuración básica: los primeros pasos

Llegó el momento de ensuciarnos las manos con algo de configuración real, pero tranquilo, vamos a mantenerlo simple y entendible. No necesitas memorizar nada de esto, solo entender los conceptos para que cuando veas configuraciones más complejas no te paralices del miedo.

Un archivo kamailio.cfg típico comienza con la carga de módulos. Esto se ve algo así como loadmodule seguido del nombre del módulo entre comillas. Por ejemplo, cargarías el módulo sl para respuestas stateless, tm para manejo de transacciones, rr para record routing, y así sucesivamente. Cada módulo puede tener parámetros de configuración que ajustan su comportamiento, esto se hace con la directiva modparam.

Después de cargar módulos viene la lógica de enrutamiento. La sección request_route es tu punto de entrada principal. Aquí es donde escribes la lógica que procesa cada mensaje SIP que llega. Un patrón común es primero hacer validaciones de seguridad básicas, verificar si el mensaje está bien formado, tal vez bloquearlo si viene de una IP en lista negra, luego determinar si es un REGISTER o una llamada normal, autenticar si es necesario, y finalmente enrutarlo a su destino.

Para entender mejor esto, pensemos en un flujo simple de registro. Un teléfono envía un mensaje REGISTER a Kamailio. Tu script primero detecta que es un REGISTER usando una simple condición if que verifica el método del mensaje. Luego llamas a una función de autenticación que verifica que el usuario exista en tu base de datos y que la contraseña sea correcta. Si la autenticación falla, respondes con un desafío de autenticación usando un código 401. Si tiene éxito, guardas la información de registro llamando a una función save que almacena en qué IP está ese usuario. Finalmente, respondes con un 200 OK indicando que el registro fue exitoso.

El enrutamiento de llamadas sigue una lógica similar pero un poco más compleja. Cuando llega un INVITE, que es el mensaje SIP que inicia una llamada, primero verificas si el llamante está autenticado y autorizado para hacer esa llamada. Luego determinas a dónde debe ir la llamada, tal vez consultando una base de datos o aplicando reglas basadas en el número marcado. Una vez que sabes el destino, necesitas registrar la ruta usando funciones de record_route para que los mensajes subsecuentes de esa llamada sepan cómo regresar. Finalmente, usas la función relay para enviar el INVITE a su destino.

Un concepto que confunde a muchos principiantes es la diferencia entre procesamiento stateless y stateful. Stateless significa que Kamailio simplemente reenvía el mensaje y se olvida de él inmediatamente, no mantiene ningún estado sobre esa transacción. Es rápido pero limitado. Stateful significa que Kamailio mantiene información sobre la transacción en memoria, puede reenviar mensajes si no hay respuesta, puede hacer forking enviando la llamada a múltiples destinos simultáneamente, y generalmente tiene mucho más control. La mayoría de las configuraciones usan procesamiento stateful para llamadas mediante el módulo tm.

Las bases de datos son otro componente crítico en configuraciones reales. Kamailio puede conectarse a MySQL, PostgreSQL, MongoDB, Redis y muchos otros sistemas de almacenamiento. Típicamente usarías una base de datos para almacenar información de usuarios, sus credenciales de autenticación, preferencias de enrutamiento, CDRs para facturación, y datos de localización persistente. El módulo db_mysql o db_postgres maneja esta conectividad, y otros módulos como auth_db y usrloc usan esa conexión para sus operaciones.

Integración con RTPEngine: el dúo dinámico

Aquí llegamos a un punto importante que muchos novatos no entienden al principio. Kamailio maneja la señalización SIP, es decir, los mensajes de control que establecen, modifican y terminan llamadas. Pero el audio o video real de la llamada no pasa por Kamailio, viaja directamente entre los endpoints usando un protocolo llamado RTP. Esto está bien en muchos casos, pero a veces necesitas que el media también pase por tu servidor, ya sea para transcoding entre diferentes codecs, para atravesar NAT complejos, o para grabar llamadas.

Aquí es donde entra RTPEngine, el compañero perfecto de Kamailio. RTPEngine es un media proxy que maneja los streams de audio y video. Kamailio y RTPEngine trabajan en equipo: Kamailio procesa los mensajes SIP y cuando detecta que necesita intervenir en el media, le dice a RTPEngine que se coloque en medio de la llamada. Kamailio modifica los mensajes SIP para que apunten a RTPEngine en lugar de directamente a los endpoints, y RTPEngine se encarga de recibir y reenviar los paquetes RTP.

Esta separación de responsabilidades es genial porque puedes escalar cada componente independientemente. Si necesitas más capacidad de procesamiento de señalización, añades más instancias de Kamailio. Si necesitas más capacidad de media, añades más instancias de RTPEngine. Kamailio puede distribuir las llamadas entre múltiples RTPEngines automáticamente.

La configuración de RTPEngine en Kamailio es relativamente simple. Cargas el módulo rtpengine, le dices dónde están tus instancias de RTPEngine mediante sockets de comunicación, y luego en tu lógica de enrutamiento llamas a funciones como rtpengine_offer y rtpengine_answer cuando procesas los mensajes INVITE y respuestas correspondientes. RTPEngine se encarga del resto mágicamente.

Monitoreo y troubleshooting: cuando las cosas se complican

Incluso con la mejor configuración, las cosas pueden salir mal, y necesitas herramientas para diagnosticar problemas. Kamailio viene con excelentes capacidades de logging y monitoreo que te salvarán la vida más de una vez.

El comando kamctl es tu navaja suiza para administrar Kamailio desde la línea de comandos. Puedes ver estadísticas en tiempo real de cuántas llamadas estás procesando, cuántos usuarios están registrados, el consumo de memoria, y muchísimo más. El comando kamcmd es similar pero usa un protocolo diferente y ofrece aún más opciones de introspección del estado interno del servidor.

Para debugging de mensajes SIP específicos, la herramienta sngrep es absolutamente invaluable. Te muestra todos los mensajes SIP en tiempo real con una interfaz tipo tcpdump pero mucho más amigable, incluyendo diagramas de flujo de llamadas que te ayudan a visualizar exactamente qué está pasando. Ver una llamada completa desde el INVITE inicial hasta el BYE final con todas las respuestas intermedias hace que encontrar problemas sea mil veces más fácil.

Kamailio también puede integrarse con sistemas de monitoreo modernos como Prometheus, Grafana, y InfluxDB mediante módulos específicos. Puedes exportar métricas detalladas y crear dashboards hermosos que muestren el estado de tu infraestructura en tiempo real. Esto es especialmente útil cuando manejas volumen serio y necesitas detectar problemas antes de que afecten a tus usuarios.

El camino del aprendizaje: de dummy a experto

Aprender Kamailio es un viaje, no un sprint. La curva de aprendizaje inicial es empinada porque estás aprendiendo no solo una herramienta sino toda una tecnología que es SIP. Pero la inversión vale absolutamente la pena. Una vez que entiendes Kamailio, entiendes cómo funcionan las telecomunicaciones modernas a un nivel fundamental.

El mejor consejo que puedo darte es empezar simple. Instala Kamailio, carga una configuración básica de ejemplo, registra un par de softphones, haz que se llamen entre sí. No intentes configurar un sistema de producción completo en tu primer día. Experimenta, rompe cosas, arregla lo que rompiste. La documentación oficial es excelente una vez que superas la joroba inicial de entender la terminología.

La comunidad de Kamailio es otra joya. La lista de correo es activa y los desarrolladores principales realmente responden preguntas. Hay conferencias anuales específicas de Kamailio donde puedes aprender de casos de uso reales de empresas que procesan millones de llamadas diarias. Los blogs y tutoriales están por todas partes, aunque algunos están desactualizados, así que siempre verifica las fechas.

Libros como "Kamailio 3.1.x" aunque un poco viejos, siguen siendo útiles para entender conceptos fundamentales que no han cambiado. Los webinars y videos de YouTube también abundan, especialmente conferencias de eventos como Kamailio World o AstriCon donde presentan casos de uso avanzados.

Conclusión: el poder en tus manos

Kamailio no es para todos, seamos honestos. Si solo necesitas una centralita pequeña para tu oficina con diez extensiones, probablemente FreePBX o 3CX sean mejores opciones. Pero si estás construyendo algo serio, algo que necesite escalar, algo donde el rendimiento importa, algo donde necesites control total sobre cada aspecto del comportamiento, entonces Kamailio es tu herramienta.

La belleza de Kamailio es que te da superpoderes. Una vez que lo dominas, puedes construir cualquier cosa que tu imaginación conciba en el mundo VoIP. Un sistema de call center distribuido globalmente, una plataforma de comunicaciones unificadas, un carrier completo de telefonía IP, lo que sea. Las limitaciones no son de la herramienta sino de tu conocimiento y creatividad.

Así que si llegaste hasta aquí leyendo este artículo, ya diste el primer paso. Ahora ve, descarga Kamailio, instálalo, juega con él, rómpelo, arréglalo, y eventualmente lo dominarás. Y cuando lo hagas, estarás en una liga muy selecta de personas que realmente entienden cómo funciona la telefonía moderna a nivel profundo. Bienvenido al club de Kamailio, donde los dummies se convierten en expertos una línea de configuración a la vez.
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo
Andrea Sannucci FreePBX: La PBX "Gratuita" Más Cara que Pagarás en Tu Vida
O cómo convertir algo simple en un infierno de clics y frustraciones

Seamos honestos: FreePBX es la prueba viviente de que "gratuito" y "open source" no siempre significan "bueno". Es como ese primo que te ofrece arreglarte el coche gratis y terminas sin frenos y con el motor haciendo ruidos extraños. Sí, no pagaste dinero, pero ahora tienes que lidiar con las consecuencias.

Después de años trabajando con sistemas de telefonía, he llegado a una conclusión irrefutable: FreePBX es la PBX más inútil y user-unfriendly del mercado, y aquí te explicaré por qué deberías correr en la dirección opuesta cuando alguien te sugiera implementarla.

La mentira del "Free" en FreePBX

Llamarse "FreePBX" es la broma más grande de la industria. Seguro, el software base es gratuito, pero ahí termina la fiesta:

¿Quieres funciones básicas que cualquier PBX del siglo XXI debería tener?
Paga por módulos comerciales.

¿Necesitas soporte porque la documentación es un desastre?
Paga por una suscripción.

¿Quieres actualizaciones sin romper tu sistema?
Reza a todos los dioses conocidos y desconocidos, porque ni pagando te salvas.

Es como descargar un videojuego "gratis" que te cobra por cada arma, cada nivel y cada respawn. Técnicamente es gratis, pero en la práctica es una pesadilla económica disfrazada de altruismo open source.

La interfaz web: cuando el diseño UI/UX se va de vacaciones permanentes

Hablemos de esa interfaz gráfica que parece diseñada por un comité de personas que nunca han usado una computadora. La GUI de FreePBX es un monumento a la confusión y al desperdicio de tiempo.

El menú lateral infinito del terror

Navegar por FreePBX es como buscar algo en una bodega abandonada donde alguien organizó las cosas estando ebrio:

Applications (¿aplicaciones? ¿en serio?)

Connectivity (ah, porque conectividad no es aplicación)

Admin (que también tiene configuraciones que deberían estar en Settings)

Settings (que tiene cosas administrativas)

Reports (que nadie usa porque son incomprensibles)

Y 47 categorías más que se solapan entre sí

¿Quieres crear una extensión? Fácil: Applications > Extensions. Pero espera, ¿quieres configurar el contexto de esa extensión? Eso está en Connectivity > Trunks... no, perdón, en Admin > Config Edit... ah no, en Settings > Asterisk SIP Settings... ¡Ja! Te engañé, realmente está escondido en un lugar completamente aleatorio que descubrirás después de 3 horas de frustración.

El botón "Apply Config" o el enemigo de la productividad

Cada. Maldito. Cambio. Requiere. Un. Apply Config.

Cambiaste una extensión: Apply Config.
Agregaste una ruta: Apply Config.
Respiraste cerca del servidor: Apply Config.

Y si tienes 50 extensiones y necesitas cambiar algo en cada una, prepárate para hacer clic 50 veces en "Submit" y luego 1 vez en "Apply Config" que tardará entre 5 segundos y la eternidad, dependiendo del humor del servidor.

Es el 2025, existen APIs REST, configuraciones atómicas, hot-reload... pero no, FreePBX decidió quedarse en 2005 donde cada cambio requiere regenerar 47 archivos XML y reiniciar medio sistema.

La documentación: un chiste de mal gusto

La documentación oficial de FreePBX es la demostración perfecta de que puedes escribir miles de páginas sin decir absolutamente nada útil.

Buscar cómo hacer algo específico en FreePBX es como:

Googlear el problema → Encuentras un post del foro de 2014

Leer 37 respuestas → 30 son "yo también tengo ese problema"

Encontrar LA respuesta → Es un video de YouTube de 2016 en 480p con audio de micrófono de $2

Seguir el video → Ya no funciona porque FreePBX cambió toda la interfaz en la versión 14

Repetir → Vuelta a Google

La Wiki oficial está llena de páginas que dicen "This page is under construction" desde 2012. Los ejemplos de configuración están incompletos. Los comandos CLI están desactualizados. Y cuando finalmente encuentras algo útil, es para CentOS 6, y tú estás en Rocky Linux 9.

El sistema de módulos: dependencias del infierno

FreePBX usa un sistema de módulos que hace que npm parezca estable y predecible. Instalar o actualizar un módulo es como jugar a la ruleta rusa:

Escenario 1: El módulo se instala perfectamente → Probabilidad: 15%

Escenario 2: El módulo depende de otros 12 módulos que debes instalar manualmente → Probabilidad: 40%

Escenario 3: El módulo rompe algo completamente no relacionado → Probabilidad: 30%

Escenario 4: FreePBX entra en un loop de muerte y tienes que reconstruir todo desde consola → Probabilidad: 15%

Y lo mejor: algunos módulos "gratuitos" desaparecen misteriosamente y reaparecen como módulos comerciales en la siguiente versión. Es el truco de magia más impresionante del mundo del software: hacer que tus funciones básicas se evaporen y luego vendértelas de vuelta.

La "integración" con Asterisk: una relación tóxica

FreePBX es básicamente una GUI que genera archivos de configuración para Asterisk. El problema es que lo hace tan mal que terminas con:

Archivos de configuración generados automáticamente que no puedes editar manualmente (porque FreePBX los sobrescribe)

Configuraciones divididas en 17 archivos diferentes con includes que incluyen includes

Un dialplan generado dinámicamente que parece código ofuscado de C++

Contextos con nombres como from-internal-xfer-00000001 que nadie entiende

Si sabes usar Asterisk directamente, FreePBX no te simplifica la vida: te la complica. Es como pedirle a alguien que traduzca tus conversaciones del español al español pero usando sinónimos aleatorios y cambiando el orden de las palabras.

Y cuando algo falla, ¿debug en FreePBX? Buena suerte. El CLI de Asterisk te da mil veces más información útil que cualquier log de FreePBX.

El rendimiento: lento como tortuga en arena movediza

FreePBX es pesado. Irrazonablemente pesado para lo que hace.

Una instalación "básica" de FreePBX consume:

MySQL/MariaDB: Porque obvio necesitas una base de datos completa para almacenar 10 extensiones

Apache/Nginx: Un servidor web completo corriendo 24/7

PHP: Con todos sus módulos y dependencias

Asterisk: El único componente que realmente necesitas

Node.js: Para algunas funcionalidades modernas (sí, en serio)

Todo esto para hacer lo que un Asterisk configurado manualmente haría usando 1/10 de los recursos.

En un servidor moderno con 4GB de RAM, FreePBX ya está usando 2GB antes de manejar una sola llamada. Es la dieta del elefante aplicada a software: maximiza el consumo de recursos mientras minimiza la funcionalidad.

La actualización: ruleta rusa con todas las cámaras cargadas

Actualizar FreePBX es una aventura que solo los valientes (o los ingenuos) se atreven a emprender.

El proceso típico:

Hacer backup (porque lo vas a necesitar)

Correr el update script

Ver cómo 23 módulos fallan al actualizarse

Intentar arreglarlo manualmente

Romper algo más en el proceso

Restaurar el backup

Decidir que "si funciona, no lo toques"

Vivir con vulnerabilidades de seguridad porque actualizar es peor

Las versiones "estables" de FreePBX tienen más bugs que un motel barato. Y cuando reportas un bug, la respuesta del foro es: "upgrade to the latest version" (que tiene 10 bugs nuevos diferentes).

La comunidad: entre el culto y el negacionismo

La comunidad de FreePBX se divide en dos grupos:

Grupo 1: Los fanáticos
"FreePBX es perfecto, tú estás haciendo algo mal, RTFM" (aunque el manual esté desactualizado y sea inútil).

Grupo 2: Los honestos
"Sí, FreePBX es horrible, pero ya invertí tanto tiempo aprendiéndolo que no puedo cambiar ahora" (el síndrome del costo hundido aplicado a software).

Cualquier crítica legítima es recibida con hostilidad. Es como criticar la comida en casa de tu suegra: técnicamente tienes razón, pero nadie quiere escucharlo.

Las alternativas que SÍ funcionan

Si todavía no te convenzo y estás considerando FreePBX, aquí están las alternativas que te ahorrarán años de sufrimiento:

1. Asterisk puro (la opción del profesional)

Configura Asterisk directamente. Sí, requiere aprender, pero:

Control total sobre todo

Configuraciones claras y mantenibles

Rendimiento óptimo

Documentación oficial excelente

Sin capas de abstracción innecesarias

2. FusionPBX (la GUI que realmente funciona)

Si necesitas una interfaz web, FusionPBX es infinitamente superior:

Basado en FreeSWITCH (mucho más rápido que Asterisk)

Interfaz intuitiva y moderna

Multi-tenant de verdad

Actualizaciones que no rompen todo

Documentación útil

3. Kamailio + RTPEngine (para los que de verdad saben)

Si manejas volumen serio:

Rendimiento insuperable

Escalabilidad real

Control total

Curva de aprendizaje empinada pero vale la pena

La dura verdad

FreePBX es el equivalente software de un Frankenstein: múltiples partes mal cosidas que técnicamente funcionan pero dan miedo verlas en acción.

Es la PBX que:

Promete simplicidad y entrega complejidad exponencial

Dice ser gratuita pero termina costando más en tiempo y frustración

Presume de user-friendly pero tiene la UX de un manual de VCR de 1987

Vende integración con Asterisk pero termina siendo un obstáculo entre tú y Asterisk

Conclusión: aléjate mientras puedas

Si estás empezando en VoIP, no cometas el error de comenzar con FreePBX. Aprende Asterisk directamente o usa una GUI que realmente funcione. Tu yo del futuro te lo agradecerá.

Si ya estás atrapado con FreePBX en producción, mi más sentido pésame. Empieza a planear tu migración ahora. Cada día que pasa es un día más de sufrimiento innecesario.

FreePBX es la prueba de que en el mundo open source no todo lo que brilla es oro. A veces es solo pirita con una GUI terrible encima.

FreePBX: Because life is too short to spend it clicking "Apply Config".

Disclaimer: Este artículo refleja experiencias reales de frustración acumulada. Si eres fanático de FreePBX y te ofendiste, probablemente es porque sabes que tengo razón pero no quieres admitirlo. Y no, no me vas a convencer en los comentarios de que "solo necesito aprender a usarla mejor".

¿Tienes tus propias historias de terror con FreePBX? ¿O eres de los valientes que la defienden? Los comentarios están abiertos... prepara tus argumentos.
Vota el Articulo:

Promedio: 5 (1 voto)

Evalúa la calidad del articulo
Andrea Sannucci Asterisk en Rocky Linux 9: instalación completa y configuración PJSIP paso a paso
Rocky Linux 9 se ha consolidado como una de las distribuciones enterprise más confiables tras la discontinuación de CentOS, y Asterisk continúa siendo el corazón de innumerables sistemas de telefonía IP alrededor del mundo. En esta guía actualizada para 2025, aprenderás a instalar Asterisk desde el código fuente y configurar PJSIP, el stack SIP moderno que ha reemplazado a chan_sip como la opción recomendada.

Rocky Linux 9 ofrece estabilidad enterprise con soporte extendido hasta 2032, lo que lo hace ideal para sistemas de producción. PJSIP, por su parte, proporciona mejor rendimiento, soporte IPv6 nativo, y una arquitectura más robusta que el antiguo chan_sip. Si estás comenzando un proyecto nuevo en 2025, esta combinación es la elección correcta.

Antes de comenzar, asegúrate de tener:

Un servidor con Rocky Linux 9 (mínimo 2GB RAM, 2 CPU cores)

Acceso root o sudo

Conexión a internet estable

Conocimientos básicos de Linux y línea de comandos

Primero, actualizamos el sistema y habilitamos el repositorio EPEL, que contiene dependencias necesarias:

sudo dnf update -y sudo dnf install epel-release -y sudo dnf config-manager --set-enabled crb sudo sed -i 's/^SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config reboot
Asterisk requiere numerosas librerías y herramientas de compilación. Instalamos todo lo necesario:

sudo dnf install -y gcc gcc-c++ make wget tar bzip2 \
libuuid-devel jansson-devel libxml2-devel sqlite-devel \
libedit-devel openssl-devel ncurses-devel newt-devel \
kernel-devel kernel-headers elfutils-libelf-devel \
libtiff-devel gtk2-devel libsrtp-devel speex-devel \
speexdsp-devel gsm-devel libogg-devel libvorbis-devel \
opus-devel corosync-devel neon-devel \
libical-devel openldap-devel freeradius-devel \
freetds-devel unixODBC-devel mariadb-devel postgresql-devel \
lua-devel patch libtool libtool-ltdl-devel libsamplerate-devel
En 2025, la versión LTS recomendada es Asterisk 20. Descargamos el código fuente desde el sitio oficial:

cd /usr/src sudo wget https://downloads.asterisk.org/pub/telephony/asterisk/asterisk-20-current.tar.gz sudo tar -xvzf asterisk-20-current.tar.gz cd asterisk-20.*
Nota: Verifica siempre la versión más reciente en el sitio oficial de Asterisk.

Ejecutamos el script de instalación de dependencias de Asterisk:

sudo contrib/scripts/install_prereq install
Este script detecta automáticamente Rocky Linux y descarga dependencias adicionales.

Ahora configuramos la compilación:

sudo ./configure --with-jansson-bundled
Usamos las versiones bundled de jansson y pjproject para garantizar compatibilidad total. Esto es especialmente importante para PJSIP.

Seleccionamos los módulos a compilar:

sudo make menuselect
En el menú interactivo:

Revisa que en Codec Translators todo los modulos presentes debajo de la etiqueta External estén selecionados

Asegúrate de que res_pjsip y todos los módulos res_pjsip_* estén seleccionados (en "Resource Modules")

Verifica que chan_pjsip esté habilitado (en "Channel Drivers")

Opcionalmente, desmarca chan_sip si no planeas usarlo (en "Channel Drivers")

En "Core Sound Packages" y "Music On Hold File Packages", selecciona el idioma español y el formato de audio que prefieras (recomendado: WAV o ULAW)

Guarda y sal del menú (botón "Save & Exit" o tecla 'x').

Compilamos e instalamos:

sudo make -j$(nproc) sudo make install sudo make samples sudo dnf -y install chkconfig initscriptssudo make config sudo ldconfig
El proceso de compilación puede tomar entre 10 y 30 minutos dependiendo de tu hardware.

Por seguridad, ejecutamos Asterisk con un usuario sin privilegios:

sudo groupadd asterisk sudo useradd -r -d /var/lib/asterisk -g asterisk asterisk sudo usermod -aG audio,dialout asterisk sudo chown -R asterisk:asterisk /etc/asterisk sudo chown -R asterisk:asterisk /var/{lib,log,spool}/asterisk sudo chown -R asterisk:asterisk /usr/lib/asterisk
Configuramos Asterisk para usar este usuario editando /etc/sysconfig/asterisk:

sudo nano /etc/sysconfig/asterisk
Descomenta y modifica estas líneas:

AST_USER="asterisk" AST_GROUP="asterisk"
También edita /etc/asterisk/asterisk.conf:

sudo nano /etc/asterisk/asterisk.conf
En la sección [options], agrega o modifica:

runuser = asterisk rungroup = asterisk
Rocky Linux 9 usa firewalld por defecto. Abrimos los puertos necesarios para SIP y RTP:

sudo firewall-cmd --permanent --add-port=5060/udp sudo firewall-cmd --permanent --add-port=5060/tcp sudo firewall-cmd --permanent --add-port=10000-20000/udp sudo firewall-cmd --reload
El rango 10000-20000 es para tráfico RTP. Puedes ajustarlo según tus necesidades en /etc/asterisk/rtp.conf.

PJSIP utiliza un archivo de configuración centralizado: /etc/asterisk/pjsip.conf. Vamos a crear una configuración básica funcional.

Primero, respaldamos el archivo de ejemplo:

sudo mv /etc/asterisk/pjsip.conf /etc/asterisk/pjsip.conf.original
Creamos una nueva configuración:

sudo nano /etc/asterisk/pjsip.conf
Contenido básico:

[global] type=global endpoint_identifier_order=ip,username,anonymous [transport-udp] type=transport protocol=udp bind=0.0.0.0:5060 external_media_address=TU_IP_PUBLICA external_signaling_address=TU_IP_PUBLICA local_net=192.168.1.0/24 [transport-tcp] type=transport protocol=tcp bind=0.0.0.0:5060 [basic-endpoint](!) type=endpoint context=from-internal disallow=all allow=ulaw allow=alaw allow=opus direct_media=no rtp_symmetric=yes force_rport=yes rewrite_contact=yes [basic-auth](!) type=auth auth_type=userpass [basic-aor](!) type=aor max_contacts=1 remove_existing=yes ; Extensión 1000 [1000](basic-endpoint) auth=1000 aors=1000 [1000](basic-auth) password=password1000 username=1000 [1000](basic-aor) contact=sip:1000@localhost ; Extensión 1001 [1001](basic-endpoint) auth=1001 aors=1001 [1001](basic-auth) password=password1001 username=1001 [1001](basic-aor) contact=sip:1001@localhost
Importante: Reemplaza TU_IP_PUBLICA con tu IP pública real si el servidor está detrás de NAT, y 192.168.1.0/24 con tu red local.

Entendiendo la configuración PJSIP

PJSIP utiliza un sistema de objetos modular:

transport: Define cómo Asterisk escucha conexiones SIP (UDP, TCP, TLS)

endpoint: Representa un dispositivo o cliente SIP

auth: Maneja la autenticación

aor (Address of Record): Gestiona las ubicaciones de contacto

Las plantillas (con !) permiten reutilizar configuraciones comunes.

Editamos /etc/asterisk/extensions.conf:

sudo nano /etc/asterisk/extensions.conf
Al final del archivo agregamos un contexto básico para llamadas internas:

[from-internal] exten => 1000,1,NoOp(Llamada a extensión 1000) same => n,Dial(PJSIP/1000,20) same => n,Hangup() exten => 1001,1,NoOp(Llamada a extensión 1001) same => n,Dial(PJSIP/1001,20) same => n,Hangup() exten => 100,1,Answer() same => n,Playback(demo-congrats) same => n,Hangup()
La extensión 100 es una prueba simple para verificar que el sistema funciona.

Editamos /etc/asterisk/codecs.conf para optimizar la calidad de audio:

sudo nano /etc/asterisk/codecs.conf
Configuración recomendada de OPUS (añadir al final del archivo):

[opus] type=opus max_playback_rate=48000 packet_loss=10 complexity=10 fec=true
Opus es el codec más moderno y ofrece la mejor calidad/ancho de banda en 2025.

Editamos /etc/asterisk/rtp.conf:

sudo nano /etc/asterisk/rtp.conf
Ajustamos el rango de puertos RTP:

[general] rtpstart=10000 rtpend=20000 strictrtp=yes icesupport=yes
Iniciamos el servicio:

sudo systemctl start asterisk sudo systemctl enable asterisk
Verificamos el estado:

sudo systemctl status asterisk
Conectamos a la consola de Asterisk:

sudo asterisk -rvvv
Verificamos que PJSIP esté cargado:

pjsip show endpoints
Deberías ver las extensiones 1000 y 1001. Para más detalles:

pjsip show endpoint 1000 pjsip list transports
Descarga un softphone compatible con PJSIP como:

Zoiper (Windows, macOS, Linux, móvil)

Linphone (multiplataforma)

MicroSIP (Windows)

Configura una cuenta con estos parámetros:

Usuario: 1000

Contraseña: password1000

Dominio/Servidor: IP_DE_TU_SERVIDOR

Puerto: 5060

Transporte: UDP

Registra el softphone y llama a la extensión 100 para probar el audio.

Los endpoints no se registran

Verifica los logs en tiempo real:

sudo asterisk -rvvv pjsip set logger on
Luego intenta registrar nuevamente y observa los mensajes.

No hay audio en las llamadas

Problema común de NAT. Verifica:

Que external_media_address y external_signaling_address estén configurados correctamente

Que los puertos RTP estén abiertos en el firewall

Que direct_media=no esté configurado en los endpoints

Asterisk no inicia

Revisa los logs:

sudo journalctl -u asterisk -n 50 sudo tail -f /var/log/asterisk/messages
Habilitar logs estructurados

Edita /etc/asterisk/logger.conf:

[logfiles] console => notice,warning,error messages => notice,warning,error full => notice,warning,error,debug,verbose
Configurar fail2ban

Protege tu servidor contra ataques de fuerza bruta:

sudo dnf install fail2ban -y
Crea /etc/fail2ban/jail.local:

[asterisk] enabled = true port = 5060,5061 protocol = udp filter = asterisk logpath = /var/log/asterisk/messages maxretry = 5 bantime = 3600
Reinicia fail2ban:

sudo systemctl restart fail2ban sudo systemctl enable fail2ban
Monitoreo con pjsip

Comandos útiles para monitorear:

# Ver estadísticas de endpoints asterisk -rx "pjsip show endpoints" # Ver llamadas activas asterisk -rx "pjsip show channels" # Ver registros asterisk -rx "pjsip show registrations" # Ver subscripciones asterisk -rx "pjsip show subscriptions"
Ahora tienes un sistema Asterisk funcional con PJSIP en Rocky Linux 9. Algunos temas avanzados para explorar:

Configurar troncales SIP con proveedores VoIP

Implementar IVR (Interactive Voice Response)

Integrar WebRTC para llamadas desde navegador

Configurar colas de llamadas (queues)

Implementar grabación de llamadas

Configurar voicemail con PJSIP

Integración con bases de datos para configuración dinámica

La combinación de Rocky Linux 9 y Asterisk con PJSIP representa el estándar moderno para sistemas de telefonía IP empresarial en 2025. Esta configuración te proporciona una base sólida y escalable para construir soluciones de comunicación robustas.

PJSIP ofrece ventajas significativas sobre chan_sip: mejor rendimiento, arquitectura más limpia, soporte IPv6 nativo, y manejo superior de NAT. Si estás migrando desde chan_sip, vale la pena el esfuerzo de aprender esta nueva configuración.

Recuerda mantener tu sistema actualizado, implementar medidas de seguridad apropiadas, y monitorear regularmente el rendimiento de tu PBX. ¡Buena suerte con tu implementación de Asterisk!

Creado por CLAUDE, certificado por Andrea
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo
Andrea Sannucci Kamailio vs FreeSWITCH: cuándo elegir uno u otro
La elección entre Kamailio y FreeSWITCH es una de las decisiones más importantes al diseñar una infraestructura VoIP, y la respuesta correcta depende fundamentalmente de lo que necesitas construir. Ambas son soluciones de código abierto maduras y probadas en producción, pero están diseñadas para resolver problemas completamente diferentes en el ecosistema de comunicaciones.

Kamailio es esencialmente un servidor SIP puro, un proxy extremadamente rápido y eficiente cuya única misión es enrutar señalización SIP. No maneja medios de audio o video directamente, no tiene capacidades de PBX integradas, no puede reproducir música en espera ni grabar llamadas por sí solo. Lo que sí hace, y lo hace mejor que casi cualquier otra solución, es procesar miles de mensajes SIP por segundo con un consumo mínimo de recursos. Su arquitectura basada en workers y su modelo de procesamiento asíncrono le permiten manejar más de 10,000 llamadas simultáneas en hardware modesto. La configuración de Kamailio se realiza a través de un lenguaje de scripting propio que puede parecer intimidante al principio, pero que ofrece un control granular sobre cada aspecto del procesamiento SIP. Puedes interceptar cualquier mensaje, modificar headers, tomar decisiones de enrutamiento basadas en prácticamente cualquier criterio, implementar lógica de negocio compleja, y todo esto sin reiniciar el servicio. Esta flexibilidad tiene un precio en complejidad, necesitas entender profundamente el protocolo SIP para sacar el máximo provecho.

FreeSWITCH, por otro lado, es una solución completa de comunicaciones unificadas. Es un softswitch que no solo maneja señalización sino que procesa medios, actúa como B2BUA, puede funcionar como PBX completo, soporta conferencias, IVR, grabación, transcoding entre diferentes códecs, y muchísimas otras funcionalidades. Su arquitectura modular permite cargar solo los componentes que necesitas, pero incluso en configuraciones mínimas consume significativamente más recursos que Kamailio porque está haciendo mucho más trabajo. FreeSWITCH puede manejar llamadas de extremo a extremo de forma autónoma, lo que significa que puede ser tu única pieza de infraestructura si estás construyendo un sistema de comunicaciones completo. Se configura principalmente a través de XML, lo cual resulta más accesible para muchos administradores, y su dialplan permite implementar lógica de enrutamiento de llamadas de manera intuitiva.

En términos de rendimiento y escalabilidad, las diferencias son dramáticas. Kamailio puede ejecutarse cómodamente en una instancia con 2GB de RAM y manejar decenas de miles de sesiones concurrentes porque solo está procesando señalización. Un servidor Kamailio bien optimizado puede alcanzar tasas de procesamiento de 5,000 a 10,000 llamadas por segundo en hardware commodity. FreeSWITCH, al estar procesando medios y realizando transcoding, necesita recursos sustancialmente mayores, especialmente CPU para el procesamiento de audio y RAM para mantener las sesiones de media. Una instancia típica de FreeSWITCH podría requerir 8GB de RAM o más para manejar mil llamadas concurrentes con transcoding activo. La diferencia fundamental es que Kamailio escala horizontalmente de forma casi lineal, puedes agregar más servidores Kamailio detrás de un balanceador y tu capacidad crece proporcionalmente. FreeSWITCH también escala horizontalmente pero con más complejidad porque necesitas coordinar el estado de las sesiones de media entre instancias.

El enfoque de seguridad presenta contrastes importantes. Kamailio te da todas las herramientas pero tú debes construir la fortaleza. Soporta TLS para cifrado de señalización, puede integrar autenticación contra bases de datos, LDAP, RADIUS, implementar listas negras dinámicas, detectar patrones de fraude en tiempo real, y mucho más, pero cada una de estas características debe ser explícitamente configurada y probada. El módulo pike permite detectar floods de mensajes SIP, el módulo htable facilita implementar limitación de tasa, y con un script bien diseñado puedes crear un sistema de defensa multicapa contra ataques. Sin embargo, la responsabilidad recae completamente en el administrador. FreeSWITCH incluye mecanismos de seguridad más integrados desde el inicio, con ACLs configurables de forma sencilla, soporte para autenticación de usuarios, capacidades de fail2ban integradas, y perfiles de seguridad predefinidos que funcionan bien para la mayoría de casos. Su modelo de B2BUA también ofrece una capa adicional de aislamiento entre las patas de la llamada. Para ambas soluciones, el uso de fail2ban, firewall correctamente configurado, y monitoreo activo son fundamentales.

El enrutamiento de llamadas revela la verdadera naturaleza de cada plataforma. En Kamailio, el enrutamiento es programación pura, escribes lógica imperativa que examina cada mensaje SIP y decide qué hacer con él. Puedes implementar enrutamiento basado en prefijos numéricos, distribución de carga entre múltiples destinos, failover automático, reescritura de URIs, manipulación de headers, inserción de información de enrutamiento en Record-Route, y básicamente cualquier cosa que puedas imaginar. El módulo dispatcher permite distribuir llamadas entre múltiples destinos usando diferentes algoritmos, round-robin, hash, weight-based, y puede detectar destinos caídos automáticamente. El módulo carrierroute facilita implementar enrutamiento LCR basado en tablas de tarifas. La complejidad aquí es que debes pensar en términos de transacciones SIP, diálogos, y estados, no en términos de llamadas telefónicas. FreeSWITCH piensa en llamadas, su dialplan te permite definir patrones de dígitos marcados y asociarles acciones de forma declarativa. Quieres que todas las llamadas a números que empiezan con 1800 vayan a un gateway específico, defines una condición y una acción. Necesitas implementar un IVR antes de enrutar, agregas las aplicaciones correspondientes en el dialplan. Es mucho más intuitivo para alguien que viene del mundo de las telecomunicaciones tradicionales pero menos flexible que el enfoque de Kamailio cuando necesitas lógica verdaderamente compleja.

El monitoreo y troubleshooting tienen filosofías diferentes. Kamailio expone métricas detalladas a través de varios mecanismos, el módulo statistics genera contadores internos accesibles vía kamctl o SNMP, el módulo jsonrpcs permite consultar estado en tiempo real vía HTTP, y puedes integrar fácilmente con Prometheus para observabilidad moderna. El troubleshooting se realiza principalmente capturando tráfico SIP con herramientas como sngrep o mediante el logging extensivo que puedes configurar en el script. Kamailio puede registrar cada decisión de enrutamiento, cada modificación de mensaje, cada lookup en base de datos, pero debes decidir qué quieres ver y configurarlo explícitamente. FreeSWITCH tiene una consola interactiva extremadamente poderosa que permite ver el estado del sistema en tiempo real, activar debugging granular por módulo, por sesión de llamada, incluso por UUID específico. Puedes ver el flujo de una llamada desde el inicio hasta el fin con todos los eventos intermedios. Su sistema de logging es más estructurado y los mensajes suelen ser más autodescriptivos. Para monitoreo de producción, FreeSWITCH expone su estado vía Event Socket Library, un mecanismo que permite aplicaciones externas subscribirse a eventos en tiempo real y tomar acciones.

El ecosistema y la comunidad también difieren. Kamailio tiene una comunidad técnicamente sofisticada, la documentación oficial es extensa pero asume conocimiento sólido de SIP. Encontrarás ejemplos de configuraciones complejas, módulos para casi cualquier caso de uso, y una lista de correo muy activa donde los desarrolladores principales participan regularmente. La curva de aprendizaje es pronunciada pero una vez que la superas, la potencia es inmensa. FreeSWITCH tiene una comunidad más amplia y diversa, con más recursos para principiantes, tutoriales paso a paso, y ejemplos de configuraciones completas. La documentación en la wiki es exhaustiva y cubre desde conceptos básicos hasta integraciones avanzadas. Hay más proveedores ofreciendo soporte comercial y soluciones preempaquetadas basadas en FreeSWITCH.

La integración con otros componentes del stack VoIP es donde la estrategia de diseño importa. Kamailio se diseñó para trabajar en conjunto con otros componentes especializados, típicamente lo combinarás con RTPEngine o RTPProxy para manejar medios, con Asterisk o FreeSWITCH mismo para funcionalidades de PBX, con bases de datos para persistencia, con Redis para datos de sesión compartidos. Esta arquitectura distribuida te permite escalar cada componente independientemente según tus cuellos de botella específicos. Si tu limitante es el procesamiento de señalización, escalas Kamailio. Si es el procesamiento de medios, escalas RTPEngine. FreeSWITCH puede hacer todo en un solo lugar, lo cual simplifica la arquitectura inicial pero puede crear puntos únicos de fallo y limita tu flexibilidad de escalamiento. Muchas arquitecturas modernas usan Kamailio como edge proxy y balanceador delante de un clúster de FreeSWITCH backends, obteniendo lo mejor de ambos mundos.

El costo de operación y mantenimiento merece consideración. Kamailio requiere menos hardware pero más expertise. Un ingeniero que domina Kamailio es un activo valioso pero también un riesgo de concentración de conocimiento. Los cambios en la configuración requieren entender bien qué estás modificando porque un error en el script puede afectar el procesamiento de todas las llamadas. FreeSWITCH es más amigable para equipos con menos especialización profunda en SIP, los cambios son generalmente más seguros y predecibles, y hay más gente en el mercado con experiencia básica en FreeSWITCH. Sin embargo, cuando algo sale mal en FreeSWITCH, especialmente en el procesamiento de medios, el debugging puede ser complejo porque hay muchas capas involucradas.

La decisión final debe basarse en tu caso de uso específico. Si estás construyendo una plataforma carrier-grade que debe manejar volúmenes masivos de tráfico SIP, donde tu negocio es enrutar llamadas entre diferentes proveedores, donde necesitas máxima flexibilidad en el procesamiento de señalización y la eficiencia de recursos es crítica, Kamailio es probablemente tu mejor opción. Si estás implementando un sistema de comunicaciones unificadas para una empresa, necesitas funcionalidades de PBX, IVR, conferencias, quieres una solución que pueda hacer todo out-of-the-box, y prefieres simplicidad operacional sobre máxima eficiencia, FreeSWITCH es más apropiado. Muchas arquitecturas de producción usan ambos, Kamailio en el edge manejando la señalización de clientes, balanceando carga, proveyendo seguridad, y FreeSWITCH en el backend proveyendo servicios de media y funcionalidades avanzadas. Esta combinación te da escalabilidad masiva de Kamailio con las capacidades ricas de FreeSWITCH.

No existe una respuesta universal, ambas herramientas son excelentes en lo que hacen. La pregunta no es cuál es mejor, sino cuál resuelve mejor tu problema específico considerando tu volumen de tráfico, tus requerimientos funcionales, tu equipo técnico, y tu estrategia de crecimiento a largo plazo.
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo
Andrea Sannucci Asterisk en la Nube: Guía Completa 2025
La implementación de Asterisk en entornos cloud se ha convertido en una alternativa cada vez más atractiva para empresas que buscan flexibilidad y escalabilidad en sus sistemas de comunicaciones. Con el lanzamiento de Asterisk 20 LTS en octubre de 2022 y su soporte extendido hasta 2026, contamos con una plataforma madura y robusta que aprovecha al máximo las capacidades del canal PJSIP, el cual ha reemplazado definitivamente al antiguo chan_sip que fue eliminado en esta versión.

La migración hacia arquitecturas cloud no solo representa un cambio de ubicación física de los servidores sino una transformación completa en la manera de diseñar, desplegar y mantener sistemas de telefonía IP. Asterisk 20 viene optimizado para estos escenarios con mejoras significativas en el manejo de conexiones remotas, NAT traversal y codecs de alta eficiencia como Opus que reduce considerablemente el consumo de ancho de banda sin sacrificar calidad de audio.

Preparando el Entorno Cloud

Antes de lanzarnos a la instalación necesitamos seleccionar el proveedor cloud adecuado. Amazon AWS, Google Cloud Platform, Microsoft Azure y DigitalOcean son opciones populares que ofrecen diferentes ventajas. Para un deployment típico de Asterisk recomiendo una instancia con al menos 2 vCPUs y 4GB de RAM aunque esto variará según el volumen de llamadas concurrentes esperado. Un servidor con estas características puede manejar cómodamente entre 50 y 100 llamadas simultáneas dependiendo de los codecs utilizados y la complejidad del dialplan.

La elección del sistema operativo es crucial y para Asterisk 20 las distribuciones más recomendadas son Ubuntu 22.04 LTS o Debian 12 que ofrecen soporte de largo plazo y excelente compatibilidad con las dependencias necesarias. Rocky Linux 9 o AlmaLinux 9 son alternativas sólidas si prefieres el ecosistema Red Hat. Personalmente trabajo mucho con AlmaLinux por su estabilidad en entornos de producción aunque Ubuntu facilita más la instalación de paquetes adicionales.

Una vez seleccionada la instancia el primer paso es asegurar el sistema operativo. Configurar el firewall es absolutamente crítico porque expondrás puertos RTP y SIP directamente a internet. Con UFW en Ubuntu o firewalld en sistemas basados en Red Hat debes permitir únicamente los puertos necesarios: 5060 UDP para SIP, 5061 TCP para SIP sobre TLS y el rango 10000-20000 UDP para RTP. Nunca abras rangos de puertos más amplios de los necesarios porque te expones a ataques de flooding y escaneos maliciosos.

Instalación de Asterisk 20

La instalación desde código fuente nos da control total sobre los módulos compilados y optimizaciones específicas para nuestro hardware. Primero instalamos las dependencias necesarias que en Ubuntu serían algo como apt-get install build-essential libssl-dev libncurses-dev libnewt-dev libxml2-dev libsqlite3-dev uuid-dev libjansson-dev y luego descargamos el tarball desde el sitio oficial de Asterisk.

El proceso de compilación comienza con el script configure que detecta las librerías disponibles en el sistema. Aquí es importante ejecutar contrib/scripts/install_prereq install para asegurarnos de tener todas las dependencias. Luego con make menuselect accedemos a una interfaz que permite seleccionar exactamente qué módulos queremos compilar. Para un deployment cloud enfocado en PJSIP debemos asegurarnos de incluir res_pjsip y todos sus módulos relacionados como res_pjsip_endpoint_identifier_ip, res_pjsip_outbound_registration y res_pjsip_nat.

Un aspecto que muchos pasan por alto es la optimización del compilador. Si agregas CFLAGS como -march=native -O3 durante el configure puedes obtener mejoras de rendimiento del 10 al 15 por ciento aunque esto hace que el binario resultante solo funcione en CPUs similares a donde fue compilado. En cloud esto generalmente no es problema porque conoces exactamente el hardware subyacente de tu proveedor.

Configuración de PJSIP

El canal PJSIP representa una evolución completa respecto a chan_sip con mejor manejo de NAT, soporte nativo para múltiples transports en paralelo y una arquitectura modular mucho más limpia. La configuración se centraliza en pjsip.conf aunque también puedes usar archivos separados con la directiva include.

Empecemos con la configuración de transport que define cómo Asterisk escuchará las conexiones SIP. Un transport básico UDP se vería así:

[transport-udp] type=transport protocol=udp bind=0.0.0.0:5060 external_media_address=TU_IP_PUBLICA external_signaling_address=TU_IP_PUBLICA local_net=10.0.0.0/8 local_net=172.16.0.0/12 local_net=192.168.0.0/16
Las directivas external_media_address y external_signaling_address son fundamentales en cloud porque permiten que Asterisk anuncie correctamente su IP pública en los mensajes SIP mientras escucha en su IP privada interna. El parámetro local_net indica qué redes considera locales para aplicar las transformaciones NAT necesarias.

Para endpoints que se conectan desde internet como softphones móviles o teléfonos remotos necesitas configurar cada uno con su propia sección. Un ejemplo completo sería:

[6001] type=endpoint context=from-internal disallow=all allow=opus allow=g722 allow=ulaw auth=6001 aors=6001 direct_media=no rtp_symmetric=yes force_rport=yes rewrite_contact=yes ice_support=yes [6001] type=auth auth_type=userpass password=TuPasswordSeguro123 username=6001 [6001] type=aor max_contacts=3 remove_existing=yes qualify_frequency=60
La sección endpoint define las características del dispositivo permitiendo los codecs Opus G722 y ulaw en orden de preferencia. El parámetro direct_media=no fuerza que todo el audio RTP pase por Asterisk en lugar de establecer conexión directa entre endpoints lo cual es necesario cuando tienes NAT de por medio. Las opciones rtp_symmetric force_rport y rewrite_contact trabajan juntas para manejar correctamente el NAT reescribiendo direcciones según sea necesario.

La sección auth maneja la autenticación SIP digest y la sección aor o Address of Record mantiene el registro de dónde contactar al endpoint. El parámetro max_contacts=3 permite que el mismo usuario registre hasta tres dispositivos simultáneamente útil para quien tiene softphone en móvil PC y teléfono de escritorio. El qualify_frequency envía OPTIONS cada 60 segundos para verificar que el endpoint sigue accesible.

Configuración de Trunks SIP

Conectar Asterisk con proveedores de telefonía o carriers requiere configuración específica de trunks. La mayoría de proveedores modernos soportan autenticación por IP eliminando la necesidad de usuario y contraseña. Un trunk típico basado en IP se configuraría así:

[trunk-proveedor] type=endpoint context=from-trunk disallow=all allow=ulaw allow=alaw aors=trunk-proveedor outbound_auth=trunk-proveedor from_domain=sip.tuproveedor.com [trunk-proveedor] type=aor contact=sip:sip.tuproveedor.com:5060 [trunk-proveedor] type=auth auth_type=userpass username=tucuenta password=tupassword [trunk-proveedor] type=identify endpoint=trunk-proveedor match=IP_DEL_PROVEEDOR
La sección identify permite que llamadas entrantes desde la IP del proveedor se asocien automáticamente con este endpoint sin necesidad de autenticación adicional. Esto es importante porque muchos carriers envían llamadas desde IPs diferentes a las que usas para originar.

Para trunks que requieren registro activo necesitas agregar una sección registration:

[trunk-proveedor] type=registration outbound_auth=trunk-proveedor server_uri=sip:sip.tuproveedor.com client_uri=sip:tucuenta@sip.tuproveedor.com retry_interval=60
Esta configuración hace que Asterisk envíe REGISTER periódicamente manteniendo activo el trunk. El retry_interval define cada cuántos segundos reintenta si el registro falla.

Dialplan y Enrutamiento

El dialplan en extensions.conf es donde defines la lógica de llamadas. Para un sistema cloud típico con extensiones internas y salida a PSTN podrías estructurarlo así:

[from-internal] exten => _6XXX,1,NoOp(Llamada interna a ${EXTEN}) same => n,Dial(PJSIP/${EXTEN},30) same => n,Hangup() exten => _9NXXNXXXXXX,1,NoOp(Llamada saliente a ${EXTEN:1}) same => n,Set(CALLERID(num)=TUNUMERO) same => n,Dial(PJSIP/${EXTEN:1}@trunk-proveedor) same => n,Hangup() [from-trunk] exten => _TUNUMERO,1,NoOp(Llamada entrante para ${EXTEN}) same => n,Dial(PJSIP/6001&PJSIP/6002,30) same => n,VoiceMail(6001@default,u) same => n,Hangup()
Este dialplan maneja tres escenarios: llamadas entre extensiones 6XXX marcan directamente a través de PJSIP, llamadas salientes que empiezan con 9 se enrutan al trunk removiendo el prefijo y llamadas entrantes que llegan desde el trunk hacen ring simultáneo en dos extensiones antes de ir a voicemail.

Para implementar IVR o menús interactivos puedes usar la aplicación Background que reproduce audio mientras espera entrada DTMF:

[from-trunk] exten => _TUNUMERO,1,NoOp(Llamada entrante) same => n,Answer() same => n,Background(bienvenida) same => n,WaitExten(5) exten => 1,1,Dial(PJSIP/6001,30) same => n,VoiceMail(6001@default,u) exten => 2,1,Dial(PJSIP/6002,30) same => n,VoiceMail(6002@default,u) exten => i,1,Playback(opcion-invalida) same => n,Goto(from-trunk,TUNUMERO,2) exten => t,1,Playback(no-respuesta) same => n,Hangup()
Seguridad y Hardening

Un Asterisk expuesto a internet requiere medidas de seguridad estrictas. Fail2ban es absolutamente esencial para bloquear IPs que intentan ataques de fuerza bruta. Configura un filtro específico para Asterisk que detecte intentos de autenticación fallidos en los logs:

[asterisk] enabled = true port = 5060,5061 protocol = all filter = asterisk logpath = /var/log/asterisk/security.log maxretry = 3 bantime = 86400
En el archivo de filtro defines patrones regex que detectan líneas de log específicas indicando intentos fallidos. Con maxretry=3 bloqueas la IP después de tres intentos en el período findtime.

Dentro de Asterisk mismo activa el módulo res_security_log que registra eventos de seguridad relevantes en un log separado facilitando el monitoreo. En modules.conf asegúrate de tener:

load = res_security_log.so
Y en logger.conf agrega:

security.log => security
El uso de contraseñas fuertes es obvio pero frecuentemente ignorado. Para cada endpoint usa contraseñas de al menos 16 caracteres con combinación de letras números y símbolos. Nunca uses contraseñas basadas en el número de extensión como 6001pass porque son las primeras que prueban los atacantes.

Implementar TLS para cifrar la señalización SIP agrega una capa importante de seguridad especialmente si transmites datos sensibles. Primero generas certificados con OpenSSL o mejor aún usa Let's Encrypt para certificados válidos públicamente. Luego configuras un transport TLS en pjsip.conf:

[transport-tls] type=transport protocol=tls bind=0.0.0.0:5061 cert_file=/etc/asterisk/keys/asterisk.crt priv_key_file=/etc/asterisk/keys/asterisk.key ca_list_file=/etc/asterisk/keys/ca.crt method=tlsv1_2
Los endpoints que se conecten a este transport deben configurarse para usar transport=transport-tls en su sección endpoint.

Monitoreo y Optimización

En producción necesitas visibilidad constante del estado del sistema. El CLI de Asterisk ofrece comandos útiles como pjsip show endpoints que lista todos los endpoints y su estado de registro, o core show channels para ver llamadas activas en tiempo real. Estos comandos pueden automatizarse con scripts que ejecutan asterisk -rx "comando" y parsean la salida.

Para métricas más profundas el módulo res_statsd permite enviar estadísticas a servidores Grafana o Prometheus. Configuras en statsd.conf:

[general] enabled = yes server = localhost port = 8125 prefix = asterisk
Esto enviará métricas como número de llamadas activas, uso de canales y estadísticas de calidad RTP que puedes visualizar en dashboards personalizados.

La calidad de las llamadas puede monitorearse activando rtcp en los endpoints con rtcp_mux=yes que multiplexa RTCP y RTP en el mismo puerto simplificando NAT. Los reportes RTCP incluyen datos de jitter pérdida de paquetes y latencia accesibles mediante pjsip show channel statistics.

Para optimizar rendimiento ajusta el número de threads que manejan tareas asíncronas en asterisk.conf:

[options] minmemfree = 256 internal_timing = yes cache_media_frames = yes
El parámetro minmemfree indica cuántos MB de RAM libre mantener antes de empezar a liberar cachés. Con cache_media_frames=yes Asterisk reutiliza estructuras de frames de audio reduciendo allocations y mejorando latencia.

Respaldo y Alta Disponibilidad

Un sistema de producción necesita estrategias de respaldo y recuperación. La configuración completa de Asterisk reside principalmente en /etc/asterisk y las grabaciones de voicemail en /var/spool/asterisk. Un script de backup simple podría usar rsync para copiar estos directorios a almacenamiento remoto:

#!/bin/bash BACKUP_DIR="/backup/asterisk-$(date +%Y%m%d)" mkdir -p $BACKUP_DIR rsync -av /etc/asterisk/ $BACKUP_DIR/etc/ rsync -av /var/spool/asterisk/ $BACKUP_DIR/spool/ tar -czf $BACKUP_DIR.tar.gz $BACKUP_DIR rm -rf $BACKUP_DIR
Ejecutado diariamente mediante cron mantiene copias comprimidas de la configuración. Para alta disponibilidad puedes implementar un cluster activo-pasivo donde dos servidores Asterisk comparten una IP virtual mediante keepalived o Pacemaker. El servidor pasivo monitorea el activo y asume la IP si detecta falla.

Una alternativa más sofisticada usa Kamailio como balanceador SIP delante de múltiples instancias Asterisk distribuyendo carga entre ellas. Kamailio maneja el registro de endpoints y enruta llamadas al Asterisk con menos carga o siguiente disponible si uno falla.

Integración con WebRTC

Asterisk 20 con PJSIP ofrece soporte robusto para WebRTC permitiendo que navegadores web se comuniquen directamente sin plugins. Configuras un transport específico para WebRTC:

[transport-wss] type=transport protocol=wss bind=0.0.0.0:8089 cert_file=/etc/asterisk/keys/asterisk.crt priv_key_file=/etc/asterisk/keys/asterisk.key
Los endpoints WebRTC requieren configuración especial habilitando codecs compatibles y protocolos de cifrado:

[webrtc-6001] type=endpoint context=from-internal disallow=all allow=opus allow=vp8 auth=webrtc-6001 aors=webrtc-6001 webrtc=yes transport=transport-wss use_avpf=yes media_encryption=dtls dtls_cert_file=/etc/asterisk/keys/asterisk.crt dtls_private_key=/etc/asterisk/keys/asterisk.key dtls_setup=actpass
El parámetro webrtc=yes activa automáticamente varios ajustes necesarios como uso de ICE para NAT traversal y habilitación de RTCP feedback. Con media_encryption=dtls el audio se cifra end-to-end usando DTLS-SRTP.

Para que clientes web se conecten necesitas implementar un servidor WebSocket que traduzca entre HTTP/WebSocket y SIP nativo. Librerías como JsSIP en JavaScript facilitan esto enormemente manejando la complejidad del protocolo SIP desde el navegador.

Casos de Uso Avanzados

En escenarios empresariales complejos Asterisk 20 puede integrarse con CRMs y sistemas de tickets mediante AMI o Asterisk Management Interface. AMI permite control externo completo de Asterisk pudiendo originar llamadas monitorear eventos y modificar configuración en tiempo real. Un script Python usando la librería Panoramisk puede suscribirse a eventos de llamada y actualizar registros CRM automáticamente.

La grabación selectiva de llamadas implementada mediante MixMonitor en el dialplan permite cumplir requerimientos de compliance grabando solo llamadas específicas según criterios como destino origen o extensión:

exten => _9NXXNXXXXXX,1,NoOp(Llamada saliente) same => n,Set(CALLFILE=/var/spool/asterisk/monitor/${UNIQUEID}.wav) same => n,MixMonitor(${CALLFILE},b) same => n,Dial(PJSIP/${EXTEN:1}@trunk-proveedor)
Para contact centers implementa colas de llamadas con queue.conf asignando agentes dinámicamente y distribuyendo llamadas según estrategias como ringall leastrecent o random. Las métricas de cola accesibles vía AMI alimentan dashboards en tiempo real mostrando llamadas esperando tiempo promedio de espera y estado de agentes.

La implementación de Asterisk en cloud representa una solución madura y escalable que con la versión 20 y el canal PJSIP ofrece todas las capacidades necesarias para sistemas empresariales modernos. La flexibilidad de deployment la reducción de costos de hardware y la facilidad de escalamiento hacen que cada vez más organizaciones migren sus comunicaciones a arquitecturas cloud basadas en esta plataforma probada y confiable.
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

Andrea Sannucci Cómo proteger un servidor Kamailio en Rocky Linux 9 en menos de 15 minutos

La seguridad en servidores VoIP es crítica. Un servidor SIP expuesto sin protección adecuada puede convertirse en objetivo de ataques de fraude telefónico, escaneos masivos y consumo fraudulento de recursos en cuestión de horas. En este artículo te mostraré cómo implementar medidas de seguridad esenciales en Rocky Linux 9 que puedes configurar en menos de 15 minutos.

Los servidores SIP son constantemente escaneados por bots que buscan vulnerabilidades. Un ataque exitoso puede resultar en:

Llamadas internacionales fraudulentas que generan miles de dólares en costos
Consumo de ancho de banda y recursos del servidor
Compromiso de la privacidad de las comunicaciones
Daño a la reputación de tu servicio

Requisitos previos

Antes de comenzar, asegúrate de tener:

Rocky Linux 9 instalado y actualizado
Acceso root o sudo al servidor
Kamailio u otro servidor SIP instalado
Puertos básicos identificados (típicamente 5060 UDP/TCP para SIP, 16384-32768 UDP para RTP)

Paso 1: Actualizar el sistema (2 minutos)

Siempre comenzamos con un sistema actualizado:

sudo dnf update -y
sudo dnf install -y epel-release

Paso 2: Configurar iptables (3 minutos)

Desactivamos firewalld y usamos iptables directamente para mayor control:

# Detener y deshabilitar firewalld
sudo systemctl stop firewalld
sudo systemctl disable firewalld

# Instalar iptables-services
sudo dnf install -y iptables-services

# Habilitar e iniciar iptables
sudo systemctl enable iptables
sudo systemctl start iptables

# Limpiar reglas existentes
sudo iptables -F
sudo iptables -X
sudo iptables -t nat -F
sudo iptables -t nat -X
sudo iptables -t mangle -F
sudo iptables -t mangle -X

# Política por defecto: denegar todo excepto lo explícitamente permitido
sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT ACCEPT

# Permitir loopback
sudo iptables -A INPUT -i lo -j ACCEPT

# Permitir conexiones establecidas
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Permitir SSH (ajusta el puerto si usas otro)
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# Permitir SIP
sudo iptables -A INPUT -p udp --dport 5060 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 5060 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 5061 -j ACCEPT

# Permitir RTP para media
sudo iptables -A INPUT -p udp --dport 16384:32768 -j ACCEPT

# Si usas RTPEngine en puerto específico
sudo iptables -A INPUT -p udp --dport 22222 -j ACCEPT

# Guardar reglas
sudo service iptables save

Paso 3: Instalar y configurar Fail2ban (4 minutos)

Fail2ban es esencial para bloquear automáticamente IPs que realicen intentos de ataque:

# Instalar Fail2ban
sudo dnf install -y fail2ban fail2ban-firewalld

# Crear configuración local
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Crear filtro específico para Kamailio:

sudo nano /etc/fail2ban/filter.d/kamailio.conf

Agregar el siguiente contenido:

[Definition]
failregex = ^.*\[.*\] NOTICE:.* <HOST>:.* - authentication failure
            ^.*\[.*\] WARNING:.* <HOST> - invalid password
            ^.*\[.*\] WARNING:.* <HOST> - failed to authenticate
ignoreregex =

Configurar la jail para Kamailio:

sudo nano /etc/fail2ban/jail.d/kamailio.local

Contenido:

[kamailio]
enabled = true
port = 5060,5061
protocol = udp
filter = kamailio
logpath = /var/log/kamailio.log
maxretry = 3
bantime = 3600
findtime = 600
action = iptables-allports

Iniciar Fail2ban:

sudo systemctl enable --now fail2ban
sudo systemctl status fail2ban

Paso 4: Implementar rate limiting con iptables (2 minutos)

Agregar reglas para limitar conexiones por IP:

# Crear script de rate limiting
sudo nano /usr/local/bin/voip-rate-limit.sh

Contenido del script:

#!/bin/bash

# Limitar nuevas conexiones SIP por IP
iptables -A INPUT -p udp --dport 5060 -m state --state NEW -m recent --set
iptables -A INPUT -p udp --dport 5060 -m state --state NEW -m recent --update --seconds 60 --hitcount 20 -j DROP

# Limitar INVITE messages
iptables -A INPUT -p udp --dport 5060 -m string --string "INVITE sip:" --algo bm -m recent --set --name INVITE
iptables -A INPUT -p udp --dport 5060 -m string --string "INVITE sip:" --algo bm -m recent --update --seconds 60 --hitcount 10 --name INVITE -j DROP

# Limitar REGISTER messages
iptables -A INPUT -p udp --dport 5060 -m string --string "REGISTER sip:" --algo bm -m recent --set --name REGISTER
iptables -A INPUT -p udp --dport 5060 -m string --string "REGISTER sip:" --algo bm -m recent --update --seconds 60 --hitcount 15 --name REGISTER -j DROP

Hacer ejecutable y aplicar:

sudo chmod +x /usr/local/bin/voip-rate-limit.sh
sudo /usr/local/bin/voip-rate-limit.sh

# Hacer persistente con systemd
sudo nano /etc/systemd/system/voip-rate-limit.service

Contenido del servicio:

[Unit]
Description=VoIP Rate Limiting Rules
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/voip-rate-limit.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Habilitar el servicio:

sudo systemctl daemon-reload
sudo systemctl enable voip-rate-limit.service

Paso 5: Configurar seguridad básica en Kamailio (4 minutos)

Edita tu configuración de Kamailio para incluir validaciones básicas:

sudo nano /etc/kamailio/kamailio.cfg

Agregar en la sección de enrutamiento:

# Anti-scanning: Drop SUBSCRIBE, NOTIFY, PUBLISH
if (method=="SUBSCRIBE" || method=="NOTIFY" || method=="PUBLISH") {
    sl_send_reply("405", "Method Not Allowed");
    exit;
}

# Rechazar métodos no estándar
if (!is_method("INVITE|ACK|BYE|CANCEL|REGISTER|OPTIONS")) {
    sl_send_reply("501", "Not Implemented");
    exit;
}

# Anti-flood: Limitar tamaño de mensajes
if (msg:len > 8192) {
    sl_send_reply("513", "Message Too Large");
    exit;
}

# Validar User-Agent vacío o sospechoso
if ($ua == "" || $ua =~ "friendly-scanner|sipcli|sipvicious") {
    sl_send_reply("403", "Forbidden");
    exit;
}

# Rechazar dominios no autorizados
if (!is_myself("$rd")) {
    sl_send_reply("403", "Relay Not Allowed");
    exit;
}

Reiniciar Kamailio:

sudo systemctl restart kamailio
sudo systemctl status kamailio

Verificación de la configuración

Después de implementar estas medidas, verifica que todo funciona correctamente:

# Verificar reglas de iptables
sudo iptables -L -n -v

# Ver reglas con números de línea
sudo iptables -L INPUT -n -v --line-numbers

# Verificar Fail2ban
sudo fail2ban-client status kamailio

# Ver IPs bloqueadas por Fail2ban
sudo fail2ban-client status kamailio

# Revisar logs de Kamailio
sudo tail -f /var/log/kamailio.log

# Monitorear intentos bloqueados
sudo journalctl -u fail2ban -f

# Ver estadísticas de rate limiting
sudo iptables -L -n -v | grep -A 5 "dport 5060"

Medidas adicionales recomendadas

Aunque las configuraciones anteriores te dan una protección sólida, considera implementar:

1. GeoIP Blocking

Bloquear países desde donde no esperas tráfico legítimo usando iptables con ipset. ipset permite crear listas de IPs que se evalúan eficientemente:

# Instalar ipset
sudo dnf install -y ipset

# Crear un conjunto (set) para almacenar rangos de IP de países bloqueados
sudo ipset create blocked_countries hash:net maxelem 1000000

# Descargar listas de rangos IP por país desde ipdeny.com
# Ejemplo: bloquear China (cn) y Rusia (ru)
cd /tmp
wget http://www.ipdeny.com/ipblocks/data/aggregated/cn-aggregated.zone
wget http://www.ipdeny.com/ipblocks/data/aggregated/ru-aggregated.zone

# Agregar todos los rangos de China al set
while read ip; do
    sudo ipset add blocked_countries $ip
done < cn-aggregated.zone

# Agregar todos los rangos de Rusia al set
while read ip; do
    sudo ipset add blocked_countries $ip
done < ru-aggregated.zone

# Aplicar regla de bloqueo en iptables
# Esta regla verifica si la IP origen está en el set y la bloquea
sudo iptables -I INPUT -p udp --dport 5060 -m set --match-set blocked_countries src -j DROP
sudo iptables -I INPUT -p tcp --dport 5060 -m set --match-set blocked_countries src -j DROP

# Verificar cuántas IPs hay en el set
sudo ipset list blocked_countries | grep "Number of entries"

# Guardar configuración para que persista
sudo service iptables save
sudo ipset save blocked_countries > /etc/sysconfig/ipset.blocked_countries

# Crear script de restauración al inicio
sudo tee /etc/systemd/system/ipset-restore.service > /dev/null <<EOF
[Unit]
Description=Restore ipset rules
Before=iptables.service

[Service]
Type=oneshot
ExecStart=/usr/sbin/ipset restore -f /etc/sysconfig/ipset.blocked_countries
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable ipset-restore.service

Script opcional para actualizar listas automáticamente:

# Crear script de actualización
sudo tee /usr/local/bin/update-geoip-blocks.sh > /dev/null <<'EOF'
#!/bin/bash

COUNTRIES="cn ru"  # Agrega códigos de país separados por espacio
TEMP_DIR="/tmp/geoip"
mkdir -p $TEMP_DIR

# Limpiar set existente
ipset flush blocked_countries 2>/dev/null || ipset create blocked_countries hash:net maxelem 1000000

# Descargar y agregar rangos
for country in $COUNTRIES; do
    wget -q -O $TEMP_DIR/$country.zone http://www.ipdeny.com/ipblocks/data/aggregated/$country-aggregated.zone
    while read ip; do
        ipset add blocked_countries $ip 2>/dev/null
    done < $TEMP_DIR/$country.zone
    echo "Agregados rangos de $country"
done

# Guardar configuración
ipset save blocked_countries > /etc/sysconfig/ipset.blocked_countries
echo "GeoIP blocks actualizados: $(ipset list blocked_countries | grep 'Number of entries')"

# Limpiar
rm -rf $TEMP_DIR
EOF

sudo chmod +x /usr/local/bin/update-geoip-blocks.sh

# Ejecutar ahora
sudo /usr/local/bin/update-geoip-blocks.sh

# Programar actualización mensual
echo "0 3 1 * * root /usr/local/bin/update-geoip-blocks.sh" | sudo tee -a /etc/crontab

Países disponibles para bloquear: Puedes encontrar la lista completa en http://www.ipdeny.com/ipblocks/ Códigos comunes: cn (China), ru (Rusia), in (India), br (Brasil), ua (Ucrania)

2. Autenticación fuerte

Usar contraseñas complejas de al menos 20 caracteres
Implementar autenticación de dos factores cuando sea posible
Rotar credenciales regularmente

3. Monitoreo continuo

Usar herramientas de monitoreo de tráfico SIP:

# Capturar tráfico SIP con tcpdump
sudo tcpdump -i any -n port 5060 -w /tmp/sip_capture.pcap

# Ver tráfico SIP en tiempo real
sudo tcpdump -i any -n port 5060 -A

# Analizar con tshark (Wireshark CLI)
sudo dnf install -y wireshark-cli
sudo tshark -i any -f "port 5060" -Y sip

4. Actualizaciones automáticas de seguridad

sudo dnf install -y dnf-automatic
sudo systemctl enable --now dnf-automatic.timer

5. Encriptación TLS

Configurar TLS para SIP (puerto 5061) y SRTP para media:

listen=tls:your-ip:5061
enable_tls=yes
tls_verify_server=1
tls_verify_client=1
tls_require_client_certificate=0
tls_method=TLSv1.2+
tls_certificate="/etc/kamailio/tls/cert.pem"
tls_private_key="/etc/kamailio/tls/privkey.pem"
tls_ca_list="/etc/kamailio/tls/ca-list.pem"

Checklist final de seguridad

[ ] iptables configurado y activo con política restrictiva
[ ] Fail2ban instalado y monitoreando logs
[ ] Rate limiting con iptables implementado
[ ] Kamailio configurado con validaciones básicas
[ ] Puertos innecesarios cerrados
[ ] Contraseñas fuertes en todas las cuentas SIP
[ ] Logs siendo monitoreados regularmente
[ ] Respaldos configurados
[ ] Actualizaciones automáticas habilitadas
[ ] TLS/SRTP configurado (recomendado)
[ ] Reglas de iptables guardadas y persistentes

Conclusión

Con estos pasos has implementado una capa sólida de protección para tu servidor VoIP SIP en Rocky Linux 9. Estas medidas te protegen contra los ataques más comunes: escaneos automatizados, intentos de fuerza bruta y flood attacks.

Recuerda que la seguridad es un proceso continuo. Revisa tus logs regularmente, mantén el sistema actualizado y ajusta las reglas según los patrones de ataque que observes.

Tiempo total invertido: Aproximadamente 15 minutos para un servidor básico.

Nivel de protección: Alto contra ataques automatizados comunes.

Recursos adicionales

¿Tienes preguntas o sugerencias? Déjame un comentario abajo y con gusto te ayudo a refinar tu configuración de seguridad VoIP.

Vota el Articulo:

November 23, 2025

Juan Oliva IA Pentesting – MCP Kali Linux
Imagina tener herramientas de hacking como nmap, Nikto, SQLMap, searchsploit listas para usar, a través de un agente IA y poder realizar un IA Vulnerability Assessment o IA Pentesting pues esto ya es posible mediante el MCP de Kali Linux.

MCP Kali Server
Es un API en que puede conectar clientes MCP (como Claude Desktop) con el servidor API instalado en Kali Linux, lo que permite ejecutar comandos de terminal de herramientas como nmap, nxc, metasploit, etc. Ademas, herramientas como curl, wget y gobuster para realizar pruebas de penetración asistidas por IA hacia aplicaciones web y/o API.

1.- Instalación de MCP Server
Aquí hay dos alternativas, realizar la instalación usando el paquete en el repositorio git o instalar directamente del gestor de paquetes, personalmente usé este ultimo.
```
sudo apt update
sudo apt install mcp-kali-server
```
La instalación en realidad no tiene problemas, ahora es necesario iniciar el servidor de la siguiente forma:
```
kali-server-mcp
```
2.- Agente IA ( Cliente MCP)
Debido a que existe en la documentación la manera de integrarlo vamos a usar Claude IA, sin embargo existen integraciones hasta con visual studio code.

Instalación
La instalación ya la detallamos en el post : IA Pentesting Metasploit la versión usada a la fecha es Claude 0.14.10 la cual la pueden descargar desde aquí :

https://github.com/aaddrick/claude-desktop-debian/releases/

3.- Configuración del cliente MCP
En la sección de desarrollador de Claude, es necesario agregar el servidor MCP de la siguiente forma :
```
{
    "mcpServers": {
        "kali_mcp": {
            "command": "python3",
            "args": [
                "/usr/share/mcp-kali-server/mcp_server.py",
                "--server",
                "http://192.168.1.83:5000/"
            ]
        }
    }
}
```
Luego cerraremos Claude.

4.- Arreglo del Bug Fix 2665
En el momento de hacer este manual, existe un bug en el MCP de Kali Linux que es necesario corregir, específicamente en el archivo «mcp_server.py» el cual está documentado como issue 2665.

«Unexpected non-whitespace character after JSON at position 4 (line 1 column 5)»

Ingresar al archivo mcp_server.py
```
vim /usr/share/mcp-kali-server/mcp_server.py
```
Cambiar esta declaración de logging

Por esta :

Luego guardar y salir.

5.- Iniciar Agente IA integrado con Kali Linux
Una vez corregida esa parte, iniciamos Claude y si todo salió bien, tendremos el cliente IA conectado con el servidor MCP de Kali Linux como se muestra a continuación.

Ahora le podemos preguntar al agente IA si está conectado al MCP server de Kali Linux de la siguiente forma :

6.- Ejecutando Pentest con el asistente IA Claude y MCP Kali Linux.

IA Pentesting usando MCP KALI LINUX para Vulnerability scan for Windows

iA Pentesting – MCP KALI LINUX , finding XSS Vulnerabilities in Web Application.

Definitivamente el uso de la IA para Pentesting es una nueva generación de mecanismos/procesos para agilizar las actividades de un pentest, sin embargo primero es necesario de capacidad computacional (VM de Kali tenía 8 nucleos y 4 GB de ram), lo segundo, es que si no se conocen las herramientas de pentest en su forma nativa, menos las vas a poder reconocer en una forma mas compleja cuando sea ejecutada y gestionada por una IA.

Espero les sirva :

@jroliva

Referencias :
https://gitlab.com/kalilinux/packages/mcp-kali-server
https://www.kali.org/tools/mcp-kali-server/
https://www.youtube.com/watch?v=X2Al2soEX2s
https://github.com/Wh0am123/MCP-Kali-Server
https://github.com/camel-ai/camel/issues/2665

November 16, 2025

Andrea Sannucci Bloqueo de Países con GeoIP en AlmaLinux 9 usando xtables-addons

En el mundo de la seguridad de servidores y la administración de redes, una de las estrategias más efectivas para reducir ataques y tráfico no deseado es el bloqueo geográfico de IPs. En este artículo te mostraré cómo implementar un sistema de bloqueo basado en GeoIP utilizando xtables-addons en AlmaLinux 9, incluyendo la solución a los problemas de compilación más comunes.

¿Qué es xtables-addons?

Xtables-addons es un conjunto de extensiones para iptables/netfilter que añade funcionalidades adicionales no incluidas en el kernel estándar de Linux. Una de sus características más potentes es el módulo GeoIP, que permite crear reglas de firewall basadas en la ubicación geográfica de las direcciones IP.

Ventajas del bloqueo con GeoIP

Simplicidad: Una sola regla puede bloquear millones de IPs
Eficiencia: Consume menos recursos que grandes listas de ipset
Mantenimiento: Las bases de datos se actualizan fácilmente
Flexibilidad: Permite bloquear o permitir países específicos

Requisitos previos

Antes de comenzar, asegúrate de tener:

AlmaLinux 9 instalado y actualizado
Acceso root o sudo
Conexión a Internet para descargar paquetes
iptables instalado (no firewalld)

Paso 1: Preparación del sistema

Primero, instalamos todas las dependencias necesarias:

# Actualizar el sistema
dnf update -y

# Instalar EPEL repository
dnf install epel-release -y

# Instalar dependencias de compilación
dnf install kernel-devel kernel-headers gcc make automake autoconf libtool -y

# Instalar herramientas adicionales
dnf install iptables iptables-services wget unzip perl-Text-CSV_XS -y

# Deshabilitar firewalld si está activo
systemctl stop firewalld
systemctl disable firewalld

# Habilitar iptables
systemctl enable iptables
systemctl start iptables

Paso 2: Descargar xtables-addons

Descargamos la última versión estable de xtables-addons:

# Crear directorio de trabajo
cd /usr/src

# Descargar xtables-addons
wget https://inai.de/files/xtables-addons/xtables-addons-3.24.tar.xz

# Extraer el archivo
tar xf xtables-addons-3.24.tar.xz
cd xtables-addons-3.24

Paso 3: Aplicar el parche para AlmaLinux 9

AlmaLinux 9 utiliza un kernel 5.14+, que tiene cambios en la API que causan errores de compilación. Necesitamos aplicar un parche:

# Crear el archivo de parche
cat > fix-kernel-5.14.patch << 'EOF'
--- a/extensions/compat_xtables.h
+++ b/extensions/compat_xtables.h
@@ -27,7 +27,11 @@
 #endif
 
 #if LINUX_VERSION_CODE < KERNEL_VERSION(5, 17, 0)
-#	define pde_data(inode) PDE_DATA(inode)
+#	if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 14, 0)
+#		define pde_data(inode) ((inode)->i_private)
+#	else
+#		define pde_data(inode) PDE_DATA(inode)
+#	endif
 #endif
 
 #if LINUX_VERSION_CODE < KERNEL_VERSION(5, 6, 0)
EOF

# Aplicar el parche
patch -p1 < fix-kernel-5.14.patch

¿Por qué es necesario este parche?

El kernel 5.14 cambió la forma en que se accede a los datos privados de las entradas /proc. La función PDE_DATA() fue reemplazada por acceso directo a inode->i_private. Este parche detecta la versión del kernel y usa el método apropiado.

Paso 4: Compilar e instalar xtables-addons

Ahora procedemos con la compilación:

# Configurar el paquete
./configure

# Compilar
make

# Instalar
make install

# Cargar el módulo del kernel
modprobe xt_geoip

# Verificar que el módulo se cargó correctamente
lsmod | grep xt_geoip

Si ves una salida similar a xt_geoip 16384 0, el módulo se cargó correctamente.

Paso 5: Descargar la base de datos GeoIP

Ahora necesitamos descargar y preparar la base de datos de ubicaciones geográficas:

# Crear directorio para la base de datos
mkdir -p /usr/share/xt_geoip

# Navegar al directorio de scripts GeoIP
cd /usr/src/xtables-addons-3.24/geoip

# Descargar la base de datos (esto puede tardar unos minutos)
./xt_geoip_dl

# Construir la base de datos binaria
./xt_geoip_build -D /usr/share/xt_geoip *.csv

# Verificar que se crearon los archivos
ls /usr/share/xt_geoip/ | wc -l

Deberías ver un número mayor a 200, representando los diferentes países y territorios.

Paso 6: Crear reglas de firewall con GeoIP

Ahora viene la parte interesante: crear reglas basadas en países.

Bloquear un país específico

# Bloquear todo el tráfico desde China
iptables -I INPUT -m geoip --src-cc CN -j DROP

# Bloquear tráfico saliente hacia Rusia
iptables -I OUTPUT -m geoip --dst-cc RU -j DROP

Bloquear múltiples países

# Bloquear varios países simultáneamente
iptables -I INPUT -m geoip --src-cc CN,RU,KP,IR -j DROP

Crear una lista blanca (whitelist)

# Permitir solo tráfico desde España, Italia y Francia
iptables -I INPUT -m geoip ! --src-cc ES,IT,FR -j DROP

Logging antes de bloquear

Es útil registrar los intentos de conexión antes de bloquearlos:

# Registrar y luego bloquear
iptables -I INPUT -m geoip --src-cc CN -j LOG --log-prefix "GeoBlock-CN: "
iptables -I INPUT -m geoip --src-cc CN -j DROP

Paso 7: Guardar la configuración

Para que las reglas persistan después de un reinicio:

# Guardar las reglas de iptables
service iptables save

# Asegurar que iptables inicie con el sistema
systemctl enable iptables

Paso 8: Script de gestión automatizada

Para facilitar la gestión, creamos un script de administración:

cat > /usr/local/bin/geoip-manager.sh << 'SCRIPT'
#!/bin/bash

# Script de gestión de GeoIP para iptables
# Autor: Tu nombre
# Fecha: $(date +%Y-%m-%d)

ACTION=$1
COUNTRIES=$2
LOG_FILE="/var/log/geoip-manager.log"

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a $LOG_FILE
}

usage() {
    cat << EOF
Uso: $0 {block|unblock|list|status|update} [COUNTRY_CODES]

Comandos:
  block CODES     Bloquear países (ej: CN,RU,KP)
  unblock CODES   Desbloquear países
  list            Mostrar reglas GeoIP activas
  status          Mostrar estadísticas de bloqueo
  update          Actualizar base de datos GeoIP

Ejemplos:
  $0 block CN,RU       # Bloquea China y Rusia
  $0 unblock CN        # Desbloquea China
  $0 list              # Lista reglas activas
  $0 update            # Actualiza base de datos

Códigos de países comunes:
  CN=China, RU=Rusia, US=Estados Unidos, BR=Brasil
  KP=Corea del Norte, IR=Irán, IN=India, VN=Vietnam
EOF
    exit 1
}

block_countries() {
    log "Bloqueando países: $1"
    
    # Bloquear tráfico entrante
    iptables -I INPUT -m geoip --src-cc $1 -j LOG --log-prefix "GeoBlock-$1: " --log-level 4
    iptables -I INPUT -m geoip --src-cc $1 -j DROP
    
    # Opcional: bloquear tráfico saliente
    # iptables -I OUTPUT -m geoip --dst-cc $1 -j DROP
    
    service iptables save
    log "Países bloqueados correctamente: $1"
}

unblock_countries() {
    log "Desbloqueando países: $1"
    
    # Eliminar reglas de bloqueo
    iptables -D INPUT -m geoip --src-cc $1 -j LOG --log-prefix "GeoBlock-$1: " --log-level 4 2>/dev/null
    iptables -D INPUT -m geoip --src-cc $1 -j DROP 2>/dev/null
    iptables -D OUTPUT -m geoip --dst-cc $1 -j DROP 2>/dev/null
    
    service iptables save
    log "Países desbloqueados: $1"
}

list_rules() {
    echo "=== Reglas GeoIP INPUT ==="
    iptables -L INPUT -n -v --line-numbers | grep geoip
    echo ""
    echo "=== Reglas GeoIP OUTPUT ==="
    iptables -L OUTPUT -n -v --line-numbers | grep geoip
}

show_status() {
    echo "=== Estado del sistema GeoIP ==="
    echo ""
    echo "Módulo del kernel:"
    lsmod | grep xt_geoip || echo "  ¡ADVERTENCIA! Módulo no cargado"
    echo ""
    echo "Base de datos GeoIP:"
    DB_COUNT=$(ls /usr/share/xt_geoip/ 2>/dev/null | wc -l)
    echo "  Países en base de datos: $DB_COUNT"
    echo ""
    echo "Reglas activas:"
    RULES_COUNT=$(iptables -L INPUT -n | grep -c geoip)
    echo "  Total de reglas GeoIP: $RULES_COUNT"
    echo ""
    echo "Estadísticas de bloqueo (INPUT):"
    iptables -L INPUT -n -v | grep geoip | awk '{print "  Paquetes bloqueados: " $1 ", Bytes: " $2}'
}

update_geoip() {
    log "Iniciando actualización de base de datos GeoIP"
    
    # Backup de la base actual
    if [ -d "/usr/share/xt_geoip" ]; then
        BACKUP_DIR="/usr/share/xt_geoip.backup.$(date +%Y%m%d_%H%M%S)"
        cp -r /usr/share/xt_geoip $BACKUP_DIR
        log "Backup creado en: $BACKUP_DIR"
    fi
    
    # Descargar nueva base de datos
    cd /usr/src/xtables-addons-3.24/geoip
    ./xt_geoip_dl
    
    if [ $? -eq 0 ]; then
        # Construir base de datos
        ./xt_geoip_build -D /usr/share/xt_geoip *.csv
        
        if [ $? -eq 0 ]; then
            log "Base de datos GeoIP actualizada correctamente"
            
            # Limpiar backups antiguos (más de 30 días)
            find /usr/share -name "xt_geoip.backup.*" -mtime +30 -exec rm -rf {} \; 2>/dev/null
        else
            log "ERROR: Fallo al construir la base de datos"
            # Restaurar backup
            rm -rf /usr/share/xt_geoip
            mv $BACKUP_DIR /usr/share/xt_geoip
            exit 1
        fi
    else
        log "ERROR: Fallo al descargar la base de datos"
        exit 1
    fi
}

# Verificar que se ejecuta como root
if [ "$EUID" -ne 0 ]; then
    echo "ERROR: Este script debe ejecutarse como root"
    exit 1
fi

# Procesar comando
case "$ACTION" in
    block)
        if [ -z "$COUNTRIES" ]; then
            echo "ERROR: Debes especificar los códigos de países"
            usage
        fi
        block_countries $COUNTRIES
        ;;
    unblock)
        if [ -z "$COUNTRIES" ]; then
            echo "ERROR: Debes especificar los códigos de países"
            usage
        fi
        unblock_countries $COUNTRIES
        ;;
    list)
        list_rules
        ;;
    status)
        show_status
        ;;
    update)
        update_geoip
        ;;
    *)
        usage
        ;;
esac
SCRIPT

# Hacer el script ejecutable
chmod +x /usr/local/bin/geoip-manager.sh

Paso 9: Uso del script de gestión

El script que acabamos de crear simplifica enormemente la gestión:

# Bloquear China y Rusia
geoip-manager.sh block CN,RU

# Ver estadísticas
geoip-manager.sh status

# Listar reglas activas
geoip-manager.sh list

# Desbloquear un país
geoip-manager.sh unblock CN

# Actualizar base de datos GeoIP
geoip-manager.sh update

Paso 10: Automatizar actualizaciones de la base de datos

Las bases de datos GeoIP deben actualizarse periódicamente:

# Crear script de actualización automática
cat > /etc/cron.monthly/update-geoip << 'EOF'
#!/bin/bash
/usr/local/bin/geoip-manager.sh update >> /var/log/geoip-update.log 2>&1
EOF

# Hacer ejecutable
chmod +x /etc/cron.monthly/update-geoip

También puedes usar crontab para actualizaciones más frecuentes:

# Editar crontab
crontab -e

# Agregar línea para actualizar el primer día de cada mes a las 3 AM
0 3 1 * * /usr/local/bin/geoip-manager.sh update >> /var/log/geoip-update.log 2>&1

Paso 11: Cargar módulo automáticamente al inicio

Para asegurar que el módulo GeoIP se cargue en cada reinicio:

# Agregar módulo a la carga automática
echo "xt_geoip" >> /etc/modules-load.d/xtables-addons.conf

# Verificar
cat /etc/modules-load.d/xtables-addons.conf

Códigos de países más utilizados

Aquí tienes una lista de códigos ISO que puedes usar:

Código	País	Código	País
CN	China	US	Estados Unidos
RU	Rusia	BR	Brasil
KP	Corea del Norte	IN	India
IR	Irán	VN	Vietnam
TR	Turquía	ID	Indonesia
UA	Ucrania	PK	Pakistán
DE	Alemania	JP	Japón
FR	Francia	KR	Corea del Sur
ES	España	IT	Italia
GB	Reino Unido	MX	México

Casos de uso prácticos

Proteger servidor VoIP

Si tienes un servidor VoIP (Kamailio, Asterisk, FreeSWITCH), puedes bloquear países de donde no esperas llamadas:

# Permitir solo España, Italia y países europeos
geoip-manager.sh block CN,RU,KP,IR,VN,IN,BR,TR

Proteger servidor web

Para un sitio web que solo atiende clientes locales:

# Permitir solo España y países vecinos
iptables -A INPUT -p tcp --dport 80 -m geoip ! --src-cc ES,FR,PT,IT -j DROP
iptables -A INPUT -p tcp --dport 443 -m geoip ! --src-cc ES,FR,PT,IT -j DROP
service iptables save

Proteger SSH

Bloquear acceso SSH desde países específicos:

# Bloquear SSH desde China y Rusia
iptables -I INPUT -p tcp --dport 22 -m geoip --src-cc CN,RU -j DROP
service iptables save

Monitorización y logs

Ver intentos de conexión bloqueados

# Ver logs en tiempo real
tail -f /var/log/messages | grep GeoBlock

# Ver estadísticas de bloqueos
grep "GeoBlock" /var/log/messages | wc -l

Analizar países bloqueados

# Crear script de análisis
cat > /usr/local/bin/geoip-stats.sh << 'EOF'
#!/bin/bash
echo "=== Estadísticas de bloqueo GeoIP ==="
echo ""
echo "Top 10 países bloqueados hoy:"
grep "GeoBlock" /var/log/messages | \
    grep "$(date '+%b %e')" | \
    awk -F'GeoBlock-' '{print $2}' | \
    awk -F':' '{print $1}' | \
    sort | uniq -c | sort -rn | head -10
EOF

chmod +x /usr/local/bin/geoip-stats.sh

Troubleshooting (Resolución de problemas)

El módulo no carga

# Verificar si el módulo existe
find /lib/modules -name "xt_geoip.ko"

# Recargar módulo
modprobe -r xt_geoip
modprobe xt_geoip

# Ver errores del kernel
dmesg | grep -i geoip

Las reglas no funcionan

# Verificar que la base de datos existe
ls -lh /usr/share/xt_geoip/

# Verificar reglas de iptables
iptables -L INPUT -n -v | grep geoip

# Probar manualmente
iptables -I INPUT -m geoip --src-cc CN -j LOG --log-prefix "TEST-GeoIP: "
# Intenta conectar desde una IP china y revisa los logs
tail -f /var/log/messages

Error de compilación persiste

Si el parche no funciona, compila sin el módulo problemático:

cd /usr/src/xtables-addons-3.24
make clean
./configure --without-pknock
make
make install

Consideraciones de seguridad

No dependas solo de GeoIP: Los atacantes pueden usar VPNs o proxies
Combina con otras medidas: Usa fail2ban, rate limiting, etc.
Actualiza regularmente: Las asignaciones de IPs cambian
Cuidado con bloqueos excesivos: Podrías bloquear tráfico legítimo
Mantén logs: Monitorea lo que estás bloqueando

Rendimiento

GeoIP es muy eficiente:

Impacto mínimo: Las búsquedas son en memoria
Escalable: Puede manejar millones de conexiones
Mejor que ipset grandes: Para bloqueos masivos por país

Actualización del sistema

Cuando actualices el kernel de AlmaLinux:

# Después de actualizar el kernel, recompila xtables-addons
cd /usr/src/xtables-addons-3.24
make clean
./configure
make
make install

# Recargar módulo
modprobe -r xt_geoip
modprobe xt_geoip

Desinstalación (si es necesario)

Si necesitas eliminar xtables-addons:

# Eliminar reglas de iptables
iptables -F

# Descargar módulo
modprobe -r xt_geoip

# Desinstalar
cd /usr/src/xtables-addons-3.24
make uninstall

# Limpiar archivos
rm -rf /usr/share/xt_geoip
rm -f /etc/modules-load.d/xtables-addons.conf

Conclusión

El bloqueo geográfico con xtables-addons y GeoIP es una herramienta poderosa para administradores de sistemas en AlmaLinux 9. Aunque requiere compilación y configuración inicial, los beneficios en seguridad y reducción de tráfico no deseado son significativos.

Este método es especialmente útil para:

Servidores VoIP que reciben ataques de países específicos
Servicios web con audiencia local
Protección de servicios administrativos (SSH, panels)
Reducción de spam y escaneos automatizados

Recuerda mantener actualizada la base de datos GeoIP y combinar esta técnica con otras medidas de seguridad para una protección integral.

Referencias y recursos adicionales

Nota del autor: Este tutorial ha sido probado en AlmaLinux 9.x con kernel 5.14+. Si encuentras algún problema o tienes sugerencias, no dudes en dejar un comentario. Se agradece el apoyo de Claude Sonnet 4.5

Vota el Articulo:

November 13, 2025

Andrea Sannucci RTPEngine Instalación Nativa vs Docker
Un Regalo en anexo

Adjunto Tamaño

rtpengine_docker_vs_nativo_guia_completa.pdf 29.22 KB
- RTPEngine
- Docker
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

Adjunto	Tamaño
rtpengine_docker_vs_nativo_guia_completa.pdf	29.22 KB

November 07, 2025

Andrea Sannucci El Louvre en jaque: La increíble falla de seguridad detrás del robo millonario
Un reciente y audaz robo de joyas por valor de 102 millones de dólares en el Museo del Louvre de París no solo expuso fallas en la seguridad física, sino también un impactante lapso en sus defensas digitales.

Según reveló un empleado del museo a ABC News, en el momento del robo, la contraseña que protegía el sistema de videovigilancia del Louvre era simplemente "Louvre".

Esta asombrosa revelación sale a la luz mientras los legisladores franceses exigen respuestas a la dirección del museo sobre cómo una de las instituciones culturales más seguras del mundo pudo ser vulnerada con tanta facilidad.

Detalles Clave del Fallo de Seguridad:

Contraseña Absurda: La contraseña para el sistema de videovigilancia era la propia palabra "Louvre", un detalle que se ha convertido en el símbolo de un "terrible fracaso" de seguridad.

Vigilancia Ineficaz: La presidenta y directora del Louvre, Laurence des Cars, admitió ante un comité del Senado francés que, si bien el sistema de alarmas y cámaras funcionó, hubo una "debilidad en la seguridad perimetral debido a la falta de inversión".

Cámara Mal Posicionada: Solo había una cámara externa instalada cerca de la Galería de Apolo (donde se produjo el robo), y esta estaba orientada hacia el oeste, perdiéndose la ventana exacta por donde los ladrones entraron y escaparon utilizando una grúa elevadora.

Promesa de Mejoras: Des Cars reconoció haber estado "consternada por la situación de seguridad del museo" cuando asumió el cargo en 2021 y se comprometió a mejorar la seguridad, incluyendo la actualización de la red de CCTV y el establecimiento de una comisaría de policía dentro del museo.

El robo, que duró tan solo siete minutos, sigue siendo investigado. Los hechos han dejado a Francia entre el bochorno y la fascinación por un crimen que parece sacado de una película, y que ha quedado grabado en la historia por una falla de ciberseguridad que cualquiera podría haber adivinado.

fuente: https://abcnews.go.com/International/password-louvres-video-surveillance-system-louvre-employee/story?id=127236297
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

October 29, 2025

Andrea Sannucci Módulo de Troncales Sangoma para Asterisk
Sangoma ofrece dos servicios de troncales SIP diseñados para diferentes tipos de usuarios: SIPStation, ideal para usuarios cotidianos, y VoIP Innovations, orientado a usuarios con mayores demandas de tráfico. Aunque ambos servicios utilizan plataformas y configuraciones muy diferentes, Sangoma ha desarrollado una solución para simplificar su integración con Asterisk.

En productos como FreePBX y Switchvox, Sangoma ya proporcionaba mecanismos automáticos de configuración mediante tokens o códigos proporcionados por cada servicio. Ahora, esta funcionalidad está disponible en Asterisk a través del módulo res_pjsip_config_sangoma, que utiliza el mecanismo de configuración "sorcery" para configurar automáticamente las troncales PJSIP.

Cómo utilizarlo:

El módulo debe seleccionarse en "make menuselect" dentro de la categoría "Resource Modules", en la sección "External"

Una vez seleccionado, se descarga e instala automáticamente durante el proceso de instalación

Es necesario configurar el módulo con los detalles específicos del servicio

Nota importante: Este módulo solo es compatible con PJSIP. El antiguo módulo chan_sip no está soportado.

Para más información técnica sobre la configuración, Sangoma proporciona documentación detallada en su base de conocimientos y también ofrece un webinar explicativo sobre el tema.

Fuente: https://www.asterisk.org/sangoma-trunking-module/
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

October 28, 2025

Andrea Sannucci Clusters de OpenSIPS Geo-Distribuidos con Replicación Bridge
La próxima versión OpenSIPS 4.0 introduce una nueva característica llamada "Cluster-Bridge Replication" (Replicación en Puente de Clusters) en el módulo clusterer, diseñada específicamente para plataformas con múltiples centros de datos distribuidos geográficamente.

El problema: Replicación Full-Mesh

Tradicionalmente, OpenSIPS utiliza replicación full-mesh (malla completa), donde cada nodo replica datos a todos los demás nodos del cluster. En un cluster con N nodos, esto genera N * (N-1) enlaces de replicación.

Ventajas:

Simple e intuitivo de configurar

Propagación inmediata de datos

Habilita contadores distribuidos de llamadas concurrentes y CPS (llamadas por segundo)

Desventajas:

Problemas de escalabilidad: En una plataforma con solo 3 centros de datos y 3 nodos por centro, ya tenemos 27 enlaces WAN

Los enlaces WAN suelen ser más lentos y pueden convertirse en cuellos de botella

Con replicaciones frecuentes (cada 200ms por defecto), el ancho de banda se satura rápidamente

La fórmula de enlaces en full-mesh es: M² * N * (N-1) / 2, donde M es el número de instancias por datacenter y N el número de datacenters.

La solución: Cluster-Bridge Replication

La nueva característica reorganiza los nodos en "islas" conectadas por puentes, reduciendo drásticamente el uso de ancho de banda WAN.

Cómo funciona:

Cada centro de datos tiene su propio cluster local

Los datacenters se conectan entre sí mediante enlaces puente únicos (una conexión TCP por par de datacenters)

Se introduce una nueva tabla SQL llamada clusterer_bridge para definir estos enlaces

Ventajas clave:

Alta disponibilidad en ambos extremos:

Lado emisor: Utiliza sharing tags para determinar qué nodo envía

Lado receptor: Lista de failover para intentar múltiples nodos sucesivamente

Reducción dramática de enlaces: La fórmula ahora es simplemente N * (N-1) / 2

Para 3 datacenters: solo 3 enlaces WAN en lugar de 27

Implementación

Actualmente, el módulo ratelimit es el primero en beneficiarse de esta característica para la replicación de pipes (tuberías de limitación de tasa).

Para habilitarlo:

Definir los clusters y puentes en las tablas SQL correspondientes

Activar el parámetro bridge_replication en el módulo ratelimit

La funcionalidad ya está disponible en la rama master de OpenSIPS y completamente documentada en los módulos clusterer y ratelimit.

Esta característica representa un avance significativo para plataformas VoIP con infraestructura distribuida globalmente, permitiendo ahorros sustanciales de ancho de banda sin sacrificar la consistencia de datos.

Me parece muy pero muy interesante. ¿Qué opinan?

Fuente: https://blog.opensips.org/2025/10/28/scaling-geo-distributed-opensips-cl...
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

October 25, 2025

Juan Oliva IA Pentesting Metasploit
Vamos a ver, cómo instalamos y hacemos funcionar, todas las piezas necesarias sobre Kali Linux y conseguir un agente I.A. funcional para realizar análisis de vulnerabilidades y pruebas de penetración con Claude y Metasploit.

El servidor MCP de Metasploit (por GH05TCREW) permite a un agente IA como Claude usar su cliente MCP para enviar ordenes al servidor MCP. El servidor MCP METASPLOIT la traduce a peticiones el API en formato API JSON commands hacia el servicio Metasploit RPC, el cual lo ejecuta en el Framework para finalmente devolver el resultado.

En Inteligencia Artificial, el servidor MCP actúa como intermediario, escucha las peticiones JSON-RPC entrantes del cliente de un agente de IA. para finalmente enviar la peticion «traducida» hacia un programa determinado.

En Pentesting, estos mensajes pueden contener el nombre de una herramienta (p. ej., list_exploits) y parámetros. El servidor valida esta solicitud y la traduce al comando correspondiente para el servicio RPC de Metasploit Framework, conocido como msfrpcd. La respuesta de Metasploit se formatea y se envía de vuelta al agente de IA.

1.- Metasploit RPC

Primera consola : Iniciar Metasploit Framework

# msfconsole

Segunda consola : Iniciar Metasploit RPC
Tener en cuenta que la contraseña asignada es exclusivamente para entornos de prueba, no usar para entornos de producción.

# msfrpcd -P pass123 -S -a 127.0.0.1 -p 55553

Verificar el proceso

2.- Metasploit MCP Server

Tercera consola:

git clone https://github.com/GH05TCREW/MetasploitMCP.git cd MetasploitMCP python3 -m venv /home/kali/MetasploitMCP source /home/kali/MetasploitMCP/bin/activate pip install -r requirements.txt pip install uv export MSF_PASSWORD="pass123" python MetasploitMCP.py --transport stdio

3.- Instalar Claude

Cuarta consola :
Instalar Prerequisitos

cd /home/kali sudo apt update sudo apt install npm -y curl -LsSf https://astral.sh/uv/install.sh | sh

Claude

wget https://github.com/aaddrick/claude-desktop-debian/releases/download/v1.1.6%2Bclaude0.14.4/claude-desktop_0.14.4_amd64.deb sudo dpkg -i claude-desktop_0.14.4_amd64.deb
```
Luego buscar en los programas "Claude" y ejecutar
```
Registrar una cuenta de correo para iniciar

Ir a las opciones de desarrollador y configurar el servidor MCP de Metasploit

Por si deseamos configurar manualmente

nano /home/kali/.config/Claude/claude_desktop_config.json

Cerrar Claude y volver a iniciar, ahora verificar que la conexión hacia el MCP de Metasploit está realizada.

Con ello hemos terminado la configuración

Ahora probaremos las capacitadaes integradas con Metasploit

1.- Búsqueda de exploits
prompt : Using the metasploit tool, please list exploits related to ‘ms17’.

2.- Escaneo de servicios y análisis de vulnerabilidades.
prompt : scan de host 192.168.1.75 and give me a report of what is running on it, use Metasploit por scanning capabilities for this task.

Definitivamente esto es la punta del iceberg en el avance de I.A. Pentesting, cada día aparecen nuevas formas de interacción con diversos componentes, espero les sirva.

@jroliva

Referencias:
https://skywork.ai/skypage/en/ai-pentesting-metasploit/1977937594626281472
https://github.com/GH05TCREW/MetasploitMC
https://unix.stackexchange.com/questions/763153/how-to-make-a-python-module-available-to-all-users
https://www.youtube.com/watch?v=_GxopZS8LwU&t

October 08, 2025

Andrea Sannucci Kamailio 6.0 e la función dlg_manage() del módulo DIALOG
En el protocolo SIP, el concepto de diálogo representa la relación completa entre dos endpoints a través de múltiples transacciones, desde el INVITE inicial hasta el BYE final. Sin embargo, el protocolo en sí mismo fue diseñado para ser stateless, lo que significa que cada mensaje puede procesarse de forma independiente sin mantener contexto. Esta desconexión entre la necesidad práctica de rastrear sesiones completas y la naturaleza sin estado del protocolo crea un desafío significativo para los servidores SIP. La función dlg_manage() surgió como la solución moderna de Kamailio para abordar este problema de manera elegante y directa.

Qué hace dlg_manage() en esencia

Esta función actúa como el punto de partida de la gestión de diálogos del módulo dialog en Kamailio. Cuando se invoca, instruye al sistema para que comience a rastrear la sesión SIP completa asociada con el mensaje actual, capturando toda la información necesaria sobre los participantes, identificadores de sesión, rutas de señalización y estado del diálogo. Lo revolucionario de esta función es que encapsula en una sola llamada todo el proceso que anteriormente requería configurar flags específicos y manejar múltiples callbacks manualmente.

La evolución histórica y el cambio de paradigma

En versiones anteriores de Kamailio, activar el seguimiento de diálogos requería un enfoque más manual y propenso a errores. Los desarrolladores debían establecer un flag específico mediante el parámetro dlg_flag antes de crear la transacción correspondiente, luego configurar callbacks para manejar mensajes dentro del diálogo. Este proceso de dos pasos era funcional pero añadía complejidad innecesaria. Con la introducción de dlg_manage(), este paradigma cambió radicalmente. En Kamailio 6.0, este cambio se consolidó completamente al eliminar el soporte para dlg_flag, convirtiendo a dlg_manage() en el método estándar y único recomendado para iniciar el rastreo de diálogos.

Cuándo invocar dlg_manage() en tu configuración

La función debe ser llamada en el momento en que deseas que Kamailio comience a rastrear un diálogo. Para INVITE iniciales, típicamente se invoca después de validar la solicitud y antes del enrutamiento final o del relay. Para mensajes dentro de un diálogo ya establecido como ACK, BYE, re-INVITE o UPDATE, dlg_manage() puede ser llamada nuevamente para asegurar que el módulo dialog procese correctamente estos mensajes secuenciales. La belleza de esta función radica en su inteligencia: llamarla múltiples veces para el mismo diálogo no causa problemas, simplemente asegura que el tracking esté activo.

Contextos de ejecución y flexibilidad

Una de las fortalezas de dlg_manage() es su versatilidad en cuanto a dónde puede ser invocada. La función opera correctamente en REQUEST_ROUTE, BRANCH_ROUTE, REPLY_ROUTE y FAILURE_ROUTE, lo que proporciona una flexibilidad excepcional para diferentes arquitecturas de configuración. Esto significa que puedes activar el rastreo de diálogos en el momento que mejor se adapte a tu lógica de enrutamiento, ya sea al recibir la solicitud inicial, durante el procesamiento de branch en escenarios de forking, al procesar respuestas, o incluso en rutas de tipo failure.

La automatización del ciclo de vida completo

Lo que hace especialmente poderosa a dlg_manage() es que no solo crea el diálogo, sino que automáticamente configura todo el ecosistema de seguimiento necesario. Esto incluye el registro de callbacks en el módulo de transacciones para monitorear respuestas, la configuración de temporizadores para detectar sesiones abandonadas, la preparación de estructuras de datos para almacenar variables de diálogo, y la inicialización de mecanismos para ejecutar acciones personalizadas en eventos del ciclo de vida. Todo esto sucede de manera transparente con una sola llamada a la función.

Integración con variables de contexto de diálogo

La función dlg_manage() habilita automáticamente el uso de las pseudo-variables de contexto de diálogo como $dlg_ctx(timeout), $dlg_ctx(flags) y otras. Estas variables permiten personalizar el comportamiento de cada diálogo de manera dinámica antes de su creación. Por ejemplo, puedes establecer un timeout personalizado para diálogos específicos, definir rutas de timeout personalizadas, o configurar si se debe enviar BYE automáticamente cuando expira el timeout. Esta integración hace que la configuración sea más intuitiva y el código más legible.

Distinción entre mensajes iniciales y secuenciales

La función dlg_manage() implementa lógica inteligente para distinguir automáticamente entre INVITE iniciales que crean nuevos diálogos y mensajes secuenciales dentro de diálogos existentes. Para INVITE iniciales sin To-tag, crea una nueva estructura de diálogo y comienza el rastreo. Para mensajes con To-tag o métodos como ACK y BYE, busca el diálogo existente y procesa el mensaje en ese contexto. Esta distinción automática elimina la necesidad de escribir lógica condicional compleja en el script de configuración.

Interacción con perfiles y límites de llamadas

Una vez que dlg_manage() ha activado el rastreo de un diálogo, todas las capacidades avanzadas del módulo dialog se vuelven disponibles. Esto incluye la posibilidad de asignar el diálogo a perfiles mediante set_dlg_profile(), lo cual es fundamental para implementar límites de llamadas concurrentes. Sin la llamada previa a dlg_manage(), estas funciones no tendrían un diálogo sobre el cual operar. La función actúa como el habilitador necesario para toda la funcionalidad basada en perfiles y agrupaciones de diálogos.

Impacto en módulos dependientes y extensiones

Muchos otros módulos de Kamailio dependen del módulo dialog y esperan que los diálogos estén siendo rastreados. El módulo uac, por ejemplo, puede almacenar automáticamente URIs originales como variables de diálogo si dlg_manage() ha sido invocado antes de llamar a funciones de manipulación de headers. El módulo acc puede generar CDR más precisos cuando tiene acceso a información completa del diálogo. La función dlg_manage() actúa como la unión que permite a estos módulos cooperar eficientemente.

Consideraciones de rendimiento y recursos

Aunque invocar dlg_manage() tiene un costo en términos de memoria y procesamiento, este es generalmente marginal comparado con los beneficios obtenidos. Cada diálogo rastreado consume memoria para almacenar su estado, pero esta memoria se libera automáticamente cuando el diálogo termina. El procesamiento adicional para mantener el estado es mínimo en comparación con el procesamiento total de mensajes SIP. En sistemas modernos, el overhead es raramente un factor limitante, y los beneficios en términos de capacidades de control y monitoreo superan ampliamente cualquier impacto en el rendimiento.

Escenarios donde evitar dlg_manage()

Existen situaciones específicas donde invocar dlg_manage() no tiene sentido o podría ser contraproducente. Para servidores que actúan como simples redirectores o que solo manejan métodos distintos a INVITE como REGISTER, MESSAGE o OPTIONS, el rastreo de diálogos es innecesario. En proxies edge que solo realizan routing básico sin necesidad de conocer el estado de las sesiones, añadir el overhead del módulo dialog no aporta valor. Si tu arquitectura ya tiene otro componente que gestiona el estado de las llamadas, duplicar esta funcionalidad en Kamailio puede ser redundante.

El futuro simplificado de la configuración

La tendencia clara en la evolución de Kamailio es hacia la simplificación y la abstracción de complejidad innecesaria. La función dlg_manage() representa perfectamente esta filosofía al encapsular operaciones complejas detrás de una interfaz simple. Con la eliminación del parámetro dlg_flag en Kamailio 6.0, el mensaje es claro: dlg_manage() es el camino correcto hacia adelante. Esta función no solo hace el código más limpio y mantenible, sino que también reduce la curva de aprendizaje para nuevos usuarios del sistema, permitiéndoles acceder rápidamente a capacidades avanzadas de gestión de sesiones con mínima configuración.
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

October 07, 2025

Andrea Sannucci Kamailio 6.0 y el Módulo Dialog
¿Qué es y por qué existe?

El módulo dialog de Kamailio representa uno de los componentes fundamentales para la gestión con estado de sesiones SIP. Mientras que Kamailio funciona por defecto como un proxy sin estado (stateless), el módulo dialog introduce la capacidad de rastrear y mantener información sobre diálogos SIP activos a lo largo del ciclo de vida completo de los mismos. Esta funcionalidad transforma a Kamailio de un simple intermediario de mensajes en un gestor inteligente de sesiones que conoce el estado actual de cada llamada en el sistema.

El problema que resuelve

En un entorno SIP estándar sin seguimiento de diálogos, el servidor procesa cada mensaje de forma independiente sin mantener contexto sobre la sesión a la que pertenece. Esto limita severamente las capacidades del sistema para implementar lógicas complejas, control de recursos, facturación o estadísticas en tiempo real. El módulo dialog cierra esta brecha manteniendo un registro en memoria de todas las sesiones activas, incluyendo información crítica como timestamps, identificadores únicos y metadatos personalizados.

Cuándo es imprescindible utilizarlo

La implementación del módulo dialog se vuelve necesaria en escenarios donde se requiere control sobre el número de sesiones concurrentes, ya sea por usuario individual, por gateway, por dirección IP o a nivel global del sistema. Es absolutamente esencial en plataformas que necesitan implementar límites de llamadas simultáneas para prevenir abuso de recursos o cumplir con posibles restricciones. También es indispensable cuando se necesitan estadísticas precisas en tiempo real sobre el tráfico de llamadas, métricas de duración o análisis de patrones de uso.

Casos de uso

En entornos de carriers y proveedores de servicios VoIP, el módulo dialog es la piedra angular para implementar sistemas de rating y billing. Permite conocer exactamente cuándo inicia una llamada, cuándo termina y su duración precisa, información vital para la facturación. En plataformas de contact center o call center, posibilita la gestión de colas y la distribución de carga, asegurando que no se superen los límites de agentes disponibles. Para empresas con licencias limitadas de canales concurrentes hacia la PSTN, el módulo garantiza el cumplimiento estricto de estos límites evitando rechazos o costos adicionales.

Alta disponibilidad y escalabilidad

Una de las capacidades más poderosas del módulo dialog es su habilidad para replicar el estado de los diálogos entre múltiples instancias de Kamailio. Esto permite construir arquitecturas de alta disponibilidad donde si un servidor falla, otro puede continuar manejando las sesiones existentes sin pérdida de información. Esta replicación es fundamental en despliegues críticos donde la continuidad del servicio no puede verse comprometida por fallos de hardware o mantenimiento programado.

Detección de sesiones abandonadas

El módulo implementa mecanismos sofisticados para detectar y limpiar diálogos que no terminaron correctamente, situación común cuando dispositivos pierden conectividad abruptamente o aplicaciones se cierran inesperadamente. Esta limpieza automática previene el agotamiento de recursos por sesiones "fantasma" que consumen memoria y contadores de límites sin representar llamadas reales. La detección se basa en timeouts configurables y puede integrarse con perfiles específicos según el tipo de sesión.

Integración con lógica

El módulo dialog no opera en aislamiento sino que se integra profundamente con el resto del script de Kamailio, permitiendo ejecutar acciones personalizadas en eventos específicos del ciclo de vida del diálogo. Esto posibilita implementar notificaciones a sistemas externos cuando una llamada inicia o termina, actualizar bases de datos en tiempo real, o ajustar dinámicamente políticas de enrutamiento basadas en la carga actual del sistema.

Consideraciones de rendimiento

Mantener estado en memoria tiene un costo en términos de recursos. Cada diálogo activo consume memoria RAM, y en sistemas con decenas de miles de llamadas concurrentes esto puede representar varios gigabytes. Sin embargo, el beneficio funcional generalmente supera ampliamente este costo, especialmente considerando que la memoria es relativamente económica y el módulo está altamente optimizado. La clave está en dimensionar correctamente el hardware y configurar límites razonables acordes con la capacidad del sistema.

¿Cuándo podrías no necesitarlo?

Si estás construyendo un simple proxy SIP que únicamente reenvía mensajes sin necesidad de conocer el estado de las sesiones, mantener estadísticas o aplicar límites, entonces el módulo dialog puede ser innecesario. Escenarios puramente stateless donde el objetivo es máxima throughput de mensajería sin lógica adicional pueden prescindir de él. Sin embargo, estos casos son relativamente raros en producción, donde casi siempre existe algún requerimiento de control o monitoreo que justifica su implementación.
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

October 06, 2025

Andrea Sannucci La Función t_relay del Módulo TM en Kamailio
En el ecosistema de Kamailio (anteriormente OpenSER), el módulo TM (Transaction Module) representa uno de los componentes más críticos para el procesamiento de mensajes SIP. Dentro de este módulo, la función t_relay() constituye el mecanismo fundamental para el reenvío stateful de mensajes SIP, implementando la lógica de transacciones definida en el RFC 3261. Este artículo explora en detalle el funcionamiento interno, arquitectura y aplicaciones prácticas de t_relay(), proporcionando una comprensión profunda para administradores e ingenieros de sistemas VoIP.

Antes de profundizar en t_relay(), es esencial comprender el contexto del módulo TM. Este módulo implementa el manejo stateful de transacciones SIP, lo que significa que mantiene el estado de cada transacción desde su inicio hasta su conclusión, contrariamente al procesamiento stateless que caracteriza al proxy básico de Kamailio.

Diferencia entre Stateful y Stateless

Procesamiento Stateless: Kamailio procesa cada mensaje de forma independiente sin mantener memoria de mensajes previos. Utiliza funciones como forward() del módulo core.

Procesamiento Stateful: El módulo TM crea y mantiene estructuras de datos (transacciones) que persisten durante el ciclo de vida completo de una petición-respuesta SIP. Esto permite:

Retransmisión automática de mensajes (cumpliendo RFC 3261)

Absorción de retransmisiones duplicadas

Correlación automática de respuestas con peticiones

Implementación de timers SIP (Timer A, B, D, E, F, G, H, I, J, K)

Cancelación de transacciones

Failover y load balancing avanzado

Definición y Propósito

t_relay() t_relay(host, port)
La función t_relay() es el punto de entrada principal para el reenvío stateful de mensajes SIP. Su responsabilidad primaria es crear (si no existe) o localizar una transacción SIP y reenviar el mensaje actual al siguiente hop determinado por el algoritmo de routing de Kamailio.

Proceso Interno Paso a Paso

Cuando se invoca t_relay(), el módulo TM ejecuta la siguiente secuencia de operaciones:

1. Creación o Localización de Transacción

El módulo TM examina el mensaje entrante y determina si corresponde a una transacción existente o si debe crear una nueva:

Para peticiones (INVITE, REGISTER, etc.):

Calcula un hash basado en Call-ID, CSeq y From-tag

Busca en la tabla de transacciones (hash table) si ya existe

Si no existe, crea una nueva estructura de transacción en memoria compartida

Reserva memoria para almacenar callbacks, timers y estado de la transacción

Para respuestas:

Utiliza el branch parameter del Via header para localizar la transacción correspondiente

Si encuentra la transacción, actualiza su estado

Si no la encuentra (respuesta tardía), generalmente la descarta

2. Clonación del Mensaje

Una vez identificada la transacción, TM realiza una clonación del mensaje SIP:

Original Message → Shared Memory Clone → Transaction Buffer
Esta clonación es crítica porque:

Los mensajes originales están en memoria privada del proceso

Las transacciones deben persistir entre diferentes procesos worker

Permite retransmisiones sin necesidad de volver a procesar el routing script

3. Determinación del Next Hop

t_relay() respeta la decisión de routing tomada previamente en el script de configuración:

Si se ha establecido el Destination Set ($du), utiliza esa URI

Si se ha modificado el Request-URI ($ru), lo utiliza como destino

Si se proporcionó un parámetro proxy_uri a t_relay(), lo usa como override

Aplica DNS lookup (NAPTR, SRV, A/AAAA) según la configuración

4. Branch Management (Gestión de Ramas)

Para peticiones iniciales, TM puede crear múltiples branches (ramas) si se ha configurado serial forking o parallel forking:

┌─→ Branch 1 → Destino 1 Request ──→│ │─→ Branch 2 → Destino 2 └─→ Branch 3 → Destino 3
Cada branch tiene:

Un branch ID único (b=xxxxxxxx en Via header)

Su propio estado de transacción

Timers independientes

Buffers de respuesta separados

5. Modificación de Headers SIP

Antes del reenvío, TM modifica automáticamente ciertos headers:

Via Header: Añade un nuevo Via header con:

Dirección IP y puerto del socket de salida

Branch parameter único (branch=z9hG4bK + random)

rport parameter si está habilitado

Max-Forwards: Decrementa el valor en 1 (prevención de loops)

Record-Route: Si record_route() fue llamado previamente, el header ya está presente

Content-Length: Recalcula si el body fue modificado

6. Activación de Timers

TM inicia los timers apropiados según el tipo de transacción:

Para transacciones INVITE:

Timer A: Retransmisión inicial (T1 = 500ms por defecto)

Timer B: Timeout de transacción (64*T1 = 32s)

Timer D: Duración máxima de respuesta final

Para transacciones non-INVITE:

Timer E: Retransmisión (similar a Timer A)

Timer F: Timeout de transacción (64*T1)

Características de retransmisión:

Backoff exponencial: T1, 2T1, 4T1, 8*T1...

Hasta Timer B (INVITE) o Timer F (non-INVITE)

Automático, no requiere intervención del script

7. Envío del Mensaje

Finalmente, el mensaje es enviado a través del socket de red:

Selecciona el socket apropiado (UDP, TCP, TLS, SCTP, WebSocket)

Para TCP/TLS, puede reutilizar conexión existente o crear nueva

Almacena el mensaje enviado para posibles retransmisiones

Registra estadísticas y logs según configuración

Valor de Retorno

t_relay() retorna diferentes valores que indican el resultado de la operación:

1: Éxito, el mensaje fue reenviado correctamente

-1: Error al crear la transacción o al enviar el mensaje

-2: Error interno (falta de memoria, configuración incorrecta)

-6: Error de resolución DNS

Parámetros y otras funciones parecidas

t_relay() sin parámetros

if (t_relay()) { xlog("L_INFO", "Message relayed successfully\n"); exit; }
Comportamiento: Utiliza el Destination Set previamente configurado en el script mediante funciones como rewritehostport(), $du, o modificación del Request-URI.

t_relay(host, port)

t_relay("192.168.1.100", "5060");
Fuerza el destino independientemente de la URI previamente configurada. Útil para:

Routing a un gateway específico

Implementación de media servers

Bypass de DNS lookup

Integración con Failure Routes

Una de las características más potentes de t_relay() es su integración con failure routes, permitiendo implementar lógica avanzada de failover:

route[RELAY] { if (!t_relay()) { sl_reply_error(); } exit; } failure_route[MANAGE_FAILURE] { # Esta ruta se ejecuta si t_relay() recibe # una respuesta de falla (>=300) o timeout if (t_check_status("408|500|503")) { # Timeout o error del servidor if (ds_next_dst()) { # Intenta siguiente destino en dispatcher t_on_failure("MANAGE_FAILURE"); t_relay(); exit; } } if (t_check_status("486|600")) { # User Busy - intenta voicemail $ru = "sip:voicemail@" + $rd; t_relay(); exit; } }
Callbacks y Event Routes

TM proporciona varios event routes que se disparan durante el ciclo de vida de la transacción:

event_route[tm:local-request] { # Se ejecuta para peticiones generadas localmente xlog("L_INFO", "Local request: $rm to $ru\n"); } event_route[tm:branch-failure] { # Se ejecuta cuando un branch específico falla xlog("L_WARN", "Branch $T_branch_idx failed: $T_reply_code\n"); }
Diferencias con Otras Funciones de Relay

t_relay() vs forward()

forward() (stateless):

No crea transacciones

No retransmite automáticamente

Menor consumo de memoria

No permite failure routes

Más rápido (menor overhead)

t_relay() (stateful):

Crea y mantiene transacciones

Retransmisión automática según RFC 3261

Permite failover y load balancing complejos

Mayor consumo de memoria

Necesario para la mayoría de escenarios de producción

t_relay() vs t_forward_nonack()

t_forward_nonack() t_forward_nonack(proxy_uri)
Variante de t_relay() que no procesa mensajes ACK. Los ACK se procesan de forma especial en SIP:

ACK para 2xx respuestas es una nueva transacción

ACK para respuestas de error (3xx-6xx) es parte de la transacción INVITE original

t_forward_nonack() es útil cuando se quiere procesar ACKs de forma stateless.

t_relay() vs t_replicate()

t_replicate("sip:backup.example.com:5060");
t_replicate() envía una copia del mensaje a un destino adicional sin esperar respuesta. Útil para:

Replicación de CDRs

Sistemas de logging distribuido

Hot standby servers

Gestión de Memoria

El módulo TM utiliza memoria compartida para las transacciones. Parámetros clave:

modparam("tm", "hash_size", 8192) # Tamaño de la hash table de transacciones # Debe ser potencia de 2 # Mayor valor = menos colisiones, más memoria modparam("tm", "timer_partitions", 4) # Particiona los timers entre múltiples threads # Mejora rendimiento en sistemas con muchos cores
Control de Timers

modparam("tm", "fr_timer", 30000) # Final Response timer (30 segundos) # Tiempo máximo para recibir respuesta final modparam("tm", "fr_inv_timer", 120000) # Final Response timer para INVITE (120 segundos) # INVITE puede tardar más (ring time) modparam("tm", "restart_fr_on_each_reply", 1) # Reinicia fr_timer en cada respuesta provisional # Útil para llamadas de larga duración
Performance para Alto Tráfico

modparam("tm", "auto_inv_100", 1) # Envía 100 Trying automáticamente para INVITE # Reduce retransmisiones del UAC modparam("tm", "auto_inv_100_reason", "Trying") # Personaliza el reason phrase del 100 modparam("tm", "aggregate_challenges", 1) # Agrega múltiples desafíos de autenticación # Útil en escenarios de parallel forking
Casos de Uso Avanzados

Load Balancing con Failover

route[LOADBALANCE] { if (!ds_select_dst("1", "4")) { # Algoritmo 4: hash sobre Call-ID send_reply("503", "Service Unavailable"); exit; } t_on_failure("LB_FAILURE"); if (!t_relay()) { sl_reply_error(); } exit; } failure_route[LB_FAILURE] { if (t_check_status("(408)|(5[0-9][0-9])")) { if (ds_next_dst()) { t_on_failure("LB_FAILURE"); t_relay(); exit; } } }
Serial Forking (Búsqueda Secuencial)

route[SERIAL_FORK] { # Obtener múltiples contactos del location table if (!lookup("location")) { send_reply("404", "Not Found"); exit; } t_on_failure("NEXT_CONTACT"); t_relay(); exit; } failure_route[NEXT_CONTACT] { if (t_check_status("408|480|486|487")) { if (next_contacts()) { t_on_failure("NEXT_CONTACT"); t_relay(); exit; } } }
Parallel Forking (Búsqueda Paralela)

route[PARALLEL_FORK] { if (!lookup("location")) { send_reply("404", "Not Found"); exit; } # lookup() ya ha preparado todos los branches # t_relay() los enviará en paralelo t_relay(); exit; }
Media Server Integration

route[VOICEMAIL] { $ru = "sip:" + $rU + "@voicemail.internal:5070"; # Añadir headers personalizados para el media server append_hf("X-Original-To: $tu\r\n"); append_hf("X-Original-From: $fu\r\n"); t_relay(); exit; }
Logs y Trazas

# Activar debug del módulo TM modparam("tm", "enable_stats", 1) route { xlog("L_INFO", "RELAY: $rm from $si:$sp to $ru\n"); if (t_relay()) { xlog("L_INFO", "RELAY: Success, transaction=$T(id_index):$T(id_label)\n"); } else { xlog("L_ERR", "RELAY: Failed, reason=$T_reply_code $T_reply_reason\n"); } }
Variables de Transacción

El módulo TM expone múltiples pseudovariables para inspección:

$T(id_index) # Índice de la transacción en la hash table $T(id_label) # Label único de la transacción $T(reply_code) # Código de la última respuesta $T(reply_reason) # Reason de la última respuesta $T(branch_index) # Índice del branch actual $T_req(hdrs) # Headers de la petición original $T_rpl(hdrs) # Headers de la respuesta
Estadísticas en Tiempo Real

# Mediante kamcmd kamcmd tm.stats kamcmd tm.hash_stats # Información de transacciones activas kamcmd tm.t_list
Problemas Comunes

Problema: Transacciones que nunca se limpian (memory leak)

# Solución: Verificar que los timers están correctamente configurados modparam("tm", "fr_timer", 30000) modparam("tm", "wt_timer", 10000) # Wait timer
Problema: Retransmisiones excesivas

# Verificar que auto_inv_100 está activo modparam("tm", "auto_inv_100", 1) # Y que los timers no son demasiado agresivos modparam("tm", "retr_timer1", 500) # T1 = 500ms modparam("tm", "retr_timer2", 4000) # T2 = 4s
Problema: Failure route no se ejecuta

# Asegurarse de registrar la failure route ANTES de t_relay() route[RELAY] { t_on_failure("MANAGE_FAILURE"); # ANTES t_relay(); # DESPUÉS }

Mejores Prácticas

1. Siempre Verificar el Valor de Retorno

if (!t_relay()) { # Manejar el error apropiadamente xlog("L_ERR", "Relay failed for $rm from $si\n"); sl_reply_error(); } exit; # IMPORTANTE: exit después de t_relay()
2. Usar exit Después de t_relay()

Una vez que t_relay() tiene éxito, el mensaje ha sido enviado y no debe continuar el procesamiento:

# CORRECTO if (t_relay()) { exit; } # INCORRECTO - puede causar comportamiento inesperado t_relay(); # más código aquí (NO HACER ESTO)
3. Configurar Failure Routes Apropiadamente

route[RELAY] { # Registrar failure route solo cuando sea necesario if ($rU =~ "^[0-9]+$") { # Solo para números t_on_failure("PSTN_FAILURE"); } t_relay(); exit; }
4. Dimensionar Correctamente el Hash Table

Para un servidor con millones de transacciones por día:

# Regla general: hash_size >= transacciones_por_segundo * avg_duration # Ejemplo: 1000 TPS * 30s avg = 30000 transacciones concurrentes modparam("tm", "hash_size", 32768) # Siguiente potencia de 2
5. Monitorear Estadísticas

event_route[core:worker-one-init] { # Log estadísticas cada 60 segundos $var(interval) = 60; route(LOG_TM_STATS); } route[LOG_TM_STATS] { $var(current) = $stat(tm:current_transactions); $var(total) = $stat(tm:total_transactions); xlog("L_INFO", "TM Stats: current=$var(current), total=$var(total)\n"); # Reprogramar timer_period("LOG_TM_STATS", $var(interval)); }
Conclusión

La función t_relay() del módulo TM es el corazón del procesamiento stateful en Kamailio. Su correcta comprensión y utilización es fundamental para construir sistemas VoIP robustos, escalables y conformes con los estándares SIP.

Los aspectos clave a recordar son:

t_relay() crea y gestiona transacciones completas según RFC 3261

Implementa retransmisión automática y gestión de timers

Permite failover y load balancing sofisticados mediante failure routes

Requiere más recursos que el procesamiento stateless pero proporciona funcionalidad crítica

Debe ser correctamente dimensionado y monitoreado en entornos de producción

La maestría en el uso de t_relay() y el módulo TM en general distingue a los administradores experimentados de Kamailio y es esencial para implementaciones de nivel enterprise.
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

October 03, 2025

Andrea Sannucci El Módulo TM en Kamailio 6.0.X
El módulo TM (Transaction Module) de Kamailio es el componente encargado de implementar la capa transaccional del protocolo SIP según la RFC 3261. Su función principal es convertir a Kamailio de un proxy stateless a un proxy stateful, lo que significa que mantiene estado de las peticiones y respuestas mientras se procesan. Este módulo es prácticamente obligatorio en cualquier implementación de Kamailio que vaya más allá del simple reenvío de paquetes.

El módulo TM gestiona transacciones SIP, que son pares de petición-respuesta. Cuando una petición SIP entra al servidor, el módulo puede crear una transacción que agrupa esa petición con todas sus respuestas asociadas. Esto incluye las respuestas provisionales (1xx), exitosas (2xx), de redirección (3xx) y de error (4xx, 5xx, 6xx).
La gestión transaccional implica varias responsabilidades críticas. Primero, el módulo implementa el mecanismo de retransmisión automática de peticiones cuando no se reciben respuestas en los tiempos establecidos por el protocolo. Esto es especialmente relevante para peticiones sobre UDP, donde los paquetes pueden perderse. Segundo, absorbe retransmisiones duplicadas, evitando que el mismo mensaje se procese múltiples veces. Tercero, genera respuestas de timeout cuando un servidor downstream no responde dentro de los límites temporales configurados.

El módulo mantiene en memoria una estructura de datos para cada transacción activa, que incluye la petición original, información de enrutamiento, timers activos y el estado actual de la transacción. Esta información se mantiene hasta que la transacción se completa, momento en el cual se libera la memoria asociada.

Funciones principales del módulo TM

- t_relay() es la función más utilizada. Envía la petición actual al destino configurado en el Request-URI, activando toda la maquinaria transaccional. Esto incluye el inicio de timers de retransmisión, la preparación de estructuras para recibir respuestas, y el establecimiento del contexto transaccional. Si la petición ya forma parte de una transacción existente (por ejemplo, es una retransmisión), t_relay() la detecta y no crea una transacción duplicada.

- t_newtran() crea explícitamente una nueva transacción sin reenviar el mensaje. Esto es útil cuando necesitas procesar el mensaje localmente o aplicar lógica compleja antes de decidir qué hacer con él. Una vez creada la transacción con t_newtran(), puedes usar otras funciones como t_reply() o t_relay() posteriormente.

- t_reply(code, reason) genera una respuesta SIP directamente desde el script. Por ejemplo, t_reply("486", "Busy Here") envía un código 486 al origen de la petición. Esta función maneja automáticamente todos los detalles del protocolo: construye las cabeceras obligatorias, copia las cabeceras necesarias de la petición original, y envía la respuesta por la ruta correcta.

- t_check_trans() verifica si el mensaje actual ya está siendo manejado por una transacción existente. Retorna verdadero si encuentra una transacción coincidente, lo que permite al script abortar el procesamiento para evitar trabajo duplicado. Esta función es especialmente importante al inicio del script de enrutamiento.

- t_on_failure("route_name") define qué bloque de failure_route se ejecutará si la transacción falla. Una transacción se considera fallida cuando todas las respuestas recibidas son negativas (códigos >= 300) o cuando expiran los timers sin recibir respuesta. Las failure_routes permiten implementar lógicas de failover, donde puedes intentar destinos alternativos o aplicar transformaciones a la petición antes de reintentarla.

- t_on_reply("route_name") especifica un bloque de onreply_route que se ejecutará cada vez que se reciba una respuesta para esa transacción. Esto permite inspeccionar y modificar respuestas en tránsito, útil para manipular SDP, agregar cabeceras personalizadas o aplicar políticas de negocio basadas en las respuestas recibidas.

El flujo de procesamiento en Kamailio con el módulo TM sigue una secuencia específica. Cuando llega una petición SIP, primero se ejecuta el bloque request_route principal sin crear ninguna transacción. En este punto el procesamiento es stateless y puedes realizar validaciones iniciales, consultas a base de datos, autenticación, autorización y cualquier lógica de negocio necesaria. La creación de la transacción ocurre cuando llamas a t_relay(), t_newtran() o implícitamente cuando usas t_reply(). A partir de ese momento, el mensaje pasa a control del módulo TM. Si el mensaje es reenviado con t_relay(), el módulo espera respuestas del downstream y las retransmite hacia el origen.

Las respuestas recibidas disparan los bloques onreply_route si fueron configurados con t_on_reply(). Estos bloques se ejecutan en el contexto de la transacción y tienen acceso tanto a la petición original como a la respuesta recibida. Puedes modificar la respuesta antes de que se reenvíe al cliente. Si todas las respuestas son negativas o hay timeout, se ejecuta el bloque failure_route configurado con t_on_failure(). Aquí puedes implementar lógica de reintentos. Por ejemplo, modificar el Request-URI para apuntar a un servidor alternativo y llamar nuevamente a t_relay(). El módulo TM maneja la complejidad de reutilizar la misma transacción para múltiples intentos de entrega.

El módulo TM tiene varios parámetros que afectan su comportamiento.

fr_timer define el timeout para respuestas finales (por defecto 30 segundos). Si no se recibe ninguna respuesta final en este tiempo, la transacción se considera fallida.

fr_inv_timer es similar pero específico para peticiones INVITE, típicamente configurado con valores mayores (120-180 segundos) porque el establecimiento de llamadas puede tomar más tiempo.

noisy_ctimer controla si el módulo registra en logs cuando expiran los timers. En producción suele desactivarse para reducir el volumen de logs. restart_fr_on_each_reply hace que el timer de respuesta final se reinicie cada vez que llega una respuesta provisional, evitando timeouts prematuros en llamadas que tardan en establecerse.

aggregate_challenges habilita la agregación de desafíos de autenticación cuando se hace fork a múltiples destinos. Sin esto, solo se retransmite la primera respuesta 401/407 recibida, lo que puede causar problemas en escenarios de autenticación complejos.

El módulo TM soporta dos modos principales de operación. En modo stateful, que es el predeterminado al usar t_relay(), se mantiene estado completo de la transacción. Esto consume memoria pero proporciona todas las funcionalidades avanzadas: retransmisiones, timeouts, failure routes, etc.
También existe la posibilidad de hacer reenvío stateless usando la función forward() del módulo core de Kamailio, sin involucrar al módulo TM. Esto consume menos recursos pero no ofrece ninguna de las garantías transaccionales. Es útil solo en escenarios muy específicos donde el volumen de tráfico es extremadamente alto y las funcionalidades avanzadas no son necesarias.

El módulo TM es la base sobre la que funcionan muchos otros módulos de Kamailio. El módulo de accounting (acc) depende del TM para registrar llamadas correctamente, ya que necesita saber cuándo una transacción se completa exitosamente. Los módulos de autenticación se integran con el TM para manejar desafíos 401/407 de forma correcta.
El módulo dialog también depende del TM, ya que los diálogos se crean cuando una transacción INVITE recibe una respuesta 2xx. El módulo registrar utiliza el TM para enviar respuestas 200 OK a los registros y para implementar timeouts en el procesamiento de registros.

Cada transacción activa consume memoria proporcional al tamaño de la petición SIP original más las estructuras de control del módulo. En sistemas con alto volumen de llamadas simultáneas, esto puede sumar varios gigabytes de RAM. El módulo TM limpia automáticamente las transacciones completadas, pero mantiene las estructuras durante un tiempo adicional para absorber retransmisiones tardías.

El procesamiento transaccional añade latencia mínima (microsegundos) pero es necesario para cumplir con el protocolo SIP correctamente. El costo computacional es bajo comparado con los beneficios de tener un proxy robusto que maneja correctamente pérdida de paquetes, timeouts y escenarios de error.
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

October 01, 2025

Andrea Sannucci Diferencia entre $ru y $du en Kamailio: Enrutamiento lógico vs físico
En Kamailio hay dos variables que constantemente generan confusión: $ru y $du. Parecen hacer lo mismo, pero en realidad cumplen funciones completamente distintas. Vamos a aclarar esto de una vez.

La variable $ru: lo que dice el mensaje

$ru es la URI que aparece en el encabezado Request-URI del mensaje SIP. Es la dirección de destino visible para cualquiera que inspeccione el tráfico. Si un usuario marca 1234, verás algo así:

INVITE sip:1234@midominio.com SIP/2.0

Esa URI (sip:1234@midominio.com) es lo que contiene $ru. Todos los proxies por donde pase el mensaje pueden verla y modificarla.

La variable $du: dónde va realmente el paquete

$du (Destination URI) es completamente diferente. No aparece en ningún encabezado SIP. Es una variable interna que le dice a Kamailio: "olvida lo que dice la RequestURI, envía este paquete a esta dirección IP específica".

Por ejemplo, si haces $du = "sip:192.168.1.20:5060", el mensaje se enviará físicamente a ese servidor, aunque la Request-URI diga otra cosa.

Un ejemplo práctico

Supongamos que llega una llamada al número 123456789. Necesitas normalizarlo añadiendo el prefijo internacional (+57) y enviarlo a tu gateway en 200.100.50.10:

$ru = "sip:+57123456789@midominio.com"; $du = "sip:200.100.50.10:5060";

El gateway recibirá un mensaje con la URI ya normalizada, pero el enrutamiento físico lo controlas tú con $du.

El caso más común: Kamailio delante de Asterisk

La mayoría usa Kamailio como SBC (Session Border Controller) delante de Asterisk. En este escenario, no quieres tocar las URIs originales, solo redirigir todo el tráfico a Asterisk:

$du = "sip:192.168.1.20:5060"; route(RELAY);

Con esto, Asterisk recibe los mensajes exactamente como llegaron, pero Kamailio decide que todos van a la IP 192.168.1.20. Asterisk puede procesar su dialplan normalmente porque las URIs están intactas.

Cuándo usar cada una

Hay que modificar $ru cuando el contenido del mensaje debe cambiar: normalización de números, reescritura de dominios, implementación de alias. Todo lo que necesite aparecer en el mensaje SIP.

Hay que modificar $du para controlar el enrutamiento sin tocar el mensaje: balanceo de carga, failover, dirigir tráfico a servidores específicos en tu red. Todo lo que sea infraestructura interna.

Para recordarlo fácilmente

$ru = "¿A quién llamo?" (lógico, visible) $du = "¿Dónde pongo el paquete?" (físico, invisible)

En instalaciones típicas con Asterisk o FreeSWITCH, vas a usar mucho más $du que $ru, precisamente porque quieres mantener las URIs originales mientras controlas hacia dónde va el tráfico en tu red.
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

September 30, 2025

Andrea Sannucci Por qué la IA todavía no domina las configuraciones complejas de Kamailio
En el mundo de las telecomunicaciones VoIP, Kamailio se ha consolidado como uno de los proxies SIP más robustos y versátiles del mercado. Sin embargo, mientras la inteligencia artificial revoluciona múltiples sectores tecnológicos, existe un área donde su capacidad todavía encuentra límites significativos: la configuración avanzada y el ruteo complejo en Kamailio.

Kamailio no es simplemente una herramienta de configuración punto a punto. Es un ecosistema completo que requiere comprensión profunda de protocolos SIP, arquitecturas de red, balanceo de carga, seguridad y optimización de rendimiento. Cada implementación es única, con requisitos específicos que van desde pequeñas empresas hasta carriers con millones de usuarios concurrentes.

La configuración de Kamailio implica trabajar con un lenguaje de scripting propio, módulos especializados y una lógica de ruteo que debe considerar múltiples variables simultáneas: códecs, NAT traversal, failover, clustering, y gestión de bases de datos en tiempo real. Esta complejidad multidimensional presenta desafíos que van más allá de la simple generación de código.

Las herramientas de IA actuales, aunque impresionantes en muchos aspectos, enfrentan limitaciones críticas cuando se trata de Kamailio:

Contexto empresarial específico: Cada organización tiene particularidades en su infraestructura, políticas de seguridad y requisitos de negocio que no pueden ser completamente capturados por un modelo generalizado. La IA puede sugerir configuraciones genéricas, pero raramente comprende las sutilezas de un entorno productivo específico.

Debugging en tiempo real: Cuando un sistema en producción falla a las 3 AM con miles de llamadas activas, se necesita más que conocimiento teórico. La experiencia práctica para identificar rápidamente problemas en logs complejos, entender patrones de tráfico anómalos y aplicar soluciones sin interrumpir el servicio es algo que la IA todavía no puede replicar efectivamente.

Decisiones de arquitectura: Elegir entre diferentes topologías, decidir cuándo implementar un dispatcher versus un carrierroute, o determinar la mejor estrategia de failover requiere años de experiencia viendo qué funciona y qué no en diferentes escenarios. La IA puede recomendar patrones comunes, pero carece del criterio formado por experiencias reales de implementación.

Integración con sistemas antiguos: Muchas implementaciones de Kamailio deben integrarse con sistemas antiguos, bases de datos propietarias o aplicaciones personalizadas. Estas integraciones requieren conocimiento específico que raramente está documentado públicamente y, por tanto, no forma parte del conjunto de entrenamiento de las IA.

La formación en persona para Kamailio ofrece ventajas que ninguna IA puede replicar actualmente:

Interacción dinámica y adaptativa: Un instructor experimentado puede detectar cuando un estudiante no comprende completamente un concepto y ajustar la explicación en tiempo real, usando analogías específicas o ejemplos relevantes para su contexto particular.

Laboratorios prácticos supervisados: Configurar un entorno de pruebas, romperlo intencionalmente y aprender a repararlo bajo supervisión experta proporciona una comprensión profunda que ningún tutorial automatizado puede igualar. Los errores comunes se convierten en oportunidades de aprendizaje invaluables.

Compartir experiencias de campo: Los instructores pueden compartir historias de implementaciones reales, errores costosos evitados y soluciones creativas a problemas complejos. Estas "historias de guerra" contienen lecciones que no aparecen en ningún manual.

Networking profesional: Los cursos presenciales conectan a profesionales que enfrentan desafíos similares. Estas conexiones frecuentemente resultan en colaboraciones futuras y un valioso intercambio de conocimientos que perdura más allá del curso.

Mentoría continua: La relación instructor-estudiante establecida en formaciones presenciales facilita el acceso a mentoría posterior cuando surgen desafíos específicos en implementaciones reales.

Esto no significa que la IA sea inútil en el contexto de Kamailio. Puede ser una herramienta valiosa para generar configuraciones básicas, documentar código existente o sugerir optimizaciones generales. Sin embargo, para implementaciones críticas y complejas, la experiencia humana sigue siendo indispensable.

La verdadera maestría en Kamailio viene de entender no solo el "cómo" sino el "por qué" detrás de cada decisión de configuración. Requiere intuición desarrollada a través de años de experiencia, capacidad para anticipar problemas futuros basándose en patrones sutiles, y la creatividad para diseñar soluciones elegantes a problemas complejos.

Mientras la tecnología continúa evolucionando, la combinación de herramientas de IA como asistentes y la experiencia humana como guía principal representa el enfoque más efectivo. La formación presencial en Kamailio no es solo sobre aprender comandos y configuraciones; es sobre desarrollar la intuición y el criterio que solo vienen de la experiencia compartida y el aprendizaje directo de expertos que han navegado estos desafíos antes.

En un mundo donde la comunicación empresarial depende cada vez más de infraestructuras VoIP confiables, invertir en formación humana especializada no es un lujo, es una necesidad estratégica. La próxima vez que tu sistema de telefonía funcione sin problemas durante una conferencia crítica o maneje elegantemente un pico de tráfico inesperado, probablemente sea gracias a un ingeniero que aprendió sus habilidades no de una IA, sino de otro ser humano que compartió generosamente su experiencia duramente ganada.
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

September 28, 2025

Andrea Sannucci Curso a distancia Kamailio v6.0 – TLS, WebRTC y Balanceo/HA - Cuarta Edición
Del 3 de Noviembre al 30 de Noviembre de 2025 se llevará a cabo la cuarta edición del curso a distancia Kamailio v5.8 TLS/WebRTC y Balanceo/HA, organizado por VozToVoice. Se trata de una formación intensiva de 4 semanas, pensada para ingenieros, programadores y empresas que trabajan en el mundo VoIP y necesitan profesionales capaces de instalar, configurar y administrar una de las plataformas SIP más potentes y flexibles del mercado. Además, en esta edición se incluye una introducción al tema de la inteligencia artificial y su papel emergente en los sistemas de comunicaciones.

El programa combina teoría, práctica, acceso a un VPS individual y sesiones en vivo (con grabación disponible al día siguiente), lo que permite a los estudiantes avanzar a su ritmo con un soporte completo. A lo largo de las semanas se cubren los siguientes ejes:

Preparación del servidor AlmaLinux 10. Instalación y configuración de Kamailio 6.0. Funcionamiento de Kamailio como PBX (registro, llamadas entre extensiones, presencia, mensajería, NAT, WebRTC, TLS/SRTP, integración con Asterisk y FreeSWITCH, grabación y transcodificación con RTPEngine. Uso de Kamailio como balanceador de carga y switch de clase 4 (módulos DISPATCHER, LCR, DROUTING). Integración en escenarios multidominio. Configuración de alta disponibilidad con Keepalived, Pacemaker y Corosync. Administración desde consola web Siremis. Seguridad avanzada (SANITY, PIKE, SECFILTER, TOPOH, TOPOS, Fail2BAN, RATELIMIT). Monitoreo profesional con Homer, Monit, SNMP y Nagios.

El curso incluye 6 videoconferencias en fechas programadas, con temas que van desde la introducción al protocolo SIP hasta la alta disponibilidad, pasando por PBX, WebRTC, balanceo y gestión web. En la sesión de apertura, además de la presentación del curso y del protocolo SIP, se abordará una introducción a la inteligencia artificial aplicada al ámbito de las comunicaciones, ofreciendo a los participantes un panorama de cómo estas tecnologías empiezan a integrarse en entornos VoIP. Cada inscrito en la modalidad completa recibe un servidor virtual privado, acceso a llamadas VoIP salientes, un número geográfico de EE.UU. para pruebas de llamadas entrantes y acceso de por vida a materiales y grabaciones. Existe también la opción de acceso a los materiales con un costo reducido.

El valor es de 250 dólares, 215 euros o 950.000 pesos colombianos, con descuentos disponibles: 10% por pronto pago antes del 26 de Octubre 2025, 15% para empresas que inscriban tres o más empleados, 20% para antiguos estudiantes de VozToVoice y 40% para quienes deseen acceder solamente a los materiales. El cupo es limitado a 10 participantes en modalidad completa y 10 en modalidad acceso materiales.

El profesor es Andrea Sannucci, con certificaciones internacionales como dCAP y SSCA® SIP Training y experiencia en la enseñanza de VoIP a nivel profesional. Al finalizar el curso se entregará un certificado de asistencia de 40 horas avalado por Mesa Proyectos SAS.

La carga horaria estimada es de 10 horas semanales. Por eso, si no es posible dedicar ese tiempo, la recomendación es no inscribirse para evitar perder dinero. Si el objetivo es dominar Kamailio en escenarios modernos de PBX, WebRTC, balanceo y alta disponibilidad con acompañamiento experto y prácticas reales, este curso representa una oportunidad concreta para dar el salto de nivel en el mundo VoIP.

En anexo encuentrn el temario, todas las informaciones relacionadas con el curso, fecha de las 6 videoconferencias y tema de cada una.

Para inscribirse, rellenen el siguiente formulario.

Adjunto Tamaño

programa_curso_kamailio.pdf 163.24 KB
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

Adjunto	Tamaño
programa_curso_kamailio.pdf	163.24 KB

September 18, 2025

Andrea Sannucci Los Errores Más Comunes al Pensar que la IA es la Solución Mágica para VoIP y Programación
La inteligencia artificial ha transformado innumerables industrias, y su potencial es innegable. Sin embargo, en el mundo de las telecomunicaciones VoIP y el desarrollo de software, muchos profesionales y empresas caen en la trampa de ver la IA como una varita mágica que resolverá todos sus problemas. Esta perspectiva no solo es ingenua, sino que puede llevar a implementaciones costosas y fallidas.

Automatización total

Uno de los errores más graves es creer que la IA puede reemplazar completamente el conocimiento técnico especializado. En VoIP, por ejemplo, la configuración de un PBX, el diseño de dial plans, o la optimización de códecs requieren comprensión profunda de protocolos como SIP, RTP, y las particularidades de cada red. La IA puede asistir en el diagnóstico de problemas o en la detección de patrones, pero no puede sustituir el criterio experto necesario para diseñar una arquitectura de telecomunicaciones robusta. En programación, aunque herramientas como GitHub Copilot o ChatGPT pueden generar código funcional, confiar ciegamente en ellas sin entender la lógica subyacente es una receta para el desastre. El código generado por IA frecuentemente contiene vulnerabilidades de seguridad, problemas de rendimiento, o simplemente no se ajusta a los patrones arquitectónicos específicos de tu proyecto.

La falacia del "Plug & Play"

Muchos creen que implementar soluciones de IA es tan simple como activar un servicio y esperar resultados inmediatos.Para VoIP, esto significa entender cómo la IA interpretará los datos de calidad de servicio (QoS), métricas de jitter, pérdida de paquetes, y latencia. No es suficiente alimentar estos datos a un modelo; necesitas contextualizarlos dentro de tu infraestructura específica, considerando factores como el ancho de banda disponible, los patrones de uso de tus usuarios, y las limitaciones de tu hardware. En desarrollo de software, implementar IA requiere considerar la arquitectura existente, los patrones de diseño utilizados, las convenciones del equipo, y los requisitos de seguridad y compliance. Una herramienta de IA que genera código perfecto para una startup ágil puede ser completamente inadecuada para un sistema bancario legacy.

El Problema de la Caja Negra

La IA, especialmente los modelos de aprendizaje profundo, opera como una caja negra. Cuando algo falla en un sistema VoIP crítico, necesitas poder rastrear exactamente qué salió mal. Si tu sistema de enrutamiento de llamadas está basado en decisiones de IA que no puedes auditar o explicar, estás creando un riesgo operacional significativo. Similar situación ocurre en programación: si no entiendes el código que la IA genera, ¿cómo lo depurarás cuando falle? ¿Cómo lo optimizarás? ¿Cómo garantizarás que cumple con los estándares de seguridad de tu organización?

Conocimiento contextual

La IA es una herramienta poderosa, pero no posee conocimiento intrínseco sobre tu negocio específico. En VoIP, cada implementación tiene sus peculiaridades: integraciones con sistemas legacy, requisitos regulatorios específicos del país, necesidades de grabación y cumplimiento normativo. La IA no conoce automáticamente las regulaciones de telecomunicaciones de tu región o los SLAs específicos que has acordado con tus clientes. En programación, la IA no comprende la deuda técnica acumulada en tu base de código, las decisiones arquitectónicas tomadas hace años, o las razones por las cuales ciertas "malas prácticas" son necesarias en tu contexto particular.

El Costo oculto del mantenimiento

Implementar IA no es un proyecto de una sola vez; es un compromiso continuo. Los modelos necesitan reentrenamiento, los datos necesitan limpieza y actualización, y los resultados necesitan monitoreo constante. En VoIP, los patrones de tráfico cambian, aparecen nuevos tipos de ataques, y los usuarios adoptan nuevos comportamientos. Tu IA necesita evolucionar constantemente. En desarrollo, los lenguajes de programación evolucionan, aparecen nuevas bibliotecas, y los patrones de diseño cambian. Una IA entrenada con código de 2023 puede generar soluciones obsoletas o inseguras en 2025.

La realidad: IA como herramienta, no como solución

La IA debe verse como lo que realmente es: una herramienta extraordinariamente poderosa que amplifica las capacidades humanas, no las reemplaza. En VoIP, la IA puede ayudarte a predecir picos de tráfico, detectar fraude, o optimizar rutas de llamadas, pero siempre bajo la supervisión y dirección de ingenieros experimentados. En programación, la IA puede acelerar el desarrollo, sugerir soluciones, y automatizar tareas repetitivas, pero el diseño de sistemas, la arquitectura de software, y las decisiones críticas de negocio siguen requiriendo experiencia humana, creatividad, y comprensión contextual.

Conclusión

El verdadero poder de la IA en VoIP y programación no radica en reemplazar el expertise humano, sino en potenciarlo. Los profesionales que prosperarán en esta nueva era serán aquellos que entiendan tanto las capacidades como las limitaciones de la IA, y que la utilicen como una herramienta más en su arsenal, no como un sustituto de su conocimiento y experiencia. La próxima vez que alguien te proponga "resolver todo con IA", pregúntate: ¿realmente entendemos el problema que estamos tratando de resolver? ¿Tenemos los datos correctos? ¿Podemos mantener y evolucionar esta solución? Y más importante aún, ¿estamos usando la IA para amplificar nuestras capacidades, o estamos intentando usarla para evitar desarrollar las competencias necesarias?
Vota el Articulo:

Sin votos (todavía)

Evalúa la calidad del articulo

Planet SIP

February 27, 2026

Vota el Articulo:

February 26, 2026

Vota el Articulo:

February 24, 2026

Vota el Articulo:

February 20, 2026

Vota el Articulo:

February 18, 2026

Vota el Articulo:

February 17, 2026

Vota el Articulo:

February 11, 2026

Vota el Articulo:

February 02, 2026

Para quién es este curso

Contenido (10 horas - 4 sesiones)

El precio incluye:

Vota el Articulo:

January 29, 2026

Vota el Articulo:

January 14, 2026

Arquitectura del Sistema

Puertos y Protocolos

Proceso de Instalación

Gestión de Usuarios

Control de Spam mediante Expresiones Regulares

Seguridad

Mantenimiento

Resolución de Problemas

Conclusión

Vota el Articulo:

January 13, 2026

Matrix: protocolo abierto, no producto propietario

Element: cliente de referencia

Arquitectura federada: homeservers

Cifrado extremo a extremo: Olm y Megolm

Bridges: interoperabilidad arquitectónica

Federación vs centralización: implicaciones políticas

Adopción institucional

Comparación con competidores

Limitaciones y trade-offs

Modelo económico: open source con capa comercial

Caso de uso: soberanía digital organizacional

Ecosistema de clientes alternativos

Widgets y extensibilidad

Conclusión operacional

Vota el Articulo:

January 10, 2026

Identidad sin vinculación: Session ID

Onion routing: ocultación de análisis de tráfico

Red descentralizada: Service Nodes y swarms

Minimización de metadatos

Trade-offs reconocidos

Sin Perfect Forward Secrecy (temporalmente)

Ausencia de llamadas (limitada)

Sincronización multi-dispositivo limitada

Resistencia a censura y ataques Sybil

Comparación con Signal

Código abierto y auditorías

Adopción y casos de uso

Limitaciones prácticas

Gratuito vs modelo económico

Conclusión operacional

Vota el Articulo:

Cifrado como infraestructura, no como marketing

Soberanía legal: la geografía importa

El modelo de pago como posición ética

Verificación criptográfica de confianza

Penetración y tracción

Limitaciones que son decisiones

Contexto competitivo

Consideraciones técnicas

Conclusión operacional

Vota el Articulo:

January 09, 2026

Puertos Necesarios para Asterisk

Arquitectura de Seguridad

Configuración Paso a Paso