Portabilité des numéros : ce que les FSI et les opérateurs doivent savoir

La portabilité des numéros est le mécanisme réglementaire qui permet à un abonné de conserver son numéro de téléphone existant lors d’un changement de fournisseur, de type de transport ou de catégorie de service. Pour les FSI et les opérateurs, c’est aussi l’un des processus les plus pénibles sur le plan administratif dans les opérations vocales, et l’un des moyens les plus faciles de perdre des clients lorsque quelque chose tourne mal. La plupart des opérateurs ne le réalisent qu’après leur premier rejet de portage.

Cet article constitue la référence opérationnelle pour les FSI, ILEC, CLEC, MSP et opérateurs de gros qui gèrent les activités de portage entrant et sortant comme une composante récurrente de leurs opérations vocales, et non comme un événement de migration ponctuel. Nous couvrons ce qu’est réellement la portabilité des numéros locaux (LNP), le fonctionnement des régimes dominants en Amérique du Nord, au Royaume-Uni, dans l’Union européenne et dans plusieurs marchés de la zone Asie-Pacifique, le rôle du Session Border Controller (SBC) au niveau de la couche de routage une fois qu’un numéro a été porté, le pipeline opérationnel pour le portage entrant et sortant, et les modes de défaillance qui causent la plupart des litiges de portage.

Si vous effectuez une migration ponctuelle du RTC vers une plateforme VoIP, le guide de migration de remplacement du RTC pour les FSI est le bon point de départ. Cet article s’adresse à l’équipe qui doit gérer les portages de manière continue, une fois la migration terminée. Pour un contexte plus large sur l’architecture SIP dans laquelle cela s’inscrit, consultez le pilier SIP trunking et interopérabilité.

Ce qu’est réellement la portabilité des numéros

La portabilité des numéros est une promesse réglementaire : lorsqu’un abonné change de fournisseur de services vocaux, le numéro l’accompagne. Cette promesse est d’origine pro-concurrentielle, et elle est désormais un élément incontournable de la politique des télécommunications dans tous les marchés significatifs. Aux États-Unis, l’exigence provient de la Section 251 du Telecommunications Act de 1996 (voir la présentation de la FCC sur la portabilité des numéros locaux sans fil). Au Royaume-Uni, elle découle des General Conditions of Entitlement de l’Ofcom. Dans l’Union européenne, elle est codifiée dans l’article 106 du Code européen des communications électroniques. L’Australie, le Brésil, l’Inde et la plupart des marchés de la zone Asie-Pacifique ont des règles parallèles administrées par leurs régulateurs respectifs.

Trois types de portabilité existent en pratique. La portabilité de fournisseur est le cas courant : le numéro reste le même, le fournisseur change. La portabilité géographique permet au numéro de suivre l’abonné vers un nouvel emplacement physique, ce que le NANP ne prend en charge que dans la même zone de tarification, mais que plusieurs marchés de l’UE autorisent de manière plus large. La portabilité de service permet à un numéro de passer d’un type de service à un autre, comme du fixe au mobile, et reste rare en dehors d’un petit nombre de juridictions. Pour les FSI et les opérateurs, la portabilité de fournisseur est le processus qui consomme le temps opérationnel.

Ce qui est portable est le numéro lui-même, pas le forfait de service, la boîte vocale, les fonctionnalités d’appel ou les identifiants SIP. Un abonné qui porte un numéro d’un opérateur donneur vers un opérateur receveur achète un nouveau service qui partage simplement un identifiant avec l’ancien. Cette distinction est la source d’une quantité surprenante de confusion chez les abonnés et d’un nombre surprenant de tickets de support post-portage, ce qui est l’une des raisons pour lesquelles la portabilité des numéros est traitée comme une discipline opérationnelle plutôt que comme une tâche technique.

Fonctionnement de la LNP dans le plan de numérotation nord-américain

Le NANP couvre les États-Unis, le Canada et la plupart des territoires des Caraïbes. La base de données centrale qui rend la LNP possible sur cette empreinte est le NPAC, exploité par iconectiv dans le cadre d’un contrat pluriannuel attribué par le NAPM (le comité NANC qui sélectionne le LNPA). Chaque numéro éligible au portage dans le NANP possède un enregistrement NPAC qui associe le numéro de téléphone à un LRN identifiant le commutateur qui le dessert actuellement. Le LRN est ce vers quoi le réseau route après l’exécution d’un portage.

