FreeSWITCH + ProSBC : configuration de la jonction SIP

FreeSWITCH est l’une des plateformes open source les plus puissantes de l’écosystème voix. Il termine le SIP, ancre le média, transcode les codecs, exécute des dialplans complets, diffuse des invites vocales, mixe des conférences, enregistre les appels et expose l’Event Socket Library (ESL) pour le contrôle externe de chaque session en cours. Les équipes qui exploitent FreeSWITCH à grande échelle le font parce qu’aucun autre moteur média open source n’égale ses capacités une fois qu’un appel est sur la machine.

Ce que FreeSWITCH n’est pas, en revanche, c’est un contrôleur de session en bordure (SBC). Il ne dispose ni de la posture de sécurité, ni de la discipline de chiffrement par segment, ni de l’intelligence de routage multi-opérateur, ni des outils d’authentification d’appels qu’un véritable SBC apporte en bordure de réseau. Les déploiements qui exposent FreeSWITCH directement sur l’internet public héritent d’une longue liste de tâches que la plateforme n’a jamais été conçue pour assumer, et les opérateurs finissent par reconstruire ces fonctions en assemblant des règles iptables, des scripts fail2ban et du code Lua. L’architecture la plus propre consiste à placer un Session Border Controller (SBC) devant FreeSWITCH et à laisser chaque couche faire son propre travail.

Cet article couvre ce que ProSBC apporte devant FreeSWITCH, les cas où le module mod_sofia intégré à FreeSWITCH suffit, les comportements SIP spécifiques à FreeSWITCH qu’un SBC doit gérer, et l’approche de configuration de haut niveau pour un déploiement en production.

FreeSWITCH en bordure vs FreeSWITCH derrière un SBC

La raison la plus courante pour laquelle les équipes adoptent cette configuration est qu’elles ont commencé avec FreeSWITCH directement sur l’internet public et ont atteint les limites de ce modèle. FreeSWITCH en bordure est fonctionnel ; des milliers de petits déploiements fonctionnent ainsi. Les problèmes commencent à grande échelle, dans les juridictions réglementées, ou partout où les exigences de qualité d’appel et de sécurité correspondent à ce que les réseaux d’opérateurs exigent de leurs points d’interconnexion.

Une instance FreeSWITCH en bordure est à la fois le serveur d’applications complet, le moteur média complet et la frontière de sécurité complète dans un seul processus. Un scan d’enregistrement, un flood d’INVITE, ou du trafic SIP malformé qui génère des erreurs d’analyse ou une charge de traitement excessive frappent tous le même noyau qui ancre les appels en cours et exécute les dialplans actifs. La plateforme n’a jamais été conçue pour absorber gracieusement le trafic hostile ; elle a été conçue pour servir des appels déjà acceptés.

Le même schéma apparaît côté interopérabilité. Le module mod_sofia de FreeSWITCH négocie le SIP et le SDP proprement avec les opérateurs qui se comportent bien, et se rabat sur des paramètres par passerelle quand ce n’est pas le cas. La collection de ces paramètres grandit au fil du temps à mesure que vous ajoutez des opérateurs, et chacun devient un élément porteur du savoir opérationnel. Un SBC déplace cette complexité hors du serveur d’applications vers un équipement dont le rôle est précisément de normaliser les différents dialectes SIP, et offre à FreeSWITCH un seul interlocuteur cohérent en amont.

La suite de cet article traite du déploiement de ProSBC en tant que véritable SBC B2BUA entre FreeSWITCH et le PSTN. Là où FreeSWITCH est le bon outil (ancrage média, IVR, conférence, enregistrement, contrôle d’appels piloté par ESL), il reste à sa place, côté LAN du SBC, à faire ce qu’il fait le mieux.

Ce que ProSBC apporte devant FreeSWITCH

FreeSWITCH possède sa propre pile SIP et sa propre pile média. La négociation de codecs, la gestion de Contact sensible au NAT, la gestion basique des enregistrements et les paramètres par passerelle sont tous intégrés à mod_sofia. Pour un déploiement mono-opérateur, à faible volume, avec un fournisseur coopératif, cela suffit. ProSBC devient nécessaire lorsque les exigences dépassent la zone de confort de mod_sofia et excèdent ce que la plateforme FreeSWITCH a été conçue pour absorber.

Routage multi-opérateur et basculement comme priorité de premier plan

