Requête CNAM : qu’est-ce que c’est et comment ça fonctionne

Chaque fois qu’un téléphone affiche le nom de l’appelant plutôt qu’un simple numéro, c’est une requête CNAM qui l’a rendu possible. Pour les utilisateurs finaux, cela semble automatique. Pour les fournisseurs de services, les opérateurs et les exploitants VoIP, le CNAM est une infrastructure réelle qui fonctionne sur des équipements réels, et le Session Border Controller (SBC) est généralement l’endroit où la requête s’exécute.
Ce guide explique le fonctionnement du CNAM du point de vue du fournisseur de services, la place du SBC dans le processus, la relation entre le CNAM et STIR/SHAKEN, et les éléments à considérer lors du déploiement du CNAM dans un réseau vocal en production.

Qu’est-ce que le CNAM ?

CNAM signifie Calling Name Delivery. C’est un service de téléphonie qui associe un nom, limité à 15 caractères, à un numéro de téléphone. Lorsqu’un appel arrive, l’opérateur de terminaison recherche le numéro appelant dans une base de données CNAM et transmet le nom associé au téléphone du destinataire, où il apparaît aux côtés du numéro sur l’afficheur d’identification de l’appelant.
Le nom peut identifier une personne (« Jean Dupont ») ou une organisation (« Acme Corp »). Le CNAM est principalement un service nord-américain, utilisé aux États-Unis et dans certaines régions du Canada. D’autres régions utilisent des mécanismes d’identification de l’appelant différents, comme le CNAP (Calling Name Presentation) dans certains réseaux européens.
Contrairement aux numéros de téléphone, qui sont gérés par un plan de numérotation nord-américain centralisé, les données CNAM ne sont pas stockées dans une base de données unique et faisant autorité. Plusieurs Line Information Databases (LIDB) et fournisseurs CNAM tiers maintiennent leurs propres enregistrements. Le nom affiché pour un même numéro peut donc varier selon la base de données interrogée par l’opérateur de terminaison. Cela signifie également que le maintien de l’exactitude des enregistrements CNAM nécessite une maintenance active de la part du propriétaire du numéro ou de son fournisseur de services.

Comment fonctionne une requête CNAM

Le processus de requête CNAM, communément appelé « interrogation CNAM » (CNAM dip), suit un schéma cohérent quel que soit le protocole sous-jacent.
Lorsqu’un appelant compose un numéro, son opérateur achemine l’appel vers l’opérateur de terminaison. La signalisation inclut le numéro de l’appelant (CLID, ou Calling Line Identification) mais n’inclut pas le nom de l’appelant. Le nom n’est pas transporté dans l’établissement de l’appel ; il doit être récupéré séparément.
Avant de présenter l’appel au destinataire, l’équipement de l’opérateur de terminaison effectue une interrogation CNAM. Il prend le numéro appelant et interroge une base de données CNAM pour récupérer le nom associé. Si une correspondance est trouvée, le nom est attaché à l’appel et affiché sur l’appareil du destinataire. Si aucune correspondance n’est trouvée, le téléphone affiche généralement « Inconnu » ou simplement le numéro brut.
L’ensemble de cette requête s’effectue en quelques millisecondes, se terminant avant que le téléphone du destinataire ne commence à sonner. Les méthodes de requête varient selon l’implémentation :

SIP

Une méthode d’intégration moderne où l’équipement de terminaison envoie une requête SIP à un fournisseur CNAM, tel que TransNexus ClearIP, qui retourne le nom de l’appelant dans la réponse SIP. Cette approche exploite l’infrastructure SIP existante, ne nécessite aucune pile de protocoles supplémentaire et s’intègre naturellement dans les réseaux vocaux basés sur IP. Le CNAM par SIP est de plus en plus adopté par les opérateurs migrant depuis les dépendances SS7 héritées.

HTTP/HTTPS

Une autre approche moderne où l’équipement de terminaison envoie une requête de type REST à l’API d’un fournisseur CNAM, transmettant le numéro appelant et recevant le nom dans la réponse. Cette méthode est largement utilisée dans les réseaux VoIP et SIP et est simple à implémenter, ne nécessitant que des capacités client HTTP standard.

TCAP sur SS7

