Groupe de travail Réseau	I. Faynberg, éditeur, Lucent Technologies
Request for Comments : 3298	J. Gato, Vodaphone
Catégorie : Information	H. Lu, Lucent Technologies
Traduction Claude Brière de L'Isle	L. Slutsman, AT&T
	août 2002

Exigences du protocole du service dans le réseau téléphonique public commuté/réseau intelligent (RTPC/RI) demandant un service Internet (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 (2002). Tous droits réservés.

Résumé
Le présent document décrit les exigences du protocole SPIRITS, sur la base de l'architecture présentée dans la RFC 3136. (SPIRITS signifie "Service dans le RTPC/IN demandant des services Internet".) L'objet du protocole est de prendre en charge les services qui ont leur origine dans le réseau téléphonique public commuté (RTPC) et nécessitent des interactions entre le RTPC et l'Internet. De même, ces services sont appelés des services SPIRITS. (L'appel Internet en attente (ICW), la fourniture de l'identité de l'appelant Internet, et la transmission d'appel Internet sont des exemples de services SPIRIT, mais le protocole est pour définir les matériaux de construction à partir desquels de nombreux autres services peuvent être construits.) Du côté du RTPC, les services SPIRITS sont initialisés à partir des entités du réseau intelligent (IN, Intelligent Network) ; le travail antérieur de l'IETF sur l'inter fonctionnement RTPC/Internet (PINT) a résulté en le protocole (RFC2848) qui prend en charge les services initiés dans l'autre sens – de l'Internet vers le RTPC.

À cette fin, le présent document fait la liste des exigences générales pour le protocole SPIRITS ainsi que celles pertinentes pour les matériaux de construction de l'IN, l'IN sans fil, et de PINT. Le document présente aussi le consensus du groupe de travail SPIRITS sur le choix du protocole de signalisation de SPIRITS.
Table des matières
1. Conventions utilisées dans ce document	1
2. Introduction	2
3. Exigences générales	3
4. Exigences pour le réseau intelligent	4
5. Exigences relatives au réseau intelligent sans fil	5
6. Exigences relatives à PINT	6
7. Suite des notifications d'événement	6
8. Méthodologie	7
9. Considérations sur la sécurité	7
10. Remerciements	8
11. Références	8
12. Adresse des auteurs	9
13. Déclaration complète de droits de reproduction	9

 	1.	Conventions utilisées dans ce document
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] et indiquent les niveaux d’exigence pour les mises en œuvre conformes.
Sauf qualification contraire, le terme PINT est utilisé ici non pour se référer aux présents protocole et services PINT, mais en référence à la portée générique des caractéristiques de service PINT (par opposition à SPIRITS) -- services qui sont invoqués à partir d'un réseau IP (par opposition au RTPC).

 	2.	Introduction

Le présent document décrit les exigences du protocole SPIRITS, sur la base de l'architecture présentée dans la RFC 3136. (SPIRITS signifie "Service dans le RTPC/IN demandant des services Internet". L'objet du protocole est de prendre en charge des services qui ont leur origine dans le réseau téléphonique public commuté (RTPC) et nécessitent des interactions entre le RTPC et l'Internet. De tels services sont appelés des services SPIRITS. (L'appel Internet en attente, la livraison de l'identifiant d'appelant Internet, et la transmission d'appel Internet sont des exemples de services SPIRIT, mais le protocole est pour définir les blocs de construction à partir desquels de nombreux autres services peuvent être construits.) Du côté du RTPC, les services SPIRITS sont initiés à partir des entités du réseau intelligent (IN, Intelligent Network) ; le travail antérieur de l'IETF sur l'interfonctionnement RTPC/Internet (PINT) a résulté en le protocole de la RFC 2848 à l'appui des services initiés dans l'autre sens – de l'Internet vers le RTPC.

À cette fin, le présent document fait la liste des exigences générales pour le protocole SPIRITS ainsi que celles pertinentes pour les éléments de construction de IN, IN sans fil, et PINT. Le document présente aussi le consensus du groupe de travail SPIRITS sur le choix du protocole de signalisation de SPIRITS. L'architecture conjointe PINT/SPIRITS (décrite dans la [RFC3136]) est décrite à la Figure 1.

