Résumé

  • Le RFC 5346 rapporte un essai précommercial coréen d’Infrastructure ENUM mené en 2006 par NIDA et deux opérateurs VoIP. Il est informatif et ne définit aucune norme Internet. Sa valeur tient à la précision de ses embranchements : une réponse DNS, une URI exploitable, la résolution de son domaine, une table privée, le repli PSTN et l’issue de l’appel constituent des preuves différentes.
  • Dans les plages « ENUM only », NOERROR sans URI d’appel utilisable signifiait qu’un numéro existait mais n’était pas en service ; l’appel devait s’arrêter, car aucun point d’interconnexion PSTN n’existait. À l’inverse, NXDOMAIN, SERVFAIL, refus, erreur de format ou expiration conduisaient vers le routage historique pour les numéros susceptibles d’être atteints par le PSTN.
  • Le contrôle durable consiste à enregistrer non seulement le numéro et le résultat, mais la réponse exacte, l’interprétation de politique, le NAPTR retenu ou rejeté, la source du mapping de domaine, la cause du repli, la passerelle choisie, l’accord d’interconnexion et l’issue finale. Sans cette chaîne, un appel abouti masque le régime qui l’a réellement routé.

Deux codes, deux politiques de continuité

Une lecture trop rapide placerait NOERROR du côté du succès et NXDOMAIN du côté de l’échec. L’essai faisait autre chose. Il distinguait l’existence du nom, la présence d’une règle NAPTR utilisable et l’existence d’un chemin téléphonique de secours.

Dans une plage « ENUM only », un numéro en service devait publier une URI SIP ou H.323 valide. Il n’avait pas de point d’interconnexion PSTN. Un numéro hors service conservait néanmoins un domaine ENUM existant, avec éventuellement un enregistrement TXT, mais sans NAPTR permettant d’initier un appel. La requête NAPTR pouvait donc réussir au sens DNS et ne livrer aucune route.

Ce vide était intentionnel. Il signifiait : ne cherchez pas ailleurs. Le softswitch devait interrompre l’appel immédiatement. Un repli vers le PSTN n’aurait pas seulement été inutile ; il aurait pu créer un nouvel échec ou une boucle, puisque la plage n’était pas desservie par ce réseau.

Pour les numéros ordinaires disposant d’un point d’interconnexion PSTN, l’absence d’une entrée ENUM ne disait rien d’équivalent. Le déploiement était encore partiel. Un NXDOMAIN pouvait simplement signaler que le nouveau répertoire ne connaissait pas encore le numéro. Le softswitch conservait alors sa méthode propre, souvent fondée sur des préfixes, et transmettait l’appel au PSTN.

Le même bit d’existence DNS ne portait donc pas toute la décision. Le sens opérationnel provenait de la combinaison entre type de plage, état de service, règle de provisionnement et chemin de secours disponible.

Le DNS transportait un état que le DNS n’avait pas inventé

L’essai avait choisi une convention précise. Un domaine existant sans URI exploitable représentait un numéro ENUM-only hors service. Un domaine absent ou une erreur déclenchait la continuité historique. Cette convention était valide pour ce dispositif parce que les opérateurs avaient arrangé leurs données en conséquence.

Elle n’était pas une propriété universelle de NOERROR ou de NXDOMAIN. Un autre système pouvait employer une autre politique, supporter d’autres enumservices, distinguer autrement les pannes transitoires ou posséder un interconnect de secours dans une plage comparable.

La leçon n’est donc pas qu’un code doit toujours conduire à une action donnée. Elle est qu’une action irréversible ne doit jamais être déduite du code sans le contrat de provisionnement qui lui donne sens.

Cette dépendance devient critique quand plusieurs équipes administrent la chaîne. L’équipe DNS peut garantir que la réponse publiée est celle de la zone. L’équipe de numérotation connaît le statut du numéro. L’opérateur de softswitch choisit les services supportés. Le responsable d’interconnexion sait si le PSTN est réellement disponible. Aucun de ces contrôles, pris seul, ne suffit.

Une URI valide n’était encore qu’un embranchement

Lorsqu’un NAPTR utilisable existait, le softswitch le sélectionnait suivant les champs d’ordre et de préférence, puis examinait le domaine de l’URI. Le RFC 3403 explique la sémantique des règles NAPTR ; le RFC 5346 s’intéresse à ce qui arrivait ensuite dans le dispositif de l’opérateur.

Deux sources pouvaient transformer ce domaine en route. Le softswitch pouvait interroger un résolveur récursif et appliquer la localisation SIP. Il pouvait aussi consulter une table fixe privée associant le domaine à un nom de passerelle et à une adresse.

La seconde solution paraissait redondante. Elle imposait de maintenir les données ENUM et une table locale. Elle protégeait pourtant le service commercial pendant une phase où peu d’entrées et peu de points d’interconnexion IP étaient disponibles.

Cette table ne représentait pas seulement une optimisation. Les opérateurs facturaient l’interconnexion et concluaient des accords bilatéraux autour de passerelles précises. Une adresse résolue publiquement ne prouvait pas que n’importe quel opérateur avait le droit de l’utiliser. La table locale matérialisait en partie cette surface contractuelle.

Si le domaine manquait dans la table, l’appel repartait vers le PSTN. Si la résolution récursive échouait ou ne livrait aucun enregistrement exploitable selon les règles SIP, même résultat. Une URI ENUM valide ne démontrait donc ni une passerelle autorisée ni le chemin finalement exécuté.

La continuité rendait le nouveau répertoire difficile à mesurer

Un repli efficace est presque invisible pour l’appelant. Le résolveur échoue, le softswitch attend ou classe l’erreur, la table historique prend le relais, puis l’appel sonne. Le tableau de bord peut compter un succès sans indiquer que la tentative ENUM n’a fourni aucune route.

