Network Working Group J

Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" pour connaître l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Le présent document définit cinq paramètres dans l’identifiant de ressource universel (URI, Uniform Resource Identifier) "tel" pour porter les informations relatives à la portabilité du numéro (NP, number portability). Ces paramètres peuvent être passés au nœud de réseau du prochain bond après qu’une interrogation de recherche dans une base de données de NP a été effectuée.

Table des Matières

1. Introduction 1

2. Conventions 2

3. Abréviations 2

4. Syntaxe formelle 2

5. Règles normatives 3

5.1 Traitement de l’URI "tel" avec un ou des paramètres NP 4

5.2 Ajout d’un ou de paramètres de NP à l’URI "tel" 5

6. Exemples 7

7. Considérations pour la sécurité 7

8. Remerciements 8

9. Considérations relatives à l’IANA 8

10. Références 8

10.1 Références normatives 8

10.2 Références pour information 8

La portabilité du numéro (NP, Number portability) [RFC3482] permet aux abonnés téléphoniques de conserver leur numéro de téléphone lorsque ils changent de fournisseur de service (portabilité du fournisseur de service) qu’il se déplacent dans une nouvelle localisation (portabilité de localisation) ou qu’ils changent d’abonnement de service (portabilité de service). Les numéros de téléphone peuvent être des numéros de téléphone géographiques, des numéros de téléphone mobile, des numéros de libre appel, ou d’autres types de numéros de téléphone non géographiques. Certains numéros de téléphone mobile sont comme des numéros de téléphone géographiques (par exemple, ceux d’Amérique du Nord) et d’autres sont de nature non géographique mais leur acheminement est similaire à l’acheminement des numéros de téléphone géographiques de sorte qu’ils ne sont pas mentionnés spécifiquement dans le présent document. Les numéros de libre appel sont aussi appelés des numéros verts. L’appelé auquel est alloué le numéro de libre appel paye les charges de l’appel lorsque l’appelant compose le numéro de libre appel.

La NP impacte la signalisation et l’acheminement d’appel. Un impact est le besoin de porter les informations qui se rapportent à la NP dans l’identifiant de ressource universel (URI, Uniform Resource Identifier) "tel" [RFC3966] pour des protocoles comme le protocole d’initialisation de session (SIP, Session Initiation Protocol) [RFC3261] et H.323 [H323] après que la recherche dans la base de données de NP a été effectuée. Un autre impact est sur un serveur de voix sur IP (VoIP, Voice over IP) pour utiliser les informations relatives à la NP dans un URI "tel" reçu pour déterminer l’acheminement.

Un numéro d’acheminement est associé à un numéro de téléphone géographique ou mobile qui a été transporté d’un transporteur donneur à un autre transporteur. Un transporteur donneur est le transporteur initial lorsque un numéro de téléphone géographique était alloué avant d’avoir été porté. Un numéro de téléphone "non porté" géographique ou mobile n’a pas de numéro d’acheminement associé parce que les N premiers chiffres du numéro de téléphone géographique ou mobile peuvent être utilisés pour l’acheminement. Un numéro d’acheminement peut être utilisé pour indiquer le commutateur ou le nœud de réseau qui génère un appel ou un service similaire au paramètre d’information de juridiction dans le système de signalisation numéro 7 (SS7) du sous système utilisateur du réseau numérique à intégration de services (ISUP, Integrated Services Digital Network User Part). Le paramètre "rn" porte les informations du numéro d’acheminement. Le paramètre "rn-context" décrit comment la valeur du paramètre "rn" devrait être interprétée lorsque la valeur n’est pas un "global-rn" comme on l’expose à la Section 4.

L’indicateur de recherche de base de données de NP est utilisé pour informer les serveurs ou les commutateurs vers l’aval durant l’établissement d’un appel qu’il n’y a pas besoin d’effectuer à nouveau la recherche dans la base de données de NP pour un numéro de téléphone géographique. Le paramètre "npdi" porte un tel indicateur.

