Asterisk vs FreeSWITCH: guía definitiva para tu centralita VoIP en Linux

La centralita VoIP autoalojada sigue siendo uno de esos proyectos que todo sysadmin termina montando en algún momento: entra una llamada, alguien pide un IVR, aparece la conferencia, y de repente tu servidor de pruebas se convirtió en infraestructura de voz real. El mercado open source ofrece dos caminos maduros y muy distintos entre sí: Asterisk, con licencia GPLv2 y un ecosistema de módulos enorme, y FreeSWITCH, más Explicit Transaction Switching, con licencia MPL y una densidad de código que asusta al principio. Elegir mal significa meses de rehacer dialplans.

Esta guía compara ambos con datos verificados contra el código fuente y los avisos oficiales, no contra folletos. Hay dos novedades que cambian la decisión de noviembre de 2026: Asterisk 24.0.0 salió el 5 de noviembre y ya es la LTS vigente, y FreeSWITCH 1.11.3 corrige el CVE-2026-116779, una inyección de comandos vía protocolo SIP MESSAGE que se está explotando en el mundo real. Te muestro a compilar ambos, a configurarlos, a verificar que funcionan y a blindar lo que queda expuesto.

Comparar Asterisk 24 y FreeSWITCH 1.11 antes de compilar nada

La comparación correcta no es “cuál es más ligero” sino “cuál encaja con el equipo que va a mantenerlo”. La tabla siguiente resume las diferencias estructurales, verificadas contra el código fuente de ambos proyectos en sus versiones vigentes al 6 de noviembre de 2026.

Aspecto	Asterisk 24.0.0	FreeSWITCH 1.11.3
Licencia	GPLv2, con licencias alternativas negociadas con Sangoma	MPL-1.1
Lenguaje	C	C con núcleo en C++
Modelo de interrupción	Una función por canal, muchas en paralelo	Explicit Transaction Switching: el núcleo ejecuta un libreto completo por llamada
Pila SIP	PJSIP (chan_pjsip); en la rama 24 el driver chan_sip ya no está en el árbol	Sofia, un solo módulo para señalización y medios
Interfaz de administración	CLI propia, con comando remoto asterisk -rx	fs_cli por Event Socket, además de -x para un solo comando
Paquete en Debian	Sí, pero solo en unstable, forky y experimental; no en bookworm ni trixie	No existe como paquete Debian: hay que compilar
GUI	FreePBX y el panel de Sangoma	La de SignalWire es de pago
Curva de entrada	Suave: los dialplans son cortos	Exigente: XML, API propia y un modelo mental distinto

La recomendación honesta: Asterisk si el objetivo es una centralita que va a crecer con usuarios y un administrador que quiere dormir tranquilo, porque su configuración es declarativa y el ecosistema de módulos de terceros está maduro. FreeSWITCH si ya dominas su modelo y necesitas control fino de la señalización, por ejemplo un carrier o una integración con transcoding pesado. Si estás en ese punto de partida y no hay un equipo de VoIP dedicado, Asterisk con FreePBX es el camino con menos sorpresas.

Instalar Asterisk 24.0.0 desde el código fuente

Asterisk 24.0.0 es la versión LTS vigente, publicada el 5 de noviembre de 2026 junto con 23.6.0, 22.12.0 y 20.22.0. El árbol de la rama 24 ya no incluye el driver chan_sip: la única ruta soportada es PJSIP, que es además la que debes usar para interoperar con operadores modernos.

Clona solo la rama que necesitas. La documentación oficial del proyecto es explícita en que clonar la rama reduce el peso del checkout, y la sintaxis exacta es git clone -b X https://github.com/asterisk/asterisk asterisk-X.

sudo apt update
sudo apt install -y build-essential git wget python3-dev libjansson-dev libxml2-dev libsqlite3-dev libssl-dev libedit-dev uuid-dev libcurl4-openssl-dev libsrtp2-dev
cd /usr/src
git clone -b 24 https://github.com/asterisk/asterisk asterisk-24
cd asterisk-24

Ese primer bloque instala las dependencias de compilación y baja el código. libjansson-dev no es opcional: el configure.ac de la rama 24 exige jansson 2.11 o superior y aborta con un mensaje explícito si no lo encuentra,anca el build de PJSIP.