Les acteurs

L’opérateur donneur dessert actuellement le numéro et est tenu par les règles de la FCC et du CRTC de coopérer au portage. L’opérateur receveur prend en charge le numéro et est responsable de l’initiation du LSR, de la collecte du LOA, de la validation du CSR, de la coordination de la bascule et de la notification à l’abonné. Le NPAC détient l’association LRN-numéro faisant autorité. iconectiv administre le NPAC, le LERG, le registre des Service Provider Identifier (SPID) et le programme de jetons Service Provider Code (SPC) qui lie les enregistrements d’autorisation de numéros à l’attestation STIR/SHAKEN.

Le processus

Un portage entrant commence lorsque l’abonné signe un LOA chez l’opérateur receveur. L’opérateur receveur valide le LSR par rapport au CSR obtenu auprès de l’opérateur donneur, puis soumet le LSR via une chambre de compensation (NeuStar, iconectiv, TNS ou Bandwidth, selon la configuration de l’opérateur). L’opérateur donneur examine le LSR, confirme la propriété du compte et retourne un FOC avec l’heure de bascule convenue, généralement exprimée sous forme de date et d’une fenêtre de quatre heures. Lors de la bascule, l’enregistrement NPAC du numéro de téléphone porté est mis à jour pour pointer vers le LRN de l’opérateur receveur. À partir de ce moment, chaque opérateur NANP qui effectue une interrogation LNP sur ce numéro route l’appel vers l’opérateur receveur.

Portages de gros vs portages d’abonnés

Pour les FSI et les opérateurs, les portages de gros et les portages au niveau de l’abonné comptent tous les deux. Un portage d’abonné implique un seul client final passant d’un fournisseur à un autre et suit le processus LSR standard. Un portage de gros couvre un bloc de numéros transférés entre deux opérateurs en amont, souvent dans le cadre d’une acquisition ou d’un changement de fournisseur de gros, et est administré par lots via les mêmes mécanismes NPAC. Un petit FSI terminant le service via un partenaire de gros peut vivre les deux simultanément : son fournisseur amont change d’opérateur (un portage de gros que le FSI n’a pas demandé), et un abonné choisit simultanément de partir (un portage sortant d’abonné que le FSI a bien initié). La coordination des deux est opérationnellement délicate et constitue l’un des modes de défaillance traités plus loin dans cet article.

Fonctionnement de la LNP en dehors de l’Amérique du Nord

Chaque marché vocal réglementé dispose d’une forme de portabilité des numéros, mais le modèle administratif et le rythme opérationnel diffèrent. Trois schémas dominent.

Royaume-Uni (Ofcom)

Le Royaume-Uni fonctionnait historiquement selon un modèle piloté par l’opérateur donneur, où ce dernier contrôlait le portage et les appels étaient systématiquement routés d’abord vers le donneur avant d’être acheminés vers le receveur. L’Ofcom met en place progressivement un modèle piloté par l’opérateur receveur qui reflète l’architecture du NANP, avec une base de données centrale faisant autorité et un routage direct vers l’opérateur receveur. Le délai de portage sous le modèle piloté par le receveur est d’un jour ouvrable pour les abonnés résidentiels, avec une exécution le jour même possible pour les clients professionnels dans certains scénarios. Le Royaume-Uni utilise des messages de portage au format XML échangés via les systèmes d’Openreach et des principaux opérateurs.

Union européenne (CCEE)

En vertu de l’article 106 du CCEE, tous les États membres sont tenus de mettre en œuvre la portabilité entre fournisseurs dans un délai d’un jour ouvrable, gratuitement pour l’abonné. Chaque État membre administre sa propre base de données centrale (l’OPTA aux Pays-Bas, le registre BIPT en Belgique, le système BNetzA en Allemagne, etc.), mais les concepts opérationnels sont alignés : l’opérateur receveur initie, l’opérateur donneur valide, un registre central enregistre le changement et le routage est mis à jour. De nombreux marchés de l’UE utilisent ENUM (correspondance E.164 vers URI) comme mécanisme de recherche de routage pour les numéros portés, ce qui signifie que le rôle du SBC au niveau de la couche de routage est légèrement différent d’une interrogation LRN dans le NANP.

