Pare-feu SIP vs SBC : choisir le bon périmètre vocal

La plupart des débats « pare-feu vs SBC » réduisent trois catégories de produits différentes à deux. Il y a le pare-feu réseau, qui opère généralement aux couches 3/4 et n’effectue pas de contrôle SIP complet. Il y a le pare-feu SIP, qui inspecte la signalisation SIP mais s’arrête généralement avant la gestion complète des médias. Et il y a le session border controller, qui termine et ré-émet la signalisation de manière indépendante et peut ancrer, relayer, sécuriser ou transformer les médias selon la politique en vigueur à la bordure du réseau. Considérer deux de ces catégories comme interchangeables conduit à sur-acheter, à sous-protéger, ou les deux.

Le terme « pare-feu SIP » est celui qui crée le plus de confusion. C’est une véritable catégorie de produits vendue par des fournisseurs comme Ingate, certaines références AudioCodes et les anciens appareils Borderware, mais c’est aussi une étiquette que certains pare-feux appliquent lorsqu’un module SIP Application Layer Gateway (ALG) est activé. Les deux cas ne sont pas équivalents. L’acheteur qui demande « ai-je besoin d’un pare-feu SIP ou d’un SBC ? » souhaite généralement une réponse simple sur la classe de produit adaptée à son déploiement, et non un exposé sur les raisons pour lesquelles un pare-feu réseau ne peut pas inspecter le SIP.

Ce guide sépare les trois catégories, les compare sur les capacités qui comptent réellement pour la voix, et passe en revue six scénarios de déploiement courants afin que vous puissiez associer votre environnement à la bonne classe de produit. Le tableau comparatif se trouve au milieu de l’article et constitue le moyen le plus rapide de visualiser les différences si vous ne disposez que d’une minute.

Les trois catégories de produits au périmètre vocal

Chaque réseau vocal possède un périmètre, et chaque périmètre nécessite une combinaison de trois types de contrôles. Lire « pare-feu SIP vs SBC » comme une question binaire masque le fait que la plupart des déploiements en production utilisent au moins deux des trois, et certains utilisent les trois.

Un pare-feu réseau se situe à la bordure du réseau IP. Il détermine qui peut atteindre l’infrastructure vocale au niveau des paquets. L’adresse IP source, l’adresse IP de destination, le protocole de transport et le numéro de port sont les contrôles disponibles. Le pare-feu n’analyse pas le SIP, ne considère pas le RTP comme du média et traite les deux comme du trafic UDP ou TCP générique. Presque tous les déploiements vocaux en disposent, soit sous forme d’appliance dédiée, soit sous forme de groupe de sécurité d’un fournisseur cloud.

Un pare-feu SIP couvre une gamme de produits plus large que le nom ne le suggère. La catégorie comprend des appliances dédiées conçues pour la signalisation (Ingate SIParator en est l’exemple de référence, avec des modèles antérieurs de Borderware et d’anciens appareils Polycom), des modules logiciels intégrés à un pare-feu généraliste (le SIP ALG sur Cisco ASA, Fortinet, Palo Alto, SonicWall), et des solutions open source où Kamailio ou OpenSIPS est configuré en périmètre SIP. Ce qu’ils ont en commun, c’est la connaissance de la signalisation sans terminaison complète des médias : ils analysent les en-têtes SIP, appliquent des règles à la signalisation et transfèrent généralement les médias sans établir de contrôle média indépendant.

Un session border controller remplit l’ensemble complet des fonctions de périmètre vocal sur les deux plans. Il termine le dialogue SIP entrant, en établit un nouveau en sortie, et fait de même pour le flux média via l’ancrage média. Cette architecture, le B2BUA, est ce qui permet au SBC d’appliquer le chiffrement par segment, de manipuler les en-têtes, de masquer la topologie, d’exécuter une logique de routage, d’effectuer le transcodage, d’ancrer et de convertir le SRTP, de s’intégrer aux services de signature STIR/SHAKEN et d’absorber le trafic de déni de service au niveau applicatif. La plupart des produits SBC publiés aujourd’hui sont logiciels et fonctionnent sur une infrastructure standard.

Les trois catégories se chevauchent aux marges, notamment parce que le marketing des fournisseurs étiquette parfois le même appareil comme « pare-feu SIP » ou « session border controller » selon le public visé. Le tableau des capacités présenté plus loin dans ce guide est le moyen le plus fiable de déterminer à quelle classe de produit un appareil donné appartient réellement.

