H.

323
Architecture et Protocoles
EFORT http://www.efort.com

Avec le dveloppement du multimdia sur les rseaux en mode paquet, il est devenu ncessaire de dvelopper des protocoles qui supportent ces nouvelles fonctionalits telles que la voix, la vido et la visioconfrence avec un souci de donnes temps rel. Le protocole H.323 ddi ltablissement de sessions multimdia sur un rseau en mode paquet est lun dentre eux. Plus qu'un protocole, H.323 ressemble davantage une association de plusieurs protocoles diffrents et qui peuvent tre regroups en trois catgories : la signalisation, la ngociation de codec, et le transport de linformation. La recommandation H.323 a t spcifie par l'ITU-T (International Telecommunications Union - Telecommunications Sector). Le paragraphe 1 prsente les entits H.323 constituant une zone H.323. Le paragraphe 2 introduit la famille de protocoles H.323. Au paragraphe 3 sont dcrits les diffrents modes de signalisation possibles. Le paragraphe 4 montre le fonctionnement du protocole de signalisation RAS permettant le contrle des terminaux H.323. Le protocole de signalisation dappel Q.931 permettant aux terminaux dtablir des communications fait lobjet du paragraphe 5. Louverture et la fermeture de canaux de communication sont mises en oeuvre par le protocole de signalisation de commande H.245 dtaill au paragraphe 6. Enfin le paragraphe 7 montre comment offrir des services complmentaires dans un rseau H.323 grce aux recommandations H.450.x.

1. Zone H.323 et entits H.323

Les entits H.323 sont regroupes dans des zones (Figure 6.1). Une zone est un ensemble de terminaux, passerelles (Gateway, GW) et ponts de confrence (Multipoint Control Unit, MCU) grs par un mme portier (Gatekeeeper, GK). La zone comprend au moins un terminal et, ventuellement, des Gateways ou des MCUs. Une zone n'a qu'un seul Gatekeeper. La zone peut tre indpendante de la topologie du rseau et peut tre constitue de plusieurs segments de rseau connects l'aide de routeurs ou d'autres dispositifs. H.323 permet lchange de signalisation afin dtablir des canaux de communication pour le transport de flux multimdia entre endpoints o un endpoint peut tre un terminal, un Gateway ou un MCU.

1.1.

Terminal

Un terminal est un endpoint permettant des communications temps rels avec dautres endpoints. Il sagit dun quipement utilisateur tel quun PC ou un tlphone IP qui supporte au moins un codec audio et ventuellement dautres codecs audio et vido.

1.2.

Gateway

Un Gateway est un endpoint du rseau qui assure en temps rel des communications bidirectionnelles entre des terminaux H.323 et d'autres terminaux (e.g., terminaux RTC, RNIS, GSM).

Copyright EFORT 2008

Pour ce faire, le Gateway traduit dune part les protocoles de signalisation (e.g., ISUP H.323) et dautre part les formats des mdia (e.g., conditionnement du trafic vocal en paquets RTP).

T1 T2

T3

GK Zone 1

T4

T5

T6 T7

GW GW RTC PABX
GW : Gateway GK : Gatekeeper MCU : Multipoint Control Unit T : Terminal H.323 RTC : Rseau Tlphonique Commut

MCU Routeur

Zone 2

Figure 1 : Zone H.323

1.3.

Gatekeeper

Un Gatekeeper est le composant le plus important d'un rseau H.323. Il agit comme tant le point central pour tous les appels dans sa zone et contrle les endpoints. Un Gatekeeper H.323 agit comme un commutateur virtuel. Le Gatekeeper excute deux fonctions importantes. La premire est la translation d'adresse d'un alias LAN d'un terminal ou d'une passerelle (Gateway) vers une adresse IP ou IPX, comme le dfinit la spcification RAS. La deuxime fonction est la gestion de la bande passante, aussi dcrite dans la spcification RAS. Par exemple, si un administrateur rseau a spcifi un seuil pour un nombre simultan de confrences sur le LAN, le Gatekeeper peut refuser toutes les connexions qui seront au-del de ce seuil. Ceci a pour effet de limiter la bande passante pour de l'usage en confrence une fraction de la bande passante totale. La bande passante restante est rserve aux e-mails, aux transferts de fichiers, et autres protocoles du rseau. L'ensemble des terminaux, des Gateways et des Multipoint Control Units (MCUs) dirig par un seul Gatekeeper constitue une Zone H.323. Le Gatekeeper n'est pas obligatoire dans un rseau H.323 mais lorsqu'il existe, tous les quipements de la zone doivent dialoguer avec lui pour tablir des communications.

1.4.

Multipoint Control Unit (MCU)

Un MCU est un terminal qui supporte des confrences entre 3 (ou plus) terminaux. Il peut sagir dun quipement indpendant (e.g., PC) ou peut tre intgr dans un Gateway, un gatekeeper ou un terminal. Un MCU consiste en deux fonctions, savoir, contrleur multipoint (Multipoint Controller, MC) et processeur multipoint (Multipoint Processor, MP) La fonction MC met en uvre le contrle et la signalisation pour le support de la confrence alors que la fonction MP reoit les flux des terminaux, les traite, et les retourne aux terminaux participant la confrence. Il existe deux types de MCUs : MCU centralis (Figure 2) : Il met en uvre la signalisation (MC) et le traitement des flux (MP). Tous les terminaux envoient les flux audio et vido et les flux de contrle au MCU en mode point point. Sa fonction MC gre de manire centralise la confrence en utilisant les fonctions de contrle H.245 qui dfinissent entres autres les capacits de chaque terminal. Le MP ralise le mixage du trafic audio et vido. Puis, il met les flux

Copyright EFORT 2008

rsultants chaque participant. Le MP doit aussi convertir si ncessaire les diffrents codecs et dbits utiliss entre terminaux. MCU dcentralis : Il met en uvre la signalisation uniquement. Les flux sont changs directement entre les terminaux. Dans ce cas, le MCU fonctionne avec la fonction MC mais sans fonction MP.
Terminal H.323 AGW PABX