Ce comportement protège l’expérience client. Il peut aussi prolonger indéfiniment un répertoire incomplet. Si le taux de réponse est la seule métrique récompensée, les défauts de couverture disparaissent derrière l’infrastructure antérieure.

Le bon dénominateur sépare au moins quatre populations : appels routés par une URI ENUM ; appels ayant reçu une URI mais basculé après échec du domaine ; appels ayant quitté ENUM après erreur ou expiration DNS ; appels arrêtés volontairement après NOERROR sans URI utilisable. Les fusionner transforme une stratégie de résilience en preuve fictive d’adoption.

La bascule entre table fixe et résolution DNS était elle-même explicite dans l’essai. Les opérateurs pouvaient changer immédiatement d’approche, par prudence face aux performances et à la fiabilité. Le document qualifie cette coexistence d’expédient temporaire et non de modèle raisonnable à long terme. Une mesure doit enregistrer cette bascule, sinon deux architectures apparaissent sous le même libellé « ENUM ».

L’expiration déplaçait le problème dans le temps d’établissement

L’absence de réponse DNS finissait par être traitée comme une erreur et déclenchait le repli. Mais l’attente était longue à l’échelle d’un appel. Le succès final ne supprimait pas la latence accumulée avant de changer de régime.

Les participants auraient pu raccourcir les timeouts. Ils ne l’ont pas fait : la pile DNS du softswitch servait d’autres usages, et une configuration non conforme exigeait d’en étudier les effets au-delà d’ENUM. Modifier un paramètre partagé pour accélérer une branche pouvait fragiliser d’autres fonctions.

Cette décision montre pourquoi un timeout est une preuve de contrôle. Il ne s’agit pas seulement d’un nombre de millisecondes. Il marque le moment où le softswitch cesse de faire confiance à la nouvelle source et remet la décision à l’ancienne.

L’erratum 1537, classé « Held for Document Update », corrige quatre renvois de la section 4.1.1 : ils doivent viser la règle 3, non la règle 2. L’erratum 1538 remplace « non-complaint » par « non-compliant ». Une procédure reproductible doit intégrer ces corrections au lieu de copier silencieusement une numérotation erronée.

La moyenne de délai ne révélait pas le chemin

L’essai mesurait le temps moyen entre un INVITE SIP et un 200 OK. Les six comparaisons ENUM/non-ENUM restaient séparées de moins d’une seconde : 2,33/2,28 secondes pour A vers A ; 2,23/2,25 pour A vers B ; 4,11/3,79 pour A vers un autre destinataire PSTN ; 2,18/2,05 pour B vers B ; 2,19/2,19 pour B vers A ; 3,95/3,41 pour B vers un autre destinataire PSTN.

Ces chiffres montrent que, dans les combinaisons observées, l’appelant distinguait difficilement le choix comme différence de qualité au démarrage. Ils ne constituent pas un benchmark universel.

Le tableau ne donne pas le nombre d’échantillons, les distributions, les percentiles, le dénominateur des échecs, l’état des caches ni le chemin précis de chaque appel terminé. 200 OK n’atteste ni la qualité du média, ni la facturation, ni la conversation achevée, ni l’autorité sur le numéro.

Un appel ENUM rapide et un repli PSTN rapide peuvent produire la même moyenne. La mesure est utile pour la perception ; elle ne prouve pas l’origine de la route.

Une erreur partagée n’avait pas de réparateur évident

Le RFC 5346 souligne un problème d’attribution. Si les données ENUM sont mal provisionnées, l’erreur se manifeste dans le réseau de l’opérateur qui place l’appel. Celui-ci ne sait pas toujours quel opérateur dessert désormais le numéro ni qui peut corriger l’enregistrement. La portabilité aggrave l’incertitude.

Le résolveur peut renvoyer fidèlement une donnée fausse. Le softswitch peut l’interpréter conformément aux règles. L’incident peut apparaître chez un tiers. Aucun de ces événements n’identifie le détenteur de l’autorité de réparation.

Le journal d’incident doit relier la version provisionnée, le canal EPP, la mise à jour DNS, le statut de portabilité, l’opérateur de service allégué, la vue du résolveur, la route choisie et un contact responsable. Sans cette chaîne, la mutualisation accélère la distribution de la donnée mais pas celle de la responsabilité.

Le répertoire public avait un coût de confidentialité

Le système 2.8.e164.arpa de l’essai était accessible par l’Internet public. Les opérateurs se demandaient si cette exposition était réaliste et craignaient la divulgation des numéros. Certains préféraient un accès privé.

Le résolveur constituait également une cible. Un attaquant capable de le compromettre pouvait imposer des échecs ou des retards. Le document recommande d’autoriser l’accès depuis le réseau local du softswitch et de restreindre l’extérieur.

Un accès privé ne garantit pas la justesse des données. Une réponse publique ne crée pas un droit d’interconnexion. Le choix modifie les personnes capables d’observer, d’interroger, d’attaquer et d’auditer le système ; il doit rester distinct de la validité de l’enregistrement et du résultat de l’appel.

Une expérience historique, pas une promesse actuelle

Le RFC 5346 est informatif. Il rapporte un essai de 2006 et ne spécifie aucune norme Internet. Le RFC 6116 a ensuite remplacé le RFC 3761. Rien dans le paquet de preuves n’établit un déploiement actuel, une part de marché, un incident réel ou le comportement d’un produit nommé.

L’expérience demeure précieuse parce qu’elle décrit la transition sans masquer l’ancien réseau. Elle montre qu’un système peut maintenir le service tout en changeant d’autorité de route. Cette continuité n’est honnête que si l’observabilité conserve le moment exact de la bascule.