Il est supposé que le client SPIRITS est soit colocalisé avec la fonction de contrôle de service (SCF, Service Control Function) IN, soit communique avec elle (sur l'interface D spécifique du RTPC) de façon à agir au nom du RTPC/IN. (Cette hypothèse est confirmée par les mises en œuvre actuelles, comme rapporté dans la [RFC2995].)

Les services SPIRITS sont invoqués (et, ensuite, le protocole SPIRITS est initialisé) quand un message provenant d'un client SPIRITS (situé dans le point de contrôle de service (SCP, Service Control Point) IN ou le nœud de service (SN, Service Node) arrive sur l'interface C à la passerelle SPIRITS. La passerelle SPIRITS traite le message et, à son tour, le passe sur l'interface B au serveur SPIRITS. Dans la plupart des cas pratiquement importants, la demande d'un client SPIRITS est en fin de compte causée par une demande provenant d'un bureau central (c'est-à-dire, un commutateur téléphonique) envoyée au SCP ou SN, bien que l'initiation de service fondé sur l'Internet par ces éléments qui n'ont pas été déclenchés par le bureau central soit théoriquement possible. (En définitive, aucun des services de référence de SPIRITS n'est initié d'une telle façon, donc, pour les besoins du développement du protocole SPIRITS, on devrait supposer que l'invocation de service est le résultat direct d'une action antérieure de la fonction de commutation de service.)

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

Figure 1 : Architecture conjointe PINT/SPIRITS 

Avec PINT (et cela s'applique aussi à l'architecture et protocole PINT comme décrit dans la [RFC2848]) la demande de service au serveur PINT est toujours initiée par le client PINT sur l'interface A. Le serveur PINT peut être colocalisé avec le contrôle de service IN ou une entité similaire (appelé un "système exécutif" par la [RFC2848]) ou communiquer avec lui sur l'interface E spécifique du RTPC.

Comme le montre la Figure 1, le client PINT et le serveur SPIRITS sont colocalisés dans l'hôte IP de l'abonné. En fait, les deux peuvent être mis en œuvre pour fonctionner comme un seul procès. Aucune disposition n'est prise pour les interactions entre le client PINT et le serveur SPIRITS. De même, le serveur/passerelle PINT et la passerelle SPIRITS sont supposées être colocalisés, eux aussi. Cette hypothèse est pratique mais pas essentielle ; le serveur PINT pourrait aussi être colocalisé avec le client SPIRITS. Dans l'un et l'autre cas, aucune disposition spécifique n'est prise pour définir l'interfonctionnement entre le serveur PINT et la passerelle SPIRITS ou le serveur PINT et le client SPIRITS autrement qu'en faisant la liste des exigences globales relatives à PINT.

Comme les réseaux sans fil actuellement déployés dans le monde entier sont fondés sur la commutation de circuits, ils sont considérés comme des réseaux RTPC pour les besoins de SPIRITS. Ajouter le type de services SPIRITS aux réseaux sans fil peut permettre que de nouveaux services soient développés (par exemple des informations de géolocalisation peuvent être traitées dans le réseau IP).

Néanmoins, il y a certaines particularités des réseaux sans fil qui forcent la prise en compte dans les exigences de protocole et dans l'architecture SPIRITS.

Un développement standard particulier d'IN sans fil considéré ici est CAMEL phase 3, normalisé par le groupe en partenariat de troisième génération (3GPP). Les considérations pertinentes de service et d'architecture et les exigences de protocole sont présentées plus loin dans ce document. Pour ce qui concerne l'architecture, certains événements sans fil sont générés par le registre de localisation de rattachement (HLR, Home Location Register) qui peut, mais n'y est pas obligé, faire partie du centre de commutation mobile (MSC, Mobile Switching Center) (équivalent sans fil du SSP). Ces événements sont communiqués au contrôle de service, point auquel ils utilisent le même mécanisme pour invoquer les services SPIRITS que ceux qu'utiliserait l'IN.

Le reste de ce document traite des exigences générales, des exigences de l'IN, des exigences spécifique de l'IN sans fil, des exigences de PINT, de la méthodologie de développement du protocole, et des questions de sécurité, dans cet ordre.

 	3.	Exigences générales

Sur la base du succès de l'extension de SIP pour PINT ([RFC2848]) et, en particulier, des résultats des mises en œuvre pré SPIRITS rapportées dans la [RFC2995], le protocole d'initialisation de session (SIP, Session Initiation Protocol) [RFC2543] a été choisi comme protocole de base de signalisation pour SPIRITS.

