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

Charge utile RTP pour chiffres DTMF, tonalités et signaux téléphoniques

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 décrit comment porter la signalisation multifréquence bi-tonalités (DTMF, dual-tone multifrequency) les autres signaux de tonalité et les événements de téléphonie dans les paquets RTP. Il rend obsolète la RFC 2833.

Le présent mémoire s'appuie sur le cadre de base défini dans la RFC 2833 et l'étend, mais ne conserve que les codes d'événements les plus basiques. Il établit un registre IANA auquel d'autres allocations de code d'événement peuvent être ajoutées. Des documents d'accompagnement ajoutent des codes d'événements à ce registre en relation avec les événements de signalisation associés au modem, à la télécopie, au texte téléphoné, et au canal. Le reste des codes d'événements définis dans la RFC 2833 est conditionnellement réservé au cas où d'autres documents reprendraient leur utilisation.

Le présent document apporte un certain nombre de précisions au document d'origine. Cependant, il diffère spécifiquement de la RFC 2833 en supprimant l'exigence que toutes les mises en œuvre conformes prennent en charge les événements DTMF. Les mises en œuvre conformes qui prennent part aux négociations hors bande de contenu du flux de supports doivent plutôt indiquer quels événements elles prennent en charge. Le présent mémoire ajoute trois nouvelles procédures au cadre de la RFC 2833 : la subdivision de longs événements en segments, le rapport de multiples événements dans un seul paquet, et le concept de rapport des événements d'état.
Table des matières
1. Introduction	2
1.1 Terminologie	2
1.2. Généralités	2
1.3 Applications potentielles	2
1.4 Événements, états, schémas de tonalités, et tonalités vocales codées	3
2. Format de charge utile RTP pour les événements de téléphone désignés	4
2.1 Introduction	4
2.2 Utilisation des champs d'en-tête RTP	4
2.3 Format de charge utile	4
2.4 Paramètres facultatifs de type de support	5
2.5 Procédures	6
2.6 Encombrement et performances	10
3. Spécification des codes d'événements pour les événements DTMF	12
3.1 Applications DTMF	12
3.2 Événements DTMF	13
3.3 Considérations d'encombrement	13
4. Format de charge utile RTP pour tonalités téléphoniques	14
4.1 Introduction	14
4.2 Exemples de signaux de tonalité téléphonique courants	14
4.3 Utilisation des champs d'en-tête RTP	15
4.4 Procédures	16
5. Exemples	16
6. Considérations de sécurité	21
7. Considérations relatives à l'IANA	21
7.1 Enregistrements de type de support	22
8. Remerciements	23
9. Références	23
9.1 Références normatives	24
9.2 Références pour information	24
Appendice A. Résumé des changements par rapport à la RFC 2833	25
Adresses des auteurs	26
Déclaration complète de droits de reproduction	26

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

