Déploiements vocaux cloud et le SBC : architecture pour la voix multi-cloud, hybride et SaaS

Les plateformes cloud ont absorbé la plupart des charges de travail d’entreprise, mais la voix reste l’exception qui confirme la règle. La messagerie, le CRM et la collaboration ont migré vers le SaaS avec un minimum de friction parce qu’ils tolèrent la latence, fonctionnent sur HTTPS et ne touchent jamais le réseau téléphonique public. La voix est différente. Elle fonctionne sur SIP, exige une latence aller-retour inférieure à 150 ms, et chaque appel qui atteint un numéro de téléphone doit traverser une interconnexion opérateur régie par des décennies de réglementation télécom et des implémentations SIP spécifiques à chaque fournisseur.

Le Session Border Controller est le composant qui comble ce fossé. Que votre plateforme vocale fonctionne entièrement dans le cloud, s’étende sur plusieurs fournisseurs cloud, ou chevauche une infrastructure sur site et un cloud public, le SBC se situe à la frontière où les trunks SIP rencontrent les services cloud. Il termine les connexions opérateur d’un côté et les connexions de plateforme cloud de l’autre, gérant la traduction du chiffrement, la normalisation SIP et l’application de la sécurité que ni l’opérateur ni la plateforme cloud ne fournissent seuls.

Cet article explique pourquoi la voix cloud nécessite toujours un SBC à la périphérie du réseau, comment fonctionnent les trois modèles de déploiement dominants, et ce qui se passe à la frontière d’interconnexion opérateur pour les architectures CPaaS, UCaaS et hybrides.

Pourquoi la voix cloud nécessite encore une périphérie physique

Les plateformes vocales cloud gèrent le contrôle d’appel, la gestion des utilisateurs et des fonctionnalités de plus en plus sophistiquées comme les agents vocaux IA et la transcription en temps réel. Ce qu’elles ne gèrent pas, c’est le transfert vers l’opérateur. Chaque appel qui provient du ou se termine sur le réseau téléphonique public doit traverser une frontière de trunk SIP où la plateforme cloud rencontre un opérateur télécom, et c’est à cette frontière que les problèmes se concentrent.

Les opérateurs livrent le trafic SIP avec des implémentations d’en-têtes spécifiques au fournisseur, un support de chiffrement variable et des exigences de transport qui diffèrent d’un trunk à l’autre. Un opérateur peut envoyer du SIP sur UDP sans chiffrement ; un autre peut exiger TLS 1.2 avec authentification mutuelle par certificat. La plateforme cloud de l’autre côté a ses propres exigences. Le Microsoft Teams Direct Routing impose TLS et SRTP sur chaque connexion. Genesys Cloud attend des formats d’en-tête SIP spécifiques pour son interface trunk BYOC. L’Elastic SIP Trunking de Twilio a ses propres exigences de normalisation.

Le SBC résout cette incompatibilité en fonctionnant comme un B2BUA qui termine complètement le SIP d’un côté et le ré-émet de l’autre. Chaque côté obtient le chiffrement, les en-têtes, les codecs et le transport qu’il attend, négociés indépendamment. Sans SBC, chaque combinaison opérateur-plateforme nécessite un travail d’intégration sur mesure que le fournisseur de la plateforme cloud ne réalisera pas et que l’opérateur n’a aucune incitation à prendre en charge.

Au-delà de la traduction de protocole, le SBC fournit le périmètre de sécurité que les plateformes cloud supposent existant mais n’implémentent pas elles-mêmes. La protection DoS au niveau SIP, la mise en liste noire dynamique, la défense contre le scan d’enregistrement SIP et la prévention de la fraude tarifaire s’exécutent toutes au SBC avant que le trafic n’atteigne l’application cloud. Exposer une plateforme vocale cloud directement au trafic SIP opérateur sans SBC est l’équivalent vocal de placer une application web sur l’Internet public sans pare-feu.

Trois modèles de déploiement pour les SBC cloud

