Groupe de travail Réseau	H. Schulzrinne, Columbia U.
Request for Comments : 5244	T. Taylor, Nortel
RFC mise à jour : 4733	juin 2008
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle

Définition des événements 
pour la signalisation téléphonique en mode canal

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

Notice de copyright
Copyright (C) The IETF Trust (2006).

Résumé
Le présent mémoire met à jour la RFC 4733 pour ajouter des codes d'événement pour les signaux de téléphonie utilisés pour la signalisation associée au canal quand ils sont portés dans la charge utile RTP d'événement de téléphonie. Il se substitue et ajoute à l'allocation originale de codes d'événements du paragraphe 3.14 de la RFC 2833. Comme documenté dans l'Appendice A de la RFC 4733, certains des événements de la RFC 2833 ont été déconseillés parce que leur spécification était ambiguë, erronée, ou redondante. En fait, le degré de changement par rapport au paragraphe 3.14 de la RFC 2833 est tel que les mises en œuvre du présent document ne seront pleinement rétro compatibles avec les mises en œuvre de la RFC 2833 que dans le seul cas de la signalisation du bit ABCD complet. Le présent document étend et améliore la couverture des systèmes de signalisation par rapport à la RFC 2833.
Table des matières
1. Introduction	1
1.1 Généralités	1
1.2 Terminologie	2
2. Définitions d'événements	2
2.1 Système de signalisation n° 5	3
2.2 Système de signalisation R1 et MF nord américaine	4
2.3 Système de signalisation R2	5
2.4 Signalisation ABCD transitoire pour circuits numériques	6
2.5 Tonalités de continuité	7
2.6 Événement Circuit indisponible	8
2.7 Événement Impulsion de mesure	8
3. Considérations d'encombrement	8
4. Considérations sur la sécurité	9
5. Considérations relatives à l'IANA	9
6. Remerciements	10
7. Références	10
7.1 Références normatives	10
7.2 Références pour information	11
Adresse des auteurs	11
Déclaration complète de droits de reproduction	11

 	1.	Introduction
 	1.1	Généralités
Le présent document étend l'ensemble des événements de téléphonie défini dans le cadre de la [RFC4733] pour y inclure les événements de signalisation qui peuvent apparaître sur un circuit dans le réseau téléphonique. La plupart de ces événements correspondent à des signaux dans un des systèmes de signalisation associés au canal encore en usage au sein du RTPC.

Les jonctions (ou circuits) dans le RTPC sont les chemins des supports entre les commutateurs téléphoniques. Une succession de protocoles a été développée en utilisant les tonalités et les conditions électriques sur les jonctions individuelles pour établir les appels téléphoniques qui les utilisent. Les événements définis dans le présent document prennent en charge une application où une telle signalisation RTPC est portée entre deux passerelles sans être signalée dans le réseau IP : l'application "circuit RTP".

Dans l'application "circuit RTP", RTP est utilisé pou remplacer une jonction normale 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é de la jonction RTP code des canaux audio avec le codage approprié, comme [G.723.1] ou [G.729]. Cependant, ce processus 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 les tonalités de signalisation dans la bande, comme les tonalités de chiffres multi fréquences (MF, multi-frequency).

Dans une application normale, les passerelles peuvent échanger leurs rôles d'un appel à l'autre : elles doivent être capables d'envoyer ou de recevoir chaque signal mis en œuvre dans le Tableau 1.

Le présent document définit des événements relatifs à quatre systèmes de signalisation différents. Trois d'entre eux se fondent sur l'échange de tonalités multi fréquences. Le quatrième ne fonctionne que sur des circuits numériques, et utilise les bits volés de moindre poids du support codé. De plus, le présent document définit des événements de tonalité pour prendre en charge des tâches comme la vérification de continuité du chemin des supports.

On notera que les descriptions des systèmes de signalisation données ci-dessous sont incomplètes. Elles sont fournies pour donner le contexte des définitions des événements qui s'y rapportent, mais omettent de nombreux détails importants de leur mise en œuvre.

 	1.2	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] et indiquent les niveaux d'exigence pour les mises en œuvre conformes.

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

KP (Key Pulse) : impulsion clé

MF(Multi-Frequency) : multi fréquences

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

RTP (Real-time Transport Protocol) : protocole de transport en temps réel [RFC3550]

ST (Start) : début

 	2.	Définitions d'événements

Le Tableau 1 fait la liste de tous les événements définis dans le présent document. Comme indiqué au Tableau 8 (Appendice A) de la [RFC4733], l'utilisation de certains des codes d'événement de la [RFC2833] a été déconseillée parce que leur spécification était ambiguë, erronée, ou redondante. En fait, le degré de changement par rapport au paragraphe 3.14 de la RFC 2833 est tel que les mises en œuvre du présent document ne vont être pleinement rétro compatibles avec les mises en œuvre de la RFC 2833 que dans le cas de la signalisation de bits ABCD complète. Le présent document étend et améliore la couverture des système de signalisation par rapport à la RFC 2833.

