STIR/SHAKEN et authentification des appels

STIR/SHAKEN n’est plus optionnel pour la plupart des fournisseurs de services vocaux aux États-Unis. Le mandat d’implémentation de la FCC, renforcé par la règle du certificat propre de septembre 2025, signifie que chaque fournisseur d’origine a besoin d’une infrastructure qui signe les appels avec son propre certificat, attribue le niveau d’attestation correct par appel, et bascule de manière fiable lorsque le service de signature est indisponible.
Le contrôleur de session en bordure (SBC) est l’endroit où tout cela se produit. Il se situe à la frontière d’origine du réseau, le dernier point de contrôle avant qu’un appel ne quitte votre domaine. Mais les SBC diffèrent considérablement dans leur gestion de STIR/SHAKEN. Certains offrent une intégration statique et propriétaire liée à un seul partenaire de signature. D’autres exposent un moteur de routage configurable qui donne au fournisseur le contrôle total de la logique d’attestation, du choix du partenaire et du comportement de basculement.
Cette page explique ce qui se passe au niveau du SBC lors de la signature et de la vérification STIR/SHAKEN, pourquoi le routage configurable est important pour la conformité, et comment l’architecture ouverte de ProSBC gère cette problématique.

Comment STIR/SHAKEN fonctionne au niveau du SBC

Le cadre STIR/SHAKEN attribue deux rôles distincts aux fournisseurs de services : le fournisseur d’origine signe l’appel, et le fournisseur de terminaison vérifie la signature. Le SBC est le point d’application pour les deux.

Signature (côté origine)

Lorsqu’un appel entre dans le SBC depuis un trunk client, le SBC collecte les informations nécessaires au jeton PASSporT : le numéro d’origine (depuis l’en-tête P-Asserted-Identity ou From), le numéro de destination (depuis l’en-tête To) et l’horodatage (depuis l’en-tête Date). Il détermine le niveau d’attestation approprié pour l’appel, puis envoie une requête de signature à un service d’authentification STIR/SHAKEN externe (STI-AS). Le STI-AS utilise le certificat du fournisseur pour générer une signature cryptographique, l’encapsule dans un jeton PASSporT et renvoie un en-tête Identity signé. Le SBC injecte cet en-tête Identity dans le SIP INVITE sortant avant de transmettre l’appel.

Vérification (côté terminaison)

Lorsque le SBC reçoit un appel entrant portant un en-tête Identity, il transmet cet en-tête à un service de vérification STIR/SHAKEN (STI-VS). Le service de vérification valide la signature cryptographique en la comparant au certificat du fournisseur d’origine, vérifie que le jeton n’a pas expiré et confirme que les numéros appelant et appelé correspondent aux déclarations du PASSporT. Le résultat est renvoyé au SBC, qui route l’appel en conséquence.

Niveaux d’attestation

Chaque appel signé porte l’un des trois niveaux d’attestation, déterminé par le fournisseur d’origine :

• A (attestation complète) : le fournisseur authentifie l’appelant et confirme qu’il est autorisé à utiliser le numéro appelant.
• B (attestation partielle) : le fournisseur peut authentifier l’origine de l’appel mais ne peut pas vérifier l’autorisation de l’appelant à utiliser le numéro spécifique.
• C (attestation passerelle) : l’appel est entré dans le réseau depuis une source externe que le fournisseur ne peut pas authentifier.

Le niveau d’attestation n’est pas décoratif. Il affecte directement la façon dont les fournisseurs en aval et les plateformes d’analyse traitent l’appel. Les appels de niveau A passent, tandis que les appels de niveau C sont signalés ou bloqués. Se tromper a des conséquences réelles sur les taux d’aboutissement des appels.
Pour une analyse détaillée de chaque niveau d’attestation et de leur utilisation, consultez notre guide sur les niveaux d’attestation STIR/SHAKEN expliqués (à venir).

Pourquoi le contrôle de l’attestation appartient à la couche de routage