Australie, Brésil, Inde et autres marchés Asie-Pacifique

L’Australie (ACMA, piloté par le receveur, délai rapide), le Brésil (ANATEL, base de données NP centrale) et l’Inde (TRAI, opérateurs régionaux de portabilité des numéros mobiles) maintiennent chacun leurs propres registres centraux et processus de portage. Le schéma commun à tous est une base de données centrale plus un échange défini entre les opérateurs donneur et receveur. La différence de comportement du SBC par rapport au NANP réside dans le type d’interrogation effectuée : une interrogation LRN contre le NPAC dans le NANP, une recherche ENUM dans une grande partie de l’UE, une requête vers la base de données NP centrale au Brésil, etc. Chaque type de requête est techniquement un appel API différent contre une source de vérité différente, mais la question de routage sous-jacente reste la même : qui dessert ce numéro actuellement ?

Considérations transfrontalières

La portabilité des numéros est nationale par conception. Un numéro américain ne peut pas être porté vers un opérateur britannique, et inversement. Les opérateurs présents dans plusieurs pays gèrent des processus LNP distincts par juridiction. Le trafic vocal international provenant d’un numéro porté est routé en utilisant les mêmes chemins de sortie que tout autre appel ; le changement de portabilité est local au marché qui administre le bloc de numéros.

Les mécanismes de routage : le rôle du SBC

Avant l’existence de la portabilité des numéros, chaque numéro de téléphone avait un domicile fixe : le NPA-NXX des chiffres composés indiquait au réseau exactement quel commutateur le desservait. Le routage était statique et résidait dans le LERG. La portabilité a brisé cette hypothèse. Après un portage, le NPA-NXX du numéro appelé indique toujours la zone de tarification d’origine, mais le commutateur de desserte réel se trouve tout à fait ailleurs. Le réseau doit découvrir le nouvel emplacement à chaque appel, et c’est là que le SBC intervient.

L’interrogation LNP

Une interrogation LNP est une requête vers la base de données de portabilité pour récupérer l’identifiant de routage actuel d’un numéro. Dans le NANP, l’interrogation retourne le LRN. Dans les marchés de l’UE utilisant ENUM, l’interrogation retourne une URI vers laquelle l’appel doit être routé. Dans chaque cas, le SBC prend le numéro appelé de l’INVITE entrant, interroge la base de données appropriée (ou une copie en cache) et réécrit la décision de routage en fonction du résultat.

L’interrogation peut s’effectuer contre la base de données nationale en direct, contre un miroir local rafraîchi périodiquement, ou contre un fournisseur tiers qui revend l’accès aux interrogations (TransNexus, Neustar, iconectiv, Bandwidth, TNS). Pour les FSI et les petits opérateurs, le modèle d’interrogation en tant que service tiers est le schéma courant. Le coût par interrogation varie selon le fournisseur et le volume, généralement une fraction de centime, mais à l’échelle d’un opérateur les coûts s’accumulent, c’est pourquoi la mise en cache des interrogations avec des TTL raisonnables est opérationnellement importante.

Gestion de l’indicateur NPDI

L’indicateur NPDI dans la signalisation SIP indique qu’un nœud en amont a déjà effectué une interrogation LNP pour cet appel. Lorsque le SBC détecte NPDI=yes sur un INVITE entrant, le comportement correct est d’honorer le résultat amont et de ne pas effectuer l’interrogation. Réinterroger un numéro qui a déjà été résolu en amont gaspille du temps, coûte de l’argent et peut provoquer des incohérences de routage si les bases de données en amont et en aval divergent. Un SBC correctement configuré vérifie toujours le NPDI avant d’initier une interrogation, et définit toujours le NPDI sur les INVITE sortants après avoir effectué sa propre interrogation afin que les nœuds en aval puissent faire de même.

Positionnement dans le pipeline de routage

