Guide d’implémentation STIR/SHAKEN sur le SBC : comment signer, attester et vérifier les appels

Si vous gérez des services vocaux aux États-Unis, STIR/SHAKEN est une exigence de base pour vos opérations. La FCC exige désormais que la plupart des fournisseurs signent les appels sortants avec leurs propres certificats, maintiennent leur inscription à jour dans la Robocall Mitigation Database (RMD) et procèdent aux recertifications annuelles. Comme les opérateurs en aval signalent ou bloquent de plus en plus les appels non signés, réussir cette implémentation est le meilleur moyen de garantir que les appels de vos clients atteignent effectivement leur destination.

La bonne nouvelle est que votre contrôleur de session en périphérie (SBC) est l’allié idéal pour cette tâche. Parce qu’il se situe en périphérie de votre réseau en tant que Back-to-Back User Agent (B2BUA), il dispose de la visibilité nécessaire pour gérer chaque session SIP. Cette architecture lui permet de collecter facilement les en-têtes SIP spécifiques (numéros appelant et appelé, horodatages et niveaux d’attestation) requis pour construire un jeton PASSporT valide.

Ce guide vous accompagne à travers le processus d’implémentation. Nous commencerons par les prérequis FCC et l’acquisition du certificat, puis nous passerons à la configuration du SBC, l’intégration du service de signature et la logique d’attestation, avant de terminer par la vérification et les tests en production.

Comment fonctionne STIR/SHAKEN au niveau du SBC

STIR (Secure Telephone Identity Revisited) définit le protocole cryptographique pour la signature de l’identité des appels. SHAKEN (Signature-based Handling of Asserted information using toKENs) définit le cadre industriel qui décrit comment les fournisseurs de services implémentent STIR dans les réseaux de production.

Côté origine (signature)

Lorsque votre SBC reçoit un appel sortant, il intercepte le SIP INVITE avant de le transmettre au prochain saut. Le SBC extrait le numéro appelant (depuis l’en-tête P-Asserted-Identity ou l’en-tête From), le numéro appelé (depuis l’en-tête To) et l’horodatage (depuis l’en-tête Date). Il regroupe ces éléments dans une requête de signature et l’envoie à un service de signature externe, également appelé STI Authentication Service (STI-AS). Cette requête est transmise via SIP (TCP, port 5060), le service de signature agissant comme un serveur de redirection SIP. ProSBC prend également en charge la signature HTTPS pour les fournisseurs STI-AS qui l’exigent. Le service de signature crée un jeton PASSporT, le signe avec la clé privée de votre certificat et retourne un en-tête Identity complet. Votre SBC injecte cet en-tête Identity dans le SIP INVITE sortant.

Côté terminaison (vérification)

Lorsque votre SBC reçoit un appel entrant avec un en-tête Identity, il peut transmettre l’appel à un service de vérification (STI-VS) via SIP. Le service de vérification valide la signature, vérifie la chaîne de certificats, confirme que le jeton n’a pas expiré ni été altéré, et retourne un SIP 302 avec un paramètre Verstat dans l’en-tête P-Asserted-Identity. ProSBC récupère la chaîne Verstat de ce 302 et la transmet à la destination suivante. En fonction du résultat de la vérification, vous appliquez votre politique : accepter, signaler ou rejeter.
Le PASSporT (Personal Assertion Token) contient cinq champs principaux : orig (numéro de téléphone d’origine), dest (numéro de destination), iat (horodatage d’émission), origid (identifiant unique de l’appel) et attest (niveau d’attestation).

Les trois niveaux d’attestation

L’attestation communique votre relation avec l’appel et l’appelant. Ce n’est pas un score de confiance ni un indicateur de spam. Pour une référence approfondie sur ce que chaque niveau signifie en pratique, consultez Les niveaux d’attestation STIR/SHAKEN expliqués. Il s’agit d’une déclaration du fournisseur de services d’origine sur le degré de connaissance qu’il a de l’appel.

A (attestation complète)

L’attestation de niveau A s’applique lorsque vous avez authentifié l’appelant, que vous savez qui il est et qu’il est autorisé à utiliser le numéro appelant. C’est le niveau que vous attribuez lorsque l’appelant est votre abonné direct ou un client dont vous avez vérifié l’identité.

B (attestation partielle)

