Groupe de travail Réseau	I. Faynberg, Lucent Technologies
Request for Comments : 3136	M. Weissman, Lucent Technologies
Catégorie : Information	H. Lu, Lucent Technologies
Traduction Claude Brière de L'Isle	L. Slutsman, éditeur, AT&T
	juin 2001

Architecture de SPIRITS

Statut de ce mémoire
Le présent mémoire apporte des informations pour la communauté de l'Internet. Le présent mémoire 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 (2001). Tous droits réservés.

Résumé
Le présent document décrit l'architecture pour prendre en charge les services SPIRITS, qui ont leur origine dans le RTPC (Réseau Téléphonique Public Commuté) et nécessitent des interactions entre le RTPC et l'Internet. (L'appel Internet en attente, la livraison de l'identifiant d'appel Internet, et la transmission d'appel Internet sont des exemples de services SPIRIT.) Précisément, il définit les composants des éléments qui constituent l'architecture et les interfaces entre les composants.
Table des matières
1. Introduction	1
2. Brève description d'exemples de services SPIRITS	2
2.1 Appel Internet en attente (ICW)	2
2.2 Livraison de l'identifiant d'appel Internet	3
2.3 Transmission d'appel Internet	3
3. Architecture SPIRITS	3
3.1 Interface A	3
3.2 Interface B	3
3.3 Interface C	4
3.4 Interface D	4
3.5 Interface E	4
4. Considérations sur la sécurité	4
5. Remerciements	4
6. Références	4
Appendice	4
Adresse des auteurs	5
Déclaration complète de droits de reproduction	6

 	1.	Introduction

Le présent document décrit l'architecture de prise en charge des services SPIRITS, qui sont ceux dont l'origine est dans le RTPC (Réseau Téléphonique Public Commuté) et nécessitent des interactions entre le RTPC et l'Internet. (L'appel Internet en attente, la livraison de l'identifiant d'appel Internet, et la transmission d'appel Internet sont des exemples de services SPIRIT.) Précisément, il définit les composants des éléments qui constituent l'architecture et les interfaces entre les composants.

La suite du document est organisée comme suit :
+ La Section 2 décrit des exemples de services SPIRITS du point de vue de l'utilisateur final ;
+ La Section 3 décrit l'architecture SPIRITS ;
+ La Section 4 contient les considérations sur la sécurité ;
+ La Section 5 contient des remerciements ;
+ La Section 6 contient les références ;
+ L'Appendice contient une figure.

 	2.	Brève description d'exemples de services SPIRITS

Pour illustrer les motivations de l'architecture globale de SPIRIT, cette section donne une brève description d'exemples de services SPIRITS :
+ Appel Internet en attente (ICW, Internet Call Waiting),
+ Livraison de l'identifiant d'appelant Internet, et
+ Transmission d'appel Internet.

