FreeSWITCH + ProSBC: configuración de SIP trunking

FreeSWITCH es una de las plataformas de código abierto más sólidas en el ecosistema de voz. Termina SIP, ancla media, transcodifica códecs, ejecuta planes de marcación completos, reproduce indicaciones de audio, mezcla conferencias, graba llamadas y expone la Event Socket Library (ESL) para el control externo de cada sesión activa. Los equipos que ejecutan FreeSWITCH a escala lo hacen porque ningún otro motor de media de código abierto iguala lo que puede hacer una vez que la llamada está en el servidor.

Sin embargo, FreeSWITCH no es un controlador de borde de sesión (SBC). No incluye la postura de seguridad, la disciplina de cifrado por tramo, la inteligencia de enrutamiento multioperador ni las herramientas de autenticación de llamadas que un SBC real aporta al perímetro de red. Los despliegues que exponen FreeSWITCH directamente a la internet pública heredan una larga lista de tareas para las que la plataforma nunca fue diseñada, y los operadores terminan reconstruyendo esas tareas uniendo reglas de iptables, scripts de fail2ban y código Lua. La arquitectura más limpia es colocar un SBC frente a FreeSWITCH y dejar que cada capa haga su propio trabajo.

Este artículo cubre lo que ProSBC agrega frente a FreeSWITCH, cuándo el módulo mod_sofia integrado de FreeSWITCH es suficiente por sí solo, el comportamiento SIP específico de FreeSWITCH que un SBC debe manejar, y el enfoque de configuración de alto nivel para un despliegue en producción.

FreeSWITCH en el perímetro vs FreeSWITCH detrás de un SBC

La razón más común por la que los equipos buscan esta configuración es que comenzaron con FreeSWITCH directamente en la internet pública y se encontraron con los límites de ese patrón. FreeSWITCH en el perímetro es funcional; miles de despliegues pequeños operan de esa manera. El problema comienza a escala, en jurisdicciones reguladas, o en cualquier lugar donde las expectativas de calidad de llamada y seguridad coinciden con lo que las redes de operadores exigen de sus puntos de interconexión.

Una instancia de FreeSWITCH en el perímetro es el servidor de aplicaciones completo, el motor de media completo y el límite de seguridad completo en un solo proceso. Un escaneo de registros, una inundación de INVITE o tráfico SIP malformado que genera errores de análisis o carga de procesamiento excesiva impactan el mismo kernel que está anclando llamadas en vivo y ejecutando planes de marcación activos. La plataforma nunca fue diseñada para absorber tráfico hostil de forma eficiente; fue diseñada para atender llamadas que ya han sido aceptadas.

El mismo patrón aparece en el lado de interoperabilidad. El módulo mod_sofia de FreeSWITCH negocia SIP y SDP limpiamente con operadores que se comportan correctamente, y recurre a parámetros por gateway cuando no es así. La colección de esos parámetros crece con el tiempo a medida que se agregan operadores, y cada uno se convierte en una pieza operativa crítica. Un SBC traslada esa complejidad fuera del servidor de aplicaciones hacia un dispositivo cuyo trabajo es exactamente normalizar entre dialectos SIP, y le da a FreeSWITCH un único upstream consistente con el cual comunicarse.

El resto de este artículo trata sobre el despliegue de ProSBC como un verdadero SBC B2BUA entre FreeSWITCH y la PSTN. Donde FreeSWITCH es la herramienta correcta (anclaje de media, IVR, conferencias, grabación, control de llamadas mediante ESL), permanece donde corresponde, en el lado LAN del SBC, haciendo lo que mejor sabe hacer.

Lo que ProSBC agrega frente a FreeSWITCH

FreeSWITCH tiene su propio stack SIP y su propio stack de media. La negociación de códecs, el manejo de Contact con reconocimiento de NAT, la gestión básica de registros y los parámetros por gateway viven dentro de mod_sofia. Para un despliegue de un solo operador, bajo volumen y con un proveedor cooperativo, eso es suficiente. ProSBC se vuelve necesario cuando los requisitos fuera de la zona de confort de mod_sofia superan lo que la plataforma FreeSWITCH fue diseñada para absorber.

Enrutamiento multioperador y conmutación por error (failover) como prioridad