L’interrogation LNP s’exécute généralement tôt dans l’établissement de l’appel, après la validation SIP de base et avant la décision de routage. Le résultat de l’interrogation confirme soit la route basée sur le NPA-NXX d’origine (le numéro n’est pas porté, ou il a été reporté vers son commutateur d’origine), soit réécrit la route vers le nouvel opérateur de desserte. ProSBC implémente les interrogations LNP via ses modules API : le script de routage invoque une requête HTTP ou SIP vers le fournisseur LNP, analyse la réponse et met à jour la décision de routage avant que l’appel ne progresse. Pour une présentation architecturale complète de la manière dont les recherches externes s’intègrent au traitement des appels du SBC, consultez le guide d’intégration REST API du SBC pour le routage d’appels.

Pourquoi le SBC est le bon endroit pour cela

Deux raisons. Premièrement, le SBC est le point d’entrée naturel : il termine déjà le SIP, ancre les médias, applique les règles de manipulation d’en-têtes SIP et constitue le premier saut où la logique de routage des appels est appliquée. Ajouter une interrogation LNP à cette couche centralise les décisions de routage. Deuxièmement, l’architecture B2BUA donne au SBC un contrôle total sur l’INVITE sortant, y compris la capacité d’insérer le NPDI, de réécrire le Request-URI, de définir le LRN comme numéro de routage et de transmettre le numéro appelé d’origine intact pour la facturation en aval.

Le pipeline opérationnel : portage entrant et sortant

La couche technique est la partie la plus facile. Le pipeline administratif est là où la plupart des portages réussissent ou échouent, et c’est aussi là où les FSI sans personnel dédié aux opérations vocales ressentent la pression. Le pipeline comporte deux flux en miroir.

Portage entrant (vous êtes l’opérateur receveur)

Recevez le LOA signé de l’abonné. Validez la demande par rapport au CSR obtenu auprès de l’opérateur donneur ; une divergence du nom de facturation ou de l’adresse de service est la raison la plus courante de rejet d’un LSR. Soumettez le LSR via votre chambre de compensation avec la date de bascule souhaitée. Suivez le retour du FOC et résolvez les codes de rejet soulevés par l’opérateur donneur (erreur de frappe dans le numéro de compte, divergence d’adresse, compte gelé, solde en attente). Une fois le FOC en main, provisionnez le routage sur votre SBC, confirmez la couverture du plan de numérotation, configurez la boîte vocale et les fonctionnalités de service attendues par l’abonné, et informez l’abonné de l’heure de bascule. Lors de la bascule, vérifiez que les appels entrants atteignent la nouvelle plateforme et que l’identifiant d’appelant sortant s’affiche correctement.

Portage sortant (vous êtes l’opérateur donneur)

Recevez le LSR de l’opérateur receveur. Validez-le par rapport à votre CSR et répondez dans le délai imposé par le régulateur : les règles de la FCC exigent que les portages simples soient effectués dans un délai d’un jour ouvrable ; les portages professionnels complexes prennent plus de temps. Émettez le FOC avec l’heure de bascule convenue, ou rejetez le LSR avec un code spécifique si la documentation ne correspond pas. Coordonnez en interne pour vous assurer que la facturation clôture la ligne lors de la bascule, que les CDR sont conservés pour la durée réglementaire requise, et que le numéro est libéré proprement de vos tables de routage SBC.

Qui exécute quelle étape

Chez un opérateur bien doté en personnel, le pipeline est réparti : les opérations vocales gèrent l’échange LSR/FOC, la facturation gère la clôture du compte, les opérations SBC gèrent le changement de routage, et le service client gère la communication avec l’abonné. Chez un FSI plus petit, la même personne exécute souvent trois ou quatre de ces étapes, ce qui est la source des erreurs. Deux pratiques distinguent les opérateurs qui gèrent un pipeline de portage propre. La première consiste à traiter le portage comme un flux de travail coordonné avec des transferts explicites et un seul responsable par portage : un ticket de suivi, une liste de contrôle et une validation à chaque étape. La seconde consiste à automatiser le changement de routage afin qu’à l’heure de la bascule, la mise à jour du routage SBC se fasse via un appel API plutôt que par une modification manuelle de configuration à 2 h du matin par la personne d’astreinte.

Modes de défaillance courants