Ces services sont considérés du point de vue de l'utilisateur final avec les hypothèses suivantes :
+	L'abonnement au service (ou son annulation) est un processus séparé et peut être fait sur le téléphone, via messagerie postale, ou sur la Toile.
+	L'hôte IP de l'abonné (par exemple, un ordinateur personnel) est chargé avec le logiciel nécessaire (incluant un numéro d'identification personnel (PIN, Personal Identification Number) et les adresses IP des serveurs SPIRITS) pour réaliser les services SPIRITS. Le logiciel peut être envoyé par message postal ou téléchargé de la Toile.
+	L'abonné active un service SPIRITS par un enregistrement de session de service, qui peut avoir lieu à tout moment après la connexion à l'Internet. L'abonné peut spécifier la durée de vie de la session. Sitôt la session terminée, le service SPIRITS est désactivé. Naturellement, l'abonné devrait aussi être capable de désactiver un service SPIRITS à tout moment durant la session de service.

Pour certains services (comme ICW ou la livraison de l'identité de l'appelant) l'hypothèse est que le souscripteur du service a une seule ligne téléphonique et un ordinateur personnel, qui est connecté à l'Internet via ce téléphone. (Ces services n'ont de sens que dans cette hypothèse.) Néanmoins, dans d'autres services (comme un centre d'appels fondé sur la Toile, dans lequel un assistant du centre d'appels pourrait rediriger ou rejeter un appel présenté dans une fenêtre incrustée) cette hypothèse peut être inutile ou même inapplicable.

 	2.1	Appel Internet en attente (ICW)
Le service d'appel Internet en attente permet à un abonné engagé dans une session Internet commutée de :
o	avoir notification d'un appel entrant sur la même ligne téléphonique qu'utilisée pour la connexion Internet ;
o	spécifier le traitement désirable de l'appel ; 
o	avoir l'appel traité comme spécifié.

Les détails du service ICW résident dans la façon dont un appel en attente peut être traité [RFC2995]. Les façons normales de traiter un appel incluent :

+	D'accepter l'appel entrant sur le RTPC en terminant la connexion Internet. (Comme la commutation ne peut pas être faite immédiatement, l'appelant peut entendre une annonce d'ouverture suivie par la tonalité de "sonnerie".)

+	De transmettre l'appel entrant à un autre numéro de téléphone. L'abonné va rester connecté à l'Internet, tandis que l'appelant va entendre une annonce indiquant que l'appel est transmis et va finalement être connecté au nouveau numéro de destination.

+	D'accepter l'appel entrant en voix sur IP. L'abonné va répondre à l'appel entrant via la connexion Internet déjà établie. (L'architecture SPIRITS proposée ne reflète cependant pas cette caractéristique.)

+	De rediriger l'appel entrant sur la messagerie vocale. L'abonné va rester connecté à l'Internet, tandis que l'appelant va entendre une annonce l'invitant à laisser un message.

+	D'exécuter un message enregistré à l'appelant et déconnecter l'appel. L'abonné va rester connecté à l'Internet.

+	De rejeter l'appel entrant. L'abonné va rester connecté à l'Internet, tandis que l'appelant va entendre une annonce rejetant l'appel.

L'abonné peut spécifier le traitement d'appel au vol lors de la notification d'un appel entrant. Autrement, l'abonné peut spécifier un traitement général a priori pour tpous les appels (par exemple, de les rediriger sur la messagerie vocale) ou des traitements d'appel spécifiques pour les numéros d'originé. Par suite, quand un appel arrive, l'appel ne va pas être présenté à l'abonné mais il peut examiner après coup le traitement et sortir l'appel du journal d'enregistrement qui est tenu pour tous les appels traités durant le service ICW. Les informations normalement enregistrées dans le journal incluent la date et l'heure de l'appel entrant, le numéro appelant, le nom de l'appelant, et la disposition de l'appel.

 	2.2	Livraison de l'identifiant d'appel Internet
Ce service permet à l'abonné de voir le numéro ou le nom de l'appelant ou les deux tout en étant connecté à l'Internet. Si l'abonné a seulement une ligne téléphonique et qu'il utilise cette même ligne pour la connexion Internet, le service est un sous ensemble du service ICW et suit la description du paragraphe 2.1. Autrement, l'hôte IP de l'abonné sert d'appareil auxiliaire du téléphone auquel l'appel est envoyé en premier.

 	2.3	Transmission d'appel Internet
Le service de transmission d'appel Internet permet à l'abonné au service de transmettre un appel entrant à un autre numéro de téléphone tout en étant connecté à l'Internet. Si l'abonné a seulement une ligne de téléphone et utilise cette même ligne pour la connexion Internet, le service est un sous ensemble du service ICW et suit la description du paragraphe 2.1. Autrement, l'hôte IP de l'abonné sert d'appareil auxiliaire du téléphone auquel l'appel est envoyé en premier.

 	3.	Architecture SPIRITS

La Figure 1 de l'Appendice décrit l'architecture SPIRITS, qui comporte les entités suivantes :

1.	Fonction de contrôle de service (SCF, Service Control Function) [IN-STD], qui exécute la logique du service, interagit avec les entités dans le domaine IP (par exemple, la passerelle SPIRITS et le serveur PINT) à travers le client SPIRITS, et indique aux commutateurs comment réaliser un appel. Physiquement, la SCF peut être localisée dans tout ordinateur autonome d'usage général appelé un point de contrôle de service (SCP, Service Control Point) ou élément spécialisé d'équipement appelé un nœud de service (SN, Service Node) [IN-STD].

2.	Fonction de commutation de service (SSF, Service Switching Function) [IN-STD], qui réside normalement dans un commutateur et est responsable de la reconnaissance des déclencheurs du réseau intelligent (IN, Intelligent Network) et des interactions avec la SCF.

3.	Client SPIRITS, qui est responsable de la réception des demandes du RTPC provenant de la SCF ainsi que de l'envoi des réponses en retour. Il peut être colocalisé avec la SCF. Sinon, il communique avec la SCF par l'interface D.

4.	Serveur PINT, qui reçoit les demandes PINT du client PINT et les relaye au RTPC pour exécution sur l'interface E.

5.	Passerelle SPIRITS, qui est colocalisée avec le serveur ou la passerelle PINT (ou les deux quand ils sont colocalisés comme on le suppose ici pour faire simple) et sert d'intermédiaire entre le serveur SPIRITS et le client SPRITS via, respectivement les interfaces B et C.

6.	Client PINT, qui réside dans l'hôte IP de l'abonné et est responsable de l'initiation des demandes PINT, qui sont envoyées au serveur PINT sur l'interface A.

7.	Serveur SPIRITS, qui termine les demandes du RTPC et est responsable de toutes les interactions (par exemple, notification d'appel entrant et relais du traitement d'appel) entre l'abonné et la passerelle SPIRITS.

La suite de la Section décrit en détails les interfaces entre les entités.

 	3.1	Interface A
Cette interface est utilisée pour envoyer les demandes PINT au serveur PINT. Sa principale utilisation est l'enregistrement des sessions de service et par suite l'activation d'un service SPIRITS (voir la Section 2). De plus, cette interface peut être utilisée pour l'abonnement au service.

 	3.2	Interface B
Cette interface sert à deux objets principaux : 1) à notifier à l'abonné les appels entrants ainsi que le numéro et le nom de l'appelant, si ils sont disponibles ; et 2) d'envoyer à la passerelle SPRITS le choix de l'abonné sur la disposition de l'appel spécifiée en vol.

 	3.3	Interface C
Cette interface est utilisée pour les communications entre le client SPIRITS et la passerelle SPIRITS. La passerelle SPIRITS peut à son tour communiquer avec le serveur SPIRITS, ou peut agir comme un serveur virtuel, et terminer les demandes sans les envoyer au serveur SPIRITS.

 	3.4	Interface D
Cette interface est pour les communications entre le client SPIRITS et la SCF. Précisément, de la SCF au client SPIRITS sont envoyés les paramètres associés aux déclencheurs IN applicables. Du client SPIRITS à la SCF est envoyée la disposition d'appel de l'abonné.
La SCF "transforme" la disposition de l'utilisateur en les actions appropriées, comme d'exécuter une annonce à l'appelant, et reprendre le traitement d'appel suspendu dans le SSP.

 	3.5	Interface E
Cette interface est destinée à envoyer les demandes PINT à la SCF pour exécution.

 	4.	Considérations sur la sécurité

Comme le montre la Figure 1, il y a deux interfaces de communications distinctes, B et C. L'interface B est, en général, à travers l'Internet public et est donc la plus vulnérable aux attaques contre la sécurité résultant en vol ou déni de service. L'interface C, par ailleurs, va probablement être mise en œuvre à travers l'intranet d'un fournisseur de services, où les mesures de sécurité devraient être appliquées à la discrétion du fournisseur de services. Même là, parce que au moins un hôte IP (la passerelle PINT) est connecté à l'Internet, des mesures particulières (par exemple, l'installation de pare-feu, bien que cette mesure particulière seule puisse être insuffisante) doivent être prises pour protéger l'interface C et le reste du réseau contre les attaques.

L'hypothèse que le client PINT et le serveur SPIRITS sont colocalisés, dicte que les considérations de sécurité pour les interfaces A et B sont exactement les mêmes. Les exigences de sécurité détaillées et des solutions pour l'interface A (et, par conséquent, B) se trouvent dans la [RFC2848]. De plus, les exigences de sécurité sont mentionnées dans la RFC sur les exigences du protocole SPIRITS [RFC3298].

 	5.	Remerciements

Nous tenons à remercier Alec Brusilovsky, Jorgen Bjorkner, Scott Bradner, Jim Buller, Lawrence Conroy, Jorge Gato, Dave Hewins, Naoto Makinae, et Dave Shrader de leurs commentaires et apports.

 	6.	Références

[IN-STD]	Faynberg, I., L. Gabuzda, M. Kaplan, et N.Shah, "The Intelligent Network Standards: Their Application to Services", McGraw-Hill,1997.

[RFC2848]	S. Petrack, L. Conroy, "Protocole de service PINT : extensions à SIP et SDP pour l'accès IP aux services de téléphone", juin 2000. (P.S.)

[RFC2995]	H. Lu et autres, "Mises en œuvre préliminaires à SPIRITS de services générés par le RTPC", novembre 2000. (Info.)

[RFC3298]	I. Faynberg et autres, "Exigences du protocole du service dans le réseau téléphonique public commuté/réseau intelligent (RTPC/RI) demandant un service Internet (SPIRITS)", août 2002. (Information)

 	Appendice

                                       ......................
       +----------------+              .                    .
       | +------------+ |              .   +------------+   .
       | |   Client   | |       A      .   |  Serveur/  |   .
       | |    PINT    |********************| passerelle |********
       | |            | |              .   |    PINT    |       *
       | +------------+ |              .   +------------+   .   *
       |                |              .                    .   *
       |  Hôte IP de    |              .                    .   *
       |    l'abonné    |              .                    .   *
       |                |              .   +------------+   .   *
       | +------------+ |              .   | Passerelle |   .   *
       | |   Serveur  | |       B      .   |  SPIRITS   |   .   *
       | |   SPIRITS  |********************|            |   .   * E
       | |            | |              .   +------------+   .   *
       | +------------+ |              .          *         .   *
       +----------------+              .          *         .   *
                                       ...........*..........   *
            //-------\\                           *             *
         ///           \\\                        *             *
        |   Téléphone de  |                       *  C          *
        |   l'abonné      |                       *             *
         \\\           ///                        *             *
           \\ -------//                           *             *
                *                                 *             *
      ++++++++++++++++++++++++++  PSTN   ++++++++++++++++++++++++++
                *                                 *             *
                *                          +------------------+ *
                * Ligne                    | Client SPIRITS   | *
                *                          |                  | *
       +--------------------+          +---+----- D  ---------+-*+
       |                    | INAP/SS7 |                         |
       |Fonction de         ************Fonction de contrôle de  |
       | commutation de     |          |        service          |
       |    service         |          +-------------------------+
       +--------------------+

Figure 1 : Architecture SPIRITS

 	Adresse des auteurs
Lev Slutsman	Igor Faynberg	
AT&T Laboratories	Bell Labs/Lucent Technologies	
200 Laurel Ave.	Room 4D-601A, 101 Crawfords Corner Road	
Middletown, New Jersey, 07748	Holmdel, New Jersey, 07733-3030	
USA	USA	
téléphone : (732) 420-3752	téléphone : 1 732 949-0137	
mél : lslutsman@att.com 	mél : faynberg@lucent.com 	

Mark Weissman	Hui-Lan Lu	
Lucent TechnologiesRoom NE406B	Bell Labs/Lucent Technologies	
Room NE406B	Room 4C-607A, 101 Crawfords Corner Road	
200 Lucent Lane	Holmdel, New Jersey, 07733-3030	
Cary, NC 27511	USA	
téléhone : +1 919 463 3258	téléphone : 1 732 949-0321	
mél : maw1@lucent.com 	mél : huilanlu@lucent.com 	

 	Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2001). 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 droits de reproduction ci-dessus et le présent 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 ou ses successeurs ou ayant droits.

Le présent document et les informations 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 encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

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