FreeSWITCH puede realizar llamadas salientes a través de múltiples gateways, pero la lógica de enrutamiento, las verificaciones de actividad mediante OPTIONS y el comportamiento de failover terminan dispersos entre el plan de marcación, scripts Lua y manejadores de eventos ESL. ProSBC consolida el enrutamiento en un motor basado en reglas con rutas ordenadas por prioridad, verificaciones de salud SIP OPTIONS por NAP y mapeo de causa-razón que avanza la ruta según los códigos de respuesta que deben reintentar y detiene las llamadas según los códigos que no. FreeSWITCH ve un único upstream y descarga la diversidad de operadores al SBC por completo.

Seguridad en el límite de la internet pública

Un servidor FreeSWITCH con una IP pública y un puerto SIP abierto es una de las clases de endpoint más escaneadas en internet. El escaneo de registros SIP, las inundaciones de INVITE y las sondas de fraude telefónico impactan cualquier endpoint SIP accesible por internet dentro de las horas posteriores a su activación. ProSBC absorbe ese tráfico en el perímetro con limitación de tasa por IP de origen y por método con reconocimiento SIP, mitigación automática de ataques DoS y escaneo de registros SIP, lista de bloqueados dinámica con greylisting para respuesta graduada, y puntuación de fraude por llamada antes de que la llamada llegue a FreeSWITCH.

Normalización SIP entre operadores y regiones

Los operadores varían en lo que aceptan, lo que esperan y lo que reescriben silenciosamente. Los P-headers transportan información que un lado requiere y el otro rechaza; los formatos de Contact y From difieren; el orden de oferta de códecs varía; los temporizadores de sesión se comportan de manera diferente entre fabricantes. El motor de manipulación de encabezados SIP de ProSBC normaliza el tramo del lado del operador por NAP sin cambiar cómo FreeSWITCH construye su propio SIP saliente. El plan de marcación se mantiene limpio; las particularidades de cada operador viven en el SBC.

STIR/SHAKEN, CNAM y autenticación de llamadas

Para los despliegues de FreeSWITCH que terminan en Norteamérica, las reglas de autenticación de identificación de llamadas de la FCC continúan endureciéndose y los operadores upstream continúan trasladando las decisiones de atestación a sus clientes mayoristas. El control de atestación, la integración con servicios de firma y la política de bypass para interrupciones pertenecen a la capa del SBC, no dentro del servidor de aplicaciones. ProSBC se integra con servicios de firma STIR/SHAKEN como TransNexus ClearIP y Neustar sobre SIP, con redundancia manejada a través del ordenamiento de rutas y lógica de failover basada en respuestas. Las consultas CNAM y búsquedas LNP se conectan al mismo motor de enrutamiento.

Cuándo mod_sofia de FreeSWITCH es suficiente vs cuándo no lo es

FreeSWITCH es un endpoint SIP perfectamente capaz dentro de sus supuestos de diseño. La arquitectura de hilos divididos maneja bien la concurrencia, el motor de códecs es maduro y los parámetros por gateway cubren la mayoría de las particularidades de los operadores una a la vez. El factor decisivo es si su entorno encaja dentro de lo que mod_sofia fue construido para manejar o si lo ha superado.

Escenario	FreeSWITCH solo	FreeSWITCH con ProSBC
Un solo operador cooperativo, bajo volumen de llamadas, solo usuarios internos	Suficiente	Opcional
Failover multioperador o enrutamiento de menor costo entre regiones	Requiere plan de marcación complejo	Recomendado
Operador con un dialecto SIP no estándar o reglas estrictas de normalización	Ajustes por gateway	Recomendado
Control de atestación STIR/SHAKEN, firma por llamada	No es la capa adecuada	Requerido
Exposición a internet pública con alto riesgo de escaneo y fraude	iptables + fail2ban manual	Requerido
Proveedor de servicios ejecutando FreeSWITCH como plataforma multiinquilino	Instancias por inquilino	NAPs por inquilino en un solo SBC

El patrón en toda la tabla es consistente. FreeSWITCH maneja el interior de su plataforma de voz; el SBC maneja el límite. Tan pronto como el límite desarrolla requisitos que exceden un único troncal cooperativo, el SBC asume esas funciones para que FreeSWITCH pueda seguir haciendo lo que hace bien. Para una discusión más amplia sobre dónde encaja FreeSWITCH en el panorama de código abierto junto a Kamailio y OpenSIPS, consulte nuestro artículo complementario sobre cómo elegir una plataforma SIP.

