Intégration d’un SBC avec Bandwidth.com : comment connecter un contrôleur de session en bordure aux jonctions SIP Bandwidth

Bandwidth.com compte parmi les plus grands fournisseurs de jonctions SIP (SIP trunking) et de CPaaS en Amérique du Nord. Si vous êtes MSP, centre de contact, ISP ou entreprise et que vous recevez du trafic voix Bandwidth sur votre réseau, l’intégration paraît simple sur le papier : il suffirait d’orienter votre jonction vers les adresses IP de l’opérateur et d’envoyer vos appels. Dans la réalité, Bandwidth impose des exigences précises en matière de transport, de taille de paquets et de redondance. Si la configuration côté client ne les respecte pas à la lettre, les appels échouent dès leur établissement au niveau SIP, sans message d’erreur explicite.

C’est le contrôleur de session en bordure (SBC) qui rend cette intégration possible. Placé à la frontière entre le réseau de Bandwidth et votre PBX, votre centre de contact ou votre plateforme UC en aval, il normalise la signalisation SIP, ancre les flux média et applique la politique de sécurité à chaque appel. Cet article détaille ce que Bandwidth.com attend de votre SBC, la raison d’être de chaque exigence, la façon de configurer chacune d’elles et les points à anticiper en matière d’attestation STIR/SHAKEN et de fraude en bordure de réseau. En s’appuyant sur plus de 20 ans d’expérience des déploiements SIP, les SBC logiciels modernes assurent ce rôle sur une infrastructure virtuelle ou cloud standard.

Pourquoi passer par un SBC pour les jonctions SIP de Bandwidth.com

Côté client, Bandwidth.com termine le trafic sur une paire de SBC opérateur. Les deux adresses IP sont actives pour la signalisation comme pour les médias : les appels entrants peuvent arriver de l’une comme de l’autre, et les appels sortants partir vers l’une ou l’autre. Ce schéma à double SBC est conçu pour la redondance, mais il reporte la complexité côté client. Chaque système en aval doit connaître les deux adresses IP de Bandwidth, les inscrire sur sa liste d’autorisation et basculer proprement quand l’une d’elles cesse de répondre.

Un SBC côté client absorbe cette complexité. Il présente à Bandwidth, en amont, un point d’interconnexion unique et maîtrisé, normalise le SIP de chaque appel conformément à la RFC 3261, ancre les médias pour appliquer en un seul point les politiques de qualité et d’enregistrement, masque la topologie interne à l’opérateur et bloque la fraude et le trafic de déni de service (DoS) avant qu’ils n’atteignent le cœur de votre téléphonie.

Sans SBC, le dialecte SIP de Bandwidth arrive directement sur votre PBX, votre centre de contact ou votre plateforme UC, et ces systèmes restent exposés au trafic de l’internet public. Une seule sonde REGISTER malformée ou une seule campagne de fraude à la taxation remonte alors jusqu’à votre commutateur.

Exigences de transport et de réseau de Bandwidth.com

Bandwidth.com publie des règles réseau et protocolaires précises pour tout SBC qui s’intègre à ses jonctions SIP. Ces règles ne se négocient pas : le trafic non conforme échoue.

Transport en UDP uniquement

Bandwidth exige que la signalisation SIP et l’audio transitent en UDP. L’offre standard de jonctions SIP ne prend pas en charge le TCP, et les guides d’intégration de Bandwidth ne proposent pas le TLS côté jonction. Votre SBC doit donc terminer le trafic UDP/5060 sur son groupe de jonctions côté Bandwidth, quel que soit le transport utilisé en aval.

Taille maximale des messages SIP : 1 350 octets

Les messages SIP peuvent dépasser cette limite, en particulier les INVITE qui transportent de longues chaînes d’en-têtes, des corps SDP volumineux ou des métadonnées injectées par l’opérateur. Ils sont alors fragmentés, voire perdus. Le SBC doit donc maîtriser la taille des messages sortants : supprimer les P-headers superflus, garder un SDP compact et retirer les extensions propriétaires avant que le message ne parte sur le réseau.

Conformité à la RFC 3261

La pile de Bandwidth rejette tout comportement SIP non standard. Des en-têtes propriétaires personnalisés, des entrées Via ou Record-Route malformées ou un traitement des méthodes non conforme aux RFC font échouer les INVITE. Le moteur de manipulation des en-têtes du SBC doit imposer un profil de message propre et conforme aux normes sur le segment côté Bandwidth.

Redondance à double SBC