Les déploiements SBC cloud se répartissent en trois modèles architecturaux. Le bon choix dépend de l’endroit où s’exécutent vos charges de travail vocales, de l’endroit où vos opérateurs se connectent et de la quantité d’infrastructure sur site que vous comptez maintenir.

Cloud pur

Dans un déploiement cloud pur, le SBC fonctionne comme une machine virtuelle aux côtés de l’application vocale chez le même fournisseur cloud. C’est le modèle le plus simple : l’instance SBC se déploie sur AWS, Azure, VMware ou KVM/Proxmox, les trunks SIP opérateur se terminent sur l’interface publique du SBC, et la plateforme vocale se connecte au SBC via le réseau interne du fournisseur cloud. La latence entre le SBC et l’application est minimale puisque les deux se trouvent dans le même centre de données ou la même zone de disponibilité.

Le cloud pur fonctionne bien pour les organisations qui ont entièrement migré vers une plateforme vocale cloud et n’ont plus d’équipement de téléphonie sur site. Il élimine complètement les appliances SBC matérielles, remplaçant les dépenses d’investissement par un modèle d’abonnement qui évolue avec le nombre réel de sessions.

Multi-cloud

Les déploiements multi-cloud placent des instances SBC sur deux fournisseurs cloud ou plus, ou dans plusieurs régions. Un FSG fournissant du Teams Direct Routing multi-locataire pourrait exécuter son SBC principal sur Azure pour la latence la plus faible vers Microsoft 365, avec une instance de secours sur AWS pour la diversité opérateur et la redondance géographique. Un opérateur de centre de contact exécutant Genesys Cloud BYOC pourrait placer des instances SBC dans US-Est et UE-Ouest pour respecter les exigences de résidence des données tout en maintenant la capacité de basculement.

Le SBC est particulièrement adapté au multi-cloud car il fonctionne comme une fonction réseau autonome. Chaque instance se connecte à ses opérateurs locaux et aux terminaux de plateforme cloud de manière indépendante, avec des règles de routage qui peuvent diriger le trafic entre les instances en fonction de la charge, de la disponibilité ou de la politique. La prise en charge par ProSBC d’AWS, Azure, VMware, KVM/Proxmox et bare metal signifie que les mêmes logiciels et modèles de configuration s’appliquent quel que soit le cloud hébergeant une instance donnée.

Hybride sur site + cloud

L’hybride est le modèle le plus courant en pratique, car la plupart des organisations ne migrent pas toutes les charges de travail vocales vers le cloud en une seule fois. Un déploiement hybride typique conserve un PBX sur site (Avaya, Cisco ou FreeSWITCH) pour les postes internes tout en acheminant les appels externes via un SBC hébergé dans le cloud qui se connecte à la fois au PBX existant et à une plateforme UCaaS cloud. Le SBC gère la normalisation SIP entre le dialecte SIP du PBX existant et les exigences de la plateforme cloud, chiffre le trafic qui traverse l’Internet public et fournit un point de gestion unique pour les connexions opérateur qui desservent les deux environnements.

Les déploiements hybrides servent également de chemin de migration du sur site vers le cloud complet. L’architecture basée sur les NAP du SBC permet aux opérateurs de migrer les groupes de trunks un à la fois, déplaçant les connexions opérateur du segment sur site vers le segment cloud progressivement. À tout moment, le retour en arrière d’un seul groupe de trunks est un changement de routage, pas une ré-architecture.

Interconnexion opérateur CPaaS et UCaaS

Le rôle du SBC devient plus visible à la frontière d’interconnexion opérateur pour les plateformes CPaaS et UCaaS. Ces plateformes abstraient la voix en API et services gérés, mais l’abstraction se brise à la frontière RTPC où de vrais trunks SIP acheminent de vrais appels vers de vrais numéros de téléphone.

UCaaS : Teams, Zoom, RingCentral