L’attestation de niveau B couvre les appels dont vous connaissez l’origine (provenant d’un trunk ou pair connu et authentifié), mais sans pouvoir vérifier que l’appelant spécifique est autorisé à utiliser le numéro appelant. C’est courant pour les fournisseurs de transit et les opérateurs de gros qui acheminent le trafic de partenaires en amont connus.

C (attestation passerelle)

L’attestation de niveau C est le niveau pour les appels qui sont entrés dans votre réseau depuis une source non fiable ou non vérifiable. Vous êtes le premier saut IP mais ne pouvez rien confirmer sur l’identité de l’appelant. Cela s’applique aux passerelles RTPC vers IP, aux interconnexions internationales ou lors de la réception de trafic de fournisseurs qui n’authentifient pas leurs utilisateurs.

Prérequis avant de commencer

Avant de toucher à la configuration de votre SBC, vous devez remplir plusieurs prérequis administratifs et techniques.

Exigences administratives de la FCC

• Obtenir un Operating Company Number (OCN). Votre OCN est attribué par la National Exchange Carrier Association (NECA). Si vous déclarez déjà en tant que fournisseur de services vocaux, vous en avez probablement un.
• Déposer un formulaire 499-A à jour. Le FCC Telecommunications Reporting Worksheet doit être à jour et déposé.
• S’inscrire dans la Robocall Mitigation Database (RMD). Vous devez certifier soit l’implémentation complète de STIR/SHAKEN, soit votre programme de lutte contre les appels automatisés. La recertification annuelle est obligatoire (la date limite la plus récente était le 1er mars 2026). Pour un aperçu complet des obligations des petits fournisseurs, consultez Conformité STIR/SHAKEN de la FCC pour les petits fournisseurs VoIP. La FCC impose désormais des pénalités de 10 000 $ pour les informations RMD fausses ou inexactes et de 1 000 $ pour le défaut de mise à jour de la base de données dans les 10 jours ouvrables suivant un changement significatif.
• Obtenir votre jeton SPC. Demandez un jeton Service Provider Code (SPC) auprès de l’administrateur de politique STIR/SHAKEN (actuellement iconectiv aux États-Unis). Ce jeton prouve votre identité lors de la demande d’un certificat.
• Acquérir votre certificat STI. Présentez votre jeton SPC à une autorité de certification STIR/SHAKEN (STI-CA) pour obtenir votre certificat numérique. En vertu de la règle du certificat propre, tous les appels doivent être signés avec votre certificat, pas celui d’un tiers. Vous pouvez confier la signature technique à un tiers, mais le certificat doit être le vôtre et les décisions d’attestation doivent être les vôtres.

Prérequis techniques

• Choisir un partenaire de service de signature. ProSBC n’effectue pas la signature cryptographique lui-même. Il s’intègre avec un STI Authentication Service (STI-AS) externe. ProSBC envoie un SIP INVITE, le service de signature retourne un 302 avec l’en-tête Identity dans le P-Asserted-Identity, et ProSBC avance le routage vers la destination suivante avec l’en-tête Identity attaché. ProSBC prend également en charge les fournisseurs STI-AS basés sur HTTPS qui préfèrent un échange HTTP POST/JSON.
• Confirmer la connectivité. Votre SBC doit pouvoir atteindre le service de signature. Pour les fournisseurs STI-AS basés sur SIP, cela signifie SIP sur TCP au port 5060 vers le FQDN du fournisseur (par exemple, sip.clearip.com). Vérifiez la résolution DNS, la connectivité TCP et que tout pare-feu entre le SBC et le service de signature autorise le trafic SIP sortant. Pour les fournisseurs HTTPS, autorisez le HTTPS sortant vers le point de signature configuré.
• Activer le prérequis SIP. Sur ProSBC, activez « Publish raw SIP to Routing Script » sous SIP Stack > Quirks. Ce paramètre est requis pour que le paramètre iat (horodatage d’émission) soit correctement rempli à partir de l’en-tête SIP Date. Sans cela, la requête de signature sera privée d’un champ obligatoire.

Configuration SBC étape par étape pour la signature STIR/SHAKEN

Cette section utilise le moteur de routage Ruby configurable de ProSBC comme implémentation de référence. Le schéma architectural (le SBC interroge un service de signature externe via SIP, puis injecte l’en-tête Identity) s’applique à tout SBC, mais les étapes de configuration spécifiques sont propres à ProSBC.

1. Configurer les paramètres du service de signature

Vous avez besoin des éléments suivants de la part de votre fournisseur de service de signature :