Donc, il est exigé que les paramètres spécifiques relatifs à SPIRITS soient portés d'une façon cohérente avec les pratiques de SIP. En particulier, le protocole de description de session (SDP, Session Description Protocol) [RFC2327] ou les extensions multi objets de messagerie Internet (MIME, Multi-purpose Internet Mail Extensions) [RFC2045], [RFC2046] peuvent être utilisés à cette fin. Sauf pour le nouveau mécanisme SUBSCRIBE/NOTIFY proposé [RFC3265], et les extensions déjà définies dans PINT, aucune nouvelle extension SIP n'est prévue ; le protocole SPIRITS est plutôt conçu comme s'appuyant sur les mécanismes d'extension ci-dessus.

Il n'est en aucune façon exigé qu'une mise en œuvre SPIRITS prenne automatiquement en charge les services PINT. Le protocole SPIRITS doit être défini d'une façon telle que, au minimum, il puisse prendre en charge seulement le mécanisme de base de notification sans s'appuyer sur les services PINT ou sur des interactions persistantes avec le RTPC. Néanmoins, il a été démontré dans la [RFC2995] que combiner les blocs de construction de PINT avec ceux de SPIRITS est bénéfique à la construction de services RTPC/Internet richement améliorés, de sorte que le protocole SPIRITS doit satisfaire aux exigences relatives à PINT mentionnées à la Section 7 du présent document.

Un exemple spécifique qui montre l'application de cette dernière exigence, qui est développée plus loin dans ce document, est le suivant : la mise en œuvre de SUBSCRIBE/NOTIFY n'est pas obligatoire tant que le protocole SPIRITS minimum est concerné. Donc, la notification initiale du RTPC (Point de détection) va toujours arriver via la méthode SIP INVITE ; cependant, pour mettre en œuvre des interactions persistantes avec le RTPC, la méthode SUBSCRIBE peut être utilisée pour obtenir d'autres notifications des événements du RTPC. Ensuite, ces événements vont être rapportés au moyen de la méthode NOTIFY.

 	4.	Exigences pour le réseau intelligent

L'interface immédiatement pertinente pour le réseau intelligent est celle entre le client SPIRITS et la passerelle SPIRITS (interface C). Un message normal (qui commence un service SPIRITS ) ressemble à :

C -> G: <Notification d'événement>, <Liste de paramètres (DP)>

Les événements pertinents correspondent aux points de détection (DP) du modèle de base d'état d'appel (BCSM, Basic Call State Model) IN. La <Liste de paramètres> est une fonction d'un DP spécifique ; elle contient les paramètres qui en relèvent. Les exigences suivantes s'appliquent :

1)	La liste des DP à couvrir inclut ceux définis dans l'ensemble numéro 3 de capacités IN du BCSM ainsi que ceux qui se rapportent au réseau intelligent sans fil (WIN, Wireless Intelligent Network) spécifié par le projet IMT 2000 de l'UIT-T.

2)	Tous les paramètres associés à de tels DP ne sont pas nécessaires pour les services de référence SPIRITS, ni dans SPIRITS. Le choix des paramètres pertinents fait partie de la définition du protocole SPIRITS.

3)	Il est souhaitable d'éviter une surcharge sémantiques des messages du protocole. (Une façon de le faire est de faire correspondre chaque type d'événement à un message et réciproquement.) Comme le protocole SPIRITS est conçu comme un ensemble d'extensions à un autre protocole (existant) avec l'ensemble de messages défini, la syntaxe et la sémantique des extensions devrait être définie en visant cette exigence.

4)	Les Recommandations de l'UIT-T utilisent la notation de syntaxe abstraite numéro un (ASN.1, Abstract Syntax Notation Number 1) pour spécifier la sémantique des paramètres du protocole d'application du réseau intelligent (INAP, IN Application Protocol) qui sont supposés être codés en binaire. Ni l'utilisation de l'ASN.1, ni l'exigence du codage binaire ne sont des exigences normales des protocoles d'application de l'IETF. Cela étant, des dispositions doivent être prises pour une spécification précise de la conversion des paramètres INAP en texte, qui doit préserver leur sémantique originelle. La conversion réelle des paramètres est la fonction du client SPIRITS.