MC MP

MCU Terminal H.323 Terminal H.323 Signalisation Transport

Figure 2 : MCU centralis

2. Famille de protocoles H.323

H323 se dessine en 3 grandes parties (Figure 3). En effet, pour tablir une communication audio ou vido sur IP, le signal doit tre encod en utilisant des codecs normaliss dfinis dans la norme H323. H323 normalise aussi la signalisation utiliser pour ltablissement dune communication. La voix ou la vido est transmise en utilisant le protocole UDP, associ aux protocoles RTP et RTCP pour le transfert des donnes en temps rel. Parmi les codecs possibles figurent G.711, G.723 .1 et G.729 pour les signaux audio, et H.261 et H.263 pour les signaux vido. La signalisation pour ltablissement des appels est mise en uvre laide de trois protocoles : H.225 RAS (Registration, Admission and Status) : La signalisation RAS est utilise entre les endpoints et le Gatekeeper qui les contrle. RAS permet donc au Gatekeeper de contrler les endpoints prsents dans sa zone. H.225 Call signaling (Q.931) : Cette signalisation permet dtablir et de librer des connexions entre endpoints H.323. Les messages utiliss sont ceux du protocole de signalisation Q.931 modifis par la recommandation H.225. H.245 : Lorsque lappel dcroche, le protocole H.245 permet ltablissement de canaux RTP/RTCP permettant le transfert de donnes multimdia et le contrle de ce transfert. Les protocoles temps rel sur IP utiliss sont RTP et RTCP. RTP fournit un transport de bout en bout sur un rseau pour les applications transmettant des donnes en temps rel, telles que la voix ou la vido, en unicast et en multicast. RTP ne se proccupe pas de la rservation de ressources et ne garantit pas la qualit de service des transferts de donnes en temps rel. Le transport des donnes bnficie aussi du protocole de contrle RTCP qui fournit un contrle minimal et des fonctions didentification particulirement utiles dans le cas de rseaux multicast. RTP et RTCP sont conus pour tre indpendants des rseaux sousjacents.

Copyright EFORT 2008

Le protocole RAS utilise un transport UDP alors que les protocoles Call Signaling et H.245 sappuient sur un transport TCP.
Applications Audio/ Vido

Contrle et Gestion dun terminal H.323 H.225.0 Signalisation Terminal - GK (RAS) H.245 Logical Channel Signaling

G.nnn (audio) H.261 (vido) RTCP H.263 (vido) RTP UDP

H.225.0 Call Signaling

TCP IP Interface LAN

Figure 3 : Les protocoles H.323

3. Mode de signalisation
Le mode de signalisation dtermine quels sont les messages de signalisation qui sont changs par les endpoints travers le Gatekeeper et quels sont ceux directement changs entre endpoints (Figure 4). Passer par un Gatekeeper permet de mieux contrler lappel mais induit une surcharge. Cest au Gatekeeper de choisir le mode de signalisation que doivent appliquer les endpoints. Les donnes multimdia (voix, vido, donnes temps rel) sont toujours changes entre les endpoints. La signalisation RAS est toujours change entre un endpoint et un Gatekeeper. La signalisation dappel Q.931 (Call Signaling) est soit change directement entre endpoints (Direct Routed), soit change entre endpoints travers le Gatekeeper (Gatekeeper Routed). Si le mode est Direct Routed, alors le Gatekeeper a une connaissance limite de lappel et a une implication mineure dans la mise en place de cet appel. Par ailleurs il ne lui est pas possible de grer efficacement sa zone, e.g., mesurer avec prcision le taux dappel russis, et dispose de fonctions de taxation limites. De plus, si lappel requiert lactivation dun service (e.g., numro vert) prsent dans un serveur distant (e.g., serveur dapplication du Rseau Intelligent), lappel ne pourra pas aboutir. Par contre, ce mode permet au Gatekeeper de traiter un grand nombre dappel. Si le mode est Gatekeeper Routed pour la signalisation dappel, le Gatekeeper connat tout instant ltat de lappel et peut ainsi mieux contrler lappel, laccs au service (en disposant dune interface avec le serveur distant) et sa taxation. Par contre, le Gatekeeper doit maintenir des connexions TCP avec les endpoints pour lchange de signalisation Q.931, ce qui augmente sa charge, et ainsi ne lui permet pas de traiter autant dappels que dans le mode Direct Routed. La signalisation de commande H.245 (Control Signaling) suit obligatoirement le mode Directly Routed si le mode de la signalisation dappel Q.931 est Direct Routed. La signalisation de commande H.245 peut suivre soit le mode Directly Routed, soit le mode Gatekeeper Routed dans le cas ou le mode de la signalisation dappel Q.931 est Gatekeeper Routed. Dans le cas o la signalisation de commande H.245 est Gatekeeper Routed, la charge du Gatekeeper est importante car il faut maintenir une autre connexion TCP avec chaque endpoint pour lchange de messages H.245. Par contre le Gatekeeper a la connaissance des types de codecs utiliss (e.g., G.711, G.729) permettant ainsi de taxer plus prcisment lappel et de raliser des statistiques sur les types dappels tablis et les types de codecs utiliss.

Copyright EFORT 2008

H.323

H.225.0 RAS

H.225.0 Call signaling (Q.931) Direct

Gatekeeper Routed

H.245 Gatekeeper Routed

H.245 Directly Routed

H.245 Directly Routed