Ahora el paso que más problemas genera: configure y make menuselect. El target menuselect.makeopts existe en el Makefile de la rama 24 y genera el archivo de selección de módulos; menuselect es el target que abre el menú interactivo. El script oficial de prerrequisitos vive en contrib/scripts/install_prereq y se ejecuta antes del configure para instalar todo lo que falte.

./contrib/scripts/install_prereq install
./configure
make menuselect.makeopts
make menuselect
make -j$(nproc)

Sobre el segundo bloque: install_prereq install resuelve dependencias del sistema y librerías de terceros, configure genera el Makefile y make menuselect abre el menú interactivo para elegir módulos. Si el configure se queja de jansson, hay dos salidas: instalar la librería del sistema, que es lo que ya hiciste con libjansson-dev, o compilar con la copia incluida en el árbol mediante ./configure --with-jansson-bundled, que es la segunda opción que el propio configure.ac sugiere en su mensaje de error. Compilar con make -j$(nproc) es lo que marca la diferencia entre 40 minutos y 8.

La instalación escribe los binarios, las librerías y las muestras de configuración. El target samples copia los archivos .sample al directorio de configuración: pjsip.conf.sample, extensions.conf.sample, rtp.conf.sample, logger.conf.sample y asterisk.conf.sample están todos presentes en la rama 24.

sudo make install
sudo make samples
sudo make basic-pbx
sudo mkdir -p /var/run/asterisk /var/log/asterisk /var/lib/asterisk
sudo chown -R asterisk:asterisk /var/log/asterisk /var/lib/asterisk /var/run/asterisk
asterisk -rx "core show version"

Ese bloque instala, deja una configuración base mínima y comprueba que el daemon responde. El comando asterisk -rx es la vía para ejecutar una orden en la consola remota: la opción -x implica el modo remoto, según el propio asterisk.c de la rama 24. Si responde con la versión, el motor está vivo.

Configurar el trunk SIP y la primera extensión

Con PJSIP la configuración se divide en dos piezas: los pjsip.conf describen los puntos de terminación (trunks y registros) y extensions.conf define a quién llama cada plan de marcado. Es una separación que parece burocracia al principio y ahorra trabajo cuando el proyecto crece.

Define el trunk con transporte TLS contra un operador y una extensión interna. El trick para validar la sintaxis antes de recargar está en el propio Asterisk: pjsip show version viene del módulo res_pjsip y pjsip show endpoints lista los puntos de terminación cargados.

sudo tee /etc/asterisk/pjsip.conf > /dev/null <<'EOF'
[transport-tls]
type=transport
protocol=tls
bind=0.0.0.0:5061
cert_file=/etc/asterisk/keys/asterisk.pem
method=tlsv1_2
[trunk-mi-operador]
type=endpoint
transport=transport-tls
aors=mi-operador
auth_user=centralita
auth_secret=CLAVE_DEL_OPERADOR
outbound_auth=centralita
context=salientes
[mi-operador]
type=aor
contact=sip:pbx.mioperador.com
[centralita]
type=auth
auth_type=userpass
username=centralita
password=CLAVE_DEL_OPERADOR
EOF
sudo tee /etc/asterisk/extensions.conf > /dev/null <<'EOF'
[general]
static=yes
writeprotect=yes
[internos]
exten=>1001,1,Dial(PJSIP/1001,30)
 same => n,Set(CDR(accountcode)="${EXTEN}")
 same => n,Hangup()
EOF

El tee con here-document escribe el archivo sin abrir un editor interactivo, que es la forma correcta de hacerlo dentro de un script de despliegue. Las dos claves auth_secret y password son las que debes cambiar: en un servidor real nunca van en el repositorio.

La extensión interna necesita su propio endpoint en pjsip.conf, porque PJSIP no crea registros implícitos. Añade un bloque [1001] de tipo endpoint con auth_type=userpass y un context que apunte a internos.

sudo asterisk -rx "core reload"
sudo asterisk -rx "pjsip show endpoints"
sudo asterisk -rx "core show uptime"
sudo asterisk -rx "core show channels concise"

