Groupe de travail Réseau	H. Schulzrinne, Columbia U.
Request for Comments : 4734	T. Taylor, Nortel
RFC rendue obsolète : 2833	décembre 2006
RFC mise à jour : 4733	
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle

Définition des événements pour les signaux de téléphonie modem, télécopie, et texte

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 IETF Trust (2006).

Résumé
Le présent mémoire met à jour la RFC 4733 pour ajouter des codes d'événement pour les signaux de modem, de télécopie, et de texte téléphoné lorsque portés dans la charge utile Événement de téléphonie RTP. Il se substitue à l'allocation des codes d'événement de la RFC 2833, et rend donc obsolète cette partie de la RFC 2833.
Table des matières
1. Introduction	1
1.1 Terminologie	1
1.2 Généralités	2
2. Définitions des événements pour le contrôle des sessions de données, télécopie et texte téléphoné	3
2.1 Événements V.8 bis	3
2.2 Événements V.21	5
2.3 Événements V.8	6
2.4 Événements V.25	8
2.5 Événements V.32/V.32bis	9
2.6 Événements T.30	10
2.7 Événements pour le texte téléphoné	12
2.8 Indicateur générique	14
3. Stratégies pour le traitement des signaux de télécopie et de modem	14
4. Exemple de négociation V.8	15
4.1 Transmission simultanée d'événements et d'événements retransmis en utilisant la redondance de la RFC 2198	16
4.2 Transmission simultaneé d'événements et de données en bande vocale avec la redondance RFC 2198	18
5. Considérations sur la sécurité	19
6. Considérations relatives à l'IANA	19
7. Remerciements	20
8. Références	20
8.1 Références normatives	20
8.2 Références pour information	21
Adresse des auteurs	22
Déclaration complète de droits de reproduction	23

 	1.	Introduction
 	1.1	Terminologie
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].

En plus de celles définies pour des événements spécifiques, le présent document utilise les abréviations suivantes :

Fax : télécopie

HDLC (High-level Data Link Control) commande de liaison de données de haut niveau

RTPC : réseau téléphonique public commuté (par circuits)

 	1.2	Généralités
Le présent document étend l'ensemble des événements de téléphonie défini dans le cadre de la [RFC4733] pour inclure les événements de contrôle et les tonalités qui peuvent apparaître sur une ligne d'abonné desservant un télécopieur, un modem, ou un appareil de texte téléphoné. Les événements sont organisés en plusieurs groupes, correspondant à la Recommandation UIT-T dans laquelle ils sont définis. Leur objet est de prendre en charge la négociation, le démarrage et l'arrêt des sessions de télécopie, modem, ou texte téléphoné et les transitions entre les modes de fonctionnement. La charge utile réelle de télécopie, modem, et texte est normalement portée par les autres types de charge utile (par exemple, relais de modem V.150.1 [V.150.1], données de bande vocale telles que formalisées dans la Recommandation UIT-T V.152 [V.152], Clearmode [RFC4040] pour données numérique, [T.38] pour la télécopie, ou [RFC4103] pour texte en mode caractères).

Note : Les mises en œuvre NE DEVRAIENT PAS se fier aux descriptions des divers protocoles de modems décrits ci-dessous sans consulter les références originales (généralement des Recommandations UIT-T). Les descriptions sont fournies dans le présent document pour donner un contexte à l'utilisation des événements définis ici. Elles omettent fréquemment d'importants détails nécessaires à la mise en œuvre.

L'application normale de ces événements est de permettre que l'Internet serve de pont entre des terminaux opérant sur le RTPC. Cette application est caractérisée comme suit :
o	chaque passerelle va agir à la fois comme envoyeur et comme receveur ;
o	les contraintes de temps s'appliquent à l'échange de signaux, rendant désirable l'identification et le rapport précoces des événements afin que l'exécution par le receveur puisse s'effectuer à temps ;
o	le receveur doit exécuter les événements dans le bon ordre ;
o	le transfert des événements doit être fiable. La capacité des applications à récupérer d'événements manquants va être variable.

Dans certains cas, une mise en œuvre peut simplement ignorer certains événements, comme des tonalités de télécopie, qui n'ont pas de sens dans un certain environnement. Le paragraphe 2.4.1 de la [RFC4733] spécifie comment une mise en œuvre peut utiliser le paramètre "fmtp" du protocole de description de session (SDP, Session Description Protocol) dans une description SDP [RFC4566] pour indiquer quels événements il est prêt à traiter.

Sans considération des événements qu'elles prennent en charge, les mises en œuvre DOIVENT être prêtes à envoyer et recevoir des signaux de données qui utilisent des types de charge utile autres que Événement de téléphonie, simultanément avec l'utilisation de cette dernière. Ceci est discuté plus en détails à la Section 3.

Dans de nombreux cas, la continuité de l'exécution est critique. En principe, ceci est réalisé par la mise en mémoire tampon à l'extrémité de réception. Il est généralement désirable de minimiser une telle mise en mémoire tampon afin de réduire le temps d'aller retour des réponses. La conservation d'un intervalle constant de mise en paquets à l'extrémité d'envoi tout en faisant rapport des événements aide à cela.

Il faut ajouter un mot sur les contraintes de temps. Les contraintes de temps qui gouvernent la durée des tonalités ne posent pas de problème quand on utilise le type de charge utile Événement de téléphonie : la charge utile spécifie la durée et la passerelle receveuse peut exécuter les tonalités en conséquence. Des problèmes surviennent quand les contraintes de temps sont spécifiées pour la durée de silence entre les tonalités. Une période de silence d'au moins x ms n'est pas un problème – les notifications d'événement peuvent être reçues plus tard, mais elles peuvent quand même être exécutées à leurs durées spécifiées.

Le problème survient si le silence doit avoir une durée spécifique ou au plus une période spécifique. La contrainte la plus générale de ce dernier type a à voir avec le fonctionnement des suppresseurs d'écho [G.164]) et des annuleurs d'écho [G.165]. Ces appareils peuvent se réactiver après 100 ms d'absence de signal sur la ligne. Par suite, dans toute situation où des suppresseurs ou annuleurs d'écho doivent être désactivés pour que la signalisation fonctionne, les événements de tonalités doivent être rapportés assez rapidement pour s'assurer que ces appareils ne sont pas réactivés.

 	2.	Définitions des événements pour le contrôle des sessions de données, télécopie et texte téléphoné
 	2.1	Événements V.8 bis
La Recommandation UIT-T V.8 bis [V.8bis] est une procédure générale pour que deux points d'extrémité établissent les capacités de l'autre et transitent entre les différents modes de fonctionnement, au démarrage de l'appel et après que l'appel a été établi. Elle prend en charge beaucoup des mêmes terminaux que [V.8] (au paragraphe 2.3 ci-dessous) mais permet  une négociation de paramètres plus détaillée. Il lui manque la prise en charge de certains des plus anciens modems de la série V définis dans V.8, mais elle ajoute des capacités de voix et données simultanées ou en alternance, de liaisons multiples [H.324], et de conférence [T.120].

À la suite de la négociation de capacités de V.8 bis, si les terminaux ont négocié un mode de fonctionnement fondé sur le modem, ils initient la session de modem réelle en utilisant le démarrage soit de V.8, d'une version tronquée de V.8 (préférée) soit de V.25. V.25 est décrit au paragraphe 2.4.

V.8 bis distingue entre "signaux" et "messages". Les signaux V.8 bis -- ESi/ESr, MRe/MRd, et CRe/CRd – consistent en tonalités, comme décrit dans les paragraphes qui suivent. Les messages V.8 bis -- MS, CL, CLR, ACK(1), ACK(2), NAK(1), NAK(2), NACK(3), et NACK(4) -- consistent en séquences de bits transportées sur une modulation [V.21].

Les signaux sont destinés à être compris chez le receveur même en présence de contenu vocal. Ils consistent en deux segments de tonalité. Le premier segment consiste en une tonalité de deux fréquences tenues pendant 400 ms, et a pour fonction de préparer le receveur et tout suppresseur ou annuleur d'écho en ligne à ce qui suit. Les fréquences spécifiques dépendent seulement de si le signal provient de l'initiateur ou de celui qui répond à la transaction. Quand on utilise la charge utile Événement de téléphonie, les événements V8bISeg et V8bRSeg du Tableau 1 représentent le premier segment de tout signal V.8 bis, respectivement chez l'initiateur et chez celui qui répond.

La stratégie complète de V.8 bis pour traiter les suppresseurs ou annuleurs d'écho est décrite à l'Appendice III de la Recommandation UIT-T V.8 bis. Les seules contraintes de période de silence imposées sont du type "au moins", ne posant pas de difficulté pour l'utilisation de la charge utile Événement de téléphonie.

Le second segment suit immédiatement le premier, et est une seule tonalité tenue pendant 100 ms. La fréquence utilisée indique le signal spécifique parmi les six définis. Quand on utilise la charge utile Événement de téléphonie, le second segment d'un signal V.8 bis est représenté par l'événement applicable : CRdSeg, CReSeg, MRdSeg, MReSeg, ESiSeg, ou ESrSeg, comme défini au Tableau 1. ESiSeg et ESrSeg utilisent les mêmes fréquences que les bits '1' du canal bas et haut de V.21, respectivement (voir le Tableau 2), et reçoivent donc les même codes d'événement.

Les messages V.8 bis utilisent la signalisation de glissement de fréquence de V.21 [V.21] pour transférer le contenu du  message. V.21 est décrit au paragraphe 2.1. V.8 bis utilise V.21 en mode semi duplex à 300 bits/s, avec le canal inférieur alloué à l'initiateur et le canal supérieur à celui qui répond.

Chaque message V.8 bis est précédé d'un préambule de 100 ms de fréquence de marquage V.21 continue sauf si elle était immédiatement précédée d'un signal ESi ou ESr (dont le second segment est cette même fréquence de marquage V.21). L'envoyeur NE DEVRA PAS rapporter cette tonalité de préambule en utilisant les événements ESiSeg ou ESrSeg ; ils ne sont utilisés que pour les signaux V.8 bis dont ils relèvent.

Ceci mis à part, la tonalité de marquage V.21 continue qui suit immédiatement V8bISeg et V8bRSeg est rapportée comme respectivement ESiSeg ou ESrSeg. La tonalité V.21 continue se produisant dans tous autres contextes, et en particulier après CRdSeg, CReSeg, MRdSeg, ou MReSeg, est rapportée par d'autres moyens comme un différent type de charge utile ou en utilisant les événements de bit '1' V.21 définis au paragraphe 2.2.

Aucun événement n'est défini pour les messages V.8 bis, mais on en donne une brève description.
o	le message CL V.8 bis décrit les capacités du terminal d'envoi ;
o	le message CLR décrit aussi les capacités, mais indique que l'envoyeur veut recevoir un CL en retour ;
o	le MS établit un mode de fonctionnement particulier ;
o	les messages ACK et NAK sont utilisés pour terminer les transactions de messages.

Les messages V.8 bis sont organisés comme une séquence d'octets. Les deux premiers des cinq octets sont des fanions HDLC (0x7E). Puis vient un identifiant de type de message (quatre bits) un identifiant de version V.8 bis (quatre bits) zéro à deux octets de plus d'informations d'identification, suivis par zéro, un ou plusieurs paramètres de champ d'informations sous la forme de transpositions binaires. Une transposition binaire individuelle est longue de un à cinq octets. Jusqu'à 64 octets d'information non standard peuvent aussi être présents. Les champs d'informations sont suivis par une somme de contrôle et par un à trois fanions HDLC. À cause des limites de taille de tous les champs d'informations, V.8 bis définit des procédures de segmentation. Les données en excès sont envoyées dans un message supplémentaire, mais seulement après en avoir avisé l'extrémité de réception.