Figure 4: Modes de signalisation H.323 Plusieurs phases sont ncessaires afin de mettre en place une communication entre endpoints. Les principales phases sont : 1. La recherche du Gatekeeper par lendpoint afin didentifier le Gatekeeper qui va contrler lendpoint. 2. Lenregistrement de lendpoint auprs de son Gatekeeper. Lendpoint indique son adresse pseudonyme et son adresse rseau. Ladresse pseudonyme peut correspondre une adresse E-mail ou un numro de tlphone. 3. Ltablissement de la connexion par change de signalisation dappel entre endpoints. 4. Lchange de capacits (e.g., types de codecs utiliss) entre terminaux afin de sassurer que les donnes multimdia (audio, vido, donnes temps rel) mises par un endpoint seront reues et traites correctement par lendpoint rcepteur. 5. Louverture de voies logiques entre terminaux pour le transport des donnes audio et vido sous forme de paquets RTP. 6. Lchange des donnes multimdia sur les voies logiques RTP. 7. La libration de la connexion. Les phases 1 et 2 utilisent la signalisation H.225 RAS. La phase 3 requiert lusage de la signalisation dappel (H.225 Call Signaling). Les phases 4 et 5 sont ralises par la signalisation H.245. RTP est utilis pour la phase 6, savoir le transfert des donnes multimdia. Enfin, la libration de la connexion fait appel la signalisation RAS, la signalisation dappel et la signalisation H.245.

4. Signalisation RAS
La signalisation RAS est utilise entre les endpoints et le Gatekeeper qui les contrle (Tableau 1). Ce protocole de signalisation permet donc au Gatekeeper de contrler les endpoints prsents dans sa zone. Le Gatekeeper est une entit optionnelle ; cest la raison pour laquelle la signalisation RAS est aussi optionnelle. Si un endpoint souhaite utiliser les services offerts par un Gatekeeper, il doit alors implanter la signalisation RAS, sinon les fonctions assures par un Gatekeeper sont mises en uvre directement dans lendpoint.
Message RAS Gatekeeper Request (GRQ) Gatekeeper Confirm (GCF) Gatekeeper Reject (GRJ) Registration Fonction Envoy par un endpoint la recherche de son Gatekeeper Retourn par le Gatekeeper pour informer lendpoint quil sera son Gatekeeper Retourn par un Gatekeeper pour informer lendpoint quil ne sera pas son Gatekeeper Permet lendpoint de senregistrer auprs de son

Copyright EFORT 2008

Request (RRQ) Registration Confirm (RCF) Registration Reject (RRJ) Unregistration Request (URQ)

Unregistration Confirm (UCF) Unregister Reject (URJ) Admission Request (ARQ) Admission Confirm (ACF) Admission Reject (ARJ) Bandwidth Request (BRQ) Bandwidth Confirm (BCF) Bandwidth Reject (BRJ) Information Request (IRQ) Information Request Response (IRR) Information Acknowledgment (IACK) Information Negative Acknowldgment (INAK) Disengage Request (DRQ) Disengage Confirm (DCF) Disengage Reject (DRJ) Location Request (LRQ)

Gatekeeper Renvoy par le Gatekeeper pour indiquer lendpoint quil est bien enregistr Renvoy par le Gatekeeper pour indiquer lendpoint le rejet de sa demande denregistrement Envoy par un endpoint pour annuler son enregistrement auprs de son Gatekeeper ; aussi mis par le Gatekeeper un endpoint pour annuler lenregistrement de ce dernier Confirmation dannulation denregistrement dun endpoint Rejet de la demande dannulation denregistrement dun endpoint Envoy par un endpoint pour demander lautorisation son Gatekeeeper de participer un appel Retourn par le Gatekeeper lendpoint pour lui confirmer son admission Retourn par le Gatekeeper lendpoint pour linformer du rejet de sa demande dadmission Emis par un endpoint ou par un Gatekeeper pour demander une modification dynamique de la bande passante alloue lappel Confirmation de changement de la bande passante Rejet de la demande de changement de bande passante Envoy par le Gatekeeper pour demander un endpoint son tat (dsactiv, drangement, etc) Retourn soit sur demande, soit priodiquement par un endpoint son Gatekeeper pour linformer de son tat Emis par un Gatekeeper un endpoint pour confirmer la rception du message IRR Renvoy par un Gatekeeper un endpoint pour linformer de la rception dun message IRR en erreur Utilis par un endpoint ou par un Gatekeeper pour demander la fin de la communication Confirmation de fin de communication Rejet de la demande de fin de communication

Envoy un Gatekeeper pour demander la traduction dune adresse pseudonyme en une adresse de transport Location Confirm Renvoy par un Gatekeeper pour fournir ladresse (LCF) de transport correspondant ladresse pseudonyme Location Reject Rejet de la demande Location Request si la (LRJ) traduction na pas pu tre ralise Request In Progress Renvoy par un endpoint ou par un Gatekeeeper (RIP) comme rponse intermdiaire si une requte requiert un certain temps pour son excution

Tableau 1: Messages de signalisation RAS

Copyright EFORT 2008

5. Signalisation dappel
La signalisation d'appel H.225.0 permet dtablir et de librer des connexions entre endpoints H.323. Les messages utiliss sont ceux du protocole de signalisation Q.931 modifis par la recommandation H.225.0 (Tableau 2). En ralit, il sagit dun sous-ensemble des messages Q.931 qui est rutilis dans le contexte H.323. La voie de signalisation d'appel pour lchange de messages de signalisation dappel (Q.931) est indpendante de la voie RAS pour lchange de messages RAS vus prcdemment et de la voie de commande H.245 pour lchange de messages H.245. Louverture de la voix de signalisation dappel est pralable celle de la voie de commande H.245. Dans des rseaux H.323 sans Gatekeeper, la voie de signalisation d'appel est ouverte directement entre les deux endpoints participant l'appel. Elle correspond une connexion TCP. Dans des rseaux avec Gatekeeper, la voie de signalisation d'appel est ouverte entre lendpoint et le Gatekeeper (Gatekeeper Routed) ou entre les endpoints eux-mmes (Direct) suivant le choix fait par le Gatekeeper.

Message Q.931 Alerting Call Proceeding

Connect

