Groupe de travail Réseau	N. Greene, Nortel Networks
Request for Comments : 2805	M. Ramalho, Cisco Systems
Catégorie : Information	B. Rosen, Marconi
Traduction Claude Brière de L'Isle	avril 2000

Architecture et exigences du 
protocole de contrôle de passerelle de supports

Statut de ce mémoire
Le présent mémoire apporte des informations pour la communauté de l'Internet. Le présent mémoire ne spécifie aucune sorte de norme de l'Internet. La distribution du présent mémoire n'est soumise à aucune restriction.

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

Résumé
Le présent document décrit les exigences du protocole pour le protocole de contrôle de passerelle de supports (MGCP, Media Gateway Control Protocol) entre un contrôleur de passerelle de supports et une passerelle de supports.
Table des matières
1. Introduction	2
2. Terminologie	2
3. Définitions	2
4. Fonctions spécifiques supposées au sein de la MG	3
5. Exigences par appel	4
5.1 Réservation de ressource	4
5.2 Exigences de connexion	4
5.3 Transformations de support	4
5.4 Traitement et inscription de signal/événement	5
5.5 QS/CS	6
5.6 Prise en charge des essais	6
5.7 Comptabilité	6
5.8 Contrôle de signalisation	6
6. Contrôle de ressource 	7
6.1 Gestion d'état de ressource	7
6.2 Allocation de ressource	7
7. Exigences de fonctionnement/gestion	8
7.1 Assurance de contrôle/connexité	8
7.2 Contrôle d'erreurs	8
7.3 Exigences de MIB	8
8. Exigences générales du protocole	9
8.1 Exigences d'association MG-MGC	9
8.2 Exigences de performances	10
9. Transport	10
9.1 Hypothèses sur le réseau sous-jacent	10
9.2 Exigences de transport	10
10. Exigences de sécurité	10
11. Exigences spécifiques de types de support particuliers	11
11.1 Types de porteuse spécifiques du support	11
11.2 Exigences spécifiques de l'application	15
12. Références	23
13. Remerciements	23
14. Adresse des auteurs	24
15. Déclaration complète de droits de reproduction	24

 	1.	Introduction

Le présent document décrit les exigences pour le protocole de contrôle de passerelle de supports. Quand le mot protocole est utilisé seul dans le présent document, il signifie implicitement le protocole de contrôle de passerelle de supports.

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

 	3.	Définitions

Circuit : connexion analogique ou numérique provenant d'un commutateur de circuits qui porte un contenu de support d'utilisateur et peut porter la signalisation téléphonique (MF, R2, etc.). Les circuits numériques peuvent être transportés et peuvent apparaître à la passerelle de supports comme des canaux au sein d'un flux binaire tramé, ou comme un flux de cellules ATM. Les circuits sont normalement provisionnés en groupes, dont chaque membre fournit un acheminement et service équivalent.

Connexion : sous le contrôle d'un contrôleur de passerelle de supports (MGC, Media Gateway Controller) la passerelle de supports (MG, Media Gateway) réalise des connexions. Dans le présent document, les connexions sont des associations de ressources hébergées par la MG. Elles impliquent normalement deux terminaisons, mais peuvent en impliquer plus.

Fonction de contrôleur de passerelle de supports (MG, Media Gateway Controller) : elle contrôle une passerelle de supports.

Fonction de passerelle de supports (MG, Media Gateway) : elle fournit la transposition de supports et/ou la fonction de transcodage entre des réseaux potentiellement dissemblables, dont un est présumé être un réseau de paquets, trames ou cellules. Par exemple, une MG pourrait terminer des facilités (jonctions, boucle locale) d'un réseau de commutation de circuits (SCN, switched circuit network) mettre en paquets les flux de supports, si ils ne le sont pas déjà, et livrer le trafic de paquets à un réseau de paquets. Elle effectuerait ces fonctions dans l'ordre inverse pour les flux de supports s'écoulant du réseau de paquet vers le SCN. Les passerelles de supports ne se limitent pas aux fonctions de SCN <-> paquet/trame/cellule : un pont de conférence avec toutes les interfaces de paquets pourrait être une MG, ainsi qu'une unité de reconnaissance vocale interactive (IVR, interactive voice recognition unit) une fonction de ressource audio, ou un système de reconnaissance vocale avec une interface de cellule.

Fonction de passerelle de signalisation (SG, Signaling Gateway) : une fonction de SG reçoit/envoie la signalisation native de SCN à la bordure d'un réseau de données. Par exemple, la fonction de SG peut relayer, traduire ou terminer la signalisation SS7 dans une passerelle SS7-Internet. La fonction de SG peut aussi être co-résidente avec la fonction de MG pour traiter la signalisation de SCN associée aux terminaisons de ligne ou de circuit contrôlées par la MG, comme le canal "D" d'un circuit PRI RNIS.

Ligne ou boucle : connexion d'accès analogique ou numérique à partir d'un terminal d'utilisateur qui porte un contenu de support d'utilisateur et une signalisation d'accès téléphonique (DP, DTMF, BRI, ensemble commercial propriétaire).

Ressource de support : des exemples de ressources de supports sont des codecs, des annonces, des tonalités, et des modems, des unités de réponse vocale interactives (IVR) des ponts, etc.

Terminaison : une terminaison est un point d'entrée et/ou sortie de flux de supports par rapport à la MG. Quand il est demandé à une MG de connecter deux terminaisons ou plus, elle comprend comment les flux entrant et sortant de chaque terminaison sont en relations les uns avec les autres. Les terminaisons sont, par exemple, des accès de DS0, de VC ATM et RTP. Un autre terme pour cela est point de porteur.

Type de support : une définition de type de support donne les exigences détaillées pour son type particulier d'application/porteur. Une classe particulière de passerelle de supports, par exemple, va prendre en charge un ensemble particulier de types de porteur.

Unité de passerelle de supports : c'est une entité physique qui contient une fonction de MG et peut aussi contenir d'autres fonctions, par exemple une fonction de passerelle de signalisation.

 	4.	Fonctions spécifiques supposées au sein de la MG

Cette Section donne un environnement pour la définition des exigences générales du protocole de contrôle de passerelle de supports.

L'architecture des MG peut être très différente selon l'endroit où la conversion et le transcodage des supports (si il est nécessaire) sont effectués, le niveau de possibilité de programmation des ressources, comment les conférences sont prises en charge, et comment est traitée la signalisation associée. Les fonctions assumées au sein de la MG ne doivent pas être biaisées par une architecture particulière.

Par exemple, les annonces dans une MG pourraient être fournies par des ressources de supports ou par la ressource de point de porteur ou la terminaison elle-même. De plus, cette différence ne doit pas être visible au MGC : le MGC doit être capable de produire une demande identique à deux mises en œuvre différentes et de réaliser une fonction identique.

Selon l'application de la MG (par exemple, transit, résidentiel) certaines fonctions mentionnées ci-dessous vont être plus proéminentes que d'autres, et dans certains cas, des fonctions peuvent même disparaître.

Bien que l'adaptation des supports soit l'essence de la MG, il n'est pas nécessaire qu'elle soit impliquée à chaque fois. Une MG peut joindre deux terminaisons/ressources du même type (c'est-à-dire, la MG se comporte comme un commutateur). La conversion de supports requise dépend du type de supports pris en charge par les ressources jointes.

En plus de la fonction d'adaptation des supports, les ressources ont un certain nombre de propriétés uniques, par exemple :
*	certains types de ressources ont des capacités de signalisation associées (par exemple, PRI, DTMF)
*	certaines ressources effectuent des fonctions de maintenance (par exemple, essais de continuité)
*	le MGC doit connaître les changements d'état des ressources (par exemple, un groupe de circuits retirés du service)
*	la MG conserve un certain contrôle sur l'allocation et le contrôle de certaines ressources (par exemple, espace de nom de ressources, numéros d'accès RTP).