• FQDN du service de signature : La destination SIP vers laquelle ProSBC acheminera les requêtes de signature. Pour ClearIP, il s’agit de sip.clearip.com (ou le FQDN régional fourni par ClearIP). Vous créerez un ou deux NAP pointant vers ce FQDN, selon que vous souhaitez un seul NAP pour tout le trafic ou des NAP distincts pour le trafic entrant et sortant.
• Identifiants d’identification source : ClearIP identifie votre compte par les en-têtes source que ProSBC envoie dans l’INVITE. Ceux-ci sont configurés dans le script de routage ClearIP_Query et fournis par le service de signature lors du provisionnement de votre compte.
• Délai de relance de routage : Le temporisateur SIP qui contrôle combien de temps ProSBC attend une réponse SIP du service de signature avant d’avancer le routage. La valeur par défaut est de 10 secondes.

2. Configurer le script de routage

Pour les déploiements SIP avec ClearIP, ProSBC s’intègre via le script de routage ClearIP_Query (ClearIP_Query.rb), qui s’insère dans la chaîne de filtres du script de routage. Le module est inclus dans votre classe de routage principale et enregistré comme before_filter, ce qui signifie qu’il s’exécute assez tôt pour ajouter les en-têtes d’identification source à l’INVITE que ProSBC enverra au NAP ClearIP. Neustar utilise un filtre dédié équivalent ; les fournisseurs STI-AS basés sur HTTPS utilisent le module StirShakenSapi à la place, enregistré comme after_remap_filter.
Pour ClearIP, l’intégration se configure au niveau du script de routage plutôt que via des paramètres d’URL de signature :

1. Importer ClearIP_Query.rb comme script de filtreTéléchargez-le via le panneau de scripts de routage et cochez « Load on startup ».
2. Inclure le module dans votre script de routage principalDans votre script de routage principal (par défaut simple_routing_sbc.rb), ajoutez require 'ClearIP_Query' unless defined?(ClearIPQuery) en haut.
3. Inclure le module dans votre classe de routageDans votre classe de routage principale, ajoutez include ClearIPQuery.
4. Enregistrer le before_filterDans la même classe de routage, ajoutez before_filter :method => :ClearIP_query. Si vous utilisez déjà le routage par label ou d’autres before_filters, placez ClearIP_query en dernier.

L’attestation dans le modèle SIP n’est pas une configuration d’URL distincte. Le NAP ClearIP porte le rôle d’attestation via la colonne service_type (traitée ci-dessous). Si vous devez différencier authentification et vérification, vous créez des NAP et des routes distincts plutôt que des points d’URL distincts.

3. Configurer les colonnes NAP

Sur ProSBC, le rôle de chaque NAP dans le flux STIR/SHAKEN est défini par une colonne NAP appelée service_type. Créez la colonne une fois avec les valeurs autorisées NORMAL | AUTHENTICATION | VERIFICATION et une valeur par défaut de NORMAL, puis attribuez la valeur appropriée à chaque NAP :

4. Comprendre le flux de signature interne

Lorsqu’un appel atteint une route qui atterrit sur un NAP avec service_type=AUTHENTICATION, voici ce qui se passe concrètement avec ClearIP :

1. Le before_filter inspecte l’INVITELe ClearIP_Query before_filter inspecte l’INVITE et ajoute les en-têtes d’identification source dont ClearIP a besoin pour authentifier la requête.
2. ProSBC envoie le SIP INVITE au NAP ClearIPLa requête est envoyée via TCP/5060 au FQDN ClearIP.
3. ClearIP retourne l’une des quatre réponses SIP302 Moved Temporarily (succès : en-tête Identity dans le PAI), 404 Not Found (aucune fraude détectée et aucune signature effectuée), 503 Service Unavailable (même effet que 404), ou 603 Decline (fraude détectée : arrêter l’appel).
4. ProSBC avance le routage selon le Reason Cause MappingLe comportement d’avancement du routage pour chacune de ces réponses est contrôlé par le Reason Cause Mapping (configuré à l’étape suivante). La liste de routes elle-même constitue la chaîne de basculement dans le modèle SIP.

Pour la vérification (service_type=VERIFICATION), le flux est identique sauf que ClearIP retourne le paramètre Verstat dans le PAI plutôt qu’un en-tête Identity.
Pour les fournisseurs STI-AS basés sur HTTPS, le flux équivalent est un HTTPS POST avec un corps de réponse JSON contenant les champs Identity_header, origination_id et attestation_info ; les mécanismes de basculement et de politique dans ce chemin sont différents et hors du périmètre de ce guide.