Un code d’identifiant de transporteur (CIC, Carrier Identification Code) identifie le fournisseur de service de libre appel actuel pour un numéro de libre appel. Ce paramètre peut aussi être utilisé pour porter les informations de transporteur pré-souscrit ou longue distance numéroté ; cependant, ceci sort du domaine d’application du présent document. Le paramètre "cic" porte les informations de CIC. Le paramètre "cic-context" décrit comment la valeur du paramètre "cic" devrait être interprétée lorsque la valeur n’est pas un "global-cic" comme on l’expose à la Section 4.

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans la [RFC2119].

ANSI (American National Standards Institute) Institut national américain de normalisation

CIC (Carrier Identification Code) (aussi cic) code d’identification du transporteur

CIP (Carrier Identification Parameter) paramètre d’identification du transporteur

GSTN (Global Switched Telephone Network) réseau téléphonique commuté mondial

ISUP (Integrated Services Digital Network User Part) sous-système utilisateur du réseau numérique à intégration de service

JIP (Jurisdiction Information Parameter) paramètre Information de juridiction

NPDB (Number Portability Database) base de données de portabilité de numéro

npdi (NP Database Dip Indicator) indicateur d’interrogation de base de données de portabilité de numéro

PNTI (Ported Number Translation Indicator) indicateur de traduction de numéro porté

La spécification de syntaxe suivante utilise la forme Backus-Naur augmentée (ABNF) décrite dans la [RFC4234] et définit les cinq paramètres, rn, npdi, cic, rn-context et cic-context, en étendant la règle de production de "parameter" de l’URI "tel" définie dans la [RFC3966].

Les paramètres "rn", "npdi", ou "cic" peuvent chacun apparaître au plus une fois dans l’URI "tel".

La première valeur "hex-phonedigit" dans "local-rn" ou "local-cic" DOIT être un nombre hexadécimal.

Pour un "global-rn", les informations de numéro d’acheminement après le "+" DOIVENT commencer par un code de pays [E.164] valide. Le nombre hexadécimal est permis après le code de pays dans le "global-rn".

Pour un "local-rn", le numéro d’acheminement dans le paramètre "rn" DOIT être interprété selon le "rn-context". Par exemple, si un numéro d’acheminement national est dans le paramètre "rn", le "rn-context" DOIT contenir un code de pays E.164 valide après le "+" si il est dans le format "global-hex-digits". Un nombre hexadécimal est permis dans le "local-rn".

Pour un "global-cic", les information de CIC après le "+" DOIVENT commencer par un code de pays E.164 valide.

Pour un "local-cic", la valeur de CIC dans le paramètre "cic" DOIT être interprétée selon le "cic-context". Par exemple, si la valeur du CIC national est dans le paramètre "cic", le "cic-context" DOIT contenir un code de pays E.164 valide après le "+" si il est dans le format "global-hex-digits".

Il y a deux utilisations distinctes pour l’URI "tel". Dans l’une, l’URI "tel" apparaît dans un élément de contenu statique. Par exemple, il pourrait apparaître dans une page de langage de balisage Hypertexte (HTML) ou un document de présence. Dans l’autre utilisation, l’URI "tel" apparaît dans des protocoles de signalisation d’appel, tels que SIP et H.323, où il est utilisé pour guider l’acheminement des messages d’établissement d’appel. Les extension à l’URI "tel" définies dans le présent document sont ciblées sur les protocoles de signalisation d’appel. Lorsque un URI "tel" est placé dans un contenu statique, les paramètres définis ici NE DEVRAIENT PAS être présents, et toute entité qui les reçoit DEVRAIT les retirer avant d’utiliser l’URI tel.