Comportamiento SIP específico de FreeSWITCH que el SBC debe manejar

La lógica de integración para FreeSWITCH es la misma que para cualquier soft switch, con un puñado de comportamientos específicos de la plataforma que vale la pena señalar. Cada uno de estos vive en mod_sofia o en el plan de marcación de FreeSWITCH y se manifiesta como algo que el SBC tiene que reconocer en el tramo del lado de FreeSWITCH. Si se configuran correctamente, el resto de la configuración encaja en su lugar.

Perfiles SIP, gateways y cómo se mapean a los NAPs de ProSBC

FreeSWITCH organiza su mundo SIP en perfiles (un perfil internal y un perfil external por defecto), cada uno escuchando en su propio puerto con su propia lista de códecs, transporte y entradas de gateway. El patrón más limpio con ProSBC al frente es tratar al SBC como un único gateway en el perfil external, con la elección de autenticación del lado de FreeSWITCH (REGISTER vs basada en IP) decidida según lo que se ajuste a su modelo operativo. Del lado de ProSBC, esa misma conexión se convierte en un único NAP apuntando a la dirección interna del servidor FreeSWITCH, con los NAPs del lado del operador manejados de forma independiente. Cada particularidad específica del operador vive en un NAP de operador, nunca en el NAP de FreeSWITCH.

Preferencia de códecs y la cuestión de la transcodificación

FreeSWITCH ofrece códecs según outbound-codec-prefs, luego negocia el conjunto de media final basándose en la respuesta recibida del lado remoto. Cuando el operador soporta un conjunto de códecs diferente, o prefiere un orden diferente, el SBC normaliza la oferta según la expectativa del operador. Para tráfico dirigido a la PSTN, eso generalmente significa G.711 µ-law o A-law en primera posición, con el SBC eliminando ofertas no PSTN como G.722 u Opus que el operador no negociará. Si una llamada realmente necesita conversión de códec en el perímetro (Opus del lado de FreeSWITCH, G.711 del lado del operador, o AMR-WB entrante desde un operador móvil), la transcodificación por hardware traslada esa carga fuera del servidor FreeSWITCH, donde de otro modo competiría con el anclaje de media y la mezcla de conferencias en la misma CPU.

Reescritura de Contact, Via y Record-Route

FreeSWITCH coloca su propia IP externa o nombre de host en los encabezados Contact y Via, con NDLB-force-rport y los flags relacionados NDLB-* (No Default Loopback Behavior) ajustando qué tan estrictamente mod_sofia respeta el puerto y dirección de origen en las respuestas. El SBC comúnmente reescribe los encabezados Contact, Via y relacionados con enrutamiento según la política de ocultación de topología antes de reenviar el tráfico saliente, y revierte la reescritura en el camino de regreso para que FreeSWITCH vea una dirección a la que pueda enrutar. La ocultación de topología en el SBC maneja esto de forma transparente, evitando que el operador vea el direccionamiento interno de FreeSWITCH y previniendo fallos de ruta causados por direcciones privadas que se filtran al exterior.

Transferencia de fax T.38 y el re-INVITE a mitad de llamada

FreeSWITCH soporta T.38 a través de mod_spandsp, con el modo gateway T.38 conectando T.38 en un tramo a passthrough G.711 en el otro. Todo el patrón depende de un re-INVITE a mitad de llamada que intercambia el flujo de audio por un flujo T.38 una vez que se detectan tonos de fax. Algunos operadores aceptan el re-INVITE limpiamente; otros lo rechazan, agotan el tiempo de espera o eliminan los atributos SDP que hacen funcionar T.38. El SBC maneja el comportamiento por NAP aquí: retransmisión T.38 donde el operador acepta T.38, passthrough G.711 con un perfil seguro para fax (cancelación de eco desactivada, jitter buffer estático, VAD desactivado) donde no lo acepta, y reescritura limpia de SDP en ambas direcciones. La mecánica completa de cómo negocia T.38 y dónde falla comúnmente se cubre en nuestra referencia de Fax sobre IP (T.38).

REFER, transferencia atendida y la alternativa bridge