5. Configurer l’action de relance de routage pour les codes de cause

Comme le modèle SIP utilise l’avancement de routage comme mécanisme de basculement et de politique, vous devez définir l’action de relance de routage pour chaque code de cause que ClearIP peut retourner. Sous Profiles → Edit Reason Cause Mapping, configurez :

Réponse SIP	Route Retry Action	Valeur par défaut ProSBC
302 Moved Temporarily	Process call routing	Déjà correct
404 Not Found	Continue call	Par défaut « Stop call » ; à modifier
503 Service Unavailable	Continue call	Déjà correct
603 Decline	Stop call	Par défaut « Continue call » ; à modifier

Implémentation de l’attestation

La distinction entre les types de requêtes SIGNING et ATTESTATION est importante pour les fournisseurs qui jouent différents rôles dans le chemin d’appel.
Utilisez SIGNING lorsque vous êtes le fournisseur de services d’origine et que vous devez créer un nouvel en-tête Identity à partir de zéro. Le service de signature génère le PASSporT, le signe avec votre certificat et retourne l’en-tête Identity complet.
Utilisez ATTESTATION lorsqu’un appel arrive avec des informations d’identité existantes (peut-être un origination_id ou attestation_info d’un fournisseur en amont) et que vous devez appliquer ou modifier le niveau d’attestation. Le point d’attestation utilise le nom de méthode identity_attestation et envoie les données d’identité existantes avec votre décision d’attestation.

Prendre les décisions d’attestation

Votre niveau d’attestation doit refléter fidèlement votre relation avec l’appel. La FCC tient le fournisseur signataire responsable de l’exactitude de l’attestation. Voici un cadre pratique :

• Attribuez le niveau A lorsque l’appelant est votre abonné direct, que vous avez vérifié son identité et qu’il est autorisé à utiliser le numéro qu’il présente. Pour un MSP, cela signifie que l’appel provient d’un client dont vous gérez les identifiants SIP et dont vous contrôlez les attributions de DID.
• Attribuez le niveau B lorsque l’appel provient d’un trunk en amont authentifié (vous connaissez le fournisseur), mais que vous ne pouvez pas vérifier indépendamment le droit de l’appelant à utiliser le numéro spécifique. C’est typique des fournisseurs VoIP recevant du trafic de partenaires de gros ou de revendeurs.
• Attribuez le niveau C lorsque l’appel entre dans votre réseau depuis une source non vérifiable : une passerelle RTPC, une interconnexion internationale ou un fournisseur en amont qui n’authentifie pas ses utilisateurs.

Le scénario d’auto-attestation

Certains opérateurs en amont ont réduit le niveau d’attestation qu’ils fournissent aux fournisseurs en aval. Par exemple, des opérateurs qui offraient auparavant l’attestation de niveau A ne fournissent désormais que le niveau C, poussant les petits fournisseurs à obtenir leurs propres certificats et à s’auto-attester. Si votre opérateur en amont ne vous donne que l’attestation de niveau C et que vous pouvez vérifier indépendamment l’identité de l’appelant et l’autorisation du numéro, vous pouvez et devez signer l’appel vous-même au niveau supérieur approprié avec votre propre certificat. Consultez notre guide sur le passage de l’attestation de niveau C à l’auto-attestation de niveau A pour le cadre opérationnel complet.

Vérification côté terminaison

Côté terminaison, votre SBC reçoit des appels entrants qui peuvent ou non inclure un en-tête Identity.
Lorsque le NAP entrant route vers un NAP avec service_type=VERIFICATION, ProSBC transmet l’appel (avec son en-tête Identity) au service de vérification via SIP. Le service de vérification vérifie la signature numérique par rapport au certificat, valide la chaîne de certificats, confirme que le jeton n’a pas expiré et retourne le résultat sous forme de SIP 302 avec le paramètre Verstat dans l’en-tête P-Asserted-Identity (ou 404/503 si aucun signal n’est disponible). ProSBC récupère la chaîne Verstat et la transmet à la destination suivante, où la politique en aval peut agir en conséquence.
En fonction du résultat de la vérification, vous définissez la politique dans votre logique de routage :

