RFC2871 page - 2 - Rosenberg & Schulzrinne

Groupe de travail Réseau

J. Rosenberg, dynamicsoft

Request for Comments : 2871

H. Schulzrinne, Columbia University

Catégorie : Information

juin 2000

Traduction Claude Brière de L’Isle




Cadre pour l’acheminement de la téléphonie sur IP


Statut de ce mémoire

Le présent mémoire apporte des informations pour la communauté de l’Internet. Il ne spécifie aucune sorte de norme de l’Internet. La distribution du présent mémoire n’est soumise à aucune restriction.


Notice de copyright

Copyright (C) The Internet Society (2000). Tous droits réservés.


Résumé

Le présent document sert de cadre pour l’acheminement téléphonique sur IP (TRIP, Telephony Routing over IP) qui prend en charge la découverte et l’échange des tableaux d’acheminement des passerelles de téléphonie IP entre les fournisseurs. Le document définit le problème de l’échange d’acheminement de téléphonie, et motive le besoin du protocole. Il présente un cadre architectural pour TRIP, définit la terminologie, spécifie les divers éléments du protocole et leurs fonctions, donne une vue générale des services fournis par le protocole, et expose comment il s’adapte au contexte plus large de la téléphonie Internet.


Table des matières

1. Introduction 1

2. Terminologie 2

3. Motivation et définition du problème 3

4. Problèmes connexes 4

5. Relations avec BGP 5

6. Exemple d’applications de TRIP 5

6.1 Chambres de compensation 5

6.2 Confédérations 6

6.3 Grossiste en passerelles 6

7. Architecture 6

8. Éléments 7

8.1 Domaine administratif IT 7

8.2 Passerelle 8

8.3 Utilisateur final 8

8.4 Serveur de localisation 9

9. Interactions des éléments 9

9.1 Passerelles et serveurs de localisation 9

9.2 Serveur de localisation à serveur de localisation 10

10. La devanture 11

10.1 Utilisateurs de la devanture 11

10.2 Protocoles de la devanture 12

11. Traduction des numéros 13

12. Considérations pour la sécurité 13

13. Remerciements 14

14. Bibliographie 14

15. Adresse des auteurs 14

16. Déclaration complète de droits de reproduction 14


1. Introduction

Le présent document sert de cadre à l’acheminement de la téléphonie sur IP (TRIP, Telephony Routing over IP) qui prend en charge la découverte et l’échange des tableaux d’acheminement de routeur de téléphonie IP entre les fournisseurs. Le document définit les problèmes d’échange d’acheminement téléphonique, et motive le besoin du protocole. Il présente un cadre architectural pour TRIP, définit la terminologie, spécifie les divers éléments du protocole et leurs fonctions, une vue générale des services fournis par le protocole, et expose comment il s’intègre dans le contexte plus large de la téléphonie Internet.

2. Terminologie


On définit les termes qui suivent. Noter qu’il y a d’autres définitions pour ces termes, en dehors du contexte de la localisation de passerelle. Nos définitions ne sont pas générales, mais se réfèrent à la signification spécifique du contexte :


Passerelle : Appareil qui possède une qualité de connexité de réseau à commutation de circuits et de connexité IP, capable d’initier et de terminer les protocoles de signalisation de téléphonie IP, et capable d’initier et de terminer des protocoles de signalisation de téléphonie de réseau.


Utilisateur final : C’est généralement (mais pas nécessairement) un humain, qui est la partie qui est l’initiateur ou receveur ultime des appels.


Appareil appelant : C’est une entité physique qui a la connexité IP. Il est sous la direction d’un utilisateur final qui souhaite passer un appel. L’utilisateur final peut ou non contrôler directement l’appareil appelant. Si l’appareil appelant est un PC, l’utilisateur final le contrôle directement. Cependant, si l’appareil appelant est une passerelle de téléphonie, l’utilisateur final peut y accéder par un téléphone.


Portier : C’est l’élément portier de la Recommandation H.323, défini dans [H.323].


Serveur SIP : Serveur mandataire ou de redirection du protocole d’initialisation de session défini dans la [RFC2543].


Agent d’appel : C’est l’agent d’appel MGCP, défini dans la [RFC2705].


GSTN : Réseau téléphonique commuté mondial (Global Switched Telephone Network), qui est le réseau mondial de circuits commutés.


Serveur de signalisation : Un serveur de signalisation est une entité qui est capable de recevoir et d’envoyer des messages de signalisation pour des protocoles de signalisation de téléphonie IP, tels que H.323 ou SIP. D’une façon générale, un serveur de signalisation est un portier, un serveur SIP ou un agent d’appel.


Serveur de localisation (LS, Location Server) : C’est une entité logique avec connexité IP qui a connaissance des passerelles qui peuvent être utilisées pour terminer les appels vers le GSTN. Le LS est la principale entité qui participe à l’acheminement téléphonique sur IP. Le LS est généralement un point de contact pour l’utilisateur final pour achever les appels au réseau téléphonique. Un LS peut aussi être chargé de la propagation des informations de passerelle vers d’autres LS. Un LS peut être corésident avec un portier H.323 ou un serveur SIP, mais ceci n’est pas obligé.


Domaine administratif de téléphonie Internet (ITAD, Internet Telephony Administrative Domain) : C’est l’ensemble des ressources (passerelles et serveurs de localisation) qui sont sous le contrôle d’une seule autorité administrative. L’utilisateur final est un client d’un ITAD.


Fournisseur : C’est l’administrateur d’un ITAD.


Politique de serveur de localisation : C’est l’ensemble des règles qui précisent comment un serveur de localisation traite les informations qu’il envoie et reçoit via TRIP. Cela inclut des règles pour l’agrégation, la propagation, la génération, et l’acceptation des informations.


Politique d’utilisateur final : Ce sont les préférences qu’a l’utilisateur final sur la façon dont un appel vers le GSTN devrait être acheminé.


Homologues : Deux LS sont des homologues lorsque ils ont une association persistante entre eux sur laquelle sont échangées les informations de passerelle.


Homologues internes : Ce sont des homologues qui résident tous deux au sein du même ITAD.


Homologues externes : Ce sont des homologues qui résident au sein d’ITAD différents.


Serveur de localisation d’origine : C’est un serveur de localisation qui génère le premier un chemin vers une passerelle dans son ITAD.


Base de données d’informations d’acheminement téléphonique (TRIB, Telephony Routing Information Base) : C’est la base de données des passerelles que construit un LS par suite de sa participation au TRIP.


3. Motivation et définition du problème


