Groupe de travail Réseau	V. Gurbani, éditeur, Lucent Tech.	
Request for Comments : 3910	A. Brusilovsky, Lucent Technologies	
Catégorie : Sur la voie de la normalisation	I. Faynberg, Lucent Technologies 	
Traduction Claude Brière de L'Isle	J. Gato, Vodafone Espana	
	H. Lu, Bell Labs/Lucent Technologies	
	M. Unmehopa, Lucent Technologies	
	octobre 2004	

Protocole SPIRITS (services du RTPC qui demandent des services Internet)

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de Copyright
Copyright (C) The Internet Society (2004).

Résumé
Le présent document décrit le protocole des services dans le RTPC (réseau téléphonique public commuté) qui demandent des services Internet (SPIRITS). L'objet du protocole SPIRITS est de prendre en charge des services qui ont leur origine dans le RTPC cellulaire ou filaire et nécessitent des interactions entre le RTPC et l'Internet. Du côté du RTPC, les services SPIRITS sont le plus souvent initiés à partir d'entités du réseau intelligent (IN, Intelligent Network). L'appel Internet en attente et la livraison de l'identification de l'appelant Internet sont des exemples de services SPIRITS, comme le sont les services fondés sur la localisation sur le réseau cellulaire. Le protocole définit les éléments constitutifs à partir desquels de nombreux autres services peuvent être construits.
Table des matières
1. Introduction	2
1.1 Conventions utilisées dans le document	2
2. Vue d'ensemble du fonctionnement	2
2.1 Terminologie	4
3. Utilisation de XML pour la souscription et la notification	4
4. Définition du format XML	5
5. Événements en rapport avec l'appel	6
5.1 Exigences spécifiques du réseau intelligent	7
5.2 Points de détection et paramètres requis	7
5.3 Services par des DP dynamiques	10
5.4 Services par des DP statiques	16
6. Événements sans relation avec l'appel	18
6.1 Événements non d'appel et paramètres exigés	18
6.2 Usage normatif	18
6.3 Nom de paquetage d'événement	19
6.4 Paramètres de paquetage d'événement	19
6.5 Corps  SUBSCRIBE	19
6.6 Durée d'abonnement	19
6.7 Corps NOTIFY	19
6.8 Traitement par le notificateur des demandes SUBSCRIBE	20
6.9 Génération par le notificateur des demandes NOTIFY	20
6.10 Traitement par l'abonné des demandes NOTIFY	20
6.11 Traitement des demandes fourchées	20
6.12 Taux de notifications	20
6.13 Agents d'état	21
6.15 Utilisation des URI pour récupérer l'état	23
7. Considérations relatives à l'IANA	23
7.1 Enregistrement de paquetages d'événement	24
7.2 Enregistrement de type MIME	24
7.3 Enregistrement d'URN	24
7.4 Enregistrement de schéma XML	25
8. Considérations sur la sécurité	25
9. Définition de schéma XML	26
10. Remerciements	28
11. Acronymes	28
12. Références	29
12.1 Références normatives	29
12.2 Références pour information	29
13. Contributeur	30
14. Adresse des auteurs	30
15. Déclaration complète de droits de reproduction	30
 	1.	Introduction

SPIRITS (Services dans le RTPC qui demandent des services Internet) est une architecture de l'IETF et son protocole associé qui permet aux éléments de traitement d'appel dans le réseau téléphonique de faire des demandes de services qui sont alors traitées sur les serveurs hébergés dans l'Internet. Le terme de réseau téléphonique public commuté (RTPC) est utilisé ici comme incluant le réseau filaire à commutation de circuits, ainsi que le réseau à commutation de circuits sans fil.

Le travail antérieur de l'IETF sur l'interfonctionnement RTPC/Internet (PINT) a résulté en le protocole de la [RFC2848] qui prend en charge les services initiés dans la direction inverse - de l'Internet au RTPC.

Le présent document a été écrit en réponse à l'appel du président du groupe de travail SPIRITS à des propositions de protocole SPIRITS. Entre autres contributions, le présent document se fonde sur :
o	"Mises en œuvre pré SPIRITS" [RFC2995] pour information
o	"Architecture SPIRITS" [RFC3136] pour information
o	"Exigences pour le protocole SPIRITS" [RFC3298] pour information.

 	1.1	Conventions utilisées dans le 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 le BCP 14, [RFC2119].

 	2.	Vue d'ensemble du fonctionnement

L'objet du protocole SPIRITS est de permettre l'exécution de services dans l'Internet sur la base de certains événements qui se produisent dans le RTPC. Le terme de RTPC est utilisé ici comme incluant toutes les sortes de commutation ; c'est-à-dire des réseaux à commutation de circuit filaires, aussi bien que sans fil.

D'une façon générale, un hôte Internet est intéressé à obtenir des notifications de certains événements qui surviennent dans le RTPC. Quand l'événement intéressant survient, le RTPC le notifie à l'hôte Internet. L'hôte Internet peut exécuter les services appropriés sur la base de ces notifications.

                             +---------+
                             |Événement|
                             | du RTPC |
                             +---------+
                            /           \
                           /             \
                  +---------+             +-----------+
                  | Relatif |             |Non relatif|
                  |à l'appel|             | à l'appel |
                  +---------+             +--+--------+
                 /        \               |
                /          \              |
           +---/----+   +---\-----+    +--+-----------------+
           |Statique|   |Dynamique|    |Gestion de mobilité/|
           |        |   |         |    |enregistrement/Dés- |
           +--------+   +---------+    |enregistrement      |
                                       +--------------------+

Figure 1 : Hiérarchie SPIRITS

La Figure 1 contient la hiérarchie des événements SPIRITS, incluant leur subdivision en deux classes distinctes pour l'exécution du service : les événements relatifs à l'établissement, la suppression et la maintenance d'un appel et les événements sans relation avec l'établissement, la suppression et la maintenance d'un appel. Un exemple de la première classe d'événements est un événement de géolocalisation de mobilité qui est tracé par le RTPC cellulaire. SPIRITS va spécifier le cadre pour la fourniture de services pour ces deux types d'événements.

Les événements relatifs à l'appel, leurs subdivisions, et comment ils permettent des services dans l'Internet sont décrits à la Section 5. Les services permis à partir d'événements sans rapport avec l'établissement, la suppression et la maintenance d'un appel sont couverts en détails à la Section 6.

Pour référence, l'architecture SPIRITS de la [RFC3136] est reproduite ci-dessous. Le présent document se concentre seulement sur les interfaces B et C. L'interface D est une affaire de politique locale ; l'opérateur RTPC peut avoir une interface fonctionnelle entre le client SPIRITS ou une interface de passage de messages. Le présent document ne discute pas des détails de l'interface D.

             +--------------+
             | Hôte IP de   |
             | l'abonné     |              +--------------+
             |              |              |              |
             | +----------+ |              | +----------+ |
             | | Client   | |      A       | |Passerelle| |
             | |  PINT    +<-------/-------->+  PINT    +<-----+
             | +----------+ |              | +----------+ |    |
             |              |              |              |    |
             | +----------+ |              | +----------+ |    |
             | | Serveur  | |      B       | |Passerelle| |    |
             | |  SPITITS +<-------/-------->+ SPIRITS  | |    |
             | +----------+ |              | +--------+-+ |    |
             |              |              |          ^   |    |
             +--------------+              +----------|---+    |
                                                      |        |
                                    Réseau IP         |        |
            ------------------------------------------|--------|---
                                      RTPC            / C      / E
                                                      |        |
                                                      v        |
                                                 +----+------+ |
                                                 | Client    | |
                                                 | SPIRITS   | v
          +-----------------------+         +----+-----D-----+-+-+
          |Fonction de commutation|INAP/SS7 |Fonction de contrôle|
          |      de service       +---------+    de service      |
          +----+------------------+         +--------------------+
               |
               |ligne
               +-+
                [0] Téléphone de l'abonné

Figure 2 : Architecture SPIRITS

(Note : Les interfaces A-E sont décrites en détails dans le document d'architecture SPIRITS [RFC3136].)

Le RTPC prend en charge aujourd'hui des modèles de service comme le réseau intelligent (IN, Intelligent Network) dans lequel des caractéristiques sont exécutées localement sur des éléments de commutation appelés des points de commutation de service (SSP, Service Switching Point). D'autres caractéristiques sont exécutées sur des éléments de service appelés des points de contrôle de service (SCP, Service Control Point). L'architecture SPIRITS [RFC3136] permet à ces éléments de SCP d'agir comme des entités intelligentes pour développer et utiliser les hôtes et capacités de l'Internet pour améliorer encore le ressenti de l'utilisateur final du téléphone.

Le protocole utilisé sur les interfaces B et C consiste en le protocole SPIRITS, et se fonde sur SIP et la notification d'événement SIP [RFC3265]. Les exigences d'un protocole SPIRITS et le choix d'utiliser SIP comme faciliteur sont détaillés dans la [RFC3298].

Le protocole SPIRITS est un ensemble de deux "paquetages d'événements" [RFC3265]. Il contient les règles de procédure et le contexte sémantique qui doit être appliqué à ces règles pour le traitement des transactions SIP. Le protocole SPIRITS doit porter des abonnements aux événements du serveur SPIRITS au client SPIRITS et aux notifications de ces événements du client SPIRITS au serveur SPIRITS. Le langage de balisage extensible (XML, Extensible Markup Language) [XML-STR] est utilisé pour codifier les abonnements et notifications.

Finalement, dans le contexte de la discussion qui suit, les termes "serveur SPIRITS" et "client SPIRITS" sont un peu ambigus car les rôles apparaissent inversés ; en fait, le "serveur SPIRITS" produit un abonnement qui est accepté par un "client SPIRITS". Pour réduire cette ambiguïté, à partir d'ici, on se référera au "serveur SPIRITS" comme à un "abonné SPIRITS" et au "client SPIRITS" comme à un "notificateur SPIRITS". Cette convention respecte la nomenclature de la [RFC3265] ; le serveur SPIRITS de la Figure 2 est un abonné (il produit les souscriptions aux événements) et le client SPIRITS de la Figure 2 est un notificateur (il produit les notifications chaque fois que se produit l'événement intéressant).

 	2.1	Terminologie
Pour faciliter les références, on donne la terminologie des acteurs SPIRITS discutés ci-dessus :

SCF (Service Control Function) : fonction de contrôle de service. Entité du RTPC qui exécute une logique de service. Elle donne des capacités d'influencer le traitement d'appel qui survient dans la fonction de commutation de service (SSF, Service Switching Function). Plus d'informations sur la façon dont une SCF participe à l'architecture SPIRITS figurent à la Section 5 et au paragraphe 5.1.

Client SPIRITS : voir notificateur SPIRITS.

Serveur SPIRITS : voir abonné SPIRITS.

Notificateur SPIRITS : agent d'utilisateur (UA, User Agent) dans le RTPC qui accepte des abonnements provenant des abonnés SPIRITS. Ces abonnements contiennent des événements pour lesquels les abonnés SPIRITS sont intéressés à recevoir une notification. Les interfaces du notificateur SPIRITS avec la fonction de contrôle de service font que quand le dit événement se produit, une notification va être envoyée à l'abonné SPIRITS pertinent.

Abonné SPIRITS : un UA dans l'Internet qui produit un abonnement contenant des événements dans le RTPC dont il est intéressé à recevoir la notification.

 	3.	Utilisation de XML pour la souscription et la notification

Les exigences du protocole SPIRITS imposent que les paramètres relatifs à "SPIRITS soient portés de façon cohérente avec les pratiques de SIP" (Section 3 de la RFC3298). SIP fournit déjà des capacités de description de charge utile par l'utilisation des en-têtes (Type de contenu, Longueur de contenu). Le présent document définit un nouveau type MIME -- "application/spirits-event+xml" -- et l'enregistre auprès de l'IANA (Section 7). Ce type MIME DOIT être présent dans l'en-tête "Type de contenu" des demandes et réponses SPIRITS, et il décrit un document XML qui contient des informations relatives à SPIRITS.

Le présent document définit un schéma XML de base pour les abonnements aux événements du RTPC. La liste des événements auxquels il est possible de s'abonner est définie dans le document des exigences du protocole SPIRITS [RFC3298] et le présent document fournit un schéma XML pour elle. Tous les abonnés SPIRITS (toute entité SPIRITS capable de produire une demande SUBSCRIBE, REGISTER, ou INVITE) DOIT prendre ce schéma en charge. Tous les notificateurs SPIRITS (toute entité SPIRITS capable de recevoir et traiter une demande SUBSCRIBE, REGISTER, ou INVITE) DOIT prendre ce schéma en charge. Le schéma est défini à la Section 9.

La prise en charge de la demande SIP REGISTER est incluse pour la compatibilité avec PINT (RFC3298, Section 6).