FreeSWITCH peut acheminer les appels sortants via plusieurs passerelles, mais la logique de routage, les vérifications de disponibilité par OPTIONS et le comportement de basculement finissent dispersés entre le dialplan, des scripts Lua et des gestionnaires d’événements ESL. ProSBC consolide le routage dans un moteur basé sur des règles avec des routes ordonnées par priorité, des vérifications de santé SIP OPTIONS par NAP, et un mappage cause-motif qui relance l’appel sur les codes de réponse appropriés et l’arrête sur ceux qui ne doivent pas déclencher de nouvel essai. FreeSWITCH ne voit qu’un seul interlocuteur en amont et décharge entièrement la diversité des opérateurs sur le SBC.

Sécurité à la frontière de l’internet public

Un serveur FreeSWITCH avec une IP publique et un port SIP ouvert est l’une des classes de points de terminaison les plus scannées sur internet. Les scans d’enregistrement SIP, les floods d’INVITE et les tentatives de fraude à la taxation frappent tout point de terminaison SIP accessible depuis internet dans les heures suivant sa mise en ligne. ProSBC absorbe ce trafic en bordure avec une limitation de débit SIP par adresse IP source et par méthode, une atténuation automatique des attaques DoS SIP et des scans d’enregistrement, une mise en liste de blocage dynamique avec mise en liste grise pour une réponse graduée, et un scoring de fraude par appel avant que l’appel n’atteigne jamais FreeSWITCH.

Normalisation SIP entre opérateurs et régions

Les opérateurs varient dans ce qu’ils acceptent, ce qu’ils attendent et ce qu’ils réécrivent silencieusement. Les en-têtes P- transportent des informations qu’un côté exige et que l’autre rejette ; les formats de Contact et From diffèrent ; l’ordre de préférence des codecs varie ; les temporisateurs de session se comportent différemment selon les fournisseurs. Le moteur de manipulation des en-têtes SIP de ProSBC normalise le segment côté opérateur par NAP sans modifier la façon dont FreeSWITCH construit son propre SIP sortant. Le dialplan reste propre ; les excentricités propres à chaque opérateur résident au niveau du SBC.

STIR/SHAKEN, CNAM et authentification des appels

Pour les déploiements FreeSWITCH qui terminent en Amérique du Nord, les règles de la FCC en matière d’authentification de l’identité de l’appelant continuent de se durcir et les opérateurs en amont continuent de déléguer les décisions d’attestation à leurs clients de gros. Le contrôle de l’attestation, l’intégration du service de signature et la politique de contournement en cas de panne relèvent tous de la couche SBC, pas du serveur d’applications. ProSBC s’intègre aux services de signature STIR/SHAKEN tels que TransNexus ClearIP et Neustar via SIP, avec une redondance gérée par l’ordonnancement des routes et une logique de basculement basée sur les réponses. Les recherches CNAM et les consultations LNP s’intègrent au même moteur de routage.

Quand le mod_sofia de FreeSWITCH suffit vs quand il ne suffit pas

FreeSWITCH est un point de terminaison SIP parfaitement capable dans le cadre de ses hypothèses de conception. L’architecture à threads séparés gère bien la concurrence, le moteur de codecs est mature, et les paramètres par passerelle couvrent la plupart des particularités des opérateurs une à une. Le facteur décisif est de savoir si votre environnement tient dans ce pour quoi mod_sofia a été conçu ou s’il l’a dépassé.

Scénario	FreeSWITCH seul	FreeSWITCH avec ProSBC
Opérateur unique et coopératif, faible volume d’appels, utilisateurs internes uniquement	Suffisant	Optionnel
Basculement multi-opérateur ou routage au moindre coût entre régions	Dialplan lourd	Recommandé
Opérateur avec un dialecte SIP non standard ou des règles de normalisation strictes	Hacks par passerelle	Recommandé
Contrôle d’attestation STIR/SHAKEN, signature par appel	Pas la bonne couche	Requis
Exposition à l’internet public avec risque élevé de scan et de fraude	DIY iptables + fail2ban	Requis
Fournisseur de services exploitant FreeSWITCH comme plateforme multi-locataire	Instances par locataire	NAPs par locataire sur un seul SBC

Le schéma est cohérent dans tout le tableau. FreeSWITCH gère l’intérieur de votre plateforme voix ; le SBC gère la frontière. Dès que la frontière développe des exigences qui dépassent une seule jonction coopérative, le SBC prend en charge ces fonctions pour que FreeSWITCH puisse continuer à faire ce qu’il fait bien. Pour une discussion plus large sur la place de FreeSWITCH dans le paysage open source aux côtés de Kamailio et OpenSIPS, consultez notre article compagnon sur le choix d’une plateforme SIP.

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