Ce qu’un pare-feu réseau fait pour le SIP, et ce qu’il ne fait pas

Un pare-feu réseau est essentiel pour la voix. Chaque périmètre vocal devrait en comporter un. La question est ce qu’il peut et ne peut pas faire une fois que le trafic SIP le traverse.

Concernant ce qu’il peut faire, un pare-feu réseau applique des listes d’autorisation par IP source pour les pairs opérateurs de confiance, restreint les ports SIP et RTP à des plages connues, rejette les attaques volumétriques évidentes (floods TCP SYN, amplification UDP, floods ICMP) avant qu’elles n’atteignent l’infrastructure vocale, et fournit la politique d’accès de base aux couches 3 / 4 qui empêche le trafic internet aléatoire d’atteindre le listener SIP. Dans les déploiements cloud, c’est le rôle d’un groupe de sécurité AWS, d’un NSG Azure ou d’une règle de pare-feu Google Cloud, complété par le scrubbing DDoS que le fournisseur cloud offre à la bordure du réseau.

Concernant ce qu’il ne peut pas faire, un pare-feu réseau ne peut pas inspecter le corps d’un message SIP. Un flood d’INVITE SIP, un flood de REGISTER SIP, un message SIP malformé conçu pour épuiser les ressources de traitement ou déclencher des erreurs d’analyseur, et un établissement d’appel normal sont tous identiques pour le pare-feu : des paquets UDP vers le port 5060. Le pare-feu ne peut pas limiter le débit par méthode SIP, ne peut pas détecter que des enregistrements arrivent avec des identifiants séquentiels ou invalides, et ne peut pas identifier un flood utilisant des IP sources usurpées. Pour un examen approfondi des raisons pour lesquelles les floods SIP contournent les contrôles des couches 3 / 4, consultez le guide détaillé sur la prévention des attaques DoS SIP.

Le SIP ALG fourni avec la plupart des pare-feux généralistes est censé combler cette lacune, et il aggrave généralement la situation. Les SIP ALG sont bien connus pour réécrire les en-têtes SIP de manière à casser les flux d’appels, interférer avec la traversée NAT, mal gérer les re-INVITE et produire de l’audio unidirectionnel difficile à diagnostiquer. De nombreux ingénieurs vocaux désactivent le SIP ALG comme première étape lors du dépannage d’un nouveau déploiement. Le guide de sécurité SBC couvre les modes de défaillance du SIP ALG en détail.

La conclusion est simple. Un pare-feu réseau a sa place dans l’architecture. Il est nécessaire mais insuffisant pour le trafic SIP, et le SIP ALG est rarement la bonne manière de combler cette lacune.

Ce qu’est réellement un « pare-feu SIP »

Le pare-feu SIP est la zone grise. L’étiquette couvre des produits aux capacités très différentes, de sorte que deux acheteurs comparant des « pare-feux SIP » peuvent finir par examiner des appareils qui ne font presque rien de similaire.

Le cas le plus clair est une appliance dédiée de pare-feu SIP. Ingate SIParator est le produit de référence de longue date dans cette catégorie et se positionne explicitement comme un hybride pare-feu SIP / E-SBC. L’appareil analyse le SIP, applique des règles d’autorisation / de blocage au niveau SIP, peut limiter le débit par méthode SIP, gère le trafic d’enregistrement et ancre ou transfère les médias de manière transparente selon la configuration. D’autres fournisseurs ont proposé des appareils similaires au fil des ans, notamment les anciens appareils Borderware et certaines références E-SBC de Polycom et AudioCodes commercialisées en mode pare-feu pour les déploiements PME. Ce sont de véritables appareils de périmètre conçus pour la signalisation.

Un deuxième cas est le SIP ALG intégré à un pare-feu généraliste, que certains fournisseurs et revendeurs présentent comme une fonctionnalité de « pare-feu SIP ». Comme indiqué précédemment, le SIP ALG est théoriquement conscient de la signalisation mais opérationnellement fragile en pratique. L’appeler pare-feu SIP brouille la catégorie, car le profil de capacités est bien plus étroit qu’une appliance dédiée.

Un troisième cas est l’open source. Kamailio et OpenSIPS peuvent tous deux être configurés pour agir comme un périmètre SIP qui filtre, limite le débit et transfère le trafic SIP vers une plateforme de traitement d’appels en aval. Certains opérateurs les déploient devant une installation Asterisk ou FreePBX comme couche « pare-feu SIP », souvent associés à fail2ban pour le blocage par IP source. Cela fonctionne pour les petits déploiements où l’opérateur dispose de la profondeur technique nécessaire pour le maintenir et où les médias peuvent transiter sans modification.