Donc, une MG réalise des connexions et conférences en point à point, et prend en charge plusieurs fonctions de ressources. Ces fonctions incluent la conversion des supports, l'allocation et la gestion des ressources, et les notifications d'événements.  Le traitement de la signalisation associée aux terminaisons est effectué soit en utilisant des notifications d'événements, soit par la partie transport arrière de signalisation d'une unité de MG (c'est-à-dire NON directement traitée par la MG).

Les MG doivent aussi prendre en charge un certain niveau de fonctions relatives au système, comme d'établir et maintenir une certaine forme d'association MG-MGC. C'est essentiel pour la redondance de MGC, la récupération sur défaillance, et le partage de ressources.

Donc, une MG est supposée contenir les fonctions de :
*	réservation et libération de ressources,
*	capacité de fournir l'état des ressources,
*	maintenance des ressources - il doit être possible de faire des opérations de maintenance indépendantes des autres fonctions de terminaison, par exemple, des états de maintenance ne devraient pas affecter les ressources associées à cette ressource. Des exemples de fonctions de maintenance sont les essais de rebouclage et de continuité.
*	gestion de connexion, incluant l'état de connexion,
*	traitement des supports, en utilisant les ressources des supports : cela fournit des services comme le transcodage, les conférences, les unités de reconnaissance vocale interactive, les unités de fonction de ressource audio ; les ressources de supports peuvent ou non faire directement partie d'autres ressources ;
*	analyse des chiffres entrants pour les terminaisons, interprétation des scripts pour les terminaisons ;
*	détection d'événement et insertion de signal pour la signalisation par canal ;
*	capacité de configurer des transports arrières de signalisation (par exemple, un transport arrière Sigtran)
*	gestion de l'association entre le MGC et la MG, ou entre le MGC et les ressources de MG.

 	5.	Exigences par appel
 	5.1	Réservation de ressource
Le protocole doit :
a.	Prendre en charge la réservation des ressources de terminaisons de porteur et de supports à utiliser par un certain appel ainsi que leur libération ultérieure (qui peut être implicite ou explicite).
b.	Permettre la libération dans un seul échange de messages, de toutes les ressources associées à un ensemble particulier de connexions et/ou associations entre un certain nombre de terminaisons.
c.	La MG n'est pas obligée (ni admise) par le protocole de maintenir un sens futur : une réservation reste en vigueur jusqu'à ce qu'elle soit explicitement libérée par le MGC.

 	5.2	Exigences de connexion
Le protocole doit 
a.	Prendre en charge les connexions impliquant des terminaisons de porteuses de paquets et de circuits dans toutes combinaisons, incluant des connexions en "épingle à cheveux" (connexions entre deux connexions de circuits au sein de la même MG).
b.	Prendre en charge des connexions impliquant un transport TDM, analogique, ATM, IP ou FR dans toutes combinaisons.
c.	Permettre la spécification de plan de porteuse (par exemple relais de trame, IP, etc.) appel par appel.
d.	Prendre en charge des flux de supports unidirectionnels, bidirectionnels symétriques, et bidirectionnels asymétriques.
e.	Prendre en charge plusieurs types de supports (par exemple audio, texte, vidéo, T.120).
f.	Prendre en charge des connexions point à point et point à multipoints.
g.	Prendre en charge la création et la modification de topologies de flux plus complexes, par exemple, capacité de pont de conférence, être capable d'ajouter ou supprimer des flux de supports durant un appel ou une session, et être capable d'ajouter ou supprimer des participants à un appel ou session.
h.	Prendre en charge l'inclusion de ressources de supports dans un appel ou session comme nécessaire. Selon le type de protocole et de ressource, les ressources de supports peuvent être implicitement incluses, allouées à une classe, ou allouées individuellement.
i.	Fournir une spécification non ambiguë des flux de supports qui passent à travers un point et de ceux qui sont bloqués à un certain moment, si le protocole permet que plusieurs flux passent à travers le même point.
j.	Permettre des modifications d'une terminaison existante, par exemple, l'utilisation d'une compression plus forte pour compenser une insuffisance de bande passante ou pour changer les connexions du réseau de transport.
k.	Permettre au MGC de spécifier qu'une certaine connexion a une priorité supérieure à celle d'autres.
l.	Permettre qu'une référence à une terminaison d'accès sur la MG soit un identifiant logique, avec une transposition biunivoque entre un identifiant logique et un accès physique.
m.	Permettre à la MG de faire rapport d'événements tels qu'une réservation de ressource et l'achèvement d'une connexion.

 	5.3	Transformations de support
Le protocole doit :
a.	Prendre en charge la médiation/adaptation des flux entre différents types de transport.
b.	Prendre en charge l'invocation de traitements supplémentaires tels que l'annulation d'écho.
c.	Prendre en charge la médiation des flux entre différents codages de contenu (codecs, chiffrement/déchiffrement)
d.	Permettre au MGC de spécifier si le trafic de modem de texte téléphoné/télécopie/données est à terminer à la MG, modulé/démodulé, et converti en paquets ou transmis par la MG dans le flux de supports comme trafic en bande vocale.
e.	Permettre au MGC de spécifier que les chiffres de bi-tonalité multi fréquence (DTMF, Dual-Tone MultiFrequency) ou autres signaux de ligne et de circuits et des tonalités multi fréquences (MF) générales sont à traiter dans la MG et comment ces chiffres/signaux/tonalités sont à traiter. Le MGC doit être capable de spécifier tous les traitements suivants de ces chiffres/signaux/tonalités :
1.	Les chiffres/signaux/tonalités sont à coder normalement dans le flux audio RTP (par exemple, pas d'analyse des chiffres/signaux/tonalités).
2.	Analysés et envoyés au MGC.
3.	Reçus du MGC et insérés dans le flux audio côté ligne.
4.	Analysés et envoyés au titre d'un flux RTP distinct (par exemple, chiffres DTMF envoyés via une charge utile RTP séparée du flux audio RTP).
5.	Pris d'un flux RTP distinct et insérés dans le flux audio côté ligne.
6.	Traités selon un descriptif d'instructions.
Pour tous les cas sauf le premier, l'option d'assourdir les chiffres/signaux/tonalités avec du silence, un bruit de fond, ou d'autres moyens (par exemple, filtrage coupe bande de certaines tonalités téléphoniques) doit être fournie. Comme la détection de ces événements peut prendre jusqu'à plusieurs dizaines de millisecondes, les premières millisecondes de tels chiffres/signaux/tonalités peuvent être codées et envoyées dans le flux audio RTP avant que les chiffres/signaux/tonalités puissent être vérifiés. Donc assourdir de tels chiffres/signaux/tonalités dans le flux audio RTP avec du silence ou du bruit de fond est compris comme se produisant à la première opportunité après la vérification des chiffres/signaux/tonalités.
f.	Permettre au MGC de spécifier les caractéristiques des flux signalés sur les circuits ainsi que sur les connexions de porteuse de paquets, par exemple loi µ/a.
g.	Permettre l'adaptation de transport de paquet/cellules seulement (pas d'adaptation de supports) par exemple mise en paquet/transcodage de mi-flux (de paquet à paquet) ou adaptation ATM AAL5 de et vers ATM AAL2.
h.	Permettre le transport de niveaux de normalisation audio comme paramètres d'établissement, par exemple, pour des ponts de conférence.
i.	Permettre qu'ait lieu une conversion entre des types de supports, par exemple, de texte en parole et de parole en texte.

 	5.4	Traitement et inscription de signal/événement
Le protocole doit :
a.	Permettre au MGC d'activer/désactiver la surveillance d'événements de supervision spécifiques sur des terminaisons de circuit spécifiques.
b.	Permettre au MGC d'activer/désactiver la surveillance d'événements spécifiques sur des flux de supports spécifiés.
c.	Permettre le rapport d'événements détectés sur la MG au MGC. Le protocole devrait fournir le moyen de minimiser le nombre de messages requis pour rapporter les séquences d'événements qui se produisent couramment.
d.	Permettre au MGC de spécifier d'autres actions (en dehors du rapport) que la MG devrait effectuer à la détection d'événements spécifiés.
e.	Permettre au MGC de permettre et/ou masquer des événements.
f.	Fournir un moyen au MGC d'accuser positivement réception des notifications d'événements.
g.	Permettre au MGC de spécifier des signaux (par exemple, de supervision, de sonnerie) à appliquer aux terminaisons de circuits.
h.	Permettre au MGC de spécifier le contenu de durées étendues (annonces, tonalités continues) à insérer dans des flux de supports spécifiés.
i.	Permettre au MGC de spécifier des conditions de remplacement (détection d'événements spécifiques, fins de temporisations) dans lesquelles l'insertion de signaux de durée étendue devrait cesser.
j.	Permettre au MGC de télécharger, et spécifier un descriptif à invoquer à l'occurrence d'un événement.
k.	Spécifier des événements et signaux courants pour maximiser l'inter fonctionnement MG/MGC.
l.	Fournir un mécanisme d'extension pour des événements et signaux définis par la mise en œuvre avec, par exemple, des procédures d'enregistrement par l'IANA. Il peut être utile d'avoir un identifiant d'organisation (c'est-à-dire UIT, ETSI, ANSI) au titre du mécanisme d'enregistrement.
m.	Le protocole devra permettre au MGC de demander l'armement d'un déclencheur de mi-appel même après l'établissement d'appel.

 	5.5	Qualité de service/classe de service
Le protocole doit :
a.	Prendre en charge l'établissement d'un canal porteur avec une qualité de service/classe de service spécifiée.
b.	Prendre en charge la capacité de spécifier la qualité de service pour la connexion entre MG, et par direction.
c.	Prendre en charge un moyen de changer la QS durant une connexion, comme un tout et par direction.
d.	Permettre au MGC d'établir des seuils de QS et de recevoir des notification que de tels seuils ne peuvent pas être maintenus.
e.	Permettre que des paramètres de mémoire tampon de gigue soient spécifiés sur les canaux RTP à l'établissement de la connexion.

 	5.6	Prise en charge des essais
Le protocole doit :
a.	Prendre en charge les différents types d'essais de continuité (COT, Continuity Testing) du RTPC pour les deux extrémités d'origine et de terminaison de la connexion de circuits (2 fils et 4 fils).
b.	Prendre spécifiquement en charge le fonctionnement de lignes d'essais (par exemple 103, 105, 108).

 	5.7	Comptabilité
Le protocole doit :
a.	Prendre en charge un identifiant commun pour marquer les ressources relatives à une connexion.
b.	Prendre en charge la collecte des informations de comptabilité spécifiées provenant des MG.
c.	Fournir le mécanisme pour que le MGC spécifie que la MG rapporte automatiquement les informations de comptabilité à la fin de l'appel, à mi appel sur demande, à des intervalles de temps spécifiques, comme spécifié par le MGC et à des unités de seuil d'utilisation comme spécifié par le MGC.
d.	Prendre en charge spécifiquement la collecte :
*	de l'heure de début et d'arrêt , par flux de supports,
*	du volume de contenu porté (par exemple, le nombre de paquets/cellules transmis, nombre reçus avec et sans erreur, gigue inter arrivées) par flux de supports,
*	statistiques de qualité de service, par flux de supports.
e.	Permettre au MGC d'avoir un certain contrôle sur les statistiques rapportées, pour lui permettre de gérer la quantité d'informations transférées.

 	5.8	Contrôle de signalisation
L'établissement et provisionnement de canaux de signalisation vers l'arrière (via SIGTRAN par exemple) sort de notre domaine d'application. Cependant, la MG doit être capable de prendre en charge la détection des événements, et l'application de signaux associés à la ligne analogique de base, et la signalisation du type de canal associé. Le protocole doit  :
a.	Prendre en charge les exigences de signalisation des lignes analogiques et la signalisation associée au canal (CAS, Channel Associated Signalling).
b.	Prendre en charge les variations nationales d'une telle signalisation.
c.	Fournir des mécanismes pour prendre en charge la signalisation sans exiger de contraintes de rythme de MG-MGC au delà de celles spécifiées dans le présent document.
d.	Ne doit pas créer une situation où il y aurait une exigence obligatoire que le MGC et la MG soient homologués ensemble pour l'utilisation du protocole ; c'est-à-dire il doit être possible de dissimuler facultativement la variation de type de signalisation au MGC.

 	6.	Contrôle de ressource
 	6.1	Gestion d'état de ressource
Le protocole doit :

a.	Permettre à la MG de faire rapport des changements d'état des entités physiques qui prennent en charge les terminaisons de supports, les ressources de supports, et les canaux de signalisation associés aux facilités, dus à des défaillances, la récupération, ou une action administrative. Elle doit être capable de rapporter si une terminaison est en service ou non.

b.	Prendre en charge le blocage et la libération administrative des terminaisons de circuit TDM.

Note : comme le point ci-dessus se rapporte seulement aux circuits contrôlés par ISUP, il peut être inutile de l'exiger puisque le MGC contrôle leur usage. Cependant, cela peut avoir un sens pour les circuits signalés en MF et R2, où les état de supervision sont réglés de façon à rendre les circuits indisponibles à l'extrémité distante.

c.	Fournir une méthode pour que le MGC demande que la MG libère toutes les ressources actuellement en usage, ou réservées, sous le contrôle d'un MGC particulier, pour une ou toutes les connexions.

d.	Fournir un mécanisme de découverte de ressource de MG qui doit permettre à un MGC de découvrir quelles ressources a la MG. Exprimer des ressources peut être un problème d'une difficulté arbitraire et la livraison initiale du protocole pourrait avoir une vue simpliste de la découverte de ressource. Au minimum, la découverte de ressource doit énumérer les noms des terminaisons de circuit disponibles et les valeurs permises pour les paramètres pris en charge par les terminaisons. Le protocole devrait être défini de telle façon que des passerelles simples puissent répondre avec une formule relativement courte, pré mémorisée, au mécanisme de demande de découverte. En général, si le protocole définit un mécanisme qui permet au MGC de spécifier un réglage ou paramètre pour une ressource ou connexion dans la MG, et si les MG ne sont pas obligées de prendre en charge toutes les valeurs possibles de ce réglage ou paramètre, le mécanisme de découverte devrait alors fournir au MGC une méthode pour déterminer quelles valeurs possibles de ces réglages ou paramètres sont pris en charge par une MG particulière.

e.	Fournir un mécanisme pour découvrir quelles ressources sont actuellement disponibles dans la MG, lorsque les ressources sont consommées de façon dynamique par les connexions et que le MGC ne peut pas raisonnablement ou fiablement retracer la consommation de ces ressources. Il devrait aussi être possible de découvrir les ressources actuellement utilisées, afin de concilier les incohérences entre le MGC et la MG.

f.	Ne pas exiger qu'un MGC mette en œuvre une fonction de gestionnaire SNMP afin de découvrir les capacités d'une MG qui peuvent être spécifiées durant l'établissement du contexte.

 	6.2	Allocation de ressource
Le protocole doit :

a.	Fournir à la MG un moyen d'indiquer qu'elle n'a pas été capable d'effectuer l'action demandée à cause de l'épuisement de ses ressources, ou à cause d'une indisponibilité temporaire de la ressource.

b.	Fournir au MGC la capacité d'indiquer à une MG la ressource à utiliser exactement pour un appel (par exemple DS0) ou indiquer un ensemble de ressources (par exemple prendre un DS0 sur une ligne T1 ou une liste de types de codec) via un mécanisme de "caractère générique" à partir duquel la MG puisse choisir une ressource spécifique pour un appel (par exemple le 16ième créneau temporel, ou G.723).

c.	Permettre l'utilisation des noms du DNS et des adresses IP pour identifier les MG et les MGC. Cela ne devra pas empêcher d'utiliser d'autres identifiants pour les MG ou les MGC quand sont utilisées d'autres technologies de transport non IP pour le protocole.

 	7.	Exigences de fonctionnement/gestion
 	7.1	Assurance de contrôle/connexité
Pour fournir l'assurance du contrôle et de la connexité, le protocole doit fournir les moyens de minimiser la durée des pertes de contrôle dues à la perte de contact, ou à des discordances d'état.

Le protocole doit :

a.	Prendre en charge la détection et la récupération de la perte de contact due à la défaillance/encombrement des liaisons de communication ou à la défaillance de la MG ou du MGC. Noter que les arrangements de reprise sur défaillance sont un des mécanismes qui pourraient être utilisés pour satisfaire cette exigence.

b.	Prendre en charge la détection et la récupération de la perte d'une vue synchronisée des états de ressource et de connexion entre les MGC et les MG (par exemple par l'utilisation d'audits).

c.	Fournir un moyen aux MGC et MG de se communiquer mutuellement les indications d'amorçage et de réamorçage, et de ce qu'est la configuration de la MG.

d.	Permettre plus d'un MGC de secours et fournir une façon réglée pour que la MG contacte une de ses sauvegardes.

e.	Fournir un retour réglé au MGC principal après récupération. 	Comment les MGC coordonnent les ressources entre eux sort du domaine d'application de ce protocole.

f.	Fournir un mécanisme afin qu'en cas de défaillence d'un MGC, les connexions déjà établies puissent être conservées. Le protocole n'a pas à fournir une capacité pour maintenir les connexions dans le processus de connexion, mais pas encore établies quand la défaillance se produit.

g.	Le protocole doit permettre la récupération ou la redistribution du trafic sans perte d'appel.

 	7.2	Contrôle d'erreurs
Le protocole doit :

a.	Permettre à la MG de rapporter les raisons de défaillances anormales des connexions de couche inférieure, par exemple une défaillance de circuit TDM, une défaillance de VCC ATM.

b.	Permettre à la MG de rapporter des événements de contrôle de paramètre d'usage (UPC, Usage Parameter Control).

c.	Fournir des moyens d'améliorer la synchronisation potentielle ou la surcharge focalisée d'événements de supervision/signalisation qui pourraient détériorer le fonctionnement de la MG ou du MGC. La restauration de l'alimentation électrique ou le rétablissement du transport de la signalisation sont des sources typiques d'averses de signalisation potentiellement néfastes de la MG au MGC ou vice-versa.

d.	Permettre à la MG de notifier au MGC qu'une terminaison a été réalisée et communiquer la raison quand une terminaison est mise hors service unilatéralement par la MG à cause d'événements anormaux.

e.	Permettre au MGC d'accuser réception de l'information qu'une terminaison a été mise hors service.

f.	Permettre à la MG de demander que le MGC libère une terminaison et en communique la raison.

g.	Permettre au MGC de spécifier, par suite d'une telle demande, sa décision de mettre hors service une terminaison, de la laisser comme elle est, ou de la modifier.

 	7.3	Exigences de MIB
Le protocole doit définir une MIB de MG commune, qui doit être extensible, mais doit :

a.	Fournir des informations sur :
* la transposition entre les ressources et la prise en charge d'entités physiques.
* des statistiques sur la qualité de service sur les interfaces de contrôle et de signalisation vers l'arrière.
* les statistiques nécessaires pour l'ingénierie du trafic au sein de la MG.

b	Le protocole doit permettre à la MG de fournir au MGC toutes les informations qu'il a besoin de fournir dans sa MIB.

c.	La MIB de MG doit prendre en charge la mise en œuvre de H.341 par l'action de la MG, du MGC, ou des deux agissant ensemble.

 	8.	Exigences générales du protocole

Le protocole doit :

a.	Prendre en charge plusieurs opérations à invoquer dans un message et les traiter comme une seule transaction.

b.	Être à la fois modulaire et extensible. Toutes les mises en œuvre peuvent ne pas souhaiter prendre en charge toutes les extensions possibles du protocole. Cela permettra des mises en œuvre légères pour des tâches spécialisées où les ressources de traitement sont restreintes. Cela pourrait être réalisé en définissant des profils particuliers pour des utilisations particulières du protocole.

c. 	Être souple dans l'allocation de l'intelligence entre MG et MGC. Par exemple, un MGC peut vouloir permettre à la MG d'allouer des ressources de MG particulières dans certaines mises en œuvre, alors que dans d'autres, le MGC peut vouloir être celui qui alloue les ressources à utiliser par la MG.

d.	Prendre en charge l'adaptabilité de très petites à de très grandes MG: Le protocole doit prendre en charge des MG avec des capacités allant de une à des millions de terminaisons.

e.	Prendre en charge l'adaptabilité de zones de contrôle de MGC de très petites à de très grandes : le protocole devrait prendre en charge des MGC qui contrôlent de une MG à quelques dizaines de milliers de MG.

f.	Prendre en charge le besoin de passerelle résidentielle qui prend en charge de une à quelques lignes, et les besoins d'une grande passerelle de RTPC prenant en charge des dizaines de milliers de lignes. Les mécanismes de protocole favorisant un extrême ou l'autre devraient être minimisés en faveur d'un mécanisme d'objet plus général applicable à une large gamme de MG. Lorsque des mécanismes spéciaux sont proposés pour optimiser un sous ensemble de mises en œuvre, ces mécanismes devraient être définis comme facultatifs, et devraient avoir un impact minimal sur le reste du protocole.

g.	Faciliter la mise à niveau des versions de MG et MGC indépendamment l'une de l'autre. Le protocole doit inclure un identifiant de version dans l'échange initial de messages.

h.	Faciliter la découverte des capacités de protocole d'une entité à l'autre.

i.	Spécifier des commandes comme facultatives (elles peuvent être ignorées) ou obligatoires (la commande doit être rejetée) et dans une commande, spécifier des paramètres comme facultatifs (ils peuvent être ignorés) ou obligatoires (la commande doit être rejetée).

 	8.1	Exigences d'association MG-MGC
Le protocole doit :

a.	Prendre en charge l'établissement d'une relation de contrôle entre un MGC et une MG.

b.	Permettre que plusieurs MGC envoient des messages de contrôle à une MG. Donc, le protocole doit permettre des messages de contrôle provenant de plusieurs adresses de signalisation à une seule MG.

c.	Fournir une méthode pour que la MG dise à un MGC qu'elle a reçu une commande pour une ressource qui est sous le contrôle d'un MGC différent.

d.	Prendre en charge une méthode pour que la MG contrôle le débit des demandes qu'elle reçoit du MGC (par exemple des techniques de fenêtre, un retard à croissance exponentielle).

e.	Prendre en charge une méthode pour que la MG dise à un MGC qu'elle ne peut pas traiter plus de demandes.

 	8.2	Exigences de performances
Le protocole doit :

a.	Minimiser les échanges de messages entre MG et MGC, par exemple durant l'amorçage/réamorçage, et durant les essais de continuité.

b.	Prendre en charge des contraintes d'essai de continuité qui soient au maximum de 200 ms de délai de propagation d'IAM entre MGC (IAM est le nom donné à un message d'établissement de connexion SS7) et un maximum de 200 ms de la fin du numérotage à l'émission d'IAM.

c.	Faire un usage efficace du mécanisme de transport sous-jacent. Par exemple, les tailles de PDU de protocole par rapport aux tailles de MTU de transport doivent être considérées dans la conception du protocole.

d.	Ne pas contenir de contraintes d'architecture ou de signalisation inhérentes qui interdiraient des taux de crête d'appel de l'ordre de 140 appels/s sur un réseau de charge modérée.

e.	Permettre des réglages de provisionnement par défaut afin que les commandes aient seulement besoin de contenir des paramètres non par défaut.

 	9.	Transport
 	9.1	Hypothèses sur le réseau sous-jacent
Le protocole doit supposer que le réseau sous-jacent :
a.	puisse être sur de grands réseaux partagés : les hypothèses de proximité ne sont pas permises ;
b	n'assure pas une livraison fiable des messages ;
c.	ne garantit pas l'ordre des messages : la livraison à la suite des messages associés à la même source d'événements n'est pas supposée ;
d.	n'empêche pas des duplications de transmissions.

 	9.2	Exigences de transport
Le protocole doit :

a.	Fournir la capacité d'interrompre la livraison des messages obsolètes à l'extrémité d'envoi si leur transmission n'a pas été réussie. Par exemple, interrompre une commande qui est dépassée par les événements.

b.	Prendre en charge les messages prioritaires : le protocole devra permettre une préséance de commande pour permettre aux messages prioritaires de supplanter les messages non prioritaires.

c.	Prendre en charge une large sortance au MGC.

d.	Fournir un moyen pour qu'une entité corrèle les commandes et les réponses avec l'autre entité.

e.	Fournir la raison de tout échec de commande.

f.	Assurer que la perte d'un paquet ne bloque pas les messages sans relation avec le ou les messages contenus dans le paquet perdu.

Noter qu'il peut y avoir ici assez d'exigences de fiabilité du protocole pour garantir la rédaction d'une couche de transport fiable séparée à part du protocole de contrôle de passerelle de supports. Il est aussi nécessaire de comparer les exigences Megaco de transport fiable avec les exigences similaires de Sigtran.

 	10.	Exigences de sécurité

Les mécanismes de sécurité peuvent être spécifiés comme ils sont fournis dans les mécanismes de transport sous-jacents, comme IPsec. Le protocole, ou ces mécanismes, doit :
a.	Permettre l'authentification mutuelle au début d'une association MGC-MG.
b.	Permettre la préservation des messages de contrôle une fois l'association établie.
c.	Permettre la protection facultative de la confidentialité des messages de contrôle. Le mécanisme devrait permettre un choix de l'algorithme à utiliser.
d.	Fonctionner de façon sûre à travers des domaines qui ne sont pas de confiance.
e.	Prendre en charge la non répudiation pour une MG située chez un consommateur qui parle au MGC d'un opérateur de réseau.
f.	Définir des mécanismes pour atténuer les attaques de déni de service.
Note : le document de protocole devra inclure une discussion étendue des exigences de sécurité, offrant des précisions sur chaque menace et donnant un tableau complet de la défense incluant des mesures hors du protocole comme de configuration.
g.	Il serait souhaitable que le protocole soit capable de passer à travers les pare-feu couramment utilisés.

 	11.	Exigences spécifiques de types de support particuliers

Les types de support mentionnés dans le Tableau 1 peuvent être regroupés dans différents types de MG. Des exemples sont mentionnés dans les paragraphes qui suivent. Comment ils sont regroupés sort du domaine d'application du protocole général de contrôle de passerelle de supports. Le protocole doit prendre en charge tous les types de supports mentionnés au Tableau 1.

Tableau 1 : Types de support et applications

Type de support	Applications	Réseau de transit	
Circuit + ISUP	circuit/accès, voix, fax, NAS, multimédia	IP, ATM, FR	
Circuit + MF	circuit/accès, voix, fax, NAS, multimédia	IP, ATM, FR	
RNIS	circuit/accès, voix, fax, NAS, multimédia	IP, ATM, FR	
Analogue	voix, fax, texte téléphoné	IP, ATM, FR	
Terminaison dans une passerelle à capacité restreinte	voix, fax, texte téléphoné	IP, ATM, FR	
Terminaison d'application multimédia H.323 	IVR,ARF, serveur d'annonces, serveur de reconnaissance vocale, multimédia H.323 	IP, ATM, FR	
Passerelle et MCU multimédia H.320	Passerelle et MCU H.323 	RNIS, IP, ATM, FR	

 	11.1	Types de porteuse spécifiques du support
Ce paragraphe décrit les exigences pour le traitement des terminaisons rattachées à des types spécifiques de réseaux.

 	11.1.1.	Exigences pour le RTPC TDM (circuit)
Ce type de support est applicable à une passerelle de circuits, une passerelle d'accès, ...

Le protocole doit permettre :

a.	que le MGC spécifie le codage à utiliser sur le circuit rattaché.

b.	en général, si quelque chose est établi par un protocole de signalisation mondial (par exemple ISUP permet de signaler la Loi mu ou la Loi A en utilisant ISUP) cela doit être réglable par le protocole.

c.	attributs TDM :
*	annulation d'écho,
*	codage MIC ou autre compression vocale (par exemple Loi mu ou Loi A),
*	le chiffrement,
*	l'adaptation du débit (par exemple V.110, ou V.120),

d.	pour les appels entrants, l'identification d'un circuit TDM spécifique (intervalles de temps et facilités),

e. 	pour les appels sortants sur le réseau de circuits, l'identification d'un circuit spécifique ou l'identification d'un groupe de circuits avec l'indication que la MG doit choisir et retourner l'identification d'un membre disponible de ce groupe,

f.	la spécification du codage par défaut du contenu qui passe de et vers un certain circuit, éventuellement sur la base d'un groupe de circuits logiques ou physiques,

g.	la spécification en tout point durant la vie d'une connexion des divers aspects du codage du contenu, incluant en particulier les informations de capacité du canal,

h.	la spécification en tout point de la vie d'une connexion d'un bourrage de perte à appliquer aux flux de supports entrants et sortants à la terminaison de circuit,

i.	la spécification en tout point de la vie d'une connexion de l'applicabilité de l'annulation d'écho au flux de supports sortant,

j.	les appels multi débits de/vers le SCN,

k.	les appels de canal H (n x 64 k) de/vers le SCN,

l.	les protocoles d'agrégation de canal B pour créer des canaux à haut débit pour le multimédia sur le SCN,

m.	les terminaisons et négociations de modem.

Le protocole peut aussi permettre :

n.	la spécification de flux de supports de sous canal,

o.	la spécification de flux de supports multi canaux.

 	11.1.2	Type de porteuse de paquets
Le protocole doit être capable de spécifier :

a.	Le codage d'entrée et de sortie (c'est-à-dire la façon dont les paquets entrants et sortants sont codés) (incluant le chiffrement).

b.	les accès, proche et distant, et les autres paramètres de session pour RTP et RTCP.

Le protocole doit prendre en charge le rapport de :

c.	re-négociation de codec pour une cause qui fera l'objet d'une étude ultérieure

 d.	les passerelles de réseau et d'accès, ressources capables de plus d'une connexion active à la fois doivent aussi être capables de mixage et de duplication de paquet. 

Le protocole doit permettre :

e.	La spécification de paramètres pour les flux sortants et entrants de paquets à des moments séparés de la vie de la connexion (parce que les adresses d'accès distant sont normalement obtenues par un échange de signalisation distinct avant ou après l'allocation des adresses d'accès de l'extrémité proche).

f.	La possibilité pour chaque passerelle de supports d'allouer les accès sur lesquels elle va recevoir les flux de paquets (incluant RTCP ainsi que les flux de supports) et rapporter ses allocations au contrôleur de passerelle de supports pour la signalisation à l'extrémité distante. Noter que la prise en charge de différents fournisseurs d'accès IP sur la base de l'appel exigerait que les accès sur lesquels les flux de paquets soient selectionnés par le MGC (mais seulement si l'adresse IP de la MG est différente pour chaque fournisseur d'accès).

g.	La spécification à tout moment de la vie d'une connexion du type de charge utile RTP et du numéro de session RTP pour chaque flux de supports encapsulé dans RTP.

h.	La capacité de spécifier si les flux sortants sont en envoi individuel ou en difffusion groupée. Noter que sur un réseau IP cette information est implicite par l'adresse de destination, mais dans d'autres réseaux, c'est un paramètre de connexion.

i.	D'invoquer le chiffrement/déchiffrement sur les flux de supports et la spécification de l'algorithme et clé associés.

Le protocole devrait aussi permettre :

j.	que le MGC configure les flux de supports non RTP (propriétaires ou autres) encapsulés.

 	11.1.3	Exigences de type de porteuse pour ATM
Ce type de porteuse est applicable aux passerelles de réseau, d'accès, ....

 	11.1.3.1	Adressage
a.	Le protocole doit être capable de spécifier les attributs de terminaison suivants :
*	identifiant de circuit virtuel,
*	identifiant de circuit virtuel plus créneau AAL2, et ses variantes permettant à la passerelle de choisir l'identifiant (ou une partie de l'identifiant)
*	adresse réseau de termination distante, nom de MG distante.
b.	Permettre la spécification d'une termination ATM qui va être allouée à une connexion de MG comme identifiant de VC, un identifiant de VC plus un créneau AAL2, une variante générique de l'un ou l'autre. Une adresse réseau de terminaison distante, ou un nom de MG distante pourrait aussi être utilisé quand la MG peut choisir le VC et changer le VC durant la vie de la connexion en utilisant la signalisation ATM.
c.	Fournir une indication par la MG de l'identifiant de VC et éventuellement du créneau AAL2 de la terminaion actuellement allouée à la connexion.
d.	Fournir un moyen de se référer ensuite à cette terminaison.
e.	Se référer à un VC existant comme interface physique + identifiant de chemin virtuel (VPI, Virtual Path Identifier) + identifiant de circuit virtuel (VCI, Virtual Circuit Identifier).
f.	Lorsque le VCC est établi localement (les SVC signalés par la passerelle par la signalisation UNI ou PNNI ou similaire) le VCC doit être l'objet d'une référence indirecte en des termes ayant une signification pour les deux extrémités du VCC. Par exemple, un nom mondial ou l'adresse ATM des appareils ATM à chaque extrémité du VCC. Cependant, il est possible/probable qu'il y ait plusieurs VCC entre une paire donnée d'appareils ATM. Donc, la paire d'adresses ATM doit être résolue par un identifiant de VCC sans ambiguïté dans le contexte de la paire d'adresses ATM.
g.	Se référer à un VCC comme l'adresse du système d'extrémité ATM de passerelle distante + VCCI.
h.	Permettre au VCCI d'être choisi par la MG ou imposée à la MG.
i.	Prendre en charge toutes les variantes d'adressage ATM (par exemple l'adresse de système d'extrémité ATM (AESA, ATM End System Address) et E.164).

 	11.1.3.2	Exigences relatives à la connexion
