Vous êtes sur la page 1sur 29

Le protocole H323

• Architecture et fonctionnalités du protocole H.323


Le protocole H.323 s’articule autour d’une
architecture particulière décrite dans ce qui suit.
Cette architecture concentre les fonctionnalités
autour d’entités, ce qui explique pourquoi le
protocole H.323 est considéré comme fortement
centralisé. Nous allons définir et détailler chacune
des entités introduites par le protocole H.323.
Les quatre entités d’une architecture H.323
1. Terminaux (au minimum deux). Ce sont
les équipements de traitement destinés aux
utilisateurs, leur permettant d’émettre et de
recevoir des appels. Deux terminaux doivent
au minimum être présents pour qu’une
communication ait lieu.
2.Gatekeeper, ou garde-barrière. C’est l’équipement
permettant la localisation des utilisateurs.
Ces derniers peuvent s’identifier entre eux par des
noms, auxquels il faut attribuer l’adresse IP
correspondante dans le réseau ou, si l’appelé n’est pas
situé dans un réseau IP, la localisation de l’entité
intermédiaire à joindre pour l’appel. Outre cette
fonction primordiale, un gatekeeper remplit tout un
ensemble de fonctions complémentaires de gestion et
de contrôle des communications, certaines étant
indispensables et d’autres facultatives.
3.Passerelle, ou gateway. C’est l’équipement
permettant à des utilisateurs du réseau IP
de joindre les utilisateurs qui sont actifs sur
d’autres types de réseaux téléphoniques,
RTC, RNIS ou ATM. On peut avoir autant de
passerelles différentes que nécessaire,
suivant la nature des réseaux non-IP à
interconnecter.
4.MCU (Multipoint Control Unit), ou unité de contrôle
multipoint, parfois appelée pont multipoint. C’est
l’équipement permettant la gestion des conférences, c’est-à-
dire les communications multimédias mettant en jeu plus de
deux interlocuteurs. Ces derniers doivent préalablement se
connecter à la MCU, sur laquelle s’établissent les demandes
et négociations des paramètres à utiliser lors de la
conférence.
Zone et système H.323. La nomenclature H.323 définit deux notions qu’il
convient de bien connaître et différencier :

– Un système H.323 est défini comme un ensemble de deux terminaux au


minimum, d’autres éléments pouvant être ajoutés.
– Une zone H.323 est un ensemble de deux terminaux avec un gatekeeper au
minimum, d’autres éléments pouvant être ajoutés.
Le gatekeeper, point de contrôle et de gestion
Facultatif de manière générale, le gatekeeper est requis pour toutes les opérations de
contrôle et de gestion des communications.

Localisation des abonnés


Pour permettre la localisation des utilisateurs dans un réseau IP utilisant H.323, le
gatekeeper effectue la conversion d’un alias en une adresse IP.
Un alias est un identifiant associé à un utilisateur. Chaque utilisateur est localisé dans le
réseau IP par une adresse IP, mais cette adresse peut être attribuée dynamiquement.
Un alias peut être défini de plusieurs façons :
• une adresse de type e-mail, éventuellement préfixée de l’indication h323: spécifiant
qu’il s’agit d’un alias H.323 ;
• une adresse de type numéro de téléphone (recommandation E.164 de l’UIT-T) ;
• une chaîne de caractères Unicode quelconque ;
• une adresse de type URL ;
• une adresse IP, éventuellement suffixée du numéro de port à utiliser.
Les adresses suivantes sont donc des alias H.323 valides : albert@domaineH323.com,
albert323, 132.227.55.155:1720, 0323323323, etc.
La translation d’un alias vers une adresse IP est illustrée à la figure 1
Lors de sa connexion au réseau IP, Bertrand indique au gatekeeper sa localisation dans le
réseau(étape 1), comme tout utilisateur qui se connecte. Le gatekeeper a sauvegardé cette
association de l’alias avec l’adresse IP correspondante dans sa base de données. Lorsqu’Alice
souhaite joindre Bertrand, elle ignore sa localisation mais dispose de son alias. En sollicitant
le gatekeeper (étape 2), Alice peut donc déterminer la localisation de Bertrand
(étape 3) puis initier un appel vers ce dernier (étape 4). Nous verrons plus loin à quelles
requêtes et réponses correspond chacune de ces étapes.
Autres fonctionnalités du gatekeeper

• Contrôle d’admission. Si la bande passante ne permet pas d’établir un nouvel appel