Bandwidth fournit deux adresses IP de SBC pour assurer la redondance de la signalisation. Côté client, les deux doivent être configurées pour le trafic entrant comme sortant. Le groupe de jonctions du SBC doit traiter cette paire comme une route principale/secondaire ou comme une paire en répartition de charge, jamais comme un point de terminaison unique doté d’une seule adresse IP.

Configuration du SBC, étape par étape

Les menus varient d’un fournisseur de SBC à l’autre, mais la logique d’intégration reste la même sur tout SBC conforme à la RFC 3261.

1. Déclarez les deux adresses IP des SBC de Bandwidth comme paire de destinations amontLa plupart des SBC appellent cela un Network Access Point (NAP), un groupe de jonctions ou une entrée de pair. Créez un NAP par SBC Bandwidth.
2. Choisissez le transport UDP sur le port 5060Appliquez ce réglage aux deux entrées de pair. N’activez ni TLS ni TCP sur le segment côté Bandwidth.
3. Limitez les messages SIP sortants à moins de 1 350 octetsServez-vous des règles de manipulation des en-têtes SIP du SBC pour supprimer les P-headers, les extensions personnalisées et tout champ injecté par votre pile en aval que Bandwidth refuserait.
4. Passez le plan de numérotation en E.164Faites précéder chaque numéro appelé et appelant d’un +, de bout en bout. L’identifiant de l’appelant en entrée comme le numéro appelé en sortie doivent respecter le format E.164 défini par la recommandation UIT-T E.164.
5. Définissez l’ordre des routes pour le basculementConfigurez un mode principal/secondaire ou actif/actif, afin que le SBC bascule automatiquement le trafic vers la seconde adresse IP lorsque la première ne répond plus.
6. Activez les sondes SIP OPTIONSLe SBC vérifie en continu que les deux SBC de Bandwidth sont joignables et passe à la route suivante dès que l’un d’eux reste muet.

Codecs et médias

Bandwidth prend en charge les codecs PSTN standard : le G.711 µ-law et A-law est disponible partout, le G.729 dans certaines régions seulement. Vérifiez la liste exacte des codecs dans la dernière version du guide d’intégration Bandwidth propre à votre service.

Le SBC négocie le codec sur chaque segment via le protocole SDP (Session Description Protocol). Si les offres de codecs de Bandwidth et de votre système en aval ne concordent pas, le SBC transcode le flux ou, faute de transcodage configuré, l’appel est rejeté au moment de la négociation SDP.

Ancrer les médias sur le SBC est le bon choix par défaut. En terminant le RTP sur le SBC, vous regroupez en un seul point la mesure de la qualité, la frontière de chiffrement et la politique d’enregistrement. Le SBC peut aussi faire le lien entre deux modes de sécurité du transport : par exemple de l’UDP non chiffré vers Bandwidth sur le segment opérateur et du SRTP vers Microsoft Teams ou une plateforme UCaaS sur le segment client, l’échange de clés étant géré indépendamment de chaque côté par le SBC.

Si votre pile en aval utilise d’autres codecs que le G.711 (Opus pour WebRTC, AMR pour les clients mobiles), dimensionnez votre capacité de transcodage en conséquence. Le transcodage logiciel d’Opus et d’AMR n’est pas disponible sur toutes les plateformes SBC et peut nécessiter une prise en charge du transcodage matériel.

Sécurité : le rôle du SBC à la frontière avec Bandwidth

Toute jonction SIP joignable depuis l’internet public devient une cible. Le SBC forme une défense en couches entre le réseau de Bandwidth et le cœur de votre téléphonie.

Liste d’autorisation d’adresses IP

N’acceptez le SIP entrant qu’en provenance des deux adresses IP des SBC de Bandwidth, et faites rejeter tout le reste par le SBC. La plupart des SBC mettent cela en œuvre au moyen de listes de contrôle d’accès (ACL) dynamiques rattachées à la définition du groupe de jonctions.

Protection contre les attaques DoS et DDoS

Une infrastructure SIP exposée au public attire les scans SIP, les inondations de requêtes d’enregistrement et les attaques volumétriques sur la signalisation. Le SBC doit appliquer une limitation de débit au niveau SIP, par adresse IP source et par groupe de jonctions, et détecter puis bloquer automatiquement les schémas de scan d’enregistrement. Les pare-feu réseau génériques ne voient pas ce qui se passe dans la couche SIP : cette protection relève du SBC.

Masquage de topologie

