FusionPBX con un SBC: configuración y mejores prácticas

FusionPBX es la interfaz web que la mayoría de los proveedores de servicios eligen cuando necesitan una PBX multi-inquilino basada en FreeSWITCH que se pueda administrar desde un navegador. Una base de datos PostgreSQL, un clúster de FreeSWITCH y una abstracción de dominios que permite que un solo despliegue atienda decenas o cientos de inquilinos. Ese diseño es lo que hace a FusionPBX popular entre MSPs, ITSPs, ILECs y CLECs que operan PBX hospedada como servicio. También es lo que hace que la pregunta sobre el SBC sea diferente de cualquier otro artículo de integración de PBX en este sitio.

La mayoría de los artículos sobre PBX y SBC comienzan con “su PBX no puede terminar diálogos SIP correctamente por sí sola.” FusionPBX no tiene ese problema. FreeSWITCH ya opera como un back-to-back user agent en cada llamada, terminando el diálogo entrante en un sofia profile y originando un nuevo diálogo en otro. La pregunta para los operadores de FusionPBX es más precisa: si FreeSWITCH ya hace lo que un Session Border Controller (SBC) hace a nivel de diálogo SIP, ¿por qué agregar otro B2BUA en el borde de la red?

Este artículo responde esa pregunta, recorre los comportamientos SIP específicos de FusionPBX que un SBC debe manejar en el borde, cubre el patrón de integración multi-inquilino que hace interesantes los despliegues de FusionPBX a escala y presenta el enfoque de configuración para colocar un SBC frente a un clúster de FusionPBX en producción.

FreeSWITCH ya termina SIP. ¿Por qué agregar un SBC?

Esta es la pregunta que separa la historia de integración de FusionPBX de la de FreePBX o 3CX, y merece una respuesta directa.

FreeSWITCH es un B2BUA. En cada llamada, el módulo sofia acepta el INVITE entrante en un perfil, ejecuta la llamada a través del dialplan y origina un nuevo INVITE hacia el destino puenteado en otro perfil. El Call-ID, From-tag y Contact en el tramo saliente son independientes del tramo entrante. Los Re-INVITEs, transferencias y negociación de medios se manejan por tramo. A nivel de diálogo SIP, FreeSWITCH hace lo que hace un SBC B2BUA.

Lo que FreeSWITCH no hace, por diseño, es asumir las preocupaciones operativas que viven en el límite entre una red de voz y la internet pública. Cinco preocupaciones, específicamente.

Seguridad en la capa SIP a nivel de operador

La defensa perimetral opera en una capa diferente a la que el parser sofia de FreeSWITCH fue construido para manejar. La pila sofia acepta un mensaje SIP, lo analiza y lo ejecuta contra la autenticación de dominio antes de rechazarlo. Con cientos de mensajes malformados por segundo provenientes de un escáner coordinado, el parser se convierte en el cuello de botella. La protección contra DoS y DDoS consciente de SIP de un SBC descarta tráfico malformado y fuera de política en el borde, con límites de tasa por método, por origen y por grupo de troncales, antes de que sofia vea el mensaje.

Integración con servicio de firma STIR/SHAKEN

La firma de llamadas no existe de forma nativa en FreeSWITCH ni en FusionPBX. No hay un módulo que llame a TransNexus ClearIP o Neustar, construya un PASSporT, adjunte el encabezado Identity y recurra a un mapa de razón-causa cuando el servicio de firma no está disponible. Los operadores norteamericanos que terminan llamadas sin un encabezado Identity verificado cada vez más degradan la atestación, y el flujo de firma STIR/SHAKEN es una responsabilidad de la capa del SBC.

Normalización SIP por operador a través de múltiples proveedores ascendentes

Las particularidades específicas de cada operador escalan mal dentro de los gateways de FreeSWITCH. Un despliegue de FusionPBX que enruta hacia cuatro operadores termina con cuatro definiciones de gateway, cada una con sus propias anulaciones de cadena de marcado saliente, excepciones de ACL, ajustes de encabezados realizados a través de variables de canal previas a la llamada y condiciones de dialplan que evalúan la rama del operador. El motor de manipulación de encabezados SIP de un SBC maneja la normalización por tramo en un solo lugar con reglas que se pueden editar sin tocar el dialplan.

