FusionPBX avec un SBC : configuration et bonnes pratiques

FusionPBX est l’interface web vers laquelle se tournent la plupart des fournisseurs de services lorsqu’ils veulent un PBX multi-locataire basé sur FreeSWITCH, gérable depuis un navigateur. Une base de données PostgreSQL, un cluster FreeSWITCH et une abstraction par domaine qui permet à un seul déploiement de servir des dizaines ou des centaines de locataires. C’est cette conception qui rend FusionPBX populaire auprès des MSP, ITSP, ILEC et CLEC offrant un PBX hébergé en tant que service. C’est aussi ce qui rend la question du SBC différente de chaque autre article d’intégration PBX sur ce site.

La plupart des articles PBX-plus-SBC commencent par « votre PBX ne peut pas terminer les dialogues SIP proprement par lui-même ». FusionPBX n’a pas ce problème. FreeSWITCH fonctionne déjà comme un back-to-back user agent sur chaque appel, terminant le dialogue entrant sur un profil sofia et originant un nouveau dialogue sur un autre. La question pour les opérateurs FusionPBX est plus précise : si FreeSWITCH fait déjà ce qu’un contrôleur de session en périphérie (SBC) fait au niveau du dialogue SIP, pourquoi ajouter un autre B2BUA en bordure de réseau ?

Cet article répond à cette question, détaille les comportements SIP spécifiques à FusionPBX qu’un SBC doit gérer en bordure, couvre le modèle d’intégration multi-locataire qui rend les déploiements FusionPBX intéressants à grande échelle, et présente l’approche de configuration pour placer un SBC devant un cluster FusionPBX en production.

FreeSWITCH termine déjà le SIP. Pourquoi ajouter un SBC ?

C’est la question qui distingue l’intégration FusionPBX de celle de FreePBX ou 3CX, et elle mérite une réponse directe.

FreeSWITCH est un B2BUA. Sur chaque appel, le module sofia accepte l’INVITE entrant sur un profil, exécute l’appel à travers le plan de numérotation et origine un nouvel INVITE vers la destination pontée sur un autre profil. Le Call-ID, le From-tag et le Contact sur le segment sortant sont indépendants du segment entrant. Les re-INVITE, les transferts et la négociation média sont gérés par segment. Au niveau du dialogue SIP, FreeSWITCH fait ce qu’un SBC B2BUA fait.

Ce que FreeSWITCH ne fait pas, par conception, c’est assumer les préoccupations opérationnelles qui se situent à la frontière entre un réseau voix et l’internet public. Cinq préoccupations, précisément.

Sécurité de la couche SIP au débit opérateur

La défense en bordure opère à un niveau différent de celui pour lequel le parseur sofia de FreeSWITCH est conçu. La pile sofia accepte un message SIP, l’analyse et le soumet à l’authentification de domaine avant de le rejeter. À des centaines de messages malformés par seconde provenant d’un scanner coordonné, le parseur devient le goulet d’étranglement. La protection DoS et DDoS orientée SIP d’un SBC rejette le trafic malformé et hors politique en bordure, avec des limites de débit par méthode, par source et par trunk group, avant que sofia ne voie le message.

Intégration du service de signature STIR/SHAKEN

La signature des appels n’existe pas nativement dans FreeSWITCH ni dans FusionPBX. Aucun module n’appelle TransNexus ClearIP ou Neustar, ne construit un PASSporT, n’attache l’en-tête Identity et ne bascule via une carte de cause-motif lorsque le service de signature est injoignable. Les opérateurs nord-américains terminant sans en-tête Identity vérifié dégradent de plus en plus l’attestation, et le flux de signature STIR/SHAKEN relève de la couche SBC.

Normalisation SIP par opérateur à travers plusieurs fournisseurs amont

Les particularités de chaque opérateur passent mal à l’échelle dans les passerelles FreeSWITCH. Un déploiement FusionPBX routant vers quatre opérateurs se retrouve avec quatre définitions de passerelle, chacune avec ses propres surcharges de chaîne de numérotation sortante, exceptions ACL, ajustements d’en-tête via des variables de canal pré-appel et conditions de plan de numérotation testant la branche opérateur. Le moteur de manipulation d’en-têtes SIP d’un SBC gère la normalisation par segment en un seul endroit avec des règles modifiables sans toucher au plan de numérotation.

Masquage de topologie et politique d’identité cohérente