Avec la croissance en nombre et en utilisations de la téléphonie IP, la gestion de son fonctionnement devient de plus en plus complexe. Une des tâches difficiles est celle de la localisation de la passerelle, aussi appelée sélection de passerelle, sélection de chemin, découverte de passerelle, et acheminement de passerelle. Le problème survient lorsqu’un appareil d’appel (comme une passerelle de téléphonie ou un PC avec un logiciel de téléphonie IP) sur un réseau IP a besoin de mener à son terme un appel à un numéro de téléphone qui représente un terminal sur un réseau téléphonique à commutation de circuits. Comme la cible prévue pour l’appel réside sur un réseau à commutation de circuits, et que l’appelant initie l’appel à partir d’un hôte IP, une passerelle de téléphonie doit être utilisée. La passerelle fonctionne comme un point de conversion pour les supports et la signalisation, convertissant les protocoles utilisés sur le réseau IP en ceux utilisés dans le réseau à commutation de circuit, et vice-versa.


La passerelle est, par nature, un point de relais pour un protocole de signalisation de couche application. Il peut y avoir de nombreuses passerelles qui auraient éventuellement la possibilité de terminer l’appel à partir de l’appareil appelant sur le réseau IP de la partie appelée sur le réseau à commutation de circuits. Choisir une telle passerelle est un processus non trivial. Il est compliqué à cause des questions suivantes :


Nombre de passerelles candidates :

Il est prévu que la téléphonie IP devienne largement déployée, et que le nombre de passerelles téléphoniques qui connectent l’Internet au GSTN devienne important. Rattachement au GSTN signifie que la passerelle aura la connexité avec le presque milliard de terminaux accessibles sur ce réseau. Cela signifie que chaque passerelle pourrait théoriquement mener à bien un appel pour n’importe quel terminal sur le GSTN. À ce titre, le nombre de passerelles candidates pour mener à bien un appel peut être très important.


Relations d’affaires :

En réalité, le propriétaire d’une passerelle ne va vraisemblablement pas rendre la passerelle disponible à tout utilisateur qui souhaite se connecter à elle. La passerelle fournit un service utile, et supporte des coûts lorsque elle réalise des appels vers le réseau à commutation de circuits. Il en résulte que les fournisseurs de passerelles vont, dans la plupart des cas, souhaiter tarifer l’utilisation de ces passerelles. Cela peut restreindre l’usage de la passerelle à ceux des usagers qui auront, d’une certaine manière, une relation établie avec le fournisseur de la passerelle.


Politique de fournisseur :

Selon toute vraisemblance, un utilisateur final qui souhaite utiliser un service de passerelle ne va pas rémunérer directement le fournisseur de la passerelle. L’utilisateur final peut avoir une relation avec un fournisseur de service de téléphonie IP qui agit comme intermédiaire avec les fournisseurs de passerelles. Le fournisseur de service de téléphonie IP peut avoir aussi ses propres passerelles. Dans ce cas, le fournisseur de service de téléphonie IP peut avoir des politiques concernant l’usage de diverses passerelles d’autres fournisseurs par ses clients. Ces politiques doivent figurer dans le processus de sélection.


Politique d’utilisateur final :

Dans certains cas, l’utilisateur final peut avoir des exigences spécifiques concernant la sélection de passerelle. L’utilisateur final peut avoir besoin d’un dispositif spécifique, ou avoir une préférence pour un certain fournisseur. Cela doit aussi être pris en compte.


Capacité :

Toutes les passerelles ne sont pas sur un pied d’égalité. Certaines sont grandes, capables de prendre en charge des centaines ou même des milliers d’appels simultanés. D’autres, comme les passerelles résidentielles, ne peuvent prendre en charge qu’un ou deux appels. Le processus de sélection des passerelles devrait permettre que la capacité de la passerelle joue un rôle. Il est particulièrement souhaitable de prendre en charge une certaine forme d’équilibrage de charge entre les passerelles fondé sur leurs capacités.


Compatibilités de protocole de caractéristiques :

Les parties à l’appel peuvent utiliser un protocole de signalisation ou de support spécifique qui n’est pas accepté par toutes les passerelles.


À partir de ces questions, il devient évident que le choix d’une passerelle est conduit dans une large mesure par les politiques de diverses parties, et par les relations établies entre ces parties. À ce titre, il ne peut pas y avoir un "répertoire des passerelles" mondial dans lequel les utilisateurs rechercheraient les numéros de téléphone. Les informations sur la disponibilité des passerelles doivent plutôt être échangées entre les fournisseurs, et sous réserve des politiques, rendues disponibles localement et ensuite, propagées aux autres fournisseurs. Cela permet à chaque fournisseur de construire sa propre base de données locale des passerelles disponibles – de telles bases de données pouvant être très différentes pour chaque fournisseur en fonction de sa politique.


À partir de cela, on peut conclure qu’un protocole est nécessaire entre les domaines administratifs pour l’échange des informations d’acheminement sur les passerelles. Le protocole qui fournit ces fonctions est l’acheminement de la téléphonie sur IP (TRIP, Telephony Routing over IP). TRIP fournit un ensemble de fonctions spécifiques :

o établissement et maintenance de relations d’homologues entre fournisseurs ;

o échange et synchronisation des informations d’acheminement sur les passerelles de téléphonie entre fournisseurs ;

o prévention d’établissement de boucles d’acheminement stables pour les protocoles de signalisation de la téléphonie IP ;

o propagation des informations d’acheminement apprises sur les passerelles aux autres fournisseurs à temps et de façon adaptée ;

o définition de la syntaxe et de la sémantique des données qui décrivent les chemins des passerelles de téléphonie.


TRIP peut être résumé de façon générale comme un protocole d’acheminement inter domaine de passerelles de téléphonie IP.


4. Problèmes connexes


À haut niveau, le problème que résout TRIP apparaît comme un problème de transposition : étant donné un numéro de téléphone, déterminer, su la base de certains critères, l’adresse d’une passerelle de téléphonie. Pour cette raison, le problème de la localisation de la passerelle est souvent appelé un "problème de traduction de numéro de téléphone en adresse IP". C’est cependant une simplification abusive. Il y a au moins trois problèmes distincts, dont chacun peut être rangé dans la catégorie des "problèmes de traduction de numéro de téléphone en adresse IP", et un seul d’entre eux est traité par TRIP :

o Soit un numéro de téléphone qui correspond à un terminal sur un réseau à commutation de circuit, déterminer l’adresse IP d’une passerelle capable de mener à bien un appel à ce numéro de téléphone.

o Soit un numéro de téléphone qui correspond à un hôte spécifique sur l’Internet (cet hôte peut avoir un numéro de téléphone afin de faciliter les appels qui lui sont destinés en provenance du réseau à commutation de circuits) déterminer l’adresse IP de cet hôte.

o Soit un numéro de téléphonie qui correspond à l’utilisateur d’un terminal sur un réseau à commutation de circuits, déterminer l’adresse IP d’un terminal IP qui appartient au même usager.


La dernière de ces trois fonctions de transposition est utile pour les services où le micro ordinateur sert d’interface au téléphone. Un de ces services est la livraison d’un message instantané à un ordinateur lorsque le téléphone de l’usager sonne. Pour fournir ce service, un commutateur dans le GSTN achemine un appel vers un numéro de téléphonie. Il souhaite envoyer un message instantané à l’ordinateur pour cet usager. Ce commutateur doit d’une certaine façon avoir accès au réseau IP, afin de déterminer l’adresse IP de l’ordinateur correspondant à l’usager avec ce numéro de téléphone. La fonction de transposition est un problème de traduction de nom en adresse, où le nom se trouve être représenté par une chaîne de chiffres. Une telle fonction de traduction est mieux prise en charge par des protocoles de répertoires. Ce problème n’est pas traité par TRIP.