La prise en charge de la demande SIP INVITE est obligatoire parce que les mises en œuvre SPIRITS pré existantes n'utilisaient pas le schéma de notification d'événement SIP. À la place, le point de détection initial RTPC arrivait toujours via la demande SIP INVITE.

Le présent document définit aussi un schéma XML de base pour les notifications d'événements (Section 9). Tous les notificateurs SPIRITS DOIVENT générer des documents XML qui correspondent au schéma de notification de base. Tous les abonnés SPIRITS DOIVENT prendre en charge les documents XML qui correspondent à ce schéma.

L'ensemble d'événements qui peuvent faire l'objet d'un abonnement et la quantité de notifications qui sont retournées par l'entité RTPC peuvent varier entre les différents opérateurs RTPC. Certains opérateurs RTPC peuvent avoir un riche ensemble d'événements qui peuvent faire l'objet d'un abonnement, tandis que d'autres vont seulement avoir l'ensemble primitif d'événements mentionné dans le document d'exigences du protocole SPIRITS [RFC3298]. Le présent document définit un schéma XML de base (Section 9) qui DOIT être utilisé pour l'abonnement et la notification de l'ensemble primitif d'événements. Afin de prendre en charge un plus riche ensemble d'abonnements et notifications d'événements, les mises en œuvre PEUVENT utiliser des espaces de noms XML supplémentaires correspondant à d'autres schémas dans un document XML SPIRITS. Cependant, toutes les mises en œuvre DOIVENT prendre en charge le schéma XML de base défini à la Section 9 du présent document. L'utilisation du schéma de base assure l'interopérabilité des mises en œuvre, et l'inclusion d'espaces de noms XML supplémentaires permet la personnalisation.

Un flux logique du protocole SPIRITS est décrit ci-dessous (note : cet exemple montre un flux temporel ; la syntaxe des documents XML et du protocole SPIRITS en rapport est spécifiée plus loin dans ce document). Dans le flux ci-dessous, S est l'abonné SPIRITS et N est le notificateur SPIRITS. La passerelle SPIRIT est supposée avoir une pure fonctionnalité de mandataire et est donc omise pour simplifier la présentation :