La présentation en bordure doit se faire en bordure. FreeSWITCH annonce son adresse de liaison dans les en-têtes Contact et Via par défaut, et les contournements standard (sip-ip, ext-sip-ip et extra-headers par passerelle dans sofia) fonctionnent mais distribuent la politique à travers plusieurs fragments XML. Un SBC applique le masquage de topologie de manière cohérente pour chaque appel sortant, quel que soit le locataire ou la passerelle d’origine.

Évaluation de la fraude avant qu’un appel ne consomme des minutes

L’évaluation du risque par appel est la couche manquante la plus coûteuse pour les MSP FusionPBX. Un poste compromis dans n’importe quel locataire du cluster peut consommer des centaines de milliers d’euros en minutes surtaxées en un week-end. FreeSWITCH peut appliquer des limites par domaine et des plafonds de débit sortant, mais l’évaluation en temps réel auprès d’un fournisseur comme TransNexus, SecureLogix ou YouMail nécessite une intégration API que la couche SBC réalise, pas la couche PBX.

Le schéma est cohérent sur les cinq préoccupations. FusionPBX et FreeSWITCH excellent en tant que moteur de contrôle d’appels multi-locataire. Le SBC prend la responsabilité des préoccupations de bordure que le moteur de contrôle d’appels n’a jamais été conçu pour assumer.

Multi-locataire par conception : domaines FusionPBX et frontière SBC

Le modèle de domaines de FusionPBX est ce qui rend l’intégration SBC véritablement différente d’un déploiement PBX mono-locataire. Chaque locataire dans FusionPBX est un domaine (par exemple, customer-a.pbx.msp.example, customer-b.pbx.msp.example, etc.), et chaque poste, passerelle, plan de numérotation, IVR et boîte vocale réside dans l’un de ces domaines. Le même processus FreeSWITCH les sert tous, avec le contexte de domaine appliqué par appel via des requêtes mod_xml_curl vers PostgreSQL.

Ce modèle crée deux schémas d’intégration SBC, selon la manière dont le MSP souhaite gérer les relations opérateur.

Mappage opérateur par locataire convient aux MSP où chaque locataire apporte son propre opérateur, ses propres DID, et parfois sa propre politique d’attestation STIR/SHAKEN. Le SBC dispose d’un NAP par locataire côté interne et d’un NAP par opérateur de locataire côté amont. Les règles de routage sur le SBC associent la plage de DID du locataire à son opérateur amont spécifique. L’isolation des locataires est appliquée au niveau du SBC, pas seulement dans FusionPBX, ce qui compte lorsque les identifiants opérateur d’un locataire ne doivent jamais atteindre le trafic d’un autre locataire.

Mappage opérateur wholesale partagé couvre les MSP qui agrègent le trafic sur un ou deux opérateurs wholesale avec leur propre inventaire de DID. Le SBC dispose d’un NAP par locataire côté interne, mais d’un ou deux NAP seulement côté amont, quel que soit le nombre de locataires. Les règles de routage acheminent les appels sortants de n’importe quel locataire vers l’opérateur wholesale, l’identité du locataire étant transportée via P-Asserted-Identity ou un en-tête personnalisé pour la réconciliation de facturation. L’attestation STIR/SHAKEN est appliquée uniformément par le MSP en tant que fournisseur de service d’origine.

Les deux schémas fonctionnent, et les grands MSP exécutent généralement un mélange des deux. Ce dont tous deux dépendent est l’isolation par NAP et par locataire au SBC. Un seul SBC en bordure avec des centaines de NAP (un par locataire côté FusionPBX, plus les NAP opérateur) consolide ce qui serait autrement des centaines de points d’entrée FusionPBX exposés individuellement en une seule frontière contrôlée. La référence SBC pour les MSP couvre l’architecture multi-locataire en détail.

Comportements SIP spécifiques à FusionPBX que le SBC doit gérer

FusionPBX est l’interface. FreeSWITCH est le moteur SIP. Le SBC dialogue avec le module sofia de FreeSWITCH, et quelques comportements de sofia façonnent ce à quoi ressemble l’intégration en pratique.

Liaison de profil sofia et la séparation internal/external

FusionPBX utilise par défaut deux profils sofia. Le profil internal gère les enregistrements de postes (typiquement sur UDP/5060 d’une adresse interne). Le profil external gère les trunks (typiquement sur UDP/5080 de la même adresse, ou sur une interface séparée). Le SBC se connecte au profil external, pas au profil internal. C’est le premier piège des nouvelles intégrations : le SBC envoie des INVITE vers l’IP du serveur FusionPBX sur le port 5060, FusionPBX les attend sur le port 5080 du profil external, et l’appel échoue avant toute logique de plan de numérotation. Vérifiez le port de liaison du profil external et configurez le NAP côté FusionPBX du SBC en conséquence.