La seconde de ces transpositions est nécessaire pour faciliter les appels depuis des téléphones traditionnels vers des terminaux IP. Lorsque un utilisateur qui est sur le GSTN souhaite appeler un usager qui a un terminal sur le réseau IP, il doit faire un numéro qui identifie ce terminal. Ce numéro pourrait être une adresse IP. Cependant, les adresses IP sont souvent éphémères, allouées à la demande par DHCP [RFC2131] ou par des serveurs d’accès de réseau à numérotation qui utilisent PPP [RFC1661]. Le numéro pourrait être un nom d’hôte, obtenu par quelque traduction d’un groupe de numéros en lettres. Cependant, ceci serait étrange. Il a été proposé d’allouer à la place des numéros de téléphone aux terminaux de téléphonie IP. Un appelant sur le GSTN numéroterait alors ce numéro comme il le ferait de n’importe quel autre. Ce numéro servirait de nom de remplacement pour le terminal IP, de la même manière que son nom d’hôte sert de nom. Un commutateur dans le GSTN doit alors accéder au réseau IP, et obtenir la transposition de ce numéro en une adresse IP pour l’ordinateur. Comme dans le cas précédent, ce problème est un problème de traduction de nom en adresse, et est mieux traité par un protocole de répertoire. Il n’est pas traité par TRIP.


La première fonction de transposition est, cependant, fondamentalement un problème de traduction d’adresse en chemin. C’est ce problème qui est considéré par TRIP. Comme exposé à la Section 3, cette transposition dépend de facteurs locaux tels que les politiques et les relations de fournisseurs. Il en résulte que la base de données des passerelles disponibles est substantiellement différente pour chaque fournisseur, et doit être construite sur des relations inter-fournisseur spécifiques. C’est pour cette raison qu’un protocole de répertoire n’est pas approprié pour TRIP, tandis qu’il l’est pour les autres.


5. Relations avec BGP


TRIP peut être classé comme un proche cousin des protocoles d’acheminement inter-domaines IP, tels que BGP [RFC1771]. Cependant, il y a des différences importantes entre BGP et TRIP:

o TRIP fonctionne à la couche application, et non à la couche réseau, où réside BGP.

o TRIP fonctionne entre des serveurs qui peuvent être séparés par de nombreux réseaux intermédiaires et des fournisseurs de service IP. BGP fonctionne entre des routeurs qui sont normalement adjacents.

o Les informations échangées entre homologues TRIP décrivent des chemins vers des appareils de couche application, et non des routeurs IP, comme cela se fait avec BGP.

o TRIP suppose l’existence d’un réseau de transport IP sous-jacent. Cela signifie que les serveurs qui échangent des informations d’acheminement TRIP n’ont pas besoin d’agir comme transmetteurs de messages de signalisation qui sont acheminés sur la base de ces informations. Cela n’est pas vrai dans BGP, où les homologues doivent aussi agir comme points de transmission (ou désigner un bond de transmission adjacent) pour les paquets IP.

o L’objet de TRIP n’est pas d’établir la connexité globale à travers tous les ITAD. Il est parfaitement raisonnable qu’il y ait de petits îlots de connexité TRIP. Chaque îlot représente un ensemble clos de relations administratives. De plus, chaque îlot peut toujours avoir la connexité complète avec le GSTN entier. Ceci est un contraste évident avec BGP, où le but est la connexité complète à travers l’Internet. Si un ensemble de systèmes autonomes (AS) est isolé d’un autre ensemble à cause d’une déconnexion de BGP, aucune connexité de réseau IP n’existe entre eux.

o Les chemins de passerelles sont beaucoup plus complexes que les chemins IP (car ils résident à la couche application, et pas à la couche réseau) avec beaucoup plus de paramètres qui les décrivent.

o BGP échange des préfixes qui représentent une portion de l’espace de noms IP. TRIP échange des gammes de numéros de téléphone, représentant une portion de l’espace des numéros du GSTN. L’organisation et la hiérarchie de ces deux espaces sont différentes.


Ces différences signifient que TRIP emprunte beaucoup des concepts de BGP, mais est quand même un protocole différent avec son propre ensemble de fonctions spécifiques.


6. Exemple d’applications de TRIP


TRIP est un outil générique pour échanger les chemins de téléphonie IP entre fournisseurs. TRIP ne dicte, en aucune façon, la structure ou la nature des relations entre ces fournisseurs. Il en résulte que TRIP a des applications pour un certain nombre de cas courants de téléphonie IP.


6.1 Chambres de compensation


Une chambre de compensation est un fournisseur qui sert de point d’échange entre un certain nombre d’autres fournisseurs, appelés les membres de la chambre de compensation. Chaque membre s’affilie à la chambre de compensation. Au titre de l’accord, le membre rend ses passerelles disponibles aux autres membres de la chambre de compensation. En échange, les membres ont accès aux passerelles possédées par les autres membres de la chambre de compensation. Lorsque une passerelle appartenant à un membre fait un appel, la chambre de compensation joue un rôle clé dans la détermination du membre qui termine l’appel.


TRIP peut être appliqué ici comme l’outil d’échange des chemins entre les membres et la chambre de compensation. C’est ce qui est montré à la Figure 1.


|------| |------|

| M1 | TRIP TRIP | M2 |

| |\ | | /| |

------ \ | | / ------

\ \ / -------------- \ / /

------ \----| |----/ ------

| | | Chambre | | |

| M3 |--------| de |--------| M4 |

| | | compensation | | |

------ /----| |----\ ------

/ -------------- \

------ / \ ------

| |/ \| |

| M5 | | M6 |

------ ------


Figure 1 : TRIP dans l’application de chambre de compensation


Il y a six compagnies membres, de M1 à M6. Chacune utilise TRIP pour envoyer et recevoir les chemins des passerelles avec le fournisseur de la chambre de compensation.


6.2 Confédérations


On se réfère à une confédération comme à un groupe de fournisseurs qui sont tous d’accord pour partager les passerelles les uns des autres dans un maillage complet sans utiliser de chambre de compensation centrale. Une telle configuration est montrée à la Figure 2. TRIP va fonctionner entre chaque paire de fournisseurs.


------ ------

| |------| |

| M1 | | M2 |

| |\ /| |

------ \ / ------

| \/ |

| /\ |<-----TRIP

------ / \ ------

| |/ \| |

| M3 | | M4 |

| |------| |

------ ------


Figure 2 : TRIP pour des confédérations


6.3 Grossiste en passerelles