FreeSWITCH implementa transferencias de llamada ya sea a través de SIP REFER (cuando es iniciado por un endpoint que envía uno) o a través del mecanismo bridge del plan de marcación, que mantiene el tramo de llamada en FreeSWITCH y origina uno nuevo. Los operadores varían en si aceptan REFER. El SBC tiene dos comportamientos correctos: pasar REFER si el operador lo soporta, o reemplazar REFER con un re-INVITE dentro del SBC para que el operador nunca vea REFER. Configure esto por NAP según lo que cada operador upstream acepte, y FreeSWITCH nunca tiene que saber qué operador está del otro lado.

Temporizadores de sesión y cortes silenciosos de llamada

FreeSWITCH utiliza temporizadores de sesión SIP (RFC 4028) cuando está configurado para ello (enable-timer, session-timeout), y los ignora en caso contrario. El SBC tiene que negociar valores de temporizador compatibles en cada tramo, refrescando hacia FreeSWITCH en la cadencia esperada y hacia el operador en lo que el operador requiera. Los temporizadores desalineados causan cortes silenciosos de llamada a mitad de conversación, que se leen como aleatorios e intermitentes en los logs de FreeSWITCH porque la falla está ocurriendo un salto más allá. Configurar los temporizadores de manera consistente en el SBC elimina esa clase de error por completo.

Enfoque de configuración: FreeSWITCH, SBC, operador

Los menús específicos difieren entre fabricantes de SBC, pero la lógica de integración es la misma en cualquier SBC B2BUA. El objetivo son dos trunk groups limpios (uno hacia FreeSWITCH, uno hacia cada operador) con el SBC conectándolos y manejando cada transformación intermedia. El lado de FreeSWITCH de la configuración es intencionalmente simple; el SBC absorbe todo lo que de otro modo viviría en parámetros por gateway a lo largo de mod_sofia.

1. Planifique la topología antes de tocar la configuraciónDecida dónde se ubica ProSBC: en el mismo VPC en la nube que FreeSWITCH, en una VM separada en el mismo centro de datos, o en una región de nube dedicada frente a un clúster FreeSWITCH on-premises. Confirme el direccionamiento de IP pública, DNS y el aprovisionamiento de certificados TLS para ProSBC. El servidor FreeSWITCH mantiene su direccionamiento LAN existente; ProSBC asume el rol público y el tráfico ESL continúa terminando en el lado LAN de FreeSWITCH donde siempre ha estado.
2. Configure el NAP del lado de FreeSWITCH en ProSBCCree un NAP apuntando a la dirección interna del servidor FreeSWITCH. Haga coincidir el transporte para el que mod_sofia está configurado en su perfil external (UDP, TCP o TLS) en el puerto acordado. Decida si FreeSWITCH se autentica por IP o por credenciales REGISTER, y configure el NAP en consecuencia. Mantenga este NAP simple: las reglas de encabezados, políticas de códecs y ajustes de seguridad pertenecen a los NAPs del lado del operador.
3. Configure cada NAP del lado del operador en ProSBCCree un NAP por operador upstream. Establezca transporte, lista de códecs, reglas de encabezados y modo de autenticación según lo que especifique la guía de integración del operador. Si el operador proporciona IPs de señalización redundantes, agrúpelas bajo un NAP con ordenamiento de rutas primaria y secundaria y un heartbeat SIP OPTIONS configurado para detección de actividad.
4. Agregue reglas de manipulación de encabezados por tramoElimine los P-headers y campos propietarios que el operador no aceptará en el tráfico saliente de FreeSWITCH. Reescriba Contact y Via con la dirección pública de ProSBC. Normalice From y PAI para que coincidan con el formato esperado por el operador para la atestación STIR/SHAKEN. Nada de esto requiere cambiar la configuración propia de FreeSWITCH.
5. Configure las reglas de enrutamiento entre NAPsDefina reglas entrantes desde cada operador hacia el NAP de FreeSWITCH, y reglas salientes desde el NAP de FreeSWITCH hacia el operador apropiado según prefijo de destino, hora del día o cualquier otro criterio. Agregue reglas de respaldo para interrupciones del operador, de modo que una llamada denegada en la ruta primaria avance a la secundaria. El mapeo de causa-razón maneja qué códigos de respuesta deben reintentar y cuáles deben detener la llamada.
6. Incorpore seguridad y autenticación de llamadasHabilite la protección contra DoS/DDoS y la protección contra escaneo de registros SIP en los troncales del lado del operador. Configure lista de bloqueados dinámica y puntuación de fraude telefónico. Para tráfico dirigido a EE.UU., conecte la firma STIR/SHAKEN a través de su proveedor STI-AS elegido, con rutas primarias y secundarias para el servicio de firma en sí y un mapa de causa-razón que avance la ruta en 404 y detenga las llamadas en 603 según el patrón de integración SIP de producción.
7. Reconfigure FreeSWITCH para comunicarse con ProSBC en lugar de los operadores directamenteEn FreeSWITCH, edite las entradas de gateway relevantes en conf/sip_profiles/external/ para que cada una apunte a ProSBC en lugar de a la dirección del operador. Las preferencias de códecs y configuraciones de proxy a nivel de gateway se simplifican sustancialmente porque el SBC absorbe todo lo específico del operador. Recargue mod_sofia o reescanee el perfil afectado en lugar de reiniciar FreeSWITCH si puede evitar la interrupción.
8. Pruebe en ambas direcciones y bajo failoverRealice llamadas de prueba entrantes y salientes. Verifique la presentación de identificación de llamadas, la negociación de códecs, DTMF (RFC 2833 / RFC 4733), el manejo de transferencias y la entrega de fax si se utiliza. Luego interrumpa deliberadamente la accesibilidad de señalización del operador primario y confirme que ProSBC mueve el tráfico a la ruta secundaria en el cronograma que dictan los SIP OPTIONS. Observe la salida de sofia.status y sofia.profile.external.status de FreeSWITCH durante el failover para confirmar que el lado de FreeSWITCH se mantiene estable en todo momento.