La logique d’intégration pour FreeSWITCH est la même que pour tout softswitch, avec quelques comportements spécifiques à la plateforme qui méritent d’être signalés. Chacun réside dans mod_sofia ou le dialplan FreeSWITCH et se manifeste comme quelque chose que le SBC doit reconnaître sur le segment côté FreeSWITCH. Gérez correctement ces points et le reste de la configuration se met en place naturellement.

Profils SIP, passerelles et leur correspondance avec les NAP ProSBC

FreeSWITCH organise son monde SIP en profils (un profil internal et un profil external par défaut), chacun écoutant sur son propre port avec sa propre liste de codecs, son transport et ses entrées de passerelle. Le schéma le plus propre avec ProSBC en frontal consiste à traiter le SBC comme une passerelle unique sur le profil external, le choix d’authentification côté FreeSWITCH (REGISTER vs basé sur l’IP) étant déterminé par ce qui convient à votre modèle opérationnel. Côté ProSBC, cette même connexion devient un NAP unique pointant vers l’adresse interne du serveur FreeSWITCH, les NAP côté opérateur étant gérés indépendamment. Chaque particularité propre à un opérateur réside sur un NAP opérateur, jamais sur le NAP FreeSWITCH.

Préférence de codecs et la question du transcodage

FreeSWITCH propose les codecs selon outbound-codec-prefs, puis négocie le jeu média final en fonction de la réponse reçue du côté distant. Quand l’opérateur supporte un jeu de codecs différent, ou préfère un ordre différent, le SBC normalise l’offre selon les attentes de l’opérateur. Pour le trafic à destination du PSTN, cela signifie généralement G.711 µ-law ou A-law en première position, le SBC supprimant les offres non PSTN comme G.722 ou Opus que l’opérateur ne négociera pas. Si un appel nécessite réellement une conversion de codec en bordure (Opus côté FreeSWITCH, G.711 côté opérateur, ou AMR-WB entrant depuis un opérateur mobile), le transcodage matériel décharge cette tâche du serveur FreeSWITCH, où elle serait autrement en concurrence avec l’ancrage média et le mixage de conférence sur le même CPU.

Réécriture de Contact, Via et Record-Route

FreeSWITCH place sa propre IP externe ou son nom d’hôte dans les en-têtes Contact et Via, avec NDLB-force-rport et les drapeaux NDLB-* associés (No Default Loopback Behavior) ajustant la rigueur avec laquelle mod_sofia respecte le port et l’adresse source dans les réponses. Le SBC réécrit généralement les en-têtes Contact, Via et ceux liés au routage selon la politique de masquage de topologie avant de transmettre en sortie, et inverse la réécriture au retour afin que FreeSWITCH voie une adresse vers laquelle il peut router. Le masquage de topologie au niveau du SBC gère cela de manière transparente, empêchant l’opérateur de voir l’adressage interne de FreeSWITCH et évitant les échecs de routage causés par des fuites d’adresses privées.

Transfert de fax T.38 et le re-INVITE en cours d’appel

FreeSWITCH supporte le T.38 via mod_spandsp, avec le mode passerelle T.38 reliant le T.38 sur un segment au passthrough G.711 sur l’autre. L’ensemble du mécanisme dépend d’un re-INVITE en cours d’appel qui remplace le flux audio par un flux T.38 une fois les tonalités de fax détectées. Certains opérateurs acceptent le re-INVITE proprement ; d’autres le rejettent, le laissent expirer, ou suppriment les attributs SDP qui font fonctionner le T.38. Le SBC gère le comportement par NAP ici : relais T.38 quand l’opérateur accepte le T.38, passthrough G.711 avec un profil compatible fax (annulation d’écho désactivée, buffer de gigue statique, VAD désactivé) quand ce n’est pas le cas, et réécriture SDP propre dans les deux directions. Les mécanismes détaillés de la négociation T.38 et les points d’échec courants sont couverts dans notre référence Fax over IP (T.38).

REFER, transfert supervisé et l’alternative du bridge