Afin de produire une interrogation (ou notification) initiale au contrôle de service, un commutateur doit avoir un tel DP établi. Cela peut être fait de façon statique via la gestion de service (cette action particulière devrait être laissée à la mise en œuvre et est donc considérée comme sortant du domaine d'application du protocole SPIRITS) ou de façon dynamique – mais seulement pour les besoins d'un appel particulier – à partir du contrôle de service. Dans ce dernier cas, il est du ressort du protocole SPIRITS (ou PINT) de demander la notification d'événement au contrôle de service. Le schéma de notification d'événement spécifique de SIP [RFC3265] devrait être spécifiquement considérée. Cette fonction peut être effectuée par le client SPIRITS ou par le serveur PINT, la distinction étant discutée au paragraphe suivant. En supposant qu'elle est effectuée par le client SPIRITS, le message pertinent devrait ressembler à :

G->C: SUBSCRIBE <Événement> <Mode> <paramètres spécifiques du DP>,

où <Événement> se réfère à un DP particulier; <Mode> détermine si le point de détection d'événement (EDP, Event Detection Point) est à armer comme une demande d'EDP (EDP-R), une notification EDP (EDP-N), ou demande de TDP (le besoin de notification TDP n'est pas prévu parce qu'elle ne fournirait aucune capacité supplémentaire pour SPIRITS) ; et le <paramètre spécifique de DP> est la liste des valeurs des paramètres associés à l'EDP (par exemple, si le DP en question est O_No_Answer, alors la valeur du temporisateur approprié devrait être inclus dans la liste). Noter qu'un tel abonnement peut aussi avoir son origine à a) un client PINT ou b) une passerelle SPIRITS, dont l'un ou l'autre peut (sans que ce soit nécessaire) avoir une définition de signification locale de <Événement>. Dans l'un et l'autre cas, c'est la fonction du client SPIRITS de traduire la définition de l'événement dans un DP particulier (ou ensemble de DP) lors du passage du message au contrôle de service. Pour résumer, dans le cas où des événements PINT et SPIRITS sont définis d'une façon telle qu'ils ne se réfèrent pas aux DP BCSM, c'est la fonction du client SPIRITS de définir une transposition

Événement -> Liste de DP,

pour chaque événement pour lequel la notification au RTPC est nécessaire.

La liste des DP CS-3 envisagés dans SPIRITS est :