Le protocole doit :
a.	Permettre le découplage de création/suppression de la connexion en bande étroite de la création/suppression du VCC sous-jacent.
b.	Permettre une déconnexion efficace de toutes les connexions associées à un accès physique ou VCC. Par exemple, cela pourrait agréger des déconnexions sur un circuit large bande qui a subi une erreur physique.
c.	Permettre que la connexion établie en utilisant ce protocole soit portée sur un VCC, qui peut être un :
*	PVC ou SPVC,
*	SVC établi à la demande, soit par le MGC lui-même, soit par un courtier agissant en son nom, ou
*	SVC généré comme demandé par la MG locale, ou par l'extrémité distante de la MG locale par la signalisation UNI ou PNNI.
d.	Permettre que les paramètres de transport ATM et les paramètres de qualité de service soient passés à la MG.
e.	Permettre le blocage et le déblocage d'une interfacephysique, d'un VCC ou d'un canal AAL1/AAL2.

Le protocole devrait :
f.	Lorsque l'établissement d'un VCC est exigé sur la base d'un appel en bande étroite, permettre que toutes les informations nécessaires soient passées en un seul message.

 	11.1.3.3	Adaptation du support
Le protocole doit :

a.	Permettre que les paramètres AAL soient passés à la MG.

b.	Permettre que plusieurs appels AAL1/AAL2 en bande étroite soient transposés en un seul VCC. Pour AAL2, ces appels sont différenciés au sein de chaque VCC par un identifiant de canal AAL2. Une connexion AAL2 peut s'étendre sur plus d'un VCC et transiter par des appareils de commutation AAL2. La Recommandation [Q.2630.1] définit un identifiant de bout en bout appelé la référence générée par l'utilisateur desservi (SUGR, Served User Generated Reference). Il porte les informations de l'utilisateur d'origine du protocole de signalisation AAL2 à l'utilisateur de terminaison de façon transparente et sans modification.

