Groupe de travail Réseau	H. Schulzrinne, Columbia University
Request for Comments : 2833	S. Petrack, MetaTel
Catégorie : Sur la voie de la normalisation	mai 2000
Traduction Claude Bière de L'Isle

Charge utile RTP pour chiffres DTMF, tonalités téléphoniques 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 Internet Society (2000). Tous droits réservés.

Résumé
Le présent mémoire décrit comment porter la signalisation bi-tonalité multi fréquences (DTMF) et les autres signaux de tonalités et d'événements de téléphonie dans les paquets RTP.
Table des matières
1. Introduction	2
1.1 Terminologie	2
2. Événements contre tonalités	2
3. Format de charge utile RTP pour événements désignés de téléphonie	3
3.1 Introduction	3
3.2 Génération simultanée d'audio et d'événements	4
3.3 Types d'événements	4
3.4 Utilisation des champs d'en-tête RTP	4
3.5 Format de charge utile	5
3.6 Envoi des paquets d'événement	5
3.7 Fiabilité	6
3.8 Exemple	6
3.9 Indication des capacités du receveur avec SDP	6
3.10 Événements DTMF	7
3.11 Événements de modem de données et de télécopie	8
3.12 Événements de ligne	9
3.13 Événements de ligne étendus	11
3.14 Événements de circuits	12
4. Format de charge utile RTP pour les tonalités téléphoniques	13
4.1 Introduction	13
4.2 Exemples de signaux courants de tonalités téléphoniques	13
4.3 Utilisation des champs d'en-tête RTP	14
4.4 Format de charge utile	14
4.5 Fiabilité	15
5. Combinaison de tonalités et d'événements désignés	15
6. Enregistrement MIME	16
6.1 Événement audio/téléphone	16
6.2 Audio/tonalité	16
7. Considérations sur la sécurité	16
8. Considérations relatives à l'IANA	17
9. Remerciements	17
10. Adresse des auteurs	17
11. Bibliographie	17
12. Déclaration complète de droits de reproduction	18

 	1.	Introduction

Le présent mémoire définit deux formats de charge utile, un pour porter les chiffres bi-tonalité multi fréquences (DTMF) les signaux d'autres lignes et circuits (Section 3), et un second pour les tonalités générales multi fréquences dans les paquets RTP [RFC1889] (Section 4). Des formats de charge utile du protocole de transport en temps réel (RTP, realtime transport protocol) séparés sont souhaitables car des codecs vocaux à bas débit ne peuvent pas garantir une reproduction assez précise de ces signaux de tonalité pour une reconnaissance automatique. Définir des formats de charge utile séparés permet aussi une plus forte redondance tout en conservant un faible débit binaire.

Les formats de charge utile décrits ici peuvent être utiles dans au moins trois applications : le traitement de DTMF pour les passerelles et systèmes d'extrémité, ainsi que pour les "circuits RTP". Dans la première application, 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 des 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. La détection par la passerelle des tonalités libère le système Internet d'extrémité receveuse de ce travail et évite aussi que des codecs à faible débit binaire comme G.723.1 rendent les tonalités DTMF inintelligibles. Deuxièmement, un système d'extrémité Internet comme un "téléphone Internet" peut émuler la fonction DTMF sans se soucier lui-même de générer les paires précises de tonalités et sans imposer la charge de la reconnaissance des tonalités au receveur.

Dans l'application "circuit RTP", RTP est utilisé pour remplacer un circuit normal de commutation de circuit entre deux nœuds. Ceci est particulièrement intéressant dans un réseau téléphonique qui est encore essentiellement à commutation de circuits. Dans ce cas, chaque extrémité du circuit RTP code les canaux audio dans le codage approprié, comme G.723.1 ou G.729. Cependant, ce prodessus de codage détruit les informations de signalisation dans la bande qui sont portées en utilisant le bit de moindre poids ("signalisation du bit volé") et peut aussi interférer avec des tonalités de signalisation dans la bande, comme la tonalité de chiffres MF. De plus, les propriétes de tonalités comme l'inversion de phase dans la tonalité ANSam, ne va pas survivre au codage de la parole. Donc, la passerelle a besoin de retirer les informations de signalisation dans la bande du flux binaire. Elle peut alors soit la porter hors bande dans un mécanisme de transport de signalisation qui reste à definir, soit utiliser le mécanisme décrit dans le présent mémoire. (Si les deux points d'extrémité du circuit sont à portée du même contrôleur de passerelle de supports, celui-ci peut aussi traiter la signalisation.) La porter dans la bande peut simplifier la synchronisation entre les paquets audio et les informations de tonalités ou signaux. Ceci est particulièrement pertinent lorsque la durée et la synchronisation importent, comme dans le portage des signaux DTMF.

 	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 la [RFC2119] et indiquent les niveaux d’exigence pour les mises en œuvre conformes.

 	2.	Événements contre tonalités

Une passerelle a deux options pour traiter les chiffres et événements DTMF. D'abord, elle peut simplement mesurer les composants de fréquence des signaux de bande vocale et transmettre ces informations au receveur RTP (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.

Tous les signaux de tonalité utilisés dans le RTPC (réseau téléphonique public commuté) et destinés à la consommation humaine sont des séquences de simples combinaisons d'ondes sinusoïdales, ajoutées ou modulées. (Il y a au moins une tonalité, la tonalité ANSam [V.8] utilisée pour indiquer la transmission de données sur des lignes vocales, qui utilise des inversions de phase périodiques.)

En seconde option, une passerelle peut reconnaître les tonalités et les traduire en un nom, comme de tonalité de sonnerie ou d'occupation. Le receveur produit alors un signal de tonalité ou autre indication appropriée au signal.

Généralement, comme la reconnaissance des signaux dépend souvent de leur schéma ouvert/fermé 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 le paquet RTP immédiatement, sans le détour par des signaux acoustiques.

Dans le réseau téléphonique, les tonalités sont générées en des lieux différents, selon la technologie de commutation et la nature de la tonalité. Cela détermine, par exemple, si une personne qui fait un appel vers un pays étranger entend ses 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 RNIS peuvent générer en local la tonalité de numérotation et envoyer ensuite un message SETUP Q.931 contenant les chiffres composés. Si le terminal envoie juste un message SETUP sans aucun des chiffres de l'appelé, alors le commutateur fait la collecte des chiffres, fournis par le terminal comme des messages KEYPAD, et fournit la tonalité de numérotation sur le canal B. Le terminal peut utiliser le signal audio sur le canal B ou peut 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 unilatéral 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 de progression de l'appel dans la bande qui atteignent l'appelant avant ou au lieu d'une tonalité de sonnerie.) La tonalité d'encombrement et les tonalités d'informations spéciales peuvent être générées par tout commutateur le long du chemin, et peuvent être générées par le commutateur de l'appelant sur la base des messages ISUP 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 des instruments analogiques, ou le terminal RNIS.