1  S->N Subscribe (événements d'intérêt dans une instance de document XML en utilisant le schéma d'abonnement de base)
2  N->S 200 OK (Subscribe)
3  N->S Notify
4  S->N 200 OK (Notification communiquant l'état de ressource actuel)
5  ...
6  N->S Notify ( Notification communiquant un changement de l'état de ressource ; la charge utile est une instance de document XML utilisant des extensions XML au schéma de notification de base)
7  S->N 200 OK (Notify)

À la ligne 1, l'abonné SPIRITS s'abonne à certains événements en utilisant un document XML sur la base du schéma de base défini dans ce document. À la ligne 6, le notificateur SPIRITS notifie à l'abonné SPIRITS l'occurrence de l'événement en utilisant des extensions au schéma de notification de base. Noter que le présent document définit aussi un schéma de base pour la notification d'événement ; le notificateur SPIRITS pourrait en profiter. Au lieu de cela, il choisit de passer à l'abonné SPIRITS un document XML composé des extensions au schéma de notification de base. L'abonné SPIRITS, si il comprend les extensions, peut interpréter le document XML en conséquence. Cependant, dans le cas où l'abonné SPIRITS n'est pas programmé à comprendre les extensions, il DOIT rechercher dans le document XML les éléments obligatoires. Ces éléments DOIVENT être présents dans tous les schémas de notification et sont détaillés à la Section 9.

 	4.	Définition du format XML

Cette section définit le format de charge utile SPIRITS codée en XML. Une telle charge utile est un document XML bien formé et est produite par les notificateurs SPIRITS et les abonnés SPIRITS.

L'URI d'espace de noms pour les éléments définis dans ce document est un nom de ressource universelle (URN, Uniform Resource Name) [RFC2141], utilisant l'identifiant d'espace de noms 'ietf' défini dans la [RFC2648] et étendu par la [RFC3688] :

urn:ietf:params:xml:ns:spirits-1.0

Les documents XML SPIRITS peuvent avoir un espace de noms par défaut, ou ils peuvent être associés à un préfixe d'espace de noms suivant les conventions établies dans "Espaces de noms XML" [XML-NOM]. De toutes façons, les éléments et attributs des documents XML SPIRITS DOIVENT se conformer au schéma XML SPIRITS spécifié à la Section 9.

Élément <spirits-event> :
La racine d'un document XML SPIRITS (caractérisé par un en-tête Content-Type de "application/spirits-event+xml">) est l'élément <spirits-event>. Cet élément DOIT contenir une déclaration d'espace de noms ('xmlns') pour indiquer l'espace de noms sur lequel le document XML se fonde. Les documents XML conformes au protocole SPIRITS DOIVENT contenir l'URN "urn:ietf:params:xml:ns:spirits-1.0" dans la déclaration d'espace de noms. D'autres espaces de noms peuvent être spécifiés comme de besoin.

L'élément <spirits-event> DOIT contenir au moins un élément <Event>, et PEUT en contenir plus d'un.

Élément <Event> :
L'élément <Event> contient trois attributs, dont deux sont obligatoires. Le premier attribut obligatoire est un attribut 'type' dont la valeur est "INDPs" ou "userprof".

Ces types correspondent, respectivement, aux événements relatifs à l'appel décrits à la Section 5 et aux événements non relatifs à l'appel décrits à la Section 6.

Le second attribut obligatoire est un attribut 'name'. Les valeurs de cet attribut DOIVENT être limitées aux mnémoniques SPIRITS définis aux paragraphes 5.2.1, 5.2.2, et 6.1.

Le troisième attribut, qui est facultatif, est un attribut 'mode'. La valeur de 'mode' est "N" ou "R", correspondant respectivement à (N)otification ou (R)equête (RFC3298, Section 4). La valeur par défaut de cet attribut est "N".

Si l'attribut 'Type' de l'élément <Event> est "INDPs", il DOIT alors contenir au moins un ou plusieurs des éléments suivants (les éléments inconnus PEUVENT être ignorés) : <CallingPartyNumber>, <CalledPartyNumber>, <DialledDigits>, ou <Cause>. Ces éléments sont définis au paragraphe 5.2 ; ils NE DOIVENT PAS contenir d'attribut et NE DOIVENT PAS être utilisés comme éléments parents. Ces éléments contiennent une valeur de chaîne comme décrit aux paragraphes 5.2.1 et 5.2.2.

Si l'attribut 'Type' de l'élément <Event> est "userprof", il DOIT alors contenir un élément <CalledPartyNumber> et il PEUT contenir un élément <Cell-ID>. Aucun de ces éléments ne contient d'attribut ni ne doit être utilisé comme élément parent. Ces éléments contiennent une valeur de chaîne comme décrit au paragraphe 6.1. Tous les autres éléments PEUVENT être ignorés si ils ne sont pas compris.

Un document XML conforme à SPIRITS utilisant l'espace de noms XML défini dans le présent document pourrait ressembler à l'exemple suivant :

<?xml version="1.0" encoding="UTF-8"?>
<spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
   <Event type="INDPs" name="OD" mode="N">
      <CallingPartyNumber>5551212</CallingPartyNumber>
   </Event>
   <Event type="INDPs" name="OAB" mode="N">
      <CallingPartyNumber>5551212</CallingPartyNumber>
   </Event>
</spirits-event>

 	5.	Événements en rapport avec l'appel

Pour les lecteurs qui pourraient n'être pas familiarisés avec les aspects d'exécution de service du RTPC/IN, on fournit ici une brève explication. Les lecteurs intéressés sont invités à consulter [IN-STD] sur le traitement détaillé de ce sujet.

Les services dans le RTPC/IN sont exécutés sur la base d'un modèle d'appel. Un modèle d'appel est un automate à états finis utilisé dans les SSP et autres éléments de traitement d'appel qui reflète précisément et de façon concise l'état actuel d'un appel à un instant donné. Les modèles d'appel consistent en états appelés des points d'appel (PIC, Point In Call) et des transitions entre les états. Les transitions entre les états passent à travers les éléments appelés des points de détection (DP, Detection Point). Les DP hébergent un ou plusieurs déclencheurs. Chaque déclencheur a un critère de déclenchement associé. Quand un déclencheur est armé (rendu actif) et quand ses critères de déclenchement associés sont satisfaits, il se déclenche. Les particularités des critères de déclenchement peuvent varier sur la base du modèle d'appel pris en charge. Quand un déclencheur se déclenche, un message est formaté avec des informations d'état d'appel et est transmis par le SSP au SCP. Le SCP lit alors ces données relatives à l'appel et génère une réponse que le SSP utilise alors dans la suite du traitement de l'appel.

Les points de détection sont de deux types : les points de détection de déclenchement (TDP, Trigger Detection Point), et les points de détection d'événement (EDP, Event Detection Point). Les TDP sont provisionnés avec des déclencheurs armés de façon statique (armés par des outils de gestion de service). Les EDP sont armés dynamiquement (armés par le SCP lorsque se fait le traitement d'appel). Les DP peuvent aussi être classés comme des DP de "Requête" ou de "Notification". Donc, on peut avoir des TDP-R, TDP-N, EDP-R et EDP-N.

Le type "-R" de DP exige que le SSP suspende le traitement d'appel quand est initiée une communication avec le SCP. Le traitement d'appel reprend quand une réponse est reçue. Le type "-N" de DP permet au SSP de continuer le traitement de l'appel quand le déclencheur se déclenche, après quoi il envoie le message au SCP, notifiant qu'un certain événement s'est produit.

Les modèles d'appel prennent normalement en charge différents types de points de détection. Noter qu'alors que le modèle d'appel INAP et l'ensemble de capacités n ° 2 de réseau intelligent (CS-2) [Q.1228] sont utilisés dans le présent document comme des exemples, et pour faciliter d'explication, d'autres modèles d'appel possèdent des propriétés similaires. Par exemple, le modèle d'appel de réseau intelligent sans fil (WIN, Wireless Intelligent Network) prend aussi en charge l'armement dynamique des déclencheurs. Donc, l'essence de cette discussion ne s'applique pas qu'au domaine filaire, mais également au domaine sans fil.

Quand le SCP reçoit le message formaté INAP du SSP, si le SCP prend en charge l'architecture SPIRITS, il peut  coder le contenu du message INAP en un message de protocole SPIRITS qui est alors transmis aux éléments à capacité SPIRITS dans le réseau IP. De même, quand il reçoit des réponses de la part des dits éléments à capacité SPIRITS, il peut reformater le contenu de la réponse en format INAP et retransmettre ces messages aux SSP. Donc, le traitement d'inter conversion et/ou codage entre les paramètres INAP et le protocole SPIRITS est d'un intérêt crucial.

Un SCP est une manifestation physique de la fonction de contrôle de service. Un SSP est une manifestation physique de la fonction de commutation de service (et de la fonction de commande d'appel). Pour prendre en charge l'uniformité de nomenclature entre les divers projets SPIRITS, on utilisera les termes SCP et SCF, et SSP et SSF de façon interchangeable dans le présent document.

 	5.1	Exigences spécifiques du réseau intelligent
La Section 4 de la [RFC3298] mentionne les exigences relatives au réseau intelligent pour le protocole SPIRITS. La demande SUBSCRIBE qui arrive au notificateur SPIRITS DOIT contenir les événements à surveiller (sous la forme d'une liste de DP) le mode (demande ou notification, la différence étant que pour une demande, l'abonné SPIRITS peut  influencer le traitement suivant de l'appel et pour une notification, aucune autre influence n'est nécessaire) et tous les paramètres relatifs au DP.

La Section 4 de la [RFC3298] énumère aussi une liste des DP de l'ensemble de capacités n ° 3 (CS-3, Capability Set 3) pour les services SPIRITS. Il est exigé (RFC3298, Section 4) que le protocole SPIRITS spécifie les paramètres pertinents des DP. Ces DP et leurs paramètres pertinents à porter dans une demande SUBSCRIBE sont codifiés dans un schéma XML. Tous les abonnés SPIRITS DOIVENT comprendre ce schéma pour souscrire aux DP dans le RTPC. Le schéma est défini à la Section 9.

Quand un DP fonctionne, une notification – utilisant une demande SIP NOTIFY -- est transmise du notificateur SPIRITS à l'abonné SPIRITS. La demande NOTIFY contient un document XML qui décrit le DP qui a fonctionné et tous les paramètres pertinents. Les DP et leurs paramètres pertinents à porter dans une demande NOTIFY sont codifiés dans un schéma XML. Tous les notificateurs SPIRITS DOIVENT comprendre ce schéma ; ce schéma PEUT être étendu. Le schéma est défini à la Section 9.

De plus, les appendices A et B de [IN-PARA] contiennent un sous ensemble choisi de DP CS-2 qui peuvent être intéressants pour le lecteur. Cependant, le présent document se référera seulement aux DP CS-3 mentionnés dans la [RFC3298].

 	5.2	Points de détection et paramètres requis
Les DP IN CS-3 envisagés pour les services SPIRITS (RFC3298, Section 4) sont décrits ci-après. Les DP IN sont caractérisés par de nombreux paramètres, cependant, tous ces paramètres ne sont pas exigés -- ou même nécessaires -- par SPIRITS. Cette section, fait donc la liste des paramètres obligatoires pour chaque DP qui DOIT être spécifié dans les abonnements et les notifications. Les mises en œuvre peuvent spécifier des paramètres supplémentaires comme extensions XML associées à un espace de noms privé (ou public et normalisé).

La liste exhaustive des DP IN CS-3 et de leurs paramètres se trouve dans la Recommandation UIT-T [Q.1238].

Chaque DP a un mnémonique spécifique de SPIRITS à utiliser dans les abonnements et notifications.

 	5.2.1	DP du côté d'origine
Origination Attempt Authorized : tentative de génération autorisée
Mnémonique SPIRITS : OAA
Paramètre obligatoire dans SUBSCRIBE : CallingPartyNumber (numéro d'appelant)
Paramètres obligatoires in NOTIFY: CallingPartyNumber, CalledPartyNumber (numéro d'appelé)
CallingPartyNumber : chaîne utilisée pour identifier la partie appelante dans l'appel. La longueur réelle et le codage de ce paramètre dépendent des particularités du plan de numérotage utilisé.
CalledPartyNumber : chaîne contenant le numéro (par exemple, le numéro d'annuaire appelé) utilisé pour identifier la partie appelée. La longueur réelle et le codage de ce paramètre dépendent des particularités du plan de numérotage utilisé.

Collected Information : informations collectées
Mnémonique SPIRITS : OCI
Paramètre obligatoire dans SUBSCRIBE : CallingPartyNumber
Paramètres obligatoires dans NOTIFY : CallingPartyNumber, DialledDigits (chiffres numérotés)
DialledDigits : ce paramètre contient des informations d'adresse non traduites collectées/reçues de utilisateur/ligne/circuit d'origine.

Analyzed Information : informations analysées
Mnémonique SPIRITS : OAI
Paramètre obligatoire dans SUBSCRIBE : CallingPartyNumber
Paramètres obligatoires dans NOTIFY : CallingPartyNumber, DialledDigits

Origination Answer : origine de réponse
Mnémonique SPIRITS : OA
Paramètre obligatoire dans SUBSCRIBE : CallingPartyNumber
Paramètres obligatoires dans NOTIFY : CallingPartyNumber, CalledPartyNumber

Origination Term Seized : terme d'origine saisi
Mnémonique SPIRITS: OTS
Paramètre obligatoire dans SUBSCRIBE : CallingPartyNumber
Paramètre obligatoire dans NOTIFY : CallingPartyNumber, CalledPartyNumber

Origination No Answer : pas de réponse à l'origine
Mnémonique SPIRITS : ONA
Paramètre obligatoire dans SUBSCRIBE : CallingPartyNumber
Paramètre obligatoire dans NOTIFY : CallingPartyNumber, CalledPartyNumber

Origination Called Party Busy : appelé occupé
Mnémonique SPIRITS : OCPB
Paramètre obligatoire dans SUBSCRIBE : CallingPartyNumber
Paramètres obligatoires dans NOTIFY : CallingPartyNumber, CalledPartyNumber

Route Select Failure : échec de choix de chemin
Mnémonique SPIRITS : ORSF
Paramètre obligatoire dans SUBSCRIBE : CallingPartyNumber
Paramètre obligatoire dans NOTIFY : CallingPartyNumber, CalledPartyNumber

Origination Mid Call : services de mi-appel à l'origine
Mnémonique SPIRITS : OMC
Paramètre obligatoire dans SUBSCRIBE : CallingPartyNumber
Paramètre obligatoire dans NOTIFY : CallingPartyNumber

Origination Abandon : abandon de l'appel à l'origine
Mnémonique SPIRITS : OAB
Paramètre obligatoire dans SUBSCRIBE : CallingPartyNumber
Paramètre obligatoire dans NOTIFY : CallingPartyNumber

Origination Disconnect : origine déconnectée
Mnémonique SPIRITS : OD
Paramètre obligatoire dans SUBSCRIBE : CallingPartyNumber
Paramètre obligatoire dans NOTIFY : CallingPartyNumber, CalledPartyNumber

 	5.2.2	DP du côté de terminaison
Termination Answer : réponse de la terminaison
Mnémonique SPIRITS : TA
Paramètre obligatoire dans SUBSCRIBE : CalledPartyNumber
Paramètres obligatoires dans NOTIFY : CallingPartyNumber, CalledPartyNumber

Termination No Answer : pas de réponse de la terminaison
Mnémonique SPIRITS : TNA 
Paramètre obligatoire dans SUBSCRIBE : CalledPartyNumber
Paramètres obligatoires dans NOTIFY : CallingPartyNumber, CalledPartyNumber

Termination Mid-Call : services de mi-appel à la terminaison
Mnémonique SPIRITS : TMC
Paramètre obligatoire dans SUBSCRIBE : CalledPartyNumber
Paramètre obligatoire dans NOTIFY : CalledPartyNumber

Termination Abandon : abandon à la terminaison
Mnémonique SPIRITS : TAB
Paramètre obligatoire dans SUBSCRIBE : CalledPartyNumber
Paramètre obligatoire dans NOTIFY : CalledPartyNumber

Termination Disconnect : déconnexion à la terminaison
Mnémonique SPIRITS : TD
Paramètre obligatoire dans SUBSCRIBE : CalledPartyNumber
Paramètres obligatoires dans NOTIFY : CalledPartyNumber, CallingPartyNumber

Termination Attempt Authorized : tentative autorisée à la terminaison
Mnémonique SPIRITS : TAA
Paramètre obligatoire dans SUBSCRIBE : CalledPartyNumber
Paramètres obligatoires dans NOTIFY : CalledPartyNumber, CallingPartyNumber

Termination Facility Selected and Available : facilité retenue et disponible à la terminaison
Mnémonique SPIRITS : TFSA
Paramètre obligatoire dans SUBSCRIBE : CalledPartyNumber
Paramètre obligatoire dans NOTIFY : CalledPartyNumber

Termination Busy : terminaison occupée
Mnémonique SPIRITS : TB
Paramètre obligatoire dans SUBSCRIBE : CalledPartyNumber
Paramètres obligatoires dans NOTIFY : CalledPartyNumber, CallingPartyNumber, Cause.
Cause : ce paramètre contient une valeur de chaîne de "Occupé" ou "Injoignable". La différence entre elles est traduite comme une exigence (RFC3298, Section 5) pour aider l'abonné SPIRITS à déterminer si l'appelé est bien occupé, ou si il est indisponible (comme il le serait si il était sur le RTPC cellulaire et que l'abonné mobile ne soit pas enregistré sur le réseau.

 	5.3	Services par des DP dynamiques
Les déclencheurs dans le RTPC peuvent être armés dynamiquement, souvent en-dehors du contexte d'un appel. Le mécanisme de notification d'événement SI¨P [RFC3265] est donc un moyen commode pour exploiter les cas où les déclencheurs hébergés dans des EDP expirrnte (voir la Section 3 de la [RFC3298]). Noter que la [RFC3298] utilise le terme "persistent" pour se référer à l'armement du DP relatif à l'appel et aux interactions associées.

Le paquetage d'événements SIP permet aux points d'extrémité IP (ou hôtes) de s'abonner et recevoir les notifications suivantes des événements survenant dans le RTPC. Par référence à la Figure 2, cela inclut des communications sur les interfaces marquées "B" et "C".

 	5.3.1	Usage normatif
Un abonné va produire une demande SUBSCRIBE qui identifie un ensemble d'événements (de DP) pour lesquels il est intéressé à obtenir la notification. Cet ensemble DOIT contenir au moins un DP, il PEUT en contenir plus d'un. La demande SUBSCRIBE est acheminée au notificateur, où elle est acceptée, sous réserve de la réussite de l'authentification.

Quand un des DP identifiés dans l'ensemble d'événements se déclenche, le notificateur formate une demande NOTIFY et la dirige sur l'abonné. La demande NOTIFY va contenir les informations pertinentes pour l'événement déclenché. Les DP non rencontrés DOIVENT être ensuite désarmés par le notificateur SPIRITS et/ou la SCF.

Le dialogue établi par le SUBSCRIBE se termine quand l'événement intéressant se produit et cette notification est passée à l'abonné par une demande NOTIFY. Si l'abonné est intéressé par de futures occurrences du même événement, il DOIT produire une nouvelle demande SUBSCRIBE, établissant un nouveau dialogue.

Quand l'abonné reçoit une demande NOTIFY, il peut  ensuite choisir d'agir d'une manière appropriée à la notification.

Les paragraphes suivants traitent des responsabilités spécifiques de paquetage évoquées au paragraphe 4.4 de la [RFC3265].

 	5.3.2	Nom de paquetage d'événement
Le présent document définit deux paquetages d'événements ; le premier est défini dans ce paragraphe et est appelé "spirits-INDPs". Ce paquetage DOIT être utilisé pour les événements correspondants aux points de détection IN dans le RTPC cellulaire ou filaire. Toutes les entités qui mettent en œuvre le protocole SPIRITS et prennent en charge les points de détection IN DOIVENT régler l'en-tête de demande "Event" [RFC3265] à "spirits-INDPs". L'en-tête général "Allow-Events" [RFC3265] DOIT inclure le jeton "spirits-INDPs" si l'entité met en œuvre le protocole SPIRITS et prend en charge les points de détection IN.

Event: spirits-INDPs
Allow-Events: spirits-INDPs

Le second paquetage d'événement est défini et discuté à la Section 6.

 	5.3.3	Paramètres de paquetage d'événement
Le paquetage d'événement "spirits-INDPs" ne prend pas en charge de paramètre supplémentaire dans l'en-tête Event.

 	5.3.4	Corps SUBSCRIBE
Les demandes SUBSCRIBE qui servent à terminer l'abonnement PEUVENT contenir un corps vide ; cependant, les demandes SUBSCRIBE qui établissent un dialogue DOIVENT contenir un corps qui code trois éléments d'information :

(1) L'ensemble d'événements (de DP) qui est souscrit. Un abonné PEUT souscrire à plusieurs DP dans une demande SUBSCRIBE, ou PEUT produire une demande SUBSCRIBE différente pour chaque DP dont il est intéressé à recevoir la notification. Le protocole permet les deux formes de représentation, cependant, il recommande la première manière de souscrire aux DP si le service dépend du déclenchement d'un des DP.

(2) À cause de l'exigence [RFC3298] que l'IN soit informé de si le point de détection est réglé comme demande ou notification, tous les événements dans le paquetage "spirits-INDPs" (mais pas dans le paquetage "spirits-user-prof") sont obligés de fournir un paramètre "mode", dont les valeurs sont "R" (pour requête) et "N" pour notification.

(3) Une liste des valeurs des paramètres associés aux point de détection d'événement. (Note : le terme "événement" se réfère ici à l'usage IN – un DP armé dynamiquement est appelé un point de détection d'événement). Voir aux paragraphes 5.2.1 et 5.2.2 la liste des paramètres associés à chaque DP.

Le type de coprs par défaut pour les SUBSCRIBE dans SPIRITS est noté par le type MIME "application/spirits-event+xml". L'en-tête "Accept", si présent, DOIT inclure ce type MIME.

 	5.3.5	Durée d'abonnement
Pour le paquetage "spirits-INDPs", l'objet de la demande SUBSCRIBE est d'armer le DP, car pour ce qui concerne le réseau intelligent, être armé est le premier pré-requis essentiel. Un DP peut être armé statiquement (par exemple, par un provisionnement de service) ou dynamiquement (par la SCF). Un DP armé statiquement reste armé jusqu'à ce qu'il soit désarmé de façon active. Un DP armé dynamiquement reste armé pour la durée d'un appel (ou plus précisément, par plus longtemps que la durée d'une relation SSF-SCF particulière).

Les DP armés dynamiquement sont automatiquement désarmés quand l'événement intéressant se produit chez le notificateur. Il  appartient à l'abonné de réarmer les DP dans le contexte d'un appel, si il le désire.

Les DP armés statiquement sont considérés sortir du domaine d'application des exigences du protocole SPIRITS [RFC3298] et donc il n'en sera pas plus question.

 	5.3.6	Corps NOTIFY
Les corps dans les demandes NOTIFY pour le paquetage "spirits-INDPs" sont facultatifs. Si il en est présents, ils DOIVENT être du type MIME "application/spirits-event+xml". Le corps dans une demande NOTIFY encapsule les éléments d'informations suivants qui peuvent être utilisés par l'abonné:

(1) L'événement qui a résulté en la génération du NOTIFY (normalement, mais pas toujours, cela va être le même événement que celui présent dans la demande SUBSCRIBE correspondante).

(2) Le paramètre "mode" ; il est simplement reflété de la demande SUBSCRIBE correspondante.

(3) Une liste des valeurs des paramètres associés à l'événement pour lequel le NOTIFY est généré. Selon l'événement, la liste des paramètres va varier.

Si l'abonné a armé plusieurs DP au titre d'une seule demande SUBSCRIBE, tous les DP non rencontrés qui faisaient partie du même dialogue SUBSCRIBE DOIVENT être désarmés par le notificateur SPIRITS et/ou la SCF/SCP.

 	5.3.7	Traitement des demandes SUBSCRIBE par le notificateur
Quand le notificateur reçoit une demande SUBSCRIBE, il DOIT authentifier la demande et s'assurer que l'abonné est autorisé à accéder à la ressource qui fait l'objet de l'abonnement, dans ce cas, les événements RTPC/IN sur une certaine ligne du RTPC.

Une fois la demande SUBSCRIBE authentifiée et autorisée, le notificateur s'interface avec la SCF sur l'interface D pour armer les points de détection correspondant à la ligne RTPC contenue dans le corps SUBSCRIBE. Les particularités de l'interface D sortent du domaine d'application du présent document ; on va simplement supposer ici que le notificateur peut  effectuer l'armement (et le désarmement) des déclencheurs dans le RTPC à travers l'interface D.

 	5.3.8	Génération par le notificateur des demandes NOTIFY
Si le notificateur s'attend à ce que l'armement des déclencheurs prenne plus de 200 ms, il DOIT immédiatement envoyer une réponse 202 à la demande SUBSCRIBE, pour accepter l'abonnement. Il devrait alors envoyer une demande NOTIFY avec un corps vide. Cette demande NOTIFY DOIT avoir un en-tête "Subscription-State" (état d'abonnement) avec une valeur de "pending" (en cours).

Ce NOTIFY immédiat avec un corps vide est nécessaire car les ressources identifiées dans la demande SUBSCRIBE n'ont pas encore un état significatif.

Une fois que le notificateur a réussi à s'interfacer avec la SCF, il DOIT envoyer une demande NOTIFY suivante avec un corps vide et un en-tête "Subscription-State" d'une valeur de "active" (actif).

Quand l'événement intéressant identifié dans la demande SUBSCRIBE se produit, le notificateur envoie une nouvelle demande NOTIFY qui DOIT contenir un corps (voir au paragraphe 5.3.6). La demande NOTIFY DOIT avoir un en-tête "Subscription-State" et sa valeur DOIT être réglée à "terminated" (terminé) avec un paramètre de raison de "fired" (expiré).

 	5.3.9	Traitement par l'abonné des demandes NOTIFY
Les étapes exactes exécutées chez l'abonné quand il reçoit une demande NOTIFY vont dépendre du service mis en œuvre. En général, l'UA associé à l'abonné devrait communiquer ces informations à l'utilisateur par des moyens visuels ou auditifs, si c'est possible.

Si la demande NOTIFY contenait un en-tête "Subscription-State" avec une valeur de "terminated" et un paramètre de raison de "fired", l'UA associé à l'abonné PEUT initier un nouvel abonnement pour l'événement qui vient d'être rapporté par la demande NOTIFY.

Il revient au contexte du service mis en œuvre de déterminer d'initier ou non un nouvel abonnement quand un existant expire. Par exemple, un utilisateur peut configurer son UA à toujours se réabonner au même événement quand il arrive à expiration, mais ce n'est pas nécessairement le cas général.

 	5.3.10	Traitement des demandes fourchées
Le fourchement des demandes SUBSCRIBE est interdit. Comme la demande SUBSCRIBE est ciblée sur le RTPC, des comportements très irréguliers se produisent si il est permis à une demande de fourcher. Les règles normales de recherche et d'acheminement du DNS de SIP [RFC3263] devraient résulter en un ensemble cible avec exactement un élément : le notificateur.

 	5.3.11	Taux de notifications
Pour des raisons de sécurité plus que de trafic réseau, il est RECOMMANDÉ que le notificateur produise deux ou, au plus trois, demandes NOTIFY pour un abonnement. Si l'abonnement a été accepté avec une réponse 202, un NOTIFY va être immédiatement envoyé à l'abonné. Ce NOTIFY sert à informer l'abonné que la demande a été acceptée et est en cours de traitement.

Une fois que la ressource (points de détection) identifiée dans la demande SUBSCRIBE a été initialisée, le notificateur DOIT envoyer une seconde demande NOTIFY. Cette demande contient l'état de base de la ressource.

Quand un événement intéressant se produit et conduit à l'expiration du déclencheur associé aux points de détection identifiés dans la demande SUBSCRIBE, un NOTIFY final est envoyé à l'abonné. Cette demande NOTIFY contient plus d'informations sur l'événement intéressant.

Si l'abonnement a été accepté avec une réponse 200, le notificateur envoie simplement deux demandes NOTIFY : une contenant l'état de base de la ressource, et l'autre contenant les informations qui conduisent à l'expiration du point de détection.

 	5.3.12	Agents d'état
Les agents d'état ne sont pas utilisés dans SPIRITS.

 	5.3.13	Exemples
Ce paragraphe contient des exemples de flux d'appels pour un service SPIRITS appelé "livraison de l'identifiant d'appelant Internet" (ICID, Internet Caller-ID Delivery). Un des services SPIRITS de référence, comme décrit au paragraphe 2.2 de la [RFC3136] est la livraison de l'identifiant d'appelant Internet:

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

On présente un exemple de flux d'appels SPIRITS pour réaliser ce service. Noter que c'est seulement un exemple, pas une description normative du service de livraison de l'identifiant d'appelant Internet:

Le texte et les détails des messages SIP ci-dessous se réfèrent aux flux d'appels de la Figure 3. La Figure 3 décrit les quatre entités qui font partie intégrante de tout service SPIRITS (les titres des entités se réfèrent aux noms établis dans la Figure 1 de la [RFC3136]) -- l'abonné SPIRITS, le notificateur SPIRITS et la SCF. Noter que la passerelle SPIRITS n'est pas incluse dans cette figure ; logiquement, les messages SPIRITS s'écoulent entre le serveur SPIRITS et le client SPIRITS. Une passerelle, si elle est présente, peut agir comme mandataire.

Serveur SPIRITS      Client SPIRITS        SCF
 ("abonné")           ("notificateur")
    S                      N
    |                      |                |
    | F1 SUBSCRIBE         |                |
    +--------------------->+                |
    |                      |                |
    |                      | F2 arme DP     |
    |     F3 200 OK (SUBS) +--------------->|
    |<---------------------|                |
    |                      |                |
    |            F4 NOTIFY |                |
    |<---------------------+                |
    |                      |                |
    |      F5 200 OK (NOT) |                |
    +--------------------->|                |
    |                      |                |
    ~                      ~                ~
    ~                      ~                ~
    |                      | F6 notif. évt. |
    |                      |<---------------+
    |            F7 NOTIFY +                |
    |<---------------------|                |
    |                      |                |
    |      F8 200 OK (NOT) |                |
    +--------------------->|                |
    |                      |                |
    |                      |                |
   \|/                    \|/              \|/
    v                      v                v

Figure 3 : Exemple de flux d'appels

Ce flux d'appels dépeint une opération globale d'un "abonné" qui réussit à souscrire au DP IN Termination_Attempt_Authorized (tentative de terminaison autorisée) (l'"abonné" est supposé être un usager, éventuellement au travail, qui est intéressé à savoir quand il a un appel téléphonique pour son numéro de téléphone à son domicile) -- cette interaction est capturée dans les messages F1 à F8 à la Figure 3. L'usager envoie en (F1) une demande SIP SUBSCRIBE identifiant le DP auquel il est intéressé avec zéro, un ou plusieurs paramètres pertinents pour ce DP (dans cet exemple, le paramètre Termination_Attempt_DP va être employé). Le notificateur SPIRITS à son tour interagit avec la SCF pour armer le Termination_Attempt_DP pour le service (F2). Un NOTIFY immédiat avec les informations d'état actuel est envoyé à l'abonné (F4, F5).

À un moment après la séquence d'événements ci-dessus, le RTPC reçoit un appel sur le téléphone de l'usager. La SSF informe la SCF de cet événement quand elle rencontre un Termination_Attempt_DP armé (non montré à la Figure 3). La SCF informe le notificateur SPIRITS de cet événement (F6).

Quand le notificateur SPIRITS reçoit cet événement, il forme une demande SIP NOTIFY et la dirige sur l'abonné SPIRITS (F7). Ce NOTIFY va contenir tous les éléments d'information nécessaires pour identifier l'appelant à l'abonné. L'abonné, à réception de la notification (F8) peut ouvrir une fenêtre avec la date/heure et le numéro de l'appelant.

Le reste de cette section contient les détails des messages SIP de la Figure 3. Le flux d'appels détaillé ci-dessous suppose que la passerelle SPIRITS est, pour les besoins de cet exemple, un mandataire SIP qui sert de mandataire sortant par défaut pour le notificateur et d'hôte d'entrée du domaine myprovider.com pour l'abonné. L'abonné et le notificateur peuvent être dans des domaines administratifs séparés.

F1 : S->N

SUBSCRIBE sip:myprovider.com SIP/2.0
From: <sip:vkg@exemple.com>;tag=8177-afd-991
To: <sip:16302240216@myprovider.com>
CSeq: 18992 SUBSCRIBE
Call-ID: 3329as77@host.exemple.com
Contact: <sip:vkg@host.exemple.com>
Via: SIP/2.0/UDP host.exemple.com;branch=z9hG4bK776asdhds
Expires: 3600
Event: spirits-INDPs
Allow-Events: spirits-INDPs, spirits-user-prof
Accept: application/spirits-event+xml
Content-Type: application/spirits-event+xml
Content-Length: ...
<?xml version="1.0" encoding="UTF-8"?>
<spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
   <Event type="INDPs" name="TAA" mode="N">
         <CalledPartyNumber>6302240216</CalledPartyNumber>
   </Event>
</spirits-event>

L'abonné forme une demande SIP SUBSCRIBE qui identifie le DP auquel il veut s'abonner (dans ce cas, le DP TAA) et la ligne réelle pour laquelle il veut que le DP soit armé (dans ce cas, la ligne associée au numéro de téléphone 6302240216). Cette demande arrive finalement au notificateur SIPRITS, N, qui l'authentifie (pas montré) et envoie une réponse de succès à l'abonné :

F3 : N->S

SIP/2.0 200 OK
From: <sip:vkg@exemple.com>;tag=8177-afd-991
To: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
CSeq: 18992 SUBSCRIBE
Call-ID: 3329as77@host.exemple.com
Contact: <sip:notifier.myprovider.com>
Via: SIP/2.0/UDP host.exemple.com;branch=z9hG4bK776asdhds
Expires: 3600
Accept: application/spirits-event+xml
Content-Length: 0

Le notificateur interagit avec la SCF pour armer le DP et aussi envoie un NOTIFY immédiat à l'abonné pour l'informer de l'étyat actuel de la notification :

F4 : N->S

NOTIFY sip:vkg@host.exemple.com SIP/2.0
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
To: <sip:vkg@exemple.com>;tag=8177-afd-991
Via: SIP/2.0/UDP gateway.myprovider.com;branch=z9hG4bK-9$0-1
Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bKqo--9
Call-ID: 3329as77@host.exemple.com
Contact: <sip:notifier.myprovider.com>
Subscription-State: active
CSeq: 3299 NOTIFY
Accept: application/spirits-event+xml
Content-Length: 0

F5 : S->N

SIP/2.0 200 OK
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
To: <sip:vkg@exemple.com>;tag=8177-afd-991
Via: SIP/2.0/UDP gateway.myprovider.com;branch=z9hG4bK-9$0-1
Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bKqo--9
Call-ID: 3329as77@host.exemple.com
Contact: <sip:vkg@host.exemple.com>
CSeq: 3299 NOTIFY
Accept: application/spirits-event+xml
Content-Length: 0

Un peu plus tard (avant que l'abonnement établi en F1 expire chez le notificateur) un appel arrive au numéro identifié dans le corps codé en XML de F1 -- 6302240216. La SCF le notifie au notificateur (F6). Les informations pertinentes provenant du RTPC sont incluses dans cette notification, à savoir, le numéro de téléphone de la partie qui tente d'appeler le 6302240216. Le notificateur utilise ces informations pour créer une demande SIP NOTIFY et l'envoyer à l'abonné. La demande SIP NOTIFY a un corps codé en XML avec les informations pertinentes provenant du RTPC :

F7 : N->S

NOTIFY sip:vkg@host.exemple.com SIP/2.0
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
To: <sip:vkg@exemple.com>;tag=8177-afd-991
Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK9inn-=u7
Call-ID: 3329as77@host.exemple.com
Contact: <sip:notifier.myprovider.com>
CSeq: 3300 NOTIFY
Subscription-State: terminated;reason=fired
Accept: application/spirits-event+xml
Event: spirits-INDPs
Allow-Events: spirits-INDPs, spirits-user-prof
Content-Type: application/spirits-event+xml
Content-Length: ...
<?xml version="1.0" encoding="UTF-8"?>
<spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
   <Event type="INDPs" name="TAA" mode="N">
         <CalledPartyNumber>6302240216</CalledPartyNumber>
         <CallingPartyNumber>3125551212</CallingPartyNumber>
   </Event>
</spirits-event>

Deux questions importantes sont à noter dans le flux d'appels pour F7 :

(1) Le corps de la demande NOTIFY contient les informations passées au notificateur SPIRITS par la SCF. Dans cet exemple particulier, c'est le numéro de téléphone de la partie (3125551212) qui a tenté d'appeler le 6302240216.

(2) Comme la notification s'est produite, l'abonnement établi en F1 s'est terminé (comme il est évident d'après l'en-tête d'état de souscription). L'abonnement s'est terminé normalement à cause du DP associé à l'expiration de TAA (donc le code de raison de "expiré" se trouve dans l'en-tête État de souscription). Si l'abonné veut être notifié d'autre tentatives d'appel au numéro 6302240216, il devrait envoyer une nouvelle demande SUBSCRIBE au notificateur.

L'abonné peut prendre toute action appropriée à réception du NOTIFY en F7. Une mise en œuvre raisonnable peut ouvrir une fenêtre remplie avec les informations contenues dans le corps de F12, avec un bouton demandant à l'abonné si il voudrait se réabonner au même événement. Autrement, un réabonnement pourrait être généré automatiquement par l'UA de l'abonné sur la base de ses préférences.

Pour achever le protocole, l'abonné envoie aussi un message 200 OK au notificateur :

F8 : S->N

200 OK SIP/2.0
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
To: <sip:vkg@exemple.com>;tag=8177-afd-991
Via: SIP/2.0/UDP notifier.myprovider.com;z9hG4bK9inn-=u7
Call-ID: 3329as77@host.exemple.com
CSeq: 3300 NOTIFY
Content-Length: 0

 	5.3.14	Utilisation des URI pour restituer l'état
Le paquetage "spirits-INDPs" NE DOIT PAS utiliser des URI pour restituer l'état. Il est prévu que la plupart des informations d'état pour ce paquetage soient assez compactes pour tenir dans un message SIP. Cependant, pour rester prudentes, les mises en œuvre DOIVENT suivre la convention mentionnée au paragraphe 18.1.1 de la [RFC3261] et utiliser un transport à contrôle de l'encombrement si la taille de la demande est dans les 200 octets de la MTU du chemin si elle est connue, ou si la taille de la demande est supérieure à 1300 octets et la MTU du chemin est inconnue.

 	5.4	Services par des DP statiques
On a mentionné au paragraphe 5.1 que le premier déclencheur qui arrive à expiration durant le traitement d'appel est normalement un TDP car il n'y a normalement aucune relation de contrôle pré-existante entre la SSF et la SCF. Certains hôtes Internet peuvent avoir exprimé un intérêt pour l'exécution de services fondés sur des TDP (par un arrangement a-priori, qui ne fait pas partie de la présente spécification). Donc, le RTPC va notifier ces hôtes. Pour ce faire, il va envoyer une demande SIP (normalement un INVITE) à l'hôte Internet. Le corps de la demande SIP DOIT contenir un multi-part MIME avec deux composants MIME : la première partie correspondant à la charge utile normale, si il en est une, de la demande; et la seconde partie va contenir des informations spécifiques de SPIRITS (par exemple, le DP qui est arrivé à expiration). Les réponses à la demande INVITE, ou les messages SUBSCRIBE suivants provenant de l'hôte Internet au RTPC dans un contexte d'appel en cours peuvent résulter en l'armement d'EDP.

 	5.4.1	Appel Internet en attente (ICW)
ICW comme service SPIRITS de référence précède en fait SPIRITS lui même. Les mises en œuvre pré SPIRITS de ICW sont détaillées dans la [RFC2995]. Cependant, comme le note le document, alors qu'il existe une diversité de mises en œuvre, ces mises en œuvre ne sont pas interopérables. Au moment de la publication de la [RFC2995], l'industrie n'avait pas autant d'expérience de SIP que maintenant. L'utilisation de SIP dans la [RFC2995] ne constitue pas l'usage normatif de SIP décrit dans la [RFC3261] ; par exemple, aucune mention n'est faite de SDP (si il en est) dans le INVITE initial (en particulier lorsque il relève du cas "accepter l'appel en utilisant VoIP"). Donc, ce paragraphe sert à fournir une description normative de ICW dans SPIRITS.

La description de ICW est extrêmement simple : c'est un service des plus utiles pour les abonnés à une seule ligne téléphonique qui utilisent la ligne pour établir une session Internet. En bref, le service permet à un abonné engagé dans une session Internet de communication téléphonique de :
o	être notifié d'un appel entrant à la ligne téléphonique même utilisée pour la connexion Internet,
o	spécifier le traitement désirable de l'appel, et
o	avoir l'appel traité comme spécifié.

 	5.4.2	Choix de disposition d'appel
La Section 2 de la [RFC2995] détaille les résultats de la disposition d'appel d'une session ICW. Ils sont reproduits ici comme une liste numérotée pour la suite de la discussion :
1. Accepter l'appel sur la ligne RTPC, terminant donc la connexion Internet (modem).
2. Accepter l'appel sur l'Internet en utilisant la voix sur IP (VoIP).
3. Rejeter l'appel.
4. Exécuter un message pré enregistré à l'appelant et déconnecter l'appel.
5. Transmettre l'appel à la messagerie vocale.
6. Transmettre l'appel à un autre numéro.
7. Rejeter (ou transmettre) sur non réponse - Si l'abonné échoue à répondre dans un certain délai après l'affichage de la boîte de dialogue, l'appel entrant peut être soit rejeté, soit traité sur la base du traitement pré défini par l'abonné.

On devrait souligner pour être complet que ICW comme service SPIRITS n'est pas possible sans faire connaître au SCP le fait que la ligne d'abonné est utilisée pour une session Internet. Cette connaissance ne fait cependant pas partie du service ICW, mais est seulement un pré requis. Une des trois méthodes suivantes DOIT être utilisée pour communiquer cette information au SCP :

A.	Méthode fondée sur l'abonné ICW : le client ICW sur l'ordinateur de l'abonné notifie au SCP la session Internet en produisant une demande SIP REGISTER.

B.	Méthode fondée sur l'IN : SCP tient une liste des numéros d'accès des fournisseurs d'accès Internet (FAI) pour une zone géographique ; quand un de ces numéros est composé et connecté, il (le SCP) suppose que l'appelant est engagé dans une session Internet.

C.	Toute combinaison des méthodes A et B.

ICW dépend du provisionnement d'un TDP dans le SSP. Quand le dit TDP est rencontré, le SSP suspend le traitement de l'appel et envoie une demande au SCP à capacité SPIRITS. Le SCP détermine que la ligne de l'abonné est utilisée pour une session Internet. Il ordonne au notificateur SPIRITS sur le SCP de créer une demande SIP INVITE et de l'envoyer à l'abonné SPIRITS qui fonctionne sur l'hôte IP de l'abonné.

L'abonné SPIRITS DOIT retourner un des résultats possibles de disposition d'appel catalogués au paragraphe 5.4.2. Noter que les résultats 1 et 4 à 7 peuvent tous être réunis dans un cas, à savoir la redirection (en utilisant le code de réponse SIP 3xx) de l'appel sur un URI SIP de remplacement. Dans le cas 1, l'URI de l'appel redirigé DOIT correspondre au numéro utilisé par le consommateur pour être en ligne. Rejeter l'appel implique d'envoyer une réponse finale non 2xx et non 3xx ; les résultats restants amènent l'appel à être redirigé sur un URI de remplacement qui donne le service désiré (c'est-à-dire, exécute une annonce pré enregistrée, ou enregistre un message vocal).

La suite du traitement d'un notificateur SPIRITS quand il reçoit une réponse finale peut être résumée par les étapes suivantes :

1. Si la réponse est d'une classe 4xx, 5xx, ou 6xx, générer et transmettre une demande d'accusé de réception et ordonner au SSP d'exécuter une tonalité d'occupation à l'appelant.

2. Autrement, pour toutes les réponses 3xx, générer et transmettre une demande d'accusé de réception, et comparer l'URI redirigé au numéro de ligne de l'abonné:
2a. Si la comparaison indique une correspondance, ordonner au SSP de garder l'appel pendant juste assez de temps pour permettre à l'abonné SPIRITS de déconnecter le modem, libérant donc la ligne ; et ensuite continuer avec le traitement d'appel normal, qui va avoir pour résultat la sonnerie du téléphone de l'abonné.
2b. Si la comparaison échoue, ordonner au SSP d'acheminer l'appel à l'URI redirigé.

3. Autrement, pour une réponse 2xx, suivre les étapes du paragraphe 5.4.3.

 	5.4.3	Acceptation d'une session ICW en utilisant VoIP
Une option du traitement d'appel dans ICW est "d'accepter un appel entrant en utilisant VoIP". Le notificateur SPIRITS n'a pas de moyen de savoir a-priori si l'abonné (l'appelé) va choisir cette option ; néanmoins, il doit tenir compte de ce choix en ajoutant un SDP dans le corps de la demande INVITE. Une façon possible d'accomplir cela est de faire que le notificateur SPIRITS contrôle une passerelle RTPC et alloue sur elle les ressources appropriées. Une fois que c'est fait, le notificateur SPIRITS ajoute des informations de réseau (adresse IP de la passerelle et numéros d'accès où les supports vont être reçus) et informations de codec comme portion SDP du corps dans la demande INVITE. SPIRITS exige que les informations de DP soient aussi portées dans le corps de la demande. À cette fin, le notificateur SPIRITS DOIT aussi ajouter les informations associées au TDP qui a déclenché le service. Donc, le corps de l'INVITE DOIT contenir un multi-part MIME, avec deux composants.

Le notificateur SPIRITS transmet la demande INVITE à l'abonné et attend une réponse finale. La suite de traitement quand l'abonné SPIRITS retourne un 200 OK DOIT être comme suit :

À réception d'un 200 OK contenant le SDP de l'UA de l'abonné, le notificateur SPIRITS va ordonner au SSP de terminer l'appel sur un accès pré-alloué de la passerelle. Cet accès DOIT être corrélé par la passerelle au SDP envoyé dans l'INVITE précédent.

Le résultat final est que l'appelant et l'appelé tiennent une session vocale avec une partie de la session sur VoIP.

 	6.	Événements sans relation avec l'appel

Il y a des événements du réseau qui sont sans rapport avec l'établissement, la maintenance, ou la suppression des appels vocaux. De tels événements surviennent sur le réseau cellulaire sans fil et peuvent être utilisés par SPIRITS pour fournir des services. Les exigences du protocole SPIRITS incluent explicitement les événements suivants pour lesquels une notification SPIRITS est nécessaire (RFC3298, Section 5(b)) :
1. Service de registre de localisation de visiteur (VLR, Visitor Location Register)
2. Mise à jour de localisation dans une autre zone de service de VLR
3. Rattachement d'identité internationale d'abonné mobile (IMSI, International Mobile Subscriber Identity)
4. Détachement d'IMSI initié par l'abonné mobile (MS, Mobile Subscriber)
5. Détachement d'IMSI initié par le réseau

 	6.1	Événements non d'appel et paramètres exigés
Chacun de ces cinq événement sans rapport avec l'appel a reçu un mnémonique spécifique de SPIRITS à utiliser dans les souscriptions et notifications.

Mise à jour de localisation dans la même zone de VLR
Mnémonique SPIRITS : LUSV
Paramètre obligatoire dans SUBSCRIBE : CalledPartyNumber
Paramètre obligatoire dans NOTIFY : CalledPartyNumber, Cell-ID (identifiant de cellule)
Cell-ID : chaîne utilisée pour identifier la cellule de service. La longueur et la représentation réelles de ce paramètre dépendent des particularités du réseau du fournisseur cellulaire.

Mise à jour de localisation dans une autre zone de service de VLR
Mnémonique SPIRITS : LUDV
Paramètre obligatoire dans SUBSCRIBE : CalledPartyNumber
Paramètre obligatoire dans NOTIFY : CalledPartyNumber, Cell-ID

Rattachement d'IMSI
Mnémonique SPIRITS : REG
Paramètre obligatoire dans SUBSCRIBE : CalledPartyNumber
Paramètre obligatoire dans NOTIFY : CalledPartyNumber, Cell-ID

Détachement d'IMSI initié par l'abonné mobile
Mnémonique SPIRITS : UNREGMS
Paramètre obligatoire dans SUBSCRIBE : CalledPartyNumber
Paramètre obligatoire dans NOTIFY : CalledPartyNumber

Détachement d'IMSI initié par le réseau
Mnémonique SPIRITS : UNREGNTWK
Paramètre obligatoire dans SUBSCRIBE : CalledPartyNumber
Paramètre obligatoire dans NOTIFY : CalledPartyNumber

 	6.2	Usage normatif
Un abonné va produire une demande SUBSCRIBE qui identifie un ensemble d'événements RTPC non relatifs à l'appel dont il est intéressé à avoir la notification. Cet ensemble PEUT contenir exactement un événement, ou il PEUT contenir plusieurs événements. La demande SUBSCRIBE est acheminée au notificateur où elle est acceptée, sous réserve de la réussite de l'authentification.

Quand un des événements identifiés dans l'ensemble se produit, le notificateur formate une demande NOTIFY et la dirige sur l'abonné. La demande NOTIFY va contenir des informations pertinentes pour un des événements dont la notification était demandée.

Le dialogue établi par le SUBSCRIBE persiste jusqu'à son expiration normale, ou est explicitement terminé par l'abonné. Ce comportement est différent de celui des abonnements associés au paquetage "spirits-INDPs". Dans le réseau cellulaire, les événements souscrits peuvent survenir à une fréquence bien plus grande que celle dans le réseau filaire (en considérant les mises à jour de localisation lorsque l'usager cellulaire se déplace). Donc, il est bien plus pratique de permettre que l'abonnement arrive normalement à expiration.

Quand un abonné reçoit une demande NOTIFY, il peut ensuite choisir d'agir d'une manière appropriée à la notification.

Les paragraphes qui suivent précisent les responsabilités spécifiques de paquetage mentionnées au paragraphe 4.4 de la [RFC3265].

 	6.3	Nom de paquetage d'événement
Le présent document définit deux paquetages d'événements ; le premier a été défini au paragraphe 5.3. Le second paquetage, défini dans cette Section est appelé "spirits-user-prof". Ce paquetage DOIT être utilisé pour les événements correspondant aux événements non relatifs à l'appel dans le réseau cellulaire. Toutes les entités qui mettent en œuvre le protocole SPIRITS et prennent en charge les événements non relatifs à l'appel mentionnés dans les exigences pour le protocole SPIRITS (RFC3298, Section 5(b)) DOIVENT régler l'en-tête "Event" à "spirits-user-prof". L'en-tête général "Allow-Events" [RFC3265] DOIT inclure aussi le jeton "spirits-user-prof".

Exemple :

Event: spirits-user-prof
Allow-Events: spirits-user-prof, spirits-INDPs

 	6.4	Paramètres de paquetage d'événement
Le paquetage d'événements "spirits-user-prof" ne prend pas en charge de paramètre supplémentaire à l'en-tête Event.

 	6.5	Corps  SUBSCRIBE
Les demandes SUBSCRIBE qui servent à terminer les abonnements PEUVENT contenir un corps vide ; cependant, les demandes SUBSCRIBE qui établissent un dialogue DOIVENT contenir un corps qui code deux éléments d'information :

(1) L'ensemble des événements qui est souscrit. Un abonné PEUT souscrire à plusieurs événements dans une demande SUBSCRIBE, ou PEUT produire une demande SUBSCRIBE différente pour chaque événement auquel il est intéressé à recevoir la notification. Le protocole permet les deux formes de représentation. Cependant, noter que si un SUBSCRIBE est utilisé pour s'abonner à plusieurs événements, une expiration du dialogue associé à cet abonnement va affecter tous ces événements.

(2) Une liste des valeurs des paramètres associés à l'événement. Voir au paragraphe 6.1 la liste des paramètres associés à chaque événement.

Le type de corps par défaut pour les SUBSCRIBE dans SPIRITS est noté par le type MIME "application/spirits-event+xml". L'en-tête "Accept", si il est présent, DOIT inclure ce type MIME.

 	6.6	Durée d'abonnement
La durée d'un dialogue établi par une demande SUBSCRIBE est limitée à l'heure d'expiration négociée entre l'abonné et le notificateur quand le dialogue est établi. L'abonné DOIT envoyer une nouvelle demande SUBSCRIBE pour rafraîchir le dialogue si il est intéressé à le garder en vie. Un dialogue peut être terminé par l'envoi d'une nouvelle demande SUBSCRIBE avec une valeur d'en-tête "Expires" de 0, comme mentionné dans la [RFC3265].

 	6.7	Corps NOTIFY
Les corps dans les demandes NOTIFY pour le paquetage "spirits-user-prof" sont facultatifs. Si il en est de présents, ils DOIVENT être du type MIME "application/spirits-event+xml". Le corps dans une demande NOTIFY encapsule les éléments d'information suivants qui peuvent être utilisés par l'abonné :
(1) l'événement qui a résulté en la génération du NOTIFY (normalement, mais pas toujours, cela va être le même événement qui est présent dans la demande SUBSCRIBE correspondante),
(2) une liste des valeurs des paramètres associés à l'événement pour lequel le NOTIFY est généré. Selon l'événement réel, la liste des paramètres va varier.

 	6.8	Traitement par le notificateur des demandes SUBSCRIBE
Quand le notificateur reçoit une demande SUBSCRIBE, il DOIT authentifier la demande et s'assurer que l'abonné est autorisé à accéder à la ressource objet de l'abonnement, dans ce cas, des événements cellulaires non relatifs à l'appel pour un téléphone mobile.

Une fois la demande SUBSCRIBE authentifiée et autorisée, le notificateur s'interface avec la SCF sur l'interface D pour régler les marques dans le HLR correspondant au numéro de téléphone mobile contenu dans le corps SUBSCRIBE. Les particularités de l'interface D sortent du domaine d'application du présent document ; on suppose simplement ici que le notificateur est capable de régler les marques appropriées dans le HLR.

 	6.9	Génération par le notificateur des demandes NOTIFY
Si le notificateur s'attend à ce que le réglage des marques dans le HLR prenne plus de 200 ms, il DOIT envoyer immédiatement une réponse 202 à la demande SUBSCRIBE, acceptant l'abonnement. Il devrait alors envoyer une demande NOTIFY avec un corps vide. Cette demande NOTIFY DOIT avoir un en-tête "Subscription-State" d'une valeur de "pending".

Ce NOTIFY immédiat avec un corps vide est nécessaire car la ressource identifiée dans la demande SUBSCRIBE n'a pas encore un état significatif.

Une fois que le notificateur a réussi à s'interfacer avec la SCF, il DOIT envoyer une demande NOTIFY suivante avec un corps vide et un en-tête "Subscription-State" d'une valeur de "active."

Quand l'événement intéressant identifié dans la demande SUBSCRIBE survient, le notificateur envoie une nouvelle demande NOTIFY qui DOIT contenir un corps comme décrit au paragraphe 6.7.

 	6.10	Traitement par l'abonné des demandes NOTIFY
Les étapes exactes exécutées chez l'abonné quand il reçoit une demande NOTIFY dépendent de la nature du service mis en œuvre. En général, l'UA associé à l'abonné devrait communiquer ces informations à l'utilisateur par des moyens visuels ou auditifs, si c'est possible.

 	6.11	Traitement des demandes fourchées
Le fourchement des demandes SUBSCRIBE est interdit. Comme la demande SUBSCRIBE est ciblée sur le RTPC, des comportements très irréguliers peuvent se produire si il est permis à la demande de fourcher. Les règles normales de recherche et d'acheminement de SIP pour le DNS [RFC3263] devraient résulter en une cible réglée avec exactement un élément : le notificateur.

 	6.12	Taux de notifications
Pour des raisons de contrôle de l'encombrement, il est important que le taux de notifications ne devienne pas excessif. Par exemple, si un abonné souscrit à l'événement de mise à jour de localisation pour un notificateur qui se déplace à travers le réseau cellulaire à une vitesse assez grande, il est parfaitement concevable que le notificateur puisse générer de nombreuses demandes NOTIFY dans un court intervalle de temps. Donc, dans le présent paquetage, l'événement de mise à jour de localisation doit avoir un mécanisme approprié de réduction.

Chaque fois qu'un notificateur SPIRITS envoie un NOTIFY de mise à jour de localisation, il DOIT lancer un temporisateur (Tn) avec une valeur de 15 secondes. Si un NOTIFY de mise à jour de localisation suivant a besoin d'être envoyé avant que le temporisateur ait expiré, il DOIT être éliminé. Toutes les futures demande NOTIFY de mise à jour de localisation DOIVENT être transmises seulement si Tn a expiré (c'est-à-dire que 15 secondes se soient passées depuis l'envoi de la dernière demande NOTIFY). Si un NOTIFY de mise à jour de localisation est envoyé, Tn devrait être remis à zéro pour compter à nouveau 15 secondes.

 	6.13	Agents d'état
Les agents d'état ne sont pas utilisés dans SPIRITS.

 	6.14	Exemples
Ce paragraphe contient des exemples de service SPIRITS qui peuvent être utilisés pour mettre à jour l'état de présence d'un usager mobile. Le flux d'appels est décrit dans la Figure 4.

Serveur SPIRITS      Client SPIRITS       SCF
 ("abonné")          ("notificateur")
    S                      N
    |                      |                |
    | F1 SUBSCRIBE         |                |
    +--------------------->+                |
    |                      |                |
    |                      | F2 règle marque HLR
    |     F3 200 OK (SUBS) +--------------->|
    |<---------------------|                |
    |                      |                |
    |            F4 NOTIFY |                |
    |<---------------------+                |
    |                      |                |
    |      F5 200 OK (NOT) |                |
    +--------------------->|                |
    |                      |                |
    ~                      ~                ~
    ~                      ~                ~
    |                      | F6 Notif. évémt|
    |                      |<---------------+
    |            F7 NOTIFY +                |
    |<---------------------|                |
    |                      |                |
    |      F8 200 OK (NOT) |                |
    +--------------------->|                |
    |                      |                |
    |                      |                |
   \|/                    \|/              \|/
    v                      v                v

Figure 4 : Exemple de flux d'appels

En F1 de la Figure 4, l'abonné indique son intérêt à recevoir une notification quand un usager mobile s'enregistre auprès du réseau cellulaire. Le réseau cellulaire note cet événement (F2) et confirme l'abonnement (F3-F5). Quand l'usager mobile allume son téléphone cellulaire et s'enregistre sur le réseau, cet événement est détecté (F6). Le réseau cellulaire envoie alors une notification à l'abonné pour l'informer de cet événement (F7-F8).

On présente ensuite les détails du flux d'appels.

En F1, l'abonné s'abonne à l'événement d'enregistrement (REG) d'un numéro de téléphone cellulaire.

F1 : S->N
SUBSCRIBE sip:myprovider.com SIP/2.0
From: <sip:vkg@exemple.com>;tag=8177-afd-991
To: <sip:16302240216@myprovider.com>
CSeq: 18992 SUBSCRIBE
Call-ID: 3329as77@host.exemple.com
Contact: <sip:vkg@host.exemple.com>
Via: SIP/2.0/UDP host.exemple.com;branch=z9hG4bK776asdhdsa8
Expires: 3600
Event: spirits-user-prof
Allow-Events: spirits-INDPs, spirits-user-prof
Accept: application/spirits-event+xml
Content-Type: application/spirits-event+xml
Content-Length: ...
<?xml version="1.0" encoding="UTF-8"?>
<spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
   <Event type="userprof" name="REG">
         <CalledPartyNumber>6302240216</CalledPartyNumber>
   </Event>
</spirits-event>

L'abonnement atteint le notificateur qui authentifie la demande (non montré) et interagit avec la SCF pour mettre à jour la base de données des abonnés pour cet événement. Le notificateur envoie une réponse de succès de l'abonnement :

F3 : N->S
SIP/2.0 200 OK
From: <sip:vkg@exemple.com>;tag=8177-afd-991
To: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
CSeq: 18992 SUBSCRIBE
Call-ID: 3329as77@host.exemple.com
Contact: <sip:notifier.myprovider.com>
Via: SIP/2.0/UDP host.exemple.com;branch=z9hG4bK776asdhdsa8
Expires: 3600
Allow-Events: spirits-INDPs, spirits-user-prof
Accept: application/spirits-event+xml
Content-Length: 0

Le notificateur envoie aussi une demande NOTIFY confirmant l'abonnement :

F4 : N->S
NOTIFY sip:vkg@host.exemple.com SIP/2.0
To: <sip:vkg@exemple.com>;tag=8177-afd-991
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
CSeq: 9121 NOTIFY
Call-ID: 3329as77@host.exemple.com
Contact: <sip:notifier.myprovider.com>
Subscription-State: active
Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7007-091a
Allow-Events: spirits-INDPs, spirits-user-prof
Accept: application/spirits-event+xml
Content-Length: 0

L'abonné confirme la réception de la demande NOTIFY :

F5 : S->N
SIP/2.0 200 OK
To: <sip:vkg@exemple.com>;tag=8177-afd-991
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
CSeq: 9121 NOTIFY
Call-ID: 3329as77@host.exemple.com
Contact: <sip:vkg@host.exemple.com>
Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7007-091a
Content-Length: 0

En F6, l'usager mobile identifié par le numéro RTPC "6302240216" allume le téléphone mobile, causant ainsi son enregistrement sur le réseau cellulaire. Le réseau cellulaire détecte cet événement, et comme un abonné a indiqué son intérêt à recevoir la notification de cet événement, une demande SIP NOTIFY est transmise à l'abonné :

F7 : N->S
NOTIFY sip:vkg@host.exemple.com SIP/2.0
To: <sip:vkg@exemple.com>;tag=8177-afd-991
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
CSeq: 9122 NOTIFY
Call-ID: 3329as77@host.exemple.com
Contact: <sip:notifier.myprovider.com>
Subscription-State: terminated;reason=fired
Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7yi-p12
Event: spirits-user-prof
Allow-Events: spirits-INDPs, spirits-user-prof
Accept: application/spirits-event+xml
Content-Type: application/spirits-event+xml
Content-Length: ...
<?xml version="1.0" encoding="UTF-8"?>
<spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
   <Event type="userprof" name="REG">
         <CalledPartyNumber>6302240216</CalledPartyNumber>
         <Cell-ID>45987</Cell-ID>
   </Event>
</spirits-event>

L'abonné reçoit la notification et en accuse réception en envoyant une réponse :

F8 : S->N
SIP/2.0 200 OK
To: <sip:vkg@exemple.com>;tag=8177-afd-991
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
CSeq: 9122 NOTIFY
Call-ID: 3329as77@host.exemple.com
Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7yi-p12
Content-Length: 0

Noter qu'une fois que l'abonné a reçu cette notification, il peut exécuter les services appropriés. Dans cette instance particulière, un service approprié peut consister en ce que l'abonné agisse comme un composeur de service de présence et tourne l'état de présence de l'usager associé au numéro de téléphone "6302240216" à "actif". Noter aussi qu'en F7 le notificateur a inclus un identifiant de cellule dans la notification.

L'identifiant de cellule peut être utilisé comme base de services de localisation spécifiques ; cependant, une discussion de tels services sort du domaine d'application de ce document.

 	6.15	Utilisation des URI pour récupérer l'état
Le paquetage "spirits-user-prof" NE DOIT PAS utiliser des URI pour restituer l'état. Il est prévu que la plupart des informations d'état pour ce paquetage soient assez compactes pour tenir dans un message SIP. Cependant, pour rester prudentes, les mises en œuvre DOIVENT suivre la convention mentionnée au paragraphe 18.1.1 de la [RFC3261] et utiliser un transport à encombrement contrôlé si la taille de la demande est dans les 200 octets de la MTU de chemin si elle est connue, ou si la taille de la demande est supérieure à 1300 octets et si la MTU du chemin est inconnue.

 	7.	Considérations relatives à l'IANA

Le présent document invite l'IANA à :
o	enregistrer deux nouveaux paquetages d'événement SIP selon la [RFC3265].
o enregistrer un nouveau type MIME selon les [RFC2045 à 49].
o enregistrer un nouvel URN d'espace de noms selon la [RFC3688].
o enregistrer un nouveau schéma XML selon la [RFC3688].

 	7.1	Enregistrement de paquetages d'événement
Nom de paquetage : spirits-INDPs
Type : paquetage
Contact : Vijay K. Gurbani, vkg@lucent.com
Référence : RFC 3910

Nom de paquetage : spirits-user-prof
Type : paquetage
Contact : Vijay K. Gurbani, vkg@lucent.com
Référence : RFC 3910

 	7.2	Enregistrement de type MIME
Nom de type de support MIME : application
Nom de sous type MIME : spirits-event+xml
Paramètres obligatoires : aucun
Paramètres facultatifs : charset (même sémantique que le paramètre charset dans application/xml [RFC3023])
Considérations de codage : les mêmes que mentionnées pour application/xml dans la [RFC3023].
Considérations de sécurité : Section 10 de la [RFC3023] et Section 8 du présent document.
Considérations d'interopérabilité : aucune.
Spécification publiée : le présent document.
Applications qui utilisent de type de support : entités à capacité SPIRITS qui adhèrent au présent document.
Informations supplémentaires :
Numéro magique : aucun.
Extension de fichier : aucune.
Code de type de fichier Macintosh : aucun.
Identifiant d'objet ou OID : aucun.
Adresse personnelle et de messagerie à contacter pour plus d'informations : Vijay K. Gurbani, <vkg@lucent.com>
Usage prévu : Commun
Auteur/Contrôleur des changements : IETF

 	7.3	Enregistrement d'URN
URI : urn:ietf:params:xml:ns:spirits-1.0
Description : c'est l'URI d'espace de noms XML pour les éléments XML définis par le présent document. Ces éléments décrivent les informations SPIRITS dans le type de contenu "application/ spirits-event+xml".
Contact d'enregistrement : IESG.

XML
  DÉBUT
    <?xml version="1.0"?>
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
              "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml">
    <head>
      <meta http-equiv="content-type"
         content="text/html;charset=utf-8"/>
      <title>Espace de noms pour les informations relatives à SPIRITS</title>
    </head>
    <body>
      <h1>Namespace for SPIRITS-related information</h1>
      <h2>application/spirits-event+xml</h2>
      <p>Voir <a href="[[[URL de la RFC publiée]]]">RFC3910</a>.</p>
    </body>
    </html>
  FIN

 	7.4	Enregistrement de schéma XML
URI : urn:ietf:params:xml:schema:spirits-1.0
Description : schéma XML de base pour les entités SPIRITS.
Contact d'enregistrement : IESG.
XML : voir la définition de schéma XML à la Section 9 du présent document.

 	8.	Considérations sur la sécurité

Cette Section se concentre sur les considérations de sécurité qui reviennent en propre à SPIRITS. Les mécanismes de sécurité de SIP sont discutés en détail dans la spécification SIP [RFC3261] et sortent du domaine d'application du présent document. Les mécanismes de sécurité de SPIRITS se fondent sur la sécurité de SIP [RFC3261] et la renforcent, par exemple, SPIRITS rend obligatoire la prise en charge de S/MIME. Au delà de cela, toutes les autres solutions de sécurité spécifiées dans la [RFC3261], c'est-à-dire, l'authentification par résumé TLS ou HTTP, peuvent être utilisées par les opérateurs SPIRITS.

Comme mentionné à la Section 9 (Considération sur la sécurité) de la [RFC3298], les aspects de sécurité suivants sont applicables au protocole SPIRITS : authentification, confidentialité, non répudiation.

L'architecture SPIRITS à la Figure 1 contient cinq interfaces -- A, B, C, D, et E. Parmi elles, deux seulement - B et C -- sont intéressantes pour SPIRITS. Les interfaces A et E sont des interfaces PINT et sont donc supposées sécurisées par PINT [RFC2848]. La sécurité de l'interface D est en dehors du domaine d'application du présent document car elle traite principalement de l'infrastructure du RTPC. On va discuter des aspects de sécurité sur les interfaces B et C sous certaines hypothèses.

Une hypothèse majeure pour la sécurité de SPIRITS est que la passerelle SPIRITS est possédée par le même opérateur RTPC que celui du notificateur SPIRITS. Donc, il est intéressant de simplement reléguer la sécurité de l'interface C chez l'opérateur RTPC, et en fait, il y a du sens à faire cela car l'interface C traverse le réseau IP et les frontières de RTPC. Cependant, une inspection plus serrée révèle que les deux interfaces B et C transmettent le protocole SPIRITS ; donc, tout arrangement de sécurité auquel on arrive pour l'interface B peut être convenablement appliqué aussi à l'interface C. Cela rend possible la sécurisation de l'interface C dans le cas où la passerelle SPIRITS n'est pas possédée par le même opérateur RTPC que celui du notificateur SPIRITS.

La discussion sur la sécurité qui suit suppose que l'abonné SPIRITS est en communication directe avec le notificateur SPIRITS (et vice-versa) et spécifie un dispositif de sécurité pour cet arrangement. Cependant, le même dispositif peut être utilisé pour sécuriser la communication entre un abonné SPIRITS et un intermédiaire (comme la passerelle SPIRITS) et entre le même intermédiaire et le notificateur SPIRITS.

La confidentialité du protocole SPIRITS est essentielle car les informations portées dans les unités de données de protocole sont de nature sensible et peuvent conduire à des problèmes de confidentialité si elles sont révélées à des parties non autorisées. Le chemin de communication entre le notificateur SPIRITS et l'abonné SPIRITS devrait être sécurisé par S/MIME [RFC3851] pour alléger les soucis de confidentialité, comme décrit dans la section de considérations de sécurité de la spécification SIP [RFC3261].

S/MIME est un mécanisme de sécurité de bout en bout qui chiffre les corps SPIRITS pour le transit à travers un réseau ouvert. Les intermédiaires n'ont pas besoin de connaître S/MIME pour acheminer les messages (les en-têtes d'acheminement voyagent en clair).

S/MIME fournit tous les aspects de sécurité pour SPIRITS mentionnés au début de cette Section : authentification, intégrité du message, confidentialité, et non répudiation. Les propriétés d'authentification fournies par S/MIME vont permettre au receveur d'un message SPIRITS de s'assurer que la charge utile SPIRITS a été générée par une entité autorisée. Le chiffrement va assurer que seules les entités SPIRITS qui possèdent une clé de déchiffrement particulière sont capables d'inspecter les corps SPIRITS encapsulés dans une demande SIP.

Tous les points d'extrémité SPIRITS DOIVENT prendre en charge les signatures S/MIME (CMS SignedData) et DOIVENT prendre en charge le chiffrement (CMS EnvelopedData).

Si les interfaces B et C sont possédées par le même opérateur RTPC, il est possible que les clés publiques soient installées dans les points d'extrémité SPIRITS. S/MIME prend en charge deux méthodes -- issuerAndSerialNumber et subjectKeyIdentifier -- pour nommer la clé publique nécessaire pour valider une signature. subjectKeyIdentifier travaille avec des certificats X.509 et aussi d'autres schémas, tandis que issuerAndSerialNumber ne fonctionne qu'avec des certificats X.509. Si l'administrateur configure les clés publiques nécessaires, assurant l'intégrité par des moyens de procédures, alors S/MIME peut être utilisé sans certificats X.509.

Toutes les demandes (et réponses) entre entités SPIRITS DOIVENT être chiffrées.

Quand une demande arrive chez un notificateur SPIRITS en provenance d'un abonné SPIRITS, le notificateur SPIRITS DOIT authentifier la demande. L'abonnement (ou l'enregistrement) d'un abonné SPIRITS DOIT être rejeté si l'authentification échoue. Si l'abonné SPIRITS s'authentifie avec succès auprès du notificateur SPIRITS, celui-ci DOIT, au moins, s'assurer que l'abonné SPIRITS est bien autorisé à recevoir des notifications des événements auxquels il s'abonne.

Noter que le présent document ne fait pas de prescription sur la façon dont le notificateur SPIRITS réalise cela. En pratique, ce pourrait être par des listes de contrôle d'accès (ACL) qui sont remplies par un système de gestion de service dans le RTPC, ou par une interface de la Toile d'un certain type.

Les demandes provenant du notificateur SPIRITS aux abonnés SPIRITS DOIVENT aussi être authentifiées, de crainte qu'une partie malveillante tente de se faire frauduleusement passer pour un notificateur SPIRITS pour capturer une session.

 	9.	Définition de schéma XML

La charge utile SPIRITS est spécifiée en XML ; cette Section définit le schéma XML de base pour les documents qui constituent la charge utile SPIRITS. Toutes les entités SPIRITS qui transportent une charge utile caractérisée par le type MIME "application/spirits-event+xml" DOIVENT prendre en charge les documents qui correspondent au schéma de base ci-dessous.

Plusieurs versions du schéma de base ne sont pas prévues ; chaque fonction supplémentaire (par exemple, de porter de nouveaux événements de RTPC) devra plutôt être accomplie par la définition d'un nouvel espace de noms XML et un schéma correspondant. Les éléments provenant du nouvel espace de noms XML vont alors coexister avec les éléments provenant du schéma de base dans un document.

<xs:schema targetNamespace="urn:ietf:params:xml:ns:spirits-1.0"
       xmlns:tns="urn:ietf:params:xml:ns:spirits-1.0"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       elementFormDefault="qualified"
       attributeFormDefault="unqualified">

<!-- Cette importation amène l'attribut de langage XML xml:lang-->
     <xs:import namespace="http://www.w3.org/XML/1998/namespace"
                schemaLocation="http://www.w3.org/2001/xml.xsd"/>

     <xs:annotation>
        <xs:documentation xml:lang="fr">
              Décrit les événements SPIRITS.
        </xs:documentation>
     </xs:annotation>

     <xs:element name="spirits-event" type="tns:SpiritsEventType"/>

     <xs:complexType name="SpiritsEventType">
        <xs:sequence>
           <xs:element name="Event" type="tns:EventType" minOccurs="1"
               maxOccurs="unbounded"/>
           <xs:any namespace="##other" processContents="lax"
               maxOccurs="unbounded"/>
        </xs:sequence>
     </xs:complexType>

     <xs:complexType name="EventType">
        <xs:sequence>
           <xs:element name="CalledPartyNumber" type="xs:token"
               minOccurs="0" maxOccurs="1"/>
           <xs:element name="CallingPartyNumber" type="xs:token"
               minOccurs="0" maxOccurs="1"/>
           <xs:element name="DialledDigits" type="xs:token"
               minOccurs="0" maxOccurs="1"/>
           <xs:element name="Cell-ID" type="xs:token"
               minOccurs="0" maxOccurs="1"/>
           <xs:element name="Cause" type="tns:CauseType"
               minOccurs="0" maxOccurs="1"/>
        </xs:sequence>
        <xs:attribute name="type" type="tns:PayloadType"
            use="required"/>
        <xs:attribute name="name" type="tns:EventNameType"
            use="required"/>
        <xs:attribute name="mode" type="tns:ModeType"
            use="optional" default="N"/>
     </xs:complexType>

     <xs:simpleType name="PayloadType">
<!-- Le <spirits-event> va contenir une liste des événements des INDP ou une liste d'événements userprof -->
        <xs:restriction base="xs:string">
           <xs:enumeration value="INDPs"/>
           <xs:enumeration value="userprof"/>
        </xs:restriction>
     </xs:simpleType>

     <xs:simpleType name="EventNameType">
        <xs:restriction base="xs:string">
<!-- Ce sont les événements relatifs à l'appel (DP). Si le PaylaodType est "INDPs", alors la valeur de l'attribut "name" est une de celles ci-dessous ; exemple <spirits-event type="INDPs" name="OCI"> -->
           <xs:enumeration value="OAA"/>
           <xs:enumeration value="OCI"/>
           <xs:enumeration value="OAI"/>
           <xs:enumeration value="OA"/>
           <xs:enumeration value="OTS"/>
           <xs:enumeration value="ONA"/>
           <xs:enumeration value="OCPB"/>
           <xs:enumeration value="ORSF"/>
           <xs:enumeration value="OMC"/>
           <xs:enumeration value="OAB"/>
           <xs:enumeration value="OD"/>
           <xs:enumeration value="TA"/>
           <xs:enumeration value="TMC"/>
           <xs:enumeration value="TAB"/>
           <xs:enumeration value="TD"/>
           <xs:enumeration value="TAA"/>
           <xs:enumeration value="TFSA"/>
           <xs:enumeration value="TB"/>
<!-- Ce sont les événements non relatifs à l'appel. Si le PayloadType est "user-prof", alors la valeur de l'attribut "name" est une de celles ci-dessous ; exemple <spirits-event type="userprof" name="LUDV"> -->
           <xs:enumeration value="LUSV"/>
           <xs:enumeration value="LUDV"/>
           <xs:enumeration value="REG"/>
           <xs:enumeration value="UNREGMS"/>
           <xs:enumeration value="UNREGNTWK"/>
        </xs:restriction>
     </xs:simpleType>

     <xs:simpleType name="ModeType">
<!-- Une des deux valeurs : "N"otification ou "R"equête -->
        <xs:restriction base="xs:string">
           <xs:enumeration value="N"/>
           <xs:enumeration value="R"/>
        </xs:restriction>
     </xs:simpleType>

     <xs:simpleType name="CauseType">
        <xs:restriction base="xs:string">
           <xs:enumeration value="Busy"/>
           <xs:enumeration value="Unreachable"/>
        </xs:restriction>
     </xs:simpleType>
</xs:schema>

 	10.	Remerciements

Les auteurs remercient les participants au groupe de travail SPIRITS des discussions qui ont contribué au présent travail. Parmi eux, J-L. Bakker, J. Bjorkner, J. Buller, J-E. Chapron, B. Chatras, O. Cleuziou, L. Conroy, R. Forbes, F. Haerens, J. Humphrey, J. Kozik, W. Montgomery, S. Nyckelgard, M. O'Doherty, A. Roach, J. Rosenberg, H. Sinnreich, L. Slutsman, D. Varney, et W. Zeuch. Les auteurs remercient aussi Steve Bellovin, Allison Mankin et Jon Peterson de leur aide pour la section Sécurité.

 	11.	Acronymes

ACL (Access Control List) liste de contrôle d'accès
CMS (Cryptographic Message Syntax) syntaxe de message cryptographique
CS (Capability Set) ensemble de capacités
DP (Detection Point) point de détection
DTD (Document Type Definition) définition de type de document
EDP (Event Detection Point) point de détection d'événement
EDP-N (Event Detection Point "Notification") point de détection d'événement de notification
EDP-R (Event Detection Point "Request") point de détection d'événement de demande
IANA (Internet Assigned Numbers Authority) autorité d'allocation des numéros de l'Internet
ICW (Internet Call Waiting) appel Internet en attente
IMSI (International Mobile Subscriber Identity) identité internationale d'abonné mobile
IN (Intelligent Network) réseau intelligent
INAP (Intelligent Network Application Protocol) protocole d'application du réseau intelligent
IP (Internet Protocol) protocole Internet
ISP (Internet Service Provider) FAI, fournisseur d'accès Internet
ITU (International Telecommunications Union) Union Internationale des Télécommunications
MIME (Multipurpose Internet Mail Extensions) extension multi objets de messagerie Internet
MS (Mobile Station ou Mobile Subscriber) station mobile ou abonné mobile
OBCSM (Originating Basic Call State Model) modèle d'état d'appel de base d'origine
PIC (Point In Call) point dans l'appel
PINT (RTPC/Internet Interworking) interfonctionnement RTPC/Internet
RTPC réseau téléphonique public commuté 
SCF (Service Control Function) fonction de contrôle de service
SCP (Service Control Point) point de contrôle de service
SDP (Session Description Protocol) protocole de description de session
SIP (Session Initiation Protocol) protocole d'initialisation de session
SIP-T (SIP for Telephones) SIP pour la téléphonie
SPIRITS (Services in the RTPC/IN Requesting InTernet Services) services du RTPC qui demandent des services Internet
SSF (Service Switching Function) fonction de commutation de service
SSP (Service Switching Point) point de commutation de service
STD (State Transition Diagram) diagramme de transition d'état
TBCSM (Terminating Basic Call State Model) modèle d'état d'appel de base de terminaison
TDP (Trigger Detection Point) point de détection de déclenchement
TDP-N (Trigger Detection Point "Notification") point de détection de déclenchement de notification
TDP-R (Trigger Detection Point "Request") point de détection de déclenchement de demande
TLS (Transport Layer Security) Sécurité de la couche Transport
UA (User Agent) Agent d'utilisateur
VLR (Visitor Location Register) Registre des localisations de visiteurs
WIN (Wireless Intelligent Network) Réseau intelligent sans fil
XML (Extensible Markup Language) Langage de balisage extensible

 	12.	Références
 	12.1	Références normatives

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

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

[RFC3261]	J. Rosenberg et autres, "SIP : Protocole d'initialisation de session", juin 2002. (Mise à jour par 3265, 3853, 4320, 4916, 5393, 6665, 8217, 8760)

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

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

 	12.2	Références pour information

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

[Q.1228]	Recommandation UIT-T Q.1228, "Ensemble de capacités n°  2 de réseau intelligent". (Union Internationale des Télécommunications, Genève.)

[Q.1238]	Recommandation UIT-T Q.1238.2, "Recommandations d'interface pour l'ensemble de capacités n° 3 de réseau intelligent : interface SCF-SSF", (Union Internationale des Télécommunications, Genève) juin 2000.

[IN-PARA]	M. Unmehopa, K. Vemuri, A. Brusilovsky, E. Dacloush, A. Zaki, F. Haerens, J-L. Bakker, B. Chatras, and J. Dobrowolski, "On selection of IN parameters to be carried by the SPIRITS Protocol", Travail en cours, janvier 2003.

[RFC2045 à 49]
[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 prendre en charge", novembre 1996. (D. S., MàJ par 2646, 3798, 5147, 6657, 8098)
[RFC2047]	K. Moore, "MIME (Extensions de messagerie Internet multi-objets) Partie trois : extensions d'en-tête de message pour texte non ASCII", novembre 1996. (MàJ par RFC2184, RFC2231) (D.S.)
[RFC2048]	N. Freed, J. Klensin et J. Postel, "Extensions multi-objets de la messagerie Internet (MIME) Partie 4 : Procédures d'enregistrement", BCP 13, novembre 1996. (Rendue obsolète par les RFC 4288-4289)
[RFC2049]	N. Freed, N. Borenstein, "Extensions multi-objets de la messagerie Internet (MIME) Partie cinq : critères de conformité et exemples", novembre 1996. (Remplace RFC1521, RFC1522, RFC1590) (D.S.)

[RFC2141]	R. Moats, "Syntaxe des URN", mai 1997. (Obsolète, voir RFC8141)

[RFC2648]	R. Moats, "Espace de nom d'URN pour les documents de l'IETF", août 1999. (Information)

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

[RFC3023]	M. Murata, S. St.Laurent et D. Kohn, "Types de prise en charge XML", janvier 2001. (Obsolète, voir RFC7303)

[RFC3263]	J. Rosenberg, H. Schulzrinne, "Protocole d'initialisation de session (SIP) : Localisation des serveurs SIP", juin 2002. (Remplace RFC2543) (P.S. ; MàJ par RFC7984, RFC8898)

[RFC3688]	M. Mealling, "Registre XML de l'IETF", BCP 81, janvier 2004.

[RFC3851]	B. Ramsdell, "Spécification du message d'extensions de messagerie Internet multi-objets/sécurisé (S/MIME) version  3.1", juillet 2004. (Obsolète, voir RFC5751)

[XML-NOM]	Tim Bray, Dave Hollander, and Andrew Layman, "Namespaces in XML", Recommandation W3C : xml-names, 14 janvier 1999, < http://www.w3.org/TR/REC-xml-names >.

[XML-STR]	Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML Schema Part 1: Structures", Recommandation W3C REC-xmlschema-1-20010502, mai 2001. < http://www.w3c.org/XML/ >.

 	13.	Contributeur

Kumar Vemuri
Lucent Technologies, Inc.
2000 Naperville Rd.
Naperville, IL 60566
USA
mél : vvkumar@lucent.com 

 	14.	Adresse des auteurs

Vijay K. Gurbani	Alec Brusilovsky	Igor Faynberg	
2000 Lucent Lane	2601 Lucent Lane	Lucent Technologies, Inc.	
Rm 6G-440	Lisle, IL 60532-3640	101 Crawfords Corner Rd.	
Naperville, IL 60566	USA	Holmdel, NJ 07733	
USA	mél : abrusilovsky@lucent.com 	USA	
mél : vkg@lucent.com 		mél : faynberg@lucent.com 	

Jorge Gato	Hui-Lan Lu	Musa Unmehopa	
Vodafone Espana	Bell Labs/Lucent Technologies	Lucent Technologies, Inc.	
Isabel Colbrand, 22	Room 4C-607A, 101 Crawfords Corner Road	Larenseweg 50, Postbus 1168	
28050 Madrid	Holmdel, New Jersey, 07733	1200 BD, Hilversum,	
Spain	USA	The Netherlands	
mél : jorge.gato@vodafone.com 	mél : huilanlu@lucent.com 	mél : unmehopa@lucent.com 	

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

Copyright (C) The IETF Trust (2004).

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

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

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

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

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

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