La méthode traditionnelle où le commutateur de terminaison envoie une requête TCAP (Transaction Capabilities Application Part) via la signalisation SS7 à une base de données CNAM. C’est la méthode utilisée par les opérateurs RTPC hérités et elle reste présente dans les réseaux hybrides où l’infrastructure SS7 est encore opérationnelle. Cependant, la tendance de l’industrie s’oriente vers les méthodes de requête basées sur IP (SIP et HTTP/HTTPS) à mesure que les opérateurs modernisent leurs réseaux.
D’autres méthodes incluent ENUM (requête basée sur DNS), SIP SUBSCRIBE/NOTIFY et les API SOAP/XML, bien qu’elles soient moins courantes dans les déploiements en production.
Les interrogations CNAM comportent un coût par requête. Les tarifs typiques varient de 0,002 $ à 0,006 $ par requête. Pour les opérateurs à haut volume traitant des millions d’appels par mois, ces coûts s’accumulent, faisant de l’interrogation CNAM sélective (décider quels appels nécessitent une requête et lesquels non) une considération opérationnelle importante.

CNAM, CLID et STIR/SHAKEN : comment ils s’articulent

Le CNAM est un composant d’une pile d’identité de l’appelant plus large. Comprendre comment il se rapporte aux autres éléments aide les fournisseurs de services à concevoir un cadre d’identité et de confiance cohérent.

CLID (Calling Line Identification)

Le CLID désigne le numéro de téléphone lui-même. En SIP, il est transporté dans l’en-tête From ou l’en-tête P-Asserted-Identity (PAI). Le CLID vous indique le numéro qui a initié l’appel.

CNAM

Le CNAM est le nom associé à ce numéro. Il est récupéré par le côté terminaison via une requête en base de données. Le CNAM vous indique à qui ce numéro est censé appartenir.

STIR/SHAKEN

STIR/SHAKEN fournit un cadre cryptographique qui atteste si le numéro appelant est légitime. L’opérateur d’origine signe l’appel avec un certificat numérique, et l’opérateur de terminaison vérifie la signature. STIR/SHAKEN ne fournit pas de nom ; il fournit un niveau d’attestation (A, B ou C) indiquant dans quelle mesure l’opérateur d’origine peut garantir l’authenticité de l’appel.
La distinction pratique est importante : le CNAM vous donne le nom, et STIR/SHAKEN vous dit s’il faut lui faire confiance. Un appel usurpé pourrait porter un CLID d’apparence légitime qui retourne un nom CNAM valide, mais la vérification STIR/SHAKEN le signalerait avec un niveau d’attestation faible (ou échouerait entièrement à la vérification). Utilisés ensemble, le CNAM et STIR/SHAKEN donnent à l’opérateur de terminaison à la fois les informations d’identité et un signal de confiance.
En perspective, les initiatives Rich Call Data (RCD) et Branded Calling vont au-delà de la limite de 15 caractères du CNAM. Ces technologies, encore en déploiement précoce, permettent aux appelants vérifiés de transmettre des logos, des noms d’entreprise et des descriptions de motif d’appel directement sur l’appareil du destinataire. Les fournisseurs de services qui construisent une infrastructure vocale aujourd’hui devraient prévoir les trois couches : le CNAM pour la transmission de base du nom, STIR/SHAKEN pour l’authentification, et une voie vers le branded calling pour des affichages de confiance enrichis.

La place du SBC dans la transmission CNAM

Pour les fournisseurs de services, le Session Border Controller (SBC) est le point d’exécution naturel pour les requêtes CNAM. Le SBC se trouve en périphérie du réseau, traitant chaque appel entrant et sortant. Il a accès aux données de signalisation de l’appel (y compris le numéro appelant), et il peut modifier les en-têtes SIP de l’appel avant de le transmettre en aval.

Déploiement SBC d’interconnexion

Le SBC reçoit les appels des opérateurs interconnectés. Lorsqu’il fonctionne comme opérateur de terminaison, le SBC effectue l’interrogation CNAM avant de router l’appel vers le prochain saut, qu’il s’agisse d’un IP-PBX, d’un softswitch ou d’un point de terminaison abonné. Le SBC interroge la base de données CNAM, reçoit le nom de l’appelant et l’inscrit dans le champ de nom d’affichage SIP afin que les équipements en aval et les appareils des utilisateurs finaux puissent le présenter.

Déploiement SBC d’accès

Le SBC se situe entre le réseau cœur du fournisseur de services et la périphérie abonné. Les informations CNAM peuvent déjà être présentes dans la signalisation de l’appel (renseignées par un élément en amont), ou le SBC d’accès peut effectuer la requête lui-même si l’architecture réseau place cette responsabilité en périphérie.
L’avantage principal de l’exécution du CNAM au niveau du SBC est le contrôle. Le SBC peut décider, par trunk ou par appel, s’il faut effectuer une interrogation CNAM, quelle base de données interroger et comment gérer les échecs de requête. Cette granularité est importante pour la gestion des coûts (ignorer les requêtes sur les trunks internes de confiance) et pour la qualité (basculement élégant lorsqu’un fournisseur CNAM est injoignable).