Ocultación de topología y política de identidad consistente

La presentación en el borde pertenece al borde. FreeSWITCH anuncia su dirección de enlace en los encabezados Contact y Via por defecto, y las soluciones estándar (sip-ip, ext-sip-ip y extra-headers por gateway en sofia) funcionan pero distribuyen la política a través de múltiples fragmentos XML. Un SBC aplica la ocultación de topología de manera consistente para cada llamada saliente sin importar qué inquilino o qué gateway la originó.

Puntuación de fraude antes de que una llamada consuma minutos

La puntuación de riesgo por llamada es la capa faltante más costosa para el MSP de FusionPBX. Una extensión comprometida en cualquier inquilino del clúster puede consumir seis cifras en minutos de tarifa premium en un fin de semana. FreeSWITCH puede aplicar límites por dominio y topes de tasa saliente, pero la puntuación en tiempo real contra un proveedor como TransNexus, SecureLogix o YouMail es una integración de API que hace la capa del SBC, no la capa de la PBX.

El patrón es consistente a través de las cinco preocupaciones. FusionPBX y FreeSWITCH son excelentes como motor de control de llamadas multi-inquilino. El SBC asume la responsabilidad de las preocupaciones del borde que el motor de control de llamadas nunca fue construido para gestionar.

Multi-inquilino por diseño: dominios de FusionPBX y el límite del SBC

El modelo de dominios de FusionPBX es lo que hace que la integración del SBC sea genuinamente diferente de un despliegue de PBX de un solo inquilino. Cada inquilino en FusionPBX es un dominio (por ejemplo, cliente-a.pbx.msp.ejemplo, cliente-b.pbx.msp.ejemplo, y así sucesivamente), y cada extensión, gateway, dialplan, IVR y buzón de correo de voz vive dentro de uno de esos dominios. El mismo proceso de FreeSWITCH los atiende a todos, con el contexto de dominio aplicado por llamada a través de consultas mod_xml_curl contra PostgreSQL.

Ese modelo crea dos patrones de integración de SBC, dependiendo de cómo el MSP quiera manejar las relaciones con operadores.

Mapeo de operador por inquilino se adapta a MSPs donde cada inquilino trae su propio operador, sus propios DIDs, y a veces su propia política de atestación STIR/SHAKEN. El SBC tiene un NAP por inquilino en el lado interno y un NAP por operador de inquilino en el lado ascendente. Las reglas de enrutamiento en el SBC mapean el rango de DID del inquilino a su operador ascendente específico. El aislamiento de inquilinos se aplica en la capa del SBC, no solo dentro de FusionPBX, lo cual importa cuando las credenciales del operador de un inquilino nunca deben llegar al tráfico de otro inquilino.

Mapeo de operador mayorista compartido cubre a MSPs que agregan tráfico en uno o dos operadores mayoristas con su propio inventario de DID. El SBC tiene un NAP por inquilino en el lado interno, pero solo uno o dos NAPs en el lado ascendente sin importar la cantidad de inquilinos. Las reglas de enrutamiento mapean el tráfico saliente de cualquier inquilino al operador mayorista, con la identidad del inquilino transportada a través de P-Asserted-Identity o un encabezado personalizado para conciliación de facturación. La atestación STIR/SHAKEN se aplica uniformemente por el MSP como proveedor de servicio originante.

Ambos patrones funcionan, y los MSPs grandes típicamente ejecutan una combinación de ambos. Lo que ambos dependen es del aislamiento de NAP por inquilino en el SBC. Un solo SBC en el borde con cientos de NAPs (uno por inquilino en el lado de FusionPBX, más NAPs de operadores) colapsa lo que de otro modo serían cientos de endpoints de FusionPBX expuestos individualmente en un solo límite controlado. La referencia de SBC para MSPs cubre la arquitectura multi-inquilino en profundidad.

Comportamientos SIP específicos de FusionPBX que el SBC debe manejar

FusionPBX es la interfaz gráfica. FreeSWITCH es el motor SIP. El SBC se empareja con el módulo sofia de FreeSWITCH, y un puñado de comportamientos de sofia determinan cómo se ve la integración en la práctica.

Enlace del sofia profile y la separación internal/external