Dans le contexte des protocoles de signalisation, ces paramètres sont destinés à être utilisés entre les entités de signalisation d’appel, les nœuds du réseau de l’appelé, entre lesquels il y a une relation de confiance. Comme les paramètres insérés par un nœud du réseau peuvent avoir un impact sur l’acheminement d’une demande chez un nœud en aval, le traitement de ces paramètres dépend de la confiance que l’élément amont a suivi correctement les règles définies ici. Un protocole de signalisation d’appel peut vérifier qu’un élément en amont fait partie de son cercle de confiance par les mécanismes d’intégrité bond par bond. Voir plus d’informations à la Section 7, "Considérations sur la sécurité". Si un nœud de réseau reçoit un message de signalisation d’appel d’un élément auquel il ne se fie pas, il DEVRAIT ignorer les paramètres.

Cette section expose comment un nœud de réseau traite un URI "tel" reçu qui contient un ou plusieurs des paramètres définis dans ce document ou a accédé à une base de données de NP pour un numéro de libre appel ou un numéro de téléphone géographique et a besoin d’ajouter à un URI "tel" certains des paramètres définis dans le présent document.

Dans les pays où il n’y a pas de portabilité des numéros de libre appel ou de portabilité des numéros de téléphone géographiques, l’acheminement de l’appel peut se fonder sur les chiffres de tête du numéro de libre appel ou du numéro de téléphone géographique. Le présent document ne décrit pas ces scénarios.

Prière de noter que deux accès aux bases de données de libre appel sont normalement faits pour acheminer un appel à un numéro en libre appel. Le premier est fait pas le réseau d’origine qui interroge une base de données de libre appel pour les informations de CIC afin que l’appel puisse être acheminé au fournisseur de service de libre appel qui dessert le numéro de libre appel demandé. Lorsque l’appel atteint le fournisseur du service de libre appel, le second accès à la base de données est effectué pour transposer le numéro de libre appel en un numéro de téléphone géographique et/ou en informations d’acheminement internes. Le présent document ne traite pas le cas où des informations d’acheminement internes sont retournées.

La première base de données de libre appel contient les informations de CIC pour tous les numéros de libre appel actifs, tandis que la seconde ne contient que les informations de transposition pour les numéros de libre appel desservis par un fournisseur de service de libre appel. Comme le transporteur d’origine peut fournir un service de libre appel, sa base de données de libre appel va contenir les informations de CIC pour tous les numéros de libre appel actifs plus les informations de transposition pour les numéros de libre appel qu’il dessert. Le présent document se réfère aux deux accès de base de données sous les noms de "premier accès de base de données de libre appel" et de "second accès de base de données de libre appel".

Lorsque on traite les paramètres "rn" et "cic" et les numéros de téléphone dans l’URI "tel" pour des besoins tels que l’accès à une base de données et l’acheminement, les séparateurs visuels qu’ils contiennent sont retirés avant d’utiliser les informations qui sont dedans.

Lorsque un nœud de réseau traite un URI "tel" qui contient des informations de "rn" ou "cic" invalides, il peut libérer l’appel ou éliminer le paramètre invalide et accéder à la base de données de NP ou de libre appel appropriée pour voir si il peut restituer un numéro d’acheminement valide pour un numéro de téléphone géographique ou un CIC valide pour le numéro de libre appel.

Lorsque un URI "tel" est reçu d’une source qui n’est pas de confiance, un nœud de réseau PEUT refaire l’interrogation NPDB.

SIP [RFC3261] a mis en place des mécanismes pour détecter les boucles d’acheminement dues à la réécriture d’URI, et les nouveaux paramètres ajoutés ici fonctionnement dans ces contextes établis. Le paramètre "npdi" dans l’URI qui indique qu’une interrogation de NPDB a déjà été faite peut aussi empêcher les boucles d’acheminement. Les autres protocoles qui envisageraient d’utiliser ces paramètres d’URI "tel" DEVRAIENT s’assurer qu’ils disposent de mécanismes pour détecter les boucles lors de la réécriture de l’URI "tel".