Facility Information

Progress

Setup Setup Acknowledge Release Complete

User Information Notify

Status

Status Inquiry

Fonction Envoy lendpoint appelant par lappel pour indiquer que l'alerte du demand a t dclenche Message optionnel mis lendpoint appelant pour indiquer l'initialisation de l'tablissement de la connexion demande Envoy par le demand au demandeur (Gatekeeper, Gateway ou endpoint) pour signaler que le demand accepte l'appel Utilis afin de rediriger lappel ou dinvoquer un service complmentaire Message optionnel envoy par une entit H.323 pour fournir des informations supplmentaires relatives ltablissement des communications. Message optionnel gnralement envoy par un Gateway (e.g., interfonctionnement avec RNIS ou RTC) pour indiquer la progression d'un appel Premier message envoy pour ltablissement dune connexion Message optionnel permettant lappel daccuser rception dun message "Setup" Envoy pour indiquer la libration de l'appel. Le message Q.931 Release nest pas rutilis par H.225.0 Message optionnel utilis entre endpoints pour schanger de linformation Emis par lendpoint appelant ou appel afin de fournir une information se rapportant un appel, par exemple l'indication "utilisateur suspendu" Envoy en rponse un message de signalisation d'appel inconnu ou un message de demande d'tat "Status Inquiry" Utilis pour demander lautre extrmit de la connexion des indications d'tat sur la communication

Tableau 2 : Messages de signalisation dappel Lexemple de la figure 5 montre ltablissement dun appel entre deux endpoints suivant le mode de signalisation dappel Gatekeeper Routed. Lendpoint 1 met un message Setup son Gatekeeper aprs avoir reu de ce dernier une confirmation dadmission. Le Gatekeeper renvoie lendpoint 1 un message Call Proceeding pour indiquer que le message Setup a
Copyright EFORT 2008

t reu et que la demande dtablissement d'appel est en cours de traitement. Il relaye par ailleurs le message Setup lendpoint 2 qui rpond par un message Call Proceeding pour indiquer au Gatekepeer que le message Setup a t reu et quil est trait. Lendpoint 2 soumet son tour une demande dadmission son Gatekeeper afin dtre autoris rpondre lappel soumis par lendpoint 1. Une fois la demande accepte, lendpoint 2 envoie un message Alerting au Gatekeeper afin de linformer que lalerte a t dclenche sur lendpoint 2. Ce message Alerting est relay du Gatekeeper lendpoint appelant. Ds que lappel dcroche, un message Connect est renvoy de lendpoint 2 au Gatekeeper qui le rachemine lendpoint 1. La procdure de signalisation de commande H.245 peut alors dbuter.
GK

Endpoint 1 ARQRAS ACFRA S/ARJ RAS Setup Q.931

Endpoint 2

Setup Q.931 Call Proceeding Q.931 ARQRAS ACFRA S/ARJ RAS

Call Proceeding Q.931

AlertingQ.931 ConnectQ .9 31 H.245

AlertingQ.931 ConnectQ .9 31

Figure 5 : Exemple de signalisation dappel suivant le mode Gatekeeper Routed

6. Signalisation de commande H.245

La signalisation de commande H.245 permet (Tableau 3) : Lchange de capacits multimdia (audio, vido), afin dassurer une transmission selon un mode audio, vido particulier. La dtermination du terminal matre et du terminal asservi afin dviter tout conflit dans le contrle dune confrence, Ltablissement et la libration de canaux logiques permettant le transfert de donnes multimdia, Le transport des donnes multimdia dans les voies logiques nest pas pris en charge par la signalisation de commande H.245. H.245 est uniquement responsable du contrle des sessions alors que le protocole RTP est responsable du transport.
Message Q.931 Master Slave Determination Master Slave Determination Ack Master Slave Fonction Demande de dtermination du matre Utilis pour confirmer au terminal ayant mis le message Master Slave Determination sil est matre ou asservi Refus du message MasterSlaveDetermination

Copyright EFORT 2008

Determination Reject Master Slave Envoy si le temporisateur associ au message Determination Release MasterSlaveDetermination a expir Terminal Capability Set Permet un terminal dindiquer ses capacits dmission et de rception un autre terminal Terminal Capability Set Confirmation de rception d'un message Ack TerminalCapabilitySet Terminal Capability Set Refus du message TerminalCapabilitySet Reject Terminal Capability Set Envoy si le temporisateur associ au message Release TerminalCapabilitySet a expir Open Logical Channel Utilis par un terminal afin douvrir une voie unidirectionnelle avec un autre terminal Open Logical Channel Confirmation d'acceptation de la demande Ack OpenLogicalChannel Open Logical Channel Refus douverture dune voie logique Reject Close Logical Channel Utilis par lentit ayant tabli la voie logique pour librer cette voie logique Close Logical Channel Confirmation de libration de la voie logique Ack Request Channel Utilis par lentit rceptrice sur une voie logique Close pour demander lmetteur de librer la voie logique Request Channel Acquittement de libration de la voie logique Close Ack Request Channel Rejet de libration de la voie logique par lentit Close Reject mettrice sur cette voie logique

Tableau 3 : Messages de signalisation de commande

6.1.

Echange de capacits

