LL

FA
AR
AT
M
PE
PA

matarpape@gmail.com
 PLAN

LL
INTRODUCTION

FA
HISTORIQUE

ARCHITECTURE ET FONCTIONNEMENT

AR
Principes d’établissement d’une communication

AT
les messages MGCP

Identifiant de transaction
M
Paramètres généraux pour les requêtes et les réponses
PE

Conclusion
PA

matarpape@gmail.com
 LL
FA
La question de la communication entre des réseaux de

AR
nature différente(ATM, RNIS, RTC ou IP) ou bien de
même nature mais exploitant des protocoles de

AT
signalisation différents (H.323, SIP ou autre) “engendra ”
l’idée de la création d’un nouveau protocole, pour
combler ce nouveau besoin, le protocole MGCP (Media
M
Gateway Control Protocol), ou protocole de contrôle des
passerelles multimédias, a été proposé.
PE
PA

matarpape@gmail.com
 LL
Pourquoi le MGCP

FA
On peut s’interroger sur la nécessité d’adopter un
nouveau protocole dans un contexte où le protocole SIP,

AR
réputé plus simple que H.323, a du mal à s’imposer
compte tenu de la forte pénétration de ce dernier.

AT
Les raisons de l’avènement du MGCP
 Centralisation et Asymétrie
M
Indépendance et Compatibilité
PE
PA

matarpape@gmail.com
 RESEAU A

LL
SIGNALISATION A CONTEXTE
TOUS CES 3 RESEAUX
APPARTIENT A UN MEME

FA
LES 3 RESEAUX OPERATEUR QUI VEUX
SONT DIFFERENT INTERCONNECTER SES 3
A SUPPOSER QUE RESEAUX OU A 3

AR
LE RESEAU A OPERATEURS QUI
VEULENT
SOIT UN RESEAU IP, INTERCONNECTER LEUR 3
RESEAUX
LE RESEAU B

UN RESEAU RTC
AT
ET LE RESEAU C
CES 3 RESEAUX
UNTILISENT CHACUN UN
PROTOCOLE DE
M
SIGNALISATION BIEN
SPECIFIQUE ET
UN RESEAU RNIS DIFFERENT DES AUTRES
PE

RESEAU B RESEAU C
PA

SIGNALISATION B SIGNALISATION C
matarpape@gmail.com
 LL
FA
AR
Il fonctionne au niveau applicatif et permet d’offrir une
couverture plus large en fédérant toutes les signalisations,
qu’elles soient de type IP ou RTC entre autres. C’est le

AT
maître d’œuvre de l’interopérabilité entre tous les
protocoles de signalisation et tous les réseaux, de quelque
nature qu’ils soient.
M
PE
PA

matarpape@gmail.com
 LL
Fruit de réflexions communes, le protocole MGCP a synthétisé des concepts énoncés par

FA
différents groupes.

L’architecture générale conceptualisant les entités de contrôleur et de passerelle

multimédia, et plus généralement le modèle maître-esclave, fut initialement proposée dans

AR
le projet TIPHON (Telecommunications and Internet Protocol Harmonization Over
Networks) de l’ETSI. La première tentative de protocole de communication entre ces entités
fut SGCP (Simple Gateway Control Protocol), en 1997. Proposée par Telcordia

AT
(anciennement BellCoRe, acronyme de Bell Communications Research), elle reçut le
soutien de Cisco. TIPHON est le protocole précurseur de MGCP.

En 1998, l’opérateur de télécommunications Level 3 Communications (groupe XCOM

M
Technologies) a mis en place un comité consultatif technique, ou TAC (Technical Advisory
Council), réunissant une douzaine d’industriels renommés, comme Ericsson, Lucent,
Nortel, Alcatel, 3Com et Cisco. Avec ces membres fondateurs, le TAC sera à l’origine de la
PE

conception d’un protocole de contrôle des entités réseau sur Internet, nommé IDCP
(Internet Device Control Protocol). Ses spécifications seront présentées à
PA

l’UIT, à l’IETF et à l’ETSI.

matarpape@gmail.com
 LL