Si l’URI "tel" contient le paramètre "npdi", le nœud du réseau NE DOIT PAS restituer les informations relatives à la NP pour les numéros de téléphone géographiques même si il est réglé à le faire.

Si l’URI "tel" contient le paramètre "cic" dont la valeur de CIC est différente de celle à laquelle est associé ce nœud de réseau, celui-ci NE DOIT PAS restituer les informations relatives à la NP pour le numéro de téléphone géographique ou effectuer le premier accès à la base de données de libre appel pour le numéro de libre appel dans l’URI "tel".

Pour les paramètres "cic" et "rn" et un numéro, soit de libre appel, soit de téléphone géographique, l’ordre de traitement est de chercher d’abord le paramètre "cic" pour l’acheminement de l’appel. Si les informations de CIC ne sont pas utiles ou si le paramètre "cic" n’existe pas, l’étape suivante est alors de chercher le paramètre "rn". Si les informations dans le paramètre "rn" ne sont pas utiles ou si le paramètre "rn" n’existe pas, on utilise alors le numéro de libre appel ou le numéro de téléphone géographique.

Si le nœud de réseau ne sait pas comment acheminer sur la base du paramètre "cic" ou "rn", les politiques locales DOIVENT décider si il faut arrêter ou continuer le traitement de l’appel en ignorant les informations invalides/inconnues.

Lorsque on cherche le paramètre "cic" et que ce paramètre existe dans l’URI "tel" :

- Le nœud de réseau DOIT ignorer le paramètre "cic" si le CIC identifie un transporteur ou un fournisseur de service associé à ce nœud et chercher le paramètre "rn" pour prendre la décision d’acheminement. Il DOIT retirer le paramètre "cic" lorsque il achemine l’appel au nœud de réseau du prochain bond qui appartient à un autre transporteur ou fournisseur de service.

- Le nœud de réseau DOIT invoquer un processus de traitement spécial si le paramètre "cic" contient un code qui exige un tel traitement. Par exemple, une valeur de CIC de "0110" dans la réponse à une interrogation de base de données de libre appel en Amérique du Nord indique "Numéro de téléphone géographique fourni traduit local". Dans cet exemple particulier, le paramètre "cic" est ignoré. Prière de noter que cette valeur particulière de CIC de "+1-0110" ne va normalement pas apparaître dans le message d’établissement d’appel. Il est donné comme exemple pour montrer que de telles valeur de CIC spéciales peuvent exister. Les valeurs de code exactes et leur traitement sortent du domaine d’application du présent document.

- Autrement, le nœud du réseau DOIT prendre la décision d’acheminement sur la base du CIC. Le nœud du réseau NE DOIT PAS retirer le paramètre "cic" sauf si il passe l’appel au transporteur ou fournisseur de service identifié par le CIC et si la politique locale exige de lui qu’il retire le paramètre "cic". Comment l’appel est en fait acheminé sur la base de la valeur du CIC dans le paramètre "cic" sort du domaine d’application du présent document.

Lorsque il cherche le paramètre "rn" et que ce paramètre existe dans l’URI "tel" :

- Si le numéro d’acheminement dans le paramètre "rn" pointe sur ce nœud de réseau (par exemple, l’appel a atteint le nœud de réseau prévu) ce nœud de réseau DOIT chercher le numéro de libre appel ou le numéro de téléphone géographique pour prendre la décision d’acheminement. Il DOIT retirer le paramètre "rn" lorsque il établit l’appel au nœud de réseau du prochain bond sans considérer si celui-ci est dans le même réseau ou dans un réseau différent.

- Si le numéro d’acheminement dans le paramètre "rn" pointe sur un réseau dans lequel est ce nœud de réseau (par exemple, dans certains pays, le numéro d’acheminement amène l’appel au réseau du transporteur desservant où un autre accès à la base de données de NP est nécessaire pour localiser le commutateur de desserte) ce nœud de réseau DOIT chercher le numéro de libre appel ou le numéro de téléphone géographique pour prendre la décision d’acheminement. Le nœud de réseau PEUT accéder à la base de données de NP pour avoir les informations d’acheminement si il est configuré pour ce faire. Il DOIT retirer le paramètre "rn" si le nœud de réseau du prochain bond appartient à un autre transporteur ou fournisseur de service.