-	origination_attempt_authorized (le service SPIRITS peut contrôler les tentatives d'appel (par exemple, pour limiter les appels durant des périodes spécifiques)

-	collected_information et analyzed_information (pour l'examen d'appel SPIRITS sortant)

-	o_answer, o_term_seized, et t_answer (pour libérer les ressources SPIRITS après l'achèvement de l'appel et effectuer les actions d'OA&M pertinentes telles que de créer un enregistrement des tentatives d'accès à une partie via divers moyens comme une ligne téléphonique terrestre, une téléphone cellulaire, un SMS, ou une recherche de personne).

-	o_no_answer, route_select_failure, et t_no_answer (pour rediriger un appel)

-	o_called_party_busy (pour rediriger un appel et pour l'appel Internet en attente)

-	o_mid_call et t_mid_call (pour assister une action en cours d'appel)

-	o_abandon, o_disconnect, t_abandon, et t_disconnect (pour terminer un service SPIRITS et libérer les ressources et effectuer les actions d'OA&M pertinentes telles que de créer un enregistrement des tentatives de joindre une partie via divers moyens comme une ligne téléphonique terrestre, une téléphone cellulaire, un SMS, ou une recherche de personne).

De plus, les DP suivants sont pertinents pour les services de référence SPIRITS actuels :
- termination_attempt_authorized (tentative de terminaison autorisée)
- facility_selected_and_available (pourrait être utilisé dans l'identification SPIRITS de l'appelant Internet)
- t_busy (pour l'appel Internet en attente et la transmission d'appel Internet).

 	5.	Exigences relatives au réseau intelligent sans fil

IN sans fil couvre plusieurs types "d'appels," qui ne sont ni de circuit commuté ni n'ont d'effet sur les appels de circuit commuté. Pour cette raison, ils ne sont pas considérés dans les exigences de SPIRITS. Pour préciser ce point, les types "d'appels" non considérés sont :
-	USSD (Unstructured Supplementary Service Data) données de service supplémentaire non structurées
-	GPRS (General Packet Radio System) service général de radiocommunication en mode paquet
-	SMS (Short Message System) système de messages courts

Les types d'appels pertinents pour SPIRITS sont les suivants :

a)	Appels vocaux : dans ce cas, aucun nouveau DP n'est nécessaire car les DP CAMEL sont inclus dans CS2. Le seul cas particulier est "Non accessible" (quand il est détecté que l'usager mobile est en dehors de la couverture ou s'est déconnecté) qui est transposé comme cause particulière dans le DP occupé. Comme les paramètres de DP occupé vont être reçus (si un service SPIRITS s'est abonné à Busy) il va être possible de distinguer une situation "occupé" d'une "non accessible".
Ceci se traduit en l'exigence qu'un des paramètres dans le message de notification d'événement (du client SPIRITS à la passerelle SPIRITS, sur l'interface C) note la "cause" pour le point de détection occupé.
Un autre aspect de différence, par rapport au RTPC, est le réglage de DP statiques. Dans les réseaux CAMEL, ceci est fait dans le registre de localisation de rattachement (HLT, Home Location Register) (et copié dans le VLR durant la mise à jour de localisation). Il est important de noter cette différence, même si elle n'a pas d'effet sur le  protocole SPIRITS.

b)	Événements de gestion de mobilité : cela permet à un serveur SPIRITS d'avoir la notification des changements de localisation d'un utilisateur mobile. Les événements vont seulement être applicables aux utilisateurs mobiles accessibles à travers un réseau de commutation de circuits. Pour assurer cette fonction, les marques d'abonnement doivent être établies dans le HLR de l'abonné. Ceci est équivalent à établir les TDP dans le SSP. Dans ce cas, les marques dans le HLR (qui sont copiées dans le registre de localisation de visiteurs (VLR, Visitor Location Register) à la mise à jour de localisation) ne sont pas transposées dans les points de détection de déclenchement.
Comme avec le réglage de TDP, ceci sort du domaine d'application du protocole SPIRITS.
Afin de prendre en charge cette fonction dans SPIRITS, le protocole SPIRITS devrait être capable de transposer les opérations spécifiques de CAMEL en notification d'événements au client SPIRITS. Comme le SCP reçoit les informations sur l'état de mobilité, cela implique l'interface C. (Ceci est juste une extension du mécanisme de notification de DP du client SPIRITS à la passerelle SPIRITS).
Les événements (qui ne sont pas relatifs au DP) qui ont besoin de notifications sont :
-	Les mises à jour de localisation dans la même zone de service de VLR,
-	Les mises à jour de localisation dans une autre zone de service de VLR,
-	Le rattachement d'IMSI,
-	Le détachement d'IMSI initié par la station mobile,
-	Le détachement d'IMSI initié par le réseau.

Avec ce mécanisme, les services SPIRITS peuvent utiliser les informations de localisation fondées sur le profil d'utilisateur. Par exemple, le service d'appel Internet en attente peut rediriger l'appel sur un téléphone mobile.

c)	Notification de services supplémentaires : ce mécanisme permet à un serveur SPIRITS de savoir qu'un abonné a invoqué un des services supplémentaires suivants : Transfert d'appel explicite, Renvoi d'appel, Rappel automatique sur occupation, ou Multi parties.

 	6.	Exigences relatives à PINT

Avant qu'un service SPIRITS puisse être invoqué, l'hôte IP pertinent doit être enregistré. Donc, l'enregistrement est un service essentiel, qui est initié à partir du côté IP. Les informations d'enregistrement sont finalement utilisés par le RTPC pour authentifier l'abonné.

Selon le modèle, ceci peut être fait de deux façons avec la présente architecture:

1) Le client PINT produit le message Register approprié sur l'interface A, qui est alors passé par le serveur PINT à la passerelle SPIRITS et au client SPIRITS:

PINT C. : -- Register --> PINT S. [--> SPIRITS Gateway --> SPIRITS C.]. Dans ce cas, le client SPIRITS (colocalisé avec le contrôle de service) est chargé de garder l'enregistrement et de l'authentification.

2) Le client PINT produit le message Register approprié au serveur PINT, qui passe alors cette information au contrôle de service RTPC "par magie".