L’attestation est une décision par appel. Elle dépend de ce que vous savez sur la source de l’appel, et cette connaissance réside dans votre logique de routage.
Prenons l’exemple d’un FAI exploitant un seul SBC qui gère trois types de trafic : des clients de jonction SIP (SIP trunking) en détail (vous avez attribué les numéros, vous authentifiez l’abonné), du transit de gros depuis un opérateur régional (vous savez d’où il vient mais ne pouvez pas vérifier l’appelant), et du trafic passerelle depuis un partenaire international (source non fiable). Le niveau d’attestation correct est A pour le premier, B pour le deuxième et C pour le troisième. Les trois passent par le même SBC.
Un SBC qui ne prend en charge qu’un niveau d’attestation global par trunk vous oblige à en choisir un seul. Attribuer A à tout revient à faire de fausses déclarations d’attestation, ce qui enfreint les règles de la FCC. Attribuer C à tout signifie que les appels de vos clients en détail sont signalés comme non vérifiés, ce qui nuit à leurs taux d’aboutissement.
C’est là que le routage configurable devient une exigence de conformité, et non un simple confort. Le moteur de routage évalue chaque appel selon votre logique métier et attribue le niveau d’attestation de manière dynamique. Client en détail sur un trunk que vous provisionnez ? Niveau A. Transit de gros où vous connaissez l’opérateur d’origine ? Niveau B. Trafic passerelle depuis un pair international non fiable ? Niveau C.
La règle du certificat propre de la FCC, en vigueur depuis le 18 septembre 2025, renforce ce principe. Votre organisation doit prendre les décisions de niveau d’attestation. Un service de signature peut effectuer l’acte technique de la signature, mais il ne peut pas attribuer l’attestation de manière indépendante. (Pour une analyse détaillée de la règle du certificat propre et de ses exigences, consultez notre page sur la règle du certificat propre FCC STIR/SHAKEN.)
Si votre SBC traite l’attestation comme une configuration statique plutôt que comme une décision de routage, vous aurez du mal à rester conforme à mesure que votre mix de trafic évolue.
Pour les fournisseurs qui doivent passer d’une attestation de niveau C à une attestation de niveau A avec leur propre certificat, consultez notre guide sur l’auto-attestation STIR/SHAKEN de niveau A (à venir).

Modèle de partenaire ouvert vs. STIR/SHAKEN propriétaire

Tous les fabricants de SBC ne gèrent pas l’intégration STIR/SHAKEN de la même manière. Certains, dont Ribbon et AudioCodes, proposent des implémentations STIR/SHAKEN propriétaires qui limitent le service de signature utilisable. L’intégration est intégrée au micrologiciel du SBC, ce qui simplifie la configuration initiale mais restreint vos options si vous souhaitez changer de partenaire de signature, ajouter une notation de fraude ou intégrer des services de conformité supplémentaires.
ProSBC adopte une approche différente. Son moteur de routage configurable s’intègre à tout service de signature HTTP ou SIP via des modules Ruby API. TransNexus ClearIP, Neustar, ou tout autre STI-AS qui accepte les requêtes de signature HTTP standard ou SIP INVITE : l’intégration se fait au niveau de la couche de routage, et non dans le micrologiciel.
En pratique, le module StirShakenapi envoie une requête de signature HTTP ou SIP INVITE à vos fournisseurs de services de signature configurés, contenant votre jeton d’autorisation et les détails de l’appel (numéro d’origine, destination, horodatage, niveau d’attestation). Le service de signature renvoie un en-tête Identity signé, et le SBC l’injecte dans l’INVITE sortant.
Trois avantages architecturaux découlent de cette approche :

Redondance

ProSBC prend en charge un fournisseur de service de signature primaire et secondaire. Si le primaire est injoignable, la requête bascule automatiquement vers le secondaire. Si les deux sont indisponibles, un en-tête P-Identity-Bypass est ajouté à l’appel, signalant aux fournisseurs en aval que la signature était indisponible pour cet appel spécifique. L’appel aboutit tout de même.

Flexibilité de partenaire

Changer de service de signature consiste à mettre à jour un fournisseur (NAP SIP dans la configuration ProSBC) et un jeton d’autorisation dans la configuration de routage. Pas de mise à jour de micrologiciel, pas d’intervention du fabricant, pas de fenêtre de maintenance. Si TransNexus augmente ses tarifs ou que Neustar ajoute une fonctionnalité dont vous avez besoin, la migration est un changement de configuration.

Composabilité

La requête de signature étant un appel HTTP ou SIP au sein du script de routage, vous pouvez la combiner avec d’autres intégrations API dans le même flux d’appel. TransNexus ClearIP, par exemple, prend en charge le routage au moindre coût (LCR), la notation de fraude et la signature STIR/SHAKEN en une seule requête. Le moteur de routage de ProSBC peut évaluer le score de fraude, prendre une décision de routage et signer l’appel en une seule passe.