- Autrement, le nœud de réseau DOIT prendre la décision d’acheminement sur la base du numéro d’acheminement qui est dans le paramètre "rn". Comment l’appel est réellement acheminé sur la base du numéro d’acheminement dans le paramètre "rn" sort du domaine d’application du présent document.

Lorsque le paramètre "cic" ou "rn" n’est pas utilisé pour l’acheminement, le nœud de réseau utilise le numéro de libre appel ou le numéro de téléphone géographique pour prendre les décisions d’acheminement. Il peut accéder à la base de données de NP si il est configuré pour le faire, ou il peut acheminer l’appel à un nœud de réseau désigné qui va accéder à la base de données de NP, ou il peut acheminer l’appel sur la base du tableau d’acheminement local. La façon dont l’appel est traité à ce stade sort du domaine d’application du présent document. Voir au paragraphe 5.2 les règles pour ajouter le ou les paramètre définis dans le présent document à l’URI "tel" si le nœud de réseau est configuré pour accéder à la base de données de NP.

Il y a deux cas pour l’accès à la base de données de NP. L’un est pour un numéro de téléphone géographique, et l’autre est pour un numéro de libre appel. Ils sont exposés dans les paragraphes 5.2.1 et 5.2.2 pour un URI "tel" utilisé pour l’acheminement.

Le paragraphe 5.2.3 discute d’un cas particulier où le paramètre "rn" est ajouté à un URI "tel" qui est associé au premier nœud de réseau qui traite la demande d’appel provenant de l’appelant. Le paragraphe 5.2.4 discute de l’ajout d’un ou de paramètres à l’URI "tel" défini dans le présent document à cause d’une conversion de protocole.

5.2.1 Restitution des informations de NP pour un numéro de téléphone géographique

Lorsque un nœud de réseau accède à une base de données de NP pour un numéro de téléphone géographique :

- si le nœud de réseau restitue un numéro d’acheminement, il DOIT ajouter le paramètre "rn" à l’URI "tel" pour porter les informations de numéro d’acheminement dans le format "global-rn" ou "local-rn". Il DOIT aussi ajouter le paramètre "npdi" ;

- si le nœud de réseau ne restitue pas un numéro d’acheminement (par exemple, pour un numéro de téléphone géographique non porté) il DOIT ajouter le paramètre "npdi" à l’URI "tel".

Le nœud de réseau DOIT suivre les règles décrites au paragraphe 5.1 pour utiliser les informations de l’URI "tel" pour prendre la décision d’acheminement.

Lorsque un nœud de réseau effectue le premier ou le second accès à une base de données de libre appel pour un numéro de libre appel :

- Si le nœud de réseau restitue un CIC qui identifie un transporteur ou fournisseur de service associé à ce nœud de réseau, ou indique qu’un numéro géographique est fourni (par exemple, "+1-0110" signifie "le numéro de téléphone géographique fourni est local, traduit") il devra restituer un numéro de téléphone géographique. Le nœud de réseau NE DOIT PAS ajouter de paramètre "cic" et DOIT remplacer le numéro de libre appel dans l’URI "tel" par le numéro de téléphone géographique restitué dans le format "numéro mondial" ou "numéro local".

Certaines bases de données de libre appel peuvent ne pas retourner le numéro de téléphone géographique mais des informations d’acheminement internes dans un format propriétaire (par exemple, un identifiant de commutateur et un identifiant de groupe de circuits). Ce cas sort du domaine d’application du présent document.