Ce que partagent la plupart des pare-feux SIP, c’est l’accent sur la signalisation. Ils analysent les messages SIP, appliquent des politiques à ces messages et laissent passer le RTP via un pinhole plutôt que de le ré-émettre. Ils sont généralement déployés comme des proxys SIP plutôt que comme des B2BUA, ce qui signifie qu’ils ne créent pas de rupture nette entre les dialogues externes et internes. Les implications pratiques sont importantes : masquage de topologie limité, pas de politique de chiffrement par segment, pas de limitation de débit sur le plan média, et des difficultés d’intégration avec les plateformes qui exigent une gestion stricte des médias comme Microsoft Teams Direct Routing.

Un pare-feu SIP est une classe de produit réelle et utile. C’est aussi une classe de produit plus étroite que le terme ne le suggère, et un pare-feu SIP n’est pas un session border controller même lorsque les fournisseurs brouillent les étiquettes.

Ce qu’un SBC complet ajoute par rapport à un pare-feu SIP

Un SBC part du même point qu’un pare-feu SIP, à savoir la connaissance de la signalisation à la bordure du réseau. Il ajoute ensuite le plan média, un moteur de routage, la normalisation, la gestion des enregistrements et le masquage de topologie.

L’ancrage média et le chiffrement constituent la différence la plus visible. Le SBC reçoit le RTP sur le segment externe et le retransmet sur le segment interne, avec des contextes de chiffrement séparés de chaque côté. C’est ce qui rend possibles le relais SRTP et la conversion RTP vers SRTP. Un déploiement Microsoft Teams Direct Routing, une intégration WebRTC et un PBX traditionnel derrière un opérateur moderne reposent tous sur ce comportement. Un pare-feu SIP limité à la signalisation n’a pas de média à terminer et ne peut donc effectuer ni l’un ni l’autre.

La normalisation SIP couvre les règles qui ajustent les en-têtes SIP par segment d’appel ou par groupe de trunks pour assurer l’interopérabilité dans les environnements multi-fournisseurs. La manipulation des en-têtes SIP inclut des opérations telles que la correction du P-Asserted-Identity pour la compatibilité STIR/SHAKEN, les corrections d’en-têtes Via pour les messages malformés, la gestion des temporisateurs de session selon la RFC 4028, et la suppression ou l’ajout d’extensions propriétaires. Un pare-feu SIP offre souvent une normalisation limitée, mais expose généralement moins de contrôle par segment que les plateformes SBC.

Le moteur de routage est l’élément qui transforme le SBC d’un dispositif de périmètre en un point de contrôle du flux d’appels. Les règles de routage peuvent diriger les appels vers différents opérateurs par préfixe de destination, par heure de la journée, par coût minimal, par niveau d’attestation, ou par le résultat d’une requête API externe vers un service de scoring de fraude, une base de données LNP ou un CRM. Le guide de routage d’appels par API REST du SBC détaille ce sujet. La plupart des pare-feux SIP disposent d’une surface de routage plus réduite et s’appuient sur une plateforme en aval pour toute logique non triviale.

La gestion des enregistrements constitue l’autre différence majeure. Un SBC peut agir comme relayeur d’enregistrements vers les registrars en amont, protéger le registrar contre le scanning d’enregistrements et le bourrage d’identifiants, et maintenir l’état d’enregistrement pour les terminaux derrière un NAT. De nombreuses implémentations de pare-feu SIP offrent une connaissance limitée des enregistrements comparée aux plateformes SBC.

Le masquage de topologie fonctionne grâce à l’architecture B2BUA. Les en-têtes de routage et sensibles à la topologie sont générés par le SBC selon la politique en vigueur, et non transférés depuis le côté externe. Ainsi, les adresses IP internes, les noms d’hôte et les identifiants n’atteignent jamais l’internet public. Un pare-feu SIP en mode proxy transfère les en-têtes originaux et divulgue donc davantage d’informations topologiques sauf configuration approfondie.

L’intégration STIR/SHAKEN est l’ajout moderne. Un SBC est l’emplacement naturel pour interroger un service de signature, générer et attacher les informations d’identité PASSporT transportées dans l’en-tête Identity de l’INVITE sortant, et valider l’en-tête Identity sur les appels entrants. ProSBC prend cela en charge via des scripts de routage Ruby qui s’intègrent à TransNexus ClearIP, Neustar et d’autres fournisseurs STI-AS, avec redondance primaire / secondaire et contrôle d’attestation par appel. Un pare-feu SIP limité à la signalisation ne dispose pas de la surface de routage nécessaire pour prendre des décisions d’attestation par appel.