La plupart des échecs de portage sont administratifs, pas techniques. Le schéma observé sur des milliers de litiges de portage est qu’environ quatre sur cinq sont imputables à des divergences de données, des délais manqués ou un manque de clarté sur les responsabilités, la couche technique de routage représentant le reste. Les modes de défaillance ci-dessous sont ceux que les opérateurs rencontrent le plus souvent.

Divergence CSR entraînant un rejet du FOC

Le nom de facturation de l’abonné sur le LSR doit correspondre exactement au CSR de l’opérateur donneur. « Jean A. Dupont » et « Jean Dupont » peuvent être traités comme des identités différentes. Il en va de même pour les adresses, les numéros de compte et les contacts autorisés. Un seul caractère divergent suffit à rejeter le LSR, ce qui coûte à l’opérateur receveur un cycle de re-collecte et de re-soumission du LOA. La solution est procédurale : l’opérateur receveur obtient le CSR avant de soumettre le LSR, le compare ligne par ligne au LOA et résout toute divergence avec l’abonné avant d’envoyer quoi que ce soit à l’opérateur donneur.

Fenêtre de bascule manquée

Le FOC fixe une heure de bascule précise. Si l’opérateur receveur n’a pas provisionné le routage sur le SBC à ce moment-là, les appels entrants vers le numéro porté échouent jusqu’à ce que le routage soit en place. Les abonnés tolèrent un portage ponctuel ; ils ne tolèrent pas des heures d’appels entrants perdus. La solution est de provisionner le routage SBC à l’avance et de lier l’activation à l’heure du FOC via l’API du SBC, de sorte que le changement de routage soit piloté par événement plutôt que dépendant d’un humain au clavier.

Snapback (inversion de portage)

L’opérateur donneur peut inverser un portage dans un délai défini, généralement 30 jours dans le NANP, en cas de portage sortant frauduleux ou en réponse à un litige d’abonné. L’opérateur receveur se retrouve avec un enregistrement orphelin : le numéro est de retour chez l’opérateur donneur, mais les tables de routage locales, les archives CDR et les registres de facturation référencent toujours l’opérateur receveur. La gestion du snapback est un problème de processus : une réconciliation régulière entre les tables de routage du SBC et l’association NPAC faisant autorité détecte les enregistrements orphelins avant qu’ils ne causent des échecs de routage.

Échecs d’interrogation LRN

Si le SBC ne parvient pas à effectuer l’interrogation LNP (délai d’attente du fournisseur, erreur réseau, identifiants API expirés, miss de cache sans repli), le routage revient à la logique basée sur le NPA-NXX et l’appel est livré à la zone de tarification d’origine. Pour les numéros portés, c’est la mauvaise destination. La solution est la redondance d’interrogation : configurez des fournisseurs LNP primaire et secondaire sur le SBC, définissez un délai d’attente serré (généralement 500 à 2 500 ms), journalisez chaque échec d’interrogation dans les CDR pour la surveillance, et définissez une politique de repli claire lorsque les deux fournisseurs échouent. Laisser les appels tomber vers le routage NPA-NXX est acceptable dans certaines configurations d’opérateurs et inacceptable dans d’autres ; la politique doit être définie explicitement.

Litiges inter-LATA et intra-LATA

Les petits ILEC résistent occasionnellement aux portages intra-LATA, invoquant des motifs tarifaires ou réglementaires qui sont généralement procéduraux plutôt que de fond. La voie de résolution est l’escalade administrative via la chambre de compensation et, dans certains cas, la FCC. La mesure préventive la plus efficace est de maintenir la documentation LSR précise et complète, ce qui élimine les motifs procéduraux de résistance.

Perte de boîte vocale et de fonctionnalités

Les messages vocaux, les fonctionnalités d’appel et les personnalisations par numéro sont spécifiques à la plateforme. Ils ne sont pas portés. Les abonnés s’attendent raisonnablement à retrouver après le portage tout ce qu’ils avaient avant, et ils appellent le support quand ce n’est pas le cas. Gérer les attentes lors de l’étape de collecte du LOA est la seule solution durable, accompagnée d’une liste de contrôle des fonctionnalités lors de la bascule pour s’assurer que la nouvelle plateforme est provisionnée avec les mêmes fonctionnalités d’appel que celles dont l’abonné disposait sur l’ancienne.

Portage de DID versus portage de trunk