c.	Permettre un lien non ambigu d'un appel en bande étroite à un identifiant de connexion AAL2, ou à un canal AAL1, au sein du VCC spécifié.

d.	Permettre que l'identifiant de connexion AAL2, ou le canal AAL1, soit choisi par la MG ou imposée à la MG.

e.	Permettre l'utilisation de l'identifiant de canal AAL2 (cid) au lieu de l'identifiant de connexion AAL2.

f.	Permettre que le profil vocal AAL2 soit imposé ou négocié avant le début de la connexion. AAL2 permet des paquets de longueur variable et des débits de paquets variables, avec plusieurs codecs possibles au sein d'un profil donné. Donc, un appel donné peut mettre à niveau ou dégrader le codec pendant la durée de vie de l'appel. Les canaux inactifs peuvent générer une bande passante nulle. Donc un VCC AAL2 peut varier en bande passante et éventuellement excéder son contrat. Les contrôles d'encombrement au sein d'une passerelle peuvent réagir à l'encombrement en modifiant les taux/types de codec.

g.	Permettre au MGC de donner pour instruction à la MG la façon dont les appels individuel en bande étroite se comportent en cas d'encombrement.

h.	Permettre au MGC de spécifier une porteuse AAL5, avec les choix suivants :
*	Conformément à la norme AF-VTOA-0083 [VTOA] de l'ATM Forum,
*	RTP avec IP/UDP,
*	RTP sans IP/IDP selon H.323v2 Annexe C [H.323],
*	RTP compressé selon la norme AF-SAA-0124.000 [GHMTOA] de l'ATM Forum.