FA
AR
En octobre 1998, avec le soutien d’importants constructeurs, tels que Cisco et
Alcatel, le protocole MGCP a été standardisé à l’IETF par le groupe de travail
MeGaCo (Media Gateway Control). Celui-ci réalisait la fusion des initiatives

AT
SGCP et IDCP. MGCP s’inscrit dans la droite ligne de la version 1.1 du protocole
SGCP, qui servira de socle principal à MGCP.
En plus de dériver de SGCP, MGCP s’est enrichi de nombreuses fonctionnalités
M
proposées dans IDCP. En octobre 1999, la RFC 2705 présentait la première
version de MGCP. Elle sera rendue obsolète en janvier 2003 par la RFC 3435, qui
sera complétée par la RFC 3661 en décembre 2003.
PE
PA

matarpape@gmail.com
 LL
1997 TELCORDIA TAC 1998

FA
SGCP IDCP

AR
MEGACO

AT
FUSION Octobre 1998
M
MGCP
PE

Décembre 1998
PA

matarpape@gmail.com
 LL
Architecture et fonctionnement

FA
AR
MGCP fonctionne selon une architecture centralisée permettant de faire communiquer
et de contrôler différentes entités appartenant à des réseaux distincts. Il se fonde sur

AT
l’hypothèse que les terminaux des utilisateurs peuvent être des composants de base, peu
coûteux et sans aucune intelligence, réduits à des fonctionnalités élémentaires.
Pour réaliser cette distinction, MGCP définit les entités suivantes :
M
• Le Call Agent, qui sert à piloter et administrer les passerelles de manière centralisée.
• Les passerelles, qui maintiennent la connectivité entre réseaux de nature différente
PE
PA

matarpape@gmail.com
 RESEAU A

LL
SIGNALISATION A

FA
PASSERELLE
PASSERELLE
MULTIMEDIA
MULTIMEDIA

AR
CALL AGENT

AT
M
RESEAU B
RESEAU C
SIGNALISATION B
SIGNALISATION C PASSERELLE
MULTIMEDIA
PE
PA

Architecture MGCP matarpape@gmail.com

 LL
Call Agent

FA
AR
Le Call Agent ou encore SoftSwitch a pour fonction de contrôler les passerelles et de
concentrer toute l’intelligence ainsi que la prise de décision dans le réseau. Il est

AT
spécifiquement responsable de la signalisation des appels établis entre des terminaux
appartenant à des réseaux de nature différente.
il contribue à centraliser le réseau autour de lui, cette centralisation n’intervient que
pour
M
arbitrer et assurer la maintenance et la gestion des échanges de signalisation
PE
PA

matarpape@gmail.com
 LL
Les passerelles multimédias

FA
Passerelle d’opérateur téléphonique, pour faire le lien entre un réseau téléphonique et
un réseau IP.
Passerelle résidentielle de type box (boîtier exploitant le modem, le câble ou les

AR
technologies xDSL), généralement mise à disposition par le FAI.
PBX d’entreprise faisant la liaison entre le réseau IP de l’entreprise et le réseau
téléphonique RTC de l’opérateur.

AT
Le rôle de la passerelle multimédia est donc réduit à l’acheminement cohérent des
données, ce qui implique qu’elle accomplisse les tâches suivantes :
• conversion du signal ;
M
• adaptation au support ;
• compression des données ;
PE

• conversion de la signalisation ;
• multiplexage ;
• mise en paquets.
PA

matarpape@gmail.com
 Principes d’établissement d’une communication

LL
Call Agent

FA
AR
Passerelle
multimédia
N°1
AT Passerelle
M
multimédia
N°2
PE
PA

Endpoint 1 matarpape@gmail.com

Endpoint 2
 LL
les messages MGCP

FA
AR
Ligne de requête ou de réponse

AT
En-tête
M
PE

Corp du message
PA

FORMAT D’UN MESSAGE MGCP

matarpape@gmail.com
 LL
FA
AR
on distingue trois parties :
• Ligne de requête ou de réponse : notifie la commande à exécuter (s’il s’agit
d’une requête) ou le résultat de la commande (s’il s’agit d’une réponse).

AT
C’est une partie indispensable.
• En-tête : spécifie la liste des paramètres du message. C’est une partie
facultative.
M
• Corps du message : décrit les paramètres de la session à établir. C’est une
partie facultative.
PE
PA