- Si le nœud de réseau restitue un CIC qui appartient à un autre fournisseur de service de libre appel, le nœud de réseau DOIT ajouter le paramètre "cic" à l’URI "tel" qui contient le CIC dans le format "global-cic" ou "local-cic". Le transporteur d’origine peut avoir des accords commerciaux avec un fournisseur de service de libre appel pour retourner le numéro de téléphone géographique en plus du CIC. Lorsque un numéro de téléphone géographique est retourné, le nœud de réseau DOIT remplacer le numéro de libre appel dans l’URI "tel" par le numéro de téléphone géographique retourné dans le format "numéro mondial" ou "numéro local".

- Si le nœud de réseau restitue un numéro de téléphone géographique (qui est le cas normal pour le second accès de base de données de libre appel) le nœud de réseau DOIT remplacer le numéro de libre appel dans l’URI "tel" par le numéro de téléphone géographique restitué dans le format "numéro mondial" ou "numéro local". Lorsque un numéro de téléphone géographique est retourné dans la réponse, il est possible que les informations de NP pour ce numéro de téléphone géographique soient aussi retournées. Dans ce cas, le nœud de réseau DOIT ajouter le paramètre "npdi" et DOIT ajouter le paramètre "rn" pour qu’il ne contienne le numéro d’acheminement dans le format "global-rn" ou "local-rn" que lorsque le numéro d’acheminement est disponible.

Le nœud de réseau DOIT suivre les règles décrites au paragraphe 5.1 pour utiliser les informations de l’URI "tel" afin de prendre la décision d’acheminement.

Dans le SS7 ISUP, le JIP identifie le commutateur qui a généré l’appel, et ces informations peuvent être utilisées par le transporteur desservant pour déterminer les charges de l’appel pour l’appelant ou par les transporteurs impliqués pour déterminer le montant des règlements à effectuer entre eux.

Un nœud de réseau qui est le premier à traiter la demande d’appel provenant de l’appelant PEUT inclure le paramètre "rn" avec l’URI "tel" associé à l’appelant, si il en existe un. Par exemple, si le nœud de réseau est une passerelle du réseau téléphonique commuté mondial (GSTN) qui reçoit un message ISUP contenant le JIP, les informations de localisation correctes dans le JIP peuvent être placées dans le paramètre "rn" de l’URI "tel" qui est associé à l’appelant.

Noter que les informations du paramètre "rn" ne peuvent pas être authentifiées ; donc, l’utilisation des informations par le receveur de l’URI "tel" pour tout ce qui se rapporte à la tarification présente un risque.

Une passerelle du GSTN a besoin de convertir le SS7 ISUP et le protocole VoIP comme SIP ou H.323. Ce type de nœud de réseau DOIT transposer les paramètres ISUP correspondants en les paramètres définis dans le présent document associés à l’URI "tel" pour l’acheminement et PEUT transposer les paramètres ISUP correspondants en paramètres définis dans le présent document qui sont dans l’URI "tel" associé à l’appelant.

Comme la prise en charge de la NP par l’ISUP dépend de chaque pays, la discussion qui suit s’applique à une situation où un nœud de réseau va transposer les informations de NP dans l’ISUP de l’ANSI et les paramètres en rapport avec la NP dans l’URI "tel".

Pour un numéro de téléphone géographique déporté, le nœud de réseau DOIT convertir le numéro d’acheminement dans le paramètre ISUP Numéro de l’appelant en un numéro d’acheminement en format soit "global-rn" soit "local-rn" et le porter dans le paramètre "rn" pour un URI "tel" qui est utilisé pour l’acheminement. Le nœud de réseau DOIT convertir le numéro de téléphone qui est marqué comme "numéro porté" dans le paramètre ISUP Adresse générique (GAP) en un numéro de téléphone en format "numéro mondial" ou "numéro local" [RFC3966] et le mettre dans la partie "chiffres du numéro mondial" ou "chiffres du numéro local" (voir la [RFC3966]) de l’URI "tel" qui est utilisé pour l’acheminement.

