Groupe de travail Réseau	G. Parsons	
Request for Comments : 3939	J. Maruszak	
Catégorie : En cours de normalisation	Nortel Networks	
Traduction Claude Brière de L'Isle	décembre 2004	

Identification de la ligne appelante pour les messages de messagerie vocale

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

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

Résumé
Le présent document décrit une méthode pour identifier l'origine d'un appel dans l'en-tête d'un message électronique vocal enregistré. Deux nouveaux champs d'en-tête sont définis à cette fin : Caller_ID (identifiant d'appelant) et Called_Name (Nom demandé). L'identifiant d'appelant est utilisé pour mémoriser des informations suffisantes pour que le receveur rappelle, ou réponde à l'envoyeur du message. Le nom d'appelant donne le nom de la personne qui envoie le message.
Table des Matières
1. Introduction	1
2. Conventions utilisées dans le présent document	2
3. Champ Identification de la ligne appelante	2
3.1 Appel interne	2
3.2 Appel externe	2
3.3 Plan de numérotage	3
3.4 En-tête de date	3
4. Champ Nom de l'appelant	3
5. Syntaxe formelle	4
5.1 Syntaxe d'identification de la ligne appelante	4
5.2 Syntaxe du nom de l'appelant	4
5.3 Exemples	4
6. Autres considérations	4
6.1 Compatibilité avec les autres numéros de téléphone Internet	4
6.2 Usage	4
7. Considérations sur la sécurité	5
8. Considérations relatives à l'IANA	5
9. Références	5
9.1 Références normatives	5
9.2 Références pour information	5
10. Remerciements	6
Adresse des auteurs	6
Déclaration complète de droits de reproduction	6

1.	Introduction

On a actuellement besoin d'un mécanisme pour identifier l'origine d'un message vocal électronique, en dehors des informations de l'en-tête "FROM". Le numéro de téléphone et le nom de l'appelant sont normalement disponibles à partir du réseau téléphonique, mais il n'y a pas de champ d'en-tête évident pour mémoriser cela dans un message de messagerie électronique Internet.

Ces informations sont destinées à être utilisées lorsque le format de message VPIM est utilisé pour mémoriser les messages vocaux "Call Answer" (réponse d'appel) dans  une mémorisation de messages de la messagerie Internet, c'est-à-dire lorsque l'appelant laisse un message vocal pour le receveur, qui se trouve incapable de répondre à l'appel. Cela implique qu'il n'y a pas d'adresse de la RFC2822 connue quant à l'origine du message.

La [RFC3801] suggère que le numéro d'origine soit inclus comme une adresse Internet, en utilisant la première méthode montrée ci-dessous. Il y a plusieurs autres façons de mémoriser ces informations, mais elles impliquent toutes des manipulations du champ "From". Par exemple :
1. From: "416 555 1234" <non-mail-user@host>
2. From: "John Doe" <4165551234@host>
3. From:  inconnu;

Comme toutes sont une traduction forcée, il serait utile de mémoriser le nom et le numéro de l'appelant comme ils sont présentés sans manipulation à l'appelé par le système téléphonique. Cela permettrait que les informations sur l'appelant soient affichées chez le receveur (comme lorsque il apparaît sur le téléphone) et cela permettrait aussi une future détermination d'une adresse Internet pour l'origine (si il en existe une). Noter qu'il n'est pas exigé de mémoriser des métadonnées (par exemple, le type de numéro, l'interdiction de présentation) car ces informations ne sont pas présentées à l'appelé, et elles ne sont généralement pas disponibles pour les systèmes de messagerie vocale. L'intention est de mémoriser les informations disponibles sur un téléphone analogique (non RNIS) (par exemple, selon la norme [T1.401] en Amérique du Nord).

La [RFC2076] enregistre actuellement "phone" comme un en-tête de message Internet qui contiendrait le numéro de téléphone de la partie qui génère l'appel mais elle le cite comme "non standard", c'est-à-dire que l'usage de cet en-tête n'est généralement pas recommandé. Il n'a pas non plus de format défini, ce qui rend les informations non analysables. Il n'y a pas d'entrée similaire pour le nom du générateur.

Il est proposé que deux nouveaux champs d'en-tête de message soient inclus pour contenir ces informations, à savoir Identification de la ligne appelante ("Caller-ID", identifiant de l'appelant) et Nom de l'appelant ("Caller-Name").

2.	Conventions utilisées dans le présent 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].

3.	Champ Identification de la ligne appelante