matarpape@gmail.com
 LL
Adressage des endpoints

FA
L’adressage d’un endpoint est représenté dans un format semblable à l’e-mail, dans

AR
le respect de la RFC 821.
Sa syntaxe est la suivante :
endpoint@domaine[:port]

AT
La partie domaine spécifie le nom de domaine absolu, conformément à la RFC 1034
(DNS), incluant le nom de la passerelle permettant d’accéder au domaine. Par
exemple, un nom de domaine peut être :
M
ma_passerelle.mon_domaine.fr
Le nom de domaine peut aussi être spécifié par une adresse MAC ou une adresse IP,
au format IPv4 ou IPv6, à condition de l’indiquer entre crochets.
PE

Elle est définie selon trois niveaux hiérarchiques séparés par le symbole /, de la
façon suivante :
niveau_hierachique_1/niveau_hierachique_2/niveau_hierachique_3
PA

matarpape@gmail.com
 LL
FA
AR
L’adressage d’un Call Agent est comparable à celui des endpoints. Il respecte la

AT
syntaxe
suivante :
callagent@domaine[:port]
Les restrictions de nommage des parties callagent et domaine sont semblables à
M
celles concernant les endpoints.
PE
PA

matarpape@gmail.com
 LL
Identifiant de transaction

FA
Pour corréler une requête avec sa ou ses réponses, le protocole MGCP utilise un code

AR
appelé identifiant de transaction.
L’identifiant de transaction permet en outre à une entité (une passerelle ou le Call
Agent) de repérer des éventuelles duplications de message.

AT
Il existe deux possibilités qu’un message soit dupliqué :
• Pour une passerelle, il y a duplication entre deux messages reçus si les deux
messages comportent le même identifiant de transaction.
• Pour un Call Agent, il y a duplication entre deux messages reçus si les deux messages
M
comportent à la fois le même identifiant de transaction et le même nom de passerelle
à l’origine du message.
PE

L’identifiant de transaction correspond à un nombre strictement compris entre 0 et

un million (ces deux valeurs n’étant pas incluses). Comme ces valeurs sont limitées,
les identifiants peuvent être réutilisés, mais au minimum trois minutes après
PA

l’utilisation de ce code.
matarpape@gmail.com
 LL
Paramètres généraux pour les requêtes et les réponses

FA
AR
Les en-têtes et corps d’un message sont communs à tous les messages MGCP.
En-tête d’un message
Cette partie est, selon les messages, obligatoire, optionnelle ou interdite. Elle

AT
mentionne des attributs caractérisant le message.
Le format général d’un paramètre d’en-tête respecte le modèle suivant :
nom_paramètre:valeur_paramètre
M
Le nom du paramètre est formé d’un ou de deux caractères (lettre ou chiffre).
Corps d’un message
Cette partie est, selon les messages, obligatoire, optionnelle ou interdite. Elle
PE

mentionne des attributs relatifs à la communication sollicitée. Elle est implémentée

en utilisant le protocole SDP, introduit à l’exposé précédent dédié à SIP
PA

matarpape@gmail.com
 LL
FA
AR
La ligne d’état MGCP
La ligne d’état est constituée des quatre éléments suivants:

AT
• Requête : indique l’action qui va être entreprise par ce message.
• Identifiant : tel qu’il a été présenté précédemment.
• Destination : spécifie l’adresse de la ou des destinations concernées par le
M
message.
• Version : indique la version du protocole MGCP utilisée
PE
PA

matarpape@gmail.com
 LL
Les requêtes

FA
AR
Le protocole MGCP définit neuf requêtes permettant de spécifier l’action à
entreprendre. Les commandes sont lancées entre le Call Agent et les passerelles
(Media Gateway).

AT
Comme MGCP est un protocole de type maître-esclave, toutes les entités n’ont pas
des possibilités comparables, et ces commandes ne peuvent être lancées qu’à
l’initiative de l’une de ces entités, soit le Call Agent, soit la Media Gateway.
M
À chaque requête correspond un code en quatre lettres de caractères ASCII, qui
permet de condenser la taille de la requête.
Le protocole MGCP étant extensible, d’autres requêtes pourront venir l’enrichir
PE