FreeSWITCH implémente les transferts d’appels soit par SIP REFER (quand initié par un terminal qui en envoie un), soit par le mécanisme de bridge du dialplan, qui maintient le segment d’appel sur FreeSWITCH et en génère un nouveau. Les opérateurs varient quant à leur prise en charge du REFER. Le SBC a deux comportements corrects : transmettre le REFER si l’opérateur le supporte, ou remplacer le REFER par un re-INVITE à l’intérieur du SBC pour que l’opérateur ne voie jamais le REFER. Configurez cela par NAP en fonction de ce que chaque opérateur en amont accepte, et FreeSWITCH n’a jamais besoin de savoir quel opérateur est de l’autre côté.

Temporisateurs de session et coupures d’appels silencieuses

FreeSWITCH utilise les temporisateurs de session SIP (RFC 4028) lorsqu’il est configuré pour (enable-timer, session-timeout), et les ignore dans le cas contraire. Le SBC doit négocier des valeurs de temporisateur compatibles sur chaque segment, en rafraîchissant vers FreeSWITCH selon la cadence attendue et vers l’opérateur selon ce que celui-ci exige. Des temporisateurs mal alignés causent des coupures d’appels silencieuses en pleine conversation, qui apparaissent comme aléatoires et intermittentes dans les logs FreeSWITCH parce que la défaillance se produit un saut plus loin. Configurer les temporisateurs de manière cohérente sur le SBC élimine entièrement cette catégorie de bug.

Approche de configuration : FreeSWITCH, SBC, opérateur

Les menus spécifiques diffèrent selon les fournisseurs de SBC, mais la logique d’intégration est la même sur tout SBC B2BUA. L’objectif est deux groupes de jonctions propres (un vers FreeSWITCH, un vers chaque opérateur) avec le SBC qui les relie et gère chaque transformation entre les deux. Le côté FreeSWITCH de la configuration est volontairement simple ; le SBC absorbe tout ce qui résiderait autrement dans des paramètres par passerelle à travers mod_sofia.

1. Planifier la topologie avant de toucher à la configurationDécidez où ProSBC se situe : dans le même VPC cloud que FreeSWITCH, sur une VM séparée dans le même centre de données, ou dans une région cloud dédiée devant un cluster FreeSWITCH sur site. Confirmez l’adressage IP public, le DNS et le provisionnement des certificats TLS pour ProSBC. Le serveur FreeSWITCH conserve son adressage LAN existant ; ProSBC prend le rôle public et le trafic ESL continue de se terminer côté LAN de FreeSWITCH comme il l’a toujours fait.
2. Configurer le NAP côté FreeSWITCH sur ProSBCCréez un NAP pointant vers l’adresse interne du serveur FreeSWITCH. Faites correspondre le transport que mod_sofia utilise sur son profil external (UDP, TCP ou TLS) sur le port convenu. Décidez si FreeSWITCH s’authentifie par IP ou par identifiants REGISTER, et configurez le NAP en conséquence. Gardez ce NAP simple : les règles d’en-têtes, les politiques de codecs et les ajustements de sécurité appartiennent aux NAP côté opérateur.
3. Configurer chaque NAP côté opérateur sur ProSBCCréez un NAP par opérateur en amont. Définissez le transport, la liste de codecs, les règles d’en-têtes et le mode d’authentification selon ce que le guide d’intégration de l’opérateur spécifie. Si l’opérateur fournit des IP de signalisation redondantes, regroupez-les sous un seul NAP avec un ordonnancement de routes primaire et secondaire et un heartbeat SIP OPTIONS configuré pour la détection de disponibilité.
4. Ajouter des règles de manipulation d’en-têtes par segmentSupprimez les en-têtes P- et les champs propriétaires que l’opérateur n’acceptera pas sur le trafic sortant de FreeSWITCH. Réécrivez Contact et Via avec l’adresse publique de ProSBC. Normalisez From et PAI pour correspondre au format attendu par l’opérateur pour l’attestation STIR/SHAKEN. Rien de tout cela ne nécessite de modifier la configuration de FreeSWITCH.
5. Configurer les règles de routage entre les NAPDéfinissez les règles entrantes de chaque opérateur vers le NAP FreeSWITCH, et les règles sortantes du NAP FreeSWITCH vers l’opérateur approprié en fonction du préfixe de destination, de l’heure de la journée, ou de tout autre critère. Ajoutez des règles de repli pour les pannes d’opérateur, afin qu’un appel refusé sur la route primaire soit redirigé vers la secondaire. Le mappage cause-motif gère quels codes de réponse doivent déclencher un nouvel essai et lesquels doivent arrêter l’appel.
6. Ajouter la couche de sécurité et l’authentification des appelsActivez la protection DoS/DDoS et la protection contre les scans d’enregistrement SIP sur les jonctions côté opérateur. Configurez la mise en liste de blocage dynamique et le scoring de fraude à la taxation. Pour le trafic à destination des États-Unis, connectez la signature STIR/SHAKEN via le fournisseur STI-AS de votre choix, avec des routes primaire et secondaire pour le service de signature lui-même et un mappage cause-motif qui relance sur 404 et arrête les appels sur 603 selon le modèle d’intégration SIP en production.
7. Reconfigurer FreeSWITCH pour communiquer avec ProSBC au lieu des opérateurs directementDans FreeSWITCH, modifiez les entrées de passerelle concernées dans conf/sip_profiles/external/ pour que chacune pointe vers ProSBC au lieu de l’opérateur. Les préférences de codecs et les paramètres de proxy au niveau de la passerelle se simplifient considérablement car le SBC absorbe tout ce qui est spécifique à l’opérateur. Rechargez mod_sofia ou rescannez le profil concerné plutôt que de redémarrer FreeSWITCH si vous pouvez éviter l’interruption.
8. Tester dans les deux directions et en conditions de basculementPlacez des appels de test entrants et sortants. Vérifiez la présentation de l’identité de l’appelant, la négociation de codecs, le DTMF (RFC 2833 / RFC 4733), la gestion des transferts et la livraison de fax si utilisée. Puis coupez délibérément la joignabilité de signalisation de l’opérateur primaire et confirmez que ProSBC bascule le trafic vers la route secondaire selon le calendrier dicté par SIP OPTIONS. Surveillez les sorties sofia.status et sofia.profile.external.status de FreeSWITCH pendant le basculement pour confirmer que le côté FreeSWITCH reste stable tout au long.