Authentification de passerelle et contact-in-ping

Pour les appels sortants, FusionPBX route via une passerelle définie dans le profil external. La passerelle indique à sofia où envoyer l’INVITE, quels identifiants utiliser (le cas échéant) pour l’authentification et quel transport employer. Lorsque le SBC est le pair amont au lieu d’un opérateur, la passerelle pointe vers le SBC et l’authentification est généralement basée sur l’IP côté SBC. L’option sofia contact-in-ping contrôle si l’en-tête Contact de la passerelle est inclus dans les pings OPTIONS ; certaines configurations SBC l’attendent, d’autres le rejettent comme malformé. Réglez la valeur pour correspondre à ce que le SBC attend.

mod_xml_curl, latence du plan de numérotation et comportement de basculement du SBC

mod_xml_curl est ce qui permet aux modifications dans l’interface FusionPBX de prendre effet sans redémarrage de FreeSWITCH. Chaque appel entrant déclenche une requête HTTP vers le serveur web FusionPBX pour résoudre le plan de numérotation, le répertoire et la configuration. Sous charge normale, c’est invisible. Sous pression PostgreSQL ou contention du serveur web, la latence de la requête augmente et les INVITE entrants vers FreeSWITCH arrivent plus vite que le plan de numérotation ne peut être résolu. Le rôle du SBC ici est d’appliquer des temporisateurs de session et des délais d’établissement d’appel de son côté, indépendamment de FreeSWITCH, afin qu’une résolution de plan de numérotation lente ne se propage pas comme un délai d’expiration visible côté opérateur. La politique de réessai sortant par NAP du SBC absorbe la variance.

Manipulation d’en-têtes pilotée par le plan de numérotation vs. normalisation pilotée par le SBC

Les plans de numérotation FusionPBX peuvent définir des variables de canal et ajouter des en-têtes aux appels sortants (sip_h_X-Custom, effective_caller_id_name, etc.). Réalisé soigneusement, cela fonctionne. Réalisé à travers de nombreux locataires et de nombreux opérateurs, cela devient un problème de maintenance : chaque nouvelle intégration opérateur nécessite des modifications de plan de numérotation à plusieurs endroits, et chaque changement exige des tests de régression à travers les locataires. Déplacer la normalisation vers la couche SBC via des règles de manipulation d’en-têtes par NAP consolide le travail en un seul endroit et maintient le plan de numérotation FusionPBX centré sur la logique d’appel spécifique au locataire. Le SBC effectue le travail spécifique à l’opérateur de manière uniforme à travers les locataires.

Transfert de REGISTER et rôle de bordure du SBC pour les téléphones hébergés

Certains déploiements MSP terminent les enregistrements SIP des téléphones directement sur FusionPBX via l’internet public. Cela fonctionne, et FreeSWITCH gère bien les enregistrements, mais cela expose le serveur FusionPBX sur l’internet public au balayage d’enregistrement. Le schéma plus propre consiste à ce que le SBC accepte les enregistrements en bordure, les transfère à FusionPBX via sa fonctionnalité de transfert d’enregistrement, et applique la protection contre le balayage d’enregistrement SIP avant que tout trafic de balayage n’atteigne FusionPBX. Le compromis est que le SBC doit dimensionner le transfert d’enregistrement au nombre total de téléphones, pas seulement au nombre d’appels actifs.

Négociation de codec et transcodage

FreeSWITCH transcode nativement entre G.711 µ-law, A-law, GSM, G.722 et L16. Opus est pris en charge nativement dans les versions récentes. G.729 et AMR sont des codecs sous licence qui nécessitent des modules supplémentaires dans FreeSWITCH et, selon le volume d’appels, peuvent dépasser la capacité CPU sur le même hôte que FusionPBX. La politique de codec par segment du SBC décide ce que l’opérateur voit et ce que le côté FusionPBX voit, indépendamment. Lorsque l’opérateur veut du G.711 uniquement et que le locataire utilise Opus pour les clients WebRTC, le transcodage peut s’exécuter sur l’option de transcodage matériel du SBC au lieu de consommer le CPU de FusionPBX.

Approche de configuration : FusionPBX, SBC, opérateur