Chacune de ces capacités est à un scénario d’acheteur de devenir déterminante. Le cadre de décision dans la section suivante associe ces scénarios aux classes de produits.

Comparaison des capacités côte à côte

Le tableau ci-dessous met en correspondance les capacités importantes au périmètre vocal avec les trois catégories de produits. « Partiel » est utilisé lorsque la capacité est techniquement présente mais matériellement plus étroite que la catégorie de la colonne à droite.

Capacité	Pare-feu réseau	Pare-feu SIP	Session Border Controller
Filtrage IP / port aux couches 3 / 4	Fonction principale	Souvent inclus	Granularité par NAP
Inspection des messages SIP (couche applicative)	SIP ALG uniquement, souvent désactivé	Analyse SIP complète	Analyse SIP complète
Architecture B2BUA (terminaison complète du dialogue)		Généralement en mode proxy
Limitation de débit SIP (par méthode, par source, par trunk)		Par méthode uniquement	Les trois portées
Liste noire et liste grise dynamiques	Blocage IP statique uniquement	IP dynamique uniquement	Y compris liste grise en pourcentage
Protection contre le scanning d’enregistrements		Filtrage REGISTER uniquement	Détection basée sur les modèles
Gestion du plan média (ancrage RTP)	Pinholes uniquement	Pass-through typique	Ancrage média complet
Terminaison TLS pour la signalisation SIP		Certains produits	Par segment
Relais SRTP et conversion RTP vers SRTP
Manipulation des en-têtes SIP pour la normalisation multi-fournisseurs		Suppression / transfert uniquement	Réécriture par segment
Masquage de topologie		Limité en mode proxy	Natif au B2BUA
Moteur de routage configurable		Règles basiques	Piloté par API
Transcodage (conversion de codecs)			DSP logiciel ou matériel
Signature et vérification STIR/SHAKEN			Intégration STI-AS
Prise en charge de Microsoft Teams Direct Routing		Pas de SRTP

Comparaison des capacités entre les trois catégories de produits au périmètre vocal.

Un cadre de décision par scénario de déploiement

La bonne classe de produit dépend de ce qui se trouve derrière le périmètre et de ce qui le traverse. Les six scénarios ci-dessous couvrent la plupart des déploiements vocaux en production.

Petite entreprise unique, PBX unique, pas de SIP exposé sur internet

Le site dispose d’un PBX hébergé ou d’un PBX sur site qui communique avec un seul opérateur via un circuit privé ou un trunk SIP managé sur une seule IP statique. L’exposition internet de l’infrastructure vocale est nulle. Un pare-feu réseau avec des listes d’autorisation strictes sur l’IP de l’opérateur et les plages de ports SIP et RTP suffit. Un pare-feu SIP n’apporte que peu de valeur, et un SBC représente un sur-investissement sauf si le site a besoin du chiffrement média, de Teams Direct Routing ou du routage multi-opérateur.

PME avec un trunk SIP sur l’internet public

Le site dispose d’un ou plusieurs trunks SIP atteignant l’opérateur via l’internet public. Les IP sources de l’opérateur peuvent changer, ou l’opérateur peut exiger une connectivité basée sur un FQDN. Un pare-feu SIP est un choix défendable si les seules exigences sont le filtrage de signalisation et l’application par IP source. Un petit SBC est le choix le plus courant en 2026 car le même appareil offre le SRTP, la normalisation d’en-têtes et la possibilité d’ajouter un second opérateur ultérieurement sans restructurer le périmètre.

MSP servant 10 à 200 clients entreprise (Teams Direct Routing)

C’est le scénario dominant de SBC pour MSP. Microsoft Teams Direct Routing est le déclencheur, et Microsoft exige le TLS pour la signalisation SIP, le SRTP pour les médias, le mutual TLS pour l’interface Teams et un FQDN correspondant à un certificat d’une autorité de certification approuvée par Microsoft. Un pare-feu SIP ne peut pas satisfaire ces exigences car il ne termine pas les médias et n’applique pas de politique TLS / SRTP par segment. La bonne classe de produit est un SBC, déployé en mode multi-tenant pour qu’un seul appareil serve de nombreux tenants clients. Consultez le guide Teams Direct Routing pour la procédure de configuration complète.

FAI, ILEC ou fournisseur de voix en gros