Lchange de capacits permet dassurer que les seuls signaux multimdias devant tre mis sont ceux qui peuvent tre reus et traits de faon approprie par le terminal rcepteur. Cela implique que les capacits de rception et de dcodage d'un terminal soient connues de l'autre terminal. Lchange de capacit doit tre pralable toute ouverture de voie logique. Toutes les capacits d'un terminal recevoir et dcoder diffrents signaux sont dclares l'autre terminal par la transmission de l'ensemble de ses capacits. Les metteurs devront limiter le contenu des donnes multimdia transmises aux donnes que le rcepteur a dclar pouvoir recevoir. Les capacits d'mission dcrivent les capacits du terminal transmettre des signaux multimdia et permettent de prsenter aux rcepteurs un choix de modes de fonctionnement possibles, de sorte que le rcepteur puisse demander le mode dans lequel il prfre recevoir les informations. L'absence de toute capacit d'mission indique que le terminal ne propose pas de choix de modes prfrs au rcepteur (mais il peut cependant transmettre tout ce qui est dans les limites des capacits du rcepteur). Un endpoint indique ses capacits dans un message TerminalCapabilitySet. Cette requte indique un numro de squence (sequenceNumber) permettant de la corrler avec sa rponse qui sera reue ultrieurement. La requte contient par ailleurs les types de formats audio et vido dcrits dans des descripteurs (CapabilityDescriptors) que lendpoint peut mettre et recevoir. Le message TerminalCapabilitySetAck acquitte et confirme le message TerminalCapabilitySet. Cette rponse contient le mme numro de squence que la requte correspondante. Si le rcepteur rencontre un problme, il renvoie un message TerminalCapabilitySetReject qui inclut la raison du rejet (e.g., Le terminal n'a pas pu stocker toutes les informations du message TerminalCapabilitySet).

Copyright EFORT 2008

Si lmetteur du message TerminalCapabilitySet ne reoit aucune rponse alors que le temporisateur associ a expir, il envoie alors un message TerminalCapabilitySetRelease. Alors que le message TerminalCapabilitySet permet un endpoint dinformer un autre endpoint de ses capacits, une commande sendTerminalCapabilitySet peut tre envoye afin de demander un endpoint ses capacits. La rponse cette commande est le message TerminalCapabilitySet. Une commande sendTerminalCapabilitySet peut tre mise suite une interruption ou tout autre motif de dfaillance afin de permettre lendpoint de sassurer quil dispose bien des dernires capacits connues de lendpoint distant. Dans lexemple de la figure 6, lendpoint 1 met sur la voie de commande (connexion TCP) le message TerminalCapabilitySet qui indique les codecs que lendpoint 1 peut supporter pour mettre des donnes multimdia. Lendpoint peut supporter les codecs (H.261, G.711, T.120) pour le transfert de la vido, de laudio et des donnes temps rel respectivement ou (H.261, G.729, T.120). Notons quun message SETUP peut demander ltablissement dun appel voix et vido. Il sagira alors douvrir des canaux RTP pour la voix et des canaux RTP pour la vido, do la ncessit dchanger les capacits pour diffrents types de mdia.
Endpoint 1
Etablissement dune connexion TCP pour le transport des messages H.245 H.245 : TerminalCapabilitySet Capability Table : H.261 Video Capability g711Alaw64k, g729 t120

Endpoint 2

Terminal Capability SetH.245 Voie de commande H.245 (TCP)

H.245 : TerminalCapabilitySetAck Capability Table : H.261, g711Alaw64k, t120

Voie de commande H.245 (TCP)

Terminal Capability Set AckH.245

H.245 : TerminalCapabilitySet Capability Table : H.261 Video Capability g711Alaw64k, g729 t120

Terminal Capability SetH.245

H.245 : TerminalCapabilitySetAck Capability Table : H.261, g729, t120

Terminal Capability Set AckH.245

Figure 6 : Echange de capacits entre endpoints Lendpoint 2 rpond par un message TerminalCapabilitySetAck en slectionnant une des possibilits. Lendpoint 2 choisit les codecs H.261, G.711 et T.120. Lendpoint 2 sera donc capable de dcoder les donnes reues avec lun de ces codecs slectionn en fonction du type des donnes multimdia. Pour les donnes que lendpoint 2 devra mettre, ce dernier dispose dun certain nombre de codecs quil propose lendpoint 1 travers un message TerminalCapabilitySet. Lendpoint 1 choisit une des possibilits. Dans lexemple, il sagit des codecs H.261, G.729, T.120. Il est donc possible dutiliser des codecs diffrents sur les deux canaux RTP unidirectionnels tablis entre les deux endpoints.

Copyright EFORT 2008

10

6.2.

Dsignation matre-asservi

Dans toute confrence, il est ncessaire quun des endpoints participants soit le matre afin quil soit le seul contrler la confrence. La procdure suivante est utilise pour dterminer le terminal matre partir des valeurs des paramtres terminalType et statusDeterminationNumber dtenues par chaque endpoint. Les valeurs terminalType sont compares entre entits travers les messages MasterSlateDetermination et MasterSlaveDeterminationAck. Le terminal ayant le numro de type de terminal le plus grand est dsign comme tant le terminal matre. terminalType est un numro qui identifie diffrents types de terminaux tels que les terminaux H.323, les MCUs, et les Gateways. Les valeurs assignes au champ terminalType sont dcrites au tableau 4. Un MCU qui contrle une confrence a la plus grande valeur possible, savoir 240. Si les numros de type de terminal sont les mmes, les numros statusDeterminationNumbers sont compars en utilisant l'arithmtique modulo pour dsigner le terminal matre. Un endpoint reoit dans un message MasterSlateDetermination les valeurs des paramtres terminalType et statusDeterminationNumber de lentit qui envoie ce message. Lendpoint rcepteur dispose lui-mme dune valeur de terminalType en fonction de son type de terminal et dune valeur de statusDeterminationNumber quil a choisi au dpart alatoirement, comprise entre 1 et 1677721(224-1). Si les deux terminaux ont des valeurs de champ terminalType diffrentes, lendpoint retourne un message MasterSlaveDeterminationAck indiquant lautre point sil est matre (master) ou asservi (slave). Si les valeurs de champ terminalType sont gales et si les valeurs de champ statusDeterminationNumber sont diffrentes, celui ayant la plus grande valeur sera alors le matre. Si par contre il y a galit entre les valeurs de champ terminalType et entre les valeurs de champ statusDeterminationNumber la fois, il y a alors indtermination. Un message MasterSlaveDeterminationReject est alors retourn dans ce dernier cas. Si le temporisateur associ au message MasterSlaveDetermination arrive expiration sans avoir reu une rponse MasterSlaveDeterminationAck ou MasterSlaveDeterminatiionReject, un message MasterSlateDeterminationRelease est alors envoy.

Tableau des valeurs TerminalType Ensemble de caractristiques Entit sans MC Entit incorporant un MC mais n'incorporant pas de MP Entit incorporant un MC avec MP de donnes Entit incorporant un MC avec MP de donnes et audio Entit incorporant un MC avec MP de donnes, audio et vido Terminal 50 70 -

Entit H.323

Gateway 60 80 90 100 110

Gatekeeper 120 130 140 150

MCU 160 170 180 190

Tableau 4 : Types de terminaux H.323 pour le choix du mode matre ou asservi H.245

6.3.

Ouverture de voies logiques unidirectionnelles

Louverture dune voie logique unidirectionnelle est ralise par lenvoi dun message openLogicalChannel. Ce dernier contient les paramtres forwardLogicalChannelNumber qui indique le numro de la voie logique directe qui doit tre ouverte et

Copyright EFORT 2008

11

 forwardLogicalChannelParameters qui inclut le type de donnes mettre sur cette voie depuis lendpoint qui met le message openLogicalChannel. Si la demande est accepte, le rcepteur met une rponse OpenLogicalChannelAck qui contient le mme numro de voie logique que celui dans le message OpenLogicalChannel et ladresse de transport (adresse IP et port RTP) laquelle doivent tre envoys les signaux multimdia. Dans lexemple suivant, les endpoints 1 et 2 ouvrent des canaux RTP pour le transport de la voix paqutise (Figure 7). Lendpoint 1 met un message OpenLogicalChannel pour ouvrir un canal RTP unidirectionnel sur lequel il mettra des paquets RTP contenant la voix encode avec G.711. Il indique par ailleurs le numro de port RTCP quil a ouvert pour recevoir ventuellement des paquets RTCP RR (Receiver Report) mis par lendpoint 2 (Cf chapitre 8 traitant RTP et RTCP). Lendpoint 2 rpond par un message OpenLogicalChannelAck contenant le numro de port RTP tabli pour recevoir la voix paqutise, encode avec G.711. Par ailleurs il fournit un numro de port RTCP auquel seront dlivrs des paquets RTCP SR (Sender Report) mis par lendpoint 1. Un second canal RTP unidirectionnel est ouvert entre lendpoint 2 (metteur) et lendpoint 1 (rcepteur) travers lchange de messages OpenLogicalChanel et OpenLogicalChannelAck.
Endpoint 1
H.245 : OpenLogicalChannel LogicalChannel 1, RTCP RR port 7001 g711Alaw64k session number, RTP Payload Type Silence suppression

Endpoint 2

OpenLogicalChannelH.245
Voie de commande H.2 45 (TCP)

H.245 : OpenLogicalChannelAck LogicalChannel 1, RTCP SR port 9325, RTP port 9324

Voie de commande H.2 45 (TCP)

OpenLogicalChannelAckH.245
H.245 : OpenLogicalChannel LogicalChannel 1, RTCP RR port 9325 g729 session number, RTP Payload Type Silence suppression

OpenLogicalChannel H.245
H.245 : OpenLogicalChannelAck LogicalChannel 1, RTCP SR port 7001, RTP port 7000

OpenLogicalChannelAckH.245
RR : Receiver Report SR : Sender Report

Figure 7: Ouverture de voies logiques unidirectionnelles Si pendant la session audio, lendpoint 1 souhaite enrichir cette session par louverture de canaux RTP pour lchange de trafic vido avec lendpoint 2, il lui suffit dmettre une demande bandwidthRequest son Gatekeeper en indiquant la bande passante ncessaire pour la partie vido (bande passante totale ncessaire ltablissement de deux canaux RTP unidirectionnels). Si le Gatekeeper accepte, un message bandwidthConfirm est retourn lendpoint 1 qui peut alors mettre un message openLogicalChannel lendpoint 2 en indiquant que le codec utilis est H.261 (Figure 8). Lendpoint 2 rpond par un message openLogicalChannelAck en indiquant le port RTP allou pour recevoir la vido paqutise. Par ailleurs, le mme port RTCP sera utilis pour recevoir dventuels paquets RTCP RR ou mettre des paquets RTCP SR relatifs au trafic RTP vido. Cela signifie quune session peut

Copyright EFORT 2008

12

contenir plusieurs canaux RTP (voix, vido) mais un seul canal RTCP pour le contrle du trafic RTP chang dans le cadre de la session. Lendpoint 2 envoie son tour un message openLogicalChannel lendpoint 1 qui retourne un message openLogicalChannelAck contenant le port RTP rserv par lendpoint 1 pour recevoir la vido encode avec le codec H.261.
Endpoint 1
H.245 : OpenLogicalChannel LogicalChannel 1, RTCP RR port 7001 H.261 session number, RTP Payload Type

Endpoint 2

OpenLogicalChannelH.245
Voie de commande H.2 45 (TCP)

H.245 : OpenLogicalChannelAck LogicalChannel 1, RTCP SR port 9325, RTP port 9326

Voie de commande H.2 45 (TCP)

OpenLogicalChannelAckH.245
H.245 : OpenLogicalChannel LogicalChannel 1, RTCP RR port 9325 H.261 session number, RTP Payload Type

OpenLogicalChannel H.245
H.245 : OpenLogicalChannelAck LogicalChannel 1, RTCP SR port 7001, RTP port 7002

OpenLogicalChannelAckH.245
RR : Receiver Report SR : Sender Report

Figure 8: Ouverture de voies logiques unidirectionnelles additionnelles pour lchange de trafic vido

6.4.

Fermeture de voies logiques

La fermeture dune voie logique est obtenue par lenvoi dun message CloseLogicalChannel. Si la voie est ferme lautre extrmit, cette dernire renvoie un message CloseLogicalChannelAck. La fermeture dune voie logique ne peut tre effectue que par lentit qui la cre, cest dire lmetteur sur cette voie. Par contre le rcepteur sur une voie donne peut suggrer lentit mettrice sur cette voie de fermer la voie par lenvoi dun message RequestChannelClose contenant un paramtre forwardLogicalChannelNumber indiquant le numro de la voie logique directe dont la fermeture est souhaite. Lmetteur sur la voie peut retourner un message RequestChannelCloseAcknowledge pour informer que la connexion de voie logique sera ferme ou un message RequestChannelCloseReject pour indiquer que la connexion de voie logique restera ouverte. Lorsque tous les canaux logiques associs une session sont ferms, un endpoint indique la fin de la session en mettant un message endSessionCommand. Aprs avoir transmis EndSessionCommand, lendpoint ne devra plus envoyer aucun autre message H.245 relatif la session.

6.5.

Procdure Fast-Connect

Les endpoints H.323 peuvent tablir des voies logiques en utilisant la procdure de connexion rapide (fast-Connect). Cette fonctionnalit est dfinie dans la recommandation H.323v2 implante dans toutes les solutions H.323 du march. Cette procdure permet aux endpoints d'tablir une communication point--point de base avec un seul aller et retour

Copyright EFORT 2008

13

d'change de messages, permettant une remise immdiate du flux multimdia ds la connexion de l'appel. Lendpoint appelant lance la procdure de connexion rapide en envoyant l'endpoint appel un message SETUP contenant l'lment fastStart. Cet lment se compose d'une squence de structures OpenLogicalChannel dcrivant des voies multimdia que l'entit appelante propose d'mettre et de recevoir, y compris tous les paramtres ncessaires une ouverture immdiate et un transfert immdiat des donnes multimdias sur les voies ainsi ouvertes. L'endpoint appel peut refuser d'utiliser la procdure de connexion rapide, par exemple sil ne l'implante pas. Lorsque l'endpoint appel souhaite appliquer la procdure de connexion rapide, il envoie un message Q.931 (CALL PROCEEDING, PROGRESS, ALERTING ou CONNECT) contenant un lment fastStart oprant une slection parmi les propositions openLogicalChannel offertes par l'endpoint appelant. Les voies ainsi acceptes sont considres comme ouvertes. L'endpoint appelant doit donc tre dispos recevoir des donnes multimdia sur l'une quelconque des voies de rception qu'il a proposes dans le message SETUP, car il est possible que les donnes multimdias soient reues avant le message Q.931 indiquant prcisment quelles voies seront utilises. Une fois qu'un message Q.931 contenant l'lment fastStart a t reu par l'endpoint appelant, celui-ci peut arrter ses tentatives de rception de donnes multimdia sur les voies pour lesquelles l'endpoint appel n'a pas accept de propositions. L'endpoint appelant peut commencer envoyer les flux mdia (en fonction des voies ouvertes) ds qu'il reoit un message Q.931 contenant l'lment fastStart. L'endpoint appel doit donc tre prt recevoir immdiatement des donnes multimdia sur les voies qu'il a acceptes dans le message Q.931 contenant l'lment fastStart.

H.225 : SETUP fastStart: OpenLogicalChannel 1 OpenLogicalChannel 2

receive G.711 RTP port 2222, RTCP port 2223 send G.711 RTCP port 2223) SETUPQ.931 ALERTING Q.931 CONNECTQ.931