Sobre el bloque de verificación: core show uptime y core show channels son comandos del núcleo registrados en main/cli.c de la rama 24, y pjsip show endpoints viene de res/res_pjsip/pjsip_configuration.c. Si el trunk no aparece en la lista, el error real está en el log, no en la consola: revisa /var/log/asterisk/full y busca el mensaje de autenticación fallida del transporte.

Compilar e instalar FreeSWITCH 1.11.3

FreeSWITCH no está empaquetado en Debian: la API de sources.debian.org devuelve 404 para el paquete fuente freeswitch, así que compilar no es una preferencia, es la única vía en Debian. La versión 1.11.3 es la que debes instalar: corrige el CVE-2026-116779 y además elimina el soporte de Debian 11 Bullseye del CI, que es la señal de que el proyecto ya no lo considera una plataforma vigente.

El proceso de compilación tiene tres etapas separadas. bootstrap.sh es el script de arranque y su opción -j lanza los jobs en segundo plano para aprovechar todos los núcleos. La opción -d es algo distinta de lo que suele suponerse: no pasa librerías de SignalWire, sino que restringe qué subdirectorios se compilan (por defecto apr srtp fs).

sudo apt update
sudo apt install -y build-essential git wget autoconf automake libtool pkg-config libsqlite3-dev libssl-dev libcurl4-openssl-dev libspeex-dev libedit-dev libncurses-dev uuid-dev libpq-dev
cd /usr/src
git clone -b v1.11.3 --depth 1 https://github.com/signalwire/freeswitch.git
cd freeswitch
./bootstrap.sh -j

Ese bloque instala las dependencias y ejecuta el bootstrap, que compila apr, srtp y el núcleo. Si instalas el paquete de Debian con apt, el script oficial scripts/packaging/fsget.sh configura el repositorio de SignalWire y deja freeswitch-meta-all listo para instalar; esa vía sí ofrece paquetes binarios, pero exige una cuenta de SignalWire.

El configure define el prefijo de instalación, que en el configure.ac de la rama 1.11.3 aparece como /usr/local/freeswitch. Después el make y el make install escriben el daemon, el fs_cli y las configuraciones de ejemplo.

./configure --prefix=/usr/local/freeswitch
make -j$(nproc)
sudo make install
sudo cp -r conf/vanilla /usr/local/freeswitch/conf
sudo /usr/local/freeswitch/freeswitch -ncwait
sudo /usr/local/freeswitch/fs_cli -x "status"

Sobre ese bloque: -ncwait es la bandera de arranque en modo no interactivo que además espera a que termine la inicialización; en el switch.c de la rama 1.11.3 activa las variables nc y do_wait, mientras que -nc solo arranca sin consola. Y fs_cli -x ejecuta un comando y sale: la opción x existe en el getopt de libs/esl/fs_cli.c con la descripción literal Execute Command and Exit.

La verificación real se hace desde la CLI, con los comandos que registra mod_commands y mod_sofia en la rama 1.11.3.

fs_cli -x "status"
fs_cli -x "sofia status"
fs_cli -x "sofia status profile internal"
fs_cli -x "module_exists mod_sofia"
fs_cli -x "version"

El status viene de mod_commands y el sofia status de mod_sofia, junto con sofia profile y sofia xmlstatus. Si sofia status reporta el perfil interno en 5060 y el externo en 5080, tu stack SIP está escuchando: esos son los valores por defecto en el vars.xml de la configuración vanilla, donde se definen internal_sip_port y external_sip_port.

Cerrar el CVE-2026-116779 antes de exponer el puerto

Este es el punto que separa una guía útil de una peligrosa. En las versiones anteriores a 1.11.3, la función sofia_presence_handle_sip_i_message() partía el usuario destinatario de un MESSAGE SIP entrante por el signo más y tomaba la parte izquierda como selector de protocolo de chat. Al elegir el proto api se llegaba a switch_api_execute(), y un MESSAGE que fuera aceptado podía ejecutar comandos de la API de FreeSWITCH, con los privilegios del daemon.