FusionPBX tiene por defecto dos sofia profiles. El perfil internal maneja los registros de extensiones (típicamente en UDP/5060 de una dirección interna). El perfil external maneja las troncales (típicamente en UDP/5080 de la misma dirección, o en una interfaz separada). El SBC se conecta al perfil external, no al internal. Este es el primer punto donde las integraciones nuevas fallan: el SBC envía INVITEs a la IP del servidor FusionPBX en el puerto 5060, FusionPBX los espera en el 5080 del perfil external, y la llamada falla antes de que cualquier lógica del dialplan se ejecute. Confirme el puerto de enlace del perfil external y configure el NAP del SBC hacia FusionPBX para que coincida.

Autenticación de gateway y contact-in-ping

Para llamadas salientes, FusionPBX enruta a través de un gateway definido en el perfil external. El gateway le dice a sofia dónde enviar el INVITE, con qué credenciales (si las hay) autenticarse y qué transporte usar. Cuando el SBC es el par ascendente en lugar de un operador, el gateway apunta al SBC y la autenticación generalmente es basada en IP del lado del SBC. La opción de sofia contact-in-ping controla si el encabezado Contact del gateway se incluye en los pings OPTIONS; algunas configuraciones de SBC lo requieren, otras lo rechazan como malformado. Configure el valor para que coincida con lo que el SBC espera.

mod_xml_curl, latencia de dialplan y comportamiento de conmutación por error (failover) del SBC

mod_xml_curl es lo que permite que los cambios en la interfaz de FusionPBX entren en vigor sin reiniciar FreeSWITCH. Cada llamada entrante dispara una consulta HTTP de vuelta al servidor web de FusionPBX para resolver dialplan, directorio y configuración. Bajo carga normal esto es invisible. Bajo presión de PostgreSQL o contención del servidor web, la latencia de la consulta aumenta, y los INVITEs entrantes a FreeSWITCH comienzan a llegar más rápido de lo que el dialplan puede resolverse. El rol del SBC aquí es aplicar temporizadores de sesión y plazos de establecimiento de llamada de su lado, independientemente de FreeSWITCH, para que una consulta lenta de dialplan no se propague como un timeout visible para el operador. La política de reintento saliente por NAP en el SBC absorbe la variación.

Manipulación de encabezados por dialplan vs. normalización por SBC

Los dialplans de FusionPBX pueden establecer variables de canal y agregar encabezados a las llamadas salientes (sip_h_X-Custom, effective_caller_id_name, y más). Hecho con cuidado, esto funciona. Hecho a través de muchos inquilinos y muchos operadores, se convierte en un problema de mantenimiento: cada nueva integración de operador requiere ediciones de dialplan en múltiples lugares, y cada cambio requiere pruebas de regresión a través de los inquilinos. Mover la normalización a la capa del SBC a través de reglas de manipulación de encabezados por NAP consolida el trabajo en un solo lugar y mantiene el dialplan de FusionPBX enfocado en la lógica de llamadas específica del inquilino. El SBC hace el trabajo específico del operador de manera uniforme a través de los inquilinos.

Reenvío de REGISTER y el rol del SBC en el borde para teléfonos hospedados

Algunos despliegues de MSP terminan los registros de teléfonos SIP directamente en FusionPBX a través de la internet pública. Eso funciona, y FreeSWITCH maneja el registro bien, pero coloca al servidor FusionPBX en la internet pública expuesto a escaneo de registros. El patrón más limpio es que el SBC acepte registros en el borde, los reenvíe a FusionPBX a través de su función de reenvío de registros, y aplique protección contra escaneo de registros SIP antes de que cualquier tráfico de escaneo llegue a FusionPBX. La contrapartida es que el SBC necesita escalar el reenvío de registros a la cantidad total de teléfonos, no solo a la cantidad de llamadas activas.

Negociación de códecs y transcodificación

FreeSWITCH transcodifica entre G.711 µ-law, A-law, GSM, G.722 y L16 de forma nativa. Opus es compatible de forma nativa en compilaciones modernas. G.729 y AMR son códecs licenciados que requieren módulos adicionales en FreeSWITCH y, dependiendo del volumen de llamadas, pueden exceder la capacidad de CPU en el mismo host que FusionPBX. La política de códec por tramo del SBC decide qué ve el operador y qué ve el lado de FusionPBX de manera independiente. Cuando el operador quiere solo G.711 y el inquilino usa Opus para clientes WebRTC, la transcodificación puede ejecutarse en la opción de transcodificación por hardware del SBC en lugar de consumir CPU de FusionPBX.