H.225 : CONNECT fastStart: OpenLogicalChannel 1 OpenLogicalChannel 2

send RTCP port 5223, receive G.711 RTP port 5222, RTCP port 5223)

Figure 9: Procdure Fast-Connect Dans lexemple suivant, lendpoint 1 met un message SETUP contenant llment fastStart (Figure 9). Ce dernier indique que lendpoint 1 est prt recevoir des paquets RTP encods avec G.711 de la part de lendpoint 2 sur le port RTP 2222. Par ailleurs, les paquets RTCP SR mis par lendpoint 2 devront tre dlivrs sur le port RTCP 2223. Ces informations caractrisent le canal RTP 1 sur lequel lendpoint 1 joue le rle de rcepteur. Par ailleurs, lendpoint 1 est metteur sur le canal RTP 2. Il enverra des paquets RTP sur ce canal avec un encodage G.711. Il peut recevoir dventuels paquets RTCP RR de la part de lendpoint 2 sur son port RTCP 2223. Lendpoint 2 retourne lappelant un message ALERTING pour linformer de lalerte de lappel et une fois lappel accept par lendpoint 2, un message CONNECT est retourn lendpoint 1. Ce message contient des paramtres de configurations des canaux RTP 1 et 2.

Copyright EFORT 2008

14