Ce qu’il faut rechercher dans un SBC pour FreeSWITCH

Les fonctionnalités qualifiantes pour un SBC compatible FreeSWITCH sont celles qui rendent tout SBC performant en interopérabilité multi-fournisseur, avec quelques considérations supplémentaires spécifiques au fonctionnement devant un serveur d’applications open source. Utilisez la liste suivante comme une grille d’évaluation.

Architecture B2BUA, pas un proxy SIP

Un proxy SIP ne peut pas remplir ce rôle. La réécriture de Contact et Via, le remplacement de REFER par un re-INVITE, la conversion de RTP en SRTP et la signature des appels sortants avec STIR/SHAKEN exigent tous que le SBC termine et régénère chaque dialogue de manière indépendante. Une architecture B2BUA est le prérequis de base.

Routage programmable qui parle le langage de FreeSWITCH

Les opérateurs FreeSWITCH s’attendent à de la programmabilité, car c’est ce que la plateforme elle-même offre via ESL, Lua et le dialplan. Un SBC associé à FreeSWITCH devrait offrir un niveau de contrôle comparable de son côté. L’API de routage Ruby de ProSBC expose le contexte complet de l’appel aux scripts externes à trois étapes de filtrage (before_filter, after_filter, after_remap_filter), avec des modules pré-construits pour la signature STIR/SHAKEN, TransNexus ClearIP, SecureLogix, YouMail et Neustar. Le modèle d’intégration est conçu pour le même type d’opérateur qui gère déjà du code dialplan et ESL côté FreeSWITCH.

TLS, SRTP et règles d’en-têtes par NAP

Recherchez un SBC où chaque NAP dispose de son propre paramètre de transport, de sa propre liste de codecs et de son propre profil de manipulation d’en-têtes. C’est ce qui permet à un opérateur de fonctionner sur UDP/5060 avec G.711 tandis qu’un autre est sur TLS/5061 avec SRTP, et que FreeSWITCH derrière les deux reçoive une présentation cohérente quel que soit l’opérateur qui a traité l’appel.

Intégration partenaire STIR/SHAKEN ouverte

L’intégration STIR/SHAKEN au niveau du SBC ne devrait pas vous enfermer avec un seul service de signature. ProSBC s’intègre avec TransNexus ClearIP et Neustar via SIP aujourd’hui, et avec tout fournisseur STI-AS exposant une API HTTPS si nécessaire. L’attestation est décidée par appel dans le moteur de routage plutôt que par jonction comme paramètre statique, ce qui correspond à ce que la règle de certificat propre de la FCC suppose lorsqu’une plateforme unique gère du trafic multi-locataire.