Le présent document utilise les abréviations suivantes :
ANSam (Answer tone (amplitude modulated)) tonalité de réponse (en modulation d'amplitude) [V.8]
DTMF (Dual-Tone Multifrequency) multifréquence bi-tonalités [Q.23]
IVR (Interactive Voice Response unit) unité de réponse vocale interactive
PBX (Private branch exchange) commutateur privé (système téléphonique)
RTPC : réseau téléphonique public commuté (par circuits)
RTP (Real-time Transport Protocol) protocole de transport en temps réel [RFC3550]
SDP (Session Description Protocol) protocole de description de session [RFC4566]

 	1.2.	Généralités
Le présent mémoire définit deux formats de charge utile RTP [RFC3550], un pour porter les chiffres de bi-tonalités multifréquences (DTMF) et les autres signaux de ligne et jonctions comme des événements (Section 2), et le second pour décrire les tonalités multifréquences générales en termes seulement de leur fréquence et cadence (Section 4). Des formats de charge utile RTP séparés pour les signaux de tonalité de téléphonie sont souhaitables car il ne peut pas être garanti que les codecs vocaux à bas débit puissent reproduire ces signaux de tonalités de façon assez précise pour une reconnaissance automatique. De plus, les propriétés de tonalités comme les inversions de phase dans la tonalité ANSam ne vont pas survivre au codage de la parole. Définir des formats de charge utile séparés permet aussi une plus forte redondance tout en maintenant un faible débit binaire. Finalement, certains événements de téléphonie comme le "raccroché" se produisent hors bande et ne peuvent pas être transmis comme des tonalités.

La suite de cette section indique les motifs de la définition des types de charge utile décrits dans le présent document. La Section 2 définit le format de charge utile et les procédures associées pour l'utilisation des événements désignés. La Section 3 décrit les événements pour lesquels des codes d'événement sont définis dans ce document. La Section 4 décrit le format de charge utile et les procédures associées pour les représentations de tonalités. La Section 5 donne des exemples d'événements codés, de tonalités, et de charges utiles combinées. La Section 6 traite des considérations de sécurité. La Section 7 définit les exigences de l'IANA pour l'enregistrement des codes d'événement pour les événements de téléphonie désignés, établit le contenu initial de leur registre, et donne les enregistrements de type de supports pour les deux formats de charge utile. L'Appendice A décrit les changements par rapport à la [RFC2833] et en particulier indique la disposition des codes d'événement définis dans la [RFC2833].

 	1.3	Applications potentielles
Les formats de charge utile décrits ici peuvent être utiles dans un certain nombre de scénarios différents.

Du côté envoyeur, il y a deux possibilités de base : soit le côté envoyeur est an système d'extrémité qui génère lui-même les signaux, soit il est une passerelle qui a pour tâche de propager les signaux de téléphonie entrants dans l'Internet.

Du côté receveur, il y a plus de possibilités. La première est que le receveur doit propager avec précision les tonalités de signalisation dans le RTPC pour la consommation de la machine. Un exemple est celui d'une passerelle qui passe les tonalités DTMF à une IVR. Dans ce scénario, les fréquences, les amplitudes, les durées des tonalités, et les durées de pause entre les tonalités sont toutes significatives, et les signaux de tonalités individuelles doivent être livrés fiablement et dans l'ordre.

Dans un second scénario de réception, le receveur doit exécuter les tonalités pour la consommation humaine. Normalement, plutôt qu'une série de signaux de tonalités ayant chacun sa propre signification, le contenu va consister en une seule tonalité exécutée en continu ou une seule séquence de tonalités et éventuellement un silence, répétée de façon cyclique pendant un certain temps. Souvent, la fin de l'exécution de la tonalité va être déclenchée par un événement en réaction dans l'autre direction, en utilisant des moyens dans la bande ou hors bande. Des exemples sont les tonalités de numérotation ou la tonalité d'occupation.

La relation entre la position dans le réseau et les tonalités à exécuter est un facteur de complication dans ce scénario. Dans le réseau téléphonique, les tonalités sont générées à des endroits différents, selon la technologie de commutation et la nature de la tonalité. Cela détermine, par exemple, si une personne qui passe un appel à l'étranger entend les tonalités locales qui lui sont familières ou les tonalités utilisées dans le pays appelé.

Pour les lignes analogiques, la tonalité de numérotation est toujours générée par le commutateur local. Les terminaux du réseau numérique à intégration de services (RNIS) peuvent générer des tonalités de numérotation en local, puis envoyer un message SETUP [Q.931] contenant les chiffres numérotés. Si le terminal envoie juste un message SETUP sans aucun des chiffres du numéro demandé, le commutateur fait alors la collecte des chiffres (fournis par le terminal comme informations KEYPAD de clés pressées dans les éléments d'information Called Party ou Keypad Facility des messages INFORMATION) et fournit la tonalité de numérotation sur le canal B. Le terminal peut utiliser le signal audio sur le canal B ou utiliser les messages Q.931 pour déclencher la tonalité de numérotation générée en local.

La tonalité de sonnerie (aussi appelée tonalité de retour d'appel) est générée par le commutateur local chez l'appelé, avec un chemin vocal unidirectionnel ouvert aussitôt que le téléphone de l'appelé sonne. (Cela réduit les chances de coupure de la réponse de l'appelé juste après la réponse. Cela permet aussi des annonces de pré réponse ou des indications dans la bande de progression d'appel pour atteindre l'appelant avant ou à la place d'une tonalité d'appel.) La tonalité d'encombrement et les tonalités d'informations spéciales peuvent être générées par tout commutateur sur le chemin, et peuvent être générées par le commutateur de l'appelant sur la base des messages du sous-système utilisateur RNIS (ISUP, ISDN User Part) reçus.  La tonalité d'occupation est générée par le commutateur de l'appelant, déclenchée par le message ISUP approprié, pour les instruments analogiques , ou le terminal RNIS.

Dans le troisième scénario, un système d'extrémité est directement connecté à l'Internet et traite directement le flux de supports entrant. Il n'y a pas besoin de régénérer les signaux de tonalités, de sorte que l'alignement temporel et des niveaux de puissance n'ont pas lieu d'être. Ces systèmes s'appuient sur les systèmes envoyeurs pour générer les événements à la place des tonalités et n'effectuent pas leur propre analyse de forme d'onde audio. Un exemple de ce système est un système Internet de réponse vocale interactive (IVR).

Dans des circonstances où un alignement temporel exact entre le flux audio et les chiffres DTMF ou autres événements n'est pas important et où les données sont envoyées en envoi individuel, comme dans l'exemple de IVR, il peut être préférable d'utiliser un protocole de contrôle fiable plutôt que des paquets RTP. Dans ces circonstances, ce format de charge utile ne va pas être utilisé.

Noter que dans un certain nombre de ces cas, il est possible que la passerelle ou système d'extrémité soit à la fois un envoyeur et un receveur des signaux téléphoniques. Parfois la même classe de signaux va être envoyée comme reçue -- dans le cas "d'agrégation RTP" ou de données en bande vocale, par exemple. Dans d'autres cas, comme celui d'un système d'extrémité qui dessert des lignes analogiques, les signaux envoyés vont être dans une classe différente de celle reçue.

 	1.4	Événements, états, schémas de tonalités, et tonalités vocales codées
Le présent document donne le moyen de transporter dans la bande sur l'Internet deux grandes classes d'informations de signalisation : les tonalités dans la bande ou séquences de tonalités, et les signaux envoyés hors bande dans le RTPC. Les signaux de tonalités peuvent être portés en utilisant une des trois méthodes citées ci-dessous. Selon l'application, il peut être souhaitable de porter les informations de signalisation dans plus d'une forme à la fois.

1.	La passerelle ou système d'extrémité peut changer pour un codec de bande passante supérieure tel que [G.711] quand des signaux de tonalité sont à transporter. Voir dans la nouvelle Recommandation UIT-T V.152 [V.152] un traitement formel de cette approche. Autrement, pour les signaux respectivement de télécopie, de texte, ou de modem, un transport spécialisé comme [T.38], [RFC4103], ou un modem relais [V.150.1] peut être utilisé. Finalement, des canaux à 64  kbit/s peuvent être portés de façon transparente en utilisant le type de charge utile Clearmode de la [RFC4040]. Ces méthodes sortent du domaine d'application du présent document, mais peuvent être utilisées avec les types de charge utile définis ici.

2.	La passerelle envoyeuse peut simplement mesurer les composants de fréquence du signal en bande vocale et transmettre ces informations au receveur RTP en utilisant la représentation de tonalités définie dans ce document (Section 4). Dans ce mode, la passerelle ne tente pas de discerner la signification des tonalités, mais simplement distingue les tonalités des signaux de parole. Un système d'extrémité peut utiliser la même approche en utilisant des fréquences configurées plutôt que mesurées.
Tous les signaux de tonalités utilisés dans le RTPC et destinés à la consommation humaine sont des séquences de simples combinaisons d'ondes sinusoïdales, additives ou modulées. (Cependant, certains signaux de modem comme la tonalité ANSam [V.8] ou dépendants du système en modulation par déplacement de phase ne peuvent pas être convoyés aussi simplement.)

3.	En troisième option, une passerelle envoyeuse peut reconnaître des tonalités comme de sonnerie ou d'occupation ou de chiffre DTMF '0', et transmettre un code qui les identifie en utilisant la charge utile Événement de téléphonie définie dans ce document (Section 2). Le receveur produit alors un signal de tonalité ou autre indication appropriée au signal. Généralement, comme la reconnaissance des signaux chez l'envoyeur dépend souvent de leur schéma d'activation/ désactivation ou de la séquence de plusieurs tonalités, cette reconnaissance peut prendre plusieurs secondes. Par ailleurs, la passerelle peut avoir accès aux informations réelles de signalisation qui génèrent les tonalités et peut donc générer immédiatement le paquet RTP, sans le détour par des signaux acoustiques.

La troisième option (utilisation d'événements désignés) est la seule méthode faisable pour transmettre des signaux RTPC hors bande comme contenus dans des sessions RTP.

 	2.	Format de charge utile RTP pour les événements de téléphone désignés
 	2.1	Introduction
Le format de charge utile RTP pour les événements de téléphonie désignés est appelé "événement de téléphonie", et le type de support est "événement audio/téléphone". En accord avec la pratique courante, ce format de charge utile n'a pas de numéro statique de type de charge utile, mais utilise un numéro de type de charge utile RTP établi de façon dynamique et hors bande. La fréquence d'horloge par défaut est 8000 Hz, mais la fréquence d'horloge peut être redéfinie lors de l'allocation dynamique du type de charge utile.

Les événements de téléphonie désignés sont portés au titre du flux audio et DOIVENT utiliser le même numéro de séquence et la même base d'horodatage que le canal audio régulier pour simplifier la génération des signaux audio à une passerelle. Le type de charge utile événement de téléphonie désigné peut être considéré comme étant un codec audio très hautement compressé et est traité comme les autres codecs.

 	2.2	Utilisation des champs d'en-tête RTP
 	2.2.1	Horodatage
La durée d'événement décrite au paragraphe 2.5 commence à l'instant donné par l'horodatage RTP. Pour les événements qui s'étendent sur plusieurs paquets RTP, l'horodatage RTP identifie le début de l'événement, c'est-à-dire que plusieurs paquets RTP peuvent porter le même horodatage. Pour les événements de longue durée qui doivent être partagés en segments (voir au paragraphe 2.5.1.3) l'horodatage indique le début du segment.

 	2.2.2	Bit marqueur
Le bit marqueur RTP indique le début d'un nouvel événement. Pour les événements de longue durée qui doivent être partagés en segments (voir au paragraphe 2.5.1.3) seul le premier segment va avoir le bit marqueur établi.

 	2.3	Format de charge utile
Le format de charge utile pour les événements de téléphonie désignés est montré par la Figure 1.

 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énement    |E|R| Volume    |              Durée            |
+---------------+---+-----------+---------------+---------------+

Figure 1 : Format de charge utile pour événements désignés

 	2.3.1	Champ Événement
Le champ Événement est un nombre entre 0 et 255 qui identifie un événement de téléphonie spécifique. Un registre IANA des codes d'événement pour ce champ a été établi (voir la Section 7, Considérations relatives à l'IANA). Le contenu initial de ce registre consiste en les événements définis à la Section 3.

 	2.3.2	Bit E
Si il est réglé à la valeur de un, le bit "E" indique que ce paquet contient la fin de l'événement. Pour les événements de longue durée qui doivent être partagés en segments (voir ci-dessous au paragraphe 2.5.1.3) seul le paquet final pour le segment final aura le bit E établi à 1.

 	2.3.3	Bit R
Ce champ est réservé pour une utilisation future. L'envoyeur DOIT le régler à zéro, et le receveur DOIT l'ignorer.

 	2.3.4	Champ Volume
Pour les chiffres DTMF et autres événements représentables comme des tonalités, ce champ décrit le niveau de puissance de la tonalité, exprimée en dBm0 après l'élimination du signe. Les niveaux de puissance sont dans la gamme de 0 à –  63  dBm0. Donc, les plus grandes valeurs notent un plus faible volume. Cette valeur n'est définie que pour les événements pour lesquels la documentation indique qu'un volume est applicable. Pour les autres événements, l'envoyeur DOIT régler le volume à zéro et le receveur DOIT ignorer la valeur.

 	2.3.5	Champ Durée
Le champ Durée indique la durée de l'événement ou segment rapporté, en unités d'horodatage, exprimée comme un entier non signé dans l'ordre des octets du réseau. Pour une valeur non zéro, l'événement ou segment commence à l'instant identifié par l'horodatage RTP et a jusqu'alors duré aussi longtemps qu'indiqué par ce paramètre. L'événement peut ou non s'être terminé. Si la durée de l'événement excède le maximum représentable par le champ Durée, l'événement est partagé en plusieurs segments contigus comme décrit ci-dessous au paragraphe 2.5.1.3.

La valeur de durée spéciale de zéro est réservée pour indiquer que l'événement dure "pour toujours", c'est-à-dire, est un état et est considéré comme étant effectif jusqu'à ce qu'il soit mis à jour. Un envoyeur NE DOIT PAS transmettre une durée de zéro pour des événements autres que ceux définis comme des états. Le receveur DEVRAIT ignorer un rapport d'événement avec une durée de zéro si l'événement n'est pas un état.

Les événements définis comme des états PEUVENT contenir une durée non zéro, indiquant que l'envoyeur a l'intention de rafraîchir l'état avant que la durée soit écoulée ("état mou").

Pour un taux d'échantillonnage de 8000 Hz, le champ Durée est suffisant pour exprimer des durées d'événement jusqu'à approximativement 8 secondes.

 	2.4	Paramètres facultatifs de type de support
Comme indiqué dans l'enregistrement de type de support pour les événements désignés au paragraphe 7.1.1, le type de support Événement de téléphonie prend en charge deux paramètres facultatifs : le paramètre "événements" et le paramètre "taux".

Le paramètre "événements" fait la liste des événements pris en charge par la mise en œuvre. Les événements sont énumérés comme un ou plusieurs éléments séparés par une virgule. Chaque élément peut être un seul entier donnant la valeur d'un code d'événement ou un entier suivi par un tiret et un plus grand entier, présentant une gamme de valeurs consécutives de codes d'événement. La liste n'a pas besoin d'être triée. Aucune espace n'est permise dans l'argument. L'union de tous les codes individuels d'événement et gammes de codes d'événement désigne l'ensemble complet de numéros d'événement pris en charge par la mise en œuvre.

Le paramètre "taux" décrit le taux d'échantillonnage, en Hertz, et donc les unités pour les champs d'horodatage RTP et de durée d'événement. Le nombre est écrit comme un entier. Si il est omis, la valeur par défaut est 8000 Hz.

 	2.4.1	Relations avec SDP
La transposition recommandée pour le type de paramètres facultatifs de SDP est donnée à la Section 3 de la [RFC3555]. Le paramètre de type de support "taux" pour le type de charge utile pour l'événement désigné suit cette convention : il est exprimé comme d'habitude comme le composant <taux d'horloge> de la ligne d'attribut a=rtpmap:.

Le paramètre de type de support "événements" diffère de la convention suggérée dans la RFC 3555 parce qu'il omet la chaîne "événements=" avant la liste des événements pris en charge.

a=fmtp:<format> <liste des valeurs>

La liste des valeurs a le format et la signification décrits ci-dessus.

Par exemple, si le format de charge utile utilise le numéro de type de charge utile 100, et si la mise en œuvre peut traiter des tonalités DTMF (événements de 0 à 15) et que les tonalités de numérotation et de sonnerie (en supposant comme exemple qu'elles ont été définies comme des événements avec les codes 66 et 70, respectivement) elles incluraient la description suivante dans leur message SDP :

m=audio 12346 RTP/AVP 100
a=rtpmap:100 événement de téléphonie/-8000
a=fmtp:100 0-15,66,70 

La définition de type de support d'échantillon suivante correspond à l'exemple SDP ci-dessus :

audio/t événement de téléphonie;événements="0-15,66,70";taux="8000"

 	2.5	Procédures
Ce paragraphe définit les procédures associées au type de charge utile d'événement désigné. Des procédures supplémentaires peuvent être spécifiées dans la documentation associée aux codes d'événement spécifiques

 	2.5.1	Procédures d'envoi
 	2.5.1.1	Négociation des charges utiles
Les événements sont généralement envoyés en combinaison avec ou en alternance avec d'autres types de charges utiles. La négociation de charge utile peut spécifier des événement et autres flux de charges utiles séparés, ou elle peut spécifier un flux combiné qui mélange d'autres types de charges utiles avec des événements utilisant des en-têtes de redondance de la [RFC2198]. La raison de l'utilisation d'un flux combiné peut être le débogage ou pour faciliter la transition entre des événements audio et généraux.

La négociation des charges utiles entre envoyeur et receveur est réalisée par des moyens hors bande, en utilisant par exemple SDP.

L'envoyeur DEVRAIT indiquer les événements qu'il prend en charge, en utilisant le paramètre facultatif "événements" associé au type de support événement-de-téléphonie. Si l'envoyeur reçoit un paramètre "événements" du receveur, il DOIT restreindre l'ensemble d'événements qu'il envoie à ceux figurant sur la liste des paramètres "événements" reçue. Pour la rétro compatibilité, si aucun paramètre "événements" n'est reçu, l'envoyeur DEVRAIT supposer la prise en charge des événements DTMF de 0 à 15, mais d'aucun autre.

Les événements PEUVENT être envoyés en combinaison avec de plus anciens événements en utilisant la redondance de la [RFC2198]. Le paragraphe 2.5.1.4 décrit comment cela peut être utilisé pour éviter des surcharges de paquet et d'en-tête RTP lors de la retransmission des rapports finaux d'événements. Le paragraphe 2.6 discute de l'utilisation de niveaux de redondance supplémentaires de la RFC 2198 pour augmenter la probabilité qu'au moins une copie du rapport de fin d'un événement atteigne le receveur. Le SDP suivant montre un exemple d'un tel usage, où l'audio G.711 apparaît dans un flux séparé, et le composant principal de la charge utile redondante est l'événement.

m=audio 12344 RTP/AVP 99
a=rtpmap:99 pcmu/8000
m=audio 12346 RTP/AVP 100 101
a=rtpmap:100 red/8000/1
a=fmtp:100 101/101/101
a=rtpmap:101 événement-de-téléphonie/8000
a=fmtp:101 0-15

Quand il est utilisé en accord avec le modèle d'offre-réponse de la [RFC3264], l'attribut SDP a=ptime: indique la période de mise en paquet à laquelle s'attend l'auteur de la description de session quand il reçoit les supports. Cette valeur n'a pas à être la même dans les deux directions. La période appropriée peut varier avec l'application, car des périodes de mise en paquet accrues impliquent des temps de réponse de bout en bout accrus dans les instances où une seule extrémité répond aux événements rapportés de l'autre.

La négociation des sessions d'événements de téléphonie en utilisant SDP PEUT spécifier de telles différences en séparant les événements correspondant aux différentes applications dans différents flux. Dans l'exemple ci-dessous, les événements 0 à 15 sont des événements DTMF, qui ont une très large tolérance au temps. Les événements 32 à 49 et 52 à 60 sont des événements relatifs à la transmission des données et sont sujets à des considérations de temps de réponse de bout en bout. Par suite, il leur est alloué une plus petite période de mise en paquet qu'aux événements DTMF.

m=audio 12344 RTP/AVP 99
a=rtpmap:99 événement-de-téléphonie/8000
a=fmtp:99 0-15
a=ptime:50
m=audio 12346 RTP/AVP 100
a=rtpmap:100 événement-de-téléphonie/8000
a=fmtp:100 32-49,52-60
a=ptime:30

Voir un exposé plus complet sur les périodes de mise en paquet au paragraphe 2.6.3.

 	2.5.1.2	Transmission des paquets d'événement
Les chiffres DTMF et autres événements de téléphonie désignés sont portés au titre du flux audio, et ils DOIVENT utiliser le même numéro de séquence et la même base d'horodatage que le canal audio régulier pour simplifier la génération des ondes audio à une passerelle.

Une source audio DEVRAIT commencer à transmettre les paquets d'événements aussitôt qu'elle reconnaît un événement et continuer d'envoyer des mises à jour jusqu'à la fin de l'événement. Les paquets de mise à jour DOIVENT avoir la même valeur d'horodatage RTP que le paquet initial pour l'événement, mais la durée DOIT être augmentée pour refléter la durée totale cumulée depuis le début de l'événement.

Le premier paquet d'un événement DOIT avoir le bit M établi. Le paquet final pour un événement DOIT avoir le bit E établi, mais établir le bit "E" PEUT être retardé jusqu'à ce que le paquet final soit retransmis (voir au paragraphe 2.5.1.4). Les paquets intermédiaires pour un événement NE DOIVENT PAS avoir le bit M ou E établi.

L'envoi d'un paquet avec le bit E établi est FACULTATIF si le paquet rapporte deux événements qui sont définis comme des états mutuellement exclusifs, ou si le paquet final pour un état est immédiatement suivi par un paquet qui rapporte un état mutuellement exclusif. (Pour les événements définis comme des états, l'apparition d'un état mutuellement exclusif implique la fin de l'état précédent.)

Une source a une grande latitude quant à la fréquence d'envoi de mises à jour d'événements. Un intervalle naturel est l'espacement entre les paquets audios non d'événement. (On rappelle qu'un seul paquet RTP peut contenir plusieurs trames audio pour les codecs fondés sur la trame et que l'intervalle de paquets peut varier durant une session.) Autrement, une source PEUT décider d'utiliser un espacement différent pour des mises à jour d'événement, avec une valeur de 50 ms RECOMMANDÉE.

Les informations de temps sont contenues dans l'horodatage RTP, ce qui permet une récupération précise des délais inter événements. Donc, en théorie, l'envoyeur n' pas besoin de conserver des intervalles de temps précis ou cohérents entre les paquets d'événements. Cependant, l'envoyeur DEVRAIT minimiser le besoin de mise en mémoire tampon à l'extrémité de réception en envoyant des rapports d'événement à des intervalles constants.

Les chiffres DTMF et autres événements de tonalités sont envoyés de façon incrémentaire pour éviter que le receveur attende l'achèvement de l'événement. Dans certains cas (par exemple, de protocoles de démarrage de session) attendre jusqu'à la fin d'une tonalité avant de le rapporter va causer l'échec de la session. Dans d'autres cas, cela va simplement causer des délais indésirables dans l'exécution à l'extrémité de réception.

Pour une meilleure robustesse, l'envoyeur DEVRAIT retransmettre périodiquement les événements "d'état".

 	2.5.1.3	Événements de longue durée
Si un événement persiste au delà de la durée maximum exprimable dans le champ Durée (0xFFFF), l'envoyeur DOIT envoyer un paquet rapportant cette durée maximum mais NE DOIT PAS établir le bit E dans ce paquet. L'envoyeur DOIT alors commencer à rapporter un nouveau "segment" avec l'horodatage RTP réglé à l'heure à laquelle le précédent segment s'est terminé et la durée réglée à la durée cumulée du nouveau segment. Le bit M du premier paquet rapportant le nouveau segment NE DOIT PAS être établi. L'envoyeur DOIT répéter cette procédure comme nécessaire jusqu'à ce que la fin de l'événement complet soit atteinte. Le paquet final pour l'événement complet DOIT avoir le bit E établi (soit sur la transmission initiale, soit sur une retransmission comme décrit ci-dessous.

 	2.5.1.3.1	Procédure exceptionnelle pour charges utiles combinées
Si des événements sont combinés comme une charge utile redondante avec un autre type de charge utile utilisant la redondance de la [RFC2198], la procédure ci-dessus DEVRA être appliquée, mais en utilisant une durée maximum qui assure que le décalage d'horodatage de la plus ancienne génération d'événements dans un paquet de la RFC 2198 n'excède jamais 0x3FFF. Si l'envoyeur utilise une période de mise en paquet constante, la durée maximum de segment peut être calculée à partir de la formule suivante :

durée maximum = 0x3FFF - (R-1)*(la période de mise en paquet en unités d'horodatage)

où R est le plus fort numéro de couche redondante consistant en charge utile d'événement.

La valeur du décalage d'horodatage d'en-tête de redondance de la RFC 2198 est seulement de 14 bits, à comparer aux 16  bits du champ de durée de charge utile d'événement. Comme avec les autres charges utiles l'horodatage RTP s'incrémente normalement pour chaque nouvel échantillon, la valeur de décalage d'horodatage devient un facteur limitant sur la durée des événements rapportés. La limite devient plus contraignante quand de plus anciennes générations d'événements sont aussi incluses dans la charge utile combinée.

 	2.5.1.4	Retransmission du paquet final
Le paquet final pour chaque événement et pour chaque segment DEVRAIT être envoyé un total de trois fois à l'intervalle utilisé par la source pour la mise à jour. Cela assure que la durée de l'événement ou segment peut être reconnu correctement même si une instance du dernier paquet est perdue.

Un envoyeur PEUT utiliser la [RFC2198] avec jusqu'à deux niveaux de redondance pour combiner les retransmissions avec les rapports de nouveaux événements, économisant donc sur les frais généraux d'en-têtes. Dans cette utilisation, la principale charge utile est le nouveau rapport d'événement, tandis que les premiers et (si nécessaire) seconds niveaux de redondance rapportent la première et la seconde retransmission des rapports finaux d'événement. Dans une session négociée pour permettre un tel usage, les paquets qui contiennent une charge utile de la RFC 2198 NE DEVRAIENT PAS être envoyés sauf quand les deux rapports principal et retransmis sont à inclure. Tous les autres paquets de la session DEVRAIENT contenir seulement la simple charge utile non redondante d'événement de téléphonie. Noter que la proportion attendue de simples paquets par rapport aux paquets redondants affecte l'ordre dans lequel ils devraient être spécifiés sur une ligne SDP m=.

Il y a peu d'objet à envoyer de façon redondante des rapports d'événement initiaux ou intérimaires parce que chaque paquet qui réussit décrit complètement l'événement (sauf pour les variations de volume qui ne sont normalement pas pertinentes).

Un envoyeur PEUT retarder l'établissement du bit E jusqu'à la retransmission du dernier paquet pour une tonalité, plutôt que d'établir le bit à sa première transmission. Cela évite d'avoir à attendre pour détecter si la tonalité s'est bien terminée. Une fois que l'envoyeur a établi le bit E pour un paquet, il DOIT continuer d'établir le bit E pour toute autre retransmission de ce paquet.

 	2.5.1.5	Empaquetage de multiples événements dans un paquet
Plusieurs événements désignés peuvent être emballés dans un seul paquet RTP si et seulement si les événements sont consécutifs et contigus, c'est-à-dire, surviennent sans chevauchement et sans pause entre eux, et si le dernier événement emballé dans un paquet survient assez rapidement pour éviter d'excessifs délais chez le receveur.

Cette approche est similaire à avoir plusieurs trames d'audio fondé sur la trame dans un paquet RTP.

La contrainte que les événements empaquetés ne se chevauchent pas implique que les événements désignés comme des états ne peuvent être suivis dans un paquet que par d'autres événements d'état qui leur sont mutuellement exclusifs. La contrainte elle même est nécessaire afin que l'instant de début de chaque événement puisse être calculé chez le receveur.

Dans un paquet qui contient des événements emballés de cette façon, l'horodatage RTP DOIT identifier le début du premier événement ou segment dans le paquet. Le bit M DOIT être établi si le paquet enregistre le début d'au moins un événement. (Cela sera vrai sauf quand le paquet porte la fin d'un segment et le début du prochain segment du même événement de longue durée.) Le bit E et la durée de chaque événement dans le paquet DOIVENT être établis en utilisant les mêmes règles que si cet événement était le seul contenu dans le paquet.

 	2.5.1.6	Numéro de séquence RTP
Le numéro de séquence RTP DOIT être incrémenté de un à chaque paquet RTP envoyé successivement. L'incrément s'applique aussi bien aux instances retransmises qu'aux instances initiales de rapports d'événement, pour permettre au receveur de détecter les paquets perdus pour les rapports de réception du protocole de contrôle de RTP (RTCP, RTP Control Protocol).

 	2.5.2	Procédures de réception
 	2.5.2.1	Indication des capacités du receveur en utilisant SDP
Les receveurs peuvent indiquer quels événements désignés ils peuvent traiter, par exemple, en utilisant le protocole de description de session [RFC4566]). Les descriptions SDP qui utilisent la charge utile d'événement DOIVENT contenir un attribut de format fmtp qui fait la liste des valeurs d'événement que le receveur peut traiter.

 	2.5.2.2	Exécution des événements de tonalité
Dans le scénario de passerelle, une passerelle de téléphonie Internet qui connecte un réseau vocal de paquets au RTPC recrée le DTMF ou les autres tonalités et les injecte dans le RTPC. Comme, par exemple, la reconnaissance des chiffres DTMF prend plusieurs dizaines de millisecondes, les premières millisecondes d'un chiffre vont arriver comme des paquets audio réguliers. Donc, un alignement précis du temps et de la puissance (volume) entre les échantillons audios et les événements est nécessaire pour éviter de générer des chiffres parasites chez le receveur. Le receveur peut aussi choisir de retarder l'exécution des tonalités d'un petit intervalle après la fin de l'exécution de l'audio précédant, pour s'assurer que l'équipement en aval peut discriminer de façon appropriée les tonalités.

Certaines mises en œuvre envoient les paquets d'événements et audio codés (par exemple, la PCMU ou le codec utilisé pour les signaux de parole) pour le même instant pour la durée de l'événement. Il est RECOMMANDÉ que les passerelles rendent seulement la charge utile événement-de-téléphonie une fois qu'elle est reçue, car l'audio peut contenir des tonalités parasites introduites par l'algorithme de compression audio. Cependant, il est prévu que ces tonalités supplémentaires ne devraient en général pas interférer avec la reconnaissance à l'extrémité distante.

Les mises en œuvre de receveur PEUVENT utiliser des algorithmes différents pour créer des tonalités, incluant les deux décrites ici. (Noter que toutes les mises en œuvre ont besoin de recréer une tonalité ; certaines peuvent seulement se soucier de la reconnaissance des événements.) Avec l'un ou l'autre algorithme, un receveur peut imposer un délai d'exécution pour assurer la robustesse contre la perte ou le retard des paquets. Le compromis entre délai d'exécution et les autres facteurs est discuté plus en détails au paragraphe 2.6.3.

Dans le premier algorithme, le receveur place simplement une tonalité de la durée donnée dans la mémoire tampon d'exécution audio à la localisation indiquée par l'horodatage. Lorsque des paquets supplémentaires sont reçus qui étendent la même tonalité, le signal dans la mémoire tampon d'exécution est étendu en conséquence. (Il faut faire attention au mixage du signal audio, c'est-à-dire, additionné, dans la mémoire tampon d'exécution plutôt que simplement copié.) Donc, si un paquet dans une tonalité qui dure plus longtemps que le temps d'inter arrivée de paquet est perdue et que le délai d'exécution est court, un trou peut se produire dans la tonalité.

Autrement, le receveur peut commencer une tonalité et l'exécutera jusqu'à ce qu'un des événements suivants se produise :
o	il reçoit un paquet avec le bit E établi ;
o	il reçoit la tonalité suivante, distinguée par une valeur différente d'horodatage (en notant que de nouveaux segments d'événements de longue durée apparaissent aussi avec une nouvelle valeur d'horodatage) ;
o	il reçoit un autre flux de supports non d'événement (en supposant qu'aucun n'a été reçu lorsque le flux d'événements était actif) ; ou
o	une certaine période de temps s'écoule.

Ceci est plus robuste contre la perte de paquet, mais peut étendre la tonalité au delà de sa durée d'origine si toutes les retransmissions du dernier paquet d'un événement sont perdues. Limiter la période d'extension de la tonalité est nécessaire pour éviter qu'une tonalité "reste pendante". Cet algorithme n'est pas une permission au envoyeur de régler le champ de durée à zéro ; il DOIT être réglé à la durée courante comme décrite, car c'est nécessaire pour créer des événements précis si le premier paquet d'événement est perdu, entre autres raisons.

Sans considération de l'algorithme utilisé, la tonalité NE DEVRAIT PAS être étendue de plus de trois temps d'intervalle d'arrivée de paquets. Une légère extension des durées de tonalités et un raccourcissement des pauses est généralement sans dommages.

Un receveur NE DEVRAIT PAS redémarrer une tonalité une fois l'exécution arrêtée. Il PEUT le faire si la tonalité est d'un type destiné à la consommation humaine ou est d'un de ceux pour lesquels une interruption ne va pas causer de confusion chez l'appareil receveur.

Si un receveur reçoit un paquet d'événement pour un événement qu'il n'exécute pas actuellement et si le paquet n'a pas le bit M établi, les paquets antérieurs pour cet événement ont évidemment été perdus. Cela peut être confirmé par des trous dans les numéros de séquence RTP. Le receveur PEUT déterminer sur la base de l'historique conservé et de l'horodatage et du code d'événement du paquet en cours qu'il correspond à un événement déjà exécuté et écoulé. Dans ce cas, les autres rapports sur l'événement DOIVENT être ignorés, comme indiqué au paragraphe précédent.

Si, par ailleurs, l'événement n'a pas été exécuté du tout, le receveur PEUT tenter d'exécuter l'événement sur la durée complète indiquée dans le rapport d'événement. Le comportement approprié va dépendre du type d'événement, et exige la prise en compte des relations de l'événement aux flux de supports audio et de si une durée d'événement correcte est essentielle pour le fonctionnement correct de la session de supports.

Un receveur NE DEVRAIT PAS s'appuyer sur un espacement particulier des paquets d'événement, mais DOIT plutôt utiliser les horodatages et les durées d'événement pour déterminer le moment et la durée de l'exécution.

Le receveur DOIT calculer la gigue pour les rapports de receveur RTCP sur la base de tous les paquets avec un certain horodatage. Note : la valeur de gigue devrait principalement être utilisée comme moyen de comparer la qualité de réception entre deux utilisateurs ou deux périodes de temps, et non comme une mesure absolue.

Si un volume de zéro est indiqué pour un événement pour lequel le champ Volume est défini, le receveur PEUT alors reconstruire le volume à partir du volume d'événement non audio ou PEUT utiliser la valeur nominale spécifiée par la Recommandation UIT-T ou d'autres documents qui définissent la tonalité. Cela assure la rétro compatibilité avec la [RFC2833], où le champ Volume était défini seulement pour les événements DTMF.

 	2.5.2.3.	Événements de longue durée
Si un rapport d'événement est reçu avec une durée égale à la durée maximum exprimable dans le champ Durée (0xFFFF) et si le bit E pour le rapport n'est pas établi, le rapport d'événement peut marquer la fin d'un segment généré conformément aux procédures du paragraphe 2.5.1.3. Si un autre rapport est reçu pour le même type d'événement, le receveur DOIT comparer l'horodatage RTP pour le nouvel événement avec la somme des horodatages RTP du précédent rapport plus la durée (0xFFFF). Le receveur utilise l'absence de trou entre les événements pour détecter qu'il reçoit un seul événement de longue durée.

La durée totale d'un événement de longue durée est (évidemment) la somme des durées des segments utilisés pour le rapporter. Cela est égal à la durée du segment final (comme indiqué dans le paquet final pour ce segment) plus 0xFFFF multiplié par le nombre de segments qui précédent le segment final.

 	2.5.2.3.1	Procédure exceptionnelle pour charges utiles combinées
Si des événements sont combinés comme une charge utile redondante avec un autre type de charge utile en utilisant la redondance de la [RFC2198], les segments sont dans ce cas générés à des intervalles de 0x3FFF ou moins, plutôt que 0xFFFF, comme exigé par les procédures du paragraphe 2.5.1.3.1. Si un receveur utilise les événements composants de la charge utile, la durée de l'événement peut être seulement un indicateur approximatif de la division en segments, mais le manque d'un bit E et l'adjacence de deux rapports avec le même code d'événement sont de forts indicateurs par eux-mêmes.

 	2.5.2.4	Événements multiples dans un paquet
Les procédures du paragraphe 2.5.1.5 exigent que si plusieurs événements sont rapportés dans le même paquet, ils soient contigus et non chevauchants. Par suite, il n'est pas strictement nécessaire que le receveur sache l'instant de début des événements qui suivent le premier afin de les exécuter – il a seulement besoin de respecter la durée rapportée pour chaque événement. Néanmoins, si la connaissance de l'instant de début d'un certain événement après le premier est requise, elle est égale à la somme de l'instant de début du précédant événement plus la durée du précédant événement.

 	2.5.2.5	États mous
Si la durée d'un événement d'état mou arrive à expiration, le receveur DEVRAIT considérer la valeur de l'état comme étant "inconnue" sauf si il est indiqué autrement dans la documentation de l'événement.

 	2.6	Encombrement et performances
La transmission de paquets à travers l'Internet est marquée par d'occasionnelles périodes d'encombrement durant de l'ordre de la seconde, pendant lesquelles le délai du réseau, la gigue, et la perte de paquet sont bien plus élevés qu'ils ne sont entre ces périodes. La référence [VOIP] caractérise ce phénomène. Les applications au bon comportement sont supposées, de préférence, réduire leurs demandes sur le réseau durant de telles périodes d'encombrement. Au moins, elles ne devraient pas augmenter leurs demandes. Ce paragraphe explore les performances des applications et les possibilités de bon comportement en présence d'encombrement.

 	2.6.1	Exigences de performances
Normalement, une mise en œuvre de charge utile événement-de-téléphonie va viser à limiter le taux de survenance de chacune des dégradations suivantes :
a.	un événement codé chez l'envoyeur échoue à être exécuté chez le receveur, soit parce que le rapport d'événement est perdu, soit parce qu'il arrive après qu'a commencé l'exécution d'un contenu ultérieur ;
b.	le début de l'exécution d'un événement chez le receveur est retardé par rapport aux autres événements ou autres supports fonctionnant sur la base du même horodatage ;
c.	la durée d'exécution d'un certain événement diffère de la durée correcte détectée chez l'envoyeur de plus d'une certaine quantité ;
d.	des trous se produisent dans l'exécution d'un certain événement ;
e.	 le délai de bout en bout pour le flux de supports excède une certaine valeur.

L'importance relative de ces contraintes varie selon les applications.

 	2.6.2	Mécanismes de fiabilité
Pour améliorer la fiabilité, tous les types de charge utile incluant des événements de téléphonie peuvent utiliser une mémoire tampon de gigue, c'est-à-dire, imposer un délai d'exécution, à l'extrémité de réception. Ce mécanisme vise la première des quatre exigences mentionnées ci-dessus, mais au détriment de la dernière.

Les procédures d'événement désignées fournissent deux mécanismes complémentaires de redondance pour traiter de paquets perdus :

a.	Mise à jour intra événement : Les événements qui durent plus qu'une période de mise en paquet (par exemple, 50 ms) sont mis à jour périodiquement, afin que le receveur puisse reconstruire l'événement et sa durée si il reçoit un des paquets de mise à jour, bien qu'avec retard. Durant un événement, le format de charge utile d'événement RTP fournit une mise à jour incrémentaire de l'événement. La résilience à l'erreur permise par ce mécanisme dépend de si le premier ou le second algorithme du paragraphe 2.5.2.2 est utilisé et du délai d'exécution chez le receveur. Par exemple, si le receveur utilise le premier algorithme et place seulement la durée courante du signal de tonalité dans la mémoire tampon d'exécution, pour un délai d'exécution de 120 ms et un intervalle de mise en paquet de 50 ms, deux paquets à la suite peuvent être perdus sans causer une fin prématurée de la tonalité générée.

b.	Répétition du dernier paquet d'événement : Comme décrit au paragraphe 2.5.1.4, le dernier rapport d'un événement est transmis un total de trois fois. Ce mécanisme ajoute de la robustesse au rapport de fin d'événement. Il peut être nécessaire d'étendre le niveau de redondance pour réaliser l'exigence a) (du paragraphe 2.6.1) dans un environnement de réseau spécifique. En prenant le taux de perte de 25 à 30 % durant les périodes d'encombrement illustrées comme typiques dans [VOIP], et en établissant un objectif qu'au moins 99 % de rapports de fin d'événement arrivent finalement au receveur dans ces conditions, un simple calcul de probabilités indique que chaque achèvement d'événement doit être rapporté quatre fois. C'est un niveau de redondance de plus qu'exigé par l'algorithme de base "Répéter le dernier paquet d'événement". Bien sûr, l'objectif est probablement une contrainte irréaliste ; il a été choisi pour faire un point. Lorsque le paragraphe 2.5.1.4 indique qu'il est approprié d'utiliser tle mécanisme de redondance audio de la [RFC2198] pour porter les retransmissions des rapports de fin d'événement, ce mécanisme PEUT aussi être utilisé pour étendre le nombre de retransmissions de rapports de fin. On fait cela en utilisant plus de deux niveaux de redondance quand nécessaire. L'utilisation de la RFC 2198 aide à atténuer la demande de bande passante supplémentaire qui serait imposée par la simple retransmission des paquets de fin d'événement plus de trois fois.

Ces deux mécanismes de redondance traitent clairement l'exigence a) du paragraphe précédent. Ils satisfont aussi l'exigence c) dans la mesure où le paquet redondant arrive avant que l'exécution de l'événement qu'ils rapportent n'expire. Ils ne servent à rien pour satisfaire les autres exigences, bien qu'il ne causent pas directement de défaillances par eux-mêmes dans le mesure où une grosse mémoire tampon de gigue augmente le délai de bout en bout.
L'algorithme d'exécution est un mécanisme supplémentaire pour satisfaire les exigences de performances. En particulier, en utilisant le second algorithme du paragraphe 2.5.2.2 on satisfait l'exigence d) du paragraphe précédent en empêchant les trous dans l'exécution, mais au prix potentiel d'une augmentation de durée (exigence c)).

Finalement, il y a une interaction entre la période de mise en paquet utilisée par un envoyeur, le délai d'exécution utilisé par le receveur, et la vulnérabilité d'un flux d'événements aux pertes de paquet. En supposant que les pertes de paquets sont indépendantes, un plus court intervalle de mise en paquets signifie que le receveur peut utiliser un plus petit délai d'exécution pour récupérer d'un nombre donné de pertes de paquet consécutives, à toute étape de l'exécution de l'événement. Cela améliore les délais de bout en bout dans les applications où cela importe.
En vue des compromis entre les différents mécanismes de fiabilité, la documentation des événements spécifiques DEVRAIT inclure une discussion des décisions de conception appropriées pour les applications de ces événements. Cette exigence est répétée dans la Section Considérations relatives à l'IANA.

 	2.6.3.	Ajustement à l'encombrement
Jusqu'à présent, la discussion a porté sur la satisfaction des exigences de performances. Cependant, il y a aussi la question de savoir si l'application des événements peut adapter l'encombrement au point de réduire les demandes sur les réseaux durant l'encombrement. En théorie cela peut être fait pour les événements en augmentant l'intervalle de mise en paquets, afin que moins de paquets soient envoyés par seconde. Cela doit être accompagné par un délai accru d'exécution à l'extrémité receveuse. La coordination entre les deux extrémités à cette fin est une question intéressante en elle-même. Cependant, si elle est faite, une telle action implique un trou ou une exécution étendue d'un événement quand l'intervalle de mise en paquets est étendu, ainsi qu'un délai accru de bout en bout durant toute la période de délai d'exécution accru.
L'avantage d'une telle mesure varie principalement selon la durée moyenne des événements traités. Dans le pire des cas, comme le montre le premier exemple, la réduction de l'usage de bande passante agrégée due à un intervalle accru de mise en paquets peut être assez modeste. Supposons que la durée moyenne d'événement soit de 3,33 ms (de bits V.21, par exemple). Supposons de plus que quatre transmissions au total soient requises pour qu'un certain rapport d'événement satisfasse l'objectif de perte. Le Tableau 1 montre l'impact de la variation des intervalles de mise en paquet sur le débit binaire agrégé du flux de supports.

Intervalle de mise en paquet (ms)	Paquets/s	Taille de paquet IP (bits)	Débit binaire IP total (bits/s)
50	20	2440	48800
33,3	30	1800	54000
25	40	1480	59200
20	50	1288	64400

Tableau 1 : Taux de données au niveau IP contre intervalle de mise en paquet 
(trois retransmissions, 3,33 ms par événement)

Comme on peut le voir, un doublement de l'intervalle (de 25 à 50 ms) fait tomber le débit binaire agrégé d'environ 20 % tandis que l'augmentation du délai de bout en bout est de 25 ms et cause un trou du même montant. (Étendre l'exécution d'un événement de tonalité V.21 spécifique est hors de question, donc le premier algorithme du paragraphe 2.5.2.2 doit être utilisé dans cette application.) La réduction du nombre de paquets par seconde avec de plus longues périodes de mise en paquet est contrée par l'augmentation de la taille de paquet due au nombre accru d'événements par paquet.

Pour les événements de plus longue durée, la réduction de bande passante est plus proportionnelle à l'augmentation de l'intervalle de mise en paquet. La perte de rapports de fin d'événement peut aussi être moins critique, de sorte que des niveaux de redondance inférieurs sont acceptables. Le Tableau 2 montre des données similaires à celles du Tableau 1, mais suppose des événements de 70 ms séparés par 50 ms de silence (comme dans une session de messagerie de texte idéale fondée sur DTMF) avec seulement deux retransmissions de base pour l'achèvement des événements.

Intervalle de mise en paquet (ms)	Paquets/s	Taille de paquet IP (bits)	Débit binaire IP total (bits/s)
50	20	448/520	10 040
33,3	30	448/520	14 280
25	40	448/520	18 520
20	50	448	22 400

Tableau 2 : taux de données au niveau IP contre intervalle de mise en paquet 
(deux retransmissions, 70 ms par événement, 50 ms entre événements)

Dans la troisième colonne du tableau, la taille de paquet est de 448 bits quand seulement un événement est rapporté et de 520 bits quand l'événement précédent est aussi inclus. Pas plus d'un niveau de redondance n'est nécessaire jusqu'à un intervalle de mise en paquet de 50 ms, bien qu'à ce point la plupart des paquets rapportent deux événements. Des intervalles plus longs exigent un second niveau de redondance au moins dans certains paquets.

 	3.	Spécification des codes d'événements pour les événements DTMF

Le présent document définit une classe d'événements désignés : les tonalités DTMF.

 	3.1	Applications DTMF
La signalisation DTMF [Q.23] est normalement générée par un appareil téléphonique ou éventuellement par un commutateur privé (PBX, Private Branch telephone eXchange). Les chiffres DTMF peuvent être consommés par des entités comme des passerelles ou des serveurs d'application dans le réseau IP, ou par des entités comme des commutateurs téléphoniques ou des répondeurs vocaux interactifs (IVR, interactive voice response) dans le réseau de commutation de circuits.

Les événements DTMF prennent en charge deux applications possibles à l'extrémité d'envoi :

1.	La passerelle de téléphonie Internet détecte le DTMF sur les circuits entrants et envoie la charge utile RTP décrite ici au lieu de paquets audio réguliers. La passerelle a probablement les processeurs et algorithmes de signal numérique nécessaires, car elle a souvent besoin de détecter le DTMF, par exemple, pour la numérotation en deux étapes. Que la passerelle détecte les tonalités libère le système d'extrémité Internet receveur de la charge de ce travail et aussi évite d'avoir des codecs à faible débit binaire comme [G.723.1] qui rendent les tonalités DTMF inintelligibles.

2.	Un système d'extrémité Internet comme un "téléphone Internet" peut émuler la fonction DTMF sans être lui-même concerné par la génération de paires de tonalités précises et sans imposer la charge de la reconnaissance des tonalités chez le receveur.

Une distinction similaire a lieu à l'extrémité receveuse.

1.	Dans le scénario de passerelle, une passerelle de téléphonie Internet qui connecte un réseau de paquets vocaux au RTPC recrée les tonalités DTMF ou autres événements de téléphonie et les injecte dans le RTPC.

2.	Dans le scénario de système d'extrémité, les événements DTMF sont consommés par l'entité receveuse elle-même.

Dans les applications les plus courantes, les tonalités DTMF sont envoyées dans une seule direction, normalement depuis l'extrémité appelante. L'appareil consommateur est très généralement un IVR. Le DTMF peut alterner avec la voix provenant de l'une et l'autre extrémité. Dans la plupart des cas, la seule contrainte sur la durée de la tonalité est qu'elle excède une valeur minimum. Cependant, dans certains cas, une tonalité de longue durée (de plus de 1 à 2 secondes) a une signification particulière.

La Recommandation UIT-T [Q.24], Tableau A-1, indique que l'équipement traditionnel de commutation dans les pays de l'étude attendent une durée minimum de signal reconnaissable de 40 ms, une pause minimum entre signaux de 40 ms, et un taux maximum de signaux de 8 à 10 chiffres par seconde selon les pays. Les signaux DTMF générés par l'homme sont généralement plus longs avec de plus longues pauses entre eux.

Les tonalités DTMF peuvent aussi être utilisées pour le texte téléphoné. Cette application est documentée dans la Recommandation UIT-T V.18 [V.18] Annexe B. Dans ce cas, le DTMF est envoyé alternativement de l'une ou l'autre extrémité (mode semi duplex) avec un temps de retour minimum de 300 ms. La seule contrainte sur les durées de tonalités dans cette application est qu'elles, et les pauses entre elles, doivent excéder les valeurs minimales spécifiées. Il est RECOMMANDÉ qu'une passerelle à l'extrémité d'envoi soit capable de détecter les signaux DTMF comme spécifiés par l'Annexe B de V.18 (tonalités et pauses  40 ms) mais devrait envoyer des durées d'événement correspondant à celles d'un envoyeur DTMF de V.18 (tonalités  70 ms, pauses  50 ms). Cela peut occasionnellement impliquer un certain degré de mise en mémoire tampon des événements sortants, mais si le terminal source se conforme à l'Annexe B de V.18, cela ne devrait pas poser de problème.

Comme des augmentations mineures de la durée de tonalité sont sans dommage pour toutes les applications de DTMF, mais qu'une interruption involontaire de l'exécution d'un chiffre DTMF peut créer une certaine confusion chez le point d'extrémité receveur en créant l'apparition de chiffres supplémentaires, les applications receveuses qui reconvertissent des événements DTMF en tonalités DEVRAIENT utiliser le second algorithme d'exécution plutôt que le premier du paragraphe  2.5.2.2. Cela donne de la robustesse contre la perte de paquet ou l'encombrement.

 	3.2	Événements DTMF
Le Tableau 3 montre les codes d'événement relatifs à DTMF dans le format de charge utile événement-de-téléphonie. Les chiffres DTMF 0 à 9 ainsi que * et # sont couramment pris en charge. Les chiffres DTMF A à D sont moins fréquemment rencontrés, normalement dans des applications spéciales comme les réseaux militaires.

Événement	Code	Type	Volume ?
0 à 9	0 à 9	tonalité	oui
*	10	tonalité	oui
#	11	tonalité	oui
A à D	12 à 15	tonalité	oui

Tableau 3 : Événements DTMF désignés

 	3.3	Considérations d'encombrement
Les considérations clés pour la livraison d'événements DTMF sont la fiabilité et l'évitement de coupures involontaires de l'exécution d'une tonalité donnée. Le délai d'aller-retour de bout en bout n'est pas une considération majeure sauf dans le cas particulier de tonalités DTMF utilisées pour le texte téléphoné. En supposant que, comme recommandé au paragraphe  3.1, on utilise le second algorithme d'exécution du paragraphe 2.5.2.2, une augmentation temporaire de l'intervalle de mise en paquet jusqu'à 100 ms ou le double de l'intervalle normal, selon ce qui est le moindre, devrait être sans dommages.

 	4.	Format de charge utile RTP pour tonalités téléphoniques
 	4.1	Introduction
Comme solution de remplacement de la description des tonalités et des événements par leur nom, comme décrit à la Section  2, il est parfois préférable de les décrire par leur propriétés de forme d'onde. En particulier, la reconnaissance est plus rapide que de désigner les signaux car cela ne dépend pas de la reconnaissance des durées ou des pauses.

Il n'y a pas une seule norme internationale pour les tonalités téléphoniques comme la tonalité d'appel, les tonalités de sonnerie, d'occupation, d'encombrement, d'annonces spéciales, ou autres tonalités particulières comme la reconnaissance d'une cabine téléphonique, d'appel en attente, ou tonalité d'enregistrement. Cependant, la Recommandation UIT-T E.180 [Q.35] note que dans tous les pays, ces tonalités partagent un certain nombre de caractéristiques :

o	Les tonalités téléphoniques consistent soit en une seule tonalité, en l'addition de deux ou trois tonalités ou en la modulation de deux tonalités. (Presque toutes les tonalités utilisent deux fréquences ; seule la "tonalité de numérotation spéciale" hongroise en a trois.) Les tonalités qui sont mixtes ont la même amplitude et ne diminuent pas.

o	Les tonalités dans la bande pour les événements de téléphonie sont dans la gamme de 25 Hz (tonalité de sonnerie en Angola) à 2600 Hz (la tonalité utilisée pour la signalisation de ligne dans le SS n° 5 et R1). La gamme de fréquence de téléphone dans la bande est limitée à 3400 Hz. R2 définit une tonalité de 3825 Hz hors bande pour la signalisation de ligne sur les circuits analogiques. (Le piano a une gamme de 27,5 à 4186 Hz.)

o	La modulation des fréquences va de 15 (tonalité ANSam) à 480 Hz (Jamaïque). Des fréquences non entières sont utilisées seulement pour les fréquences de 16 2/3 et 33 1/3 Hz.

o	Les tonalités qui sont non continues ont des durées de moins de quatre secondes.

o	La Recommandation UIT-T E.180 [Q.35] note que les différentes compagnies de téléphone exigent une précision de tonalité entre 0,5 et 1,5 %. La Recommandation suggère une tolérance de fréquence de 1 %.

 	4.2	Exemples de signaux de tonalité téléphonique courants
Comme aide à la mise en œuvre, le Tableau 4 résume les tonalités les plus courantes.
Les lignes marquées "UIT ..." se réfèrent à la Recommandation UIT-T E.180 [Q.35]. Dans ces lignes, les durées avec et sans sont les gammes suggérées dans lesquelles chaque norme locale va établir des valeurs spécifiques. Le symbole "+" dans le tableau indique l'addition des tonalités, sans modulation, tandis que "*" indique la modulation d'amplitude.

Nom de la tonalité	Fréquence	Durée avec (s)	Durée sans (s)
CNG	1100	0,5	3,0
V.25 CT	1300	0,5	2,0
CED	2100	3,3	--
ANS	2100	3,3	--
ANSam	2100*15	3,3	--
V.21 bit	980 ou 1180 ou 1650 ou 1850	0,00333	--
tonalité de numérotation UIT	425	–	--
tonalité de numérotation U.S	350+440	–	--
tonalité d'appel UIT	425	0,67-1,5	3-5
tonalité d'appel U.S	440+480	2,0	4,0
tonalité d'occupation UIT	425	0,1-0,6	0,1-0,7
tonalité d'appel U.S	480+620	0,5	0,5
tonalité d'encombrement UIT	425	0,1-0,6	0,1-0,7
tonalité d'encombrement U.S	480+620	0,25	0,25

Tableau 4 : Exemples de tonalités téléphoniques

 	4.3	Utilisation des champs d'en-tête RTP
 	4.3.1	Horodatage
L'horodatage RTP reflète le point de mesure pour le paquet en cours. la durée d'événement décrite au paragraphe 4.3.3 commence à cet instant.

 	4.3.2	Bit Marqueur
Le type de charge utile Tonalité utilise le bit marqueur pour distinguer le premier paquet RTP rapportant une certaine instance d'une tonalité à partir de paquets successifs pour cette tonalité. Le bit marqueur DEVRAIT être réglé à 1 pour le premier paquet, et à 0 pour tous les paquets successifs relatifs à la même tonalité.

 	4.3.3	Format de charge utile
Sur la base des caractéristiques décrites ci-dessus, le présent document définit un format de charge utile RTP appelé "tonalité" qui peut représenter des tonalités consistant en une ou plusieurs fréquences. (Le type de support correspondant est "audio/tonalité".) Le taux d'horodatage par défaut est 8000 Hz, mais d'autres taux peuvent être définis. Noter que le taux d'horodatage n'affecte pas l'interprétation de la fréquence, juste les durées.

En accord avec les pratiques courantes, ce format de charge utile n'a pas de numéro de type de charge utile statique, mais utilise un numéro de type de charge utile RTP établi de façon dynamique et hors bande.

La Figure 2 montre le format de charge utile.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Modulation   |T|  Volume   |          Durée                |
+---------------+-+-+-----------+---------------+---------------+
|R R R R|       Fréquence       |R R R R|       Fréquence       |
+-------+-------+---------------+-------+-------+---------------+
|R R R R|       Fréquence       |R R R R|       Fréquence       |
+-------+-------+---------------+-------+-------+---------------+
           ......
+---------------+---------------+-------+-------+---------------+
|R R R R|       Fréquence       |R R R R|      Fréquence        |
+-------+-------+---------------+-------+-------+---------------+

Figure 2 : Format de charge utile pour les tonalités

La charge utile contient le champs suivants :

Modulation : fréquence de modulation, en Hz. Le champ est un entier non signé de 9 bits, permettant des fréquences de modulation jusqu'à 511 Hz. Si il n'y a pas de modulation, ce champ a une valeur de zéro. Noter que l'amplitude de modulation n'est pas indiquée dans la charge utile et doit être déterminée par des moyens hors bande.

T : si le bit T est établi (à un) la fréquence de modulation est à diviser par trois. Autrement, la fréquence de modulation est prise comme elle est. Ce bit permet des fréquences précises à 1/3 Hz, car des fréquences de modulation comme 16  2/3  Hz sont utilisées en pratique.

Volume : niveau de puissance de la tonalité, exprimée en dBm0 après élimination du signe, avec une gamme de 0 à –  63  dBm0. (Note : une gamme de niveaux préférée pour les générateurs de tonalités numériques est de - 8 dBm0 à -  3  dBm0.)

Durée : durée de la tonalité, mesurée en unités d'horodatage et présentée dans l'ordre des octets du réseau. La tonalité commence à l'instant identifié par l'horodatage RTP et dure la valeur de la durée. La valeur de zéro n'est pas permise, et les tonalités avec une telle durée DEVRAIENT être ignorées. La définition de la durée correspond à celle des codecs fondés sur l'échantillon, où l'horodatage représente le point d'échantillonnage pour le premier échantillon.

Fréquence : fréquences des tonalités à ajouter, mesurées en Hz et représentées comme un entier de 12 bits non signé. La taille du champ est suffisante pour représenter des fréquences jusqu'à 4095 Hz, ce qui excède la gamme des systèmes téléphoniques. Une valeur de zéro indique un silence. Une seule tonalité peut contenir tout nombre de fréquences. Si aucune fréquence n'est spécifiée, le paquet rapporte une période de silence.

R : ce champ est réservé pour une utilisation future. L'envoyeur DOIT le régler à zéro, et le receveur DOIT l'ignorer.

 	4.3.4	Paramètres facultatifs de type de support
Le paramètre "taux" décrit le taux d'échantillonnage, en Hertz. Le nombre est écrit comme un entier. Si il est omis, la valeur par défaut est 8000 Hz.

 	4.4	Procédures
Ce paragraphe définit les procédures associées au type de charge utile de tonalité.

 	4.4.1	Procédures d'envoi
L'envoyeur PEUT envoyer un paquet initial de tonalités aussitôt qu'une tonalité est reconnue, ou PEUT attendre jusqu'à l'écoulement d'une période de mise en paquet pré négociée. Le premier paquet RTP pour une tonalité DEVRAIT avoir le bit marqueur réglé à 1.

Dans le cas de tonalités de longue durée, l'envoyeur DEVRAIT générer plusieurs paquets RTP pour la même instance de tonalité. L'horodatage RTP DOIT être mis à jour pour chaque paquet généré (à la différence, par exemple, de l'horodatage pour les paquets qui portent des événements de téléphonie). Les paquets suivants pour la même tonalité DEVRAIENT avoir le bit marqueur réglé à 0, et l'horodatage RTP dans chaque paquet suivant DOIT être égal à la somme de l'horodatage et de la durée dans le paquet précédant.

Un paquet RTP final PEUT être généré aussitôt que la fin de la tonalité est détectée, sans attendre l'écoulement de la dernière période de mise en paquet.

La charge utile événement-de-téléphonie décrit à la Section 2 est par nature redondante, en ce que les derniers paquets pour le même événement portent tous l'historique antérieur de l'événement sauf les variations de volume. À l'opposé, chaque paquet pour le type de charge utile de la tonalité est autonome ; un paquet perdu signifie un trou dans les informations disponibles à l'extrémité de réception. Donc, pour une fiabilité accrue, l'envoyeur DEVRAIT combiner les nouveaux et anciens rapports de tonalité dans le même paquet RTP en utilisant la redondance audio de la [RFC2198].

 	4.4.2	Procédures de réception
Les mises en œuvre receveuses exécutent les tonalités telles qu'elles sont reçues, normalement avec un délai d'exécution  pour permettre de récupérer des paquets perdus. Lors de l'exécution de rapports de tonalité successifs pour la même tonalité (le bit marqueur est zéro, l'horodatage RTP est contigu avec celui du paquet RTP précédent, et le contenu de charge utile est identique) la mise en œuvre receveuse DEVRAIT continuer la tonalité sans changement ni coupure.

 	4.4.3	Traitement de l'encombrement
Si l'envoyeur détermine que des paquets sont perdus à cause de l'encombrement (par exemple, grâce aux rapports de receveur RTCP) il DEVRAIT augmenter l'intervalle de mise en paquet pour les rapports initiaux et intérimaires de tonalité afin de réduire le volume de trafic chez le receveur. Le degré auquel cela est possible sans causer de conséquences dommageables à l'extrémité de réception dépend du délai d'exécution utilisé à cette extrémité et de l'application spécifique associée aux tonalités. L'intervalle maximum de mise en paquet et l'augmentation maximum de l'intervalle de mise en paquet à tout moment sont donc tous deux une affaire de configuration ou de négociation hors bande.

 	5.	Exemples

Considérons une séquence de numérotation DTMF, où l'utilisateur compose les chiffres "911" et qu'une passerelle envoyeuse les détecte. Le premier chiffre fait 200 ms (1600 unités d'horodatage) et commence à l'instant 0 ; le second chiffre dure 250 ms (2000 unités d'horodatage) et commence à l'instant 880 ms (7040 unités d'horodatage) ; le troisième chiffre est composé à l'instant 1,4 s (11 200 unités d'horodatage) et dure 220 ms (1760 unités d'horodatage). La durée de la trame est de 50 ms.

Le Tableau 5 montre la séquence complète d'événements en supposant que seul le type de charge utile événement-de-téléphonie est rapporté. Pour simplifier, l'horodatage est supposé commencer à 0, le numéro de séquence RTP à 1, et les réglages de volume sont omis.

Temps (ms)	Événement	Bit M	Horodatage	N° séq	Code évmnt	Durée	Bit E
0	Début de "9"						
5	Paquet RTP 1 envoyé	"1"	0	1	9	400	"0"
100	Paquet RTP 2 envoyé	"0"	0	2	9	800	"0"
150	Paquet RTP 3 envoyé	"0"	0	3	9	1200	"0"
200	Paquet RTP 4 envoyé	"0"	0	4	9	1600	"0"
200	Fin de "9" 						
250	1ère retrans. paquet RTP 4	"0"	0	5	9	1600	"1"
300	2ème retrans. paquet RTP 4	"0"	0	6	9	1600	"1"
880	Premier "1"débute						
930	Paquet RTP 5 envoyé	"1"	7040	7	1	400	"0"
…	…	…	…	…	…	…	... 
1130	Paquet RTP 9 envoyé	"0"	7040	11	1	2000	"0"
1130	Fin de premier "1"						
1180	1ère retrans. paquet RTP 9	"0"	7040	12	1	2000	"1"
1230	2ème retrans. paquet RTP 9	"0"	7040	13	1	2000	"1"
1400	Second "1" débute						
1450	Paquet RTP 10 envoyé	"1"	11200	14	1	400	"0"
…	…	…	…	…	…	…	...
1620	Second "1" se termine						
1650	Paquet RTP 14 envoyé	"0"	11200	18	1	1760	"1"
1700	1ère retrans. paquet RTP 9	"0"	11200	19	1	1760	"1"
1750	2ème retrans. paquet RTP 9	"0"	11200	20	1	1760	"1"

Tableau 5 : Exemple de rapport d'événement

Le Tableau 6 montre la même séquence en supposant que seul le type de charge utile de tonalité est rapporté. Cela paraît un peu différent. Pour simplifier, l'horodatage est supposé commencer à 0, le numéro de séquence à 1. Le volume, le bit T, et la fréquence de modulation sont omis. Ces deux derniers sont toujours 0.

Temps(ms)	Événement	Bit M	Horodatage	N° de séq.	Durée	Fréq 1 (Hz)	Fréq 2 (Hz) 
0	Début de "9"
50	Paquet RTP 1 envoyé	"1"	0	1	400	852	1477
100	Paquet RTP 2 envoyé	 "0"	400	2	400	852	1477
…	…	…	…	…	…	…	...
200	Paquet RTP 4 envoyé	"0"	1200	4	400	852	1477
200	Fin de "9"
880	Début du premier "1"
930	Paquet RTP 5 envoyé	"1"	7040	5	400	697	1209
980	Paquet RTP 6 envoyé	"0"	7440	6	400	697	1209
…	…	…	…	…	…	…	...
1130	Fin du premier "1"
1400	Début du second "1"
1450	Paquet RTP 10 envoyé	"1" 	11200	10	400	697	1209
…	…	…	…	…	…	…	...
1620	Fin du second "1"
1650	Paquet RTP 14 envoyé	"0"	12800	14	160	697	1209

Tableau 6 : Exemple de rapport de tonalité

Considérons maintenant une charge utile combinée, où la charge utile de tonalité est le principal type de charge utile et la charge utile événement est traitée comme un codage redondant (un niveau de redondance). Parce que la charge utile principale est une tonalité, les règles de charge utile de tonalité déterminent le réglage des champs d'en-tête RTP. Cela signifie que l'horodatage RTP avance toujours. En corollaire, le décalage d'horodatage pour la charge utile d'événements dans l'en-tête de la RFC 2198 augmente du même montant.

Un problème qui doit être considéré dans une charge utile combinée est comment traiter les retransmissions de rapports d'événement finaux. La spécification de charge utile de tonalité ne recommande pas les retransmissions des paquets finaux, de sorte qu'il est n'est pas clair ce qu'on doit mettre dans les champs de charge utile principale du paquet combiné. Pour faire simple, il est suggéré que les paquets retransmis copient les champs relatifs à la charge utile principale (incluant l'horodatage RTP) provenant du paquet original. Le même principe peut être appliqué si le paquet comporte plusieurs niveaux de redondance de charge utile d'événement.

Les figures ci-dessous illustrent toutes "le paquet RTP 14" dans les tableaux ci-dessus. La Figure 3 montre un événement seulement de charge utile, correspondant au Tableau 5. La Figure 4 montre une charge utile seulement de tonalité, correspondant au Tableau 6. Finalement, la Figure 5 montre une charge utile combinée, avec des tonalités principales et des événements comme une seule couche de redondance. Noter que la charge utile combinée a les numéros de séquence RTP montrés au Tableau 5, parce que la séquence transmise inclut les paquets retransmis.

La Figure 3 suppose que la spécification SDP suivante a été utilisée. Cette description de session fournit des flux séparés d'audio et d'événements [G.729]. Les paquets rapportés dans le flux G.729 ne sont pas considérés ici.

m=audio 12344 RTP/AVP 99
a=rtpmap:99 G729/8000
a=ptime:20
m=audio 12346 RTP/AVP 100
a=rtpmap:100 événement-de-téléphonie /8000
a=fmtp:100 0-15
a=ptime:50

 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   |M|     PT      |    Numéro de séquence         |
| 2 |0|0|   0   |0|    100      |            18                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+---------------+
|                           Horodatage                          |
|                             11200                             |
+---------------+---------------+---------------+---------------+
|         Identifiant de source de synchronisation (SSRC)       |
|                            0x5234a8                           |
+---------------+-+-+-----------+---------------+---------------+
|     Événement |E R| Volume    |          Durée                |
|       1       |1 0|    20     |             1760              |
+---------------+-+-+-----------+---------------+---------------+

Figure 3 : Exemple du paquet RTP pour une charge utile Événement

La Figure 4 suppose qu'a été utilisée une spécification SDP similaire à celle du cas précédent.

m=audio 12344 RTP/AVP 99
a=rtpmap:99 G729/8000
a=ptime:20
m=audio 12346 RTP/AVP 101
a=rtpmap:101 tone/8000
a=ptime:50

 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   |M|     PT      |       Numéro de séquence      |
| 2 |0|0|   0   |0|    101      |             14                |
+-+-+-+-+-------+-+-------------+---------------+---------------+
|                           Horodatage                          |
|                             12800                             |
+---------------+---------------+---------------+---------------+
|         Identifiant de source de synchronisation (SSRC)       |
|                            0x5234a8                           |
+---------------+-+-+-----------+---------------+---------------+
|    Modulation   |T|  Volume   |          Durée                |
|        0        |0|    20     |             160               |
+-------+-------+-+-+-----------+-------+-------+---------------+
|R R R R|       Fréquence       |R R R R|       Fréquence       |
|0 0 0 0|          697          |0 0 0 0|         1209          |
+-------+-------+---------------+-------+-------+---------------+

Figure 4 : Exemple de paquet RTP pour une charge utile Tonalité

La Figure 5, pour la charge utile combinée, suppose la description de session SDP suivante :

m=audio 12344 RTP/AVP 99
a=rtpmap:99 G729/8000
a=ptime:20
m=audio 12346 RTP/AVP 102 101 100
a=rtpmap:102 red/8000/1
a=fmtp:102 101/100
a=rtpmap:101 tone/8000
a=rtpmap:100 événement-de-téléphonie /8000
a=fmtp:100 0-15
a=ptime:50

Pour faciliter la présentation, la Figure 5 présente les charges utiles réelles comme si elles commençaient sur des limites de 32 bits. Dans le paquet réel, elles suivent immédiatement après la fin de l'en-tête de la RFC 2198, et elles sont donc déplacées d'un octet dans les mots successifs.

 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   |M|     PT      |       Numéro de séquence      |
| 2 |0|0|   0   |0|    102      |             18                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Horodatage                          |
|                             12800                             |
+---------------+---------------+---------------+---------------+
|         Identifiant de source de synchronisation (SSRC)       |
|                            0x5234a8                           |
+-+-------------+---------------+-----------+---+---------------+
|F|   Bloc PT   | Décalage d'horodatage     | Longueur de bloc  |
|1|      100    |       1600                |        4          |
+-+-------------+---------------+-----------+---+---------------+
|F|   Bloc PT   | Début de charge utile d'événement             /
|0|      101    |                                               \
+-+-------------+---------------+-----------+---+---------------+

Charge utile Événement

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Événement   |E R| Volume    |          Durée                |
|       1       |1 0|    20     |             1760              |
+---------------+---+-----------+---------------+---------------+

Charge utile Tonalité

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Modulation   |T|  Volume   |          Durée                |
|        0        |0|    20     |             160               |
+-------+-------+-+-+-----------+-------+-------+---------------+
|R R R R|       Fréquence       |R R R R|       Fréquence       |
|0 0 0 0|          697          |0 0 0 0|         1209          |
+-------+-------+---------------+-------+-------+---------------+

Figure 5 : Exemple de paquet RTP pour des charges utiles combinées de tonalité et d'événement

 	6.	Considérations de sécurité

Les paquets RTP qui utilisent les formats de charge utile définis dans la présente spécification sont soumis aux considérations de sécurité exposées dans la spécification RTP [RFC3550], et tout profil RTP approprié (par exemple, la [RFC3351]). La discussion de la RFC 3550 se concentre sur les exigences pour la confidentialité. Des considérations de sécurité supplémentaires relatives à la mise en œuvre sont décrites dans la [RFC2198].

La charge utile événement-de-téléphonie définie dans la présente spécification est très compressée. Un changement de la valeur d'un seul bit peut résulter en un changement majeur de la signification décodée chez le receveur. Donc, l'intégrité du message DOIT être assurée pour le type de charge utile événement-de-téléphonie.

Pour satisfaire le besoin de protection de la confidentialité et de l'intégrité, les mises en œuvre conformes DEVRAIENT utiliser le protocole de transport sûr en temps réel (SRTP, Secure Real-time Transport Protocol) [RFC3711].

Noter que la méthode appropriée de distribution de clés pour SRTP peut varier avec l'application. Dans certains déploiements, il peut être préférable d'utiliser d'autres moyens pour assurer une protection équivalente à celle fournie par SRTP.

Pourvu que la conception de passerelle comporte une génération de tonalités robuste, à faible redondance, ce type de charge utile ne présente aucune non uniformité significative de complexité de calcul du côté du receveur qui cause au traitement de paquet une potentielle menace de déni de service.

 	7.	Considérations relatives à l'IANA

Le présent document met à jour les descriptions de deux formats de charge utile RTP, "événement-de-téléphonie" et "tonalité"et les types de supports Internet associés, audio/événement-de-téléphonie et audio/tonalité. Il documente aussi les codes d'événement pour les événements de tonalités DTMF.

Dans le type audio/événement-de-téléphonie, les événements DOIVENT être enregistrés par l'IANA. Les enregistrements sont soumis à la politique de "Spécification exigée" et "Revue par expert" définies dans la [RFC2434]. L'expert désigné par l'IETF doit s'assurer que :
a.	 la signification et l'application des événements proposés sont clairement documentées ;
b.	les événements ne peuvent pas être représentés par les codes d'événement existants, éventuellement avec des modification mineures des définitions d'événement ;
c.	le nombre des événements est le minimum nécessaire pour satisfaire l'objet de leur application.

L'expert est de plus responsable de la fourniture de conseils sur l'allocation des codes d'événement pour les événements proposés. Précisément, l'expert doit indiquer si l'événement apparaît comme étant le même qu'un défini dans la RFC 2833 mais non spécifié dans un nouveau document. Dans ce cas, le code d'événement spécifié dans la RFC 2833 pour cet événement DEVRAIT être alloué à l'événement proposé. Autrement, les codes d'événement DOIVENT être alloués à partir de l'ensemble de codes d'événement disponibles dont la liste figure ci-dessous. Si cet ensemble est épuisé, le critère d'allocation à partir de l'ensemble réservé de codes d'événement est d'abord d'allouer ceux qui paraissent avoir la plus faible probabilité d'être restitués dans leur signification de la RFC 2833 dans une nouvelle spécification.

La documentation pour chaque événement DOIT indiquer si l'événement est un état, une tonalité, ou un autre type d'événement (par exemple, un événement électrique hors bande comme un décroché ou une indication qui ne va pas être elle-même exécutée comme une tonalité à l'extrémité de réception). Pour les événements de tonalités, la documentation DOIT indiquer si le champ Volume est applicable ou doit être réglé à 0.

En vue des compromis entre les différents mécanismes de fiabilité discutés au paragraphe 2.6, la documentation d'événements spécifiques DEVRAIT inclure une discussion des décisions de conception appropriées pour les applications de ces événements.

Les codes d'événement légaux sont dans la gamme de 0 à 255. Le contenu du registre initial est montré au Tableau 7, et consiste en seize événements définis à la Section 3 de ce document. Les codes restants ont la disposition suivante :
o	les codes 17 à 22, 50 à 51, 90 à 95, 113 à 120, 169, et 206 à 255 sont disponibles pour allocation ;
o	les codes 23 à 40, 49, et 52 à 63 sont réservés pour les événements définis dans la [RFC4734] ;
o	 les codes 121 à 137 et 174 à 205 sont réservés pour les événements définis dans la [RFC5244] ;
o	les codes 16, 41 à 48, 64 à 88, 96 à 112, 138 à 168, et 170 à 173 sont réservés dans la première instance des spécifications restituant les événements correspondants de la RFC 2833, et en seconde instance pour allocation générale après que tous les autres codes ont été alloués.

Code d'événement	Nom d'événement	Référence
 0	chiffre DTMF "0"	RFC 4733
 1	chiffre DTMF "1"	RFC 4733
 2	chiffre DTMF "2"	RFC 4733
 3	chiffre DTMF "3"	RFC 4733
 4	chiffre DTMF "4"	RFC 4733
 5	chiffre DTMF "5"	RFC 4733
 6	chiffre DTMF "6"	RFC 4733
 7	chiffre DTMF "7"	RFC 4733
 8	chiffre DTMF "8"	RFC 4733
 9	chiffre DTMF "9"	RFC 4733
10	chiffre DTMF "*"	RFC 4733
11	chiffre DTMF "#"	RFC 4733
12	chiffre DTMF "A"	RFC 4733
13	chiffre DTMF "B"	RFC 4733
14	chiffre DTMF "C"	RFC 4733
15	chiffre DTMF "D"	RFC 4733

Tableau 7 : Registre de codes d'événement audio/événement-de-téléphonie

 	7.1	Enregistrements de type de support
 	7.1.1	Enregistrement des types de support événement audio/téléphonique
Cet enregistrement est fait en accord avec les [RFC3555] et [RFC4288].

Nom de type : audio
Nom de sous type : événement-de-téléphonie 
Paramètres exigés : aucun.
Paramètres facultatifs : Le paramètre "événements" fait la liste des événements pris en charge par la mise en œuvre. Les événements sont énumérés comme un ou plusieurs éléments séparés par une virgule. Chaque élément peut être soit un seul entier fournissant la valeur d'un code d'événement soit un entier suivi par un tiret et un plus grand entier, présentant une gamme de valeurs consécutives de codes d'événement. La liste n'a pas à être triée. Aucune espace n'est permise dans l'argument. L'union de tous les codes d'événement individuels et gammes de codes d'événement désigne l'ensemble complet de numéros d'événement pris en charge par la mise en œuvre. Si le paramètre "événements" est omis, la prise en charge des événements 0 à 15 (les tonalités DTMF) est supposée. Le paramètre "taux" décrit le taux d'échantillonnage, en Hertz. Le nombre est écrit comme un entier. Si il est omis, la valeur par défaut est 8000 Hz.

Considérations de codage : dans la terminologie décrite au paragraphe 4.8 de la [RFC4288], ce type est tramé et binaire.
Considérations de sécurité : voir la Section 6, "Considérations sur la sécurité", dans le présent document.
Considérations d'interopérabilité : aucune.
Spécification publiée : le présent document.
Applications qui utilisent ce support : le sous type audio événement-de-téléphonie prend en charge le transport des événements survenant dans les systèmes de téléphonie sur l'Internet.
Informations supplémentaires :
Numéro magique : N/A.
Extension de fichier : N/A.
Code de type de fichier Macintosh : N/A.
Adresse personnelle & de messagerie à contacter pour plus d'informations : Tom Taylor, taylor@nortel.com. groupe de travail IETF AVT.
Utilisation prévue : COMMUNE.
Restrictions d'utilisation : ce type n'est défini que pour le transfert via RTP [RFC3550].
Auteur : groupe de travail IETF Transport Audio/Vidéo.
Contrôleur des changements :  groupe de travail IETF Transport Audio/Vidéo sur délégation de l'IESG.

 	7.1.2	Enregistrement du type de support audio/tonalité
Cet enregistrement est fait en accord avec les [RFC3555] et [RFC4288].

Nom de type : audio
Nom de sous type : tonalité
Paramètres requis : aucun
Paramètres facultatifs : le paramètre "taux" décrit le taux d'échantillonnage, en Hertz. Le nombre est écrit comme un entier. Si il est omis, la valeur par défaut est 8000 Hz.

Considérations de codage : dans la terminologie définie au paragraphe 4.8 de la [RFC4288], ce type est tramé et binaire.
Considérations de sécurité : voir la Section 6, "Considérations sur la sécurité", dans le présent document.
Considérations d'interopérabilité : aucune
Spécification publiée : le présent document.
Applications qui utilisent ce support : le sous type de tonalité audio prend en charge le transport de pures tonalités composites, par exemple, celles couramment utilisées dans le système téléphonique actuel pour signaler la progression de l'appel.

Informations supplémentaires :
Numéro magique : N/A.
Extension de fichier : N/A.
Code de type de fichier Macintosh : N/A.

Adresse personnelle & de messagerie à contacter pour plus d'informations : Tom Taylor, taylor@nortel.com. groupe de travail IETF AVT.
Utilisation prévue : COMMUNE.
Restrictions d'utilisation : ce type n'est défini que pour le transfert via RTP [RFC3550].
Auteur : groupe de travail IETF Transport Audio/Vidéo.
Contrôleur des changements : groupe de travail IETF Transport Audio/Vidéo sur délégation de l'IESG.

 	8.	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 on doit mettre au crédit de Scott l'énergie derrière l'idée d'un codage compact des tonalités sur IP.

Dans la RFC 2833, les suggestions du groupe de travail Megaco ont été reconnues. Colin Perkins et Magnus Westerland, présidents du groupe de travail AVT, ont fourni des conseils utiles pour la formation du présent document. Au fil des ans, des conseils détaillés et des commentaires pour la RFC 2833, le présent document, ou les deux, ont été fournis par Hisham Abdelhamid, Flemming Andreasen, Fred Burg, Steve Casner, Dan Deliberato, Fatih Erdin, Bill Foster, Mike Fox, Mehryar Garakani, Gunnar Hellstrom, Rajesh Kumar, Terry Lyons, Steve Magnell, Zarko Markov, Tim Melanchuk, Kai Miao, Satish Mundra, Kevin Noll, Vern Paxson, Oren Peleg, Raghavendra Prabhu, Moshe Samoha, Todd Sherer, Adrian Soncodi, Yaakov Stein, Mira Stevanovic, Alex Urquizo, et Herb Wildfeur.

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

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

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

[RFC2434]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, octobre 1998. (Rendue obsolète par la RFC5226)

[RFC3264]	J. Rosenberg et H. Schulzrinne, "Modèle d'offre/réponse avec le protocole de description de session (SDP)", juin 2002. (P.S.  ; MàJ par  RFC8843)

[RFC3550]	H. Schulzrinne, S. Casner, R. Frederick et V. Jacobson, "RTP : un protocole de transport pour les applications en temps réel", STD 64, juillet 2003. (MàJ par RFC7164, RFC7160, RFC8083, RFC8108, RFC8860)

[RFC3555]	S. Casner et P. Hoschka, "Enregistrement de type MIME pour les types de charge utile RTP", juillet 2003. (P.S.  ; Rendue obsolète par les RFC 4855, 4856)

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

[RFC4288]	N. Freed et J. Klensin, "Spécifications du type de support et procédures d'enregistrement", BCP 13, décembre 2005.

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

[Q.23]	Recommandation UIT-T Q.23, "Caractéristiques techniques des appareils téléphoniques à bouton poussoir", UIT-T, Genève, 1988.

[Q.24]	Recommandation UIT-T Q.24, "Réception de signal de bouton poussoir multifréquences", UIT-T, novembre 1988.

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

[G.723.1]	Recommandation UIT-T G.723.1, "Codeurs de parole : codeur de parole à deux taux pour les communications multimédia émettant à 5,3 et 6,3 kbit/s", UIT-T, mars 1996.

[G.729]	Recommandation UIT-T G.729, "Codage de la parole à 8 kbit/s avec prédiction linéaire à excitation par séquences codées à structure algébrique conjuguée (CS-ACELP)", UIT-T, mars 1996.

[Q.35]	Recommandation UIT-T Q35, "Caractéristiques techniques des tonalités pour le service téléphonique", UIT-T, mars 1998.

[Q.931]	Recommandation UIT-T Q.931, "Réseau numérique à intégration de service (RNIS) – Système n°  1 de signalisation d'abonné numérique (DSS1) - Spécification de l'interface usager-réseau de couche 3 pour le contrôle d'appel de base". (Union Internationale des Télécommunications, Genève, mai 1998)

[RFC2833]	H. Schulzrinne, S. Petrack, "Charge utile RTP pour chiffres DTMF, tonalités téléphoniques et signaux téléphoniques", mai  2000. (Obsolète, voir RFC4733, RFC4734) (P.S.)

[RFC3351]	N. Charlton et autres, "Exigences des usagers sur le protocole d'initialisation de session (SIP) pour la prise en charge des individus malentendants et ayant des difficultés d'élocution", août 2002. (Information)

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

[RFC4734]	H. Schulzrinne, T. Taylor, "Définition des événements pour les signaux de modem, télécopie et téléphonie textuelle", décembre 2006. (Remplace RFC2833) (MàJ RFC4733) (P.S.)

[RFC5244]	H. Schulzrinne, T. Taylor, "Définition des événements de signalisation de téléphonie orientée canal", juin 2008. (MàJ RFC4733) (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.

[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.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 l'amendement 1, novembre 2002.

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

[VOIP]	VOIP Troubleshooter LLC, "Indepth: Packet Loss Burstiness", 2005, <http://www.voiptroubleshooter.com/indepth/burstloss.html >.

 	Appendice A.	Résumé des changements par rapport à la RFC 2833

Le présent mémoire a été significativement restructuré, incorporant un grand nombre de précisions à la spécification. À l'exception des éléments notés ci-dessous, les changements sont destinés à être rétro compatibles. Cependant, du fait de certaines incohérences et de définitions obscures dans la [RFC2833] il est probable que certaines mises en œuvre ont interprété ce mémoire d'une façon différente de la présente version.

La RFC 2833 exigeait que toutes les mises en œuvre soient capables de recevoir les événements DTMF (codes d'événement 0 à 15). Le paragraphe 2.5.1.1 du présent document exige qu'un envoyeur transmette seulement les événements que le receveur est capable de recevoir. En l'absence de connaissance des capacités du receveur, l'envoyeur DEVRAIT supposer la prise en charge des événements DTMF mais d'aucun autre événement. L'envoyeur DEVRAIT indiquer quels événements il peut envoyer. Le paragraphe 2.5.2.1 exige qu'un receveur qui signale ses capacités en utilisant SDP DOIT indiquer quels événements il peut recevoir.

Des valeurs non à zéro dans le champ Volume de la charge utile n'étaient applicables qu'aux tonalités DTMF dans la RFC2833, et pour les autres événements, il était exigé du receveur qu'il les ignore. Le présent mémoire exige que la définition de chaque événement indique si le champ Volume est applicable à cet événement. Le dernier alinéa du paragraphe 2.5.2.2 indique ce qu'un receveur peut faire si il reçoit des volumes avec des valeurs de zéro pour des événements auxquels le champ Volume est applicable. Avec la règle du receveur de la RFC 2833, cela assure la rétro compatibilité dans les deux directions de transmission.

Les paragraphes 2.5.1.3 et 2.5.2.3 introduisent une nouvelle procédure pour rapporter et exécuter les événements dont la durée excède la capacité du champ Durée de charge utile. Cette procédure peut causer une confusion momentanée chez un vieux receveur (RFC 2833) parce que l'horodatage est mis à jour sans établir le bit E du précédant rapport d'événement et sans établi le bit M bit du nouveau.

Les paragraphes 2.5.1.5 et 2.5.2.4 introduisent une nouvelle procédure par laquelle une séquence d'événements de courte durée peut être empaquetée dans un seul rapport d'événement. Si un receveur de la RFC 2833 reçoit un tel rapport, il peut éliminer le paquet comme invalide, car le paquet contient plus que ce qui est attendu par le receveur. En tous cas, les événements supplémentaires dans le paquet vont être perdus.

Le paragraphe 2.3.5 introduit la possibilité d'événements "d'état" et définit des procédures pour régler le champ Durée pour faire rapport de tels événements. Le paragraphe 2.5.1.2 définit des exceptions particulières pour l'établissement du bit E pour les événements d'état. Trois paragraphes supplémentaires mentionnent les procédures relatives à ces événements.

La Section Considérations sur la sécurité est mise à jour pour mentionner l'exigence de protection de l'intégrité. Plus important, elle rend obligatoire la mise en œuvre de SRTP [RFC3711] pour les mises en œuvre conformes, sans spécifier de méthode de distribution de clé de mise en œuvre obligatoire.

Finalement, le présent document établit un registre de l'IANA pour les codes d'événement et établit des critères pour leur documentation. Le présent document donne la population initiale du nouveau registre, consistant seulement en seize événements DTMF. Deux documents d'accompagnement, les [RFC4734] et [RFC5244] décrivent les événements relatifs respectivement aux modems, à la télécopie, et au texte téléphoné et à la signalisation téléphonique associée au canal. Des changements ont été apportés à cette dernière à cause d'erreurs et redondances dans les allocations de la RFC 2833. Les événements restants définis dans la RFC 2833 sont déconseillés parce qu'ils ne paraissent pas avoir été mis en œuvre, mais leur codes ont été conditionnellement réservé au cas où l'en d'entre eux serait nécessaire à l'avenir. Le Tableau 8 indique en détails la disposition des codes d'événement. Les codes d'événement non mentionnés dans ce tableau n'ont pas été alloués dans la RFC 2833 et continuent d'être inutilisés.

Codes d'événement	Description de la RFC 2833	Disposition
 0 à 15	Chiffres DTMF	RFC 4733
       16	Éclair de ligne (déconseillé)	Réservé
 23 à 31	non utilisés	[RFC4734]
 32 à 40	Données et télécopie	[RFC4734]
 41 à 48	Données et télécopie (V.8bis, déconseillé)	Réservé
 52 à 63	non utilisés	[RFC4734]
 64 à 89	Événements de ligne E.182 (déconseillé)	Réservé
  96 à 112	Événements de ligne spécifiques du pays (déconseillé)	Réservé
121 à 127	non utilisés	[RFC5244]
128 à 137	Circuits : MF 0-9	[RFC5244]
138 à 143	Circuits : autres MF(déconseillé	Réservé
144 à 159	Circuits : signalisation ABCD	[RFC5244]
160 à 168	Circuits : divers (déconseillé	Réservé
170 à 173	Circuits : divers (déconseillé	Réservé
174 à 205	non utilisés	[RFC5244]

Tableau 8 : Disposition des codes d'événement définis dans la RFC 2833

 	Adresses 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 IETF Trust (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 y contenues sont fournies 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 ci-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.