L’opérateur revend des trunks SIP, effectue l’attestation STIR/SHAKEN, s’interconnecte avec plusieurs opérateurs et gère un large éventail de terminaux clients. Rien de tout cela n’entre dans le périmètre d’un pare-feu SIP. Le SBC est la seule classe de produit qui offre le moteur de routage, la logique d’attestation par appel et la normalisation d’en-têtes multi-fournisseurs que ce profil exige. Le guide sur l’authentification des appels STIR/SHAKEN explique pourquoi l’attestation doit résider dans la couche de routage.

Centre de contact migrant vers une plateforme cloud (BYOC)

Le centre de contact migre de la voix sur site vers une plateforme cloud telle que Genesys, Five9 ou NICE, avec un modèle Bring Your Own Carrier. La plateforme cloud bénéficie généralement d’un SBC en bordure afin que le centre de contact conserve le choix de l’opérateur, le contrôle anti-fraude, l’intégration d’enregistrement et les métriques de qualité indépendamment de la plateforme. Un pare-feu SIP ne fournit pas les points d’intégration d’enregistrement, les hooks de routage pour le scoring de fraude, ni l’isolation CDR par NAP dont un centre de contact a besoin. Le SBC est la bonne classe.

Transit et peering entre opérateurs

L’opérateur est un transporteur de transit ou un hub de peering avec de nombreuses relations SIP en amont et en aval. La politique de chiffrement par pair, la normalisation d’en-têtes, les limites de débit anti-fraude et le masquage de topologie vis-à-vis de chaque pair sont tous essentiels. C’est le cas d’usage originel du SBC, et la classe de produit pare-feu SIP ne l’a jamais visé.

Le piège du « nous avons déjà un pare-feu »

L’erreur la plus courante dans la planification du périmètre vocal est de conclure qu’un pare-feu réseau couvre le SIP parce qu’il dispose d’une case à cocher SIP ALG. Les sections précédentes ont expliqué pourquoi cela est insuffisant. Trois modes de défaillance méritent d’être signalés explicitement car ils ne se manifestent généralement qu’après un incident.

Les attaques par flood SIP traversent les pare-feux sans modification. Un flood d’INVITE, un flood de REGISTER, un flood d’OPTIONS et une attaque par messages malformés ressemblent tous à du trafic UDP valide pour le pare-feu. Le guide approfondi sur la prévention des attaques DoS SIP couvre chaque type d’attaque et la manière dont la limitation de débit au niveau applicatif les arrête. Un pare-feu SIP couvre une partie de cette surface (limitation de débit au niveau signalisation), tandis qu’un SBC couvre l’ensemble, y compris les floods sur le plan média.

Le chiffrement média est impossible sans terminaison média. Le SRTP exige que l’appareil gère le flux RTP, dérive les clés par segment et re-chiffre du côté sortant. Ni un pare-feu réseau ni un pare-feu SIP limité à la signalisation ne font cela. Les déploiements qui nécessitent le SRTP pour la conformité (Teams Direct Routing, WebRTC, ePHI liés à HIPAA en transit) exigent un SBC. Consultez le guide de configuration TLS et SRTP du SBC pour les modèles de déploiement.

La fuite de topologie est difficile à corriger rétroactivement. Un pare-feu SIP en mode proxy transfère les en-têtes SIP qu’il reçoit, y compris les en-têtes Via, Contact et d’identité qui révèlent les adresses IP et les noms d’hôte internes. Une fois que des parties externes ont vu ces en-têtes, les attaquants peuvent cibler directement l’infrastructure interne et contourner entièrement le périmètre. L’architecture B2BUA d’un SBC génère de nouveaux en-têtes du côté interne, de sorte que la topologie interne reste interne. Le guide de sécurité SBC couvre le masquage de topologie en plus des quatre autres couches de sécurité.

L’architecture correcte pour un déploiement vocal utilisant l’une des plateformes vocales modernes est en couches. Le pare-feu réseau gère la politique de trafic aux couches 3 / 4. Le SBC gère le SIP, les médias, le chiffrement, le routage et la topologie. Le pare-feu SIP occupe une niche plus étroite et s’avère le plus utile lorsque le déploiement n’a véritablement pas besoin de gestion des médias ni de routage.

Où se positionne ProSBC