Enfoque de configuración: FusionPBX, SBC, operador

Los menús específicos difieren entre proveedores de SBC y entre versiones de FusionPBX, pero la lógica de integración es la misma en cualquier SBC B2BUA frente a un clúster multi-inquilino de FusionPBX.

1. Planifique la topología y el modelo de inquilinos antes de tocar la configuración. Decida si cada inquilino trae su propio operador o si el MSP agrega en operadores mayoristas. El modelo de inquilinos determina cuántos NAPs necesita en el SBC y cómo se verán las reglas de enrutamiento. FusionPBX se mueve a una interfaz privada (o una subred de nube privada); el SBC toma el rol público.
2. Configure los NAP(s) orientados a FusionPBX en el SBC. Cree un NAP por inquilino de FusionPBX, o un NAP para todo el clúster de FusionPBX si todos los inquilinos comparten un operador mayorista. Apunte cada NAP al perfil sofia external de FusionPBX (típicamente UDP/5080 o TLS/5081), no al perfil internal. Confirme que el puerto de enlace coincida.
3. Configure cada NAP orientado al operador en el SBC. Cree un NAP por operador ascendente con el transporte, lista de códecs, reglas de encabezados y modo de autenticación que especifica la guía de integración del operador. Use los valores publicados por el operador, no los valores predeterminados de FreeSWITCH.
4. Agregue reglas de manipulación de encabezados por tramo. Elimine los P-headers que el operador rechaza, reescriba Contact y Via para ocultación de topología, normalice From y PAI para compatibilidad de atestación STIR/SHAKEN en salida, y aplique límites de tamaño de mensaje SIP donde el operador los requiera.
5. Configure las reglas de enrutamiento entre NAPs. Entrante de cada operador al NAP del inquilino FusionPBX correcto basándose en el rango de DID. Saliente de cada NAP de inquilino FusionPBX al operador apropiado con prioridad y respaldo para que el SBC mueva el tráfico cuando un operador deje de responder.
6. Agregue preservación de identidad del inquilino. Cuando el SBC agrega muchos inquilinos en un operador mayorista, la identidad del inquilino (para facturación, atestación, grabación) se transporta a través de P-Asserted-Identity, un encabezado personalizado o el encabezado From. Configure el SBC para rellenarlo desde el contexto del NAP del inquilino.
7. Agregue capas de seguridad y autenticación de llamadas. Active la protección contra DoS y DDoS, la protección contra escaneo de registros si el SBC reenvía registros a FusionPBX, listas de bloqueados dinámicas, puntuación de fraude telefónico y firma STIR/SHAKEN en el tramo del operador.
8. Reconfigure los gateways de FusionPBX para apuntar al SBC. En la interfaz de FusionPBX bajo Advanced → Gateways, edite cada gateway orientado al operador para que el proxy y registrar (si se usa) apunten a la dirección interna del SBC en lugar de la dirección pública del operador. Las extensiones, dialplans, IVRs y correo de voz no se ven afectados. Recargue mod_sofia para el perfil external.
9. Pruebe llamadas entrantes, salientes y aislamiento de inquilinos bajo conmutación por error (failover). Realice llamadas de prueba desde cada inquilino. Verifique el identificador de llamadas, DTMF, negociación de códec, manejo de transferencias y correo de voz. Interrumpa la señalización del operador primario y confirme que el SBC realiza la conmutación por error sin perder llamadas en curso. Confirme que una llamada realizada desde el inquilino A nunca llega al contexto de dominio del inquilino B en el lado de FusionPBX.

Seguridad en el borde de FusionPBX

FreeSWITCH incluye ACLs basadas en IP, autenticación por dominio y limitación de tasa en la pila sofia. Esos mecanismos funcionan, y la mayoría de los despliegues de FusionPBX en producción los ejecutan. El SBC los complementa con defensas en capas que operan antes de que el tráfico llegue a FreeSWITCH, lo cual es la posición arquitectónica correcta para la protección en la capa SIP a través de muchos inquilinos en un clúster.