Les passerelles qui envoient des événements de signalisation via RTP PEUVENT envoyer des signaux désignés (Section 3) et la représentation de tonalité (Section 4) comme une seule session RTP, en utilisant le mécanisme de redondance défini au paragraphe 3.7 pour entrelacer les deux représentations. C'est généralement une bonne idée d'envoyer les deux, car cela permet au receveur de choisir le rendu approprié.

Si une passerelle ne peut pas présenter une représentation de tonalité, elle DEVRAIT envoyer les tonalités audio comme paquets audio RTP réguliers (par exemple, comme PCMU de format de charge utile) en plus des signaux désignés.

 	3.	Format de charge utile RTP pour événements désignés de téléphonie
 	3.1	Introduction
Le format de charge utile pour les événements de téléphonie désignés décrits ci-dessous convient pour les scénarios de passerelle et de bout en bout. Dans le scénario de passerelle, une passerelle de téléphonie Internet connectant un réseau de paquets vocaux au RTPC recrée les tonalités DTMF ou les autres événements de téléphonie et les injecte dans le RTPC. Comme, par exemple, la reconnaissance des chiffres DTMF prend plusieurs dizièmes de milliseconde, les premières millisecondes d'un chiffre vont arriver comme des paquets audio réguliers. Donc, un alignement attentif du temps et de la puissance (volume) entre les échantillons audio et les événements est nécessaire pour éviter de générer des chiffres parasites chez le receveur.

Les chiffres DTMF et 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 base d'horodatage que le canal audio régulier pour simplifier la génération des ondes audio à une passerelle. La fréquence d'horloge par défaut est 8 000 Hz, mais la fréquence d'horloge peut être redéfinie quand on alloue le type de charge utile dynamique.

Le format de charge utile décrit ici réalise même dans le cas de pertes de paquets soutenues une redondance supérieure à celle de la méthode proposée pour l'accord de mise en œuvre de la voix sur relais de trame [FRF.11].

Si un système d'extrêmité est directement connecté à l'Internet et n'a pas besoin de générer à nouveau de signaux de tonalité, l'alignement en temps et les niveaux de puissance ne sont pas pertinents. Ces systèmes s'appuient sur les passerellles RTPC ou les systèmes d'extrémité Internet pour générer des événements DTMF et n'effectuent pas leur propre analyse des ondes audio. Un exemple d'un tel système est celui de la réponse vocale interactive Internet (IVR, interactive voice-response).

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 en envoi individuel, comme l'exemple de l'IVR mentionné ci-dessus, 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 sera pas utilisé.

 	3.2	Génération simultanée d'audio et d'événements
Une source PEUT envoyer des événements et des paquets audio codés pour les mêmes instants, en utilisant des événements comme le codage redondant pour le flux audio, ou elle PEUT bloquer l'audio sortant lorsque les tonalités d'événement sont actives et envoyer seulement des événements désignés comme codages à la fois primaires et redondants.

Noter qu'une période couverte par une tonalité codée peut se chevaucher dans le temps avec une période d'audio codé par d'autres moyens. Cela va probablement se produire à l'attaque d'une tonalité et est nécessaire pour éviter de possibles erreurs d'interprétation de la tonalité reproduite à l'extrémité distante. Les mises en œuvre qui prennent en charge ce format de charge utile doivent être prêtes à traiter ce chevauchement. Il est RECOMMANDÉ que les passerelles rendent seulement la tonalité codée car l'audio peut contenir des tonalités parasites introduites pas l'algorithme de compression audio. Cependant, il est prévu que ces tonalités supplémentaires ne devraient pas en général interférer avec la reconnaissance à l'extrémité distante.

 	3.3	Types d'événements
Ce format de charge utile est utilisé pour cinq types de signaux différents :
o	tonalités DTMF (paragraphe 3.10) ;
o	tonalités relatives à la télécopie (paragraphe 3.11) ;
o	tonalités de ligne d'abonné standard (paragraphe 3.12) ;
o	tonalités de ligne d'abonné spécifiques du pays (paragraphe 3.13) et 
o	événements de circuits (paragraphe 3.14).

Une mise en œuvre conforme DOIT prendre en charge les événements mentionnés au Tableau 1 à l'exception de "flash". Si elle utilise d'autres mécanismes hors bande pour la signalisation des conditions de ligne, elle n'a pas besoin de mettre en œuvre les autres événements.

Dans certains cas, une mise en œuvre peut simplement ignorer certains événements, comme des tonalités qui n'ont pas de sens dans un environement particulier. Le paragraphe 3.9 spécifie comment la mise en œuvre peut utiliser le paramètre SDP "fmtp" au sein d'une description SDP pour indiquer son incapacité à comprendre un événement ou gamme d'événements particuliers.

Selon les interfaces d'utilisateur disponibles, une mise en œuvre PEUT rendre toutes les tonalités du Tableau 5 de la même façon ou, de préférence, utiliser les tonalités portées par la charge utilie "tonalité" concurrente ou d'autres charges utiles RTP audio. Autrement, elle pourrait fournir une représentation textuelle.

Noter que les systèmes d'extrémité qui émulent le téléphone ont seulement besoin de prendre en charge les événements  décrits dans les paragraphes 3.10 et 3.12, tandis que les systèmes qui reçoivent de la signalisation de circuit ont besoin de mettre en œuvre ceux décrits dans les paragraphes 3.10, 3.11, 3.12 et 3.14, car les circuits MF portent aussi la plupart des signaux de "ligne". Les systèmes qui ne prennent pas en charge la fonction de télécopie ou de modem n'ont pas besoin de rendre les événements relatifs à la télécopie décrits au paragraphe 3.11.

Le format de charge utile RTP est conçu comme un "événement de téléphonie", le type MIME comme "événement audio/téléphone". Le taux d'horodatage par défaut est de 8000 Hz, mais d'autres taux peuvent être définis. 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 dynamiquement et hors bande.

 	3.4	Utilisation des champs d'en-tête RTP
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 3.5 s'étend à partir de cet instant. Le receveur calcule la gigue pour les rapports de receveur RTCP sur la base de tous les paquets qui ont un certain horodatage. Note : la valeur de gigue devrait principalement être utilisée comme moyen pour comparer la qualité de réception entre deux utilisateurs ou deux périodes, et non comme une mesure absolue.

Bit marqueur : le bit marqueur RTP indique le début d'un nouvel événement.

 	3.5	Format de charge utile