Les plateformes UCaaS présentent le modèle d’intégration SBC le plus propre parce que le fournisseur de la plateforme définit les exigences SIP explicitement. Microsoft Teams exige TLS avec un certificat d’une CA de confiance, SRTP pour tous les médias, la surveillance heartbeat SIP OPTIONS et un formatage d’en-tête SIP spécifique. Le SBC termine le trunk SIP de l’opérateur d’un côté (souvent en UDP non chiffré) et présente du TLS/SRTP conforme à Teams de l’autre. ProSBC prend en charge Teams Direct Routing et a été déployé avec succès dans des environnements Teams DR auprès de FSG, FAI et réseaux d’entreprise.

Pour les FSG servant plusieurs clients, le SBC permet la livraison vocale Teams multi-locataire depuis une seule instance. Chaque locataire Microsoft 365 du client se connecte via un NAP dédié avec son propre FQDN de sous-domaine, son certificat TLS et ses règles de routage, tout en partageant les connexions opérateur sous-jacentes et l’infrastructure SBC.

CPaaS : Twilio, Telestax, Cloudoni

L’interconnexion opérateur CPaaS fonctionne différemment car le SBC se situe entre la plateforme CPaaS et les propres opérateurs de l’organisation dans un modèle BYOC. Au lieu d’utiliser la téléphonie intégrée du fournisseur CPaaS (et de payer des tarifs à la minute à grande échelle), l’organisation apporte ses propres trunks SIP et utilise le SBC pour normaliser le trafic entre ses opérateurs et le terminal SIP de la plateforme CPaaS.

Ce modèle est de plus en plus courant parmi les organisations qui construisent des agents vocaux IA, des composeurs sortants automatisés et des systèmes SVI programmables. La plateforme CPaaS fournit la logique applicative, mais le SBC fournit le routage opérateur, la sécurité, la signature STIR/SHAKEN et le contrôle des coûts. Aircall, par exemple, utilise ProSBC sur AWS pour normaliser le trafic de fournisseurs SIP internationaux pour plus de 50 000 utilisateurs, en exploitant le moteur de manipulation d’en-têtes SIP et l’API RESTful du SBC pour gérer la diversité opérateur dans plusieurs pays.

BYOC pour centres de contact

Les plateformes de centres de contact cloud (Genesys Cloud, Five9, NICE CXone, Talkdesk) prennent toutes en charge les modèles BYOC où le client fournit ses propres trunks SIP via un SBC. Le SBC gère la même normalisation opérateur et traduction de chiffrement que dans le cas UCaaS, avec des exigences supplémentaires pour une densité de sessions élevée, un traitement média à faible latence et l’intégration avec des systèmes de prévention de la fraude qui évaluent les appels pendant l’établissement.

Sécurité à la périphérie vocale cloud

Migrer la voix vers le cloud n’élimine pas la surface d’attaque ; elle la déplace. Le SBC devient le périmètre de sécurité entre l’Internet public (où arrive le trafic SIP opérateur) et l’environnement cloud (où s’exécutent les applications vocales). Un traitement complet des capacités de sécurité du SBC est disponible dans le guide dédié Sécurité SBC, mais les préoccupations spécifiques au cloud méritent une attention particulière.

Le pontage de chiffrement est la fonction de sécurité la plus fondamentale. Les plateformes cloud imposent TLS et SRTP, tandis que de nombreux opérateurs livrent encore le trafic sur UDP non chiffré. Le SBC termine le SIP/RTP non chiffré côté opérateur et ré-émet du TLS/SRTP chiffré côté cloud. ProSBC négocie TLS 1.3 exclusivement sans repli vers des versions antérieures, garantissant que le segment chiffré répond à la norme la plus forte disponible. Les pairs qui ne peuvent pas négocier TLS 1.3 se connectent via des segments UDP ou TCP, où le SBC fournit toujours l’inspection au niveau signalisation et l’ancrage média.

Le masquage de topologie prend une importance supplémentaire dans les environnements cloud. Les orchestrateurs de conteneurs, les répartiteurs de charge et les couches réseau cloud introduisent des adresses IP internes qui ne doivent jamais fuiter dans les en-têtes SIP traversant l’Internet public. L’architecture B2BUA du SBC remplace toutes les adresses internes par l’IP publique du SBC, rendant l’infrastructure cloud architecturalement invisible aux parties externes.