Retirez les adresses IP privées des en-têtes Contact, Via et Record-Route de chaque message sortant vers Bandwidth. L’opérateur ne doit jamais voir votre adressage interne, et l’infrastructure amont de Bandwidth doit rester invisible pour vos systèmes internes.

Détection de la fraude à la taxation

C’est sur ce point que le SBC se rentabilise. Les appels internationaux vers des numéros surtaxés constituent le principal risque de facturation sur toute jonction SIP : un point de terminaison SIP compromis ou un REGISTER SIP obtenu par bourrage d’identifiants (credential stuffing) peut générer des dizaines de milliers de dollars de trafic frauduleux en quelques heures. Une évaluation du risque appel par appel, qui tient compte du préfixe de destination, du rythme des appels, de l’heure et du profil d’appel, repère les anomalies avant qu’elles n’atteignent la jonction. Des partenaires de détection de fraude validés, comme TransNexus et YouMail, s’intègrent au SBC via des API standard.

Attestation STIR/SHAKEN et Bandwidth.com

Bandwidth.com assure la signature STIR/SHAKEN pour ses clients nord-américains. En tant que fournisseur de services d’origine, l’opérateur signe les appels sortants avec des jetons d’identité PASSporT et leur attribue un niveau d’attestation (A, B ou C) selon sa connaissance directe de l’appelant, conformément au cadre d’authentification des appels de la FCC.

Les clients qui remettent des appels à Bandwidth sans avoir eux-mêmes de relation directe avec le numéro de l’appelant obtiennent une attestation plus faible qu’ils ne l’imaginent. La politique d’attestation s’est durcie au cours de l’année écoulée, et un passage de A à C pèse directement sur le chiffre d’affaires : taux de réponse en baisse, davantage d’étiquettes « Spam Likely » et score de confiance réduit chez les opérateurs de terminaison.

Dans le cadre STIR/SHAKEN, c’est Bandwidth qui signe, en sa qualité de fournisseur de services d’origine. Le SBC côté client intervient en amont : il renseigne avec exactitude les en-têtes d’identité de l’appelant (P-Asserted-Identity, From) pour que Bandwidth dispose des bonnes informations au moment d’attribuer l’attestation, et il conserve l’en-tête Identity des appels qui en portent déjà un. Supprimer ou réécrire les informations d’identité sur le SBC dégrade silencieusement le niveau d’attestation obtenu.

Supervision, CDR et dépannage

Bandwidth met à disposition les enregistrements de détail d’appel (CDR) dans son portail. Rapprochez-les des CDR produits par votre SBC côté client pour valider la facturation. Tout écart entre les deux sources est le signal le plus rapide qu’un élément est routé ou comptabilisé autrement que prévu.

Le SBC doit proposer une trace SIP en direct et une capture de paquets de type Wireshark pour déboguer la signalisation au niveau de la jonction. La grande majorité des tickets « les appels échouent par intermittence » se résument à un message SIP précis que l’une des deux parties rejette, et la seule façon de le trouver consiste à examiner ce qui circule réellement sur le réseau.

Le score MOS calculé par le SBC révèle les problèmes d’audio unidirectionnel, de gigue et d’incompatibilité de codecs avant qu’ils ne se traduisent par des plaintes d’utilisateurs. Des tableaux de bord dynamiques et des alertes à seuils, proposés par des produits comme Monitoring as a Service, font partie des exigences de base de tout déploiement en production.

Questions fréquentes

Conclusion

Bandwidth.com est un fournisseur de jonctions SIP et de CPaaS de qualité, qui opère à grande échelle, et l’intégration est à la portée de tout SBC moderne. Elle obéit toutefois à des règles précises : le transport UDP, le plafond de 1 350 octets par message SIP, la conformité à la RFC 3261 et la redondance sur deux adresses IP de SBC doivent tous être correctement configurés côté client. Ajoutez le masquage de topologie, la liste d’autorisation IP, la protection contre le DoS, l’évaluation du risque de fraude en bordure et une bonne compréhension du cheminement de l’attestation STIR/SHAKEN chez Bandwidth, fournisseur de services d’origine, et vous obtenez une intégration prête pour la production.

Pour choisir un SBC destiné à un déploiement Bandwidth.com, les critères déterminants sont une architecture B2BUA complète, une manipulation des en-têtes SIP configurable par groupe de jonctions, une sécurité étendue au niveau SIP et la qualité des outils de débogage et de supervision qui permettent de diagnostiquer et d’ajuster l’intégration sous charge, en production.