FusionPBX avec un SBC : configuration et bonnes pratiques

FusionPBX est l’interface web que la plupart des fournisseurs de services choisissent lorsqu’ils veulent un PBX multi-locataire basé sur FreeSWITCH, administrable depuis un navigateur. Une base de données PostgreSQL, un cluster FreeSWITCH et une abstraction par domaine qui permet à un seul déploiement de desservir des dizaines ou des centaines de locataires. C’est cette architecture qui rend FusionPBX populaire auprès des MSP, des ITSP, des ILEC et des CLEC exploitant un PBX hébergé en tant que service. C’est aussi ce qui rend la question du SBC fondamentalement différente de celle abordée dans les autres articles d’intégration PBX de ce site.

La plupart des articles sur l’association PBX + SBC commencent par « votre PBX ne peut pas terminer proprement les dialogues SIP par lui-même ». FusionPBX n’a pas ce problème. FreeSWITCH fonctionne déjà comme un B2BUA sur chaque appel, terminant le dialogue entrant sur un profil sofia et en originant un nouveau sur un autre profil. 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 périphérie ?

Cet article répond à cette question, parcourt les comportements SIP spécifiques à FusionPBX qu’un SBC doit gérer en périphérie, 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 de 3CX, et elle mérite une réponse directe.

FreeSWITCH est un B2BUA. À chaque appel, le module sofia accepte l’INVITE entrant sur un profil, exécute l’appel à travers le plan de numérotation et génère 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 que fait un SBC B2BUA.

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 vocal et l’internet public. Cinq préoccupations, précisément.

Sécurité de la couche SIP à un débit de classe opérateur

La défense en périphérie 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 confronte à l’authentification du domaine avant de le rejeter. À raison de centaines de messages malformés par seconde provenant d’un scanner coordonné, le parseur devient le goulot d’étranglement. La protection DoS et DDoS orientée SIP d’un SBC rejette le trafic malformé et hors politique en périphérie, avec des limites de débit par méthode, par source et par groupe de trunks, 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 ou FusionPBX. Il n’existe aucun module qui appelle TransNexus ClearIP ou Neustar, construise un PASSporT, attache l’en-tête Identity et bascule vers un mécanisme de secours lorsque le service de signature est injoignable. Les opérateurs nord-américains qui terminent des appels sans en-tête Identity vérifié dégradent de plus en plus le niveau d’attestation, et le flux de signature STIR/SHAKEN relève de la couche SBC.

Normalisation SIP par opérateur sur de nombreux fournisseurs amont

Les particularités propres à chaque opérateur s’adaptent mal à l’intérieur des 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, ses exceptions ACL, ses ajustements d’en-têtes via des variables de canal pré-appel, et des 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 périphérie doit se faire en périphérie. FreeSWITCH annonce par défaut son adresse de liaison dans les en-têtes Contact et Via, et les solutions habituelles (sip-ip, ext-sip-ip et extra-headers par passerelle dans sofia) fonctionnent mais dispersent la politique à travers plusieurs fragments XML. Un SBC applique le masquage de topologie de manière uniforme pour chaque appel sortant, quel que soit le locataire ou la passerelle à l’origine de l’appel.

Évaluation du risque de 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 utilisant FusionPBX. Une extension compromise chez n’importe quel locataire du cluster peut engendrer des centaines de milliers de dollars de 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 est une intégration API que la couche SBC assure, pas la couche PBX.

Le schéma est le même pour ces cinq préoccupations. FusionPBX et FreeSWITCH excellent en tant que moteur de contrôle d’appels multi-locataire. Le SBC prend en charge les préoccupations de périphérie que le moteur de contrôle d’appels n’a jamais été conçu pour assumer.

Multi-locataire par conception : les domaines FusionPBX et la frontière du 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, client-a.pbx.msp.example, client-b.pbx.msp.example, etc.), et chaque extension, passerelle, plan de numérotation, IVR et boîte vocale réside à l’intérieur de l’un de ces domaines. Le même processus FreeSWITCH les dessert 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 dont chaque locataire apporte son propre opérateur, ses propres numéros 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 font correspondre la plage DID du locataire à son opérateur amont spécifique. L’isolation des locataires est assurée au niveau du SBC, pas uniquement à l’intérieur de 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 dirigent le trafic sortant de n’importe quel locataire vers l’opérateur wholesale, avec l’identité du locataire portée par 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 services d’origine.

Les deux schémas fonctionnent, et les grands MSP utilisent généralement un mélange des deux. Ce dont les deux dépendent, c’est de l’isolation par NAP par locataire au niveau du SBC. Un seul SBC en périphérie 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’accès FusionPBX exposés individuellement en une seule frontière contrôlée. La référence SBC pour 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 s’appaire avec le module sofia de FreeSWITCH, et quelques comportements de sofia déterminent à quoi ressemble l’intégration en pratique.

Liaison du profil sofia et la séparation interne/externe