La prévention des attaques au niveau SIP protège l’application cloud contre les menaces que les pare-feu réseau ne peuvent pas traiter. Les attaques par inondation SIP, le scan d’enregistrement et les exploits de messages SIP malformés ciblent tous la couche application. Le SBC inspecte le trafic SIP au niveau protocole, appliquant une limitation de débit par méthode, par source et par groupe de trunks, avec une mise en liste noire dynamique qui bloque automatiquement les sources dépassant les seuils configurés.

Haute disponibilité et basculement entre régions cloud

La voix tolère mal les temps d’arrêt. Une application web qui retourne un 503 pendant trente secondes cause un désagrément ; une plateforme vocale qui perd des appels pendant trente secondes cause une perturbation opérationnelle et, pour les fournisseurs de services, des violations de SLA avec des pénalités financières. La haute disponibilité dans les déploiements SBC cloud opère à deux niveaux : au niveau instance et au niveau région.

La HA au niveau instance utilise une paire 1+1 où une instance SBC de secours surveille la principale et reprend son adresse IP et ses sessions actives si la principale tombe en panne. La HA 1+1 de ProSBC fonctionne sur des machines virtuelles standard sans nécessiter de réseau cloud spécialisé, ce qui la rend déployable sur AWS, Azure, VMware ou KVM sans modification. L’instance de secours maintient la synchronisation de configuration avec la principale, de sorte que le basculement ne nécessite aucune intervention manuelle.

La redondance au niveau région protège contre les pannes de zone de disponibilité ou de région cloud en plaçant des instances SBC dans des emplacements géographiquement séparés. Les enregistrements DNS SRV côté opérateur ou la surveillance de santé basée sur SIP OPTIONS dirigent le trafic vers l’instance disponible. Pour les organisations avec des exigences strictes de disponibilité, les déploiements actif-actif entre régions distribuent le trafic en continu, chaque instance gérant une portion de la charge d’appels et absorbant le trafic de l’autre en cas de panne.

Les déploiements SBC cloud bénéficient également de la couche Monitoring as a Service (MaaS), qui fournit des tableaux de bord en temps réel, des alertes basées sur des seuils et une analyse des tendances historiques sur toutes les instances SBC, quel que soit leur emplacement d’hébergement. MaaS détecte les schémas de dégradation (gigue croissante sur un trunk opérateur spécifique, anomalies de comptage d’enregistrements, capacité de sessions approchant les limites) avant qu’ils ne deviennent des pannes, donnant aux équipes d’exploitation le temps de réagir avant que le basculement ne soit nécessaire.

Questions fréquentes

Conclusion

La voix est peut-être la dernière charge de travail majeure à migrer vers le cloud, mais la migration est bien en cours. Ce qui distingue les déploiements vocaux cloud réussis des problématiques est la façon dont la frontière opérateur est gérée. Le SBC fournit la traduction de protocole, le pontage de chiffrement, l’application de la sécurité et la haute disponibilité que les plateformes vocales cloud exigent mais n’implémentent pas nativement.

Que vous déployiez une architecture cloud pure chez un seul fournisseur, que vous vous étendiez sur plusieurs clouds pour la redondance et la conformité, ou que vous mainteniez un environnement hybride pendant une migration progressive, le SBC fonctionne comme le point de contrôle constant à chaque interconnexion opérateur. Son architecture B2BUA garantit que chaque côté de la connexion obtient exactement le comportement SIP, le chiffrement et le routage qu’il requiert, sans exiger que l’un ou l’autre côté s’adapte à l’autre.

Pour les organisations évaluant leur architecture vocale cloud, le SBC n’est pas un composant optionnel à ajouter après l’apparition des problèmes. C’est la couche fondamentale qui fait fonctionner correctement l’interconnexion opérateur, l’interopérabilité multi-fournisseurs et la sécurité vocale dès le départ.