Noter que le registre de l'IANA des codes d'événement de téléphonie a été établi par la RFC 4733, et non par la RFC 2833. Donc, les allocations de code d'événement faites originalement dans la RFC 2833 n'apparaissent dans le registre que si elles sont réaffirmées dans la RFC 4733 ou une mise à jour de la RFC 4733, comme le présent document.

Événement	Fréquence (Hz)	Code d'événement	Type d'événement	Volume ?
MF 0...9	(Tableau 2)	128...137	tonalité	oui
MF Code 11 (SS n° 5 ou KP3P/ST3P (R1)	700+1700	123	tonalité	oui
MF KP (SS n° 5) ou KP1 (R1)	1100+1700	124	tonalité	oui
MF KP2 (SS n° 5) ou KP2P/ST2P (R1)	1300+1700	125	tonalité	oui
MF ST (SS n° 5 et R1) 	1500+1700	126	tonalité	oui
MF Code 12 (SS n° 5) ou KP'/STP (R1)	900+1700	127	tonalité	oui
Signalisation ABCD	N/A	144...159	état	non
Signalisation AB (C, D non utilisés)	N/A	208...211	état	non
Signalisation bit A (B, C, D non utilisés)	N/A	206...207	état	non
Tonalité d'essai de continuité	2000	121	tonalité	oui
Tonalité de vérification de continuité	1780	122	tonalité	oui
Impulsion de mesure	N/A	174	autre	non
Circuit indisponible	N/A	175	autre	non
MFC vers l'avant 1...15	(Tableau 4	176...190	tonalité	oui
MFC vers l'arrière 1...15	(Tableau 5)	191...205	tonalité	oui

Table 1 : Événements de signalisation de circuit

 	2.1	Système de signalisation n° 5
Le système de signalisation n° 5 (SS n° 5) est défini dans les Recommandations UIT-T Q.140 à Q.180 [Q.140]. Il a deux systèmes de signaux : la signalisation de "ligne" pour acquérir et libérer le circuit, la signalisation de "registre" pour passer les chiffres vers l'avant d'un commutateur au suivant.

 	2.1.1	Signaux de ligne du système de signalisation n° 5
La signalisation de ligne n° 5 utilise les tonalités à deux fréquences : 2400 et 2600 Hz. Les tonalités sont utilisées seules pour la plupart de signaux, mais ensemble pour la suppression vers l'avant et la garde de libération. (Cela réduit les chances d'une libération accidentelle d'appel due à la duplication du contenu de support transporté d'une des fréquences.) Le signal spécifique indiqué par une tonalité dépend de l'étape de l'établissement d'appel à laquelle il est appliqué.

Aucun événement n'est défini à l'appui de la signalisation de ligne n° 5. Cependant, les mises en œuvre PEUVENT utiliser les événements de bit AB décrits au paragraphe 2.4 et montrés dans le Tableau 1 pour propager les signaux de ligne du SS n° 5. Si elles le font, elles DOIVENT utiliser les transpositions suivantes. Ces transpositions se fondent sur une transposition sous-jacente qui fait A = 0 en présence d'un signal de 2400 Hz et B = 0 en présence d'un signal de 2600 Hz dans la direction indiquée.

o	2400 et 2600 Hz tous deux présents : code d'événement 208;
o	2400 Hz présent : code d'événement 210;
o	2600 Hz présent : code d'événement 209;
o	aucun des deux signaux n'est présent : code d'événement 211.