Pour un numéro de téléphone géographique non déporté, le nœud de réseau DOIT convertir le numéro de téléphone en paramètre ISUP Numéro de l’appelant en format de "numéro mondial" ou de "numéro local" et le mettre dans la partie chiffres de numéro mondial ou chiffres de numéro local (voir la [RFC3966]) de l’URI "tel" qui est utilisé pour l’acheminement. Le paramètre "rn" NE DOIT PAS apparaître dans l’URI "tel" sauf si les politiques locales exigent que le nœud de réseau l’inclue. Il sort du domaine d’application du présent document de définir comment inclure le paramètre "rn" si les politiques locales exigent que le nœud de réseau fasse ainsi.

Le nœud de réseau DOIT inclure le paramètre "npdi" dans l’URI "tel" qui est utilisé pour l’acheminement lorsque le bit Indicateur de traduction de numéro porté (PNTI, Ported Number Translation Indicator) dans le paramètre Indicateur de transmission d’appel (FCI, Forward Call Indicator) est réglé à "1".

Le nœud de réseau DOIT inclure le paramètre "cic" dans le format "global-cic" ou "local-cic" dans l’URI "tel" qui est utilisé pour l’acheminement lorsque le paramètre ISUP Identification du transporteur (CIP) est présent.

Le nœud de réseau PEUT inclure le paramètre "rn" dans l’URI "tel" associé aux informations sur l’appelant lorsque le JIP ISUP est présent. Cela peut être soumis à la politique locale du nœud de réseau et/ou au protocole de signalisation qui porte l’URI "tel".

La transposition des paramètres relatifs à la NP d’un URI "tel" en informations relatives à la NP dans le message ISUP dépend de la mise en œuvre nationale de l’ISUP et sort du domaine d’application du présent document.

A. Un URI "tel", tel:+1-800-123-4567, contient un numéro de libre appel "+1-800-123-4567". En supposant que ce numéro de libre appel est desservi par un fournisseur de service de libre appel avec un CIC "+1-6789". Après restitution des informations relatives à la NP, l’URI "tel" serait réglé à tel:+1-800-123-4567;cic=+1-6789

B. Un URI "tel", tel:+1-800-123-4567;cic=+1-6789, est traité par un nœud de réseau dans le réseau du fournisseur de service de libre appel de desserte. En supposant que le numéro de libre appel est transposé en un numéro de téléphone géographique "+1-202-533-1234". Après restitution des informations relatives à la NP, l’URI "tel" serait réglé à tel:+1-202-533-1234

C. Un URI "tel", tel:+1-202-533-1234, contient un numéro de téléphone géographique "+1-202-533-1234". En supposant que ce numéro de téléphone géographique est déporté et est associé à un numéro d’acheminement "1-202-544-0000". Après restitution des informations relatives à la NP, l’URI "tel" serait réglé à tel:+1-202-533-1234;npdi;rn=+1-202-544-0000

D. Un URI "tel", tel:+1-202-533-6789, contient un numéro de téléphone géographique "+1-202-533-6789". En supposant que ce numéro de téléphone géographique n’est pas déporté. Après l’accès à la base de données de NP, l’URI "tel" serait réglé à tel:+1-202-533-6789;npdi

E. Un URI "tel", tel:+1-202-533-1234;npdi;rn=+1-202-000-0000, contient un numéro d’acheminement invalide (par exemple, pas d’informations d’acheminement sur "+1-202-000-0000") ; le nœud de réseau peut abandonner le paramètre "rn" et accéder de nouveau à la base de données de NP.

F. Un URI "tel", tel:+1-800-123-456, contient un numéro de libre appel "+1-800-123-456" qui est trop court d’un chiffre. Lors de l’accès à la base de données de libre appel, il n’y aura pas d’informations de "cic" pour ce numéro de libre appel. L’appel sera libéré.