Implémentation STIR/SHAKEN de ProSBC

ProSBC prend en charge trois types de requêtes STIR/SHAKEN via ses modules Ruby API :

Signature

Le SBC envoie une requête de SIGNATURE au STI-AS configuré. Il remplit les déclarations du PASSporT à partir du message SIP : orig depuis l’en-tête P-Asserted-Identity ou From, dest depuis l’en-tête To, et iat depuis l’en-tête Date. Le service de signature renvoie un en-tête Identity signé contenant la signature numérique et le niveau d’attestation, que le SBC injecte dans l’INVITE sortant.

Attestation

Pour les déploiements qui séparent la décision d’attestation de l’opération de signature, le SBC peut envoyer une requête d’ATTESTATION. Cela permet à la logique d’attestation du fournisseur de s’exécuter indépendamment du service de signature.

Vérification

Côté terminaison, le SBC envoie une requête de VÉRIFICATION, transmettant l’en-tête Identity entrant au STI-VS. Le résultat de la vérification alimente les décisions de routage en aval.
Voici les informations supplémentaires configurées par défaut dans ProSBC :
Délai d’attente configurable. Chaque requête HTTP ou SIP vers le service de signature dispose d’un délai d’attente configurable. La configuration par défaut est de 10 secondes. Cela empêche la latence de signature de bloquer l’établissement de l’appel lorsque le service de signature est lent ou ne répond pas.
Fournisseurs primaire et secondaire (Network Access Points dans ProSBC). Les services de signature et de vérification prennent en charge deux fournisseurs pour le basculement automatique.
Basculement P-Identity-Bypass. Si le service de signature est injoignable après les tentatives de reprise sur les deux fournisseurs, le SBC ajoute un en-tête P-Identity-Bypass plutôt que de bloquer l’appel. L’appel aboutit, et l’en-tête fournit la transparence sur l’absence de l’en-tête Identity.
Routage basé sur le domaine. Pour les réseaux gérant à la fois le trafic d’origine mobile (MO) et de terminaison mobile (MT), l’implémentation prend en charge le routage basé sur le domaine pour appliquer un comportement STIR/SHAKEN différent par direction d’appel.
Intégrations partenaires validées. ProSBC dispose d’intégrations documentées avec TransNexus ClearIP (LCR combiné, notation de fraude et STIR/SHAKEN) et Neustar (authentification, vérification et traitement de redirection 302). Ce sont des intégrations validées et testées en production, et non de simples déclarations d’API génériques.

Pour commencer

Si vous évaluez la gestion de STIR/SHAKEN par votre SBC, ou si vous déployez STIR/SHAKEN pour la première fois, commencez par le guide d’implémentation STIR/SHAKEN pour SBC pour la procédure de configuration détaillée étape par étape. ProSBC offre plusieurs options pour démarrer.

ProSBC Lab

ProSBC Lab est une licence gratuite et permanente de 3 sessions pour les environnements de laboratoire et de test. Elle est en libre-service et se met en place en une vingtaine de minutes. Vous pouvez configurer la signature et la vérification STIR/SHAKEN dans un environnement de laboratoire avant de passer en production.

Essai gratuit de 30 jours

L’essai gratuit de 30 jours de ProSBC vous offre 500 sessions simultanées pour une évaluation en production. Si votre implémentation STIR/SHAKEN nécessite des tests à l’échelle avant la mise en service, l’essai couvre ce besoin.

Service managé

Le service managé ProSBC est disponible pour les fournisseurs qui souhaitent que TelcoBridges gère la configuration, la surveillance et la gestion continue de la conformité STIR/SHAKEN. Le service managé peut être déployé sur votre propre infrastructure (AWS, Azure, VMware, KVM, sur site) ou hébergé par TelcoBridges. Votre organisation conserve un accès complet.
Pour les fournisseurs qui exploitent déjà un SBC avec une intégration STIR/SHAKEN propriétaire et qui recherchent plus de flexibilité, ou pour ceux qui déploient STIR/SHAKEN pour la première fois sous la pression réglementaire, c’est la combinaison du contrôle configurable de l’attestation, du choix ouvert de partenaires et de la redondance intégrée qui fait fonctionner cette approche.