Comment ProSBC gère les requêtes CNAM

ProSBC intègre les requêtes CNAM directement dans son moteur de routage Ruby programmable. Plutôt que de traiter le CNAM comme un interrupteur de configuration statique, ProSBC l’expose comme un filtre dans la chaîne de routage des appels, offrant aux opérateurs un contrôle fin sur le moment, la méthode et les appels pour lesquels les interrogations CNAM s’effectuent.
ProSBC prend en charge les méthodes de requête CNAM basées sur IP : SIP, HTTP et HTTPS. ProSBC ne prend pas en charge l’interrogation CNAM via TCAP sur SS7, étant une plateforme entièrement native IP conçue autour des protocoles de signalisation modernes.

CNAM par SIP avec TransNexus ClearIP

L’intégration CNAM principale de ProSBC utilise SIP pour interroger TransNexus ClearIP. Lorsqu’un appel atteint le moteur de routage, le filtre envoie une requête CNAM par SIP à ClearIP, qui retourne le nom de l’appelant dans la réponse SIP. À la réception de la réponse, le filtre inscrit le nom retourné dans le champ calling_display de l’appel, qui correspond au nom d’affichage SIP vu par les équipements en aval. Le filtre utilise un mécanisme de retour asynchrone au script afin que le routage ne soit pas bloqué en attendant la réponse de la base de données. Cette approche par SIP exploite l’infrastructure SIP existante et ne nécessite aucune pile de protocoles supplémentaire.

Requêtes CNAM HTTP/HTTPS

ProSBC prend également en charge les requêtes CNAM via les API REST HTTP/HTTPS. Il s’agit d’une méthode d’intégration directe où le moteur de routage envoie une requête HTTP au point de terminaison API d’un fournisseur CNAM, transmettant le numéro appelant et recevant le nom de l’appelant dans la réponse. Le CNAM par HTTP est facile à implémenter et fonctionne avec tout fournisseur CNAM proposant une API REST.

Intégration TNS Dip

Pour les opérateurs qui utilisent Transaction Network Services (TNS), le moteur de routage de ProSBC prend en charge les interrogations combinées de bases de données via SIP. Un seul script de routage peut gérer les requêtes LNP (portabilité des numéros locaux), numéros gratuits et CNAM ensemble. La colonne de configuration dip au niveau du NAP contrôle quels types d’interrogation sont actifs pour chaque groupe de trunks. Le régler sur CNAME déclenche uniquement les requêtes CNAM ; le régler sur ALL déclenche LNP, numéros gratuits et CNAM en séquence. Le régler sur NONE ignore complètement les interrogations. Note : TNS prend actuellement en charge l’interrogation CNAM via TCAP sur SS7 uniquement ; la prise en charge CNAM par SIP de TNS est prévue mais pas encore disponible.

Contrôle par NAP

Les Network Access Points (NAP) dans ProSBC représentent les groupes de trunks ou les pairs SIP. Le comportement CNAM est configurable par NAP, permettant aux opérateurs d’activer les interrogations CNAM sur les trunks transportant du trafic externe tout en les désactivant sur les trunks internes ou de confiance où l’identité de l’appelant est déjà connue. Cela maintient les coûts de requête sous contrôle sans sacrifier la couverture là où elle compte.

Prévention des requêtes en double

Le moteur de routage désactive automatiquement le service CNAM pour un appel après la première réponse réussie, empêchant les requêtes répétées inutiles si l’appel traverse plusieurs étapes de routage.
L’approche de ProSBC diffère des SBC qui proposent le CNAM comme un interrupteur binaire marche/arrêt au niveau système. La programmabilité par NAP et par appel permet aux opérateurs d’implémenter des politiques nuancées : interroger le CNAM pour les appels arrivant sur les interconnexions opérateurs, l’ignorer pour les appels de clients entreprise connus, et appliquer différents fournisseurs CNAM à différents groupes de trunks en fonction du coût ou de la couverture.

Bonnes pratiques pour les fournisseurs de services

Choisissez votre fournisseur de base de données CNAM en fonction de la couverture

Puisqu’aucune base de données CNAM ne contient chaque numéro, le fournisseur que vous interrogez affecte directement le pourcentage d’appels qui retournent un nom valide. Certains fournisseurs agrègent les données de plusieurs LIDB pour une couverture plus large. Évaluez les fournisseurs en fonction du taux de correspondance pour votre profil de trafic, pas uniquement du coût par requête.