i.	Permettre un lien non ambigu d'un appel en bande étroite à un canal AAL1 au sein du VCC spécifié. (Dans AAL1, plusieurs appels en bande étroite peuvent être transposés dans un seul VCC.)

 	11.1.3.4	Exigences de rapport
Le protocole devrait:

a.	Permettre que des statistiques de fin d'appel montrent la perte/restauration de VCC sous-jacent pendant la durée de l'appel, ainsi que la durée de la perte.

b.	Permettre la notification, à la demande du MGC, de toutes actions d'évitement d'encombrement prises par la MG.

Le protocole doit :

c.	Permettre que les VCC ATM ou les canaux AAL2 soient l'objet d'un audit par le MGC.
a
d.	Permettre que des changements de l'état des VCC ATM ou des canaux AAL2 soient notifiés comme demandé par le MGC.

e.	Permettre au MGC d'interroger les ressources et la disponibilité des points d'extrémité. Les ressources peuvent inclure des VCC, et des DSP. Les VCC peuvent être actifs ou inactifs. Les points d'extrémité peuvent être libres de connexion, connectés ou indisponibles.

 	11.1.3.5	Exigences fonctionnelles
Le protocole doit :
a.	Permettre au MGC de réserver un support, et de spécifier un chemin pour lui à travers le réseau.

 	11.2	Exigences spécifiques de l'application
 	11.2.1	Passerelle de circuits
Une passerelle de circuits est une interface entre des réseaux SCN et des réseaux de voix sur IP ou de voix sur ATM. De telles passerelles font normalement l'interface du SS7 ou autre signalisation NNI sur le SCN et gèrent un grand nombre de circuits numériques.

Le protocole doit :
a.	Fournir le bouclage de circuit et côté paquet.
b.	Fournir des connexions n x 64kbit/s côté circuit.
c.	Fournir des connexions en sous débit et multi débits pour étude ultérieure.
d.	Fournir la capacité de prendre en charge le rapport/génération de signalisation de CAS par circuit (DP, DTMF, MF, R2, J2, et variantes nationales).
e.	Fournir la capacité de prendre en charge le rapport des événements DTMF détectés soit chiffre par chiffre, comme la séquence de chiffres détectée avec un mécanisme souple pour que la MG détermine la fin probable de la chaîne de numérotation, soit dans un flux RTP distinct.
f.	Fournir la capacité de prendre en charge la génération et la réception de ANI et DNIS.

 	11.2.2	Passerelle d'accès
Une passerelle d'accès connecte les interfaces UNI comme de RNIS (PRI et BRI) ou les interfaces traditionnelles de terminal vocal analogique, à un réseau de voix sur IP ou de voix sur ATM, ou de réseau de voix sur relais de trame.

Le protocole doit :

a.	Prendre en charge la détection et la génération de la signalisation de ligne analogique (état du crochet, génération des sonneries).

b.	Fournir la capacité de prendre en charge le rapport des événements DTMF détectés soit chiffre par chiffre, comme une séquence de chiffres détectée avec un mécanisme souple pour que la MG détermine la fin probable de la chaîne de numérotation, soit dans un flux RTP distinct.

c.	Ne pas exiger de mécanismes d'inscription, de mise en mémoire tampon d'événements, de mémorisation de transposition de chiffres quand il met en œuvre des passerelles à fonction restreinte (1à 2 lignes) avec des capacités très limitées.

d.	Fournir la capacité de prendre en charge la génération et la réception de l'identifiant d'appelant.

Le relais du protocole par un mandataire fera l'objet d'une étude ultérieure.

 	11.2.3	Passerelle de circuit/accès avec accès de télécopie
a.	Le protocole doit être capable d'indiquer la détection d'un support de télécopie.
b.	Le protocole doit être capable de spécifier T.38 pour le transport de la télécopie.
c.	Le protocole doit être capable de spécifier le codage G.711 pour le transport de tonalités de télécopie sur un réseau de paquets.

 	11.2.4	Passerelle de circuit/accès avec accès de texte téléphoné
Une passerelle d'accès avec des accès capables de communication de texte téléphoné doit fournir la communication entre le texte téléphoné dans le SCN et les canaux de conversation de texte dans le réseau de paquets.