Dans cette application, il y a un certain nombre de gros fournisseurs de passerelles de téléphonie. Chacun d’eux revend ses services de passerelle aux fournisseurs de taille moyenne. Ceux-ci à leur tour, revendent aux fournisseurs locaux qui vendent directement aux consommateurs. C’est en fait une relation pyramidale, comme le montre la Figure 3.


------

| |

| M1 |

| |

------

/ \ <------- TRIP

------ ------

| | | |

| M2 | | M3 |

| | | |

------ ------

/ \ / \

------ ------ ------

| | | | | |

| M4 | | M5 | | M6 |

| | | | | |

------ ------ ------


Figure 3 : TRIP pour grossistes


Noter que dans cet exemple, le fournisseur M5 revend les passerelles aussi bien de M2 que de M3.


7. Architecture


La Figure 4 donne l’architecture globale de TRIP.

(Les passerelles sont marquées GW pour "gateway")

ITAD1 ITAD2

----------------- ------------------

| | | |

| ---- | | ---- |

| | GW | | | | EU | |

| ---- \ ---- | | ---- / ---- |

| | LS | ---------------- | LS | |

| ---- ---- | / ---- \ ---- |

| | GW | / | /| | EU | |

| ---- | / | ---- |

| | / | |

------------------ / ------------------

/

/

--------- /----------

| | |

| ---- |

| | LS | |

| / ---- \ |

| ---- || ---- |

| | GW | || | EU | |

| ---- || ---- |

| ---- || ---- |

| | GW | / \ | EU | |

| ---- ---- |

| |

---------------------

ITAD3


Figure 4 : Architecture de TRIP


Il existe un certain nombre de domaines administratifs de téléphonie Internet (ITAD, Internet Telephony administrative domain) chacun d’eux a au moins un serveur de localisation (LS, Location Server). Les LS, par un moyen hors bande, appelé protocole intra-domaine, se renseignent sur les passerelles de leur domaine. Le protocole intra domaine est représenté par les lignes entre les éléments GW et LS dans ITAD1 sur la Figure. Les LS ont des associations avec les autres LS, sur lesquelles ils échangent les informations de passerelles. Ces associations sont établies administrativement, et sont établies lorsque les domaines administratifs IT ont une sorte d’accord établi en ce qui concerne l’échange des informations de passerelle. Dans la figure, le LS dans ITAD1 est connecté au LS dans ITAD2, qui à son tour est connecté au LS dans ITAD3. Par l’acheminement de téléphonie sur IP (TRIP) le LS dans ITAD2 apprend l’existence des deux passerelles qui sont dans ITAD1. Ces informations sont accessibles aux utilisateurs finaux (EU, End User) dans ITAD2 grâce au processeur frontal. Le processeur frontal est un protocole ou mécanisme différent de TRIP par lequel on accède aux bases de données du LS. Dans ITAD3, il y a à la fois des EU et des passerelles. Le LS dans ITAD3 apprend quelles sont les passerelles dans ITAD1 grâce à une annonce éventuellement agrégée de la part du LS dans ITAD2.


8. Éléments


L’architecture dans la Figure 4 consiste en un certain nombre d’éléments. Cela inclut le domaine administratif IT, l’utilisateur final, la passerelle, et le serveur de localisation.


8.1 Domaine administratif IT


Un domaine administratif IT consiste en zéro, une ou plusieurs passerelles, au moins un serveur de localisation, et zéro, un ou plusieurs utilisateurs finaux. Les passerelles et les LS sont ceux qui sont sous le contrôle administratif d’une seule autorité. Cela signifie qu’il y a une autorité qui est chargée de dicter les politiques et la configuration des passerelles et des LS.


Un domaine administratif IT n’a pas besoin d’être le même qu’un système autonome. Alors qu’un AS représente un ensemble de réseaux connectés physiquement, un domaine administratif IT peut consister en éléments sur des réseaux disparates, et même au sein de systèmes autonomes disparates.


Au sein d’un domaine administratif IT, l’utilisateur final est effectivement le client de ce domaine administratif IT. Il est intéressé à l’achèvement de l’appel vers le réseau téléphonique, et a donc besoin de l’accès aux passerelles. Un utilisateur final peut être client d’un domaine administratif IT pour un appel, puis un client d’un domaine différent pour le suivant.


Un domaine administratif IT n’a pas besoin d’avoir de passerelle. Dans ce cas, son LS va apprendre où sont les passerelles dans d’autres domaines, et les rendre disponibles pour l’utilisateur final au sein de son domaine. Dans ce cas, le domaine administratif IT est effectivement un fournisseur de passerelle virtuelle de téléphonie. Cela parce que il fournit un service de passerelle, mais peut ne pas posséder ou administrer réellement de passerelle.


Un domaine administratif IT n’a pas besoin d’avoir d’utilisateur final. Dans ce cas, il fournit un service de passerelle "en gros" , rendant ses passerelles disponibles pour les clients d’autres domaines administratifs IT.


Un domaine administratif IT n’a pas besoin d’avoir de passerelles ni d’utilisateurs finaux. Dans ce cas, l’ITAD a seulement des LS. L’ITAD agit comme revendeur, apprenant où sont les autres passerelles, puis agrégeant et propageant ces informations aux autres ITAD qui ont des clients.


8.2 Passerelle


Une passerelle est un appareil logique qui a à la fois la connexité IP et la connexité à un autre réseau, normalement un réseau téléphonique public ou privé. La fonction de la passerelle est de traduire les protocoles du support et de signalisation d’une technologie réseau à l’autre, réalisant une connexion transparente pour les utilisateurs du système.


Une passerelle a un certain nombre d’attributs qui caractérisent le service qu’elle fournit. Les plus fondamentaux d’entre eux sont la gamme de numéros de téléphonie à laquelle elle veut fournir le service. Cette gamme peut être divisée en sous gammes, et associée à chacune, une métrique de coût ou des jetons de coût. Ce jeton indique une notion de coût ou de préférence pour achever les appels pour cette partie de la gamme de numéros de téléphone.


Une passerelle a des attributs qui caractérisent le volume de service qui peut être fourni. Cela inclut le nombre d’accès qu’elle a (c’est-à-dire, le nombre d’appels téléphoniques simultanés qu’elle peut prendre en charge) et la vitesse de la liaison d’accès. Ensemble, ces deux caractéristiques représentent une notion de la capacité de la passerelle. La métrique est utile pour permettre aux serveurs de localisation de décider d’acheminer les appels vers les passerelles en proportion de la valeur de la métrique, réalisant ainsi une forme simple d’équilibrage de charge.


Une passerelle a aussi des attributs qui caractérisent le type de service qu’elle fournit. Cela inclut, sans s’y limiter, les protocoles de signalisation pris en charge, les caractéristiques de téléphonie fournies, les codecs de parole acceptés, et les algorithmes de chiffrement qui sont mis en œuvre. Ces attributs peuvent être importants dans le choix d’une passerelle. En l’absence des caractéristiques de base exigées pour toutes les passerelles (un but admirable, mais difficile à atteindre) un tel ensemble d’attributs est requis afin de choisir une passerelle avec laquelle les communications puissent être établies. L’utilisateur final qui a des exigences spécifiques pour son appel (comme un utilisateur qui demande un appel de classe affaires, auquel cas certaines caractéristiques d’appel peuvent devoir être prises en charge) peut souhaiter faire usage aussi de telles informations.