La Figure 1 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Événement   |E|R| Volume    |          Durée                |
+---------------+-+-+-----------+---------------+---------------+

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

Événement : les événements sont codés comme montré dans les paragraphes 3.10 à 3.14.

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é en dBm0 après l'élimination du signe. Les niveaux de puissance vont de 0 à -63 dBm0. La gamme de DTMF valides va de 0 à -36 dBm0 (doit être accepté) ; les niveaux inférieurs à -55 dBm0 doivent être rejetés (TR-TSY-000181, UIT-T Q.24A). Donc, les plus grandes valeurs notent les volumes inférieurs. Cette valeur est seulement définie pour les chiffres DTMF. Pour les autres événements, il est réglé à zéro par l'envoyeur et est ignoré par le receveur.

Durée : durée de ce chiffre, en unités d'horodatage. Donc, l'événement commence à l'instant identifié par l'horodatage RTP et a jusqu'à présent duré aussi longtemps qu'indiqué par ce paramètre. L'événement peut ou non s'être terminé. Pour un taux d'échantillonnage de 8000 Hz, ce champ est suffisant pour exprimer des durées d'événement jusqu'à approximativement 8 secondes.

E : si il est réglé à une valeur de un, le bit "End" (fin) indique que ce paquet contient la fin de l'événement. Donc, le paramètre durée au dessus mesure la durée complète de l'événement.
Un envoyeur PEUT retarder l'établissement du bit de fin jusqu'à ce qu'il retransmette le dernier paquet pour une tonalité, plutôt qu'à sa première transmission. Cela évite d'avoir à attendre de détecter si la tonalité s'est bien terminée.
Les mises en œuvre de receveur PEUVENT utiliser des algorithmes différents pour créer des tonalités, incluant les deux décrits ici. Dans le premier, 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 si l'audio est mixé, c'est-à-dire, additionné, dans la mémoire tampon d'exécution, plutôt que simplement copié.) Donc, si un paquet est perdu dans une tonalité qui dure plus longtemps que le temps d'arrivée en paquets et si le le délai d'éxécution est court, un trou peut se produire dans la tonalité. Autrement, le receveur peut commencer une tonalité et l'exécuter jusqu'à ce qu'il reçoive un paquet avec le bit "E" établi, la prochaine tonalité, distinguée par une valeur différente d'horodatage, ou qu'une certaine durée s'écoule. Ceci est plus robuste contre la perte de paquet, mais peut étendre la tonalité si toutes les retransmissions du dernier paquet dans un événement sont perdues. Limiter la période d'extension de la tonalité est nécessaire pour éviter qu'une tonalité "reste collée". Sans considération de l'algorithme utilisé, la tonalité NE DEVRAIT PAS être étendue de plus de trois temps d'inter arrivées de paquets. Une légère extension des durées de tonalité et de raccourcissement des pauses est généralement sans dommage.

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

 	3.6	Envoi des paquets d'événement
Une source audio DEVRAIT commencer à transmettre les paquets d'événement aussitôt qu'elle reconnaît un événement et toutes les 50 ms à partir de là ou à l'intervalle de paquet pour le codec audio utilisé pour cette session, si il est connu. (L'envoyeur n'a pas besoin de maintenir des intervalles de temps précis entre les paquets d'événement afin de conserver des délais inter événements précis, car les informations de synchronisation sont contenues dans l'horodatage.)

La Recommandation UIT-T Q.24 [Q.24], Tableau A-1, indique que toutes les administrations interrogées utilisent une durée minimum de signal de 40 ms, avec une vélocité de signalisation (tonalité et pause) de pas moins de 93 ms.

Si un événement se continue sur plus d'une période, la source qui génère les événements devrait envoyer un nouveau paquet d'événement avec la valeur d'horodatage RTP correspondant au début de l'événement et la durée de l'événement augmentée en conséquence. (Le numéro de séquence RTP est incrémenté de un pour chaque paquet.) Si il n'y a pas eu de nouvel événement dans le dernier intervalle, l'événement DEVRAIT être retransmis trois fois ou jusqu'à ce que le prochain événement soit reconnu. Cela assure que la durée de l'événement peut être reconnue correctement même si le dernier paquet d'un événement est perdu.

Les chiffres DTMF et les événements sont envoyés de façon incrémentaire pour éviter que le receveur attende l'achèvement de l'événement. Comme certaines tonalités sont longues de deux secondes, cela induirait un délai substantiel. L'émetteur ne sait pas si la longueur d'un événement est importante et a donc besoin de transmettre immédiatement et de façon incrémentaire. Si l'application du receveur ne se soucie pas de la longueur de l'événement, le mécanisme de transmission incrémentaire évite des délais. Certaines applications, comme les passerelles dans le RTPC, se soucient à la fois des délais et de la durée des événements.

 	3.7	Fiabilité
Durant un événement, le format de charge utile d'événement RTP fournit des mises à jour incrémentaires sur l'événement. La résilience à l'erreur dépend du délai d'exécution chez le receveur. Par exemple, pour un délai d'exécution de 120 ms et un trou de paquet de 50 ms, deux paquets à la suite peuvent être perdus sans causer de trou dans les tonalités générées chez le receveur.

Le mécanisme de redondance audio décrit dans la [RFC2198] PEUT être utilisé pour récupérer d'une perte de paquet à travers les événements. Le taux effectif de données est r fois 64 bits (32 bits pour l'en-tête de redondance et 32 bits pour la charge utile d'événement de téléphonie) toutes les 50 ms ou r fois 1280 bits/s, où r est le nombre d'événements redondants portés dans chaque paquet. La valeur de r est un compromis de la mise en œuvre : une valeur de 5 est suggérée.

Le décalage d'horodatage dans ce schéma de redondance a 14 bits, de sorte qu'il permet à un seul paquet de "couvrir" 2,048  secondes d'événements de téléphone à un taux d'échantillonnage de 8000 Hz. Inclure le temps de début des événements précédents permet une reconstruction précise de la séquence de tonalités à une passerelle. Le schéma est résilient aux pertes consécutives de paquets s'étendant sur cet intervalle de 2,048 secondes ou r chiffres, selon celui qui est le plus petit. Noter que pour les chiffres précédents, seul un volume moyen peut être représenté.

Un codeur PEUT traiter la charge utile d'événement comme une version très compressée de la trame audio en cours. Dans ce mode, chaque paquet RTP durant un événement va contenir le rendu courant du codec audio (disons, G.723.1 ou G.729) de ce chiffre ainsi que la représentation décrite au paragraphe 3.5, plus tout événement précédent vu antérieurement.

Cette approche permet aux passerelles sourdes qui ne comprennent pas ce format de fonctionner. Voir aussi la discussion de la Section 1.

 	3.8	Exemple