La capacité de texte téléphoné des accès est supposée possible en combinaison avec les autres options pour les appels comme décrit au paragraphe 11.2.5 (e.) sur les "NAS adaptables".

L'accès est supposé ajuster les différences dans les protocoles de texte téléphoné pris en charge, afin que le flux de supports de texte puisse être communiqué codé selon T.140 dans le réseau de paquets sans autre transcodage [T.140].

Le protocole doit être capable de rapporter le type de texte téléphoné qui est connecté à l'accès de SCN. Les types prévus sont les mêmes que ceux pris en charge par la Recommandation UIT-T V.18 : DTMF, EDT, Baudot-45, Baudot-50, Bell, V.21, Minitel et V.18. Il devrait être possible de contrôler quels protocoles sont supportés. L'accès de SCN est supposé contenir la fonction UIT-T V.18 [V.18].

Le protocole doit être capable de contrôler les niveaux de fonction suivants de prise en charge de texte téléphoné :

a.	Simple prise en charge de texte seul : l'appel est établi en mode texte depuis le début de l'appel, afin de mener une conversation seulement de texte.

b.	Prise en charge d'une alternance de texte et de voix : l'appel peut commencer en mode vocal ou en mode texte et, à tout moment durant l'appel, changer de mode à la demande de l'utilisateur SCN. Du côté paquet, les deux flux de supports de voix et de texte doivent être ouverts, et il doit être possible de contrôler l'alimentation de chaque flux par le protocole.

c.	Prise en charge simultanée du texte et de la voix : l'appel est effectué dans un mode quand des flux simultanés de texte et de voix sont pris en charge. L'appel peut commencer en mode vocal et changer durant l'appel à l'état d'un appel texte et voix.

Un accès peut mettre seulement en œuvre le niveau a, ou toute combinaison de niveaux de a, b et c, incluant toujours le niveau a.

Le protocole doit prendre en charge :

d.	Une solution de remplacement fondée sur le texte à la réponse vocale interactive, ou une fonction de ressource audio de la passerelle quand l'accès est utilisé en mode texte téléphoné.

e.	Le choix de quel tableau de traduction national doit être utilisé entre les protocoles de texte téléphoné T.140 fondé sur Unicode et celui fondé sur 5 à 7 bits.

f.	Le contrôle du message de sonde V.18 à utiliser sur les appels entrants.

 	11.2.5	Serveur d'accès réseau
Un serveur d'accès réseau (NAS, Network Access Server) est une passerelle d'accès (MG, Media Gateway) qui termine les signaux de modem ou les connexions HDLC synchrones d'un réseau (par exemple, d'un SCN ou d'un réseau xDSL) et donne l'accès des données au réseau de paquets. Seules les exigences spécifiques de NAS sont décrites ici.

La Figure 1 donne l'architecture de référence pour un serveur d'accès réseau (NAS). La signalisation vient dans le MGC et le MGC contrôle le NAS.

                          +-------+        +-------+
           Signalisation  |       |        |       |
               -----------+  MGC  +        |  AAA  |
                          |       |        |       |
                          +---+---+        +--+----+
                              |               |
                        Megaco|_______________|
                                              |
                                              |
                          +---+---+         ~~|~~~
              porteuse    |       |        (      )
               -----------+  NAS  +-------(   IP   )
                          |       |        (      )
                          +-------+         ~~~~~~

Figure 1 : architecture de référence de NAS

Le protocole doit prendre en charge :

a.	Des capacités de rappel : rappel

b.	Des appels par modem : le protocole doit être capable de spécifier le type de modem à utiliser pour l'appel.

c.	Portage des informations de porteuse : le protocole doit être capable de spécifier le débit de données de la connexion TDM (par exemple, 64 kbit/s, 56 kbit/s, 384 kbit/s) si il est disponible d'après le SCN.

d.	Adaptation de débit : le protocole doit être capable de spécifier le type d'adaptation de débit à utiliser pour l'appel y compris d'indiquer le sous débit, si il est disponible au SCN (par exemple 56 k, ou V.110 signalé dans les capacités de porteuse avec un sous débit de connexion de 19,2 kbit/s).

e.	NAS adaptables : le protocole doit être capable de prendre en charge plusieurs options pour un appel entrant pour permettre au NAS de choisir dynamiquement le type d'appel approprié. Par exemple, un appel RNIS entrant codé pour une capacité de porteuse de "parole" pourrait en réalité être un appel vocal, de modem, de télécopie, de texte téléphoné, ou de 56 kbit/s synchrone. Le protocole devrait permettre au NAS de rapporter au MGC le type réel d'appel une fois détecté.

Les quatre types de base de porteuse pour un NAS sont :
1. Parole en mode circuit, à 64 kbit/s, structuré à 8 kHz.
2. Audio à 3,1 kHz en mode circuit, à 64 kbit/s, structuré à 8 kHz.
3. Transmission numérique sans restriction à débit adapté de 56 kbit/s en mode circuit à 64-kbit/s, structuré à 8 kHz.
4. Transmission numérique sans restriction en mode circuit, à 64 kbit/s, structuré à 8 kHz.

f.	Passage des informations de numéro appelé et de numéro appelant au NAS à partir du MGC. Aussi, passage du numéro à taxer/facturer, du numéro de renvoi, et du numéro d'appel d'origine, si ils sont connus, au NAS par le MGC. Si il y a d'autres champs Q.931 qui doivent être passés du MGC à la MG, il devrait alors être possible de les passer [Q.931].

g.	Capacité du MGC à conduire le NAS à se connecter à un tunnel spécifique, par exemple à un LNS, ou à un serveur AAA.

h.	Quand cela est demandé par le MGC, être capable de rapporter les informations de capacité, par exemple, les types de connexion (V.34/V90/RNIS synchrone...) le mécanisme AAA (RADIUS/DIAMETER/...) le type d'accès (PPP/SLIP/...) après redémarrage ou mise à niveau.

 	11.2.6	Passerelle à capacités restreintes
Les exigences précisées ici peuvent aussi être appliquées à de petites passerelles analogiques, et aux modems câble/xDSL. Voir aussi le paragraphe sur les passerelles d'accès.

Le protocole doit prendre en charge :

a.	La capacité de fournir une version adaptée du protocole. Quand des caractéristiques du protocole ne sont pas prises en charge, un message d'erreur approprié doit être envoyé. L'action par défaut appropriée doit être définie. Le lieu où cela est défini peut sortir du domaine d'application du protocole.

b.	La capacité de fournir des informations de capacité de l'appareil au MGC par rapport à l'utilisation du protocole.

 	11.2.7	Passerelle multimédia
Le protocole doit avoir une capacité suffisante pour prendre en charge une passerelle multimédia. H.320 et H.324 sont caractérisés par un seul flux de données avec plusieurs flux de supports multiplexés sur lui.

Si la transposition est de H.320 ou H.324 sur le côté circuit, et H.323 sur le côté paquet, il est supposé que la MG sait comment transposer les sous canaux respectifs du côté H.320/H.324 en flux sur le côté paquet. Si des informations supplémentaires sont requises quand on connecte deux terminaisons, elles doivent alors être fournies afin que les connexions ne soient pas ambiguës.

La passerelle multimédia :

1)	devrait prendre en charge l'agrégation de canal de porteuse de lien,

2)	doit prendre en charge l'agrégation 2xB (et éventuelle ment de débits plus élevés) via H.221,

3)	doit être capable de changer dynamiquement la taille des canaux audio, vidéo et de données dans le multiplex H.320,

4)	doit réagir aux changements dans le multiplex H.320 sur les limites de 20 ms,

5)	doit prendre en charge les commandes BAS TCS4/IIS,

6)	doit prendre en charge la détection et la création des tonalités DTMF,

7)	devrait prendre en charge les MIB SNMP comme spécifié dans [H.341].

a.	Si une des exigences ci-dessus ne peut pas être traitée par le protocole de MGC à MG à cause de contraintes de temps, il est alors probable que le traitement de H.245 à H.242 doive avoir lieu à la MG. Autrement, la prise en charge de cette fonction dans la passerelle multimédia est une exigence du protocole.

b.	Il doit être possible que le protocole spécifie appel par appel les différentes applications. Donc, un appel pourrait être de RTPC à RTPC sous le contrôle du SS7, tandis que le suivant pourrait être RNIS/H.320 sous le contrôle du SS7 à H.323.  C'est seulement un exemple ; l'exigence clé est que le protocole n'empêche pas de telles applications.

 	11.2.8	Fonction de ressource audio
Une fonction de ressource audio (ARF, Audio Resource Function) consiste en un ou plusieurs modules fonctionnels qui peuvent être déployés sur un serveur IVR de passerelle de support autonome, un périphérique intelligent, une unité de reconnaissance de la parole/locuteur, etc. ou une passerelle de supports traditionnelle. Une telle passerelle de supports est appelée une passerelle à capacité audio (AEG, Audio Enabled Gateway) si elle effectue des tâches définies dans un ou plusieurs des modules fonctionnels ARF suivants :
exécution audio,
collecte DTMF,
enregistrement audio,
reconnaissance de la parole,
vérification/identification du locuteur,
extraction/reconnaissance des caractéristiques de l'auditoire, ou
audio conférence.

Des modules de fonction ARF supplémentaires qui prennent en charge les communications homme - machine par l'usage de tonalités téléphoniques (par exemple, DTMF) ou des moyens auditifs (par exemple, la parole) peuvent être ajoutés à la définition d'AEG dans de futures versions de ces exigences.

Les paquetages génériques de descriptif de tout module doivent prendre en charge toutes les exigences pour ce module. Toute extension de paquetage pour un module donné doit inclure, par héritage ou référence explicite, les exigences pour ce module donné.

Les exigences du protocole pour chaque module ARF sont fournies dans les paragraphes qui suivent.

 	11.2.8.1	Module d'exécution audio