dans les prochaines versions.

PA

matarpape@gmail.com
 LL
Format des neuf requêtes MGCP

FA
AR
Format complet Format abrégé

AUDITCONNECTION AUCX
AUDITENDPOINT
CREATECONNECTION
DELETECONNECTION
AT AUEP
CRCX
DLCX
M
ENDPOINTCONFIGURATION EPCF
MODIFYCONNECTION MDCX
NOTIFICATIONREQUEST RQNT
PE

NOTIFY NTFY
RESTARTINPROGRESS RSIP
PA

matarpape@gmail.com
 LL
Du Call Agent vers les passerelles

FA
AR
Le Call Agent peut agir sur les passerelles dont il a le contrôle par l’intermédiaire de

AT
sept commandes.
CreateConnection
ModifyConnection
DeleteConnection
M
NotificationRequest
AuditEndpoint
AuditConnection
PE

EndpointConfiguration
PA

matarpape@gmail.com
 LL
FA
D’une passerelle vers le Call Agent

AR
AT
Une passerelle dispose de trois commandes pour communiquer avec le Call Agent,
dont l’une est similaire à celle qu’utilise le Call Agent.
DeleteConnection
M
Notify
RestartInProgress
PE
PA

matarpape@gmail.com
 LL
Les réponses MGCP

FA
Toutes les requêtes MGCP sont acquittées par un message de réponse.

AR
ETAT EN-TÊTE CORP

AT
M
PE

CODE REPONSE ID COMMENTAIRE

PA

matarpape@gmail.com
 LL
FA
Comme pour SIP, les messages de réponse à une requête sont envoyés par un code de
retour à trois chiffres. Là aussi, on distingue plusieurs catégories de codes de retour,
assez comparables à ceux de SIP.

AR
Le premier chiffre d’un code de retour désigne la catégorie de code de retour à
laquelle le code appartient. Le tableau suivant indique quelques codes d’état qui ont
été définis et les catégories auxquelles ils appartiennent.

Code d’état
0xx – Messages d’acquittement AT Commentaire
La requête a bien été reçue.
M
000 Réponse d’acquittement (indique
seulement la réception de la requête).
1xx – Message d’information C’est une réponse temporaire, qui informe
PE

l’émetteur. Une réponse définitive sera émise

plus tard.
100 La requête est en cours de traitement.
PA

matarpape@gmail.com
 LL
FA
Les codes de retour numérotés de 800 à 899 et 903 à 905 inclus sont réservés pour les
paquetages.

AR
Les codes de messages non définis sont interprétés selon la correspondance établie
au tableau suivant:

AT
Code d’erreur inconnu commençant Interprété comme s’il s’agissait du
par le chiffre code
0 000
1 100
M
2 200
3 521
PE

4 400
5, 6, 7, 8 ou 9 510
PA

matarpape@gmail.com
 LL
Un message de réponse complet serait de la forme suivante :

FA
AR
200 1204 OK
I: FDE234C8

v=0
AT
o=- 25678 753849 IN IP4 128.96.41.1
M
s=-
c=IN IP4 128.96.41.1
t=0 0
PE

m=audio 3456 RTP/AVP 96

a=rtpmap:96 G726-32/8000
PA

matarpape@gmail.com
 LL
Conclusion

FA
AR
Comme il se place en parallèle des protocoles de signalisation intérieurs des réseaux,
MGCP ne souffre pas vraiment de concurrence. Il est du reste le protocole de
référence pour les fournisseurs d’accès à Internet, qui l’utilisent afin de contrôler les

AT
équipements qu’ils mettent à disposition des utilisateurs.
Tandis que l’avenir des protocoles H.323 et SIP semble se profiler avec la
spécification d’un protocole de nouvelle génération, H.325, conçu par l’UIT pour
M
simplifier notamment la gestion des équipements de contrôle, de la qualité de
service et du passage par les pare-feu d’entreprise, l’avenir de MGCP semble quant à
lui serein.
PE

Son successeur annoncé MeGaCo existe depuis l’année 2000, sans véritablement
susciter d’intérêt chez les équipementiers ni manifester de véritables innovations
qui justifieraient un changement de protocole.
PA

matarpape@gmail.com