Surveillez les coûts des requêtes à grande échelle

À 0,002 $ à 0,006 $ par requête, un opérateur traitant 10 millions d’appels par mois pourrait dépenser de 20 000 $ à 60 000 $ annuellement en interrogations CNAM uniquement. Utilisez le contrôle CNAM par trunk (comme ProSBC le propose) pour éviter les requêtes sur les trunks où elles sont inutiles. Négociez une tarification basée sur le volume avec votre fournisseur CNAM.

Soyez délibéré concernant la mise en cache

Certains fournisseurs mettent en cache les résultats CNAM localement pour réduire le nombre de requêtes externes. La mise en cache réduit les coûts mais introduit l’obsolescence : un abonné qui a changé de nom ou porté son numéro peut encore afficher l’ancienne entrée CNAM jusqu’à l’expiration du cache. Définissez les TTL du cache en fonction de votre tolérance aux données obsolètes.

Combinez le CNAM avec STIR/SHAKEN

Le CNAM sans authentification est un nom sans preuve. Si votre réseau prend en charge la signature et la vérification STIR/SHAKEN, l’associer au CNAM donne à vos abonnés à la fois un nom et un indicateur de confiance. ProSBC prend en charge à la fois STIR/SHAKEN (via ses modules de signature/vérification) et le CNAM dans la même chaîne de routage.

Préparez l’évolution vers le branded calling

La limite de 15 caractères du CNAM a été conçue pour une époque d’écrans de téléphone réduits et de réseaux à commutation de circuits. Les plateformes Rich Call Data et branded calling transmettent des logos, des noms d’entreprise complets et du texte de motif d’appel. Bien que le CNAM reste la référence de base, les fournisseurs de services doivent s’assurer que leur SBC et leur infrastructure en aval peuvent transmettre les données d’identité enrichies de l’appelant à mesure que ces normes mûrissent.

Maintenez l’exactitude des enregistrements CNAM pour vos propres abonnés

En tant que fournisseur de services d’origine, vous êtes responsable de la maintenance des entrées CNAM associées aux numéros que vous attribuez. Des données CNAM inexactes érodent la confiance dans l’ensemble du système et peuvent conduire à ce que vos numéros soient signalés par les moteurs d’analyse en aval.

CNAM et réglementations de la FCC

Le Truth in Caller ID Act de la FCC interdit la transmission d’informations d’identification de l’appelant trompeuses ou inexactes dans l’intention de frauder. Bien que cette loi cible principalement l’usurpation d’identité, elle souligne l’environnement réglementaire autour de l’identité de l’appelant, dont le CNAM est un composant clé.
Le mandat STIR/SHAKEN, que la FCC a commencé à appliquer en 2021, complète le CNAM en exigeant que les fournisseurs de services authentifient les numéros appelants à l’aide de certificats numériques. STIR/SHAKEN ne remplace pas le CNAM, mais fournit la couche d’authentification qui lui manque.
Plus récemment, la FCC a exploré l’extension de l’identité de l’appelant au-delà du CNAM par des initiatives de branding des appels. Un Further Notice of Proposed Rulemaking de 2025 a examiné des cadres pour la transmission d’informations d’identité commerciale vérifiées (y compris des logos et des noms d’entreprise de plus de 15 caractères) aux consommateurs. Les fournisseurs de services devraient suivre ces procédures, car de futures règles pourraient exiger une prise en charge au niveau du SBC de données d’identité d’appelant plus riches.

Conclusion

Le CNAM est une infrastructure vocale fondamentale. Pour les fournisseurs de services et les opérateurs, ce n’est pas une fonctionnalité à activer et oublier. C’est une opération par appel qui affecte l’expérience abonné, les coûts d’exploitation et la conformité réglementaire.
Le SBC, en tant qu’élément de périphérie réseau traitant chaque appel, est l’endroit approprié pour exécuter les requêtes CNAM. ProSBC rend cela pratique grâce à son moteur de routage programmable, où les requêtes CNAM sont des filtres dans la chaîne d’appel, configurables par groupe de trunks, combinables avec les interrogations LNP et numéros gratuits, et intégrées aux côtés de l’attestation STIR/SHAKEN.
Que vous déployiez le CNAM pour la première fois ou que vous optimisiez une implémentation existante, le contrôle par NAP et les scripts de routage Ruby de ProSBC vous offrent la flexibilité nécessaire pour adapter votre stratégie CNAM à votre profil de trafic et vos objectifs de coûts.

Foire aux questions