El advisory oficial describe tres condiciones que se cumplen en una instalación común: el chat entrante está habilitado en los perfiles internos y externos de fábrica, cualquier cuenta autenticada del perfil basta, y el usuario default del directorio vanilla se autentica sin contraseña ni a1-hash. La CVSS v3.1 del CVE-2026-116779 es 9.8, vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, y el advisory confirma explotación en el mundo real. El rango afectado es <= 1.11.2 y el parche está en >= 1.11.3.

El arreglo de la versión 1.11.3 es un parámetro por perfil, enable-chat-api-proto, que queda apagado salvo que lo actives explícitamente. En el código de sofia_presence.c el chequeo ocurre antes de ejecutar el comando y, si el flag está apagado, la petición se rechaza. En los perfiles vanilla viene comentado, con la nota de que solo debe activarse para pares de confianza.

sudo grep -n "enable-chat-api-proto" /usr/local/freeswitch/conf/sip_profiles/internal.xml /usr/local/freeswitch/conf/sip_profiles/external.xml
sudo fs_cli -x "sofia profile internal restart"
fs_cli -x "sofia status profile internal"

El primer comando te muestra el estado real del parámetro en tus archivos. En la configuración vanilla de 1.11.3 la línea aparece comentada, o sea con el flag desactivado, que es justo lo que quieres. Si alguien la descomentó con true, vuelve a comentarla y reinicia el perfil: el cambio no se aplica en caliente. Una verificación más profunda consiste en comprobar que existe un usuario de directorio sin credenciales, que es lo que el advisory señala como la puerta de entrada más cómoda.

sudo ls /usr/local/freeswitch/conf/directory/default/
sudo grep -n -A4 'user id="default"' /usr/local/freeswitch/conf/directory/default/default.xml
sudo mv /usr/local/freeswitch/conf/directory/default/default.xml /usr/local/freeswitch/conf/directory/default/default.xml.disabled
sudo fs_cli -x "reloadxml"

El archivo default.xml del directorio vanilla incluye un usuario default sin contraseña que, según el propio texto de ese archivo, se autentica correctamente y aterriza en el contexto público del perfil externo. Deshabilitarlo y recargar el XML es la segunda mitad de la mitigación. Recuerda que endurecer la autenticación de MESSAGE no basta por sí solo, y que deshabilitar los comandos de API del sistema tampoco cierra la ruta.

Entender los avisos de seguridad de Asterisk de junio 2026

El 25 de junio de 2026, el proyecto Asterisk publicó tres avisos de seguridad en simultáneo, y conviene entenderlos por separado porque tienen vectores de ataque muy distintos. El primero, CVE-2026-57203, es una escalada de privilegios local: ast_loggrabber ejecutaba un script de Python desde /tmp, que es escribible por cualquiera, así que un atacante con una sesión de shell abierta podía dejar su script allí y esperar a que un administrador ejecutara la utilidad con privilegios elevados. La CVSS v4.0 es 6.9, severidad media, y el advisory lo clasifica como “Moderate”.

El segundo, CVE-2026-57193, es una inyección de filtros LDAP a través del nombre de usuario SIP en res_config_ldap: un atacante no autenticado podía disparar consultas LDAP arbitrarias y filtrar información. La CVSS v4.0 es 6.9, también “Moderate”. El módulo res_config_ldap tiene que estar cargado y configurado contra un servidor LDAP, que no es el valor por defecto, pero en un entorno corporativo con Active Directory es exactamente el escenario habitual.

El tercero, CVE-2026-57190, es una inyección SQL en los backends de registro de eventos cel_pgsql y cel_tds a través del campo eventtype de CELGenUserEvent. La CVSS v4.0 es 7.0, severidad alta, y el advisory lo publica como “High”. Los tres avisos comparten los mismos rangos afectados y las mismas versiones corregidas: <= 20.20.0, <= 21.12.2, <= 22.10.0 y <= 23.4.0 quedan parcheados en 20.20.1, 21.12.3, 22.10.1 y 23.4.1, más Certified Asterisk 20.7-cert11 y 22.8-cert3.

sudo asterisk -rx "core show version"
sudo asterisk -rx "module show like res_config_ldap"
sudo asterisk -rx "module show like cel_pgsql"
sudo asterisk -rx "module show like res_cel"