L'en-tête Identification de la ligne appelante ("Caller-ID") contient des informations suffisantes pour que le système de messagerie vocale du receveur rappelle, ou réponde à l'envoyeur du message. Le numéro qui est contenu dans cet en-tête est fourni par le système téléphonique. Le format exact des données reçues dépend du type de l'appel, c'est-à-dire – appel interne ou externe.

Noter que pour les deux options, le champ de numéro DOIT contenir seulement les chiffres du numéro et qu'il DOIT être représentable en utilisant le jeu de caractères du code standard américain pour les échanges d'information (ASCII, American Standard Code for Information Interchange) [ASCII] ; il ne comporte aucun caractère séparateur (par exemple, "-").

On suppose que par défaut, ce qui est vraisemblablement le cas le plus courant, il n'y a aucune sémantique de plan de numérotage associée au numéro. Cependant, dans le cas où elle est connue, un paramètre facultatif "NumberingPlan" PEUT être utilisé pour indiquer la sémantique.

3.1	Appel interne
Pour un appel interne (par exemple, entre deux extensions au sein de la même société) il est suffisant de relayer seulement l'extension de l'appelant, sur la base du plan de numérotage de la société.

Cependant, la prise en  charge de numéros plus longs peut être assurée par le système téléphonique de l'entreprise.

3.2	Appel externe
Pour un appel international, le numéro de l'appelant doit être le numéro international complet décrit dans [E.164], c'est-à-dire, le code de pays (CC), le code de destination national (NDC), et le numéro d'abonné (SN). D'autres informations, comme les préfixes ou symboles (par exemple, "+") NE DOIVENT PAS être inclus. [E.164] permet jusqu'à 15 chiffres.

Pour un appel au sein de l'Amérique du Nord, il est aussi suggéré que 15 chiffres soient pris en charge conformément à [T1.625]. Cependant, certains fournisseurs de service peuvent ne prendre en charge que 10 chiffres comme décrit dans [T1.401] et [GR-31]. Bien qu'il soit souhaitable qu'un numéro international ne soit pas tronqué à 10 chiffres si il en contient plus, il est reconnu que cette limitation de divers systèmes est cause que cela arrive.

Les mises en œuvre de la présente spécification devraient savoir que certains systèmes téléphoniques sont connus pour tronquer les numéros internationaux, bien que ce comportement soit indésirable.

Noter que les autres champs définis disponibles pour les systèmes non analogiques (par exemple, sous adresse, numéro de renvoi) ainsi que les métadonnées, ne sont pas destinés à être mémorisés dans cet en-tête.

3.3	Plan de numérotage
Dans ce cas de base (c'est-à-dire, de lignes analogiques) aucune information de plan de numérotage n'est connue ou impliquée. Cependant, dans le cas où un plan de numérotage est connu, un paramètre "NumberingPlan" facultatif PEUT être utilisé pour indiquer sa sémantique. Seules trois sémantiques sont définies : "unknown", "local", et "e164". "unknown" est par défaut si aucune sémantique de plan de numérotage n'est connue (et si le paramètre est absent). "local" n'a de signification que pour le domaine du système de messagerie vocale qui a mémorisé le message (c'est-à-dire, le système de messagerie vocale sait que le numéro appartient au plan de numérotage local). "e164" indique que le numéro est comme décrit dans [E.164]. "x-" peut être utilisé pour indiquer des plans de numérotage spécifiques d'une entreprise ou service.

3.4	En-tête de date
La date et l'heure peuvent être incluses par le système téléphonique avec le numéro de téléphone de l'appelant selon [T1.401]. Cela PEUT être utilisé, car il y a un en-tête Internet "Date" existant  pour contenir cette information. C'est une décision de mise en œuvre locale d'enregistrer cette heure ou l'heure du système local dans l'en-tête "Date".

4.	Champ Nom de l'appelant

Le nom de la personne qui envoie le message est aussi important. Les informations sur le fait que l'appel est interne ou externe peuvent être incluses si elles sont disponibles. Ces informations peuvent n'être pas disponibles sur les appels internationaux.

De plus, le format exact de ce champ est normalement une option du fournisseur de service selon [T1.641]. Il est possible que le nom de l'appelant soit envoyé dans un certain jeu de caractères selon le transport de signalisation du fournisseur de service (par exemple, ISDN-UP, SCCP, TCAP). Cela inclut :
1)	l'alphabet de référence international (IRA, International Reference Alphabet) anciennement appelé Alphabet International n° 5 ou IA5 [T.50]
2)	 l'alphabet latin n° 1 [ISO-8859]
3)	le code standard américain pour les échanges d'information [ASCII]
4)	les jeux de caractères pour le service Télétexte international [T.61]