Certains de ces attributs sont transportés dans TRIP pour décrire les passerelles, et d’autres ne le sont pas. Cela dépend de si la métrique peut être raisonnablement agrégée, et de si c’est quelque chose qui doit être convoyé dans TRIP avant l’établissement de l’appel (par opposition à quelque chose de négocié ou échangé par les protocoles de signalisation eux-mêmes). La philosophie de TRIP est de rester simple, et de favoriser l’adaptabilité plutôt que l’abondance d’information. L’ensemble d’attributs de TRIP est directement extensible. Des fanions fournissent des informations qui permettent que des attributs inconnus soient traités raisonnablement par un LS.


8.3 Utilisateur final


Un utilisateur final est une entité (normalement un être humain) qui souhaite réaliser un appel à travers une passerelle entre un réseau IP et un terminal sur un réseau téléphonique. Un utilisateur final peut être un usager connecté sur un ordinateur qui a un logiciel de téléphonie Internet. L’utilisateur final peut aussi être connecté au réseau IP à travers une passerelle téléphonique d’entrée, à laquelle l’usager accède par un combiné téléphonique. C’est le cas pour ce qu’on appelle le service de "téléphone à téléphone" avec le réseau IP qui est utilisé pour le transport inter centraux.


L’utilisateur final peut être ou non conscient de ce qu’il y a un service d’acheminement téléphonique qui fonctionne quand il passe un appel vers le réseau téléphonique. Dans les cas où il le sait, l’utilisateur final peut avoir des préférences sur la façon dont un appel se déroule. Ces préférences peuvent inclure des caractéristiques d’appel qui doivent être prises en charge, des mesures de qualité, d’opérateur ou d’administrateur, et des préférences de coût.


TRIP ne fixe pas comment ces préférences se combinent avec celles du fournisseur pour donner le choix final de la passerelle. Pas plus que TRIP ne prend en charge le transport de ces préférences au LS. Ce transport peut être réalisé en utilisant le processeur frontal, ou par quelque moyen qui ne relève pas du protocole.


8.4 Serveur de localisation


Le serveur de localisation (LS) est la principale entité fonctionnelle de TRIP. C’est un appareil logique qui a accès à une base de données des passerelles, appelée la base de données des informations d’acheminement téléphonique (TRIB, Telephony Routing Information Base). Cette base de données des passerelles est construite par la combinaison de l’ensemble des passerelles localement disponibles et de l’ensemble des passerelles distantes (apprises par TRIP) sur la base d’une politique. Le LS exporte aussi un ensemble de passerelles à ses LS homologues dans d’autres ITAD. L’ensemble des passerelles exporté est construit à partir de l’ensemble des passerelles locales et de l’ensemble des passerelles distantes (apprises à partir de TRIP) sur la base d’une politique. À ce titre, la politique joue un rôle central dans le fonctionnement du LS. Ce flux d’informations est montré à la Figure 5.


|protocole intra domaine

|

\ /

Passerelles

locales


TRIP--> Passerelles POLITIQUE Passerelles -->TRIP

entrantes | sortantes

|

\ /

Base de données d’informations

d’acheminement téléphonique


Figure 5 : Flux d’informations dans TRIP


La construction de TRIB dans le LS lui permet de prendre des décisions sur l’acheminement des appels téléphoniques IP. Lorsque un message de signalisation arrive à un serveur de signalisation, destiné à une adresse du réseau téléphonique, la base de données du LS peut fournir des informations qui sont utiles pour déterminer une passerelle ou un serveur de signalisation supplémentaire pour lui transmettre le message de signalisation. Pour cette raison, un LS peut être corésident avec un serveur de signalisation. Lorsque ils ne sont pas corésidents, certains moyens de communication entre le LS et le serveur de signalisation sont nécessaires. Cette communication n’est pas spécifiquement traitée par TRIP, bien qu’il soit possible que TRIP puisse satisfaire aux besoins d’un tel protocole.


Un ITAD doit avoir au moins un LS afin de participer à TRIP. Un ITAD peut avoir plus d’un LS, pour les besoins de l’équilibrage de charge, de facilité de gestion, ou pour toute autre raison. Dans ce cas, des communications entre ces LS peuvent devoir se faire afin de synchroniser les bases de données et partager les informations apprises des homologues externes. Ceci est souvent appelé le composant intérieur d’un protocole inter domaines. TRIP comporte une telle fonction.


La Figure 5 montre un LS qui découvre des passerelles au sein de l’ITAD au moyen d’un protocole intra domaine. Il n’est pas nécessaire qu’il y ait un protocole intra domaine. Un LS peut fonctionner sans connaissance de passerelles de fonctionnement local. Ou, il peut connaître des passerelles de fonctionnement local, mais par configuration statique. Un LS peut aussi être corésident d’une passerelle, auquel cas il va connaître la passerelle dont il est corésident.


9. Interactions des éléments

9.1 Passerelles et serveurs de localisation


Les passerelles doivent d’une certaine façon propager les informations sur leurs caractéristiques à un LS au sein du même ITAD. Ce LS peut, à son tour, propager ces informations en-dehors de l’ITAD au moyen de TRIP. Ce LS est appelé un LS d’origine pour cette passerelle. Lorsque un LS n’est pas corésident avec la passerelle, le moyen par lequel les informations sont propagées n’est pas du ressort de TRIP. Le protocole utilisé pour accomplir cela est généralement appelé un protocole intra domaine.


Une façon de propager les informations est d’utiliser le protocole de localisation de service (SLP, Service Location Protocol) [RFC2165]. La passerelle peut contenir un agent de service (SA, Service Agent) et le LS peut agir comme agent de répertoire (DA, Directory Agent). SLP définit des procédures par lesquelles les informations de service sont automatiquement propagées aux DA à partir des SA. De cette façon, un LS peut apprendre quelles sont les passerelles dans l’ITAD.


Un autre mécanisme pour le protocole intra domaine est via les procédures d’enregistrement de SIP ou de H.323. Les procédures d’enregistrement fournissent des moyens par lesquels les utilisateurs informent un portier ou un serveur SIP de leur adresse. Une telle procédure d’enregistrement pourrait être étendue pour permettre à une passerelle de s’enregistrer effectivement aussi.


LDAP [RFC1777] peut aussi être utilisé comme protocole intra domaine. Une passerelle peut utiliser LDAP pour ajouter une entrée pour elle-même dans la base de données. Si le LS joue aussi le rôle de serveur LDAP, il sera capable d’apprendre qui sont toutes ces passerelles dans son ITAD.


Le protocole intra domaine qui est utilisé peut être différent d’un domaine administratif IT à l’autre, et c’est une question de configuration locale. Il peut aussi y avoir plus d’un protocole intra domaine dans un ITAD particulier. Un LS peut aussi fonctionner sans protocole intra domaine. Il peut apprendre les passerelles par configuration statique, ou ne rien savoir des passerelles locales.