Les menus spécifiques diffèrent selon les fournisseurs de SBC et selon les versions de FusionPBX, mais la logique d’intégration est la même sur tout SBC B2BUA placé devant un cluster FusionPBX multi-locataire.

1. Planifiez la topologie et le modèle de locataires avant de toucher à la configuration. Décidez si chaque locataire apporte son propre opérateur ou si le MSP agrège sur des opérateurs wholesale. Le modèle de locataires détermine le nombre de NAP nécessaires sur le SBC et l’allure des règles de routage. FusionPBX passe sur une interface privée (ou un sous-réseau cloud privé) ; le SBC prend le rôle public.
2. Configurez le(s) NAP côté FusionPBX sur le SBC. Créez un NAP par locataire FusionPBX, ou un NAP pour l’ensemble du cluster FusionPBX si tous les locataires partagent un opérateur wholesale. Pointez chaque NAP vers le profil sofia external de FusionPBX (typiquement UDP/5080 ou TLS/5081), pas vers le profil internal. Vérifiez que le port de liaison correspond.
3. Configurez chaque NAP côté opérateur sur le SBC. Créez un NAP par opérateur amont avec le transport, la liste de codecs, les règles d’en-têtes et le mode d’authentification que le guide d’intégration de l’opérateur spécifie. Utilisez les valeurs publiées par l’opérateur, pas les valeurs par défaut de FreeSWITCH.
4. Ajoutez des règles de manipulation d’en-têtes par segment. Supprimez les P-headers que l’opérateur rejette, réécrivez Contact et Via pour le masquage de topologie, normalisez From et PAI pour la compatibilité d’attestation STIR/SHAKEN en sortie, et appliquez des limites de taille de message SIP là où l’opérateur l’exige.
5. Configurez les règles de routage entre NAP. Entrant de chaque opérateur vers le bon NAP de locataire FusionPBX selon la plage de DID. Sortant de chaque NAP de locataire FusionPBX vers l’opérateur approprié avec priorité et basculement pour que le SBC redirige le trafic lorsqu’un opérateur cesse de répondre.
6. Ajoutez la préservation de l’identité du locataire. Lorsque le SBC agrège de nombreux locataires sur un opérateur wholesale unique, l’identité du locataire (pour la facturation, l’attestation, l’enregistrement) est transportée via P-Asserted-Identity, un en-tête personnalisé ou l’en-tête From. Configurez le SBC pour le remplir à partir du contexte du NAP de locataire.
7. Superposez la sécurité et l’authentification des appels. Activez la protection DoS et DDoS, la protection contre le balayage d’enregistrement si le SBC transfère les enregistrements vers FusionPBX, la mise en liste noire dynamique, l’évaluation de la fraude à la tarification et la signature STIR/SHAKEN sur le segment opérateur.
8. Reconfigurez les passerelles FusionPBX pour pointer vers le SBC. Dans l’interface FusionPBX sous Advanced → Gateways, modifiez chaque passerelle côté opérateur afin que le proxy et le registrar (si utilisé) pointent vers l’adresse interne du SBC au lieu de l’adresse publique de l’opérateur. Les postes, plans de numérotation, IVR et messageries vocales ne sont pas affectés. Rechargez mod_sofia pour le profil external.
9. Testez les appels entrants, sortants et l’isolation des locataires en mode basculement. Passez des appels de test depuis chaque locataire. Vérifiez l’identité de l’appelant, le DTMF, la négociation de codec, la gestion des transferts et la messagerie vocale. Coupez la signalisation de l’opérateur principal et confirmez que le SBC bascule sans couper les appels en cours. Vérifiez qu’un appel passé depuis le locataire A n’aboutit jamais dans le contexte de domaine du locataire B côté FusionPBX.

Sécurité en bordure de FusionPBX

FreeSWITCH inclut des ACL basées sur l’IP, l’authentification par domaine et la limitation de débit sur la pile sofia. Tout cela fonctionne, et la plupart des déploiements FusionPBX en production les utilisent. Le SBC les complète avec des défenses en couches qui opèrent avant que le trafic n’atteigne FreeSWITCH, ce qui est la bonne position architecturale pour la protection de la couche SIP à travers de nombreux locataires sur un seul cluster.