• Vérifié, attestation de niveau A : Confiance élevée. Acheminer normalement.
• Vérifié, attestation de niveau B ou C : Confiance moindre mais correctement signé. Acheminer normalement, mais vous pouvez choisir de signaler l’appel ou d’appliquer un filtrage de fraude supplémentaire via des intégrations comme TransNexus ClearIP, SecureLogix ou YouMail.
• Vérification échouée ou absence d’en-tête Identity : L’appel n’est pas signé ou la signature est invalide. Selon votre tolérance au risque, vous pouvez acheminer normalement (de nombreux appels légitimes de petits fournisseurs ne sont toujours pas signés), signaler l’appel pour surveillance, appliquer un filtrage supplémentaire ou rejeter l’appel.

ProSBC prend en charge l’intégration Neustar comme chemin de vérification dédié. Lors de l’utilisation de Neustar, vous configurez la colonne NAP service_type à VERIFICATION sur le NAP entrant concerné, et le filtre nuestar_query gère la requête de vérification automatiquement.

Architecture de redondance et de basculement

La disponibilité du service de signature impacte directement le taux de connexion des appels si votre implémentation ne prend pas en compte les défaillances. Le module STIR/SHAKEN de ProSBC inclut une conception de basculement à trois niveaux exprimée via la liste de routes elle-même :

Niveau 1 : NAP ClearIP principal

Toutes les requêtes de signature pour cette classe de trafic arrivent ici en premier. Le NAP remappé de première priorité de la route est le NAP principal.

Niveau 2 : NAP ClearIP secondaire (ou STI-AS alternatif)

Une deuxième route à priorité inférieure pointe vers un NAP secondaire : soit le FQDN redondant de ClearIP, une région différente, soit un fournisseur STI-AS entièrement différent. Si le principal retourne un SIP 503 ou expire, ProSBC avance le routage vers le secondaire selon le Reason Cause Mapping configuré ci-dessus.

Niveau 3 : Route de contournement

Une route finale à la priorité la plus basse envoie l’appel à sa destination sans passer par aucun STI-AS. Si les niveaux 1 et 2 échouent tous les deux, l’appel aboutit quand même. Pour les déploiements HTTPS, l’équivalent est l’en-tête P-Identity-Bypass que le module StirShakenSapi ajoute après avoir épuisé les deux URL ; dans le modèle SIP, le même résultat est obtenu par l’ordonnancement des routes.

Considérations de surveillance

Surveillez ces métriques pour vous assurer que votre implémentation STIR/SHAKEN reste opérationnelle :

• Taux de réussite de la signature : le pourcentage d’appels signés avec succès par rapport à ceux ayant basculé vers le contournement. Une augmentation soudaine des événements de contournement indique un problème du service de signature.
• Latence de signature : le temps entre la requête HTTP ou SIP et la réponse. Une latence croissante peut indiquer une dégradation du service de signature avant qu’elle ne devienne une panne.
• Distribution des attestations : la répartition des niveaux d’attestation A, B et C dans votre trafic. Des changements inattendus (par exemple, une augmentation soudaine des appels de niveau C) peuvent indiquer un changement dans les schémas de trafic en amont.
• Taux d’échec de vérification côté terminaison : le pourcentage d’appels pour lesquels la vérification échoue. Des taux élevés peuvent indiquer des problèmes de certificat, un décalage d’horloge ou du trafic usurpé.

La sortie CDR de ProSBC, les traps SNMP et la capacité de trace de journaux (réglez le niveau de trace à 2 pour les événements STIR/SHAKEN) fournissent les données nécessaires à cette surveillance. Pour les fournisseurs qui souhaitent une surveillance sans intervention, TelcoBridges propose le Monitoring as a Service (MaaS) comme produit autonome.

Erreurs d’implémentation courantes

Voici les erreurs qui retardent ou cassent le plus fréquemment les déploiements STIR/SHAKEN :

Tester votre implémentation

Utilisez d’abord un environnement de laboratoire

ProSBC Lab est une licence gratuite et permanente à 3 sessions conçue exactement pour ce type de tests. Vous pouvez déployer une instance de laboratoire en environ 20 minutes, configurer la signature STIR/SHAKEN contre l’environnement de test de votre service de signature et valider le flux complet avant de toucher à la production.

Étapes de vérification