Le second modèle est plus facile à traiter, parce qu'il implique seulement une interface ("A") ; cependant, il suppose qu'il n'y a pas d'inter fonctionnement entre PINT et SPIRITS excepté que le client SPIRITS trouve "par magie" qu'un hôte IP amical et attendu est vivant et en bonne santé.

Finalement, dans le cas où PINT n'est pas mis en œuvre, le mécanisme SIP SUBSCRIBE peut être utilisé.

Comme noté dans la section précédente, les éléments de construction existants PINT SUBSCRIBE/NOTIFY [RFC2848] doivent être étendus pour être utilisés dans SPIRITS pour les besoins d'établissement des DP et obtenir les notifications d'événement de DP. (Un mécanisme SIP plus général pour le même bloc introduit par PINT est décrit dans la [RFC3265];  il donne le mécanisme nécessaire pour spécifier les événements pertinents.) À l'inverse, les mêmes blocs de construction pour les capacités fonctionnelles peuvent être utilisés dans les deux protocoles PINT et SPIRITS. Noter cependant que dans SPIRITS la notification du RTPC peut arriver sans abonnement particulier à un événement (dans le cas d'un DP établi de façon statique).

 	7.	Suite des notifications d'événement

Les exigences de cette Section ne sont spécifiques ni de PINT ni de l'IN ; leur rôle est de souligner les éléments restants qui sont nécessaires pour la fourniture du service SPIRITS, qui est la réaction à la notification reçue.

Dans un scénario particulier où :
a)	L'abonné IP enregistre un service SPIRITS ;
b)	Un appel déclenchant le service SPIRITS est reçu (et une notification est envoyée) ; 
c)	La disposition de l'appel est effectuée par l'utilisateur final, le flux de signalisation est montré à la Figure 2.

                      |----> Enregistrement      ----->|
   Passerelle SPIRITS |<-- Notification d'événement<-- | Client SPIRITS
                      |---> Disposition d'appel   ---->|
                      |                   |
                                          V
                                   Contrôle de service 
                                          |
                                          V
                                         SSP

Figure 2 : Séquence des actions SPIRITS

Une des actions suivantes est requise des services de référence :
a) Accepter l'appel entrant
b) Rejeter l'appel entrant
c) Rediriger l'appel entrant
d) Accepter l'appel via VoIP (cet élément particulier sort du domaine du groupe de travail SPIRITS).