Les applications qui prennent en charge la signalisation V.8 bis en utilisant la charge utile Événement de téléphonie PEUVENT transférer des messages V.8 bis sous la forme de séquences de bits, en utilisant les événements de bit V.21 définis à la section suivante. Si elles le font, les informations transmises DOIVENT inclure le contenu complet du message : les fanions HDLC initiaux, les champ d'informations, la somme de contrôle, et les fanions HDLC de terminaison.

La transmission DOIT aussi inclure les bits '0' supplémentaires ajoutés conformément aux procédures du paragraphe 7.2.8 de la Recommandation UIT-T V.8 bis, pour empêcher une fausse reconnaissance des fanions HDLC chez le receveur. Les mises en œuvre devraient noter que ces bits '0' supplémentaires signifient en général que les messages V.8 bis tels que transmis sur le réseau ne constituent pas un multiple pair d'octets. Les mises en œuvre envoyeuses PEUVENT choisir de faire varier l'intervalle de mise en paquet pour inclure exactement un octet d'information plus tous les bits '0' supplémentaires insérés dans cet octet ; la variation résultante va être insignifiante comparée à la quantité de mémoire tampon requise pour se garder contre les délais de livraison des paquets au receveur (voir ci-dessous).

Une raison pour rapporter les bits V.21 exactement comme présentés sur le réseau est de faire correspondre le contenu si il est aussi porté par d'autres moyens, comme des données de bande vocale.

Les niveaux de puissance des signaux V.8 bis et V.21 sont soumis à des règles nationales. Donc, il semble convenable de modéliser les événements V.8 bis comme des tonalités pour lesquelles les volumes DEVRAIENT être spécifiés par l'envoyeur. Si le receveur rend les tonalités V.8 bis comme du contenu audio pour la transmission en cours, le receveur PEUT utiliser les volumes contenus dans les rapports d'événement, ou PEUT modifier les volumes pour satisfaire aux exigences national en aval.

Le Tableau 1 résume les codes d'événement définis pour la signalisation V.8 bis dans le présent document. Les événements individuels sont décrits à la suite du tableau. Chaque événement commence quand le début du segment de la tonalité est détecté et se termine quand la tonalité n'est plus détectée.

Événement	Fréquence (Hz)	Durée (ms)	Code	Type	Volume ?
EsiSeg	980	100	38	tonalité	oui
EsrSeg	1650	100	40	tonalité	oui
CrdSeg	1900	100	23	tonalité	oui
CreSeg	400	100	24	tonalité	oui
MrdSeg	1150	100	25	tonalité	oui
MreSeg	650	100	26	tonalité	oui
V8bISeg	1375 + 2002	400	28	tonalité	oui
V8bRSeg	1529 + 2225	400	29	tonalité	oui

Table 1 : Événements pour signaux V.8 bis

EsiSeg : second segment d'un signal d'échappement initiateur (Esi, initiating Escape Signal) V.8 bis. Le signal ESi complet est représenté par des événements V8bISeg suivis par ESiSeg. ESi va être suivi par un message MS, CL, ou CLR provenant du même terminal. Un intervalle de silence de 1,5 s peut venir entre le signal ESi et la transmission du message MS, CL, ou CLR pour s'accommoder des suppresseurs d'écho du réseau.

EsrSeg : second segment d'un signal d'échappement de réponse (Esr, responding Escape Signal) V.8 bis. Le signal Esr complet est représenté par des événements V8bRSeg suivis par ESrSeg. ESr est toujours envoyé par le terminal appelant en réponse à un MRe ou CRe provenant d'une station de réponse automatique. Il va être suivi par un message MS, CL, ou CLR. Le signal ESr coupe toute annonce générée par la station de réponse automatique.

CrdSeg : second segment d'un signal de demande de capacités (Crd, Capabilities Request) V.8 bis. Le premier segment d'un signal CRd est représenté par V8bISeg ou V8bRSeg, selon le contexte. L'autre extrémité va retourner une liste de capacités (message CL ou CLR).

CreSeg : second segment d'un signal de demande de capacités (Cre, Capabilities Request) V.8 bis initiée par un terminal de  réponse automatique. Le signal Cre complet est représenté par des événements V8bISeg suivis par CReSeg. Le terminal appelant va répondre par un signal CRd ou un message CL ou CLR.

MrdSeg : second segment d'un signal de demande de mode (Mrd, Mode Request) V.8 bis . Le premier segment du signal MRd est représenté par V8bISeg ou V8bRSeg, selon le contexte. L'autre extrémité va retourner un signal CRd ou un message MS.

MreSeg : second segment d'un signal de demande de mode (Mre, Mode Request) V.8 bis initié par un terminal de réponse automatique. Le signal MRe complet est représenté par des événements V8bISeg suivis par MReSeg. Le terminal appelant va répondre avec un signal MRd ou CRd ou un message MS.

V8bISeg : premier segment d'un signal V.8 bis initiateur, qui peut être ESi, CRd, CRe, MRd, ou MRe.

V8bRSeg : premier segment d'un signal V.8 bis de réponse, qui peut être ESr, CRd, ou MRd.

 	2.1.1	Traitement de l'encombrement
Les mises en œuvre V.8 bis ne vont probablement pas tolérer de trous ou d'extensions dans les temps d'exécution dus à des retards de paquet causés par l'encombrement. Au minimum, la transaction en cours va être réinitialisée quand ces défauts d'exécution se produisent. Par suite, une gestion attentive de la mémoire tampon d'exécution est nécessaire chez le receveur pour augmenter la robustesse en présence de possibles paquets perdus ou retardés. L'algorithme d'exécution devrait aussi être tel qu'il ne cause pas d'événement d'exécution qui excède la durée nominale de l'événement.

V.8 bis ne paraît pas offrir d'opportunités pour l'adaptation dynamique à l'encombrement par des manipulations de l'intervalle de mise en paquet.

 	2.2	Événements V.21
V.21 [V.21] est un protocole de modem qui offre la transmission de données au taux maximum de 300 bits/s. Deux canaux sont définis, qui prennent en charge la transmission de données bidirectionnelle si nécessaire. Le canal inférieur utilise des fréquences de 980 Hz pour '1' (marque) et 1180 Hz pour '0' (espace) ; le canal supérieur utilise les fréquences 1650 Hz pour '1' et 1850 Hz pour '0'. Le modem peut fonctionner en synchrone ou en asynchrone.

V.21 est utilisé par d'autres protocoles (par exemple, V.8 bis, V.18, T.30) pour la transmission de données de contrôle, et est aussi utilisé de plein droit entre terminaux de texte. Les événements V.21 sont récapitulés au Tableau 2.

Les mises en œuvre envoyeuses DEVRAIENT rapporter un événement achevé pour chaque bit transmis (c'est-à-dire, plutôt qu'aux transitions entre '0' et '1').
Les événements de bits sont supposés commencer et se terminer avec l'intervalle d'horloge pour l'événement, négligeant les temps de montée et de descente entre les transitions de bits. Donc, il est important pour une passerelle de déterminer le débit binaire réel utilisé avant de commencer de rapporter des événements V.21.

La détermination du débit binaire n'est parfois pas immédiatement possible, comme dans le cas de signal d'entraînement de 100 ms à la fréquence de marque V.21 utilisée avant les messages V.8 bis. La transmission d'un seul événement V.21 de plus longue durée est raisonnable dans ces circonstances et ne devrait pas causer de difficultés à l'extrémité receveuse.

Les mises en œuvre DEVRAIENT emballer plusieurs événements dans un paquet, en utilisant les procédures du paragraphe 2.5.1.5 de la [RFC4733]. Huit à dix bits est un intervalle raisonnable de mise en paquet.

La transmission fiable des événements V.21 est importante pour empêcher la corruption des données. Rapporter un événement par bit plutôt que par transition augmente la redondance des rapports et donc leur fiabilité, car chaque achèvement d'événement est transmis trois fois, comme décrit au paragraphe 2.5.1.4 de la [RFC4733]. Pour réduire le nombre de paquets nécessaires pour les rapports, les mises en œuvre DEVRAIENT porter les événements retransmis en utilisant le codage de redondance de la [RFC2198]. C'est ce qui est illustré dans l'exemple du paragraphe 4.1.

Le temps pour transmettre un bit V.21 au taux nominal de 300 bits/s est 3,33 ms, ou 26,67 unités d'horodatage au taux d'échantillonnage par défaut de 8000 Hz pour le type de charge utile Événement de téléphonie. Comme cette durée n'est pas un nombre entier d'unités d'horodatage, un rapport précis du début d'un événement et de la durée de l'événement est impossible. Les passerelles envoyeuses DEVRAIENT arrondir les temps de début d'événement V.21 à la plus proche unité d'horodatage entière.

Lors de l'envoi de plusieurs événements V.21 consécutifs dans une succession de paquets, la passerelle envoyeuse DOIT s'assurer que les durées d'événements individuels rapportées ne causent pas le chevauchement du dernier événement d'un paquet avec le premier événement du suivant, en tenant compte des horodatages initiaux d'événement respectifs. Pour réaliser cela, la passerelle envoyeuse DOIT déduire les durées d'événement individuel comme la succession des différences entre les instants de début d'événement (de sorte que, à 8000 Hz, tout troisième événement a une durée rapportée de 26  unités, et les autres de 27 unités).

Lorsque une passerelle receveuse reconnaît qu'un paquet rapporte une série consécutive d'événements de bit V.21, elle DEVRAIT les exécuter à un taux uniforme en dépit de discordance possible d'une unité d'horodatage dans leur espacement et leur durée rapportés.

Événement	Fréquence (Hz)	Code d'événement	Type	Volume ?
canal 1, V.21, bit '0'	1180	37	tonalité	oui
canal 1, V.21, bit '1'	  980	38	tonalité	oui
canal 2, V.21, bit '0'	1850	39	tonalité	oui
canal 2, V.21, bit '1'	1650	40	tonalité	oui

Tableau 2 : événements pour les signaux V.21

Les mises en œuvre qui choisissent de transmettre du contenu V.21 en utilisant un type de charge utile différent peuvent souhaiter utiliser un des événements indicateurs définis au Tableau 7 pour alerter le receveur sur la nature du contenu. Il n'est pas prévu qu'une mise en œuvre envoie ces deux événements indicateurs et les événements de bit V.21 définis ci-dessus pour le même contenu.

 	2.2.1	Traitement de l'encombrement
La durée des bits V.21 ne peut pas être étendue au delà de sa valeur nominale (qui dépend du taux de transmission). L'algorithme d'exécution chez le receveur devrait prendre en compte cette contrainte dans la compensation du retard ou de la perte de paquets à cause d'encombrement.

D'autres considérations en rapport avec l'encombrement dépendent de l'application pour laquelle les événements de bit V.21 sont utilisés.

 	2.3	Événements V.8
V.8 [V.8] est un plus ancien protocole général de négociation et de contrôle, qui prend en charge le démarrage des terminaux suivants : multimédia H.324 [H.324], texte V.18 [V.18], vidéotexte T.101 [T.101], télécopie T.30 [T.30] en envoi ou réception, et une longue liste de modems de série V incluant V.34 [V.34], V.90 [V.90], V.91 [V.91], et V.92 [V.92]. À la différence de V.8 bis [V.8bis], dans V.8 seul le terminal appelant peut déterminer le mode de fonctionnement.

V.8 n'utilise pas la même terminologie que V.8 bis. Elle définit quatre signaux qui consistent en bits transférés par V.21 [V.21] à 300 bits/s : le signal indicateur d'appel (CI, call indicator), le signal menu d'appel (CM, call menu), la terminaison de CM (CJ), et le signal de menu joint (JM, joint menu). De plus, elle utilise les tonalités définies dans [V.25] et [T.30] (décrits plus loin) et une tonalité (ANSam) définie dans V.8 lui-même. Le terminal appelant envoie en utilisant le canal V.21 inférieur ; le terminal qui répond utilise le canal supérieur.