Ese bloque comprueba qué versión corres y qué módulos partidos tienes cargados. El module show like es la forma de confirmar si el vector del CVE-2026-57193 aplica a tu instalación: si res_config_ldap no aparece, la inyección de LDAP no te toca. Y sobre el rango de versiones afectadas: los avisos cubren las series 20, 21, 22 y 23. La rama 24.0.0 es posterior a los cortes de corrección publicados, así que arranca en esa versión con los tres problemas resueltos.

Decidir la instalación: Debian, paquetes o código fuente

Este es el punto donde casi todas las guías fallan, porque repiten la receta de Ubuntu de hace cinco años. La realidad en Debian verificada hoy es esta: el paquete binario asterisk no existe en bookworm ni en trixie. Revisando los índices binarios de main, contrib y non-free de ambas suites, la única coincidencia exacta del nombre de paquete es cero; lo que sí existe son los paquetes de sonidos, como asterisk-core-sounds-en y asterisk-core-sounds-es. El paquete de verdad aparece en unstable, forky y experimental, con la versión 1:22.10.1+dfsg+~cs6.17.60671434-1 en unstable y forky. Bullseye todavía tiene la serie antigua 1:16.28.0~dfsg.

FreePBX tampoco escapa a esto: su instalador oficial comprueba la versión de Debian y admite únicamente bookworm. Sobre esa base, estas son las tres rutas con sus gastos reales.

Ruta	Qué obtienes	Coste
Compilar desde fuente	Exactamente la versión que quieres, con tus módulos	25-40 min, jansson y las dependencias de cada proyecto
Asterisk de unstable/forky	1:22.10.1 listo para instalar con apt	Mezclar suites en producción no es una decisión de sysadmin
FreePBX en bookworm	Asterisk más la interfaz web de administración	Te ata a Debian 12 y a un panel con su propio modelo de permisos

La recomendación para una instalación de producción: compila desde fuente la rama que necesites, o usa una imagen de contenedor con la versión fijada. Con eso el control de versiones es tuyo y no dependes de que una distribución decida qué empaquetar. El coste es que te toca mantener el sistema de build, y eso hay que decirlo claro.

Verificar la centralita en marcha y dejarla sobreviviendo a un reinicio

Un daemon que arranca no es un daemon que funciona. La verificación útil comprueba que el stack SIP escucha, que hay extensiones registradas y que la persistencia está resuelta, porque una centralita que cae con cada reinicio es un teléfono muerto para tus usuarios.

Para Asterisk, la rama 24 trae su propio unit de systemd en contrib/systemd/asterisk.service, y es la referencia que conviene seguir: usa Type=notify, corre como usuario asterisk y recarga con asterisk -rx 'core reload'.