Lorsqu’un abonné dispose d’un trunk avec de nombreux DID, chaque DID est porté individuellement via son propre LSR. Tenter de porter un trunk de mille DID comme un seul enregistrement peut entraîner des complétions partielles, où certains DID atterrissent chez l’opérateur receveur et d’autres restent chez l’opérateur donneur, cassant le routage entrant pour la moitié du trunk. Les portages de gros utilisent des mécanismes de portage par bloc spécifiquement pour éviter cela ; les portages au niveau de l’abonné de grands inventaires de DID nécessitent un traitement par lots coordonné.

STIR/SHAKEN et la traçabilité documentaire du portage

Dans le NANP, la documentation de portage n’est plus un simple artefact opérationnel. Dans le cadre réglementaire de la FCC pour l’authentification de l’appelant, l’attestation de niveau A exige que le fournisseur de services d’origine ait une relation directe et vérifiée avec l’appelant et des enregistrements précis de l’association numéro-client. Le LOA, le CSR et le FOC constituent la preuve que le fournisseur peut légitimement attester au niveau A pour les appels provenant du numéro porté. Les fournisseurs incapables de produire une documentation de portage propre sont de plus en plus rétrogradés vers une attestation de niveau B ou C par leurs partenaires de signature en amont, avec un impact mesurable sur les taux de complétion d’appels.

La conséquence pratique : le processus de portage alimente désormais directement le processus de conformité. Conservez les LOA en archivage à long terme, liez-les à l’enregistrement de portage NPAC et stockez-les de manière à ce que l’équipe de conformité puisse les récupérer à la demande. Pour une présentation approfondie des exigences d’attestation et du parcours opérationnel du niveau C au niveau A de signature, consultez le guide d’attestation STIR/SHAKEN de niveau A.

Ce qu’il faut rechercher dans un SBC pour les opérations LNP

Un SBC fonctionnant dans un environnement avec une activité de portage active a des exigences spécifiques. La plupart découlent des points architecturaux déjà traités.

Moteur de routage programmable. Chaque régime LNP est différent. Le NANP utilise le NPAC et les interrogations LRN ; l’UE utilise ENUM dans de nombreux marchés ; le Brésil et l’Inde utilisent des bases de données NP centrales avec leurs propres sémantiques de requête. Un SBC avec une couche de routage programmable peut implémenter chaque type de requête sans attendre un cycle de publication du fournisseur. Le moteur de routage Ruby de ProSBC expose plus de 100 paramètres d’appel et prend en charge les requêtes HTTP, Radius et SIP vers n’importe quel système externe, ce qui facilite l’ajout d’un nouveau fournisseur LNP ou d’un nouveau format de requête.

Prise en charge du NPDI en entrée et en sortie. Le SBC doit détecter le NPDI sur les appels entrants et honorer le résultat de l’interrogation amont, et il doit définir le NPDI sur les appels sortants après avoir effectué sa propre interrogation. Ignorer cela transforme une interrogation à un seul saut en une cascade d’interrogations à plusieurs sauts.

Contrôle LNP par NAP. Différents trunk groups ont des besoins différents. Un NAP orienté opérateur de gros peut toujours faire confiance au NPDI amont ; un NAP orienté abonné peut toujours interroger localement ; un trunk Teams Direct Routing peut nécessiter une politique encore différente. Le SBC doit permettre à l’opérateur de définir le comportement LNP par NAP sans modifier la politique globale.

Redondance d’interrogation et journalisation des échecs. Fournisseurs primaire et secondaire, délais d’attente serrés, journalisation des résultats d’interrogation dans les CDR et comportement de repli explicite. Les interrogations LNP ne sont pas optionnelles, donc le mode de défaillance doit être défini à l’avance et observable après coup.

Changements de routage pilotés par API. L’heure de bascule ne doit pas dépendre d’un humain. Le SBC doit accepter les mises à jour de routage via son API REST afin que le pipeline de portage puisse déclencher le changement de routage exactement au moment prévu par le FOC.

Détail CDR pour les audits de portage. Chaque résultat d’interrogation, chaque LRN, chaque indicateur NPDI, chaque réécriture de Request-URI doit être visible dans le CDR afin que l’équipe d’exploitation puisse reconstituer le routage de tout appel litigieux.

FAQ