En conséquence, le protocole SPIRITS devrait définir les types de message suivants :
a) S->G: <Accepter l'appel>
b) S->G: <[Rejeter l'appel],[Cause]>
c) S->G: <[Rediriger l'appel],[Destination de redirection]>

 	8.	Méthodologie

Pour déterminer le vocabulaire MINIMUM du protocole SPIRITS (c'est-à-dire, l'ensemble de messages) les événements RTPC associés à chaque point de détection du modèle d'état d'appel de base devraient être examinés. Aujourd'hui, le BSCM CS-3 a le plus riche ensemble de DP, bien que tous les commutateurs ne l'aient pas mis en œuvre.

Pour déterminer les informations MINIMUM disponibles au client SPIRITS (cette information est à porter par le protocole SPIRITS du client SPIRITS au serveur SPIRITS) chaque élément d'information spécifique de DP doit être examiné.

Les paramètres devraient être spécifiques de l'événement ; les types génériques de paramètres suivants sont supposés être obligatoires :
- temporisateur (pour la non réponse)
- information de contrôle à mi appel (pour mid_call)
- nombre de chiffres (pour les informations collectées)

 	9.	Considérations sur la sécurité

Globalement, les aspects de base de la sécurité s'appliquent au protocole SPIRITS :

-	Authentification : dans les communications entre le client SPIRITS et la passerelle SPIRITS ainsi qu'entre la passerelle SPIRITS et le serveur SPIRITS, il est exigé que les informations soient envoyées entre des partenaires connus et de confiance.

-	Intégrité : il est exigé qu'aucune des données échangées ne soit modifiée dans le transit.

-	Confidentialité : il est exigé que toute information privée d'utilisateur ou données confidentielles du réseau soient protégées par le protocole (normalement par le chiffrement, pour lequel le protocole devrait permettre un choix d'algorithmes.

-	Disponibilité : il est exigé que les points d'extrémité en communication restent en service seulement pour un usage autorisé.

De plus, le protocole devrait prendre en charge la non répudiation pour les messages de contrôle relevant de la facturation de l'abonné RTPC.

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 plus vulnérable aux attaques résultant en vol ou déni de service. L'interface C, est par ailleurs probablement mise en œuvre à travers des intranets de fournisseurs de services, où des mesures de sécurité devraient être appliquées à la discrétion du fournisseur de services. Même alors, parce que au moins un hôte IP (la passerelle PINT) est connectée à l'Internet, des mesures spéciales (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. Des exigences et solutions de sécurité détaillées pour l'interface A (et, par conséquent, B) se trouvent dans la [RFC2848].

Des attaques possibles peuvent résulter à la fois en le vol et le déni de services. De plus, de telles attaques peuvent violer  l'intimité d'un abonné du RTPC. Par exemple, avec l'appel Internet en attente, un enregistrement frauduleux (ou une manipulation de l'intégrité d'un enregistrement valide) peut forcer un opérateur de réseau à fournir à une partie autorisée un enregistrement complet de tentatives d'appels téléphoniques (accompagné de l'identification des appelants). De plus, les appels peuvent être livrés aux mauvais receveurs (qui peuvent ensuite tromper des appelants non soupçonneux). Dans ce cas, l'appelant utilise seulement le RTPC et s'attend donc à la sécurité des communications qui est normale sur le RTPC. Les fournisseurs de services RTPC peuvent être tenus pour responsables des conséquences de l'établissement de mauvaises connexions. De plus, les fournisseurs de services RTPC peuvent être tenus pour responsables de la divulgations involontaire d'informations privées de l'abonné.

Les fournisseurs de services et de réseau doivent revoir les possibilités d'attaques contre la sécurité et préparer les moyens de protection contre elles. Une partie de ces moyens peut être réalisée en utilisant des moyens hors de ceux fournis par le protocole lui-même. Par exemple, des informations administratives (comme les statistiques collectées par la MIB PINT ou SPIRITS) peuvent aider à déterminer des violations et à les déjouer. Pour autant que le protocole soit concerné, il doit fournir des moyens pour authentifier un abonné ainsi qu'une session. Il doit aussi fournir la capacité de porter des informations chiffrées dans son corps.

 	10.	Remerciements

Les auteurs remercient tous les participants au groupe SPIRITS de la discussion qui a structuré le présent travail. Un grand merci à Jorgen Bjorkner, Alec Brusilovsky, Jim Buller, Lawrence Conroy, Soren Nyckelgard, et John Voelker de leurs commentaires incisifs. Des remerciements particuliers sont dus à Vijay Gurbani, Dave Hewins, et Kumar Vemuri, dont la relecture attentive et détaillée de plusieurs versions de ce document a été particulièrement utile pour en améliorer la qualité.

 	11.	Références

[RFC2045]	N. Freed et N. Borenstein, "Extensions de messagerie Internet multi-objets (MIME) Partie 1 : Format des corps de message Internet", novembre 1996. (D. S., MàJ par 2184, 2231, 5335.)

[RFC2046]	N. Freed et N. Borenstein, "Extensions de messagerie Internet multi-objets (MIME) Partie 2 : Types de support", novembre 1996. (D. S., MàJ par 2646, 3798, 5147, 6657, 8098)

[RFC2327]	M. Handley et V. Jacobson, "SDP : Protocole de description de session", avril 1998. (Obsolète; voir RFC4566)

[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.)

[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.)

[RFC3136]	L. Slutsman, éd., "Architecture SPIRITS", juin 2001. (Information)

[RFC3265]	A.B. Roach, "Notification d'événement spécifique du protocole d'initialisation de session (SIP)", juin 2002. (MàJ par RFC6446) (Remplacée par la RFC6665) 

 	12.	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	
USA	USA	
téléphone : (732) 420-3752	téléphone : (732) 949-0137	
mél : lslutsman@att.com 	mél : faynberg@lucent.com 	

Jorge Gato	Hui-Lan Lu	
Vodaphone	Bell Labs/Lucent Technologies	
Avda de Europa, 1.	Room 4C-607A, 101 Crawfords Corner Road	
28108 Alcobendas (Madrid).	Holmdel, New Jersey, 07733	
Espagne	USA	
téléhone : +34 607 13 31 10	téléphone : (732) 949-0321	
mél : jgato@airtel.es 	mél : huilanlu@lucent.com 	

 	13.	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 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.