Lendpoint 2 est prt recevoir dventuels paquets RTCP RR de la part de lendpoint 1 sur son port RTCP 5223. Il a par ailleurs tabli le port RTP 5222 pour recevoir des paquets RTP de lendpoint 1 et le port RTCP 5223 pour recevoir des paquets RTCP SR. Les canaux RTP et RTCP tablis entre les deux endpoints sont prsents la figure 10.

Endpoint

Endpoint
Canal RTP 5222 Canal RTP

2222 Canal RTCP 2223

Port RTP rcepteur Port RTCP metteur et rcepteur

5223

Figure 10: Canaux RTP et RTCP tablis entre les endpoints

7. Les services H.450

LITU-T dans la srie de recommandations H.450 a spcifi un ensemble de services hrits des services complmentaires du monde de la tlphonie.

7.1.

Approches pour introduire les services H.450

Il existe plusieurs approches pour introduire les services H.450 dans un rseau H.323 : Le terminal H.323 contient les logiciels correspondant aux services: Cette approche est valide pour des services tels transfert dappel, renvoi dappel, mise en attente, appel en attente et ventuellement confrence multiparties. Le MCU offre le service de confrence multiparties. Le Feature Server offre les services quil nest pas appropri dintroduire dans un terminal. Les services concerns sont par exemple distribution dappel o lappel nest pas destin un appel particulier ; il sagit en fait de relayer lappel lagent dun centre dappel qui est le plus apte rpondre lappel en fonction de ses comptences. La signalisation Call signaling (Q.931) suit alors obligatoirement le mode Gatekeeper Routed. Le Gatekeeper interagit avec le Feature pour demander lexcution du service. Le Feature server pourrait aussi tre utilis comme proxy ou client secondaire pour les destinataires qui ne sont pas oprationnels (e.g., non connects). Sur la dtection du nonfonctionnement du destinataire, le Gatekeeper route les appels destins l appel non connect vers le Feature server qui peut alors excuter les services tels que renvoi d appel pour le compte du destinataire.