Le rapport d'événement initial pour chaque signal DEVRAIT être généré aussitôt que le signal est reconnu, et en tous cas, pas plus tard qu'au moment de reconnaissance indiqué au Tableau 1 de la Recommandation UIT-T Q.141 (c'est-à-dire, 40  ms pour "saisir" et "procéder à l'envoi", 125 ms pour tous les autres signaux). L'intervalle de mise en paquet qui suit le rapport initial DEVRAIT être choisi en considérant comme première priorité une transmission fiable. Noter que le receveur doit fournir ses propres valeurs de volume pour reconvertir ces événements en tonalités. De plus, le receveur PEUT étendre l'exécution de "saisir" jusqu'à ce qu'il ait reçu le premier rapport d'un événement KP (voir ci-dessous) afin d'avoir un meilleur contrôle de l'intervalle entre la fin du signal de saisie et le début de l'exécution de KP.

Le KP doit être envoyé en commençant 80 +/- 20 ms après l'arrêt du signal de "saisie" du SS n° 5.

 	2.1.2	Signaux de registre du système de signalisation n° 5
La signalisation de registre n° 5 utilise des paires de tonalités pour porter les chiffres et les signaux qui les trament. Les combinaisons de tonalités et les signaux correspondants sont montrés au Tableau 2. Tous les signaux sauf KP1 et KP2 sont  envoyés pour une durée de 55 ms. KP1 et KP2 sont envoyés pour une durée de 100 ms. Les pauses entre les signaux sont toujours de 55 ms.

	Fréquence supérieure (Hz)
Fréquence inférieure (Hz)	900	1100	1300	1500	1700
 700	Chiffre 1	Chiffre 2	Chiffre 4	Chiffre 7	Code 11
 900		Chiffre 3	Chiffre 5	Chiffre 8	Code 12
1100			Chiffre 6	Chiffre 9	KP1
1300				Chiffre 0	KP2
1500					ST

Tableau 2 : Signaux de registre du SS n° 5

Les signaux KP sont utilisés pour indiquer le début de la signalisation de chiffres. KP1 indique un appel supposé se terminer dans un réseau national desservi par le commutateur auquel est envoyée la signalisation. KP2 indique un appel supposé transiter par le commutateur auquel la signalisation est envoyée, vers un autre commutateur international. La fin de la signalisation des chiffres est indiquée par le signal ST. Le code 11 ou le code 12 suivant un code de pays (et éventuellement un autre chiffre) indique un appel à diriger sur une position d'opérateur dans le pays de destination. Un code 12 peut être suivi par d'autres chiffres indiquant un opérateur particulier sur lequel l'appel doit être dirigé.

Les mises en œuvre qui utilisent la charge utile Événements de téléphonie pour porter la signalisation de registre SS n° 5 DOIVENT utiliser les événements suivants du Tableau 1 pour porter les signaux de registre montrés au Tableau 2 :
o	code d'événement 123 pour porter le code 11 ;
o	code d'événement 124 pour porter KP1 ;
o	code d'événement 125 pour porter KP2 ;
o	code d'événement 126 pour porter ST ;
o	code d'événement 127 pour porter le code 12.
o	code d'événement 128 pour porter le chiffre 0 ;
o	codes d'événement 129 à 137 pour porter les chiffres 1 à 9, respectivement ;

La mise en œuvre qui envoie DEVRAIT envoyer un rapport d'événement initial pour les signaux KP aussitôt qu'ils sont reconnus, et elle DOIT envoyer un rapport d'événement pour tous ces signaux aussitôt qu'ils sont achevés.

 	2.2	Système de signalisation R1 et MF nord américaine
Le système de signalisation R1 est principalement utilisé en Amérique du Nord, comme l'est sa plus courante variante désignée simplement comme "MF". R1 est défini dans les Recommandations UIT-T Q.310-Q.332 [Q.310], tandis que MF est défini dans [GR-506].

Comme le SS n° 5, R1/MF a des signaux de ligne et de registre. Les signaux de ligne (sans compter Occupé et Réorganisation) sont mis en œuvre sur des circuits analogiques par l'application d'une tonalité de 2600 Hz, et sur les circuits numériques en utilisant la signalisation ABCD. L'interprétation des signaux de ligne dépend de l'état (comme avec le SS n° 5).

 	2.2.1	Signaux de ligne du système de signalisation R1
Conformément au Tableau 1 de Q.311, les mises en œuvre PEUVENT utiliser les événements de bit A décrits au paragraphe 2.4 et montrés au Tableau 1 pour propager les signaux de ligne R1. Si elles font ainsi, elles DOIVENT utiliser les transpositions suivantes. Ces transpositions se fondent sur une transposition sous-jacente qui fait A = 0 en présence d'un signal de 2600 Hz dans la direction indiquée et A = 1 en l'absence de ce signal.
o	2600 Hz présent : code d'événement 206 ;
o	signal non présent : code d'événement 207.

 	2.2.2	Signaux de registre du système de signalisation R1
R1 a une capacité de signal de 15 codes pour les signaux inter registre vers l'avant mais pas les signaux inter registre vers l'arrière. Chaque code ou chiffre est transmis par une paire de tonalités dans un ensemble de 6 fréquences. Le signal de registre R1 consiste en KP, ST, et les chiffres "0" à "9". Les fréquences allouées aux signaux sont montrées au Tableau 3. Noter que ces fréquences sont les mêmes que celles allouées aux signaux de registre de même nom du SS n° 5, sauf que KP utilise la combinaison de fréquences correspondant à KP1 dans le SS n° 5. Le Tableau 3 montre aussi des signaux supplémentaires utilisés en Amérique du Nord : KP', KP2P, KP3P, STP ou ST', ST2P, et ST3P [GR-506].

	Fréquence supérieure (Hz)
Fréquence inférieure (Hz)	900	1100	1300	1500	1700
  700	Chiffre 1	Chiffre 2	Chiffre 4	Chiffre 7	KP3P ou ST3P
  900		Chiffre 3	Chiffre 5	Chiffre 8	KP' ou STP |
1100			Chiffre 6	Chiffre 9	KP
1300				Chiffre 0	KP2P ou ST2P |
1500					ST

Table 3 : Signaux de registre R1/MF

Les mises en œuvre qui utilisent la charge utile Événements de téléphonie pour porter la signalisation de registre R1 d'Amérique du Nord DOIVENT utiliser les événements suivants du Tableau 1 pour porter les signaux de registre montrées au Tableau 3 :
o	code d'événement 123 pour porter KP3P ou ST3P ;
o	code d'événement 124 pour porter KP ;
o	code d'événement 125 pour porter KP2P ou ST2P ;
o	code d'événement 126 pour porter ST ;
o	code d'événement 127 pour porter KP' ou STP.
o	code d'événement 128 pour porter le chiffre 0;
o	codes d'événement 129-137 pour porter les chiffres 1 à 9, respectivement ;

Comme avec les signaux originaux de téléphonie, le receveur interprète les codes 123, 125, et 127 comme des signaux KPx ou STx sur la base de leur position dans la séquence de signalisation.

À la différence du SS n° 5, R1 permet une grande tolérance au temps d'établissement de la signalisation de registre suivant la reconnaissance du signal de ligne de début de numérotation. Cela signifie que les mises en œuvre envoyeuses PEUVENT attendre pour envoyer un rapport d'événement KP jusqu'à l'achèvement du KP.

 	2.3	Système de signalisation R2
Le système de signalisation international R2 est décrit par les Recommandations UIT-T Q.400 à Q.490 [Q.400], mais il y a de nombreuses variantes nationales. Les signaux de ligne R2 sont continus, hors bande, liaison par liaison, et associés au canal. Les signaux de (inter)registre R2 sont multi fréquences, imposés, dans la bande, de bout en bout, et aussi associés au canal.

 	2.3.1	Signaux de ligne du système de signalisation R2
Les signaux de ligne R2 peuvent être analogiques, un chiffre utilisant le bit A dans le seizième canal, ou un chiffre utilisant les deux bits A et B. Les mises en œuvre PEUVENT utiliser les événements de bit A ou AB décrits au paragraphe 2.4 et montrés au Tableau 1 pour propager ces signaux. Si elles le font, elles DOIVENT utiliser les transpositions suivantes :

1.	Pour les signaux de ligne analogique R2 montrés au Tableau 1 de la Recommandation UIT-T Q.411, les mises en œuvre DOIVENT transposer comme suit. Cette transposition se fonde sur une transposition sous-jacente du bit A = 0 quand la tonalité est présente.
* Le code d'événement 206 (Tableau 1) est utilisé pour indiquer la condition de Q.411 "tonalité activée" ;
* Le code d'événement 207 (Tableau 1) est utilisé pour indiquer la condition de Q.411 "tonalité désactivée".

2.	Les signaux de ligne R2 numériques, comme décrits par la Recommandation UIT-T Q.421, sont portés sur deux bits, A et B. La transposition entre les valeurs de bits A et B et les codes d'événement DEVRA être la même dans les deux directions et DEVRA suivre les principes de transposition des bits A et B spécifiés au paragraphe 2.4.

 	2.3.2	Signaux de registre du système de signalisation R2
Dans la signalisation R2, la séquence de signalisation est initiée à partir de l'échange sortant par l'envoi d'un signal de "saisie" de ligne. Après le signal de "saisie" de ligne (et le signal "accusé de réception de saisie" dans R2D) la séquence de signalisation continue en utilisant des signaux de registre multi fréquences. La Recommandation UIT-T Q.441 classe les signaux de registre multi fréquences vers l'avant (fréquences supérieures) en groupes I et II, les signaux de registre multi fréquences vers l'arrière (fréquences inférieures) dans les groupes A et B. Ces groupes ont une signification par rapport au type d'informations qu'ils portent et où elles peuvent se produire dans la séquence de signalisation.

Les tonalités utilisées dans la signalisation de registre R2 sont des combinaisons de deux fréquences parmi six. Les versions nationales peuvent être réduites à 10 signaux (deux fréquences parmi cinq) ou 6 signaux (deux fréquences parmi quatre).

La signalisation de registre R2 est un protocole de signalisation de tonalité contrainte, ce qui signifie qu'une tonalité est exécutée jusqu'à la réception d'un "accusé de réception ou d'une directive pour la prochaine tonalité" qui indique que la tonalité d'origine devrait cesser. Un signal de registre R2 vers l'avant est acquitté par un signal vers l'arrière. Un signal vers l'arrière est acquitté par la fin du signal vers l'avant. Dans des circonstances exceptionnelles spécifiées dans la Recommandation UIT-T Q.442, l'entité en aval peut envoyer des signaux vers l'arrière autonomes plutôt qu'en réponse à des signaux vers l'avant spécifiques.

Dans la signalisation R2, la séquence de signalisation est initiée à partir de l'échange sortant par l'envoi d'un signal de groupe I vers l'avant. Le premier signal vers l'avant est normalement le premier chiffre du numéro appelé. L'échange entrant répond normalement par un groupe A-1 vers l'arrière qui indique à l'échange sortant d'envoyer le chiffre suivant du numéro demandé.

Les tonalités ont une signification ; cependant, cette signification varie selon l'endroit où la tonalité se produit dans la signalisation. La signification peut aussi dépendre du pays. Donc, pour éviter un nombre d'événements non gérable, le présent document fournit simplement des moyens pour indiquer les 15 tonalités R2 MF vers l'avant et les 15 tonalités MF R2 vers l'arrière (c'est-à-dire, en utilisant les codes d'événement 176 à 190 et 191 à 205, respectivement, comme le montre le Tableau 1). Les paires de fréquences pour ces tonalités sont montrées dans les Tableaux 4 et 5.

Noter qu'une stratégie naïve pour le relais vers l'avant des signaux inter registre R2 peut résulter en des temps d'établissement d'appel d'un durée inacceptable, et des fins de temporisation quand l'appel passe à travers plusieurs commutateurs ainsi qu'une passerelle avant de se terminer. Plusieurs stratégies sont disponibles pour accélérer le transfert des informations de signalisation à travers un certain point de relais. Dans le pire des cas, le point de relais doit agir comme un commutateur, terminant la signalisation d'un côté et régénérant l'appel de l'autre côté.

	Fréquence supérieure (Hz)
Fréquence inférieure (Hz)	1500	1620	1740	1860	1980
1380	avt 1	avt 2	avt 4	avt 7	avt 11
1500		avt 3	avt 5	avt 8	avt 12
1620			avt 6	avt 9	avt 13
1740				avt 10	avt 14
1860					avt 15

Table 4 : Signaux de registre R2 vers l'avant

	Fréquence supérieure (Hz)
Fréquence inférieure (Hz)	1140	1020	900	780	660
1020	Arrière 1
  900	Arrière 2	Arrière 3
  780	Arrière 4	Arrière 5	Arrière 6
  660	Arrière 7	Arrière 8	Arrière 9	Arrière 10
  540	Arrière 11	Arrière 12	Arrière 13	Arrière 14	Arrière 15

Table 5 : Signaux de registre R2 vers l'arrière

 	2.4	Signalisation ABCD transitoire pour circuits numériques
ABCD est système de signalisation de quatre bits utilisé par les circuits numériques, où A, B, C, et D sont les désignations des bits individuels. La signalisation peut être à 16 états (les quatre bits sont tous utilisés) à 4 états (les bits A et B sont utilisés) ou à 2 états (seul le bit A est utilisé). Les événements de signalisation ABCD sont tous des états mutuellement exclusifs. La plus récente transition d'état détermine l'état en cours.

Quand on utilise le tramage T1 de super trame étendue (ESF, Extended Super Frame) les informations de signalisation sont envoyées comme des bits volés dans les trames 6, 12, 18, et 24. Une super trame D4 transmet seulement une signalisation à  4 états avec les bits A et B. Sur la trame E1 de la conférence européenne des postes et télécommunications (CEPT) toutes la signalisation est portée dans l'intervalle de temps 16, et deux canaux de signalisation à 16 états (ABCD) sont envoyés par trame. La Recommandation UIT-T G.704 [G.704] donne les détails du placement des bits ABCD dans les divers arrangements de tramage.

La signification des signaux ABCD varie avec l'application. Un exemple de spécification de codes de signalisation ABCD est celui de [T1.403.02], qui reflète la pratique nord américaine de signalisation de "boucle" par opposition à la signalisation de circuit discutée dans les paragraphes précédents.

Comme les informations ABCD sont 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é à l'Annexe L de la Recommandation UIT-T [I.366.2]. 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, cela se continue alors. Après une période de non changement, les informations ABCD sont envoyées toutes les 5 secondes.

Comme le montre le Tableau 1, les 16 états possibles sont représentés respectivement par les codes d'événement 144 à 159. Les mises à jour qui utilisent ces codes d'événement DOIVENT les transposer en informations ABCD sur la base des principes suivants :

1.	Les numéros d'état sont déduits du sous ensemble de bits ABCD utilisé en les traitant comme un seul nombre binaire, où le bit A est le bit de poids fort.

2. 	Les numéros d'état se transposent en codes d'événement par ordre de valeur croissante (c'est-à-dire que le numéro d'état 0 se transpose en le code d'événement 144, ..., le numéro d'état 15 se transpose en le code d'événement 159).

Si seuls les bits A et B sont utilisés, alors la transposition en codes d'événement devra être la suivante :
o	A = 0, B = 0 se transpose en le code d'événement 208 ;
o	A = 0, B = 1 se transpose en le code d'événement 209 ;
o	A = 1, B = 0 se transpose en le code d'événement 210 ;
o	A = 1, B = 1 se transpose en le code d'événement 211 ;

Finalement, si seul le bit A est utilisé,
o	A = 0 se transpose en le code d'événement 206 ;
o	A = 1 se transpose en le code d'événement 207.

Des codes d'événement distincts sont alloués à la signalisation de bit A et à la signalisation de bit AB parce que, comme indiqué dans la Recommandation UIT-T [G.704], quand les bits B, C, et D ne sont pas utilisés, leurs valeurs par défaut diffèrent selon le système de transmission. En spécifiant des codes pour les seuls bits utilisés, le présent mémoire permet à la passerelle de réception de compléter les bits restants en accord avec sa configuration locale.

 	2.5	Tonalités de continuité
Les tonalités de continuité sont utilisées pour les épreuves de continuité de circuit durant l'établissement de l'appel. Deux procédures de base sont utilisées. Dans la pratique internationale, la clause 7 de la Recommandation UIT-T [Q.724] décrit la procédure applicable aux circuits de jonction à quatre fils, où une seule tonalité d'essai de 2000 +/- 20 Hz est transmise depuis le commutateur téléphonique initiateur. Le commutateur distant établit une boucle de retour, et l'épreuve de continuité réussit si le commutateur d'envoi peut détecter la tonalité sur le chemin de retour. La clause 8 de Q.724 décrit la procédure pour les circuits de jonction à deux fils. La procédure à deux fils implique deux tonalités : une tonalité de 2000  Hz envoyée dans la direction avant et une tonalité de 1780 +/- 20 Hz envoyée en réponse.

Noter que les mises en œuvre envoient souvent une tonalité d'épreuve légèrement différente, par exemple, 2010 Hz, à cause de certaines propriétés indésirables du 2000 Hz.

Si les mises en œuvre utilisent le type de charge utile Événements de téléphonie pour propager les tonalités d'épreuve de continuité, elles DOIVENT transposer ces tonalités en codes d'événement comme suit :
o	Pour l'épreuve de continuité à quatre fils, la tonalité d'épreuve de 2000 Hz est transposée en le code d'événement 121.
o	Pour l'épreuve de continuité à deux fils, la tonalité initiale de 2000 Hz d'essais est transposée en le code d'événement 121. La tonalité de vérification de continuité de 1780 Hz est transposée en le code d'événement 122.

 	2.6	Événement Circuit indisponible
Cet événement indique que le circuit n'est pas disponible pour le service. La longueur du temps d'arrêt de système est indiquée dans le champ Durée. Le champ Durée est réglé à une valeur qui permet une granularité adéquate pour décrire le temps  d'arrêt de système. Une valeur de 1 seconde est RECOMMANDÉE. Quand le circuit devient indisponible, cet événement est envoyé avec le même horodatage trois fois à un intervalle de 20 ms. Si le circuit persiste dans l'état indisponible à la fin de la durée indiquée, l'événement est alors retransmis, de préférence avec le même schéma de redondance.

L'indisponibilité du circuit pourrait résulter d'une défaillance ou d'une action administrative. Cet événement est utilisé de façon sans état pour synchroniser l'indisponibilité de circuit entre les équipements connectés par des circuits provisionnés par RTP. Cela évite une consommation inutile de bande passante en envoyant un flux continu de paquets RTP avec une charge utile fixe pendant la durée du temps d'arrêt du système, comme ce serait exigé dans certaines applications fondées sur E1. Dans les applications fondées sur T1, le conditionnement de circuits via les événements ABCD transitoires peut être utilisé à la place.

 	2.7	Événement Impulsion de mesure
L'événement Impulsion de mesure peut être utilisé pour transmettre des impulsions de mesure à des fins de facturation. Pour des informations sur ses fondements, une référence possible est http://www.seg.co.uk/telecomm/automat3.htm. Comme l'impulsion de mesure est un événement discret, chaque rapport d'événement d'impulsion de mesure DOIT avoir les deux bits 'M' et 'E' établis. L'impulsion de mesure est normalement transmise par des moyens hors bande pendant que la conversation est en cours. Les envoyeurs DOIVENT donc être prêts à transmettre à la fois les types de charge utile Événement de téléphonie et audio simultanément. Les événements d'impulsion de mesure DOIVENT être retransmis comme recommandé au paragraphe 2.5.1.4 de la [RFC4733]. Il est RECOMMANDÉ que l'intervalle de retransmission soit de moins de 50 ms et le taux d'impulsion de pas moins que le taux de mise en paquet audio.

 	3.	Considérations d'encombrement

La capacité de s'adapter à l'encombrement varie selon le système de signalisation utilisé et aussi les chiffres diffèrent entre les signaux de ligne et de registre.

Avec l'exception spécifique de la signalisation de registre pour le S.S.n° 5 et R1/MF, les signaux décrits dans le présent document sont très tolérants aux allongements de durées, si celles-ci devaient être nécessaires. Donc, dans des conditions d'encombrement, l'envoyeur peut s'adapter en rallongeant l'intervalle de rapport pour les tonalités concernées. À l'extrémité de réception, si une tonalité est exécutée et si une insuffisance de données se produit à cause de paquets retardés ou perdus, il vaut mieux continuer d'exécuter la tonalité jusqu'à ce qu'arrive le prochain paquet. L'interruption prématurée d'une tonalité, avec ou sans reprise, peut causer l'échec de la tentative d'établissement d'appel, tandis qu'une extension d'exécution augmente juste le temps d'établissement de l'appel.

La signalisation de registre pour le S.S. n° 5 et R1/MF est soumise à des contraintes de temps. Les périodes de signaux de tonalité et de silence entre eux ont des durées spécifiées et des tolérances de l'ordre de 5 à 10 ms. Les durées des tonalités individuelles sont de l'ordre de deux à trois intervalles de mise en paquet (55/68 ms, avec le KP initial qui dure 100 ms). L'exigence critique pour la transmission des charge utiles Événement de téléphonie est que le receveur sache quel signal exécuter à un moment donné. Il est moins important que le receveur reçoive à temps une notification de la fin de chaque tonalité. Il devrait plutôt exécuter la séquence avec les durées spécifiées dans la norme de signalisation plutôt que les durées réelles rapportées.

Ces considérations suggèrent qu'aussitôt qu'un signal de registre a été identifié de façon fiable, l'envoyeur devrait émettre un rapport de cette tonalité. Il devrait ensuite fournir une mise à jour dans les 5 ms pour la fiabilité et pas plus de mises à jour jusqu'au rapport de la fin de la tonalité.

Augmenter la mémoire tampon d'exécution chez le receveur durant la signalisation de registre ne va pas accroître la fiabilité. Cela doit être mis en balance avec l'augmentation impliquée pour le temps d'établissement de l'appel.

 	4.	Considérations sur la sécurité

Les événements pour lesquels les codes d'événement sont fournis dans ce document se rapportent directement à l'établissement, la facturation, et la fin des appels téléphoniques. À ce titre, ils sont soumis, en utilisant la terminologie de la [RFC3552], aux menaces sur les communications et la sécurité du système. Les attaques concernées sont :
o	les violations de la confidentialité (surveillance des numéros appelants et appelés) ;
o	l'établissement de connexions téléphoniques non autorisées par insertion de message ;
o	la capture des connexions téléphoniques par insertion de message ou la modification des messages par interposition ;
o	le déni de service aux appels téléphoniques individuels par insertion, modification, suppression ou retard de message.

Ces attaques peuvent être empêchées par l'utilisation de la protection appropriée de la confidentialité, l'authentification, ou la protection de l'intégrité. Si la protection de la confidentialité, de l'intégrité ou l'authentification sont nécessaires, le protocole de transport sécurisé en temps réel (SRTP, Secure Real-time Transport Protocol) [RFC3711] DEVRAIT être utilisé avec la gestion de clés automatique.

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

 	5.	Considérations relatives à l'IANA

Le présent document définit les codes d'événement montrés au Tableau 6. Ces événements s'ajoutent au registre des événements de téléphonie établi par la [RFC4733]. La référence de tous ces événements est le présent document.

Code d'événement	Nom d'événement	Référence
121	Tonalité d'essai de continuité	[RFC5244]
122	Tonalité de vérification de continuité	[RFC5244]
123	MF Code 11 (SS n° 5) ou KP3P/ST3P (R1)	[RFC5244]
124	MF KP (SS n° 5) ou KP1 (R1)	[RFC5244]
125	MF KP2 (SS n° 5) ou KP2P/ST2P (R1)	[RFC5244]
126	MF ST (SS n° 5 et R1)	[RFC5244]
127	MF Code 12 (SS n° 5) ou KP'/STP (R1)	[RFC5244]
128	Chiffre SS n° 5 ou R1 "0"	[RFC5244]
129	Chiffre SS n° 5 ou R1 "1"	[RFC5244]
130	Chiffre SS n° 5 ou R1 "2"	[RFC5244]
131	Chiffre SS n° 5 ou R1 "3"	[RFC5244]
132	Chiffre SS n° 5 ou R1 "4"	[RFC5244]
133	Chiffre SS n° 5 ou R1 "5"	[RFC5244]
134	Chiffre SS n° 5 ou R1 "6"	[RFC5244]
135	Chiffre SS n° 5 ou R1 "7"	[RFC5244]
136	Chiffre SS n° 5 ou R1 "8"	[RFC5244]
137	Chiffre SS n° 5 ou R1 "9"	[RFC5244]
144	État de signalisation ABCD '0000'	[RFC5244]
145	État de signalisation ABCD '0001'	[RFC5244]
146	État de signalisation ABCD '0010'	[RFC5244]
147	État de signalisation ABCD '0011'	[RFC5244]
148	État de signalisation ABCD '0100'	[RFC5244]
149	État de signalisation ABCD '0101'	[RFC5244]
150	État de signalisation ABCD '0110'	[RFC5244]
151	État de signalisation ABCD '0111'	[RFC5244]
152	État de signalisation ABCD '1000'	[RFC5244]
153	État de signalisation ABCD '1001'	[RFC5244]
154	État de signalisation ABCD '1010'	[RFC5244]
155	État de signalisation ABCD '1011'	[RFC5244]
156	État de signalisation ABCD '1100'	[RFC5244]
157	État de signalisation ABCD '1101'	[RFC5244]
158	État de signalisation ABCD '1110'	[RFC5244]
159	État de signalisation ABCD '1111'	[RFC5244]
174	Impulsion de mesure	[RFC5244]
175	Circuit indisponible	[RFC5244]
176	Signal MFC vers l'avant 1	[RFC5244]
177	Signal MFC vers l'avant 2	[RFC5244]
178	Signal MFC vers l'avant 3	[RFC5244]
179	Signal MFC vers l'avant 4	[RFC5244]
180	Signal MFC vers l'avant 5	[RFC5244]
181	Signal MFC vers l'avant 6	[RFC5244]
182	Signal MFC vers l'avant 7	[RFC5244]
183	Signal MFC vers l'avant 8	[RFC5244]
184	Signal MFC vers l'avant 9	[RFC5244]
185	Signal MFC vers l'avant 10	[RFC5244]
186	Signal MFC vers l'avant 11	[RFC5244]
187	Signal MFC vers l'avant 12	[RFC5244]
188	Signal MFC vers l'avant 13	[RFC5244]
189	Signal MFC vers l'avant 14	[RFC5244]
190	Signal MFC vers l'avant 15	[RFC5244]
191	Signal MFC vers l'arrière 1	[RFC5244]
192	Signal MFC vers l'arrière 2	[RFC5244]
193	Signal MFC vers l'arrière 3	[RFC5244]
194	Signal MFC vers l'arrière 4	[RFC5244]
195	Signal MFC vers l'arrière 5	[RFC5244]
196	Signal MFC vers l'arrière 6	[RFC5244]
197	Signal MFC vers l'arrière 7	[RFC5244]
198	Signal MFC vers l'arrière 8	[RFC5244]
199	Signal MFC vers l'arrière 9	[RFC5244]
200	Signal MFC vers l'arrière 10	[RFC5244]
201	Signal MFC vers l'arrière 11	[RFC5244]
202	Signal MFC vers l'arrière 12	[RFC5244]
203	Signal MFC vers l'arrière 13	[RFC5244]
204	Signal MFC vers l'arrière 14	[RFC5244]
205	Signal MFC vers l'arrière 15	[RFC5244]
206	État de signalisation de bit A '0'	[RFC5244]
207	État de signalisation de bit A '1'	[RFC5244]
208	État de signalisation de bit AB '00'	[RFC5244]
209	État de signalisation de bit AB '01'	[RFC5244]
210	État de signalisation de bit AB '10'	[RFC5244]
211	État de signalisation de bit AB '11'	[RFC5244]

Tableau 6 : Événements de signalisation en mode canal dans le registre des codes d'événements Audio/Événement de téléphonie

 	6.	Remerciements

La liste complète des remerciements pour les contributions au développement et la révision de la RFC 2833 est contenue dans la [RFC4733]. L'éditeur estime ou est certain que les personnes suivantes ont contribué spécifiquement au présent document : Flemming Andreasen, Rex Coldren, Bill Foster, Alfred Hoenes, Rajesh Kumar, Aleksandar Lebl, Zarko Markov, Oren Peleg, Moshe Samoha, Adrian Soncodi, et Yaakov Stein. Steve Norreys et Roni Even ont fourni d'utiles commentaires après leur relecture.

 	7.	Références
 	7.1	Références normatives

[G.704]	Recommandation UIT-T G.704, "Structures de trame synchrones utilisées aux niveaux hiérarchiques 1544, 6312, 2048, 8448 et 44 736 kbit/s". (10/1998)

[GR-506]	Telcordia Technologies, "LSSGR: signalling for Analog Interfaces", Generic Requirement GR-506, juin 1996.

[Q.140]	Recommandation UIT-T Q.140, "Spécifications pour le système de signalisation n° 5", UIT-T, Genève, novembre  1988.

[Q.310]	Recommandation UIT-T Q.310, "Spécifications du système de signalisation R1", UIT-T, Genève, novembre  1988.

[Q.400]	Recommandations UIT-T Q.400 à 490, "Spécifications du système de signalisation R2", UIT-T, Genève, novembre  1988.

[Q.724]	Recommandation UIT-T Q.724, "Procédures de signalisation pour la partie Utilisateur de téléphonie", UIT-T, Genève, novembre  1988.

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

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

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

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

 	7.2	Références pour information

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

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

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

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

[T1.403.02]	American National Standard for Telecommunications T1.403.02-1999, "Network and Customer Installation Interfaces -- DS1 Robbed-Bit signalling State Definitions", ANSI/T1, mai 1999.

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

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

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

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

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

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

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

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