dans une zone H.323, la passerelle est habilitée à interdire de nouveaux appels et à
établir une liste de priorités d’appels licites.
• AAA (Authentication, Authorization, Accounting), ou authentification, autorisation et
comptabilisation. L’authentification permet de connaître l’identité de la personne
connectée, tandis que l’autorisation indique quels sont les droits (et éventuellement les
conditions) attribués à la personne qui s’est authentifiée.
• Gestion des flux. Le gatekeeper peut implémenter un gestionnaire de bande passante
pour décider de l’allocation de bande affectée aux terminaux. Il est en outre possible de
limiter le nombre d’intervenants dans une conférence et de rejeter certaines demandes
de flux (par exemple en n’autorisant que la voix à un utilisateur qui réclame l’audio et la
vidéo).
Optionnellement, il est possible d’implémenter au sein de ce serveur des fonctionnalités
de gestion et de surveillance de la zone H.323 de façon à assurer divers services,
notamment les suivants :
• gestion des coûts, par le biais d’un système de facturation s’interfaçant avec les appels
et calculant la durée de chaque communication ;
• mise en place d’annuaire, particulièrement utile en entreprise, mais tout aussi
disponible dans un cadre plus vaste ;
• gestion des appels avec différents services proposés, notamment le transfert d’appel, la
mise en attente, la restriction d’appels en provenance de terminaux spécifiques ou bien
à des horaires déterminés, entre autres possibilités ;
• historique des appels effectués, sauvegardés dans des journaux et ultérieurement
exploitables ;
• génération de statistiques d’utilisation.

Signalisation routée et directe


Pour mettre en relation deux utilisateurs, il est possible d’utiliser deux moyens
différents pour faire transiter la signalisation dans le réseau :
• un mode indirect, ou routé, la signalisation entre les correspondants passant par le
gatekeeper;
• un mode direct, la signalisation entre les correspondants ne faisant intervenir que ces
correspondants, sans entité intermédiaire.
Les messages H.323
Bien plus qu’un protocole, H.323 renvoie à une plate-forme complète décrivant comment
des protocoles se combinent pour assurer la signalisation. Pour être fonctionnel, H.323
doit impérativement utiliser d’autres protocoles, qui forment son ossature. Les plus
importants d’entre eux sont les standards fondamentaux H.225.0, qui exploite les
protocoles
RAS et Q.931, hérités du RNIS, et H.245.
Le protocole H.225.0 met en place un canal de signalisation d’appel et d’enregistrement
afin d’assurer la mise en relation des interlocuteurs. Le protocole H.245 permet quant à
lui de créer un canal de contrôle pour la négociation des paramètres de la communication
(codeur utilisé, contrôle de flux, etc.).
Les couches protocolaires de ce modèle sont illustrées à la figure ci-dessous.
Le protocole H.225.0, signalisation d’appel et d’enregistrement
Le protocole H.225.0 est utilisé pour permettre la signalisation d’appel et la signalisation
d’enregistrement (avec le contrôle d’admission). Ces deux types de signalisation sont
assurés par les protocoles RAS (Registration Admission Status) et Q.931.

La signalisation d’appel avec Q.931


La signalisation d’appel permet l’établissement d’un appel, la libération de la
communication et la transmission des messages indiquant l’état d’un appel (occupation
d’un poste, redirection, etc.). Elle regroupe les fonctionnalités de mise en paquet, de
synchronisation, de multiplexage et de confidentialité.

Les cinq messages fondamentaux suivants doivent obligatoirement être supportés :