• Vérifier l’injection de l’en-tête Identity. Utilisez la capture Wireshark en direct de ProSBC ou la trace d’appel pour inspecter les SIP INVITE sortants. L’en-tête Identity doit être présent sur chaque appel signé, contenant le PASSporT complet avec la référence à votre certificat.
• Valider les niveaux d’attestation. Vérifiez que les niveaux d’attestation A, B et C sont correctement attribués en fonction de la configuration de vos routes et de l’origine de l’appel. Votre fournisseur de service de signature peut offrir un tableau de bord de test affichant la répartition des attestations.
• Tester le basculement. Bloquez la connectivité SIP vers le NAP ClearIP principal (bloquez l’IP de destination via le pare-feu, ou désactivez le NAP dans ProSBC) et confirmez que ProSBC avance le routage vers le NAP secondaire et que l’appel aboutit toujours avec un en-tête Identity. Puis bloquez les deux NAP et confirmez que l’appel avance vers votre route de contournement. Pour les déploiements HTTPS, l’état final équivalent est l’en-tête P-Identity-Bypass sur l’INVITE sortant.
• Test de bout en bout. Émettez un appel signé depuis votre SBC et vérifiez côté terminaison que l’en-tête Identity est présent et que la signature est valide. Si vous disposez d’un second SBC ou d’un compte de test chez un fournisseur de terminaison, vous pouvez vérifier la chaîne complète.
• Examiner les journaux. Le module STIR/SHAKEN de ProSBC journalise au niveau de trace 2. Entrées de journal clés à rechercher : « Send to first signing domain », « HTTP server returned 200 », « Added Identity header » et le corps complet de la réponse JSON. Si vous voyez « This is the third iteration, send call anyway adding Bypass SIP header », votre service de signature est en échec.

Choisir une architecture de service de signature ouverte ou verrouillée

Tous les SBC n’implémentent pas STIR/SHAKEN de la même manière. Le choix architectural de votre fournisseur de SBC détermine votre flexibilité en tant que fournisseur. Pour un aperçu plus large de la comparaison entre les modèles de signature ouverts et propriétaires, consultez STIR/SHAKEN et authentification des appels.

Implémentations propriétaires

Les implémentations propriétaires (courantes chez Ribbon, Oracle) couplent étroitement le SBC à un service de signature spécifique ou nécessitent le propre serveur de politique du fournisseur comme intermédiaire. Cela simplifie le déploiement initial mais vous enferme dans l’écosystème du fournisseur pour les services de signature, la tarification et la disponibilité des fonctionnalités.

Modèle API ouvert (ProSBC)

Le modèle API ouvert traite le service de signature comme un composant externe interchangeable connecté via SIP ou HTTPS, selon la préférence du fournisseur STI-AS. Le moteur de routage configurable de ProSBC s’intègre avec TransNexus ClearIP et Neustar via SIP aujourd’hui, et prend en charge le HTTP POST/JSON pour les fournisseurs STI-AS qui l’exigent. Cela signifie que vous pouvez choisir TransNexus, Neustar ou tout autre fournisseur STI-AS. Vous pouvez changer de fournisseur sans modifier la configuration de votre SBC au-delà de la mise à jour des URL et des identifiants. Vous pouvez même utiliser différents services de signature pour différents types de trafic (par exemple, un fournisseur pour le trafic domestique et un autre pour le trafic de passerelle internationale).
Ce modèle de partenariat ouvert prépare également votre déploiement pour l’avenir. À mesure que l’écosystème STIR/SHAKEN évolue et que de nouvelles fonctionnalités de service de signature apparaissent (analytique avancée de l’identifiant d’appel, intégration du scoring de fraude, données de réputation en temps réel), vous pouvez les adopter en choisissant un fournisseur qui les propose, plutôt que d’attendre que votre fournisseur de SBC construise une intégration propriétaire.

Foire aux questions

Conclusion

L’implémentation de STIR/SHAKEN au niveau du SBC est un exercice de configuration simple une fois les prérequis administratifs en place et le choix d’un partenaire de service de signature effectué. Les étapes clés sont : obtenir votre certificat, configurer les NAP de signature principal et secondaire, définir votre logique d’attestation, activer le module de routage et tester.
Les choix d’implémentation qui comptent le plus sont ceux que la règle du certificat propre de la FCC renforce : votre certificat, votre décision d’attestation, votre responsabilité. La signature technique peut être déléguée à un tiers, mais le signal de confiance qu’un opérateur en aval ou un SBC de terminaison voit sur l’en-tête Identity remonte toujours au fournisseur d’origine.