sudo tee /etc/systemd/system/asterisk.service > /dev/null <<'EOF'
[Unit]
Description=Asterisk PBX and telephony daemon.
After=network.target
[Service]
Type=notify
Environment=HOME=/var/lib/asterisk
WorkingDirectory=/var/lib/asterisk
User=asterisk
Group=asterisk
ExecStart=/usr/sbin/asterisk -mqf -C /etc/asterisk/asterisk.conf
ExecReload=/usr/sbin/asterisk -rx 'core reload'
LimitCORE=infinity
Restart=always
RestartSec=4
StandardOutput=null
PrivateTmp=true
[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable --now asterisk
systemctl status asterisk --no-pager

Ese unit es el oficial del proyecto. La combo de flags -mqf de ExecStart significa “consola remota silenciosa, sin fork y con la configuración de /etc/asterisk/asterisk.conf“: sin fork el proceso queda en primer plano, que es lo que systemd espera de un Type=notify. El Restart=always con RestartSec=4 cubre la caída, y el PrivateTmp=true es una defensa extra: aísla el /tmp del daemon, que es justamente el directorio del que habla el CVE-2026-57203.

En FreeSWITCH, la persistencia se resuelve con el propio freeswitch en modo no interactivo, y la configuración de arranque vive en /usr/local/freeswitch/conf/autoload_configs/. La verificación de que todo está en pie incluye el puerto del Event Socket, que en la configuración vanilla escucha en 8021 con la contraseña ClueCon.

sudo ss -lunp | grep -E '5060|5080'
sudo ss -ltnp | grep 8021
fs_cli -x "sofia status"
fs_cli -x "status"
sudo tail -n 50 /usr/local/freeswitch/log/freeswitch.log | grep -i -e sofia -e register

El ss te dice si los sockets están vivos en el kernel, que es un dato que no depende de que el daemon sea amable con la consola. El log vive en el directorio de logs configurado en vars.xml, que en la configuración vanilla apunta al subdirectorio log del prefijo de instalación, y mod_logfile lo compone con el nombre freeswitch.log. Y si cambiaste la contraseña del Event Socket, fs_cli deja de conectar con la de vanilla: edita conf/autoload_configs/event_socket.conf.xml y ponle una contraseña propia antes del primer arranque en producción.

Blindar la centralita expuesta a Internet

Una centralita VoIP es un objetivo atractivo porque los tránks SIP tienen credenciales y porque el protocolo MESSAGE abre una superficie de ataque poco considerada. Los tres ajustes que más reducen el riesgo, en orden de impacto, son estos.

Primero, cambiar las credenciales por defecto. El Event Socket de FreeSWITCH con ClueCon y la contraseña de ejemplo de los certificados de Asterisk son las puertas que se abren primero. Segundo, restringir por ACL quién alcanza el puerto SIP, porque el puerto 5060 abierto a todo el mundo es el que permite los escaneos automatizados. Tercero, activar el transporte TLS y desactivar el registro en claro cuando el operador lo permita.

sudo ufw allow 5060:5061/udp
sudo ufw allow 5060:5061/tcp
sudo ufw allow from 203.0.113.10 to any port 5060 proto udp
sudo ufw allow from 127.0.0.1 to any port 8021 proto tcp
sudo ufw deny 8021/tcp
sudo ufw status numbered
sudo asterisk -rx "pjsip show endpoint trunk-mi-operador"

Sobre ese bloque: la regla deny 8021/tcp bloquea el Event Socket desde fuera, y para que la CLI siga funcionando en local hay que permitirla explícitamente por loopback, como hace la penúltima línea. El ufw evalúa las reglas en orden, así que la regla allow from específica del proveedor tiene que ir antes que la apertura general del puerto 5060, o la primera gana y tu ACL no restringe nada.

Para el lado de Asterisk, la restricción equivalente vive en el propio PJSIP, no en el firewall. Un endpoint con identify por IP y una lista de ACL en la sección acl más un permit por IP del operador limitan quién puede registrarse, y es la defensa que realmente importa porque un atacante que no puede registrarse no puede hacer una llamada.

Y el control que más se olvida: las credenciales de trunk nunca en el archivo de configuración de producción. Asterisk admite #include de un archivo fuera del árbol de configuración, con permisos 600 y propiedad del usuario del daemon, que es el lugar correcto para el secreto.

sudo install -o asterisk -g asterisk -m 600 /dev/null /etc/asterisk/secrets.conf
sudo tee /etc/asterisk/secrets.conf > /dev/null <<'EOF'
[trunk-mi-operador]
auth_secret=CLAVE_REAL_DEL_OPERADOR
EOF
sudo chown asterisk:asterisk /etc/asterisk/secrets.conf
sudo chmod 600 /etc/asterisk/secrets.conf
sudo asterisk -rx "core reload"
sudo asterisk -rx "pjsip show registrations" 2>&1 | head -5

El install con /dev/null como origen crea el archivo vacío con el propietario y los permisos correctos de una sola vez, y el chmod 600 cierra el acceso. La comprobación final con pjsip show registrations confirma si el trunk está registrado contra el operador: si la lista aparece vacía, el problema está en las credenciales o en el transporte, no en el firewall.

Preguntas frecuentes

Lee también

• Organizando Conferencias Virtuales con Herramientas Open Source para Sysadmins Linux
• Guía Definitiva: Configura tu Servidor VPN con WireGuard en Linux Paso a Paso
• IPv6 en tu homelab: SLAAC, NAT66 y primeros pasos para sysadmins Linux
• dnsmasq: servidor DNS y DHCP para tu homelab Linux en 2026