La séquence de base du protocole est soumise à un certain nombre de variations pour s'accommoder des différents types de terminaux. Une pure séquence V.8 est comme suit :

1.  Après une période initiale de silence, le terminal appelant transmet le signal V.8 CI. Il répète CI au moins trois fois, continuant avec des pauses occasionnelles jusqu'à ce qu'il détecte une tonalité ANSam. Le CI indique si le terminal appelant veut fonctionner comme un modem H.324, V.18, T.30 en envoi, T.30 en réception, ou de série V.

2.  Le terminal qui répond transmet ANSam après la détection de CI. ANSam va désactiver tous les suppresseurs d'écho [G.164] sur le circuit après 400 ms et tout annuleur d'écho [G.165] après une seconde d'exécution de ANSam.

3.  À la détection de ANSam, le terminal appelant fait une pause d'au moins une demie seconde, puis commence à transmettre CM pour indiquer les capacités détaillées dans le mode choisi.

4.  Après détection d'au moins deux séquences identiques de CM, le terminal qui répond commence à transmettre JM, indiquant ses propres capacités (ou offrant un type de terminal de remplacement si il ne peut pas prendre en charge celui demandé).

5.  Après détection d'au moins deux séquences identiques de JM, le terminal appelant achève l'octet de CM en cours, puis transmet CJ pour accuser réception du signal JM. Il fait une pause d'exactement 75 ms, puis commence à fonctionner dans le mode choisi.

6.  Le terminal qui répond transmet JM jusqu'à ce qu'il ait détecté CJ. À ce point, il arrête immédiatement de transmettre JM, fait une pause d'exactement 75 ms, puis commence à fonctionner dans le mode choisi.

Les signaux CI, CM, et JM consistent tous en une séquence fixe de dix bits '1' suivie par un schéma qui dépend du signal de dix bits de synchronisation, suivis par un ou plusieurs octets d'informations variables. Chaque octet est précédé d'un bit de début de '0' et suivi par un bit d'arrêt de '1'. La combinaison du schéma de synchronisation et du canal V.21 identifie de façon univoque le type de message. Le signal CJ consiste en trois octets successifs de zéros avec les bits de début et d'arrêt mais sans les '1' précédents ni le schéma de synchronisation des autres signaux.

Les applications PEUVENT rapporter chaque instance d'un signal CM, JM, et CJ comme une série d'événements de bits V.21 (paragraphe 2.2) ou peuvent utiliser un autre type de charge utile pour porter ces informations. Les applications qui prennent en charge la signalisation V.8 en utilisant la charge utile Événement de téléphonie PEUVENT rapporter la partie synchronisation du signal CI (dix '1' suivis par '00000 00001') aussi bien comme une série d'événements de bits V.21 et, quand elle a été reconnue, comme un seul événement CI.

Noter que l'événement CI couvre seulement la partie synchronisation du signal CI. L'octet restant de fonction d'appel et ses bits de début et d'arrêt ont aussi besoin d'être transmis, soit comme série d'événements de bit V.21, soit dans d'autres formats de charge utile. On peut supposer que la passerelle de l'extrémité appelante va utiliser le même format pour les signaux CM et CJ.

La nature chevauchante de la signalisation V.8 signifie qu'il n'y a pas de risque de silence excédant 100 ms une fois que ANSam a désactivé tous les circuits de contrôle d'écho. Cependant, la pause de 75 ms avant d'entrer en fonctionnement dans le mode de données choisi va exiger que les deux passerelles, appelante et receveuse, reconnaissent l'achèvement de CJ, afin qu'elles puissent passer de l'exécution d'événement de téléphonie à l'exécution de la charge utile porteuse de données après la période de 75 ms.

Événement	Fréquence (Hz)	Code d'événement	Type	Volume ?
ANSam	2100 x 15	34	tonalité	oui
/ANSam	2100 x 15 phase rev.	35	tonalité	oui
CI	(V.21 bits)	53	tonalité	oui

Tableau 3 : Événements pour signaux V.8

ANSam : la tonalité de réponse modifiée ANSam consiste en un signal sinusoïdal à 2100 Hz, modulé en amplitude par une onde sinusoïdale à 15 Hz. Le début de l'événement est au début de la tonalité. La fin de l'événement est au plus tôt de la fin de la tonalité ou de l'occurrence d'un renversement de phase (marquant le début d'un événement /ANSam). Les renversements de phase sont utilisés pour désactiver l'annulation d'écho ; si ils sont appliqués, ils se produisent à des intervalles de 450 ms.
Un paquet d'événement ANSam NE DEVRAIT PAS être envoyé avant qu'il soit possible de discriminer entre un événement ANSam et un événement ANS (voir les événements V.25, au paragraphe 2.4).
L'enveloppe modulée pour la tonalité ANSam varie en amplitude entre 0,8 et 1,2 fois son amplitude moyenne. La puissance transmise moyenne est gouvernée par les règlements nationaux. Donc, il y a un sens à indiquer le volume du signal.

/ANSam : /ANSam rapporte le même signal physique que ANSam, mais est rapporté suivant la première inversion de phase de ce signal. Il commence avec l'inversion de phase et se termine à la fin de la tonalité. Le receveur de /ANSam DOIT inverser la phase de la tonalité au début de l'exécution de /ANSam et toutes les 450 ms à partir de là jusqu'à la fin de la tonalité.

CI : CI rapporte l'occurrence du schéma de bits V.21 '11111 11111 00000 00001' qui indique le début d'un signal V.8 CI. L'événement commence au début du premier bit et se termine à la fin du dernier. Cet événement NE DOIT PAS être rapporté sauf dans un contexte où un signal V.8 CI pourrait être attendu (c'est-à-dire, à l'extrémité appelante durant l'établissement d'appel). Noter que si le modem appelant envoie le signal CI, il va normalement le répéter plusieurs fois.

Il est prévu que l'événement CI sera très utile quand le contenu du modem est transmis principalement en utilisant un autre type de charge utile. L'événement agit comme un commentaire sur ce contenu, permettant au receveur de reconnaître que de la signalisation V.8 est en cours.

 	2.3.1	Traitement de l'encombrement
Les tolérances incorporées dans V.8 suggèrent qu'il peut être le plus robuste en présence de perte ou retards de paquets. L'exécution de ANSam et /ANSam peut être étendue de plusieurs périodes de mise en paquets sans dommage, pourvu que les inversions de phase se produisent sur des intervalles de 450 ms programmés au plus tard durant l'exécution.

Pour augmenter la robustesse de transmission des signaux fondés sur V.21, les applications envoyeuses qui utilisent les événements V.21 DEVRAIENT inclure un nombre entier d'octets, incluant les bits de début et d'arrêt, dans chaque paquet. La présence des bits de début et d'arrêt permet d'espérer que les mises en œuvre receveuses peuvent surmonter les trous inévitables dans l'exécution entre les octets. Quand un message est répété (comme c'est possible pour CI, CM, et JM) une mesure encore plus forte de robustesse serait que le receveur conserve une copie du message quand il est reçu en premier, et quand un paquet est retardé ou perdu pour continuer d'exécuter l'instance de message en cours et commencer une nouvelle répétition comme si les paquets avaient continué d'arriver comme prévu.

 	2.4	Événements V.25
V.25 [V.25] est un protocole de démarrage qui emprunte à V.8 [V.8] et V.8 bis [V.8bis]. Il spécifie l'échange de deux signaux de tonalité : CT et ANS.