• La protection contre le balayage d’enregistrement SIP détecte les schémas de balayage en bordure, bloque la source automatiquement et ne transfère jamais la sonde à FreeSWITCH. Cela compte le plus lorsque le SBC est le transmetteur d’enregistrement pour les téléphones hébergés.
• L’atténuation DoS et DDoS applique une limitation de débit orientée SIP par IP source, par NAP de locataire et par méthode SIP. Le parseur de sofia ne voit pas du tout l’attaque lorsque le SBC est en façade.
• La détection de fraude à la tarification évalue chaque appel selon le préfixe de destination, le débit d’appels, l’heure et l’historique des schémas. Dans un déploiement FusionPBX multi-locataire, un seul poste compromis dans n’importe quel locataire suffit à consommer des minutes surtaxées pendant la nuit ; l’évaluation du risque par appel détecte le schéma avant que FreeSWITCH n’alloue un canal.
• Le masquage de topologie fait en sorte que l’IP publique du SBC soit la seule adresse que l’opérateur voit, quel que soit l’hôte FreeSWITCH ou le domaine à l’origine de l’appel.
• La mise en liste noire et grise dynamique automatise la réponse aux abus détectés sans intervention manuelle.

Le modèle complet de sécurité SBC couvre le schéma de défense en couches en détail.

STIR/SHAKEN pour les MSP FusionPBX

Pour les déploiements FusionPBX terminant en Amérique du Nord, la question STIR/SHAKEN façonne la manière dont le MSP est positionné auprès de ses opérateurs amont et, de plus en plus, les taux de réponse que chaque locataire constate sur les appels sortants.

FreeSWITCH et FusionPBX ne signent pas les appels. Il n’existe aucun module natif pour la construction de PASSporT, aucun chemin de requête STI-AS et aucune injection d’en-tête Identity dans la pile sofia. La signature s’effectue au niveau de la couche SBC ou en amont chez l’opérateur.

Pour les MSP qui détiennent leur propre token SPC et veulent un contrôle total de l’attestation, le SBC gère la signature par appel. Le niveau d’attestation est décidé par appel, pas par locataire, car un seul cluster FusionPBX transporte typiquement du trafic mixte : niveau A pour les locataires directs dont le KYC est vérifié, niveau B pour les numéros revendus, et niveau C pour tout locataire dont l’appelant ne peut être authentifié. La référence sur l’attestation STIR/SHAKEN de niveau A couvre ce qui est requis pour maintenir le niveau A à mesure que l’environnement politique amont se durcit.

Pour les MSP qui laissent un opérateur wholesale amont signer en leur nom, le rôle du SBC est de renseigner les en-têtes d’identité SIP avec précision afin que l’opérateur dispose des informations correctes pour fonder l’attestation. Supprimer ou réécrire P-Asserted-Identity au SBC dégradera silencieusement les résultats d’attestation.

Dans les deux schémas, le SBC s’intègre aux services de signature comme TransNexus ClearIP et Neustar via le moteur de routage du SBC, pas via quoi que ce soit à l’intérieur de FusionPBX. Les détails d’implémentation se trouvent dans le guide d’implémentation STIR/SHAKEN pour SBC.

Questions fréquemment posées

Conclusion

FusionPBX est l’un des meilleurs choix du marché pour un PBX hébergé multi-locataire basé sur FreeSWITCH. Ses atouts sont le modèle de domaines, l’interface graphique au-dessus du moteur de contrôle d’appels FreeSWITCH, et les économies opérationnelles liées à l’hébergement de nombreux locataires sur une seule infrastructure. Ses limites apparaissent à la frontière entre cette infrastructure et l’internet public : la sécurité de la couche signalisation, la signature STIR/SHAKEN, la normalisation par opérateur à grande échelle et l’évaluation de la fraude par appel relèvent toutes d’une couche que FusionPBX n’a pas été conçu pour assumer. Le SBC est ce qui prend la responsabilité de ces préoccupations sans modifier la manière dont FusionPBX gère les locataires et les appels en interne.

Les caractéristiques décisives lors de l’évaluation d’un SBC pour un déploiement FusionPBX sont l’architecture B2BUA pour un contrôle total des en-têtes et du chiffrement sur chaque segment, la politique de transport et de codec par NAP afin que chaque locataire et chaque opérateur obtienne le bon profil, un modèle de partenaire STIR/SHAKEN ouvert pour que le choix du service de signature reste celui du MSP, une capacité de NAP à l’échelle des locataires pour qu’un seul SBC couvre l’ensemble du cluster FusionPBX, et une évaluation en libre-service pour confirmer l’intégration avec votre déploiement réel avant de signer quoi que ce soit.