Qué buscar en un SBC para FreeSWITCH

Las características que califican a un SBC compatible con FreeSWITCH son las mismas que hacen que cualquier SBC sea bueno en interoperabilidad multifabricante, con algunas consideraciones adicionales específicas de operar frente a un servidor de aplicaciones de código abierto. Trate la siguiente lista como un checklist al evaluar opciones.

Arquitectura B2BUA, no un proxy SIP

Un proxy SIP no puede hacer este trabajo. Reescribir Contact y Via, reemplazar REFER con re-INVITE, convertir RTP a SRTP y firmar llamadas salientes con STIR/SHAKEN requieren que el SBC termine y reorigine cada diálogo de forma independiente. Una arquitectura B2BUA es el requisito base.

Enrutamiento programable que se adapta a FreeSWITCH en sus propios términos

Los operadores de FreeSWITCH tienden a esperar programabilidad, porque eso es lo que la plataforma misma ofrece a través de ESL, Lua y el plan de marcación. Un SBC emparejado con FreeSWITCH debería ofrecer un nivel comparable de control de su lado. La API de enrutamiento Ruby de ProSBC expone el contexto completo de la llamada a scripts externos en tres etapas de filtro (before_filter, after_filter, after_remap_filter), con módulos preconstruidos para firma STIR/SHAKEN, TransNexus ClearIP, SecureLogix, YouMail y Neustar. El modelo de integración está diseñado para el mismo tipo de operador que ya gestiona plan de marcación y código ESL del lado de FreeSWITCH.

TLS, SRTP y reglas de encabezados por NAP

Busque un SBC donde cada NAP tenga su propia configuración de transporte, su propia lista de códecs y su propio perfil de manipulación de encabezados. Eso es lo que permite que un operador esté en UDP/5060 con G.711 mientras otro está en TLS/5061 con SRTP, y FreeSWITCH detrás de ambos reciba una presentación consistente independientemente de qué operador manejó la llamada.

Integración abierta con socios STIR/SHAKEN

STIR/SHAKEN en el SBC no debería atarlo a un solo servicio de firma. ProSBC se integra con TransNexus ClearIP y Neustar sobre SIP actualmente, y con cualquier proveedor STI-AS que exponga una API HTTPS cuando sea necesario. La atestación se decide por llamada dentro del motor de enrutamiento en lugar de por troncal como configuración estática, que es lo que la regla de certificado propio de la FCC asume cuando una sola plataforma maneja tráfico de múltiples inquilinos.