a.	être capable de fournir le fonctionnement de base suivant :
-	demander à une MG ARF d'exécuter une annonce.
b.	être capable de spécifier les caractéristiques d'exécution :
-	volume d'exécution
-	vitesse d'exécution
-	itérations d'exécution
-	intervalle entre les itérations d'exécution
-	duré d'exécution
c.	Permettre la spécification de variables vocales comme le DN, numéro, date, heure, etc. Le protocole doit permettre la spécification de la valeur (par exemple 234-3456), et aussi le type (numéro de répertoire).
d.	En utilisant la terminologie où un segment est une unité de parole exécutable, ou est une abstraction qui se résout en une unite de parole exécutable, permettre la spécification des types de segment suivants :
-	un enregistrement provisionné ;
-	un bloc de texte à convertir en parole ;
-	un bloc de texte à afficher sur un appareil ;
-	une longueur de silence qualifiée par sa durée ;
-	une tonalité générée par un algorithme ;
-	une variable vocale, spécifiée par un type et une valeur. Étant donnée une variable de type et de valeur, les unités IVR/ARF vont assembler dynamiquement les phrases requises pour son exécution ;
-	une abstraction qui représente une séquence de segments audios. Les incorporations de ces abstractions doivent aussi être permises.
Un exemple de cette abstraction est une séquence de segments audios, dont le premier est un enregistrement des  mots "Le numéro que vous avez composé", suivi par un numéro d'annuaire variable, suivi par un enregistrement des mots "n'est plus en service".
-	une abstraction qui représente un ensemble de segments audios et qui se résout en un seul segment par un qualificatif. L'incorporation de ces abstractions doit être permise.
	Par exemple prenons un ensemble de segments audios enregistrés dans différents langages dont tous expriment le concept signifiant "Le numéro que vous avez composé n'est plus en service". L'ensemble se résout en un qualificatif de langage. Si le qualificatif est "Français", l'ensemble se résout en la version française de cette annonce.
	Dans le cas d'une abstraction incorporée consistant en un ensemble qualifié par un langage à un niveau et un ensemble qualifié par un genre à un autre niveau, il serait possible de spécifier qu'une annonce soit exécutée en français et dit par une voix féminine.

e.	Fournir deux différentes méthodes de spécification audio :
-	spécification directe des composants audio à exécuter en spécifiant la séquence de segments dans la commande elle-même ;
-	spécification indirecte des composants audio à exécuter par référence à un seul identifiant qui se résout en une séquence provisionnée de segments audios.

 	11.2.8.2	Module de collecte DTMF
Le module de collecte DTMF doit prendre en charge toutes les exigences dans le module d'exécution en plus des exigences suivantes :

a.	être capable de fournir le fonctionnement de base suivant :
-	demander qu'un AEG exécute une annonce, qui peut facultativement être terminée par le DTMF, et ensuite collecter le DTMF

b.	être capable de spécifier ces caractéristiques de collection d'événements :
-	le nombre de tentatives pour que l'utilisateur entre un schéma DTMF valide.

c.	par rapport aux temporisations de chiffres, permettre la spécification :
-	du temps permis à l'utilisateur pour entrer le premier chiffre,
-	du temps permis à l'utilisateur pour entrer chaque chiffre suivant le premier chiffre,
-	du temps permis à l'utilisateur pour entrer un chiffre une fois que le nombre maximum de chiffres attendus a été entré.

d.	être capable de permettre que plusieurs opérations d'invite de collecte de chiffres DTMF, d'enregistrement vocal (si c'est pris en charge) et/ou d'analyse de reconnaissance de la parole (si c'est pris en charge) fournissent les types d'invites suivants :
-	invite initiale
-	re invite
-	invite d'erreur
-	annonce d'échec
-	annonce de succès

e.	en vue de la confrontation des schémas de chiffres, permettre la spécification :
-	du nombre maximum de chiffres à collecter,
-	du nombre minimum de chiffres à collecter,
-	d'un schéma de chiffres utilisant une expression régulière.

f.	en vue du contrôle de la mémoire tampon des chiffres, permettre la spécification de :
-	la capacité de vider la mémoire tampon des chiffres avant d'exécuter l'invite initiale (le comportement par défaut est de ne pas vider la mémoire) ;
-	de vider par défaut la mémoire tampon après l'exécution d'un segment d'annonce non interruptible ;
-	de vider par défaut la mémoire tampon avant d'exécuter une ré-invite en réponse à une entrée invalide précédente.

g.	fournir une méthode pour spécifier la possibilité d'interrompre le DTMF sur la base du segment audio.

h.	permettre la spécification de séquences de clés définissables pour la collecte de chiffres DTMF pour :
-	éliminer les chiffres collectés en cours, re-exécuter l'invite, et reprendre la collecte des chiffres DTMF ;
-	éliminer les chiffres collectés en cours et reprendre la collecte des chiffres DTMF ;
-	terminer l'opération en cours et retourner la séquence de clés de terminaison au MGC.

i.	fournir un moyen de demander à la MG ARF de prendre en charge les clés définissables suivantes pour la collecte et l'enregistrement des chiffres. La MG ARF serait alors capable d'agir sur ces clés :
-	une clé pour terminer l'exécution d'une annonce en cours ;
-	un ensemble d'une ou plusieurs clés qui peuvent être acceptées comme le premier chiffre de la collecte ;
-	une clé qui signale la fin de l'entrée de l'utilisateur. La clé peut ou non être retournée au MGC avec les entrées déjà collectées ;
-	des clés pour arrêter l'exécution de l'annonce en cours et reprendre l'exécution au début du premier segment de l'annonce, du dernier segment de l'annonce, du précédent segment de l'annonce, du prochain segment de l'annonce, ou du segment d'annonce en cours.

 	11.2.8.3	Module d'enregistrement audio
Le module d'enregistrement doit prendre en charge toutes les exigences du module d'exécution en plus des exigences suivantes :

a.	être capable de fournir l'opération de base suivante :
-	demander à un AEG d'exécuter une annonce et ensuite d'enregistrer la voix.

b.	être capable de spécifier ces caractéristiques de collecte d'événements :
-	le nombre de tentatives permises à l'utilisateur de faire un enregistrement.

c.	par rapport aux temporisateurs d'enregistrement, permettre la spécification :
-	du temps à attendre avant que l'utilisateur commence à parler ;
-	la quantité de silence nécessaire à la suite du dernier segment de parole pour que l'enregistrement soit considéré comme terminé ;
-	la longueur maximum permise de l'enregistrement (non inclus le silence pré- et post- parole).

d.	être capable de permettre plusieurs opérations d'invite pour la collecte de chiffres DTMF (si c'est pris en charge), d'enregistrement vocal (si c'est pris en charge) d'analyse de reconnaissance de la parole (si c'est pris en charge) et/ou de vérification/identification de la parole (si c'est pris en charge) et ensuite de fournir les types d'invite suivants :
-	invite initiale
-	re invite
-	invite d'erreur
-	annonce d'échec
-	annonce. de succès

e.	permettre la spécification de séquences de clés définissables pour l'enregistrement de chiffres ou l'analyse de reconnaissance de la parole (si c'est pris en charge) pour :
-	éliminer l'enregistrement en cours, re-exécuter l'invite, et reprendre l'enregistrement ;
-	éliminer l'enregistrement en cours et reprendre l'enregistrement ;
-	terminer l'opération en cours et retourner au MGC la séquence de clés de terminaison.

f.	fournir un moyen pour demander à la MG ARF de prendre en charge les clés définissables suivantes pour l'enregistrement. La MG ARF serait alors capable d'agir sur ces clés :
-	une clé pour terminer l'exécution d'une annonce en cours ;
-	une clé qui signale la fin de l'entrée de l'utilisateur. La clé peut ou non être retournée au MGC avec les entrées déjà collectées ;
-	des clés pour arrêter l'exécution de l'annonce en cours et reprendre l'exécution au début du premier segment de l'annonce, du dernier segment de l'annonce, du précédent segment de l'annonce, du prochain segment de l'annonce, ou du segment d'annonce en cours.

g.	alors que les invites audio sont généralement provisionnées dans les MG IVR/ARF, la prise en charge du changement des invites provisionnées dans une session vocale plutôt que dans une session de données. En particulier, par rapport à la gestion audio :
-	une méthode pour remplacer l'audio provisionné par l'audio enregistré durant un appel. Le nouvel audio enregistré doit être accessible en utilisant l'identifiant de l'audio qu'il remplace ;
-	une méthode pour revenir de l'audio remplacé à l'audio provisionné à l'origine ;
-	une méthode pour prendre l'audio enregistré durant un appel et le mémoriser de telle façon qu'il ne soit accessible à l'appel en cours que par son propre identifiant unique qui vient d'être créé ;
-	une méthode pour prendre l'audio enregistré durant un appel et le mémoriser de façon qu'il soit accessible à tout appel ultérieur par son propre identifiant unique qui vient d'être créé.

 	11.2.8.4	Module de reconnaissance vocale
Le module de reconnaissance de la parole peut être utilisé pour un certain nombre d'applications de reconnaissance de la parole, telles que :
-	une reconnaissance de parole isolée de vocabulaire limité (par exemple, "oui", "non", le chiffre "quatre") ;
-	une reconnaissance de caractéristique de parole continue de vocabulaire limité (par exemple, la prononciation de "quatre cent trente trois Euros") et/ou
-	une reconnaissance de parole continue (par exemple, des tâches de reconnaissance de la parole non contraintes).

Le module de reconnaissance de la parole doit prendre en charge toutes les exigences du module d'exécution en plus des exigences suivantes :

a.	être capable de fournir l'opération de base suivante : demander à un AEG d'exécuter une annonce et d'effectuer ensuite une analyse de reconnaissance de la parole.

b.	être capable de spécifier ces caractéristiques de collecte d'événements :
-	le nombre de tentatives à accorder pour effectuer la tâche de reconnaissance de la parole.

c.	par rapport aux temporisateurs d'analyse de reconnaissance de la parole, permettre la spécification :
-	du temps à attendre pour que l'utilisateur commence à parler ;
-	la quantité de silence nécessaire à la suite du dernier segment de parole pour que le segment d'analyse de reconnaissance de la parole soit considéré comme terminé ;
-	la longueur maximum admissible de l'analyse de reconnaissance de la parole (non inclus le silence pré- et post- parole).

d.	être capable de permettre plusieurs opérations d'invite pour la collecte de chiffres DTMF (si c'est pris en charge), d'enregistrement vocal (si c'est pris en charge) et/ou d'analyse de reconnaissance de la parole et ensuite de fournir les types d'invite suivants :
-	invite initiale
-	re invite
-	invite d'erreur
-	annonce d'échec
-	annonce. de succès