FusionPBX configure par défaut deux profils sofia. Le profil internal gère les enregistrements des extensions (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 à l’adresse IP du serveur FusionPBX sur le port 5060, FusionPBX les attend sur le port 5080 du profil external, et l’appel échoue avant même que la logique du plan de numérotation ne s’exécute. Confirmez 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 à travers une passerelle définie dans le profil external. La passerelle indique à sofia où envoyer l’INVITE, avec quels identifiants (le cas échéant) s’authentifier et quel transport utiliser. 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’exigent, 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 apportées dans l’interface FusionPBX de prendre effet sans recharger 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. En 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 minuteries de session et des délais d’établissement d’appel de son côté, indépendamment de FreeSWITCH, afin qu’une résolution lente du plan de numérotation ne se propage pas comme un dépassement de délai visible par l’opérateur. La politique de réessai sortant par NAP sur le SBC absorbe la variance.

Manipulation d’en-têtes par le plan de numérotation vs. normalisation 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.). Fait avec soin, cela fonctionne. Fait sur 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 du plan de numérotation à plusieurs endroits, et chaque changement exige des tests de régression sur l’ensemble des 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 permet au plan de numérotation FusionPBX de se concentrer sur la logique d’appel spécifique au locataire. Le SBC effectue le travail spécifique à l’opérateur de manière uniforme pour tous les locataires.

Transfert de REGISTER et le rôle du SBC en périphérie 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 face au balayage d’enregistrement. Le schéma le plus propre consiste à faire accepter les enregistrements par le SBC en périphérie, à les transférer vers FusionPBX via sa fonctionnalité de transfert d’enregistrement, et à appliquer 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, de manière indépendante. Lorsque l’opérateur exige G.711 uniquement et que le locataire utilise Opus pour ses 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 varient selon les fournisseurs de SBC et les versions de FusionPBX, mais la logique d’intégration est la même pour 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 le trafic sur des opérateurs wholesale. Le modèle de locataires détermine le nombre de NAP nécessaires sur le SBC et la forme des règles de routage. FusionPBX passe sur une interface privée (ou un sous-réseau cloud privé) ; le SBC assume le rôle public.
2. Configurez le ou les 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. Confirmez 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 spécifiés dans le guide d’intégration de l’opérateur. 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 en-têtes P- 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 les limites de taille de message SIP lorsque l’opérateur l’exige.
5. Configurez les règles de routage entre les NAP. En entrée, de chaque opérateur vers le bon NAP locataire FusionPBX en fonction de la plage DID. En sortie, de chaque NAP locataire FusionPBX vers l’opérateur approprié avec priorité et basculement, afin 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 seul opérateur wholesale, l’identité du locataire (pour la facturation, l’attestation, l’enregistrement) est portée par P-Asserted-Identity, un en-tête personnalisé ou l’en-tête From. Configurez le SBC pour le renseigner à partir du contexte NAP du 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 du risque de fraude de péage 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 extensions, 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 conditions de basculement. Passez des appels de test depuis chaque locataire. Vérifiez l’identification 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. Confirmez qu’un appel passé depuis le locataire A n’atterrit jamais dans le contexte de domaine du locataire B côté FusionPBX.

Sécurité en périphérie 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. 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 sur de nombreux locataires partageant un même cluster.

• La protection contre le balayage d’enregistrement SIP détecte les schémas de balayage en périphérie, bloque la source automatiquement et ne transfère jamais la sonde à FreeSWITCH. C’est particulièrement important lorsque le SBC assure le transfert 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 adresse IP source, par NAP locataire et par méthode SIP. Le parseur de sofia ne voit pas du tout l’attaque lorsque le SBC est en amont.
• La détection de fraude de péage évalue chaque appel en fonction du préfixe de destination, du rythme d’appel, de l’heure et de l’historique des schémas. Dans un déploiement FusionPBX multi-locataire, une seule extension compromise chez n’importe quel locataire suffit à générer 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’adresse 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 en liste grise dynamique automatise la réponse aux abus détectés sans intervention manuelle.

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

STIR/SHAKEN pour les MSP utilisant FusionPBX

Pour les déploiements FusionPBX qui terminent en Amérique du Nord, la question STIR/SHAKEN détermine le positionnement du MSP vis-à-vis de ses opérateurs amont et, de plus en plus, les taux de réponse que chaque locataire obtient 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 du SBC ou en amont chez l’opérateur.

Pour les MSP qui détiennent leur propre jeton SPC et souhaitent un contrôle complet de l’attestation, le SBC gère la signature par appel. Le niveau d’attestation est déterminé par appel, pas par locataire, car un cluster FusionPBX unique transporte typiquement un trafic mixte : niveau A pour les locataires de détail directs dont le KYC est vérifié, niveau B pour les numéros revendus et niveau C pour tout locataire dont l’identité de l’appelant ne peut pas être authentifiée. 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 réglementaire 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 correctement les en-têtes d’identité SIP afin que l’opérateur dispose des informations exactes pour fonder l’attestation. Supprimer ou réécrire P-Asserted-Identity au niveau du 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 de mise en œuvre se trouvent dans le guide de mise en œuvre 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 de FreeSWITCH, et l’économie opérationnelle que procure 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 de signalisation, la signature STIR/SHAKEN, la normalisation par opérateur à grande échelle et l’évaluation du risque de fraude par appel relèvent tous d’une couche que FusionPBX n’a pas été conçu pour assumer. Le SBC est ce qui prend en charge ces préoccupations sans modifier la façon 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 : une architecture B2BUA pour un contrôle complet des en-têtes et du chiffrement sur chaque segment, une politique de transport et de codec par NAP afin que chaque locataire et chaque opérateur obtienne le bon profil, un modèle de partenariat STIR/SHAKEN ouvert pour que le choix du service de signature reste celui du MSP, une capacité NAP à l’échelle des locataires pour qu’un seul SBC puisse desservir 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.