• Protección contra escaneo de registros SIP detecta patrones de escaneo en el borde, bloquea el origen automáticamente y nunca reenvía la sonda a FreeSWITCH. Esto importa más cuando el SBC es el reenviador de registros para teléfonos hospedados.
• Mitigación de DoS y DDoS aplica limitación de tasa consciente de SIP por IP de origen, por NAP de inquilino y por método SIP. El parser de sofia no ve el ataque en absoluto cuando el SBC está al frente.
• Detección de fraude telefónico evalúa cada llamada contra prefijo de destino, tasa de llamadas, hora del día e historial de patrones. En un despliegue multi-inquilino de FusionPBX, una extensión comprometida en cualquier inquilino es suficiente para consumir minutos de tarifa premium durante la noche; la puntuación de riesgo por llamada detecta el patrón antes de que FreeSWITCH asigne un canal.
• Ocultación de topología mantiene la IP pública del SBC como la única dirección que el operador ve, sin importar qué host de FreeSWITCH o qué dominio originó la llamada.
• Listas de bloqueados y listas grises dinámicas automatizan la respuesta al abuso detectado sin intervención manual.

El modelo completo de seguridad del SBC cubre el patrón de defensa en capas en profundidad.

STIR/SHAKEN para MSPs de FusionPBX

Para despliegues de FusionPBX que terminan en Norteamérica, la cuestión de STIR/SHAKEN determina cómo se posiciona el MSP con sus operadores ascendentes y, cada vez más, qué tasas de respuesta ve cada inquilino en las llamadas salientes.

FreeSWITCH y FusionPBX no firman llamadas. No existe un módulo nativo para la construcción de PASSporT, ninguna ruta de consulta STI-AS y ninguna inyección de encabezado Identity en la pila sofia. La firma ocurre en la capa del SBC o aguas arriba en el operador.

Para MSPs que poseen su propio token SPC y desean control total de atestación, el SBC maneja la firma por llamada. El nivel de atestación se decide por llamada, no por inquilino, porque un clúster de FusionPBX típicamente transporta tráfico mixto: nivel A para inquilinos minoristas directos donde se verificó KYC, nivel B para números revendidos y nivel C para cualquier inquilino cuya parte llamante no puede ser autenticada. La referencia de atestación STIR/SHAKEN nivel A cubre lo que se requiere para mantener el nivel A a medida que el entorno de políticas ascendente se endurece.

Para MSPs que permiten que un operador mayorista ascendente firme en su nombre, el trabajo del SBC es poblar los encabezados de identidad SIP con precisión para que el operador tenga información correcta sobre la cual basar la atestación. Eliminar o reescribir P-Asserted-Identity en el SBC degradará silenciosamente los resultados de atestación.

En cualquiera de los dos patrones, el SBC se integra con servicios de firma como TransNexus ClearIP y Neustar a través del motor de enrutamiento del SBC, no a través de nada dentro de FusionPBX. Los detalles de implementación se encuentran en la guía de implementación de STIR/SHAKEN para SBC.

Preguntas frecuentes

Conclusión

FusionPBX es una de las mejores opciones del mercado para una PBX hospedada multi-inquilino basada en FreeSWITCH. Sus fortalezas son el modelo de dominios, la interfaz gráfica sobre el motor de control de llamadas de FreeSWITCH y la economía operativa de ejecutar muchos inquilinos en una sola huella de infraestructura. Sus limitaciones se manifiestan en el límite entre esa infraestructura y la internet pública: seguridad en la capa de señalización, firma STIR/SHAKEN, normalización por operador a escala y puntuación de fraude por llamada, todas viven en una capa que FusionPBX no fue diseñado para gestionar. El SBC es lo que asume la responsabilidad de esas preocupaciones sin cambiar cómo FusionPBX maneja inquilinos y llamadas internamente.

Las características decisivas al evaluar un SBC para un despliegue de FusionPBX son la arquitectura B2BUA para control total de encabezados y cifrado en cada tramo, política de transporte y códec por NAP para que cada inquilino y cada operador obtenga el perfil correcto, un modelo abierto de socios STIR/SHAKEN para que la elección del servicio de firma permanezca en manos del MSP, capacidad de NAPs a escala de inquilinos para que un SBC pueda atender a todo el clúster de FusionPBX, y evaluación de autoservicio para que pueda confirmar la integración contra su despliegue real antes de firmar cualquier cosa.