9.2 Serveur de localisation à serveur de localisation


L’interaction entre les LS est ce qui est défini par TRIP. Les LS au sein du même ITAD utilisent TRIP pour synchroniser les informations entre eux. Les LS au sein de différents ITAD utilisent TRIP pour échanger les informations de passerelles conformément à leur politique. Dans le premier cas, les LS sont appelés des homologues internes, et dans le dernier cas, des homologues externes.


Les LS communiquent les uns avec les autres grâce à des associations durables. Un LS peut être connecté à un ou plusieurs autres LS. Les LS n’ont pas besoin d’être physiquement adjacents ou de faire partie du même système autonome. L’association entre une paire de LS est normalement établie de façon administrative. Deux LS sont configurés pour communiquer les uns avec les autres lorsque leurs administrateurs ont un accord établi pour échanger des informations de passerelles. Bien que TRIP ne fournisse pas de procédure d’auto découverte pour que les LS homologues se découvrent les uns les autres, on peut éventuellement en utiliser une. Une telle procédure pourrait être utile pour créer un LS homologue de secours lorsque survient une panne. Autrement, dans un environnement où les relations d’affaires entre homologues deviennent plus normalisées, les homologues pourraient être autorisés à se découvrit les uns les autres par des protocoles comme le protocole de localisation de service (SLP, Service Location Protocol) [RFC2608]. Déterminer si l’auto découverte devrait ou non être utilisée est à la discrétion de l’administrateur.


La syntaxe et la sémantique des messages échangés dans l’association entre les LS sont fixées par TRIP. Le protocole ne fixe pas la nature des accords qui doivent être établis. TRIP fournit simplement un moyen de transport pour échanger les informations d’acheminement sur les passerelles qui paraissent appropriées aux administrateurs du système. Les détails sont fournis dans la spécification du protocole TRIP elle-même.


Les règles qui gouvernent quelles informations de passerelles sont générées, propagées, et acceptées par une passerelle sont appelées une politique de serveur de localisation. TRIP ne fixe ni ne rend obligatoire aucune politique spécifique.


9.2.1 Nature des informations échangées

Les informations échangées par les LS sont un ensemble d’objets d’acheminement. Chaque objet d’acheminement consiste au minimum en une gamme de numéros de téléphone qui sont joignables, et en une adresse IP ou nom d’hôte qui est le "prochain bond" de couche application vers une passerelle qui peut atteindre cette gamme de numéros. Les objets d’acheminement sont appris du protocole intra domaine, par configuration statique, ou des LS dans des ITAD distants. Un LS peut agréger ces objets d’acheminement (en fusionnant des gammes de numéros de téléphone, et en remplaçant l’adresse IP par sa propre adresse IP, ou par l’adresse IP d’un serveur de signalisation avec lequel le LS est en communication) et ensuite les propager à un autre LS. La décision sur les objets à agréger et propager est appelée une opération de choix de chemin. L’administrateur a une grande latitude pour choisir quels objets agréger et propager, pour autant qu’ils sont dans les limites d’un fonctionnement correct du protocole (c’est-à-dire, qu’aucune boucle n’est formée). La sélection peut être effectuée sur la base des informations apprises par TRIP, ou par tout moyen hors bande.


Un objet d’acheminement peut avoir des informations supplémentaires qui caractérisent le service d’une passerelle. Ces attributs incluent des choses comme les protocoles, les caractéristiques prises en charge, et la capacité. Un plus grand nombre d’attributs peut fournir des informations utiles, cependant, cela a un coût. L’agrégation devient difficile avec de plus en plus d’informations, ce qui a un impact sur la capacité d’adaptation du protocole.


L’agrégation joue un rôle central dans TRIP. Afin de faciliter l’adaptabilité, les objets d’acheminement peuvent être combinés en de plus grands agrégats avant d’être propagés. Le mécanisme par lequel cela est fait est spécifié dans TRIP. L’agrégation de chemins de couche application vers des passerelles est un problème non trivial. Il y a des compromis fondamentaux entre agrégation et fluidité. Plus il y a d’informations présentes dans un objet d’acheminement TRIP, plus il est difficile à agréger.


Considérons un exemple simple de deux passerelles, A et B, capables d’atteindre, respectivement, un certain ensemble de numéros de téléphone, X et Y. C est un LS pour l’ITAD dans lequel résident A et B. C apprend l’existence de A et B par quelque autre moyen. Il se révèle que X et Y peuvent être combinés dans une seule gamme d’adresses, Z. C a plusieurs options. Il peut propager juste l’annonce pour A, juste l’annonce pour B, propager les deux, ou les combiner et propager l’annonce agrégée. Dans ce cas, C choisit cette dernière approche, et envoie un seul objet d’acheminement à un de ses homologues, D, objet qui contient la gamme d’adresses Z et sa propre adresse, car il est aussi un serveur de signalisation. D est aussi un serveur de signalisation.


Un appareil d’appel, E, souhaite passer un appel téléphonique au numéro de téléphone T, qui se trouve être dans la gamme d’adresses X. E est configuré à utiliser D comme portier H.323 par défaut. Aussi, E envoie un message d’établissement d’appel à D, contenant l’adresse de destination T. D détermine que l’adresse T est comprise dans la gamme Z. Comme D a reçu un objet d’acheminement de la part de C qui contient la gamme d’adresses Z, il transmet le message d’établissement d’appel à C. C, à son tour, voit que T est dans la gamme X, et transmet donc l’établissement d’appel à A, qui termine la signalisation d’appel et initie un appel vers le réseau téléphonique.


9.2.2 Qualité de service

Un des facteurs utiles à prendre en considération lors du choix d’une passerelle est la "QS" – un appel à travers cette passerelle subira t-il une perte, un délai, une gigue suffisamment faibles ? La qualité d’un appel dépend de deux composants - la QS sur le chemin entre l’appelant et la passerelle, et la capacité de la passerelle elle-même (mesurée en termes de nombre de circuits disponibles, de capacité de la liaison, de ressources de DSP, etc.). La détermination de cette dernière exige une connaissance complexe des topologies de réseau sous-jacentes, et de l’endroit où est situé l’appelant. C’est quelque chose qui est traité par les protocoles de qualité de service de l’acheminement et sort du domaine d’application de TRIP.


Cependant, la capacité de la passerelle ne dépend pas de la situation de l’appelant ou des caractéristiques du chemin. Pour cette raison, une certaine forme de métrique de la capacité est prise en charge par TRIP. Cette métrique représente la capacité statique de la passerelle, et non la capacité dynamique disponible qui varie de façon continuelle durant le fonctionnement des passerelles. Les LS peuvent utiliser cette métrique comme moyen d’équilibrage de la charge des appels entre les passerelles. Elle peut aussi être utilisée comme entrée à toute autre décision de politique.


9.2.3 Informations de coût