• SETUP : envoyé pour initier et établir une communication avec un terminal H.323.
• ALERTING : indique que le poste appelé est en train de sonner et que l’appelant se met
en attente de sa réponse.
• CONNECT : indique que la communication peut débuter.
• RELEASE COMPLETE : envoyé pour initier la terminaison de l’appel.
• STATUS FACILITY : envoyé pour demander des services complémentaires.
Nous allons montrer comment s’effectuent l’ouverture et la fermeture d’un canal de
signalisation d’appel, en restreignant le scénario aux seules étapes qui relèvent de la
signalisation Q.931 (sans la localisation de l’appelé notamment).
Exemple 1. Ouverture du canal de signalisation d’appel
L’ouverture d’un canal de signalisation d’appel se fait généralement en trois étapes :
1. Message SETUP : l’appelant contacte son correspondant
2. Message ALERTING : la sonnerie du terminal appelé retentit, et le terminal se met en
attente de la réponse du correspondant.
3. Message CONNECT : dès que l’appelé a décroché, ce message prévient l’appelant de
la disponibilité de son interlocuteur.
Ce scénario est illustré à la figure ci-dessous.
Exemple 2. Fermeture du canal de signalisation d’appel
La fermeture d’un canal de signalisation d’appel se fait à l’initiative de l’interlocuteur qui
a raccroché son combiné, mettant fin à la conversation.
Un message RELEASE COMPLETE est envoyé pour fermer le canal de signalisation d’appel.
Ce scénario est illustré à la figure ci-dessous.
La signalisation d’enregistrement avec RAS
Le protocole RAS (Registration Admission Status) intervient pour les dialogues entre les
terminaux et le gatekeeper, donc nécessairement dans une zone H.323.
Entre le terminal et le gatekeeper, on parle d’interface RAS pour indiquer que des
messages RAS sont échangés entre ces deux entités. Le protocole RAS utilise UDP comme
protocole de transport et les ports 1719 pour la diffusion d’un message à un seul
destinataire(mode unicast) et 1718 pour les diffusions multiples (mode multicast).
Généralement, tous les messages sont envoyés en unicast.
Messages RAS génériques
Les messages RAS sont relativement simples et ressemblants. Chaque action possède
généralement les trois déclinaisons de messages suivantes :
• XRQ : indique un message RAS de requête (REQUEST).
• XRJ : indique un message RAS de rejet de la requête (REJECT).
• XCF : indique que la requête a été correctement traitée (CONFIRM).
Le caractère X est ici générique et concerne n’importe quel message. Le tableau 3.1
récapitule les principales requêtes du protocole RAS. Chacune d’elles dispose des
déclinaisons de réponse XRJ et XCF.
Exemple 1. Enregistrement d’un terminal auprès d’un gatekeeper
Lorsqu’un terminal se connecte dans une zone H.323, il doit s’enregistrer auprès du
gatekeeper de la zone afin de lui indiquer sa présence dans le réseau, et donc sa
disponibilité potentielle. Cela permet de recenser les terminaux pour ensuite fournir le
service de localisation d’un utilisateur, soit à un terminal appelant, soit à un autre
gatekeeper.
Le terminal fournit dans sa requête d’enregistrement son adresse IP associée à son
identifiant H.323. De cette manière, tout utilisateur souhaitant joindre un terminal
enregistré auprès du gatekeeper peut solliciter ce dernier en lui mentionnant l’identifiant
H.323 du terminal à joindre. Dans le même temps, le terminal réclame au gatekeeper de
disposer des services auxquels il a droit.
Ce scénario d’utilisation classique est illustré à la
Figure ci-contre
Le protocole H.245, la signalisation de contrôle de connexion
Le protocole H.245 gère l’ouverture du canal de contrôle, l’établissement du canal de
transmission, la négociation des paramètres (comme le codec utilisé) et le contrôle de flux
ainsi que la fermeture du canal de contrôle. Comme pour le protocole Q.931, tous les
messages H.245 ne sont pas exploitables dans le protocole H.323, qui n’en utilise qu’une
faible proportion.
Initialement, les messages H.245 ne devaient être diffusés qu’après le message Q.931
SETUP. Pour optimiser les temps d’établissement d’une communication, les versions
suivantes de H.323 ont fortement suggéré que les échanges H.245 s’établissent en parallèle
ou même avant le message Q.931 SETUP.
Le message TCS
Le message TCS (TERMINALCAPABILITYSET) est obligatoirement le premier envoyé dans
le canal H.245. Il indique les capacités du terminal qui émet ce message, notamment le
type de média (audio, vidéo, données) et les codecs qu’il supporte.
Chaque terminal envoie la liste de ses capacités, généralement par ordre de préférence,
dans un message TCS. À réception, un message d’acquittement TERMINALCAPACITYSETACK
est retourné.
La figure suivante illustre les échanges de capacités entre deux terminaux.
Exemple
Le message OLC
Le message OLC (OPENLOGICALCHANNEL) permet d’ouvrir un canal de signalisation de
contrôle (on dit aussi canal logique). Celui-ci indique le type de données multimédias
transmis et les codecs utilisés.
L’ouverture d’un canal logique se fait généralement sur un port TCP, mais peut tout aussi
bien s’effectuer en UDP. Comme le canal n’est pas bidirectionnel, chaque terminal doit
avoir un canal logique en utilisant le message OPENLOGICALCHANNEL. Ce message
assigne un identifiant de session (session ID) à la communication. Par défaut, la session 1
est attribuée à une communication audio, la session 2 à une communication vidéo et la
session 3 à une communication de données.
Le message doit en outre utiliser un codec sélectionné parmi ceux que le correspondant a
préalablement mentionnés dans la requête TCS. Un message d’acquittement
OPENLOGICALCHANNELACK
valide la requête.
La figure suivante illustre l’ouverture d’un canal de contrôle entre deux terminaux.
Exemple
Exemple: si on veut enrichir le trafic audio par la vidéo
Les messages CLC et ESC
Deux messages distincts sont nécessaires pour clôturer un canal de signalisation de
contrôle : le message CLC (CLOSELOGICALCHANNEL), qui attend un acquittement
CLOSELOGICALCHANNELACK, et le message ESC (ENDSESSIONCOMMAND), qui doit être
émis par chaque intervenant.
La figure 3.21 illustre la fermeture d’un canal de contrôle entre deux terminaux.
Exemple de scénario d’une
communication complète
4. Fonctionnement simplifié :
Cas 1 : communication « point à point » de deux clients simples :
Cas 2 : communication « point à point » entre deux clients enregistrés auprès d'un
gatekeeper

Cas 3 : communication « Multipoints » entre plusieurs clients (MCU nécessaire) :


Cas 4 : 3 Gatekeeper

Cas 5 : autres

Dans un cas réel, il est probable que l’architecture comprenne les éléments suivants :

• Une ou plusieurs passerelles vers le RTC ou vers d’autres réseaux de ToIP.


• Des serveurs de messageries vocales (MCU avec capacité d’enregistrement)
• Des serveurs (MCU) capable de diffuser des messages réseau (signaux
d’occupation, de mise en attente, …)
Exemple d'un échange protocolaire H.323

Vous aimerez peut-être aussi