7.2. Le service renvoi dappel implant dans un terminal et dans un Feature server
7.2.1. Renvoi dappel implant dans le terminal
Si lon considre un rseau H.323 sans Gatekeeper, la signalisation RAS ne sapplique pas. Lappelant (terminal A) souhaite tablir un appel avec le terminal B (Figure 11). Il ouvre une connexion TCP avec ce terminal et met sur cette connexion un message SETUP. Dans ce cas, le terminal A connat ladresse IP du terminal B. Le terminal B ayant programm un renvoi dappel inconditionnel excute le logiciel correspondant et retourne un message Facility au terminal A contenant ladresse de renvoi dappel. Le terminal A acquitte la rception du message Facility et met un message Release Complete pour librer la connexion TCP tablie pour l change de signalisation dappel Q.931.

Copyright EFORT 2008

15

Le terminal A peut alors mettre un message INVITE au terminal C dont ladresse est celle retourne par le terminal B. En considrant lutilisation de llment fastStart, le message SETUP contient les caractristiques du mdia tabli par le terminal A. Le terminal C retourne un message Alerting et lorsque lappel est accept, renvoie un message CONNECT contenant les proprits du mdia tabli par ce terminal C. Les canaux RTP et le canal RTCP sont alors mis en uvre entre les terminaux A et C. Le service ne peut tre excut que si le terminal B est connect afin de pouvoir retourner le numro de renvoi dappel au terminal A.
Terminal A Terminal B Terminal C

H.225 SETUP (destination = B) H.225 FACILITY Facility IE : callRerouting.Invoke H.225 FACILITY Facility IE : callRerouting.Result H.225 RELEASE COMPLETE

Une application dtermine ltat de renvoi dappel de B

H.225 SETUP Facility IE : divertingLegInfo2.Invoke H.225 ALERTING H.225 CONNECT Facility IE : diverting LegInfo3.Invoke Canaux RTP tablis entre A et C

Figure 11 : Service de renvoi dappel excut par le terminal

7.2.2. Service Renvoi dappel implant dans le Feature server

Lapproche consistant implanter le service dans un Feature server nest possible que dans le cas o le rseau H.323 dispose dun Gatekeeper (Figure 12) Lorsque le terminal A met un message SETUP au terminal B, ce message est obligatoirement pass dans un premier temps au Gatekeeper. Le Gatekeeper sachant que le terminal B a souscrit un service de renvoi dappel inconditionnel tablit une connexion TCP avec le Feature Serer et renvoie le message SETUP au Feature server. Le terminal B nest pas impliqu dans lexcution du service. Le Feature server retourne le numro de renvoi dappel au Gatekeeper par un message Facility. Le Gatekeeper acquitte la rception du message Facility et renvoie un message Release Connection pour librer la connexion TCP tablie avec le Feature server. Le Gatekeeper renvoie le message SETUP initial au terminal C (numro de renvoi dappel) et par ailleurs informe le terminal A du renvoi dappel. Les rponses Alerting et Connect retournes par le terminal C au Gatekeeper son relayes par ce dernier au terminal A.

Copyright EFORT 2008

16

Les canaux RTP et le canal RTCP sont tablis entre les terminaux A et C.
Terminal A Gatekeeper Feature Server Terminal C

H.225 SETUP (destination = B)

H.225 SETUP H.225 FACILITY Une application Facility IE : dtermine ltat de callRerouting.Invoke renvoi dappel de B H.225 FACILITY Facility IE : callRerouting.Result H.225 RELEASE COMPLETE H.225 SETUP Facility IE : divertingLegInfo2.Invoke

Facility IE : divertingLegInfo1.Invoke

Two legs joined H.225 ALERTING H.225 CONNECT Facility IE:diverting LegInfo3.Invoke

H.225 ALERTING

H.225 CONNECT Facility IE : diverting LegInfo3.Invoke

Canaux RTP entre A et C

Figure 12: Service de renvoi dappel excut par le Feature Server Rfrences
ITU-T Rec. H.323, Protocole de commande pour communications multimdias , 1999. ITU-T Rec. H.225.0, Protocoles de signalisation d'appel et mise en paquets d'un train multimdia pour des systmes de communication multimdias en mode pquet , 1998. ITU-T Rec. H.245, Systmes de communication multimdia en mode paquet , 1999. ITU-T Rec. Q.931, Spcification de la couche 3 de l'interface usager-rseau RNIS pour la commande de l'appel de base , 1998. ITU-T Rec. Q.932, Systme de signalisation d'abonn numrique n 1 Procdures gnriques pour la commande des services complmentaires RNIS , 1998. ITU-T Rec. H.450.2, Service complmentaire de transfert de communication dans un systme H.323, 1998. ITU-T Rec. H.450.4, Service complmentaire de dviation dappel dans les systmes H.323, 1999. ITU-T Rec. H.450.4, Service complmentaire de mise en attente dans les systmes H.323, 1999. ITU-T Rec. H.450.6, Service complmentaire dappel en attente dans les systmes H.323, 1999.

Copyright EFORT 2008

17