Un autre attribut utile à propager est une métrique de tarification. Elle peut représenter la quantité qu’une passerelle particulière va facturer pour un appel. La métrique peut être un indice dans un tableau qui définit une structure de tarification conformément à une accord commercial préexistant, ou elle peut contenir une représentation du prix lui-même. TRIP ne définit pas de métrique de tarification, mais il peut et devrait en être définie une comme extension. Utiliser une extension pour la tarification signifie que plus d’une de ces métriques peuvent être définies.


10. La devanture


Par suite de TRIP, le LS construit une base de données (la TRIB) des chemins de passerelles. Ces informations sont rendues disponibles à diverses entités au sein de l’ITAD. La façon dont ces informations sont rendues disponibles est appelée la devanture. C’est le moyen visible par lequel les services TRIP sont exposés à l’extérieur du protocole.


10.1 Utilisateurs de la devanture


Il y a plusieurs entités qui peuvent utiliser la devanture pour accéder à la TRIB. Cela inclut, sans s’y limiter :



Les serveurs de signalisation :

Les serveurs de signalisation reçoivent des messages de signalisation (tels que des messages H.323 ou SIP) dont l’objet est l’initiation des appels de téléphonie IP. L’adresse de destination de ces appels peut être un numéro de téléphone correspondant à un terminal sur le GSTN. Afin d’acheminer ces appels sur une passerelle appropriée, le serveur de signalisation va avoir besoin d’accéder à la base de données construite dans le LS.


Les utilisateurs finaux :

Ils peuvent interroger directement le LS pour obtenir les informations d’acheminement. Cela leur permet de fournir des informations détaillées sur leurs exigences. Ils peuvent alors aller contacter le serveur de signalisation ou la passerelle du prochain bond vers ce numéro de téléphone.


Les administrateurs

Les administrateurs peuvent avoir besoin d’accéder à la TRIB pour des fonctions de maintenance et de gestion.


Lorsque un serveur de signalisation contacte le LS pour acheminer un numéro de téléphone, il le fait normalement parce qu’un appareil appelant (au nom d’un utilisateur final) a tenté d’établir un appel. Il en résulte que les serveurs de signalisation agissent effectivement comme mandataires pour l’utilisateur final lors de l’accès à la base de données du LS. La communication entre les appareils appelants et leurs mandataires (les serveurs de signalisation) se fait par le protocole de signalisation.


L’avantage de cette approche par mandataire est que l’interaction réelle de LS est cachée à l’appareil appelant. Que l’appel soit un numéro de téléphone ou une adresse IP est donc sans importance. L’acheminement dans le cas des numéros de téléphone se fait de façon transparente. Le mode mandataire est aussi avantageux pour les petits clients (comme les téléphones IP autonomes) qui n’ont pas d’interface ou de puissance de traitement pour une interrogation directe du LS.


L’inconvénient de l’approche du mandataire est le même que son avantage – l’interaction des LS est cachée à l’appareil appelant (et donc à l’utilisateur final). Dans certains cas, l’utilisateur final peut avoir des exigences sur la façon dont il voudrait que soit acheminé l’appel. Cela inclut des préférences en matière de coût, de qualité, d’administrateur, ou de services et protocoles d’appel. Ces exigences sont appelées la politique de l’utilisateur final. Dans l’approche par mandataire, l’utilisateur accède effectivement au service à travers le protocole de signalisation. Le protocole de signalisation ne sera vraisemblablement pas capable de prendre en charge l’expression de préférences d’acheminement d’appel complexes de la part de l’utilisateur final (noter cependant, que SIP prend bien en charge certaines formes de préférences d’appelant pour l’acheminement d’appel [RFC3840]). Donc, l’accès direct de l’utilisateur final au LS peut fournir des services d’acheminement d’appel beaucoup plus riches.


Lorsque la politique d’utilisateur final est présentée au LS (soit directement, soit par le protocole de signalisation) la façon de l’utiliser est à la discrétion du LS. Le serveur de localisation peut avoir ses propres politiques concernant la façon de traiter les préférences de l’utilisateur final.


10.2 Protocoles de la devanture

Il y a de nombreux protocoles qui peuvent être utilisés dans la devanture pour accéder à la base de données du LS. TRIP ne spécifie ou n’interdit aucune possibilité pour la devanture. Il n’est pas clair qu’il soit nécessaire ou même désirable qu’il y ait un seul standard pour la devanture. Les divers protocoles ont leurs forces et leurs faiblesses. L’un peut être la bonne solution dans certains cas, et un autre dans des cas différents.


Certains des protocoles possibles pour la devanture sont :


Protocole de localisation de service (SLP, Service Location Protocol) : SLP a été conçu pour remplir exactement cette sorte de fonction. SLP est idéal pour localiser les serveurs décrits par un ensemble d’attributs. Dans ce cas, le serveur est une passerelle (ou le prochain bond vers la passerelle) et les attributs sont la politique de l’utilisateur final. L’utilisateur final est un UA SLP, et le LS est un DA SLP. L’interrogation de service est utilisée pour demander une passerelle avec un ensemble d’attributs particulier.


Protocole ouvert de règlements (OSP, Open Settlements Protocol) : OSP [TS101.321] est un protocole client serveur. Il permet au client d’interroger un serveur sur un numéro de téléphone, et d’avoir en retour l’adresse d’un prochain bond, ainsi que des jetons d’autorisation à utiliser pour l’appel. Dans ce cas, le serveur peut être un LS. Le tableau d’acheminement qu’il utilise pour répondre aux interrogations OSP est celui qui est construit en utilisant TRIP.


Protocole léger d’accès à un répertoire (LDAP, Lightweight Directory Access Protocol) : LDAP est utilisé pour accéder aux bases de données réparties. Comme le serveur LS contient une base de données, LDAP pourrait être utilisé pour l’interroger.


Page de la Toile : Le LS pourrait avoir une devanture sur la Toile. Les utilisateurs pourraient entrer des questions dans un formulaire, et les passerelles correspondantes seraient retournées dans la réponse. Ce mécanisme d’accès est, cependant, plus approprié pour l’accès humain. Un serveur de signalisation ne va vraisemblablement pas accéder à la devanture par une page de la Toile.


TRIP : Les protocoles exposés ci-dessus sont tous du type interrogation-réponse. Il n’y a aucune raison pour que l’accès au LS doive se faire sous cette forme. Il est parfaitement acceptable que l’accès se fasse par une complète synchronisation des bases de données, de sorte que l’entité qui accède à la base de données du LS en ait effectivement une copie complète. Si on souhaite cette approche, TRIP est lui-même un mécanisme approprié. Cette approche a des inconvénients évidents, mais rien ne s’oppose à sa mise en œuvre.


11. Traduction des numéros


Le modèle de TRIP présente de nombreuses passerelles, dont chacune est volontaire pour faire la terminaison des appels vers un certain ensemble de numéros de téléphonie. Souvent, cet ensemble sera fondé sur l’ensemble des numéros de téléphone qui sont dans la proximité géographique de la passerelle. Par exemple, une passerelle sur Orléans pourrait être volontaire pour terminer des appels aux codes de zone 02 38 et 02 37. Bien sûr, il dépend des administrateurs de décider quels numéros de téléphone la passerelle veut appeler.