Parmi eux, les jeux de caractères IRA et T.61 contiennent un certain nombre d'options qui aident à spécifier les versions nationales et orientées sur des applications. Si il n'y a pas d'accord entre les parties pour utiliser ces options, on supposera alors que c'est le jeu de caractères à 7 bits dans lequel sont codés les caractères graphiques de IRA, T.61, et ASCII exactement de la même manière. De plus, les caractères graphiques à 7 bits de [ISO-8859] sont les mêmes que dans [ASCII].

Noter que pour la livraison à l'équipement de l'usager en Amérique du Nord, le nom de l'appelant DOIT être présenté en ASCII selon [T1.401].

Il en résulte que pour l'en-tête Nom de l'appelant défini dans le présent document, les caractères sont représentés avec les caractères ASCII. Cependant, si on reçoit un nom qui ne peut pas être représenté en ASCII à 7 bits, il PEUT être mémorisé en utilisant le jeu de caractères dans lequel il a été émis comme défini dans la [RFC2047].

Dans les réseaux téléphoniques, la longueur du champ Nom NE DOIT PAS excéder 50 caractères, comme défini dans [T1.641]. Cependant, les fournisseurs de service peuvent choisir de limiter cela à 15 caractères pour la livraison à l'équipement de l'utilisateur, par exemple, [T1.401] et [GR-1188].

5.	Syntaxe formelle

L'identification de la ligne appelante et le nom de l'appelant suivent la spécification de la syntaxe en utilisant le format Backus-Naur augmenté (ABNF) décrit dans la [RFC2234]. Bien que la sémantique de ces en-têtes soit définie aux sections 4 et 5, la syntaxe utilise le jeton 'unstructured' défini dans la [RFC2822] :

unstructured = *([FWS] utext) [FWS]

5.1	Syntaxe d'identification de la ligne appelante
"Caller-ID" ":" 1*DIGIT [ "," "NumberingPlan=" ( "unknown" / "local" / "e164" / ietf-token / x-token ) ] CRLF

ietf-token := <jeton d'extension défini par une RFC sur la voie de la normalisation et enregistré par l'IANA.>

x-token := <les deux caractères "X-" ou "x-" suivis, sans espace blanche intercalée, par tout jeton>

5.2	Syntaxe du nom de l'appelant
"Caller-Name" ":" unstructured CRLF

5.3	Exemples
To: +19725551212@vm1.example.com
Caller-ID: 6137684087
Caller-Name: Derrick Dunne

To: 6137637582@example.com
Caller-ID: 6139416900
Caller-Name: Jean Chretien

6.	Autres considérations
6.1	Compatibilité avec les autres numéros de téléphone Internet
L'intention de ces en-têtes est d'enregistrer le numéro de téléphone qui est envoyé par le système téléphonique analogique avec un appel entrant sans altération ni interprétation. Si une sémantique suffisante est connue ou peut être déduite, ceci peut être inclus dans le champ NumberingPlan. Cela peut lui permettre d'être ultérieurement traduit en un numéro de téléphone adressable. Les numéros de téléphone adressables ou composables (que le présent document ne définit pas) sont définis dans d'autres documents, comme les adresses GSTN [RFC3191] ou les URL telephone [RFC2806].

6.2	Usage
On peut considérer quelques scénarios de la façon dont ce mécanisme peut échouer. Le premier est mentionné au paragraphe  3.2 : la troncature d'un numéro international à 10 chiffres. Il pourrait en résulter une mauvaise interprétation du numéro résultant. Un numéro international (par exemple, d'Irlande) de la forme "353 91 73 3307" pourrait être tronqué à "53 91 73 3307" lorsque reçu en Amérique du Nord, et interprété comme "539 917 3307", un numéro de style paraissant "nord américain". Donc, le receveur reste avec cette information incorrecte pour répondre au message, avec éventuellement un demandé nord américain dérangé pour rien.

Le second scénario est la possibilité d'envoyer une extension interne à un receveur externe lorsque est transmis un message de réponse d'appel. Cela pose deux problèmes, un numéro de téléphone faux est donné au receveur, et le plan de numérotage de la société pourrait être exposé.

Le dernier problème se rapporte à l'exercice des options de caractères qui sont disponibles pour coder le champ Nom de l'appelant. Un système international peut envoyer un message avec des options de codage qui ne sont pas disponibles sur le système receveur, donnant ainsi au destinataire un nom d'appelant incorrect.

7.	Considérations sur la sécurité