e.	permettre la spécification de séquences de clés définissables pour l'enregistrement des chiffres (si c'est pris en charge) ou l'analyse de reconnaissance de la parole pour :
-	éliminer l'analyse en cours, répéter l'invite, et reprendre l'analyse ;
-	éliminer l'enregistrement en cours et reprendre l'analyse ;
-	terminer l'opération en cours et retourner au MGC la séquence de clé de terminaison.

f.	fournir un moyen pour demander à la MG ARF de prendre en charge les clés définissables suivantes pour l'analyse de la reconnaissance de la parole. La MG ARF serait alors capable d'agir sur ces clés pour que :
-	une clé termine l'exécution d'une annonce en cours ;
-	une clé signale la fin d'une entrée de l'utilisateur. La clé peut ou non être retournée au MGC avec les entrées déjà collectées ;
-	les clés arrêtent l'exécution de l'annonce en cours et reprennent l'exécution au début du premier segment de l'annonce, du dernier segment de l'annonce, du précédent segment de l'annonce, du prochain segment de l'annonce, ou du segment d'annonce en cours.

 	11.2.8.5	Module de vérification/identification de parole
Le module de vérification/identification de la parole retourne les paramètres qui indiquent la probabilité que le locuteur soit la personne qu'il prétend être (tâche de vérification) ou la probabilité que le locuteur soit une des personnes contenues dans un ensemble de locuteurs précédemment caractérisés (tâche d'identification).

Le module de vérification/identification du locuteur doit prendre en charge toutes les exigences du module d'exécution en plus des exigences suivantes :

a.	être capable de télécharger des paramètres, comme des gabarits de locuteur (tâche de vérification) ou des ensembles de gabarits de locuteurs potentiels (tâche d'identification) avant la session ou en cours de session ;

b.	être capable de télécharger un logiciel spécifique d'application à l'ARF, avant la session ou en cours de session ;

c.	être capable de retourner des paramètres indiquant la probabilité que le locuteur soit la personne qu'il prétend être (tâche de vérification) ou la probabilité que le locuteur soit une des personnes contenues dans un ensemble de locuteurs précédemment caractérisés (tâche d'identification).

d.	être capable de fournir l'opération de base suivante : demander à une AEG d'exécuter une annonce puis d'effectuer une analyse de vérification/identification de la parole.

e.	être capable de spécifier ces caractéristiques de collecte d'événements : le nombre de tentatives à donner pour effectuer les tâches de vérification/identification de parole.

f.	par rapport aux temporisateurs d'analyse de vérification/identification de parole, permettre la spécification :
-	du temps à attendre pour que l'utilisateur commence à parler ;
-	la quantité de silence nécessaire après le dernier segment de parole pour que le segment d'analyse de vérification/identification soit considéré comme complet ;
-	la longueur maximum admissible de l'analyse de vérification/identification de parole (non inclus le silence pré- et post- parole).

g.	être capable de permettre plusieurs opérations d'invite pour la collecte des chiffres de DTMF (si c'est pris en charge) l'enregistrement vocal (si c'est pris en charge) l'analyse de reconnaissance de la parole (si c'est pris en charge) et/ou la vérification/identification de la parole et fournir les types suivants d'invite :
-	invite initiale
-	re invite
-	invite d'erreur
-	annonce d'échec
-	annonce. de succès

h.	permettre la spécification de séquences de clés définissables pour l'enregistrement des chiffres (si c'est pris en charge) ou de reconnaissance de la parole (si c'est pris en charge) dans l'analyse de la vérification/identification de la parole pour :
-	éliminer la vérification/identification de la parole dans l'analyse, répéter l'invite, et reprendre l'analyse ;
-	éliminer l'analyse de vérification/identification de la parole en cours et reprendre l'analyse ;
-	terminer l'opération en cours et retourner la séquence de clés de terminaison au MGC.

i.	fournir un moyen de demander à la MG ARF de prendre en charge les clés définissables suivantes pour l'analyse de la vérification/identification de la parole. La MG ARF serait alors capable d'agir sur ces clés :
-	une clé pour terminer l'exécution d'une annonce en cours ;
- 	une clé qui signale la fin des entrées de l'utilisateur. La clé peut ou non être retournée au MGC avec les entrées déjà collectées ;
-	des clés pour arrêter l'exécution de l'annonce en cours et reprendre la vérification/identification de la parole au début du premier segment de l'annonce, du dernier segment de l'annonce, du précédent segment de l'annonce, du prochain segment de l'annonce, ou du segment en cours d'annonce.

 	11.2.8.6	Module d'extraction/reconnaissance des caractéristiques de l'auditoire
Le module d'extraction/reconnaissance des caractéristiques de l'auditoire est agencé pour surveiller en continu les flux auditifs pour l'apparition de signaux auditifs particuliers ou d'occurences de parole intéressantes et de rapporter ces événements (et facultativement une représentation de caractéristique de signal de ces événements) aux serveurs réseau ou aux MGC.

Le module d'extraction/reconnaissance des caractéristiques de l'auditoire doit prendre en charge les exigences suivantes :

a.	être capable de télécharger le logiciel spécifique d'application  à l'ARF avant la session ou en cours de session ;

b.	être capable de télécharger des paramètres, comme une représentation des caractéristiques auditives à extraire/reconnaître, avant la session ou en cours de session ;

c.	être capable de retourner des paramètres indiquant l'événement d'auditoire trouvé ou une représentation de la caractéristique trouvée (c'est-à-dire, la caractéristique auditive).

 	11.2.8.7	Module d'audio conférence
Le protocole doit prendre en charge :
a.	un mécanisme pour créer des conférences en multi-points d'audio seul et de conférences multimédia dans la MG ;
b.	le mixage audio, mélangeant plusieurs flux audio en un nouveau flux audio composite ;
c.	la commutation audio, choisissant un flux audio entrant à envoyer à tous les participants à la conférence.

 	11.2.9	Unités de contrôle multi points
Le protocole doit prendre en charge :
a.	un mécanisme pour créer des conférences en multi-points d'audio seul et de conférences multimédia dans la MG ;
b.	le mixage audio, mélangeant plusieurs flux audio en un nouveau flux audio composite ;
c.	la commutation audio, choisissant un flux audio entrant à envoyer à tous les participants à la conférence ;
d.	la commutation vidéo; choisissant un flux vidéo à envoyer à tous les participants à la conférence ;
e.	la lecture en mode video, une option de sélection de vidéo où la source de vidéo est envoyée à tous les utilisateurs de la conférence ;
f.	le multi-points de conférence de données T.120 ;
g.	la capacité pour la MG de fonctionner comme un MP H.323, et pour le MGC de fonctionner comme un MC H.323, connecté par ce protocole (MEGACOP/H.248). Il devrait être possible que des MG/MP audio, de données, et de vidéo soient physiquement séparés tout en étant sous le contrôle d'un seul MC MGC/H.323.

 	12.	Références

[GHMTOA]	ATM Forum Technical Committee, af-saa-0124.000, "Gateway for H.323 Media Transport Over ATM", mai  1999.

[H.323]	Recommandation UIT-T H.323v3, "Systèmes de communication multimédia fondés sur le paquet" (inclut l'Annexe C - H.323 sur ATM), UIT, Genève, septembre 1999.

[H.341]	Recommandation UIT-T H.341, "Transmission en ligne de signaux non téléphoniques", UIT, Genève, mai 1999.

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

[Q.2630.1]	Recommandation UIT-T Q.2630.1, "Ensemble de capacités n°  1de protocole de signalisation AAL type 2",(Union Internationale des Télécommunications, Genève, décembre 1999).

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

[T.140]	Recommandation UIT-T T.140, "Protocole pour conversation textuelle d'application multimédia", (Union Internationale des Télécommunications, Genève, février 1998).

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

[VTOA]	ATM Forum Technical Committee, af-vtoa-0083.001, "Voice and Telephony Over ATM to the Desktop Specification", mars 1999.

 	13.	Remerciements

Les auteurs tiennent à remercier les nombreux contributeurs qui ont participé au débat sur l'architecture et les exigences du contrôle de passerelle de supports sur les listes de diffusion Megaco et Sigtran de l'IETF. Des contributions au présent document ont aussi été faites sur les projets Internet et des discussions avec les membres de ETSI Tiphon, du SG16 de l'UIT-T, du TIA TR41.3.4, de l'ATM Forum, et du Multiservice Switching Forum.

 	14.	Adresse des auteurs

Nancy Greene	Michael A. Ramalho	Brian Rosen	
Nortel Networks	Cisco Systems	Marconi	
P.O. Box 3511 Stn C	1802 Rue de la Port	1000 FORE Drive, Warrendale, 	
Ottawa, ON, Canada K1Y 4H7	Wall Township, NJ USA	PA 15086, USA	
téléphone : (514) 271-7221	téléphone : +1.732.449.5762	téléphone : (724) 742-6826	
mél : ngreene@nortelnetworks.com 	mél : mramalho@cisco.com 	mél : brosen@eng.fore.com 	

 	15.	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 le besoin 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.