ProSBC est un session border controller logiciel qui couvre l’intégralité de la colonne SBC du tableau comparatif. Les fonctionnalités qui apparaissent le plus souvent dans les scénarios d’achat ci-dessus sont toutes incluses : architecture B2BUA, TLS et SRTP par segment, normalisation SIP complète, limitation de débit par NAP et liste noire dynamique avec liste grise en pourcentage, protection contre le scanning d’enregistrements SIP, masquage de topologie, routage configurable via une API Ruby, et signature STIR/SHAKEN à travers des intégrations partenaires ouvertes avec TransNexus ClearIP et Neustar.

ProSBC monte jusqu’à 60 000 sessions par serveur, prend en charge jusqu’à 1 024 NAP pour les déploiements multi-tenant et fonctionne sur AWS, Azure, VMware, KVM, Proxmox ou du matériel physique. Les tarifs commencent à partir de 1,40 $ par session par an en abonnement, avec un essai gratuit de 30 jours pour l’évaluation commerciale et une licence permanente ProSBC Lab qui fournit trois sessions simultanées pour les tests et le travail d’intégration.

Le point d’entrée le plus courant pour les acheteurs comparant les pare-feux SIP aux SBC est la licence ProSBC Lab. Elle offre l’ensemble complet des fonctionnalités, se déploie en environ 20 minutes et permet à l’acheteur de tester le comportement du périmètre avec ses propres intégrations opérateur et plateforme avant de s’engager sur un niveau payant.

Questions fréquemment posées

Un pare-feu SIP est-il la même chose qu’un SBC ?

Non. Un pare-feu SIP est conscient de la signalisation et fonctionne généralement comme un proxy SIP sans terminer les médias. Un session border controller termine et ré-émet la signalisation de manière indépendante, et peut ancrer, relayer, sécuriser ou transformer les médias selon la politique en tant que B2BUA, ce qui permet le relais SRTP, le transcodage, la politique de chiffrement par segment, le masquage de topologie et un moteur de routage configurable. Certains fournisseurs utilisent les étiquettes de manière interchangeable, mais les profils de capacités diffèrent.

Puis-je simplement activer le SIP ALG sur mon pare-feu existant ?

La plupart des ingénieurs vocaux désactivent les SIP ALG comme première étape de dépannage. Les SIP ALG réécrivent les en-têtes SIP de manière à casser fréquemment l’établissement d’appel, la traversée NAT, les re-INVITE et la négociation SRTP, et ils n’offrent qu’une fraction des capacités d’un pare-feu SIP dédié ou d’un SBC.

Ai-je besoin d’un SBC pour Microsoft Teams Direct Routing ?

Oui. Microsoft exige le TLS pour la signalisation SIP, le SRTP pour les médias, le mutual TLS pour l’interface Teams, un FQDN avec un certificat d’une autorité de certification approuvée par Microsoft, et la gestion des SIP OPTIONS pour la surveillance de la santé. La plupart des produits pare-feu SIP ne sont pas conçus pour satisfaire l’ensemble des exigences de Microsoft Teams Direct Routing car ils ne terminent pas les médias. Microsoft publie également une liste de SBC certifiés ; ProSBC prend en charge Teams Direct Routing mais ne figure pas sur la liste certifiée de Microsoft au moment de la rédaction.

Où se situe le pare-feu réseau si je dispose d’un SBC ?

Les deux sont présents dans l’architecture. Le pare-feu réseau applique la politique d’accès aux couches 3 et 4 et absorbe les attaques réseau volumétriques. Le SBC se situe derrière et gère l’ensemble des contrôles SIP et RTP. Dans les déploiements cloud, les groupes de sécurité et la protection DDoS du fournisseur cloud remplissent le rôle du pare-feu réseau.

Quand un pare-feu SIP est-il le bon choix par rapport à un SBC ?

Un pare-feu SIP convient à un profil étroit : un déploiement qui nécessite un filtrage SIP au niveau applicatif, qui n’a pas d’exigences sur le plan média (pas de SRTP, pas de transcodage, pas de Teams Direct Routing), qui utilise un environnement SIP unique et homogène, et qui préfère un appareil plus petit et moins coûteux. Dès que le déploiement ajoute une plateforme vocale moderne ou une exigence de chiffrement, le SBC devient la bonne classe.

ProSBC est-il aussi un pare-feu SIP ?

ProSBC inclut toutes les capacités d’un pare-feu SIP (analyse de la signalisation, limitation de débit au niveau applicatif, liste noire dynamique, protection contre le scanning d’enregistrements, masquage de topologie) et y ajoute l’ensemble complet des capacités SBC. Les acheteurs comparant les produits pare-feu SIP à ProSBC comparent un appareil plus étroit à un sur-ensemble.