CT (tonalité d'appel, calling tone) consiste en une série de salves interrompues de tonalité de 1300 Hz, actives pour une durée de pas moins de 0,5 s et de pas plus de 0,7 s et interrompues pour une durée de pas moins de 1,5 s et pas plus de 2,0  s [V.25]. Des modems qui ne commencent pas par le signal V.8 CI utilisent souvent cette tonalité.

ANS (tonalité de réponse, answer tone) est une tonalité de 2100 Hz utilisée pour désactiver la suppression d'écho pour la transmission des données [V.25], [T.30]. Pour les télécopieurs, la Recommandation UIT-T T.30 [T.30] se réfère à cette tonalité comme la tonalité de réponse d'identification de terminal (CED). ANS diffère du ANSam V.8 en ce que, à la différence de celui-ci, elle a une amplitude constante.

V.25 inclut spécifiquement des procédures pour désactiver les suppresseurs d'écho, comme défini par la Recommandation UIT-T G.164 [G.164]. Cependant, les suppresseurs d'écho G.164 ont été maintenant pour la plupart remplacés par des annuleurs d'écho G.165 [G.165], qui exigent des inversions de phase dans la tonalité de désactivation (voir ci-dessus ANSam). Par suite, la Recommandation UIT-T V.25 a été modifiée en juillet 2001 pour dire que l'inversion de phase est exigée dans la tonalité ANS si les annuleurs d'écho vont être désactivés.

Une séquence V.25 possible est la suivante :

1.  Le terminal appelant commence par générer CT aussitôt que l'appel est connecté.

2.  Le terminal appelé attend en silence pendant 1,8 à 2,5 s après la réponse, puis commence à transmettre ANS continuellement. Si des annuleurs d'écho sont sur la ligne, la phase du signal ANS est inversée toutes les 450 ms. ANS ne va pas atteindre le terminal appelant tant que l'équipement de contrôle d'écho n'est pas désactivé. Comme cela prend environ une seconde, cela ne peut se produire que dans le trou entre une salve de CT et la suivante.

3.  Suite à la détection de ANS, le terminal appelant peut arrêter immédiatement de générer des CT ou attendre la fin de la salve en cours. En tous cas, il doit attendre au moins 400 ms (au moins 1 s si l'inversion de phase de ANS est utilisée pour désactiver les annuleurs d'écho) après l'arrêt de CT avant qu'il puisse générer la tonalité de réponse de la station appelante. Cette tonalité est spécifique du modem, et non spécifiée dans V.25.

4.  Le terminal appelé exécute ANS pendant 2,6 à 4,0 secondes ou jusqu'à ce qu'il ait détecté la réponse de la station appelante pendant 100 ms. Il attend 55 à 95 ms (nominal 75 ms) en silence. (Noter que la limite supérieure de 95 ms est assez proche du point auquel le contrôle d'écho peut se rétablir lui-même.) Si la raison de la terminaison d'ANS était une fin de temporisation plutôt que la détection de la réponse de la station appelante, le terminal appelé recommence à exécuter un ANS pour maintenir la désactivation du contrôle d'écho jusqu'à ce que la station appelante réponde.

Les événements définis pour la signalisation V.25 sont montrés au Tableau 4.

Événement	Fréquence (Hz)	Code d'événement	Type	Volume ?
Tonalité de réponse (ANS)	2100	32	tonalité	oui
/ANS	2100 ph. rev.	33	tonalité	oui
CT	1300	49	tonalité	oui

Tableau 4 : Événements pour signaux V.25

ANS : le début de l'événement est au commencement de la tonalité de 2100 Hz. La fin de l'événement est au plus tôt de la fin de la tonalité ou de l'occurrence d'une inversion de phase (marquant le début d'un événement /ANS).
Un paquet initial d'événement ANS NE DEVRAIT PAS être envoyé jusqu'à ce qu'il soit possible de discriminer entre un événement ANS et un événement ANSam (voir les événements V.8 ci-dessus).

/ANS : /ANS rapporte le même signal physique que ANS, mais est rapporté à la suite de la première inversion de phase dans ce signal. Il commence avec l'inversion de phase et se termine à la fin de la tonalité. Le receveur de /ANS DOIT inverser la phase de la tonalité au début de l'exécution de /ANS et toutes les 450 ms à partir de là jusqu'à la fin de la tonalité.

CT : le début de l'événement CT est au commencement d'une salve individuelle de la tonalité de 1300 Hz. La fin de l'événement est à la fin de cette salve de tonalité. La passerelle à l'extrémité appelante DEVRAIT utiliser un intervalle de mise en paquet plus petit que la durée nominale d'une salve de CT, pour s'assurer que l'exécution de CT à l'extrémité appelée précède l'envoi d'un ANS provenant de cette extrémité.

 	2.4.1	Traitement de l'encombrement
La séquence V.25 paraît être robuste en présence de paquets perdus ou retardés, pourvu que le receveur continue d'exécuter toute tonalité qu'il est en train d'exécuter jusqu'à ce que plus de paquets soient reçus. Le receveur doit exécuter les transitions de phase pour /ANS comme prévu, à des intervalles de 450 ms, même si des mises à jour de l'événement /ANS ont été retardées. Il apparaît aussi possible que l'envoyeur augmente temporairement l'intervalle de mise en paquet pour réduire les volumes de paquets quand de l'encombrement est rencontré. Le risque est qu'une exécution étendue se fasse après la fin réelle de la tonalité (ce qui est déterminé rétroactivement) et que le receveur soit forcé de continuer d'imposer un temps de mise en mémoire tampon d'exécution supplémentaire afin de satisfaire au contraintes de durée maximum de la période de silence nominale de 75 ms qui suit l'exécution de la tonalité.

 	2.5	Événements V.32/V.32bis
La Recommandation UIT-T V.32 [V.32] est un modem qui utilise un chiffrement de glissement de phase avec modification de l'amplitude de quadrature. Il opère sur une porteuse à 1800 Hz, modulée à 2400 symboles/s. Les taux de données de base pour V.32 sont 4800 et 9600 bits/s. [V.32bis] étend les débits de données jusqu'à 14 400 bits/s. La plupart ou tous les déploiements existants sont V.32bis, normalement à l'appui de terminaux de point de vente et autres de la sorte.

Une raison pour laquelle V.32bis est encore utilisé est à cause de sa séquence de démarrage relativement rapide, en particulier sur les liaisons louées. En fonctionnement sur le réseau téléphonique public, le démarrage commence comme suit :

a.  l'extrémité qui répond commence par la procédure de réponse de V.25 (1,8 à 2,5 s de silence suivie par la tonalité ANS continue pendant un maximum de 3,3 s, avec de possibles inversions de phase pour désactiver l'équipement d'annulation d'écho) ;

b.  l'extrémité appelante attend en silence jusqu'à avoir détecté ANS pendant 1 s ;

c.  l'extrémité appelante commence à transmettre un schéma V.32/V.32bis appelé AA, c'est-à-dire, une série de séquences de bits '0000' transmises à 4800 bits/s ;

d.  à la détection du schéma AA pendant au moins 100 ms, le modem appelé reste silencieux pendant 75 +/- 20 ms, puis répond avec un schéma AC, qui est une série de séquences de bits '0011' transmises à 4800 bits/s.

La différence dans le fonctionnement sur liaisons louées est que le modem appelant commence la session par l'envoi de AA. Après cela, le modem appelé répond par AC, et le reste de la séquence est inchangé.

À l'appui du fonctionnement de V.32/V.32bis, le Tableau 5 définit deux événements, V32AA et V32AC.

Événement	Schéma binaire 	Code d'événement	Type	Volume ?
V32AA	b'0000' répété	63	tonalité	oui
V32AC	b'0011' répété	27	tonalité	oui

Tableau 5 : Événements pour signaux V.32/V.32bis

V32AA : indique que le schéma appelant AA d'un terminal V.32/V.32bis a été détecté.

V32AC : indique que le schéma de réponse AC d'un terminal V.32/V.32bis a été détecté.

Chacun de ces deux événements commence au début de son schéma, et se termine nominalement quand le schéma cesse d'être reçu. Suivant l'envoi de l'un ou l'autre de ces événements, la session peut continuer en utilisant le relais de modem V.150.1 [V.150.1] ou Clearmode [RFC4040] comme négocié ou configuré à l'avance. Pour aider à faire la transition aussi rapidement que possible, l'événement V32AA ou V32AC DEVRAIT être rapporté aussitôt que le schéma correspondant est détecté. Il semble probable que la mise en œuvre va transmettre les rapports d'événement simultanément aux mêmes données sous une autre forme, normalement en utilisant la redondance de la [RFC2198].

 	2.5.1	Traitement de l'encombrement
Le principal problème soulevé par l'encombrement est la perte ou le retard indu du rapport initial. Une fois que le receveur sait qu'un schéma AA ou AC a été détecté, les autres rapports n'ont pas d'intérêt. La durée réelle du schéma AC peut être de juste 27 ms. Sur cette base, le comportement approprié de l'envoyeur peut être d'envoyer au moins trois paquets rapportant l'événement en utilisant les mises à jour normales d'événement et de terminer le comportement de retransmission d'événement, ainsi qu'un très court intervalle de mise en paquet (20à 30 ms).

 	2.6	Événements T.30
La Recommandation UIT-T T.30 [T.30] définit les procédures utilisées par les télécopieurs de groupe III. Les procédures de pré-message pour lesquelles les événements de ce paragraphe sont définis sont utilisées pour identifier les capacités du terminal à chaque extrémité et négocier le mode de fonctionnement. Les procédures post-message sont aussi incluses, pour traiter les cas de transmission de multiples documents. Les terminaux de télécopie prennent en charge une grande variété de piles de protocoles, de sorte que T.30 a un certain nombre d'options pour les protocoles et séquences de contrôle.

T.30 définit deux signaux de tonalité utilisés au début d'un appel. Le signal CNG est envoyé par le terminal appelant. C'est une pure tonalité de 1100 Hz exécutée en salves : 0,5 s ouvert, 3 s fermé. Il continue jusqu'à une fin de temporisation ou jusqu'à ce que le terminal appelant détecte une réponse. Son principal objet est de faire savoir aux opérateurs humains de l'extrémité appelée qu'un télécopieur a été activé à l'extrémité appelante.

Le terminal appelé attend en silence pendant au moins 200 ms. Il peut alors retourner la tonalité CED (qui est physiquement identique à l'ANS V.25) ou un ANSam V.8 si il a la capacité V.8. Si les terminaux appelant et appelé prennent tous deux en charge V.8, le terminal appelé va détecter CI ou plus probablement CM en réponse à son ANSam et va continuer avec la négociation V.8. Autrement, le terminal appelé arrête de transmettre CED après 2,6 à 4 secondes, attend 75 +/- 20 ms en silence, puis entre dans la phase de négociation T.30.

Dans la phase de négociation T.30 les terminaux échangent des messages binaires en utilisant les signaux V.21, seulement sur les fréquences de canal supérieur, à 300 bits/s. Chaque message est précédé d'un préambule d'une seconde (nominale) consistant entièrement d'octets de fanion HDLC (0x7E). Ce fanion a pour fonction de préparer l'équipement de contrôle d'écho au message qui suit.

Les messages de pré transfert échangés en utilisant le codage V.21 sont :

Signal d'identification numérique (DIS, Digital Identification Signal) : caractérise les capacités standard UIT-T du terminal appelé. C'est toujours le premier message envoyé.

Commande de transmission numérique (DTC, Digital Transmit Command) : réponse possible au signal DIS par le terminal appelant. Elle demande au terminal appelé d'être l'émetteur du contenu de la télécopie.

Signal de commande numérique (DCS, Digital Command Signal) : message de commande envoyé par le terminal émetteur pour indiquer les options à utiliser dans la transmission et demander que l'autre extrémité se prépare à recevoir un contenu de télécopie. Il est envoyé par l'extrémité appelante si elle veut émettre, ou par l'extrémité appelée en réponse à un DTC provenant de l'extrémité appelante. Il est suivi par un signal d'entraînement, aussi envoyé par le terminal émetteur.

Confirmation à recevoir (CFR, Confirmation To Receive) : réponse numérique confirmant que la procédure de pré message entière incluant l'essai a été réalisée et que les transmissions de messages peuvent commencer.

Chaque message peut consister en plusieurs trames limitées par des fanions HDLC. Les messages sont organisés comme une série d'octets, mais comme dans V.8 bis, T.30 invite à l'insertion de bits '0' supplémentaires pour empêcher une reconnaissance fallacieuse de fanions HDLC.

T.30 assure aussi la transmission de messages de contrôle après l'achèvement de la transmission du document (par exemple, pour prendre en charge la transmission de plusieurs documents). La transition de et vers le modem utilisé pour la transmission de document ([V.17], [V.27ter], [V.29], [V.34]) est précédée de 75 ms (nominales) de silence).

Les applications qui prennent en charge la signalisation T.30 en utilisant la charge utile Événement de téléphonie PEUVENT rapporter le préambule précédant chaque message comme une série d'événements de bits V.21 et, quand il a été reconnu, comme un seul événement de préambule V.21. Le message de contrôle T.30 qui suit le préambule PEUT être rapporté sous la forme d'une séquence d'événements de bit V.21 ou en utilisant un autre type de charge utile. Si il est transmis comme événements de bits, les informations transmises DOIVENT inclure le contenu complet du message : les fanions HDLC initiaux, les champs d'informations, la somme de contrôle, les fanions HDLC de terminaison, et les bits '0' supplémentaires ajoutés pour empêcher une fausse reconnaissance des fanions HDLC chez le receveur. Les mises en œuvre devraient noter que ces bits '0' supplémentaires signifient en général que les messages T.30 tels que transmis ur le réseau ne font pas un multiple pair d'octets.

Le signal envoyé par le terminal émetteur après le DCS consiste en une chaîne continue de zéros sur le canal supérieur V.21 (tonalité de 1850 Hz) pendant 1,5 s. Comme le débit binaire (nominalement 300 bits/s) devrait avoir été clairement établi lors du traitement de la signalisation précédente, il est naturel que si le type de charge utile Événement de téléphonie  est utilisé, ce signal d'entraînement va aussi être envoyé comme une série d'événements de bits V.21 à ce débit. Cependant, si la passerelle d'envoi est capable de reconnaître la transition de la fin du DCS au début de l'entraînement, elle PEUT rapporter le signal d'entraînement comme un seul événement '0' étendu V.21 (canal supérieur).

Les événements définis pour la signalisation T.30 sont montrés au Tableau 6. Les événements CED et /CED représentent exactement les mêmes signaux de tonalité que ANS et /ANS, et ont les mêmes codets ; ils ne sont reproduits ici que par convention.

Événement	Fréquence (Hz)	Code d'événement	Type	Volume ?
CED (tonalité appelée)	2100	32	tonalité	oui
/CED	2100 inv de phase	33	tonalité	oui
CNG (tonalité appelante)	1100	36	tonalité	oui
Fanion de préambule V.21	(V.21 bits)	54	tonalité	oui

Tableau 6 : Événements pour signaux T.30

CED : le début de l'événement est au commencement de la tonalité de 2100 Hz. La fin de l'événement est au plus tôt de la fin de la tonalité ou de l'occurrence d'une inversion de phase (marquant le début d'un événement /CED).
Un paquet initial d'événement CED NE DEVRAIT PAS être envoyé jusqu'à ce qu'il soit possible de discriminer entre un événement CED et un événement ANSam (voir les événements V.8 ci-dessus).

/CED : /CED rapporte le même signal physique que CED, mais est rapporté à la suite de la première inversion de phase dans ce signal. Il commence avec l'inversion de phase et se termine à la fin de la tonalité. Le receveur de /CED DOIT inverser la phase de la tonalité au début de l'exécution de /CED et toutes les 450 ms tà partir de là jusqu'à la fin de la tonalité.

CNG : le début de l'événement CNG est au commencement d'une salve individuelle de la tonalité de 1100 Hz. La fin de l'événement est à la fin de cette salve de tonalité.

Fanion de préambule V.21 : cet événement commence avec le premier bit V.21 transmis après une période de silence. Il se termine quand un schéma de bits V.21 autre qu'un fanion HDLC est observé. Cela signifie que l'événement de préambule V.21 absorbe les fanions HDLC initiaux du message suivant.

Il est prévu que l'événement de fanion de préambule V.21 sera très utile quand le contenu du modem est transmis principalement en utilisant un autre type de charge utile. L'événement agit comme un commentaire sur ce contenu, permettant au receveur de se préparer à la transition au mode télécopie.

 	2.6.1	Traitement de l'encombrement
T.30 apparaît comme un cas intermédiaire en termes de vulnérabilité à l'encombrement. L'exécution de la tonalité en présence de retard ou perte de paquet est sujette aux mêmes considérations que pour V.25 (voir le paragraphe 2.4.1). De façon similaire, le receveur peut étendre l'exécution de l'événement de préambule tout en attendant d'autres rapports. Cependant, les trous ou l'exécution étendue des séquences V.21 ne sont pas possibles. Cela signifie, comme avec V.8 bis, que le receveur doit gérer sa mémoire tampon d'exécution de façon appropriée pour augmenter la robustesse en présence d'encombrement.

 	2.7	Événements pour le texte téléphoné
 	2.7.1	Indicateurs de format de signal pour le texte téléphoné
Le texte téléphoné traditionnel utilise une large variété de terminaux, avec des normes différentes en vigueur dans les différentes parties du monde. La vision d'avenir est que les nouveaux terminaux fonctionneront directement dans le réseau de paquets et s'appuieront sur la mise en paquet des données de caractères de la [RFC4103]. En prévision de cette migration, il est RECOMMANDÉ que le texte porté dans le RTPC par les protocoles de modem traditionnels soit converti en paquets de la RFC 4103 à la passerelle d'envoi.

Durant la période de transition, les passerelles de moindre capacité peuvent cependant être capables de reconnaître la nature du contenu entrant, mais peuvent être seulement capables de le coder comme des données de bande vocale sur le côté paquet. Dans de telles circonstances, cela aidera à optimiser le traitement du signal à l'extrémité receveuse si celle-ci reçoit une indication de la nature des signaux de données codes en vocal. Les événements définis dans ce paragraphe donnent de telles indications, et PEUVENT être utilisés en conjonction avec la Recommandation UIT-T V.152 [V.152], pour, par exemple, porter le contenu comme des données de bande vocale.

Les mises en œuvre devraient noter une classe supplémentaire de terminaux de texte non considérée dans les événements ci-dessous. Ces terminaux utilisent des tonalités de multi fréquences bi-tonalités (DTMF, dual tone multi-frequency) pour coder et échanger les signaux. Cette application est décrite dans la [RFC4733], paragraphe 3.1, en conjonction avec l'enregistrement des événements DTMF.

Les événements montrés au Tableau 7 correspondent aux signaux provenant des types de modem suivants :

o  Baudot [TIA-825-A], codage de caractère sur cinq bits fonctionnant nominalement à 45,45 ou 50 bits/s avec les fréquences 1800 Hz = '0', 1400 Hz = '1';

o  EDT, qui est V.21 [V.21] fonctionnant à 110 bits/s en mode  semi duplex (seulement le canal inférieur) ; les caractères sont de l'IA5 à 7 bits plus un bit initial de début, un bit de parité en queue, et deux bits d'arrêt ;

o  Mode Bell 103 (documenté dans l'Annexe D de la Recommandation UIT-T V.18) qui est structurellement similaire à V.21, mais utilise des fréquences différentes : canal inférieur, 1070 Hz = '0', 1270 Hz = '1' ; canal supérieur, 2025 Hz = '0', 2225 Hz = '1' ; les caractères sont l'US ASCII tramé par un bit de début, un bit de parité en queue, et un bit d'arrêt ;

o  Vidéotexte fondé sur V.23 [V.23], dans les versions Minitel et Prestel. V.23 offre un canal vers l'avant fonctionnant à 1200 bits/s si possible (2100 Hz = '0', 1300 Hz = '1') ou autrement à 600 bits/s (1700 Hz = '0', 1300 Hz = '1') et un canal de retour à 75 bits/s, qui est transmis à 390 Hz (des '1' continus) sauf quand '0' est à transmettre (450 Hz) ;

o  Terminal de texte non V.18 qui utilise V.21 [V.21] à 300 bits/s. Les caractères sont du 7 bits national (par exemple, US ASCII) avec un bit de début, un bit de parité, et un bit d'arrêt.

Événement	Débit (bits/s)	Fréquence (Hz)	Code d'événement	Type	Volume ?
ANS2225	N/A	2225	52	tonalité	oui
V21L110	110	980/1180	55	autres	non
V21L300	300	980/1180	30	autres	non
V21H300	300	1650/1850	31	autres	non
B103L300	300	1070/1270	56	autres	non
V23Main	600/1200	1700-2100/1300	57	autres	non
V23Back	75	450/390	58	autres	non
Baud4545	45,45	1800/1400	59	autres	non
Baud50	50	1800/1400	60	autres	non
XCIMark	1200	2100/1300	62	tonalité	oui

Tableau 7 : Indicateurs pour le texte téléphonique

ANS2225 : indique qu'une tonalité de réponse de 2225 Hz a été détectée. C'est une tonalité pure sans modulation d'amplitude et sans sémantique attachée aux inversions de phase, si il en est. L'envoyeur DEVRAIT rapporter le début de l'événement quand la tonalité est détectée. L'envoyeur PEUT envoyer des mises à jour pendant que la tonalité continue, et DOIT rapporter la fin de l'événement quand la tonalité cesse. La tonalité concernée est générée par un modem de type Bell 103 en mode réponse. Cet événement NE DOIT PAS être rapporté en dehors du contexte de démarrage (c'est-à-dire, du côté qui répond au début d'un appel).

V21L110 : indique que l'envoyeur a détecté une modulation V.21 opérant sur le canal inférieur à 110 bits/s. Noter qu'il peut prendre un certain temps pour distinguer entre le fonctionnement à 300 bits/s et à 110 bits/s. On s'attend à ce que les mises en œuvre ne transmettent pas à la fois cet événement et des événements de bit V.21 individuel pour le même contenu.

V21L300 : indique que l'envoyeur a détecté une modulation V.21 opérant sur le canal inférieur à 300 bits/s. Noter qu'il peut prendre un certain temps pour distinguer entre le fonctionnement à 300 bits/s et à 110 bits/s. On s'attend à ce que les mises en œuvre ne transmettent pas à la fois cet événement et des événements de bit V.21 individuel pour le même contenu.

V21H300 : indique que l'envoyeur a détecté une modulation V.21 opérant sur le canal supérieur à 300 bits/s. On s'attend à ce que les mises en œuvre ne transmettent pas à la fois cet événement et des événements de bit V.21 individuel pour le même contenu.

B103L300 : indique que l'appareil envoyeur a détecté une modulation Bell 103 opérant sur le canal inférieur à 300 bits/s.

V23Main : indique que l'appareil envoyeur a détecté une modulation V.23 opérant sur le canal à grande vitesse. Comme décrit ci-dessous, cet indicateur peut alterner avec l'indication XCIMark.

V23Back : indique que l'appareil envoyeur a détecté une modulation V.23 opérant dans le canal de retour à 75 bit/s.

Baud4545 : indique que l'appareil envoyeur a détecté une modulation Baudot opérant à 45,45 bits/s.

Baud50 : indique que l'appareil envoyeur a détecté une modulation Baudot opérant à 50 bits/s.

XCIMark : indique que l'appareil envoyeur a détecté le schéma binaire spécifique (0) 1111 1111(1)(0)1111 1111(1) envoyé à 1200 bits/s en utilisant une modulation V.23 de canal supérieur, suivie par une période de "marque" V.23 de canal principal (1300 Hz).

On suppose dans tous les cas que les rapports d'événement décrits ici sont transmis en plus d'un autre codage de support, normalement des données de bande vocale [G.711], rapportant les mêmes informations. une méthode naturelle pour le faire est de combiner les données de bande vocale avec les rapports d'événement dans une chage utile de redondance de la [RFC2198].

Le traitement de ANS2225 a été indiqué plus haut. Comme c'est une tonalité spécifique, elle peut être traitée comme tout les autres événements de tonalité.

Pour tous les autres indicateurs, l'envoyeur DEVRAIT générer un rapport d'événement initial aussitôt que la nature du contenu audio a été reconnue. Pour plus de fiabilité, le rapport d'événement initial DEVRAIT être retransmis deux fois à un court intervalle. (20 ms est une valeur suggérée, bien que la période de mise en paquets du support associé puisse être suffisante.) L'envoyeur PEUT continuer d'envoyer des rapports supplémentaires du même événement d'indicateur, bien qu'il n'aient que peu de valeur une fois que le receveur s'est ajusté au type de contenu qu'il reçoit.

Si la nature du contenu change (par exemple, parce qu'il vient d'un terminal V.18 en phase de reconnaissance) l'envoyeur DOIT envoyer un rapport d'événement pour le nouveau type de contenu aussitôt qu'il est reconnu. Si l'envoyeur a envoyé des mises à jour pour l'indicateur précédent, il DEVRAIT rapporter la fin de ce précédent événement d'indicateur avec le début du nouveau.

 	2.7.1.1	Traitement de l'encombrement
En présence de perte ou retard de paquets, il est approprié que le receveur continue d'exécuter l'événement ANS2225 jusqu'à ce que d'autres paquets soient reçus. Pour les autres événements, le problème est la perte du rapport d'événement initial plutôt que la maintenance de la continuité de l'exécution. L'avis sur la retransmission de ces autres événements déjà donnés ci-dessus est suffisant pour traiter la perte ou le retard de paquet dû à l'encombrement.

 	2.7.2	Utilisation des événements avec des modems V.18
La Recommandation UIT-T V.18 [V.18] définit un terminal pour la conversation de texte, éventuellement en combinaison avec la voix. V.18 est destiné à interopérer avec divers terminaux de texte traditionnels, de sorte que sa séquence de démarrage peut consister en une série de stimuli conçus pour déterminer ce qu'il y a à l'autre extrémité. Deux terminaux V.18 parlant ensemble vont utiliser V.8 pour négocier le démarrage et continuer au niveau physique avec V.21 à 300 bits/s portant des caractères de 7 bits bordés par des bits de début et d'arrêt.

Le terminal V.18 est aussi conçu pour interopérer avec les modems de texte énumérés dans le sous paragraphe précédent. Les séquences de démarrage pour tous ces différents types de terminaux sont naturellement assez différents. La séquence initiale de démarrage V.18 vise spécifiquement des terminaux à capacité V.8 et des terminaux V.21 et, par la combinaison des signaux, des terminaux de vidéotexte V.23. Durant la séquence initiale de démarrage, le terminal V.18 écoute sur les fréquences de réponses qui caractérisent les autres types de terminaux. Si il établit bien le contact dans l'étape préliminaire, il s'assure spécifiquement de chaque type. Par la nature de l'application, V.18 a été conçu pour fournir une capacité de démarrage extrêmement robuste.

Le traitement du signal V.18 XCI est un cas spécifique des procédures décrites au paragraphe précédent. XCI est un signal transmis en modulation V.23 bande supérieure pour stimuler les terminaux V.23 à répondre et permettre la détection de capacités V.18 chez un DCE. Le signal XCI de 3 secondes utilise le canal supérieur V.23 qui a des périodes de "marque" (c'est-à-dire, 1300 Hz) alternant avec le schéma XCIMark. La définition complète se trouve au paragraphe 3.13 de V.18. L'envoyeur DEVRAIT indiquer V23Main durant la transmission de la portion "marque" de XCI, et changer l'indication en XCIMark quand ce schéma est détecté.

 	2.8	Indicateur générique
Il existe de nombreux protocoles de modem propriétaires, ainsi que des protocoles normalisés non identifiés ci-dessus. Le Tableau 8 définit un seul événement d'indicateur qui peut être utilisé pour identifier le contenu d'un modem quand un événement plus spécifique n'est pas disponible. Normalement, il va être envoyé en combinaison avec un autre type de charge utile, par exemple, données de bande vocale, comme spécifié par la Recommandation UIT-T V.152 [V.152].

Comme avec les indicateurs du paragraphe précédent, l'envoyeur DEVRAIT générer un rapport d'événement initial aussitôt que la nature du contenu audio a été reconnue. Pour la fiabilité, le rapport d'événement initial DEVRAIT être retransmis deux fois à un court intervalle. (20 ms est une valeur suggérée, bien que la période de mise en paquets du support associé puisse être suffisante.) L'envoyeur PEUT continuer d'envoyer des rapports supplémentaires de l'événement VBDGen, bien qu'ils aient peu de valeur une fois que le receveur s'est ajusté au type de contenu qu'il reçoit.

Événement	Débit (bits/s)	Fréquence (Hz)	Code d'événement	Type 	Volume ?
VBDGen	Variable	Variable	61	autres	non

Tableau 8 : Indicateur générique de signal de modem

VBDGen : indique que l'envoyeur a détecté des schémas de tonalité qui indiquent le fonctionnement d'une certaine forme de modem. Cet indicateur NE DEVRAIT PAS être envoyé si un événement plus spécifique est disponible.

 	3.	Stratégies pour le traitement des signaux de télécopie et de modem

Comme décrit au paragraphe 1.2, l'application de données normale implique une paire de passerelles interposées entre deux terminaux, où les terminaux sont dans le RTPC. Les passerelles vont probablement desservir un mélange de trafic de voix et de données, et doivent adopter les types de charge utile appropriés aux flux de supports tels qu'ils arrivent. Si la compression vocale est utilisée pour les appels vocaux, cela signifie que les passerelles ont besoin de la souplesse de passer aux autres types de charge utile quand des flux de données sont reconnus.

Dans le cadre établi de l'IETF, cela implique que les passerelles doivent négocier les charges utiles potentielles (voix, événement de téléphonie, tonalités, données de bande vocale, télécopie T.38 [T.38], et éventuellement flux d'octets de texte [RFC4103] et Clearmode [RFC4040]) comme types de charge utile distincts. Du point de vue de l'écoulement du temps, cela est plus facilement fait tau début d'un appel, mais résulte en une sur allocation de ressources aux passerelles et dans le réseau intervenant.

Une solution de remplacement est d'utiliser des événements désignés pour gagner du temps tandis que des signaux hors bande sont échangés pour mettre à jour le nouveau type de charge utile applicable à la session. Grâce aux événements définis dans le présent document, c'est une approche viable pour les sessions qui commencent par les séquences de contrôle V.8, V.8 bis, T.30, ou V.25.

Les événements désignés relatifs aux données permettent aussi aux passerelles d'optimiser leur fonctionnement quand des signaux de données sont reçus sous une forme relativement générale. Un exemple est l'utilisation d'événements en rapport avec V.8 pour déduire que les données de bande vocale envoyées dans une charge utile G.711 viennent d'un modem de vitesse supérieure et donc exigent de désactiver les annuleurs d'écho.

Toutes les procédures de contrôle décrites dans les paragraphes de la Section 2 débouchent finalement sur le contenu de données. Comme mentionné précédemment, ce contenu va être porté par d'autres types de charge utile. Les passerelles receveuses DOIVENT être prêtes à passer aux autres type de charge utile dans les contraintes de temps associées aux applications respectives. (Pour plusieurs des procédures documentées ci-dessus, l'envoyeur fournit 75 ms de silence entre le signal initial de contrôle et l'envoi du contenu de données.) Dans certains cas ([V.8bis], [T.30]) plus de signalisation de contrôle peut se produire après l'établissement de l'appel.

Une stratégie possible est d'envoyer les deux charges utiles Événement de téléphonie et Données dans un arrangement de redondance de la [RFC2198]. La passerelle receveuse propage alors la charge utile de données chaque fois qu'aucun événement n'est en cours. Pour que cela fonctionne, la charge utile de données et les événements (quand ils sont présents) DOIVENT couvrir exactement le même contenu sur la même période ; autrement, des événements parasites vont être détectés en aval. Un exemple de ce mode de fonctionnement est montré ci-dessous.

Noter qu'il y a de nombreux cas où aucune séquence de contrôle ne va précéder le contenu de données. C'est vrai, par exemple, pour un certain nombre de types de terminaux de texte traditionnels. Dans ce cas, les événements définis au paragraphe 2.7 en particulier PEUVENT être envoyés pour aider la passerelle distante à optimiser son traitement de la charge utile de remplacement.

 	4.	Exemple de négociation V.8

Cette Section présente un exemple de l'utilisation des codes d'événement définis à la Section 2. Le scénario est la séquence de démarrage pour le fonctionnement de modem V.34 en duplex. On suppose qu'une fois que la séquence initiale V.8 est achevée, les passerelles vont entrer en fonctionnement de données de bande vocale en utilisant le codage G.711 pour transmettre les signaux de modem. La séquence de paquets de base est indiquée dans le Tableau 9. Les paquets d'échantillon sont alors montrés en détail pour deux variantes de stratégie de transmission d'événement :
o  transmission simultanée des événements et événements retransmis en utilisant la redondance de la [RFC2198] ;
o  transmission simultanée des événements, événements retransmis, et données de bande vocale couvrant le même contenu en utilisant la redondance de la RFC 2198.

Pour simplifier et approcher la réalité, les temps montrés dans l'exemple supposent un retard fixe à chaque passerelle de 20  ms entre le côté paquet de la passerelle et l'équipement d'utilisateur local et vice versa (c'est-à-dire, un minimum de 40  ms entre le paquet reçu et le paquet envoyé spécifiquement en réponse au paquet reçu). Un délai de propagation de 5 ms est supposé entre les passerelles. On suppose que l'intervalle de mise en paquet d'événement est 30 ms, compromis raisonnable entre volume de paquets et délai de mise en mémoire tampon, en particulier pour les événements V.21.

Au niveau de base du protocole V.8, le tableau suppose que le modem qui répond attend 0,2 s (200 ms) à partir du début de l'appel pour commencer à transmettre ANSam. Le modem appelant attend 1 s (1000 ms) à partir de l'instant où il commence à recevoir ANSam jusqu'à ce qu'il commence à envoyer le signal V.8 CM. Les deux modems attendent 75 ms à partir du moment où ils finissent respectivement d'envoyer et de recevoir CJ, jusqu'à ce qu'ils commencent à envoyer les signaux de modem V.34.

Temps (ms)	Événement	
220	La passerelle appelée détecte le début de ANSam à partir de sa fin.	
250	La passerelle appelée envoie le premier paquet d'événement ANSam. Le bit M est établi, l'horodatage est ts0 + 1760 (où ts0 est la valeur de l'horodatage au démarrage de l'appel). L'événement ANSam initial se poursuit jusqu'à ce qu'un glissement de phase soit détecté à 670 ms (voir ci-dessous). Jusqu'à cet instant, la passerelle appelée envoie d'autres mises à jour d'événement ANSam, avec le même horodatage initial, le bit M à zéro, et la durée cumulative augmentant de 240 unités à chaque fois.	
255	La passerelle appelante reçoit le premier rapport d'événement ANSam et commence à exécuter la tonalité ANSam dès sa fin.	
275	Le terminal appelant reçoit le début de la tonalité ANSam et lance son temporisateur. Il va commencer à envoyer le signal CM 1 s plus tard (à 1275 ms) dans l'appel.	
670	La passerelle appelée détecte un glissement de phase dans le signal entrant, marquant un changement de ANSam à /ANSam. Cela se trouve coïncider avec la fin d'un intervalle de mise en paquets. Pour l'exemple, on suppose que la passerelle appelée ne détecte pas cela à temps pour le rapport d'événement qu'elle envoie.	
700	La passerelle appelée produit le prochain paquet de rapport d'événement programmé, qui indique un rapport initial pour /ANSam (bit M établi, horodatage ts0 + 5360, durée 240 unités d'horodatage). Le paquet porte aussi la première retransmission du rapport final ANSam, durée totale 3600 units, cette fois avec le bit E établi.	
1295	La passerelle appelante commence à recevoir le signal CM provenant du modem appelant.	
1325	La passerelle appelante envoie un paquet contenant les 9 premiers bits du signal CM.	
1445	La passerelle appelante envoie un paquet contenant les 4 derniers bits du premier signal CM, plus les 5 premiers bits de la prochaine répétition de ce signal. Les bits de CM vont continuer d'être transmis de la passerelle appelante jusqu'à 2015 ms (voir ci-dessous) pour un total de 24 paquets. (Le paquet final porte aussi le début du signal CJ.)	
1596,7	La passerelle appelée achève l'exécution du bit final de la seconde occurrence du signal CM.	
1636,7	La passerelle appelée détecte la fin de /ANSam (et le début de JM) provenant du modem appelé. Le prochain paquet n'est pas encore à envoyer.	
1660	La passerelle appelée envoie un paquet combinant le rapport final d'événement /ANSam (bit E établi et durée totale de 533 unités d'horodatage) avec les 7 premiers bits du signal JM. Le bit M pour le paquet est établi et l'horodatage du paquet est ts0 + 12560 (début de l'événement /ANSam maintenant interrompu).	
1690	La passerelle appelée envoie un paquet contenant les neuf prochains bits du signal JM. Le bit M est établi et l'horodatage est ts0 + 13280 (début du premier bit du paquet). JM va continuer d'être transmis jusqu'à 2170  ms (voir ci-dessous) pour un total de 18 paquets (plus deux pour les retransmissions finales).	
1938,3	La passerelle appelante achève l'exécution du paquet final de la seconde occurrence du signal JM.	
1995	La passerelle appelante commence à recevoir les bits initiaux du signal CJ.	
2015	La passerelle appelante envoie un paquet contenant les 3 bits finaux de la première décade d'un signal CM et les 6 premiers bits d'un signal CJ.	
2095	La passerelle appelante reçoit le dernier bit du signal CJ. Une période de silence durant 75 ms commence à l'extrémité appelée. Il n'est pas encore temps d'envoyer un rapport d'événement.	
2105	La passerelle appelante envoie un paquet contenant les 6 bits finaux du signal CJ.	
2130	La passerelle appelée finit l'exécution du dernier bit du signal CJ qui lui a été envoyé.	
2135	La passerelle appelante envoie un paquet ne contenant pas de nouvel événement, mais des retransmissions des 15 derniers bits du signal CJ (en deux générations).	
2165	La passerelle appelante envoie un paquet ne contenant pas de nouvel événement, mais des retransmissions des 6 bits finaux du signal CJ.	
2170	La passerelle appelée envoie le dernier paquet contenant les bits du signal JM (sauf les retransmissions). Noter que conformément à la spécification de V.8, ces bits ne terminent en général pas un signal JM ou même un "octet" de ce signal (bien que cela arrive dans cet exemple). Une période de silence de 75  ms commence à l'extrémité appelée.	
2170	La passerelle appelante commence à recevoir de la signalisation V.34 du modem appelé.	
2175	La passerelle appelante termine l'exécution du ernier bit du signal JM qui lui est envoyé.	
2195	La passerelle appelante envoie un premier paquet de signalisation V.34 comme données de bande vocale (PCMU). L'horodatage est ts0 + 17360 et le bit M est établi pour indiquer le début du contenu après le silence. Le paquet contient 200 échantillons de 8 bits. L'intervalle de mise en paquets est montré ici comme continuant d'être de 30 ms. Il pourrait être moins, mais NE DOIT PAS être plus parce que cela rendrait la période de silence trop longue.	
2200	La passerelle appelée envoie un paquet ne contenant pas de nouvel événement, mais des retransmissions des 18 derniers bits du signal JM (en deux générations).	
2225	La passerelle appelante envoie le second paquet de signalisation V.34 comme données de bande vocale (PCMU). L'horodatage est ts0 + 17560 et le bit M n'est pas établi. Le paquet contient 240 échantillons de 8  bits.	
2230	La passerelle appelée envoie un paquet ne contenant pas de nouvel événement, mais des retransmissions des 9 bits finaux du signal JM.	
2245	La passerelle appelée commence à recevoir de la signalisation V.34 du modem appelé. 	
2255	La passerelle appelante envoie un troisième paquet de signalisation V.34 comme données de bande vocale (PCMU). L'horodatage est ts0 + 17800 et le bit M n'est pas établi. Le paquet contient 240 échantillons de 8  bits.	
2260	La passerelle appelée envoie un premier paquet de signalisation V.34 comme données de bande vocale (PCMU). L'horodatage est ts0 + 17960 et le bit M est établi pour indiquer le début du contenu après le silence. Le paquet contient 120 échantillons. L'intervalle de mise en paquets est montré ici comme continuant d'être 30 ms. Il pourrait être moins, mais NE DOIT PAS être plus parce que cela rendrait la période de silence trop longue.	

Tableau 9 : Événements pour un exemple de scénario V.8

 	4.1	Transmission simultanée d'événements et d'événements retransmis en utilisant la redondance de la RFC 2198
La négociation du mode de transmission décrit dans ce paragraphe va utiliser un SDP similaire à ce qui suit :

m=audio 12343 RTP/AVP 99
a=rtpmap:99 pcmu/8000
m=audio 12345 RTP/AVP 100 101
a=rtpmap:100 red/8000/1
a=fmtp:100 101/101/101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15,32-41,43,46,48-49,52-68

Cela indique deux flux de supports, le premier pour G.711 (c'est-à-dire, voix ou données de bande vocale) le second pour des événements de téléphonie triplement redondants. Comme le note la RFC 2198, il est aussi possible que l'envoyeur envoie des charges utiles Événement de téléphonie sans redondance dans le second flux, bien que la forme redondante soit le principal mode de transmission. (Il serait raisonnable d'envoyer les rapports intérimaires ANSam sans redondance.) L'ensemble des événements de téléphonie pris en charge inclut les événements DTMF (non pertinents dans cet exemple) et tous les événements de données définis dans le présent document. En fait, seuls les codes d'événement 34-35 et 37-40 sont utilisés dans l'exemple.

Pour illustrer l'utilisation de la redondance de la RFC 2198 ainsi que pour montrer la composition de base des rapports d'événement, le second paquet rapportant les bits du signal JM (envoyé par la passerelle appelée à 1690 ms) semble être un bon choix. Ce paquet va aussi porter la seconde retransmission du rapport final d'événement /ANSam et la première retransmission des 7 bits initiaux du signal JM. Le contenu détaillé du paquet est montré dans la Figure 1. Pour voir plus clairement le contenu des générations successives, elles sont présentées comme si elles étaient alignées sur des limites successives de 32 bits. En fait, elles sont toutes décalées d'un octet, se suivant de façon consécutive à partir de l'en-tête de la RFC 2198.

Le bit M est établi dans l'en-tête RTP pour le paquet, comme exigé pour le codage d'événements multiples dans le principal bloc de données. En fait, la RFC 2198 implique que c'est le comportement correct, mais ne le dit pas de façon aussi explicite. Le bit E bit est établi pour tous les événements. Il est possible qu'il ne soit pas établi pour l'événement final dans le bloc principal.

 0                   1                    2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3  4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC=0  |1|  PT=100     |Numéro de séquence = seq0 + 48 |
+---+-+-+-------+-+-------------+---------------+---------------+
|             Horodatage = ts0 + 13280                          |
+---------------+---------------+---------------+---------------+
|      Identifiant de source de synchronisation (SSRC)          |
+---------------+---------------+---------------+---------------+
|1| bloc PT=101 | Décalage d'horodatage =720| Long. de bloc = 4 |
+-+-------------+---------------+-----------+-+-+-+-+-+-+-+-+-+-+
|1| bloc PT=101 | Décalage d'horodatage =267| Long de bloc = 28 |
+-+-------------+---------------+-----------+---+---------------+
|0| bloc PT=101 |     (Début de bloc pour /ANSam ...)
+-+-------------+---------------+---------------+---------------+

Bloc /ANSam (seconde retransmission)

+-+-+-+-+-+-+-+-+-+-+-+---------+-+--------------+---------------+
| Événement = 35  |1|R| Volume    |           Durée = 533        |
+---------------+-+-+-+-+-+-+-+-+-+--------------+---------------+

7 premiers bits de JM (="1111111" dans le canal V.21 supérieur) (première retransmission)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Événement = 40 |1|R| Volume    |          Durée = 27         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ (5 événements similaires, durées 27,26,27,27,26 respectivement)/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Événement = 40 |1|R| Volume    |          Durée = 27         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

9 bits suivants de JM (="111000000" dans le canal V.21 supérieur) (nouveau contenu)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Événement = 40 |1|R| Volume    |          Durée = 27         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/  (7 événements similaires, codes 40,40,39,39,39,39,39 et      /
/      durées 26,27,27,26,27,27,26 respectivement)              /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Événement = 39 |1|R| Volume    |          Durée = 27         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1 : Contenu de paquet, événements redondants seulement

Comme tous les événements dans le paquet ci-dessus sont consécutifs et adjacents, il aurait été permis conformément à la spécification de charge utile Événement de téléphonie de les porter comme une simple charge utile d'événement sans l'en-tête de la RFC 2198. L'avantage de ce dernier est que la passerelle receveuse peut sauter les événements retransmis quand elle traite le paquet, sauf si elle en a besoin.

 	4.2	Transmission simultanée d'événements et de données en bande vocale avec la redondance RFC 2198
La négociation du mode de transmission décrite dans ce paragraphe utiliserait un SDP similaire à ce qui suit :

m=audio 12343 RTP/AVP 99 100 101
a=rtpmap:99 red/8000/1
a=fmtp:99 100/101/101/101
a=rtpmap:100 pcmu/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15,32-41,43,46,48-49,52-68

Cela indique un flux de supports, avec G.711 (c'est-à-dire, voix ou données de bande vocale) comme contenu principal, avec trois blocs d'événements de téléphonie. La RFC 2198 exige que la représentation la plus volumineuse (c'est-à-dire, le G.711) soit le principal. Le plus récent bloc d'événements couvre la même période que les données de bande vocale. Les deux autres flux fournissent la première et la seconde retransmission des événements comme dans l'exemple précédent. Parce que G.711 est le contenu principal, le bit M pour les paquets ne va en général pas être établi, sauf après les périodes de silence.

La Figure 2 montre le détail du contenu des paquets pour le même point d'échantillonnage que dans la figure précédente, mais en incluant le contenu G.711.

 0                   1                    2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3  4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC=0  |0|  PT=99      | Numéro de séquence = seq0 + 48|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Horodatage = ts0 + 13280                          |
+---------------+---------------+---------------+---------------+
|     Identifiant de source de synchronisation (SSRC)           |
+---------------+---------------+---------------+---------------+
|1| Bloc PT=101 | Décalage horodatage = 720 | Longueur bloc = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Bloc PT=101 | Décalage horodatage = 267 | Longueur bloc = 28|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Bloc PT=101 | Décalage horodatage = 0   | Longueur bloc = 36|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Bloc PT=100 |     (Début de bloc /ANSam ...)
+-+-+-+-+-+-+-+-+---------------+---------------+---------------+

Bloc /ANSam (secondr retransmission)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Événement = 35 |1|R| Volume    |       Durée = 533           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

7 premiers bits de JM (="1111111" dans le canal V.21 supérieur) (première retransmission)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Événement = 40 |1|R| Volume    |       Durée = 27            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ (5 événements similaires, durées 27,26,27,27,26 respectivement)/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Événement = 40 |1|R| Volume    |       Durée = 27            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

9 bits suivants de JM (="111000000" dans le canal V.21 supérieur) (nouveau contenu)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Événement = 40 |1|R| Volume    |       Durée = 27            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/  (7 événements similaires, codes 40,40,39,39,39,39,39 et      /
/      durées 26,27,27,26,27,27,26 respectivement)              /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Événement = 39 |1|R| Volume    |       Durée = 27            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

30 ms de données de bande vocale codée en G.711 (240 échantillons)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Échantillon 1 | Échantillon 2 | Échantillon 3 | Échantillon 4 |
+---------------+---------------+---------------+---------------+
/                            . . .                              /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Échantillon 237|Échantillon 238|Échantillon 239|Échantillon 240|
+---------------+---------------+---------------+---------------+

Figure 2 : Contenu de paquet avec données en bande vocale combinées avec des événements

 	5.	Considérations sur la sécurité

Les événements de bit V.21 définis dans le présent document peuvent être utilisés pour transmettre des données d'utilisateur sensibles. Cela pourrait inclure des séquences initiales de connexion et des échanges de protocole de niveau application ainsi que du contenu d'utilisateur. Par suite, un tel usage des événements de bit V.21 entraîne, dans la terminologie de la [RFC3552], des menaces pour la sécurité des communications et des systèmes. Les attaques concernées sont :
o	des violations de la confidentialité et l'espionnage des mots de passe ;
o	la capture des sessions de données par l'insertion de messages ;
o	la modification du contenu transmis par des attaques par interposition ;
o	le déni de service au moyen d'insertion, suppression, et modification de messages visant à interférer avec le protocole d'application.

Pour empêcher ces attaques, la transmission des événements de bit V.21 DOIT recevoir une protection de la confidentialité. L'authentification du message et la protection de l'intégrité du message DOIVENT aussi être fournies. Cela vise les menaces d'insertion et modification de message. Avec la mise en place de ces mesures, les numéros de séquence RTP et la redondance fournie par les procédures de la RFC 4733 pour la transmission des événements ajoutent la protection et une certaine résilience à la suppression de message.

Les autres événements définis dans le présent document (et les événements de bit V.21 au sein des séquences de contrôle) sont utilisés seulement pour l'établissement et le contrôle des sessions entre les terminaux de données ou les appareils de télécopie. Bien que la divulgation de ces événements n'expose pas de données sensibles de l'utilisateur, elle peut éventuellement exposer les capacités de l'équipement d'utilisateur qui pourraient être exploitées par des attaques dans le domaine RTPC. Donc, la protection de la confidentialité DEVRAIT être assurée. La principale menace est le déni de service, par l'injection de signaux inappropriés à des points vulnérables de la séquence de contrôle ou par l'altération ou le blocage d'assez de paquets d'événement pour interrompre cette séquence. Pour répondre à cette menace d'injection, l'authentification et la protection de l'intégrité du message DOIVENT être assurées.

Le protocole de transport sécurisé en temps réel (SRTP, Secure Real-time Transport Protocol) [RFC3711] satisfait aux exigences de protection de la confidentialité, de l'intégrité du message, et de l'authentification de message décrites ci-dessus. Il DEVRAIT donc être utilisé pour protéger les flux de supports qui contiennent les événements décrits dans le présent document.

Noter que la méthode appropriée de distribution de clés pour SRTP peut varier selon l'application.

Dans certains déploiements, il peut être préférable d'utiliser d'autres moyens pour assurer une protection équivalente à celle de SRTP.

 	6.	Considérations relatives à l'IANA

Le présent document ajoute les événements du Tableau 10 au registre établi par la [RFC4733].

Code d'événement	Nom d'événement	Référence	
23	CrdSeg : second segment du signal V.8 bis CRd	RFC 4734	
24	CreSeg : second segment du signal V.8 bis CRe	RFC 4734	
25	MrdSeg : second segment du signal V.8 bis MRd	RFC 4734	
26	MreSeg : second segment du signal V.8 bis MRe	RFC 4734	
27	V32AC : schéma de bits modulés à 4800 bits/s, émis par un terminal V.32/V.32bis de réponse à la détection du schéma AA.	RFC 4734	
28	V8bISeg : premier segment d'initiation de signal V.8 bis	RFC 4734	
29	V8bRSeg : premier segment de réponse de signal V.8 bis	RFC 4734	
30	V21L300 : indication de canal inférieur V.21 à 300 bits/s	RFC 4734	
31	V21H300 : indication de canal supérieur V.21 à 300 bits/s	RFC 4734	
32	ANS (tonalité de réponse V.25). Aussi appelé CED| (tonalité appelée T.30).	RFC 4734	
33	/ANS (tonalité de réponse V.25 après glissement de phase). Aussi appelé /CED (tonalité appelée T.30 après glissement de phase).	RFC 4734	
34	ANSam (tonalité de réponse V.8 à amplitude modifiée).	RFC 4734	
35	/ANSam (tonalité de réponse V.8 à amplitude modifiée après glissement de phase).	RFC 4734	
36	CNG (tonalité d'appel T.30).	RFC 4734	
37	Canal 1 V.21 (canal inférieur), bit '0'.	RFC 4734	
38	Canal 1 V.21, bit '1'. Aussi utilisé pour ESiSeg (second segment de signal ESi V.8 bis).	RFC 4734	
39	Canal 2 V.21, bit '0'.	RFC 4734 |	
40	Canal 2 V.21, bit '1'. Aussi utilisé pour ESrSeg (second segment de signal ESr V.8 bis).	RFC 4734	
49	CT (Tonalité d'appel V.25).	RFC 4734	
52	ANS2225 : indication de texte téléphoné à 2225 Hz.	RFC 4734	
53	CI (préambule de signal d'indication d'appel V.8).	RFC 4734	
54	Fanion de préambule V.21 (T.30)	RFC 4734	
55	V21L110 : indication de texte téléphoné à 110 bits/s V.21.	RFC 4734	
56	B103L300 : indication de texte téléphoné sur canal inférieur Bell 103.	RFC 4734	
57	V23Main : indication de canal principal V.23 pour texte téléphoné.	RFC 4734	
58	V23Back : indication de canal de retour V.23 pour texte téléphoné.	RFC 4734	
59	Baud4545 : indication de texte téléphoné Baudot à 45,45 bits/s.	RFC 4734	
60	Baud50 : indication de texte téléphoné Baudot à 50 bits/s.	RFC 4734	
61	VBDGen : indication de schéma de tonalité à utiliser pour un type de modem non identifié.	RFC 4734	
62	XCIMark : schéma de bits modulés dans le canal pricipal V.23, émis par un terminal appelant V.18.	RFC 4734	
63	V32AA : schéma de bits modulés à 4800 bits/s, émis par un terminal appelant V.32/V.23bis.	RFC 4734	

Tableau 10 : Ajouts relatifs aux données au registre d'événement de téléphonie de la RFC 4733

 	7.	Remerciements

Scott Petrack était l'auteur original de la RFC 2833. Henning Schulzrinne a ensuite prêté son expertise pour compléter le document, mais Scott doit être crédité de l'énergie derrière l'idée d'un codage compact des tonalités sur IP.

Gunnar Hellstrom et Keith Chu ont fourni des commentaires qui ont été particulièrement utiles à structurer le présent document. Amiram Allouche et Ido Benda ont attiré l'attention des auteurs sur l'intérêt d'inclure des événements pour V.32/V.32bis dans le document, et Yaakov Stein a confirmé les détails du fonctionnement de ce modem.

 	8.	Références
 	8.1	Références normatives

[G.164]	Recommandation UIT-T G.164, "Suppresseurs d'écho", UIT-T, novembre 1988.

[G.165]	Recommandation UIT-T G.165, "Annuleurs d'écho", UIT-T, mars 1993.

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

[RFC2198]	C. Perkins et autres, "Charge utile RTP pour données audio redondantes", septembre 1997. (P.S.)

[RFC3711]	M. Baugher et autres, "Protocole de transport sécurisé en temps réel (SRTP)", mars 2004. (P.S.)

[RFC4566]	M. Handley, V. Jacobson et C. Perkins, "SDP : Protocole de description de session", juillet 2006. (P.S.  ; remplacée par RFC8866)

[RFC4733]	H. Schulzrinne, T. Taylor, "Charge utile RTP pour chiffres DTMF, tonalités téléphoniques, et signaux de téléphonie", décembre 2006. (Remplace RFC2833) (MàJ par RFC4734, RFC5244) (P.S.)

[T.30]	Recommandation UIT-T T.30, "Procédures pour la transmission de documents de télécopie sur le réseau téléphonique commuté général", UIT-T, juillet 2003.

[V.8]	Recommandation UIT-T V.8, "Procédures pour le démarrage de sessions de transmission de données sur le réseau téléphonique public commuté", UIT-T, novembre 2000.

[V.8bis]	Recommandation UIT-T V.8bis, "Procédures pour l'identification et le choix de modes commun de fonctionnement entre équipements de terminaison de circuit de données (RETCD) et entre équipements terminaux de données (ETD) sur le réseau téléphonique public commuté et sur les circuits loués point à point de type téléphonique", UIT-T, novembre 2000.

[V.18]	Recommandation UIT-T V.18, "Exigences de fonctionnement et d'inter fonctionnement pour les équipements terminaux de circuits de données fonctionnant en mode de texte téléphoné", (Union Internationale des Télécommunications, Genève, février 1998). Voir aussi la Recommandation V.18, Amendement 1, nov. 2002.

[V.21]	Recommandation UIT-T V.21, "Modem duplex à 300 bits par seconde normalisé pour le réseau téléphonique commuté général", UIT-T, novembre 1988.

[V.25]	Recommandation UIT-T V.25, "Équipement de réponse automatique et procédures générales pour équipement d'appel automatique sur le réseau téléphonique commuté général incluant les procédures pour désactiver les appareils de contrôle d'écho pour les appels établis manuellement et automatiquement", UIT-T, octobre 1996. Voir aussi le corrigendum 1 à la Recommandation V.25, juillet 2001.

[V.32]	Recommandation UIT-T V.32,  "Famille de modems duplex deux fils fonctionnant à des taux de signalisation de données jusqu'à 9600 bit/s à utiliser sur le réseau téléphonique commuté général et sur les circuits loués de type téléphonique", UIT-T, mars 1993.

[V.32bis]	Recommandation UIT-T V.32bis, "Modem duplex fonctionnant à des taux de signalisation de données jusqu'à 14  400 bit/s à utiliser sur le réseau téléphonique commuté général et sur les circuits loués point à point de type téléphonique", UIT-T, février 1991.

 	8.2	Références pour information

[G.711]	Recommandation UIT-T G.711, "Modulation par impulsions et codage (MIC) des fréquences vocales", UIT-T, novembre 1988.

[H.324]	Recommandation UIT-T H.324, "Terminal pour communication multimédia à faible débit binaire", UIT-T, mars 2002.

[RFC3552]	E. Rescorla, B. Korver, "Lignes directrices pour la rédaction d'une section de considérations sur la sécurité dans les RFC", juillet 2003. (BCP0072)

[RFC4040]	R. Kreuter, "Format de charge utile RTP pour un appel transparent à 64 kbit/s", avril 2005. (P.S.)

[RFC4103]	G. Hellstrom, P. Jones, "Charge utile RTP pour conversation textuelle", juin 2005. (Remplace RFC2793) (P.S.)

[T.38]	Recommandation UIT-T T.38, "Procédures pour la communication en temps réel de télécopie groupe 3 sur les réseaux IP", UIT-T, juillet 2003.

[T.101]	Recommandation UIT-T T.101, "Interfonctionnement international pour les services vidéotexte", UIT-T, novembre 1994.

[T.120]	Recommandation UIT-T T.120, "Protocoles de données pour conférence multimédia", UIT-T, juillet 1996.

[TIA-825-A]	Telecommunications Industry Association, "A Frequency Shift Keyed Modem for Use on the Public Switched Telephone Network", ANSI TIA- 825-A-2003, avril 2003.

[V.17]	Recommandation UIT-T V.17, "Modem deux fils pour applications de télécopie à des débits jusqu'ào 14 400 bit/s", UIT-T, févrirr 1991.

[V.23]	Recommandation UIT-T V.23, "Modem à 600/1200 bauds normalisé pour l'utilisation dans le réseau téléphonique commuté général", UIT-T, novembre 1988.

[V.27ter]	Recommandation UIT-T V.27ter, "Modem à 4800/2400 bits/s normalisé pour l'utilisation dans le réseau téléphonique commuté général", UIT-T, novembre 1988.

[V.29]	Recommandation UIT-T V.29, "Modem à 9600 bits/s normalisé pour l'utilisation sur les circuits loués point à point de type téléphonique", UIT-T, novembre 1988.

[V.34]	Recommandation UIT-T V.34, "Modem fonctionnant à des taux de signalisation de données jusqu'à 33 600 bit/s pour utilisation dans le réseau téléphonique commuté général et sur les circuits loués point à point de type téléphonique", UIT-T, février 1998.

[V.90]	Recommandation UIT-T V.90, "Paire de modem numérique et de modem analogique à utiliser sur le réseau téléphonique public commuté (RTPC) à des taux de signalisation de données jusqu'à 56 000 bit/s vers l'aval et jusqu'à 33 600 bit/s vers l'amont", UIT-T, septembre 1998.

[V.91]	Recommandation UIT-T V.91, "Modem numérique fonctionnant à des taux de signalisation de données jusqu'à 64 000 bit/s à utiliser sur une connexion de circuit commuté 4 fils et sur les circuits loués point à point 4 fils numériques", UIT-T, mai 1999.

[V.92]	Recommandation UIT-T V.92, "Améliorations à la Recommandation V.90", UIT-T, novembre 2000.

[V.150.1]	Recommandation UIT-T V.150.1, "Réseaux à modem sur IP : procédures pour la connexion de bout en bout d'équipement terminal de circuit de données de la série V", UIT-T, janvier 2003.

[V.152] 	Recommandation UIT-T V.152, "Procédures pour la prise en charge de données dans la bande vocale sur réseaux IP", UIT-T, janvier 2005.

 	Adresse des auteurs
Henning Schulzrinne	Tom Taylor	
Columbia U.	Nortel	
Dept. of Computer Science	1852 Lorraine Ave	
Columbia University	Ottawa, Ontario  K1H 6Z8	
1214 Amsterdam Avenue	Canada	
New York, NY  10027	mél : taylor@nortel.com 	
USA		
mél : schulzrinne@cs.columbia.edu 		

 	Déclaration complète de droits de reproduction
Copyright (C) The Internet Society (2006)

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, 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, le IETF TRUST 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 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.

Remerciement
Le financement de la fonction d'édition des RFC est actuellement assuré par la Internet Society.