G. Un URI "tel", tel:+1-800-123-4567;cic=+1-56789, est traité par un nœud de réseau dans un réseau d’origine ou de transit. Les informations de "cic" sont invalides. Le nœud de réseau peut abandonner le paramètre "cic" et accéder à nouveau à la base de données de libre appel. Si les mêmes mauvaises informations de CIC sont reçues, le nœud de réseau va libérer l’appel parce que il ne sait pas comment acheminer l’appel avec un CIC invalide. Si des informations valides sont reçues, le nœud de réseau va utiliser le CIC reçu dans le "cic" et acheminer l’appel sur la base du "cic".

En plus des implications pour la sécurité discutées dans l’URI "tel" révisé [RFC3966], il y a de nouvelles implications de sécurité qui sont associées aux paramètres définis dans le présent document.

Si la valeur de "rn" ou "cic" dans l’URI "tel" est changée illégalement lorsque le message de signalisation portant l’URI "tel" est en route pour l’entité de destination, le message de signalisation ou l’appel peut être acheminé au mauvais réseau ou nœud de réseau causant le rejet de l’établissement d’appel.

Si le "npdi" est illégalement inséré dans l’URI "tel" lorsque le message de signalisation portant l’URI "tel" est en route pour l’entité de destination, l’appel peut être acheminé au mauvais réseau ou nœud de réseau, causant le rejet de l’établissement de l’appel. C’est un moindre problème si le "npdi" est illégalement retiré. Une interrogation supplémentaire de NPDB peut être effectuée pour restituer les informations de numéro d’acheminement et avoir le "npdi" inclus à nouveau.

Si le "rn" dans l’URI "tel" qui est associé à l’appelant est illégalement changé ou inséré, les taxes de l’appel fondées sur ce "rn" seront incorrectes.

À cause de ces considérations, ces extensions d’URI "tel" ne sont applicables qu’au sein d’un ensemble de nœuds de réseau entre lesquels existe une confiance mutuelle. Si un nœud reçoit une demande de signalisation d’appel provenant d’un nœud en amont qui n’est pas de confiance, il DEVRAIT retirer ces paramètres. Cela va généralement l’obliger à refaire les interrogations de base de données.

Pour vérifier qu’un voisin en amont est de confiance, et pour empêcher les attaques par interposition par lesquelles un agresseur insère ou modifie ces paramètres, les protocoles de signalisation d’appel qui portent ces paramètres DEVRAIENT assurer l’intégrité de message bond par bond. Dans le cas de SIP, cela se fait avec le mécanisme d’URI sécurisation du protocole d’initialisation de session (SIPS, Session Initiation Protocol Secure).

L’auteur souhaite remercier Penn Pfautz, Jon Peterson, Jonathan Rosenberg, Henning Schulzrinne, Antti Vaha-Sipila, Flemming Andreasen, et Mike Hammer de leurs discussions et commentaires.

Le présent document définit cinq paramètres pour l’URI "tel". Plus d’informations sur le registre de ces paramètres sont couvertes par la [RRC5341]. Le présent document ne requiert aucune action de l’IANA.

[E.164] Recommendation UIT-T E.164, "Plan de numérotage des télécommunications publiques internationales", mai 1997.

[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

[H.323] Recommendation UIT-T H.323, "Systèmes de communication multimédia fondés sur le paquet", novembre 2000.

[RFC5341] C. Jennings, V. Gurbani, "Registre des paramètres d'identifiant de ressource uniforme (URI) de l'IANA", septembre 2008. (MàJ RFC3966) (P.S.)

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org , et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations qui y sont contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est) la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP 78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur le répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr.

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf- ipr@ietf.org.

Le financement de la fonction d’édition des RFC est fourni par l’activité de soutien administratif (IASA) de l’IETF

Groupe de travail Réseau	J. Yu, NeuStar
Request for Comments : 4694	octobre 2006
Catégorie : En cours de normalisation	Traduction Claude Brière de L’Isle