Un paquet RTP normal, où l'utilisateur compose juste le dernier chiffre de la séquence DTMF "911". Le premier chiifre était long de 200 ms (1600 unités d'horodatage) et a démarré à l'instant 0, le second chiffre a duré 250 ms (2000 unités d'horodatage) et commencé à l'instant 800 ms (6400 unités d'horodatage) le troisième chiffre a été composé à l'instant 1,4 s (11 200 unités d'horodatage) et le paquet montré a été envoyé à l'instant 1,45 s (11 600 unités d'horodatage). La durée de la trame est de 50 ms. Pour rendre les parties reconnaissables, la figure ci-dessous ignore l'alignement sur l'octet. L'horodatage et le numéro de séquence sont supposés avoir été zéro au début du premier chiffre. Dans cet exemple, les types de charge utile (PT) dynamiques 96 et 97 ont été alloués, respectivement, pour le mécanisme de redondance et l'événement de téléphonie.

 	3.9	Indication des capacités du receveur avec SDP
 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|     96      |              28               |
+---+-+-+-------+-+-------------+---------------+---------------+
|                          Horodatage                           |
|                             11200                             |
+---------------+---------------+---------------+---------------+
|          Identifiant de source de synchronisation (SSRC)      |
|                            0x5234a8                           |
+---------------+---------------+---------------+---------------+
|F|   Bloc PT   |  Décalage d'horodatage    | Longueur de bloc  |
|1|     97      |            11200          |         4         |
+-+-------------+---------------+-----------+---------------+---+
|F|   Bloc PT   |  Décalage d'horodatage    | Longueur de bloc  |
|1|     97      |   11200 - 6400 = 4800     |         4         |
+-+-------------+---------------+-----------+---------------+---+
|F|   Bloc PT   |
|0|     97      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Chiffre    |E R| Volume    |          Durée                |
|       9       |1 0|     7     |             1600              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Chiffre    |E R| Volume    |          Durée                |
|       1       |1 0|    10     |             2000              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Chiffre    |E R| Volume    |          Durée                |
|       1       |0 0|    20     |              400              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2 : Exemple de paquet RTP après composition du "911"

Les receveurs PEUVENT indiquer quels événements désignés ils peuvent traiter, par exemple, en utilisant le protocole de description de session [RFC2327]. Les formats de charge utile utilisent le format fmtp suivant pour faire la liste des valeurs d'événement qu'ils peuvent recevoir :

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

La liste des valeurs consiste en éléments séparés par une virgule, qui peuvent être un seul nombre décimal ou deux nombres décimaux séparés par un tiret, où le second nombre est supérieur au premier. Aucune espace n'est permise entre les numéros ou les tirets. La liste n'a pas à être triée.

Par exemple, si le format de charge utile utilise le type de charge utile numéro 100, et si la mise en œuvre peut traiter les tonalités DTMF (événements 0 à 15) et les tonalités de numérotation et de sonnerie, elle va inclure la description suivante dans son message SDP :

a=fmtp:100 0-15,66,70

Comme toutes les mises en œuvre DOIVENT être capables de recevoir les événements 0 à 15, faire la liste de ces événements dans la ligne a=fmtp est FACULTATIF.

Le paramètre MIME correspondant est "events", de sorte que la définition de type de support d'échantillons suivante correspond à l'exemple SDP ci-dessus :

audio/telephone-event;events="0-11,66,67";rate="8000"

 	3.10	Événements DTMF
Le Tableau 1 résume les événements désignés relatifs à DTMF dans le format de charge utile telephone-event.

Événements	Codage (décimal)
 0—9	0--9
* 	10
 #	11
 A—D	12--15
 Flash 	16

Tableau 1 : événements DTMF désignés

 	3.11	Événements de modem de données et de télécopie
Le Tableau 3 résume les événements et tonalités qui peuvent apparaître sur une ligne d'abonné desservant un télécopieur ou un modem. Les tonalités sont décrites ci-dessous, avec des détails supplémentaires dans le Tableau 7.

ANS : cette tonalité de 2100 +/- 15 Hz est utilisée pour désactiver la suppression d'écho pour la transmission de données [V.25], [T.30]. Pour les télécopieurs, la Recommandation T.30 [T.30] se réfère à cette tonalité comme tonalité de réponse d'identification du terminal appelé (CED).

/ANS : c'est le même signal que ANS, excepté qu'il inverse la phase à un intervalle de 450 +/- 25 ms. Il désactive les annuleurs d'écho et les suppresseurs d'écho. (Dans la Recommandation UIT-T V.25 [V.25], ce signal est rendu comme ANS avec une barre par dessus.)

ANSam : la tonalité de réponse modifiée (ANSam) [V.8] est un signal sinusoïdal à 2100 +/- 1 Hz sans inversion de phase, modulé en amplitude par une sinusoïde à 15 +/- 0,1 Hz. Cette tonalité est envoyée par les modems si la désactivation d'annuleur d'écho du réseau n'est pas exigée.

/ANSam : la tonalité de réponse modifiée avec inversions de phase (ANSam) [V.8] est un signal sinusoïde à 2100 +/- 1 Hz avec inversions de phase à des intervalles de 450 +/- 25 ms, modulé en amplitude par une sinusoïde à 15 +/- 0,1 Hz. Cette tonalité [G.165], [V.25] est envoyée par les modems [V.34] et les télécopieurs pour désactiver les suppresseurs d'écho.