Flexibilidad de despliegue que iguala la flexibilidad de FreeSWITCH

FreeSWITCH se ejecuta en Linux en prácticamente cualquier entorno. El SBC debería ejecutarse dondequiera que su topología realmente coloque el perímetro: AWS, Azure, VMware, KVM/Proxmox o bare metal. Un SBC nativo en la nube co-ubicado con un FreeSWITCH alojado en la nube minimiza la latencia entre los dos; un SBC virtualizado en el mismo hipervisor que un FreeSWITCH on-premises mantiene todo el stack de voz en infraestructura propiedad del cliente.

Evaluación autoservicio

La mejor manera de confirmar que un SBC maneja FreeSWITCH correctamente es pasar tráfico a través de él. Una licencia de evaluación gratuita y autoservicio le permite levantar el SBC junto a una instancia de prueba de FreeSWITCH y validar cada comportamiento listado anteriormente antes de comprometerse.

Seguridad en el perímetro de FreeSWITCH

FreeSWITCH tiene sus propias protecciones, incluyendo filtrado basado en ACL y límites de tasa a nivel de mod_sofia. El SBC complementa esas protecciones con defensas en capas que operan antes de que el tráfico llegue a FreeSWITCH, que es la posición arquitectónica correcta para la protección a nivel SIP. Todo lo que FreeSWITCH nunca tiene que examinar es CPU que no tiene que gastar decidiendo qué hacer con ello.

Protección contra escaneo de registros SIP

El ataque más común contra un servidor FreeSWITCH en internet pública es una inundación lenta de REGISTER que sondea extensiones válidas o contraseñas débiles. ProSBC detecta patrones de escaneo por frecuencia y distribución de origen, bloquea la fuente automáticamente y nunca reenvía la sonda a FreeSWITCH. El greylisting con respuesta basada en porcentaje permite al SBC investigar fuentes sospechosas gradualmente en lugar de bloquearlas y desbloquearlas en ciclos alternos.

Mitigación de DoS y DDoS

Las inundaciones volumétricas de INVITE y OPTIONS que consumirían el pool de conexiones de FreeSWITCH se limitan primero en la capa del SBC. La limitación de tasa con reconocimiento SIP por IP de origen, por trunk group y por método SIP descarta el tráfico malicioso antes de que consuma la capacidad de manejo de llamadas de FreeSWITCH.

Detección de fraude telefónico en el tramo del lado del operador

La marcación internacional a números de tarifa premium es el mayor riesgo de exposición de facturación en cualquier endpoint SIP. ProSBC aplica una puntuación de riesgo por llamada considerando prefijo de destino, tasa de llamadas, hora del día e historial de patrones, y bloquea la llamada o la enruta para revisión antes de que salga por el troncal del lado del operador. La integración con socios de detección de fraude validados como TransNexus y YouMail se conecta al mismo motor de enrutamiento.

Ocultación de topología para el servidor FreeSWITCH

La IP pública de ProSBC es la única dirección que el operador ve. El nombre de host interno de FreeSWITCH, su dirección privada, la estructura de la LAN detrás de él y cualquier sistema back-end conectado por ESL permanecen invisibles desde el lado del operador. Eso reduce la superficie de ataque a un único límite bien defendido en lugar del servidor de aplicaciones en sí.

Preguntas frecuentes

Conclusión

FreeSWITCH es una plataforma de código abierto capaz dentro de sus supuestos de diseño. Con un solo operador cooperativo y un entorno contenido, no necesita nada frente a él. Más allá de ese punto, las preguntas de integración se acumulan: diversidad de operadores, perfiles SIP personalizados, atestación en industrias reguladas, exposición a internet pública, entrega de servicio multiinquilino. Cada una de esas preguntas se resuelve limpiamente con un SBC en el perímetro.

Las características decisivas al evaluar un SBC para FreeSWITCH son la arquitectura B2BUA para control total de encabezados, política de transporte y códecs por NAP, enrutamiento programable que se adapta a los operadores de FreeSWITCH en sus propios términos, un modelo abierto de socios STIR/SHAKEN y evaluación autoservicio para confirmar que la integración funciona antes de firmar nada. Si se cumplen esas condiciones, el SBC hace su trabajo silenciosamente durante años mientras FreeSWITCH continúa haciendo lo que hace bien.