Flexibilité de déploiement à la hauteur de celle de FreeSWITCH

FreeSWITCH fonctionne sur Linux sur pratiquement n’importe quoi. Le SBC devrait fonctionner partout où votre topologie place réellement la bordure : AWS, Azure, VMware, KVM/Proxmox ou bare metal. Un SBC cloud-native co-localisé avec un FreeSWITCH hébergé dans le cloud minimise la latence entre les deux ; un SBC virtualisé sur le même hyperviseur qu’un FreeSWITCH sur site maintient l’ensemble de la pile voix sur l’infrastructure du client.

Évaluation en libre-service

La meilleure façon de confirmer qu’un SBC gère FreeSWITCH correctement est d’y faire passer du trafic. Une licence d’évaluation gratuite et en libre-service vous permet de mettre le SBC en place à côté d’une instance FreeSWITCH de test et de valider chaque comportement listé ci-dessus avant de vous engager.

Sécurité en bordure de FreeSWITCH

FreeSWITCH dispose de ses propres protections, notamment le filtrage par ACL et les limites de débit au niveau de mod_sofia. Le SBC complète celles-ci avec des défenses en couches opérant avant que le trafic n’atteigne FreeSWITCH, ce qui est la position architecturale correcte pour la protection au niveau SIP. Tout ce que FreeSWITCH n’a pas à examiner représente du CPU qu’il n’a pas à dépenser pour décider quoi en faire.

Protection contre les scans d’enregistrement SIP

L’attaque la plus courante contre un serveur FreeSWITCH exposé sur l’internet public est un flood lent de REGISTER sondant les extensions valides ou les mots de passe faibles. ProSBC détecte les schémas de scan par fréquence et distribution de source, bloque automatiquement la source et ne transmet jamais la sonde à FreeSWITCH. La mise en liste grise avec un taux de réponse en pourcentage permet au SBC d’examiner les sources suspectes progressivement au lieu de les bloquer et débloquer en cycles alternés.

Atténuation DoS et DDoS

Les floods volumétriques d’INVITE et d’OPTIONS qui consommeraient le pool de connexions de FreeSWITCH sont limités en débit au niveau du SBC en premier. La limitation de débit SIP par adresse IP source, par groupe de jonctions et par méthode SIP rejette le trafic malveillant avant qu’il ne consomme la capacité de traitement d’appels de FreeSWITCH.

Détection de fraude à la taxation sur le segment côté opérateur

La numérotation internationale vers des numéros surtaxés est le risque de facturation le plus important sur tout point de terminaison SIP. ProSBC applique un score de risque par appel tenant compte du préfixe de destination, du taux d’appels, de l’heure de la journée et de l’historique des schémas, et bloque l’appel ou le redirige pour examen avant qu’il ne quitte la jonction côté opérateur. L’intégration avec des partenaires de détection de fraude validés comme TransNexus et YouMail s’intègre au même moteur de routage.

Masquage de topologie pour le serveur FreeSWITCH lui-même

L’IP publique de ProSBC est la seule adresse que l’opérateur voit. Le nom d’hôte interne de FreeSWITCH, son adresse privée, la structure du LAN derrière lui et tout système back-end connecté par ESL restent tous invisibles depuis le côté opérateur. Cela réduit la surface d’attaque à une seule frontière bien défendue au lieu du serveur d’applications lui-même.

Foire aux questions

Conclusion

FreeSWITCH est une plateforme open source performante dans le cadre de ses hypothèses de conception. Avec un seul opérateur coopératif et un environnement maîtrisé, il n’a besoin de rien devant lui. Au-delà de ce point, les questions d’intégration s’accumulent : diversité d’opérateurs, profils SIP personnalisés, attestation en industrie réglementée, exposition à l’internet public, livraison de services multi-locataire. Chacune de ces questions se résout proprement avec un SBC en bordure.

Les fonctionnalités décisives lors de l’évaluation d’un SBC pour FreeSWITCH sont l’architecture B2BUA pour un contrôle total des en-têtes, la politique de transport et de codecs par NAP, un routage programmable qui parle le langage des opérateurs FreeSWITCH, un modèle partenaire STIR/SHAKEN ouvert, et une évaluation en libre-service pour confirmer que l’intégration fonctionne avant de signer quoi que ce soit. Obtenez ces éléments et le SBC fait discrètement son travail pendant des années tandis que FreeSWITCH continue de faire ce qu’il fait bien.