Cependant, certains numéros de téléphone ne représentent pas du tout des terminaux du GSTN, mais ils représentent plutôt des services ou des adresses virtuelles. Un exemple de tels numéros est celui des numéros de Libre appel et du LNP. Dans le réseau téléphonique, il sont en fait transposés en numéros de téléphone acheminables, souvent sur la base de formules complexes. Un exemple classique est la traduction fondée sur l’heure.


Bien que rien n’empêche une passerelle d’annoncer une accessibilité à de telles sortes de numéros, cet usage est fortement déconseillé. Comme TRIP est un protocole d’acheminement, les chemins qu’il propage devraient être des numéros susceptibles d’acheminement, et non des noms qui sont finalement traduits en numéros acheminables. De nombreux problèmes se font jour lorsque TRIP est utilisé pour propager des chemins vers ces numéros :

o Souvent, ces numéros ont seulement une signification locale. Les appels à un numéro de téléphone en libre appel faits depuis Paris peuvent aboutir dans un bureau parisien de la compagnie de téléphone, alors que les appels faits depuis Marseille vont aboutir dans la filiale marseillaise. Si ce numéro de téléphonie en libre appel est injecté dans TRIP par une passerelle à Paris, il pourrait être propagé à d’autres LS qui ont des utilisateurs finaux à Marseille. Si ce chemin est utilisé, les appels pourraient n’être pas acheminés comme prévu.

o Les chemins de signalisation d’appel peuvent être très sous optimaux. Considérons une passerelle à Paris qui annonce un numéro porté qui se transpose en un téléphone à Marseille. Ce numéro est propagé par TRIP, et finalement appris par un LS dont les utilisateurs sont en Provence Côte d’Azur. Lorsque on compose ce numéro, l’appel est acheminé sur le réseau IP vers Paris où il emprunte la passerelle, et ensuite il est acheminé sur le GSTN de retour à Marseille. C’est un gâchis de ressources. Si le numéro porté avait été traduit avant que la fonction d’acheminement de la passerelle ne soit invoqué, une passerelle marseillaise aurait pu être accédée directement.

Il en résulte qu’il est plus efficace d’effectuer des traductions de ces numéros spéciaux avant d’accéder aux bases de données d’acheminement des LS. La façon d’effectuer cette traduction sort du domaine d’application de TRIP. Elle peut être accomplie par l’appareil appelant avant d’effectuer l’appel, ou par un serveur de signalisation avant qu’il accède à la base de données du LS.


12. Considérations pour la sécurité


La sécurité est une composante importante de TRIP. Le modèle de TRIP suppose un niveau de confiance entre les LS homologues qui échangent les informations. Ces informations sont utilisées pour propager les informations qui déterminent où acheminer les appels. Si ces informations sont incorrectes, cela peut causer un mauvais acheminement complet des appels. Cela rend possible de significatives attaques de déni de service. Les informations pourraient aussi être propagées à d’autres ITAD, causant l’extension potentielle du problème. Il en résulte que l’authentification mutuelle des LS homologues est critique. De plus, la protection de l’intégrité du message est requise.

Les messages TRIP peuvent contenir des informations potentiellement sensibles. Elles représentent les capacités d’acheminement d’un ITAD. De telles informations pourraient être utilisées par des concurrents en affaire pour déterminer la topologie du réseau et la capacité de l’ITAD. Il en résulte que le chiffrement des messages est aussi pris en charge dans TRIP.


Comme les objets d’acheminement peuvent être passés d’un LS à un autre, il y a aussi besoin d’une sorte d’authentification de bout en bout. Cependant, l’agrégation va causer la modification des objets d’acheminement, et donc l’authentification ne peut avoir lieu qu’après le point de la dernière agrégation vers les LS receveurs.


13. Remerciements


Les auteurs tiennent à remercier Randy Bush, Mark Foster, Dave Oran, Hussein Salama, et Matt Squire pour leur commentaires utiles sur le présent document.


14. Bibliographie


[H.323] Union Internationale des Télécommunications, secteur de la normalisation des télécommunications, Recommandation H.323, "Systèmes et équipements de visiophone pour réseaux de zone locale qui fournissent une qualité de service non garantie", Genève, Confédération Helvétique, mai 1996.


[RFC1661] W. Simpson, éditeur, "Protocole point à point (PPP)", STD 51, juillet 1994. (MàJ par la RFC 2153)


[RFC1771] Y. Rekhter, T. Li , "Protocole de routeur frontière v. 4 (BGP-4)", mars 1995. (Obsolète, voir RFC4271) (D.S.)


[RFC1777] W. Yeong, T. Howes, S. Kille, "Protocole léger d'accès de répertoire", mars 1995. (Hist. voir RFC3494)


[RFC2131] R. Droms, "Protocole de configuration dynamique d'hôte", mars 1997. (Màj par les RFC3396 et 4361)


[RFC2165] J. Veizades et autres, "Protocole de localisation de service", juin 1997. (MàJ par RFC2608, RFC2609) (P.S.)


[RFC2543] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, "SIP : protocole d'initialisation de session", mars 1999. (Obsolète, voir RFC3261, RFC3262, RFC3263, RFC3264, RFC3265) (P.S.)


[RFC2608] E. Guttman et autres, "Protocole de localisation de service, version 2", juin 1999. (MàJ par RFC3224) (P.S.)


[RFC2705] M. Arango, A. Dugan, I. Elliott, C. Huitema, S. Pickett, "Protocole de contrôle de passerelle support (MGCP) version 1.0", octobre 1999. (Obsolète, voir RFC3435) (MàJ par RFC3660) (Information)


[RFC3840] J. Rosenberg, H. Schulzrinne et P. Kyzivat, "Indication des capacités d'agent d'utilisateur dans le protocole d'initialisation de session (SIP)", août 2004.


[TS101.321] Institut Européen des normes de télécommunications (ETSI), Harmonisation des télécommunications et du protocole Internet sur les réseaux (TIPHON), "Inter-domain pricing, authorization, et usage exchange," Technical Specification 101 321 version 1.4.2, ETSI, 1998.


15. Adresse des auteurs


Jonathan Rosenberg

Henning Schulzrinne

dynamicsoft

Columbia University

72 Eagle Rock Avenue

M/S 0401

First Floor

1214 Amsterdam Ave.

East Hanover, NJ 07936

New York, NY 10027-7003

USA

USA

mél : jdrosen@dynamicsoft.com

mél : schulzrinne@cs.columbia.edu


16. Déclaration complète de droits de reproduction


Copyright (c) The Internet Society (2002). Tous droits réservés.


Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de copyright ci-dessus et le présent et paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.


Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society, ses successeurs ou ayant droits.


Le présent document et les informations y contenues sont fournies 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.


Remerciement

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.