CNG : après avoir numéroté le numéro de téléphone du télécopieur appelé (et avant qu'il réponde) le télécopieur de groupe  III appelant commence (facultativement) à envoyer une tonalité d'appel (CNG) consistant en une tonalité de 1100 Hz interrompue [T.30].

Crdi : demande de capacités (CRd), côté initiateur, [V.8bis] est un signal à double tonalités avec des tonalités à 1375 Hz et 2002 Hz pendant 400 ms, suivies par une seule tonalité à 1900 Hz pendant 100 ms. "Ce signal demande à la station distante de passer du mode téléphonie à un mode de transfert d'information et demande la transmission d'un message de liste de capacités de la part de la station distante. En particulier, CRdi est envoyé par la station initiatrice durant le cours d'un appel, ou par la station appelante à l'établissement de l'appel en réponse à un CRe ou MRe."

Crdr : CRdr est la tonalité de réponse à CRdi (voir ci-dessus). Elle consiste en un signal à double tonalités avec des tonalités à 1529 Hz et 2225 Hz pendant 400 ms, suivies par une seule tonalité à 1900 Hz pendant 100 ms.

Cre : demande de capacité (CRe) [V.8bis] est un signal de double tonalités avec des tonalités à 1375 Hz et 2002 Hz pendant 400 ms, suivies par une seule tonalité à 400 Hz pendant 100 ms. "Ce signal demande à la station distante de passer du mode téléphonie au mode de transfert d'informations et demande la transmission d'un message de liste de capacités de la part de la station distante. En particulier, CRe est envoyé par une station de réponse automatique à l'établissement de l'appel."

CT : "La tonalité d'appel [V.25] consiste en une série de salves interrompues de signaux binaires 1 ou de 1300 Hz, pendant une durée de pas moins de 0,5 s et pas plus de 0,7 s et pause pour une durée de pas moins de 1,5 s et pas plus de 2,0 s." Les modems qui ne démarrent pas avec la tonalité d'initialisation d'appel V.8 utilisent souvent cette tonalité.

Esi : le signal d'échappement (ESi) [V.8bis] est un signal à double tonalités avec des tonalités à 1375 Hz et 2002 Hz pendant 400 ms, suivi par une seule tonalité à 980 Hz pendant 100 ms. "Ce signal demande à la station distante de passer du mode téléphone à un mode de transfert d'informations. Le signal ESi est envoyé par la station initiatrice."

Esr : le signal d'échappement (ESr) [V.8bis] est un signal à double tonalités avec des tonalités à 1529 Hz et 2225 Hz pendant 400 ms, suivi par une seule tonalité à 1650 Hz pendant 100 ms. Comme pour ESi, mais envoyé par la station qui répond.

Mrdi : la demande de mode (MRd), côté initiateur, [V.8bis] est un signal à double tonalités avec des tonalités à 1375 Hz et 2002 Hz for 400 ms pendant 400 ms, suivi par une seule tonalité à 1150 Hz pendant 100 ms. "Ce signal demande à la station distante de passer du mode téléphonie à un mode de transfert d'informations et demande la transmission d'un message de sélection de mode par la station distante. En particulier, le signal MRd est envoyé par la station initiatrice dans le cours d'un appel, ou par la station appelante à l'établissement de l'appel en réponse à un MRe." [V.8bis]

Mrdr : MRdr est la tonalité de réponse à MRdi (voir ci-dessus). Il consiste en un signal à double tonalités avec des tonalités à 1529 Hz et 2225 Hz pendant 400 ms, suivi par une seule tonalité à 1150 Hz pendant 100 ms.

Mre : la demande de mode (MRe) [V.8bis] est un signal à double tonalités avec des tonalités à 1375 Hz et 2002 Hz pendant 400 ms, suivi par une seule tonalité à 650 Hz pendant 100 ms. "Ce signal demande à la station distante de passer du mode téléphonie à un mode de transfert d'informations et demande la transmission d'un message de sélection de mode par la station distante. En particulier, le signal MRe est envoyé par une station de réponse automatique à l'établissement de l'appel." [V.8bis]

V.21 : V.21 décrit un modem à 300 bit/s bi-directionnel qui emploie la modulation par déplacement de fréquences (FSK, frequency shift keying). Il est utilisé par les télécopieurs de groupe 3 pour échanger des informations T.30. L'appelant émet sur le canal 1 et reçoit sur le canal 2 ; le modem qui répond émet sur le canal 2 et reçoit sur le canal 1. Chaque valeur de bit a une tonalité distincte, de sorte que la signalisation V.21 comporte un total de quatre tonalités distinctes.

Le Tableau 2 résume les procédures utilisées

Procédure	Indications
V.25 et V.8 	ANS
V.25, annuleur d'écho désactivé	ANS, /ANS, ANS, /ANS
V.8	ANSam
V.8, annuleur d'écho désactivé	/ANSam

Tableau 2 : Utilisation de ANS, ANSam et /ANSam dans les Recommandations V.x

Événement	Codage (décimal)
tonalité de réponse (ANS)	32
/ANS	33
ANSam	34
/ANSam	35
tonalité d'appel (CNG)	36
V.21 canal 1, bit "0"	37
V.21 canal 1, bit "1"	38
V.21 canal 2, bit "0"	39
V.21 canal 2, bit "1"	40
CRdi 	41
CRdr 	42
CRe	43
ESi	44
ESr	45
Mrdi	46
Mrdr	47
Mre	48
CT	49

Tableau 3 : événements désignés de données et de télécopie

 	3.12	Événements de ligne
Le Tableau 4 résume les événements et tonalités qui peuvent apparaître sur une ligne d'abonné.

La Recommandation UIT-T E.182 [E.182] définit quand certaines tonalités devraient être utilisées. Elle définit les tonalités standard suivantes qui sont entendues par l'appelant :

tonalité de numérotation : le commutateur est prêt à recevoir les informations d'adresse.

tonalité de numérotation interne au PABX : le PABX est prêt à recevoir les informations d'adresse.

tonalité de numérotation spéciale : la même que la tonalité de numérotation, mais la ligne de l'appelant est soumise à une condition spécifique, comme un renvoi d'appel ou qu'une messagerie vocale est disponible (par exemple, "tonalité de manœuvre cadencée").

tonalité de seconde numérotation : le réseau a accepté les informations d'adresse, mais des informations supplémentaires sont requises.

sonnerie : cet événement de signal désigné cause la génération par le receveur d'un signal d'alertie ("sonnerie"). La tonalité réelle ou les autres indications utilisées pour rendre cet événement désigné relèvent du receveur. (Ceci diffère de la tonalité de sonnerie, ci-dessous, entendue par l'appelant.)

tonalité de sonnerie : l'appel a été passé à l'appelé et un signal d'appel (sonnerie) est transmis à l'appelé. Cette tonalité est aussi appelée "retour d'appel".

tonalité de sonnerie spéciale : un service spécial, comme une transmission d'appel ou un appel en attente, est actif chez le numéro appelé.

tonalité d'occupation : le numéro de téléphone appelé est occupé.

tonalité d'encombrement : les facilités nécessaires pour l'appel sont temporairement indisponibles.

tonalité de service de carte d'appel : elle consiste en 60 ms de la somme de tonalités à 941 Hz et 1477 Hz (DTMF '#') suivie par 940 ms de 350 Hz et 440 Hz (tonalité de numérotation des USA) décroissant de façon exponentielle avec une constante de temps de 200 ms.

tonalité d'information spéciale : l'appelé ne peut pas être joint, mais la raison n'est ni "occupé" ni "encombrement". Cette tonalité devrait être utilisée avant toute annonce d'échec de l'appel, à l'intention des équipements automatiques.

tonalité de bruit de fond : l'appel est en cours de traitement. Cette tonalité peut être utilisée durant de longs délais après la numérotation, par exemple, dans les connexions internationales.

tonalité de mise en garde : l'appelant a été placé en garde.

tonalité d'enregistrement : l'appelant a été connecté à un répondeur automatique et il lui est demandé de commencer à parler.

tonalité d'appel en attente : la station appelée est occupée, mais a un service d'appel en attente.

tonalité de payement : l'appelant, qui est à un téléphone à pièces, est invité à mettre des pièces supplémentaires.

tonalité d'indication positive : le service supplémentaire a été activé.

tonalité d'indication négative : le service supplémentaire n'a pas pu être activé.

tonalité d'avertissement de décroché : l'appelant a laissé le combiné décroché pendant un longue période.

Les tonalités suivantes peuvent être entendues par l'appelant ou l'appelé durant une conversation :

tonalité d'appel en attente : une autre partie veut joindre l'abonné.

tonalité d'avertissement : l'appel est enregistré. Cette tonalité n'est pas exigée dans toutes les jurisdictions.

tonalité d'intrusion : l'appel est surveillé, par exemple,par un opérateur.

signal d'alerte CPE : tonalité utilisée pour alerter un appareil de l'arrivée d'une transmission de données FSK dans la bande. Un signal d'alerte CPE est une tonalité combinée à 2130 et 2750 Hz, toutes deux avec des tolérances de 0,5 % et une durée de 80 ms. Le signal d'alerte CPE est utilisé avec des services ADSI et d'identifiant d'appel en attente [Critères].

Les tonalités suivantes sont entendues par les opérateurs :

tonalité de reconnaissance de téléphone à pièces : la personne qui fait l'appel ou est appelée utilise un téléhone à pièces (et donc il est mal avisé de permettre des appels en PCV à une telle personne).

Événement	Codage (décimal)
Décroché 	64
Racccroché	65
Tonalité de numérotation 	66
Tonalité de numérotation interne au PABX	67
Tonalité de numérotation spéciale	68
Tonalité de seconde numérotation	69
Tonalité de sonnerie	70
Tonalité de sonnerie spéciale	71
Tonalité d'occupation	72
Tonalité d'encombrement	73
Tonalité d'informations spéciales	74
Tonalité de bruit de fond	75
Tonalité de mise en garde	76
Tonalité d'enregistrement	77
Tonalité d'appelant en attente	78
Tonalité d'appel en attente	79
Tonalité de payement	80
Tonalité d'indication positive	81
Tonalité d'indication négative	82
Tonalité d'avertissement 	83
Tonalité d'intrusion	84
Tonalité de service de carte d'appel	85
Tonalité de reconnaissance de téléphone à pièces	86
Signal d'alerte CPE (CAS)	87
Tonalité d'avertissement de décroché	88
Sonnerie	89

Tableau 4 : Événements de ligne E.182

 	3.13	Événements de ligne étendus
Le Tableau 5 récapitule les événements et tonalités spécifiques de pays qui peuvent apparaître sur une ligne d'abonné.

Événement	Codage (décimal)
Tonalité d'acceptation	96
Tonalité de confirmation	97
Tonalité de numérotation, rappel	98
Tonalité de fin de service à trois	99
Tonalité de facilités	100
Tonalité de ligne verrouillée	101
Tonalité de numéro injoignable	102
Tonalité d'offre	103
tonalité de signal permanent	104
Tonalité de préemption	105
Tonalité de file d'attente	106
Tonalité de refus 	107
Tonalité d'acheminement	108
Tonalité de validité	109
Tonalité d'attente	110
Tonalité d'avertissement (fin de période)	111
Tonalité d'avertissement (PIP)	112

Tableau 5 : événements de ligne spécifiques de pays

Le T1 ESF (format de super trame étendu) permet 2, 4, et 16 options de bits de signalisation d'état. Ces bits de signalisation sont nommés A, B, C, et D. Les informations de signalisation sont envoyées comme des bits volés dans les trames 6, 12, 18, et 24 quand on utilise le tramage ESF T1. Une super trame D4 transmet seulement une signalisation à quatre états avec les bits A et B. Sur la trame CEPT E1, toute la signalisation est portée dans l'intervalle de temps 16, et deux canaux de signalisation à 16 états (ABCD) sont envoyés par trame.

Comme cette information est un état plutôt qu'un signal changeant, les mises en œuvre DEVRAIENT utiliser le mécanisme de triple redondance suivant, similaire à celui spécifié dans la Rcommandation UIT-T I.366.2 [I.366.2], Annexe L. Au moment d'une transition, les mêmes informations ABCD sont envoyées trois fois à un intervalle de 5 ms. Si une autre transition se produit durant ce temps, alors cela continue. Après une période sans changement, les informations ABCD sont envoyées toutes les 5 secondes.

Clignotant : une brève transition, normalement 120 à 290 ms, de raccroché (non saisi) à décroché (saisi) et retour à raccroché, utilisée par le commutateur entrant pour signaler que la signalisation d'adresse de l'appel peut se faire.

 	3.14	Événements de circuits
Le Tableau 6 récapitule les événements et tonalités qui peuvent apparaître sur un circuit. Noter qu'un circuit peut aussi porter des événements de ligne (paragraphe 3.12) car la signalisation MF ne comporte pas de signaux vers l'arrière [Signal].

ABCD transitoire : signalisation à 4 bits utilisée pa les circuits numériques. Pour la signalisation à N états, les N premières valeurs sont utilisées.

Saisie entrante : indication entrante de tentative d'appel (décroché).

Événement	Codage (décimal)
MF 0... 9	128...137
MF K0 ou KP (début d'impulsion)	138
MF K1	139
MF K2	140
MF S0 à ST (fin d'impulsion)	141
MF S1... S3	142...143
Signalisation ABCD (voir ci-dessus)	144...159
Clignotement	160
Fin de clignotement	161
Saisie entrante	162
Saisie	163
Circuit non saisi	164
Essai de continuité	165
Tonalité de défaut de continuité	166
Tonalité de continuité (tonalité seule)	167
Essai de continuité envoyé	168
Continuité vérifiée	170
Bouclage arrière	171
Ancienne tonalité milliwatt (1000 Hz)	172
Nouvelle tonalité milliwatt (1004 Hz)	173

Tableau 6 : Événements de circuits

Saisie : saisie par le commutateur qui répond, en réponse à une saisie sortante.

Circuit non saisi : transition d'un circuit de décroché à raccroché à la fin d'un appel.

Fin de clignotement : brève transition, normalement de 100 à 350 ms, de décroché (saisi) à raccroché (non saisi) et retour à décroché (saisi). Utilisé par des circuits de services d'opérateur.

Tonalité de continuité envoyée : tonalité de 2010 Hz.

Tonalité de continuité détectée : tonalité de 2010 Hz.

Essai de continuité envoyé : tonalité de 1780 Hz envoyée par le commutateur appelant. Si elle est reçue par le commutateur appelé, il retourne une tonalité "continuité vérifiée".

Continuité vérifiée : tonalité de 2010 Hz. C'est une tonalité de réponse, utilisée dans les procédures de double tonalités.

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

Il n'y a pas de norme internationale sur les tonalités téléphoniques comme la tonalité de numérotation, de sonnerie (retour d'appel) d'occupation, d'encombrement ("occupé") des tonalités d'annonces spéciales, ou autres tonalités spéciales, comme la reconnaissance des téléphones à pièces, des appels en attente ou de l'enregistrement. Cependant, dans tous les pays, ces tonalités partagent un certain nombre de caractéristiques [E.180] :

o	Les tonalités de téléphonie consistent 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 pour les événements de téléphonie sont dans la gamme de 25 (tonalité de sonnerie en Angola) à 1800 Hz. La CED est la plus haute tonalité utilisée à 2100 Hz. La gamme des fréquences de téléphonie est limitée à 3 400 Hz. (Le piano a une gamme de 27,5 à 4186 Hz.)

o	Les fréquences de modulation vont de 15 (tonalité ANSam) à 480 Hz (Jamaique). Des fréquences non entières ne sont utilisées que pour les fréquences de 16 2/3 et 33 1/3 Hz. (Ces fractions de fréquences paraissent être dérivées de plus anciennes de grilles de fréquences en courant continu.)

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

o	La Recommandation UIT-T E.180 [E.180] note que 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 courants de tonalités téléphoniques
Pour aider les mises en œuvre, le Tableau 7 récapitule certaines tonalités courantes. Les rangées intitiulées "UIT ..." se réfèrent à la recommandation générale de la Recommandation UIT-T E.180 [E.180]. Noter qu'il n'y a pas de lignes directrices spécifiques pour ces tonalités. Dans le tableau, le symbole "+" indique l'ajout des tonalités, sans modulation, tandis que "*" indique la modulation en amplitude. La signification de certaines des tonalités est décrite au paragraphe 3.12 ou 3.11 (pour V.21).

Nom de la tonalité	Fréquence	Période avec	Période sans
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 "0" bit, ch. 1	1180	0,00333
V.21 "1" bit, ch. 1	 980	0,00333
V.21 "0" bit, ch. 2	1850	0,00333
V.21 "1" bit, ch. 2	1650	0,00333
tonalité de num. UIT	 425	–	--
tonalité de num. U.S	350+440	–	--
______________________________________________________
tonalité de sonnerie UIT	425	0,67--1,5	3--5
tonalité de sonnerie U.S	440+480	2,0	4,0
tonalité d'occupation UIT	425
tonalité d'occupation U.S	480+620	0,5	0,5
______________________________________________________
tonalité d'encombrement UIT	425
tonalité d'encombrement U.S	480+620	0,25	0,25

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

 	4.3	Utilisation des champs d'en-tête RTP
Horodatage : l'horodatage RTP reflète le point de mesure pour le paquet en cours. La durée de l'événement décrite au paragraphe 3.5 s'étend à partir de cet instant.

 	4.4	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é "tone" qui peut représenter des tonalités consistant en une ou plusieurs fréquences. (Le type MIME correspondant est "audio/tone".) Le taux d'horodatage par défaut est de 8 000 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, mais seulement la durée.

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 dynamiquement et hors bande.

Il est montré dans la Figure 3.

 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 3 : format de charge utile pour tonalités

La charge utile contient les champs suivants :

Modulation : fréquence de modulation, en Hz. Le champ est un entier non signé de 9 bits, permettant des fréquenes de modulation jusqu'à 511 Hz. Si il n'y a pas de modulation, ce champ a une valeur de zéro.

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 au 1/3 Hz, car des fréquences de modulation comme 16 2/3 Hz sont utilisées en pratique.

Volume : le niveau de puissance de la tonalité, exprimé en dBm0 après élimination du signe, avec une gamme de 0 à -63  dBm0. (Note : une gamme de niveau 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. La tonalité commence à l'instant identifié par l'horodatage RTP et dure la valeur de la durée. 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 : les fréquences des tonalités à ajouter, mesurées en Hz et représentées comme un entier non signé de 12 bits. 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 le silence. Une seule tonalité peut contenir un nombre quelconque de fréquences.

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

 	4.5	Fiabilité
Ce format de charge utile utilise le mécanisme de fiabilité décrit au paragraphe 3.7.

 	5.	Combinaison de tonalités et d'événements désignés

Les formats de charge utile des Sections 3 et 4 peuvent être combinés en une seule charge utile en utilisant la méthode spécifiée dans la RFC 2198. La Figure 4 montre un exemple. Dans cet exemple, le paquet RTP combine deux charges utiles "tones" et une "telephone-event". Les types de charge utile sont choisis arbitrairement comme respectivement 97 et 98, avec un taux d'échantillonnage de 8000 Hz. Ici, le format de redondance a le type de charge utile dynamique de 96.

Le paquet représente une photographie de la tonalité de sonnerie des U.S.A, 1,5 secondes (12 000 unités d'horodatage) dans la seconde partie "active" de la cadence 2,0/4,0 seconde, c'est-à-dire, un total de 7,5 secondes (60 000 unités d'horodatage) dans le cycle de sonnerie. La tonalité 440 + 480 Hz de cette seconde cadence a commencé à l'horodatage RTP 48 000. Quatre secondes de silence la précèdent, mais comme la RFC 2198 a seulement un décalage de quatorze bits, seules 2,05 s (16 383 unités d'horodatage) peuvent être representées. Même si la séquence de tonalité n'est pas complète, l'envoyeur a été capable de déterminer que c'est bien un retour d'appel, et donc il inclut l'événement désigné correspondant.

 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 |P|X|  CC   |M|     PT      |     Numéro de séquence        |
| 2 |0|0|   0   |0|     96      |              31               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Horodatage                           |
|                             48000                             |
+---------------+---------------+---------------+---------------+
|       Identifiant de source de synchronisation (SSRC)         |
|                            0x5234a8                           |
+-+-------------+---------------+-----------+-------------------+
|F|   bloc PT   |   Décalage d'horodatage   | Longueur de bloc  |
|1|     98      |            16383          |         4         |
+-+-------------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|   bloc PT   |   Décalage d'horodatage   | Longueur de bloc  |
|1|     97      |            16383          |         8         |
+-+-------------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|   Block PT  |
|0|     97      |
+-+-------------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|évémnt=sonnerie|0|0| Volume=0  |        durée=28383            |
+---------------+---------------+---------------+---------------+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Modulation=0    |0| Volume=63 |        durée=16383            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|     Fréquence=0       |0 0 0 0|    Fréquence=0        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Modulation=0    |0| Volume=5  |        Durée=12000            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|     Fréquence=440     |0 0 0 0|    Fréquence=480      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4 : Combinaison de tonalités et événements dans un seul paquet RTP

 	6.	Enregistrement MIME
 	6.1	Événement audio/téléphone
Nom de type de support MIME : audio
Nom de sous type MIME : telephone-event
Paramètres exigés : aucun
Paramètres facultatifs : Le paramètre "events" fait la liste des événements pris en charge par la mise en œuvre. Les événements sont mentionnés comme un ou plusieurs éléments séparés par une virgule. Chaque élément peut être un seul ou deux entiers séparés par un tiret. Aucune espace n'est permise dans l'argument. Les entiers désignent les numéros d'événement pris en charge par la mise en œuvre. Toutes les mises en œuvre DOIVENT prendre en charge les événements 0 à 15, de sorte que le paramètre peut être omis si la mise en œuvre ne prend que ces événements en charge. Le paramètre "rate" décrit le taux d'échantillonnage en Hertz. Le nombre est écrit avec un nombre à virgule flottante ou comme un entier. Si il est omis, la valeur par défaut est 8000 Hz.
Considérations de codage : ce type est seulement défini pour le transfert via RTP [RFC1889].
Considérations de sécurité : voir la Section 7, "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 telephone-event prend en charge le transport des événements qui se produisent dans les systèmes de téléphonie sur l'Internet.
Information supplémentaires :
1. Numéro magique : N/A
2. Extension de fichier : N/A
3. Code de type de fichier Macintosh : N/A

 	6.2	Audio/tonalité
Nom de type de support MIME : audio
Nom de sous type MIME : tone
Paramètres exigés : aucun
Paramètres facultatifs : le paramètre "rate" décrit le taux d'échantillonnage, en Hertz. Le nombre est écrit comme un nombre à virgule flottante ou comme entier. Si il est omis, la valeur par défaut est 8000 Hz.
Considérations de codage : ce type n'est défini que pour le transfert via RTP [RFC1889].
Considérations de sécuité : voir la Section 7, "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 tone 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.
Information supplémentaires :
1. Numéro magique : N/A
2. Extension de fichier : N/A
3. Code de type de fichier Macintosh : N/A

 	7.	Considérations sur la sécurité

Les paquets RTP qui utilisent le format de charge utile défini dans la présente spécification sont soumis aux considérations sur la sécurité discutées dans la spécification RTP [RFC1889], et dans tout profil RTP approprié (par exemple de la [RFC1890]). Cela implique que la confidentialité des flux de supports est réalisée par le chiffrement. Parce que la compression de données utilisée avec ce format de charge utile est appliquée de bout en bout, le chiffrement peut être effectué après la compression afin qu'il n'y ait pas de conflit entre les deux opérations.

Ce type de charge utile ne présente aucune non uniformité significative de la complexité de calcul du côté receveur pour le traitement de paquet qui pourrait causer une menace potentielle de déni de service.

Dans les réseaux plus anciens qui emploient la signalisation dans la bande et manquent des filtres de tonalité appropriés, les tonalités du paragraphe 3.14 peuvent être utilisés pour commettre des fraudes sur les tarifs.

Des considérations de sécurité supplémentaires sont décrites dans la [RFC2198].

 	8.	Considérations relatives à l'IANA

Le présent document définit deux nouveaux formats de charge utile RTP, appelés telephone-event et tones, et les types associés de support Internet (MIME) audio/telephone-event et audio/tone.

Dans le type audio/telephone-event, des événements supplémentaires DOIVENT être enregistrés par l'IANA. Les enregistrements sont soumis à l'approbation du président en exercice du groupe de travail IETF audio/video transport, ou par un expert désigné par le directeur de la zone transport si le groupe de travail AVT a été fermé.

La signification des nouveaux événements DOIT être documentée dans une RFC ou un document de normalisation équivalent produit par un autre organisme de normalisation comme l'UIT-T.

 	9.	Remerciements

Nous remercions de ses suggestions le groupe de travail Megaco. Des avis et commentaires détaillés ont été fournis par Fred Burg, Steve Casner, Fatih Erdin, Bill Foster, Mike Fox, Gunnar Hellstrom, Terry Lyons, Steve Magnell, Vern Paxson et Colin Perkins.

 	10.	Adresse des auteurs

Henning Schulzrinne
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
USA
mél : schulzrinne@cs.columbia.edu 

Scott Petrack
MetaTel
45 Rumford Avenue
Waltham, MA 02453
USA
mél :  scott.petrack@metatel.com 

 	11.	Bibliographie

[Critères]	Bellcore, "Functional criteria for digital loop carrier systems," Technical Requirement TR-NWT-000057, Telcordia (anciennement Bellcore), Morristown, New Jersey, janvier 1993.

[E.180]	Recommandation UIT-T E.180, "Caractéristiques techniques des tonalités du service téléphonique", UIT-T, Genève, janvier 1994.

[E.180sup2]	Supplément 2 à la Recommandation UIT-T E.180, "Tonalités diverses utilisées dans les réseaux nationaux", UIT-T, Genève, janvier 1994.

[E.182]	Recommandation UIT-T E.182, "Application des tonalités et annonces enregistrées dans les services téléphoniques," UIT-T, Genève, mars 1998.

[FRF.11]	R. Kocen and T. Hatala, "Voice over frame relay implementation agreement", Implementation Agreement FRF.11, Frame Relay Forum, Foster City, California, janvier 1997.

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

[I.366.2]	Recommandation UIT-T I.366.2, "Sous couche de convergence spécifique du service AAL de type 2 pour circuits", Union Internationale des Télécommunications, Genève, février 1999.

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

[RFC1889]	H. Schulzrinne, S. Casner, R. Frederick et V. Jacobson, "RTP : protocole de transport pour applications en temps réel", janvier 1996. (Obsolète, voir RFC3550 STD64) 

[RFC1890]	H. Schulzrinne, "Profil RTP pour conférences audio et vidéo avec contrôle minimal", janvier 1996. (Obsolète, voir RFC3551) (P.S.)

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

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

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

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

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

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

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

[Signal]	J. G. van Bosse, "Signaling in Telecommunications Networks Telecommunications and Signal Processing", New York, New York: Wiley, 1998.

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

Copyright (C) The Internet Society (2000). Tous droits réservés.

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent paragraphe soient inclus dans toutes copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour les besoins du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant droits.

Le présent document et les informations contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

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