Noter que les numéros non listés et interdits ne sont pas un problème car ces champs d'en-tête sont définis comme contenant ce que l'appelé va voir (par exemple, 'Nom privé') par opposition aux détails complets échangés entre les fournisseurs de service.

Cependant, on doit aussi noter que ce mécanisme permet l'indication explicite de numéros de téléphone dans les en-têtes d'un message électronique (utilisé pour mémoriser des messages vocaux). Bien que la raison en soit reprise dans la Section 1, le receveur de ce message peut ne pas savoir que cette information est contenue dans les en-têtes sauf si le client de l'utilisateur présente l'information. Son utilisation est destinée à l'information car elle va apparaître sur l'écran d'un téléphone.

8.	Considérations relatives à l'IANA

Le présent document définit un espace d'enregistrement administré par l'IANA pour les plans de numérotation d'identification d'appelant au paragraphe 5.1. Chaque entrée du registre consiste en un jeton d'identification et une brève description textuelle de l'entrée. Il y a trois entrées initiales dans ce registre :
- unknown : la sémantique du numéro est inconnue. Cette valeur est celle par défaut en l'absence de ce paramètre.
- local : le numéro n'a de signification qu'au sein du domaine du système envoyeur identifié par le champ From de la [RFC2822] du message.
- e164  : la sémantique du numéro est décrite dans [E.164].

La seule façon d'ajouter des entrées supplémentaires (ietf-token au paragraphe 5.1) à ce registre est par une RFC sur la voie de la normalisation.

9.	Références
9.1	Références normatives

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

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

[RFC2234]	D. Crocker et P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", novembre 1997. (Obsolète, voir RFC5234)

[RFC2822]	P. Resnick, "Format de message Internet", avril 2001. (Remplace la RFC0822, STD 11, Remplacée par RFC5322)

[RFC3801]	G. Vaudreuil, G. Parsons, "Profil vocal pour la messagerie Internet - version 2 (VPIMv2)", juin 2004. (D.S.)

9.2	Références pour information

[ASCII]	American National Standards Institute (ANSI), "Coded Character Set - 7-Bit American National Standard Code for Information Interchange", ANSI X3.4, 1986.

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

[GR-1188]	Telcordia Technologies, "CLASS Feature: Calling Name Delivery Generic Requirements", GR-1188-CORE, Issue 2, décembre 2000

[GR-31]	Telcordia Technologies, "CLASS Feature: Calling Number Delivery", GR-31-CORE, Issue 1, juin 2000

[ISO-8859]	Norme internationale ISO/CEI 8859-1 (1998), "Technologies de l'information  - Jeux de caractères graphiques de 8 bits codés sur un seul octet - Partie 1 : Alphabet Latin n° 1".

[RFC2076]	J. Palme, "En-têtes communs de message Internet", février 1997. (Information)

[RFC2806]	A. Vaha-Sipila, "URL pour les appels téléphoniques", avril 2000. (Obsolète, voir RFC3966) (P.S.)

[RFC3191]	C. Allocchio, "Format minimal d'adresse GSTN dans la messagerie Internet", octobre 2001. (D.S.)

[T.50]	Recommandation UIT-T T.50 (1992), "Alphabet de référence international (IRA)".

[T.61]	Recommandation UIT-T T.61 (1988) (retirée), "Répertoire de caractères et jeux de caractères codés pour le service international de Teletexte"

[T1.401]	American National Standards Institute (ANSI), "Telecommunications - Network-to-Customer Installation Interfaces - Analog Voicegrade Switched Access Lines with Calling Number Delivery, Calling Name Delivery, or Visual Message-Waiting Indicator Features", ANSI T1.6401.03-1998

[T1.625]	American National Standards Institute (ANSI), "Telecommunications - Integrated Services Digital Network (ISDN) - Calling Line identification Presentation and Restriction Supplementary Services", ANSI T1.625-1993

[T1.641]	American National Standards Institute (ANSI), "Telecommunications - Calling Name Identification Presentation", ANSI T1.641-1995

10.	Remerciements

Les auteurs des versions précédentes du présent document étaient Derrick Dunne et Jason Collins. Les auteurs de la version actuelle tiennent à remercier Derrick et Jason de leurs contributions.

Adresse des auteurs

Glenn Parsons	Janusz Maruszak	
Nortel Networks	téléphone : +1-416-885-0221	
P.O. Box 3511, Station C	mél : jjmaruszak@sympatico.ca 	
Ottawa, ON K1Y 4H7		
téléphone : +1-613-763-7582		
mél : gparsons@nortelnetworks.com 		

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (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 ci-encloses ne violent 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 pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.

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

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

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