Université Mohammed V – Souissi N° Ordre :

Ecole Supérieure d’Informatique et

d’Analyse des Systèmes (ENSIAS)
Rabat

THESE
Pour l’obtention du

Doctorat National
Présentée par

Mohammed OUZZIF

FORMALISATION ET IMPLEMENTATION DE
PROTOCOLES DE GESTION ET DE CONTROLE
DANS UN SYSTEME DE VIDEOCONFERENCE
SUR INTERNET

Soutenue le 11 Mars 2005 devant le jury :

Président B. Regragui

Directeur de Thèse M. Erradi

J-P. Courtiat

Rapporteurs D. Chiadmi
N. Naja
R. Mrabet
2
3
4
Table de matières

RESUME & ABSTRACT

INTRODUCTION GENERALE 12

PREMIERE PARTIE : ETAT DE L’ART 15

CHAPITRE1 : SYSTEMES COOPERATIFS 16

1.1 Introduction 16
1.2 Travail coopératif 17
1.2.1 Définitions 17
1.2.2 Caractérisation du travail coopératif 19
1.3 Classification des systèmes TCAO 24
1.3.1 Classification espace-temps 24
1.3.2 Classification par travail coopératif 25
1.3.3 Classification par domaines d’applications 27
1.4 Conclusion

CHAPITRE 2 : NORMES ET PROTOCOLES STANDARDS 30

2.1 Introduction 30
2.2 Recommandation H.323 31
2.2.1 Architecture H.323 31
2.2.2 Protocoles d’un système H.323 35
2.2.3 Recommandation T.120 36
2.3 Architecture IETF 40
2.3.1 Multicast Internet 41
2.3.2 Agents médias 42
2.3.3 Gestion de conférence 44
2.4 Conclusion 53

CHAPITRE 3 : SYSTEMES DE TELECONFERENCE ET GESTION DE "FLOOR" 54

3.1 Introduction 54
3.2 Produits de téléconférence 55
3.2.1 Produits ITU 55

5
 3.2.2 Produits Internet 56
3.3 Concepts de gestion et de contrôle de conférence 59
3.3.1 Gestion de conférence 60
3.3.2 Contrôle de "floor" 61
3.4 Recommandation SCCP 65
3.4.1 Initiation de la conférence 66
3.4.2 Terminologie de SCCP 66
3.4.3 Services de SCCP 67
3.4 Conclusion 68

DEUXIEME PARTIE : ARCHITECTURE, SPECIFICATION

ET IMPLEMENTATION 69

CHAPITRE 1 : FORMALISATION DE LA GESTION ET DU CONTROLE

AU SEIN D'UNE CONFERENCE MULTIMEDIA 70

1.1 Introduction 70
1.2 Architecture et pile protocolaire 71
1.2.1 Architecture 71
1.2.2 Pile de protocoles 73
1.3 Description formelle du comportement d’un MMTS 76
1.3.1 Techniques et langages de description formelle 76
1.3.2 Spécification formelle de MMTS à politique présidée 78
1.3.3 Spécification formelle de MMTS à politique explicite 89
1.4 Conclusion 94

CHAPITRE 2 : VERIFICATION DE PROPRIETES DE LA GESTION

ET DU CONTROLE AU SEIN D’UNE CONFERENCE MULTIMEDIA 95

2.1 Introduction 95
2.2 Description des propriétés 96
2.2.1 Description informelle 96
2.2.2 Description formelle en LTL 96
2.3 Vérification des propriétés 101
2.3.1 Description Promela 101
2.3.2 Vérification à l’aide de SPIN 107
2.4 Conclusion 109

CHAPITRE 3 : MECANISMES DE REALISATION 110

3.1 Introduction 110

3.2 Algorithmes d’exclusion mutuelle 111
3.3 Insertion dynamique de sites dans des algorithmes à jeton 112
3.3.1 Adaptation de l’algorithme Le Lann pour l’insertion dynamique 112

6
 3.3.2 Adaptation de l’algorithme Naimi-Tréhel pour l’insertion dynamique 115
3.4 Suppression dynamique de sites dans des algorithmes à jeton 125
3.4.1 Suppression dans l’algorithme Le Lann 125
3.4.2 Suppression dans l’algorithme Naimi-Tréhel 127
3.5 Conclusion 134

CHAPITRE 4 : IMPLEMENTATION 135

4.1 Introduction 135

4.2 Conception et réalisation d’un système à politique présidée 136
4.2.1 Conception UML 136
4.2.2 Réalisation 143
4.3 Réalisation d’un système à politique explicite 149
4.3.1 Environnement Platine 149
4.3.2 Architecture du système 150
4.3.3 Implémentation 152
4.4 Application au télé-enseignement 153
4.4.1 Caractéristiques d’une application de préparation coopérative 153
4.4.2 Réalisation d’une application de préparation coopérative 154
4.5 Conclusion 157

CONCLUSION GENERALE 159

BIBLIOGRAPHIE 162

7
Liste des figures
Figure I.1.1. Modèle du trèfle 23
Figure I.1.2. Classification espace-temps du travail coopératif 25
Figure I.1.3. Taxonomie du travail coopératif. 26
Figure I.2.1. Environnement H.323 32
Figure I.2.2 . Terminal H.323 33
Figure I.2.3. Pile de protocoles pour une conférence H.323 35
Figure I.2.4. Séquence de messages d’initialisation d’une conférence H.323 36
Figure I.2.5. Architecture multipoint T.120 37
Figure I.2.6. Modèle du système T.120 38
Figure I.2.7. Architecture IETF pour la téléconférence sur Internet 40
Figure I.2.8. Description SDP d’une session 47
Figure I.2.9. Format du paquet SAP 47
Figure I.2.10. Invitation SIP via un "proxy server" 50
Figure I.2.11. Invitation SIP via un "redirect server" 50
Figure II.1.1. Architecture d’une téléconférence sur Internet 72
Figure II.1.2. Architecture de gestion et de contrôle de conférence 74
Figure II.1.3. Interaction de l’entité GCCF 76
Figure II.1.4. Paquet GCCF 79
Figure II.1.5. Comportement du processus "Coordination_GCCF" présidé 84
Figure II.1.6. Comportement du processus "Gestion conférence" présidé 85
Figure II.1.7. Comportement du processus "Contrôle Floor" présidé 86
Figure II.1.8. Comportement du processus "Gestion Media" 87
Figure II.1.9. Scénario d'une conférence présidée. 88
Figure II.1.10. Comportement du processus "Coordination_GCCF" explicite 90
Figure II.1.11. Comportement du processus "Gestion Conférence" explicite 91
Figure II.1.12. Comportement du processus "Contrôle Floor" explicite 92
Figure II.1.13. Scénario d'une conférence explicite 93
Figure II.2.1. Comportement du processus "Contrôle Floor" relatif au simple participant 103
Figure II.2.2. Comportement du processus "Contrôle Conférence" relatif au modérateur 105
Figure II.2.3. Comportement du processus "Contrôle Floor" dans une politique explicite 106
Figure II.2.4. Vérification de la propriété d’exclusion mutuelle du floor dans un MMTS présidé 108
Figure II.2.5. Vérification de la propriété d’exclusion mutuelle du floor dans un MMTS explicite 109

8
Figure II.3.1. Algorithme Le Lann 113
Figure II.3.2. Insertion de nouveaux participants dans l’anneau Le Lann 114
Figure II.3.3. Insertion de nouveaux participants dans l’algorithme Le Lann 114
Figure II.3.4. Traitement des messages relatifs à l’insertion dans l’algorithme Le Lann 115
Figure II.3.5. Situation initiale 117
Figure II.3.6. Demande de la section critique par le site 2 117
Figure II.3.7. Demande de la section critique par le site 3 118
Figure II.3.8. Demande de la section critique par le site 4 118
Figure II.3.9. Libération de la section critique par le site 2 119
Figure II.3.10. Algorithme Naimi-Tréhel 119
Figure II.3.11. Insertion de nouveaux sites dans l’arborescence Naimi-Tréhel 120
Figure II.3.12. Insertion de nouveaux sites dans l’algorithme Naimi-Tréhel 122
Figure II.3.13. Traitement des messages relatifs à l’insertion dans l’algorithme Naimi-Tréhel 123
Figure II.3.14. Suppression de sites de l’anneau Le Lann 125
Figure II.3.15. Suppression de sites de l’algorithme Le Lann 126
Figure II.3.16. Traitement des messages relatifs à la suppression dans l’algorithme Le Lann 126
Figure II.3.17. Isolement d’un sous-groupe 127
Figure II.3.18. Blocage de l’ensemble des sites 128
Figure II.3.19. Situation normale de départ de deux sites 129
Figure II.3.20. Isolement d’un sous-groupe suite à deux départs simultanés 129
Figure II.3.21. Départ de la racine 130
Figure II.3.22. Suppression de sites dans l’algorithme Naimi-Tréhel 132
Figure II.3.23. Traitement des messages relatifs à la suppression dans l’algorithme Naimi-Tréhel 133
Figure II.4.1. Cas d’utilisation relatifs au modérateur 137
Figure II.4.2. Cas d’utilisation relatifs à un simple participant 138
Figure II.4.3. Diagramme de classes 139
Figure II.4.4. Diagramme de séquence d’attribution du floor 140
Figure II.4.5. Diagramme de séquence de retrait de floor 141
Figure II.4.6. Diagramme de séquence de demande de floor 142
Figure II.4.7. Diagramme de séquence de libération de floor 143
Figure II.4.8. Interface de saisie des informations d’un utilisateur 144
Figure II.4.9. Interface "Conference Directory" 145
Figure II.4.10. Interface "Création d’une conférence" 146
Figure II.4.11. Interface "Joindre une conférence" 146
Figure II.4.12. Interface "Chairman" 147
Figure II.4.13. Interface "Simple Participant" 148
Figure II.4.14. Architecture de l’environnement Platine 150

9
Figure II.4.15 Architecture du MMTS réalisé 151
Figure II.4.16. Interface du système à politique explicite 153
Figure II.4.17. Editeur de l’exercice 155
Figure II.4.18. Tableau blanc 156
Figure II.4.19. Architecture de l’application de préparation coopérative des exercices 157

10
Liste des tableaux
Tableau I.2.1. Description des informations d’une session 45
Tableau I.2.2. Description de l’aspect temps d’une session 46
Tableau I.2.3. Description des médias 46
Tableau I.3.1. Comparaison entre les produits de téléconférence 59
Tableau I.3.2. Correspondance politique/mécanisme 65
Tableau II.1.1. Primitives et champs 82

11
Introduction générale

Durant cette dernière décennie, nous avons assisté à une révolution extraordinaire dans les
domaines des télécommunications et de l’informatique. L’évolution conjointe de ces deux
technologies a permis l’émergence et le développement des réseaux informatiques. Grâce à
ces réseaux, il est actuellement possible d’acquérir et d’échanger aisément des informations
de différents types (texte, audio, vidéo) entre des sites distants. L’interconnexion des réseaux
hétérogènes de différentes catégories (locaux, métropolitains et étendues) a permis l’extension
rapide du "réseau des réseaux" communément appelé Internet. Ce réseau supporte
actuellement des applications de travail coopératif telles que les applications de télétravail,
télémédecine, téléenseignement, etc.

Les réseaux informatiques ont fait des progrès énormes aussi bien en terme de bande
passante qu’en fiabilité, qualité de service, gestion et sécurité. Ils constituent un support de
communication efficace pour les systèmes informatiques répartis qui sont en pleine
expansion. Une catégorie de ces systèmes regroupe les systèmes multimédias distribués, et
plus particulièrement les systèmes de téléconférence. En effet, de tels systèmes nécessitent
l’échange de différents types de données et requièrent des contraintes temporelles pour leur
transmission. Ils sont devenus réalisables, dans un premier temps, grâce à l’émergence des
réseaux à haut débit. Actuellement, ils sont aussi supportés par le réseau Internet grâce aux
efforts de l’IETF (Internet Engenering Task Force) en terme de protocoles de transport de
données multimédias et de réservation de ressources.

Les systèmes de téléconférence multimédia (ou MMTS pour Multimedia

Teleconferencing System) sont des systèmes qui permettent à un groupe de personnes,
physiquement distantes, de mener des réunions de travail ou des conférences virtuelles. Un
MMTS est généralement constitué de deux composantes principales : la composante
d’initiation et de découverte de conférence et la composante de gestion et contrôle du
déroulement de la conférence. La première composante concerne la mise en place d’une
conférence. Il s’agit là de la description de la conférence, son annoncement et son initiation.
La deuxième composante concerne le contrôle d’une conférence lors de son déroulement. Il
s’agit de gérer les utilisateurs d’une même téléconférence, de contrôler l’accès aux ressources

12
de la téléconférence (l’audio, la vidéo, les applications partagées, etc) et d’assurer la
coordination des interactions entre les utilisateurs.

Dans ce travail de thèse, nous portons un intérêt particulier à la composante de gestion et

de contrôle de déroulement de la conférence. L’objectif de ce travail se résume dans les points
suivants :
- La définition d’une couche de gestion et de contrôle au sein de l’architectutre IETF
d’une conférence multimédia ;
- La spécification formelle de protocoles de gestion de conférence et de contrôle de
"floor" (protocoles GCCF) ainsi que leur vérification ;
- L’élaboration de mécanismes de réalisation des protocoles spécifiés ;
- L’implémentation de ces protocoles.

Au niveau de la définition de l’architecture, nous nous plaçons dans le cadre IETF où

l’aspect gestion et contrôle de conférence n’est pas défini. La problématique posée à ce niveau
est d’intégrer deux aspects importants pour la gestion du déroulement des systèmes de
téléconférence multimédia, à savoir : la gestion de conférence et le contrôle de "floor". Le
premier aspect concerne la gestion des membres de la téléconférence, le deuxième aspect
concerne la coordination des interventions des participants et le contrôle de l’accès aux
différentes ressources partagées (audio, vidéo, tableau blanc etc.).

Au niveau de la spécification formelle de protocoles de gestion de conférence et de

contrôle de "floor", nous utilisons la description informelle du protocole SCCP (Simple
Conference Control Protocol) de l’IETF. Cette description fournit les caractéristiques et les
services requis par de tels protocoles. Toutefois, elle ne spécifie pas le comportement des
politiques sociales qui peuvent régir un système de téléconférence. La problématique posée à
ce niveau est de définir le comportement de gestion et de contrôle de conférence et les
propriétés à vérifier pour pouvoir valider de tels systèmes.

Au niveau des mécanismes de réalisation, il s’agit d’élaborer des techniques

d’implémentation du contrôle de "floor". Ces techniques permettent de réguler le contrôle de
bas niveau et de synchroniser les événements entre les sites. Nous projetons utiliser les
techniques existantes de gestion et de contrôle d’accès multiples à des ressources partagées.
La problématique à ce niveau est d’adapter ces techniques en vue d’assurer un contrôle

13
d’accès dynamique tout en supportant l’avènement et le départ de participants au sein d’une
téléconférence multimédia.

Au niveau de l’implémentation, il s’agit de mettre en oeuvre les composantes de gestion

et de contrôle de conférence proposées dans notre architecture. Il s’agit aussi de réaliser les
protocoles de gestion de conférence et de contrôle de "floor" spécifiés en utilisant les
mécanismes proposés. Ces réalisations ont pour objectif d’expérimenter nos contributions. La
problématique posée à ce niveau consiste à effectuer les choix des outils et des plateformes
d’audio/vidéo appropriés et à adapter des environnements de visioconférence existants pour le
support de contrôle de "floor".

Cette thèse s’organise ainsi en deux parties : la partie "Etat de l’art" et la partie
"Architecture Spécification et implémentation". La première partie est organisée en trois
chapitres. Le premier chapitre présente les concepts relatifs aux systèmes coopératifs. Le
deuxième chapitre traite des standards et normes des systèmes de téléconférence multimédia.
Le troisième chapitre présente des systèmes de gestion de conférence et les concepts relatifs à
la gestion et contrôle de téléconférence.

La deuxième partie est organisée en quatre chapitres. Le premier chapitre est consacré à
l’architecture de gestion de conférence et de contrôle de "floor" ainsi qu’à la spécification
formelle du comportement des protocoles de gestion et de contrôle. Le deuxième chapitre
présente la définition des propriétés temporelles relatives à la sûreté et la vivacité du système
spécifié. Le troisième chapitre présente les mécanismes de réalisation. Le dernier chapitre
décrit les implémentations des systèmes de téléconférence que nous avons réalisées.

14
Première Partie

Etat de l’art

15
 Chapitre 1

Systèmes coopératifs

1.1 Introduction

Les systèmes de travail coopératif assisté par ordinateur (TCAO) constituent une classe
d’applications distribuées et interactives. Ces systèmes supportent les fonctions
habituellement fournies par les applications interactives (comme par exemple, des fonctions
permettant la visualisation des résultats d’une commande) ainsi que des fonctions spécifiques
destinées à supporter un travail coopératif dans lequel plusieurs intervenants agissent en
même temps ou à différents instants sur un espace de travail commun. Les systèmes de
téléconférence multimédia font partie de ces applications et permettent une coopération
synchrone moyennant différents outils (visioconférence, tableau blanc, application partagée,
etc.).

Dans ce chapitre, nous présentons les principaux concepts du travail coopératif assisté par
ordinateur. Nous donnons ensuite une classification des systèmes supportant le TCAO.

16
1.2 Travail coopératif

1.2.1 Définitions

Le travail coopératif assisté par ordinateur (TCAO) est un domaine de recherche

relativement récent. Il a vu le jour dans les années quatre-vingt au sein d’un groupe de travail
organisé par Irène Greif et Paul Cashman [Greif 88]. Ce domaine est connu aussi sous le nom
de CSCW (Computer Supported Cooperative Work) auquel est souvent associé le terme
"groupware" (ou collecticiel). La définition originale de ce terme est la suivante :

"GROUPEWARE = ensemble de procédures et de processus d’un groupe (GROUP)

intentionnel en vue de réaliser des objectifs spécifiques + des outils logiciels
(softWARE) conçus pour supporter et faciliter le travail de groupe" [John 82].

Une définition plus récente du groupware a été donnée par Ellis.

"un groupware est un système informatique qui supporte des groupes de personnes
engagées dans une tâche commune fournissant une interface à un environnement
partagé" [Elli 91].

Le CSCW est un champ multidisciplinaire [Kars 94] dans lequel interviennent des
recherches provenant de différentes sciences humaines : psychologie, sociologie et
ethnologie. La psychologie étudie les répercussions liées à l’utilisation d’un logiciel
coopératif. La sociologie s’intéresse dans ce domaine à l’étude des comportements sociaux et
des lois qui régissent les interactions des membres d’un groupe. L’ethnologie traite ces
interactions suivant les différentes cultures. Ainsi, la démarche générale de l’ingénierie
relative au CSCW consiste à définir des outils à la fois pour comprendre et analyser
l’interaction à l’aide de théories, méthodes et modèles issus des sciences humaines pour
ensuite envisager des solutions logicielles adaptées [Bann 93]. Toutefois, l’essor que connaît
actuellement le domaine CSCW est essentiellement lié à l’émergence des réseaux de
communication et à la large diffusion des moyens informatiques dans les environnements
professionnels, éducatifs et domestiques [Bour 00].

L’utilisation des collecticiels au sein des entreprises est essentiellement motivée par un
meilleur contrôle des coûts de production, une augmentation de la productivité, une
diminution du nombre de réunions en présentiel, une amélioration de la coopération entre des
équipes géographiquement réparties, etc.

17
1.2.2 Caractérisation du travail coopératif

Nous donnons dans cette section la définition des principaux concepts du travail
coopératif. Nous présentons ensuite les caractéristiques et les particularités des systèmes de
travail coopératif.

1.2.2.1 Terminologie

Coopération et travail coopératif

La coopération permet à plusieurs utilisateurs de travailler conjointement sur un même

projet. La coopération en informatique est une instantiation de cette définition et est basée sur
des moyens logiciels et matériels. Elle désigne une activité informatique menée par un groupe
d’utilisateurs dans un espace informatique commun. Le travail coopératif désigne un travail
faisant intervenir plusieurs utilisateurs sur des ressources informatiques communes [Dewa
01].

Groupe et individu

Chaque participant est un individu (ou acteur) qui appartient à un groupe de participants
utilisant un système de travail coopératif. Un groupe est un ensemble d’individus travaillant
sur un même domaine. D’autres termes synonymes au groupe sont utilisés dans la littérature à
savoir : collectif ou équipe [Bell 96].

Contexte partagé

Un contexte partagé désigne l’ensemble des ressources accessibles par un groupe

d’utilisateurs. Ces ressources peuvent être des données partagées ou des données concernant
l’état de progression du travail du groupe.

Rôle et vue

Dans un groupe de travail, un individu peut avoir un rôle bien précis [Davi 98]. Ce rôle
définit les droits et les devoirs du participant vis à vis de ces partenaires et des données
partagées. Il peut évoluer au cours du temps et être constitué de plusieurs rôles élémentaires.

Le terme "vue" est utilisé pour définir une perception d’un ensemble d’informations du
contexte partagé [Mari 94]. Elle peut être attachée à un rôle dans le sens où ce dernier permet
de définir les actions que peut mener un individu sur les entités manipulées collectivement.

18
1.2.2.2 Paramètres d’un système de travail coopératif

Mode d’interaction

Un système de travail coopératif peut adopter l’un des deux modes d’interaction suivants :
asynchrone ou synchrone. Une coopération asynchrone correspond aux applications
coopératives dont le support de communication est asynchrone et ne nécessite pas la co-
présence des différents participants. Ce mode est fréquemment utilisé dans l’édition
coopérative des documents [Deco 96]. En outre, la coopération synchrone correspond aux
applications coopératives où la présence des membres du groupe est obligatoire en même
temps. L’échange des informations est assuré en temps réel. Ainsi, les acteurs de ce type de
coopération sont avertis en temps réel sur les actions menées sur les ressources partagées
[Ohmo 92]. Les systèmes de téléconférence sont des exemples représentatifs de ce mode
d’interaction [Crow 95, Laur 00]. Il est également possible que des applications coopératives
utilisent les deux modes d’interaction [Mino 93].

Dans la suite, nous nous intéressons plus particulièrement aux paramètres des systèmes
coopératifs synchrones.

Mode de fonctionnement WYSIWIS

Le terme WYSIWIS (What You See Is What I See) a été introduit par Stefik dans [Stef
87]. Il signifie en français : "Ce que tu vois est ce que je vois". Le concept WYSIWIS garantit
une vue cohérente du contexte partagé à tout moment de la coopération. Toute modification
apportée à ce contexte est perçue par l’ensemble de tous les participants du groupe. Le
WYSIWIS implique nécessairement un mode d’interaction synchrone alors que ce type
d’interaction ne suffit pas pour définir le mode WYSIWIS.

Il existe deux types du WYSIWIS : le type strict et le type relaxé. Le WYSIWIS strict est
l’application extrême du mode de fonctionnement WYSIWIS. Il consiste à avoir une vue
identique des informations partagées sur tous les terminaux des participants. Seulement,
l’expérience a montré que les utilisateurs souhaitent des fois avoir une certaine indépendance
sur certains détails tels que par exemple, le fait de définir la taille ou le positionnement des
fenêtres sur l’écran. Le WYSIWIS relaxé, quand à lui, permet à chaque participant de
personnaliser l’interface du système de travail coopératif de manière à ce que différentes vues
du contexte partagé soient perçues par les participants [Baec 94, Gutw 95, Green 95, Sein 97].

19
 Granularité

La granularité caractérise la taille de l’entité élémentaire partagée par les membres

coopérants. A l’opposé du mode d’interaction, la granularité est une caractéristique spatiale
qui est fréquemment associée aux droits d’accès aux données. Elle définit l’unité
d’information (mot, paragraphe, document, etc.) à laquelle peut accéder simultanément
plusieurs participants. Elle peut aussi concerner une action dans un espace partagé d’une
application coopérative adoptant un mode WYSIWIS strict tel que le cas d’une application
partagée dans un système de télétravail.

Il existe deux types de granularité [Gutw 00], à savoir : la granularité fine et la granularité
faible. La granularité fine est associée à un mode d’interaction synchrone définissant un
travail fortement couplé et la granularité faible définit un travail faiblement couplé. Par
exemple, un éditeur de texte permettant l’accès simultané à un même mot permet une
granularité plus fine qu’un éditeur permettant l’accès à un document à la fois.

Conscience de groupe (Awarness)

Lorsque des personnes travaillent en co-présence, c’est à dire en même temps et dans le
même lieu, elles échangent un certain nombre d’informations implicites et explicites. Ces
informations créent chez chaque participant une "conscience de groupe" lui permettant de
situer ses actions au sein du groupe et de mesurer son activité dynamique. Cette notion de
conscience de groupe a été définie par Dourish [Dour 98, Bout 01] comme étant "la
compréhension des activités des autres, qui permet de donner un contexte à sa propre
activité". Dans un groupe virtuel, la disparition de la co-présence entraîne la disparition de
certaines informations et particulièrement les informations implicites. Ceci entraîne par
conséquent la disparition de la conscience de groupe.

Gestion de groupes

Un groupe est une entité logique qui permet de structurer un ensemble de membres
partageant une propriété particulière au sein d’un système. Ces membres peuvent être des
personnes ou des processus. L’intérêt majeur du concept de groupe est qu’il permet
d’abstraire les communications. En effet, un message peut être adressé à tous les membres du
groupe sans qu’il soit nécessaire de les nommer explicitement ni de connaître la taille du
groupe. Cette transparence facilite la conception d’algorithmes répartis relatifs au collecticiel.

Un groupe peut adopter différentes topologies logiques. Il peut être un groupe non
structuré, un groupe de diffusion ou un groupe hiérarchique. Un groupe non structuré est

20
composé de processus qui sont tous émetteurs et récepteurs. Un groupe de diffusion comprend
une partie de membres qui ne peuvent que recevoir sans avoir la possibilité d’émettre. Un
groupe hiérarchique adopte une structure arborescente [Lian 90].

Un groupe se caractérise également par les primitives de diffusion qui lui sont associées.
Ces primitives se distinguent par la propriété qu’elles respectent en matière de qualité de
service et d’ordonnancement des messages.

La gestion d’un groupe doit fournir des protocoles de connexion de nouveaux membres et
de déconnexion d’anciens membres de façon dynamique. Ces protocoles doivent fournir à un
nouvel arrivé une vue cohérente de l’espace partagé et doivent gérer le départ d’un participant
qu’il soit volontaire ou résultant d’une panne quelconque du réseau ou des sites.

Contrôle de la concurrence et contrôle d’accès

Le contrôle de la concurrence a pour rôle de veiller à ce que les actions concurrentes

puissent accéder à des objets partagés tout en maintenant un état cohérent du système. Cet
aspect a été largement traité dans les systèmes de gestion de base de données à l’aide du
modèle transactionnel [Domm 97]. Le contrôle de la concurrence dans un collecticiel se
rapproche plus du contrôle de la cohérence dans les systèmes distribués (sérialisation des
opérations concurrentes et synchronisation). Une technique courante consiste à verrouiller les
objets partagés [Domm 99]. Cette technique reste peu commode dans le sens où elle peut
engendrer le problème de famine suite à un départ d’un participant ou une défaillance du site
relatif au participant ayant procédé au verrouillage. De ce fait, la concurrence doit être gérée
par des protocoles plus appropriés. [Kana 95] propose une décomposition d’un protocole de
gestion de concurrence en trois couches, dites modèles : modèle de concurrence, modèle de
cohérence et modèle de communication. Le modèle de concurrence décrit le degré de
parallélisme supporté par le protocole. Le modèle de cohérence décrit les contraintes
imposées aux mises à jour des objets du contexte partagé. Le modèle de communication décrit
les propriétés de communication de groupe sur lequel s’appuie le protocole de concurrence.

Le contrôle d’accès constitue un autre moyen pour éviter les conflits entre les participants
et les incohérences de l’espace partagé. Il se base sur la gestion des droits d’utilisation des
outils d’un collecticiel et le droit d’exécution de certaines de ses fonctionnalités. Les droits
d’accès sont définis en fonction des rôles assignés aux différents participants et sont
dynamiquement attribués au cours du travail coopératif.

21
 Protocoles coopératifs

Les protocoles coopératifs définissent les règles ou politiques gouvernant les interactions
entre les différents utilisateurs. On distingue deux types de protocoles : les protocoles sociaux
et les protocoles technologiques. Un protocole social se réfère aux séquences possibles
d’échanges de signaux et d’informations qui déterminent et identifient les discussions. Les
règles d’échange sont définies par le groupe de travail et sont proches à ses besoins.
Toutefois, elles sont soumises à la bonne volonté des participants. Ils peuvent ainsi être
injustes voire inefficaces. Au contraire, les protocoles coopératifs technologiques quand à eux
sont implémentés par des logiciels et permettent de structurer le groupe et les interactions de
ses membres. Ils peuvent être restrictifs en limitant les possibilités d’utilisation.

Architectures coopératives

L’architecture d’un collecticiel peut adopter l’une des trois approches suivantes [Kars 94,
Cour 01]: l’approche centralisée, l’approche distribuée et l’approche hybride. Dans la
première approche, un seul processus gère la cohérence des données et les actions entreprises
par les différents utilisateurs. Cette approche a l’avantage de la simplicité d’implémentation et
en particulier lorsqu’il s’agit de l’implantation de la synchronisation et du contrôle de la
concurrence. Cependant, elle présente deux inconvénients majeurs : un temps de réponse lent
et la non-tolérance aux fautes [Greg 99].

L’architecture distribuée correspond aux collecticiels où chaque utilisateur dispose de son

propre processus. Les données sont répliquées sur chaque site et leur cohérence est maintenue
grâce à des communications entre les différents processus. Cette approche est difficile à
mettre en œuvre. En effet, la répartition du contrôle rend plus complexe les opérations telles
que la cohérence des données ou l’ordonnancement des actions [Lauw 90, Laur 02a, Laur
02b ; Ande 00].

L’approche hybride se base sur un processus central qui gère la cohérence des données et
un processus par utilisateur qui gère ses actions. Elle résoud partiellement l’inconvénient de la
lenteur du temps de réponse mais ne résoud pas le problème de la tolérance aux fautes.

1.2.2.3 Caractérisation fonctionnelle

Pour structurer l’analyse et la conception d’un collecticiel, il est judicieux d’avoir une
catégorisation de ses fonctionnalités. Dans ce sens, [Salb 95] propose le modèle du trèfle
(figure I.1.1) qui s’inspire du modèle donné par [Elli 94] et fournit un cadre conceptuel

22
déterminant trois espaces fonctionnels que doit couvrir un système de travail coopératif :
l’espace de production, l’espace de communication et l’espace de coordination. Ce cadre
constitue un moyen de classification de nombreux outils permettant d’atteindre les objectifs
d’un tel travail.

Production Communication

Coordination

Figure I.1.1. Modèle du trèfle.

Espace de production

Dans certaines situations, il est possible de coopérer grâce à la seule présence face à
face (éventuellement virtuelle). Cependant, une coopération plus fructueuse nécessite le
partage d’information au sein d’un espace de production. Cet espace concerne des
fonctionnalités de production d’objets partagés tels que des documents et la gestion des
accès à ces données.

Espace de communication

Cet espace correspond aux fonctionnalités permettant l’échange d’informations entre

les acteurs d’un système supportant le travail coopératif. Cet échange est assuré par la
communication homme-homme médiatisée [Salb 95]. [Tarp 97] a réservé le mot
communication à un échange de données informatiques et associe le terme conversation à
tout échange coopératif. Il existe différents modes de conversation à savoir le textuel
(messagerie, chat), le gestuel (langue des signes), l’audio (téléphone), la vidéo
(mediaspace).

Espace de coordination

Pour se coordonner, les participants d’un travail coopératif ont besoin de suivre les
activités des autres participants ainsi que l’utilisation et l’évolution des ressources

23
 partagées. C’est le rôle de l’espace de coordination de supporter ces aspects. Il correspond
aux fonctionnalités dédiées à l’assignation des tâches et des rôles aux différents acteurs
d’une activité coopérative en vue de coordonner leurs interventions. Cette coordination
peut s’exprimer en terme de planification de tâches.

Toutefois, il convient de noter que certaines fonctionnalités peuvent être à l’intersection

de plusieurs espaces. En effet, il est tout à fait possible qu’une activité de coordination ait lieu
après une activité de communication. Par exemple, la prise de rendez-vous par téléphone est
une activité de coordination basée sur une activité de communication. De plus, le rôle
fonctionnel global d’un système de travail coopératif peut évoluer au cours du temps. Cette
évolution peut être modélisée par le modèle du trèfle (figure I.1.1). En effet, dans un système
dédié à la production, il est possible, à un moment donné, que l’activité de groupe soit centrée
sur la communication en vue de se coordonner pour redéfinir l’activité de production.
Toutefois, il faut noter que les trois espaces ne sont pas forcement supportés par un
collecticiel. Ceci est le cas du courrier électronique qui ne supporte que l’espace de
communication.

1.3 Classification des systèmes TCAO

Il existe trois types de classification des systèmes de travail coopératif assisté par
ordinateur dans la littérature : classification espace-temps, classification par travail coopératif
et classification par domaine d’application.

1.3.1 Classification espace-temps

La classification espace-temps repose sur la matrice "matrice espace-temps" ou matrice de

Johannsen [Joha 88]. La figure I.1.2 représente cette catégorisation à partir des variantes
proposées par [Davi 98, Elli 91, Hoft 98]. Cette classification repose sur deux
caractéristiques, à savoir où et quand une action est exécutée par des utilisateurs par rapport à
d’autres utilisateurs. Elle s’organise selon deux axes : l’axe espace et l’axe temps. Le premier
axe considère la distance spatiale entre les utilisateurs et le deuxième axe considère la
distance temporelle.

24
 interaction face à face interaction asynchrone
même lieu
exemple : jeu sur console exemple : Workflow

interaction synchrone interaction asynchrone

lieux distribuée distribuée
différents exemple : appel exemple : mail
téléphonique

même moment moments différents

Figure I.1.2. Classification espace-temps du travail coopératif.

Cette taxonomie est largement répandue dans la littérature. Toutefois, elle présente
quelques insuffisances pour représenter l’ensemble des collecticiels. Par exemple, les
collecticiels présentant un mode d’interaction variable synchrone/asynchrone tels que
l’éditeur présenté dans [Mino 93], peuvent figurer dans la classe des collecticiels synchrones
et asynchrones. Cette classification présente ainsi les limitations suivantes :

- elle ne permet pas de placer distinctement tous les collecticiels dans une classe parmi
les quatre classes identifiées ;

- plus d’informations sur la nature et le fonctionnement sont généralement requises

pour une classification.

1.3.2 Classification par travail coopératif

La classification par travail coopératif repose sur le modèle du travail coopératif présenté
par [Dix 93]. Ce modèle (figure I.1.3) identifie deux entités impliquées dans le travail
coopératif : les participants (P) et les artefacts du travail (A). Les artefacts représentent les
entités manipulées permettant aux participants d’interagir entre eux et avec le système. Les
outils mis à disposition de l’utilisateur dans une application de tableau partagé sont des
exemples de tels artefacts (exemple : tableau blanc et outil d’applications partagées de
l’environnement Platine [Baud 02]).

25
 Compréhension P : Participant
mutuelle A : Artefact

P P
Comunication
directe
Manipulation et
rétroactions

A Artefact du travail

Figure I.1.3. Taxonomie du travail coopératif.

Les relations entre les entités de ce modèle de travail coopératif sont de trois types :

- la communication directe entre les participants (orale, écrite ou gestuelle, etc.) ;

- l’établissement d’une compréhension mutuelle pour mener des actions conjointes ;

- la manipulation des artefacts qui évoque la manipulation des objets partagés. La

rétroaction est la perception par les autres utilisateurs du résultat de ces actions.

A partir de ce modèle, [Dix 93] a identifié trois catégories de collecticiels :

- les systèmes de communication médiatisés dédiés à la communication directe entre

les participants.

- Les systèmes de réunion et d’aide à la décision qui ont pour but de favoriser et
d’aider à la compréhension mutuelle pour faciliter le déroulement de réunion ou la
prise de décision.

- Les systèmes d’espaces partagés qui recouvrent les collecticiels mettant en œuvre
des espaces partagés dans lesquels les participants peuvent manipuler des artefacts.

1.3.3 Classification par domaines d’applications

La classification par domaines d’applications se base sur les applications de travail

coopératif existantes. Cette classification doit souvent être révisée pour prendre en compte de
nouveaux types d’applications. Cette classification repose sur quatre catégories de

26
collecticiels : les applications d’édition partagée, les applications pour la coordination, les
applications de jeu en réseau et les applications dédiées à la Communication Homme-Homme
Médiatisée (CHHM ou CMC pour Computed-Mediated Communication).

a. Les applications d’édition conjointe

Ces applications permettent à des utilisateurs de partager un ensemble de documents, de

les éditer, d’en modifier le contenu et de visualiser les opérations des autres intervenants.
Elles permettent ainsi de mener une édition coopérative de documents avec gestion des
différentes versions. Ces outils sont complexes à réaliser, en particulier pour la gestion des
tâches concurrentes comme le "défaire" et "refaire" (undo et redo) [Chou 95, Zafe 01] ou la
fusion de différentes versions [Dour 96]. StorySpace [East 02] est un exemple d’éditeur de
texte partagé.

b. Les applications pour la coordination

Les applications pour la coordination regroupent les systèmes de workflow, les systèmes
d’aide à la décision et les calendriers partagés.

- Les systèmes workflow [Bowe 95, Elli 99, Whit 00] sont des systèmes dédiés à la
gestion de processus (industriels, commerciaux, administratifs etc.) et à la coordination des
différents intervenants au cours d’un processus. De tels systèmes ont pour objectif
l’élaboration de documents et ont la charge de veiller à leur bonne circulation entre les
différents intervenants aux moments clés du processus.

- Les systèmes d’aide à la décision permettent d’assister un groupe d’utilisateurs pour des
discussions qui facilitent l’obtention d’un consensus en vue d’une prise de décision [Usab 02].
CoNex (Coordinator and Negociation Support for eXpert in design applications) [Hahn 91]
est un exemple d’un tel système.

- Les agendas partagés [Pale 02] offrent des services de planification des tâches, de
gestion de projets et de coordination de membres d’une équipe de travail. A la différence des
systèmes de workflow, la planification n’est pas basée sur l’acheminement des documents. De
tels systèmes permettent la détection des incompatibilités dans la planification d’une tâche ou
la détermination de plages horaires communes aux membres du groupe.

c. Les jeux en réseau

Les jeux en réseau permettent à un groupe de personnes géographiquement distribuées de

mener un jeu ensemble. C’est un type de collecticiel qui se base sur la coopération et la

27
compétition entre joueurs. Quake [IdSo 02] et Starcraft [Bliz 02] sont des exemples de tels
systèmes.

d. les applications CHHM

Les applications CHHM regroupent les messageries électroniques, les forums de

discussion, les mediaspaces et les systèmes de téléconférence.

- Les messageries électroniques sont actuellement les collecticiels les plus répandus et
les plus utilisés. Ils se sont enrichis de fonctionnalités "intelligentes" pour trier les
courriers, détruire ceux qui sont indésirables et envoyer des réponses
automatiquement [Qual 02].

- Les forums de discussion peuvent être de deux classes principales selon leur mode
d’utilisation (synchrone ou asynchrone). La première classe regroupe les forums en
ligne du type IRC (Internet Relay Chat). La deuxième classe rassemble les listes de
diffusion (mailing list) et les news groups. Contrairement au courrier électronique,
ce type de collecticiel est destiné à communiquer avec un grand nombre de
personnes.

- Les mediaspaces [Cout 99, Dour 96, Finn 97, Mack 99] sont des collecticiels mettant
en œuvre une liaison vidéo permanente au sein d’une équipe dans le but de favoriser
la communication informelle et d’entretenir une conscience de groupe forte entre
membres distants. Ce type de collecticiel soulève le problème de protection de la vie
privée de par la présence des caméras fonctionnant en permanence.

- Les systèmes de téléconférence permettent à des personnes physiquement distantes

de mener des réunions de travail ou des conférences [Baud 01b]. Ces applications
ont la lourde tâche de remplacer les réunions autour d’une table, devant un tableau
ou un rétro-projecteur. Ces applications mettent à la disposition des utilisateurs des
canaux de communication audio/vidéo. Les premières applications de téléconférence
utilisaient des canaux de communications analogiques annexés aux supports
informatiques. CAVECAT [Mant 94] met en œuvre un équipement vidéo annexe au
matériel informatique.

La seconde génération d’applications de téléconférence présente un environnement de

travail complètement intégré. Souvent équipées de moyen de communication audio/vidéo
numériques, de telles applications fournissent des outils pour supporter le travail coopératif. Il

28
s’agit en général de fenêtres partagées servant de tableaux de présentation, d’éditeurs ou
d’applications de dessin.

Les systèmes de téléconférence supportent une coopération synchrone entre les membres
qui participent à la conférence. Cette coopération synchrone est assurée via l’échange en
temps réel de différents types de données. Ils permettent aussi une collaboration en mode
WYSIWIS en offrant aux participants des outils pour le partage des données tels que les
tableaux blancs et les outils d’applications partagées. Toutefois, la conscience de groupe doit
être gérée à l’aide d’autres mécanismes vu que la co-présence dans de tels systèmes est
virtuelle.

1.4 Conclusion

Dans ce chapitre, nous avons présenté la définition de la coopération et du travail

coopératif assisté par ordinateur. Nous avons ensuite présenté les principaux concepts des
systèmes coopératifs ainsi que différents modèles de leur classification. Ces systèmes peuvent
être synchrones ou asynchrones. Nous nous intéressons dans la suite de ce mémoire au
premier type de ces systèmes qui nécessite un support technique permettant aux usagers de
collaborer en temps réel et d’échanger différents types de médias.

29
 Chapitre 2

Normes et protocoles standards des

systèmes de téléconférence

2.1 Introduction

Nous avons présenté dans le chapitre précédent les propriétés et les caractéristiques des
systèmes coopératifs. Ces systèmes requièrent un support technologique permettant l’échange
des différents types de données (texte, audio et vidéo) et fournissant des outils relatifs au
travail coopératif (tableau blanc, application partagée etc.). De tels services sont assurés par
les systèmes de téléconférence. En vue de remédier aux problèmes relatifs à l’hétérogénéité
des plates-formes assurant le transport des données multimédias, il a été nécessaire de
standardiser les équipements et les protocoles relatifs à ces aspects. Dans ce sens, l’IUT
(Internationnal Telecommunication Union) et l’IETF (Internet Engineeering Task Force) ont
effectué plusieurs travaux permettant une telle standardisation.

Dans ce chapitre, nous présentons tout d’abord la recommandation H.323 qui fournit une
standardisation de l’architecture, des équipements et des protocoles de transmission audio et
vidéo. Nous présentons ensuite, les travaux de l’IETF concernant les systèmes de
téléconférence.

30
2.2 Recommandation H.323

L’ITU (Internationnal Telecommunication Union) a initié la standardisation des

équipements audio/vidéo permettant la communication coopérative entre plusieurs utilisateurs
vers la fin des années 80. Ces efforts de standardisation ont conduit à l’élaboration des
recommandations des séries H.32x. Chacune de ces recommandations est un standard
consistant en un ensemble de protocoles pour une fonctionnalité bien précise. Le premier
standard H.320 [ITU 93a] a été finalisé en 1990 et concerne les systèmes RNIS (Réseau
Numérique à Intégration de Services) à bande étroite. Ce standard a été adapté en 1995 pour
les réseaux RNIS large bande et constitue la série H.321 [ITU 95a]. Les séries H.322 [ITU
95b] et H.323 [ITU 96a] ont été définis pour les réseaux locaux (LAN). L’aspect donnée d’un
système H.32x est décrit dans la série de recommandation T.120 [ITU 96b]. Nous présentons
dans ce qui suit, les recommandations H.323 et T.120.

2.2.1 Architecture H.323

La recommandation H.323 définit les spécifications techniques concernant les

équipements audio/vidéo lorsque la transmission s’effectue sur un ou plusieurs réseaux
locaux, ne pouvant pas offrir une qualité de service garantie équivalente à celle du RNIS à
bande étroite. L’architecture d’un environnement H.323 (figure I.2.1) comporte quatre
principaux composants : les terminaux H.323, les passerelles (Gateway), les portiers
(Gatekeeper) et les MCUs (Multicast Control Unit).

- Terminal

Le terminal H.323 (figure I.2.2) est le point d’extrémité de l’environnement H.323 qui
fournit une communication temps réel. Un terminal supporte les fonctionnalités de base d’un
système H.323. Ces fonctionnalités sont fournis par des composants permettant
l’acheminement des médias audio (par exemple G.711 [ITU 88a]), vidéo (par exemple H.261
[ITU 93b]), des messages de contrôle H.245 [ITU 95c] et H.225 [ITU 95d] et des données
applicatifs T.120.

31
 H.323 MCU

Passerelle Terminal
RNIS RTGC H.324

Terminal H.323

Terminal
Terminal H.323 H.324
Terminal H.323

Portier H.323

Internet

Firewall
Zone H.323 Terminal
H.324

Figure I.2.1. Environnement H.323.

Le codec vidéo a pour rôle de coder le signal vidéo provenant de la source vidéo (caméra)
pour transmission et de décoder le code vidéo reçu qui est restitué sur un écran vidéo. Le
codec audio code le signal reçu du microphone pour transmission, et décode le code reçu qui
est restituée à la sortie du haut-parleur.

La voie de données assure diverses applications télématiques : transfert d’images fixes,

échange de fichiers, accès à des bases de données, etc. L’application de données normalisée
pour la conférence audio-graphique en temps réel est celle de la recommandation T.120. Le
module de gestion système assure la signalisation nécessaire au bon fonctionnement du
terminal H.323. Il assure la commande d’appel, l’échange des capacités, la signalisation des
commandes et des indications et fournit des messages d’ouverture des voies logiques pour
l’acheminement des médias.

La couche H.225 assure le formatage des trains de signaux vidéo, audio, de données et de
commande à transmettre à l’interface réseau. Elle extrait les trains des signaux des messages
reçus des messages entrant provenant de l’interface réseau.

32
 Codec video
H.261, H.263

Codec audio Retard sur le

G.711, G.722, trajet de
G.723, G.728, reception
G.729 Interface
Données
T.120 Couche Réseau
Gestion du H.225
Commande H.245
Interface du
module de Commande
gestion avec d'appel H.225
l'utilisateur Call Control
Commande RAS
Contrôle H.225

Figure I.2.2 Terminal H.323.

- Passerelle

La passerelle a pour rôle d’assurer la conversion entre les formats de transmission (par
exemple, du format H.225 au format H.221 ou vice versa) ainsi qu’entre les procédures de
communication (par exemple, de la procédure H.245 à la procédure H.242 ou vice versa). La
passerelle assure aussi l’établissement et la libération des connexions tant du côté réseau local
que du côté réseau à commutation de circuits (SCN).

La passerelle peut assurer aussi la conversion entre les formats vidéo, audio et données.
En général, la passerelle a pour rôle d’informer un point d’extrémité du réseau (SCN) des
caractéristiques d’un point d’extrémité du réseau local et vice versa, de façon transparente.

Un point d’extrémité H.323 peut communiquer avec un autre point d’extrémité H.323
directement sur le même réseau local, sans l’intermédiaire d’une passerelle. Celle-ci peut être
omise s’il n’est pas nécessaire d’établir des communications avec les terminaux du réseau à
commutation de circuit.

- Portier

Le portier, optionnel dans un système H.323, assure des services de commande d’appel
aux points d’extrémité H.323. Plusieurs portiers peuvent coexister et communiquer entre eux
dans un mode non précisé. Le portier est en principe séparé des points d’extrémité. Il peut
toutefois être couplé à un terminal, une passerelle, un contrôleur multipoint ou un autre
dispositif du réseau local non H.323.

33
 Lorsqu’un portier est intégré dans un système H.323, il doit assurer les fonctionnalités
suivantes :

- Conversion d’adresses – Le portier doit convertir l’adresse pseudonyme en adresse de

transport. Il utilise à cet effet une table de conversion qu’il met à jour à l’aide des
messages d’enregistrement. Ces messages sont émis par les nouveaux points d’extrémités
intégrant une zone H.323.

- Contrôle des admissions – Le portier doit autoriser l’accès au réseau local au moyen des
messages ARQ/ACF/ARJ (demande/confirmation/refus d’admission) H.225.
L’autorisation d’accès peut être fondée sur l’autorisation d’appel, la largeur de bande ou
d’autres critères.

- Régulation de la largeur de bande – Le portier doit prendre en charge les messages

BRQ/BRJ/BCF (demande/refus/confirmation de modification de la largeur de bande). La
prise en charge de ces messages peut être fondée sur la gestion de la largeur de bande.

- Gestion de zone – Le portier doit assurer les fonctions mentionnées ci dessus pour les
terminaux et les passerelles qui se font enregistrés auprès de lui dans une zone H.323.

- MCU

Le MCU H.323 (Multipoint Control Unit) consiste en deux composants fonctionnels : le

contrôleur multipoint et le processeur multipoint. Le contrôleur multipoint assure des
fonctions de commande pour la mise en œuvre de conférences entre au moins trois points
d’extrémité dans une conférence multipoint. Il procède à l’échange des capacités multipoints
entre les différents points d’extrémité participant à ce type de conférence. Il envoie ensuite un
ensemble de capacités à ces points d’extrémité, indiquant les modes de fonctionnement dans
lesquels ceux-ci peuvent émettre.

Le contrôleur multipoint détermine ainsi le mode de communication choisi (SCM,

Selected Communication Mode) pour la conférence. Le mode SCM peut être commun à tous
les points d’extrémité participant à la conférence. Certains points peuvent aussi ne pas utiliser
le même mode SCM que les autres points d’extrémité participant à la conférence. Le
processeur multipoint reçoit les trains de signaux audio, vidéo et/ou de données en
provenance des points d’extrémité participant à une conférence multipoint, les traite et les
renvoie aux points d’extrémité.

34
 Un processeur multipoint assurant le traitement vidéo doit assurer la commutation vidéo
ou le mélange vidéo. La commutation vidéo est le processus de sélection de l’image que le
processeur multipoint transmet aux terminaux d’une source à une autre. Le mélange vidéo
consiste à formater plusieurs sources vidéo que le processeur envoie aux terminaux. Un
processeur audio qui assure le traitement audio doit préparer N sorties audio à partir de M
entrées audio par commutation ou mélange ou par une combinaison de ces deux procédés.

2.2.2 Protocoles d’un système H.323

Les entités de l’architecture H.323 interagissent en utilisant la pile de protocoles

représentée dans la figure I.2.3. Quoique H.323 est spécifiée pour un réseau à commutation
de paquets, seul le réseau IP est actuellement le meilleur en pratique. H.323 utilise le
protocole TCP dans le but d’assurer l’acheminement fiable des signalisations de
l’initialisation (Setup Call) au dessus de IP. Le transport de l’audio et la vidéo fait appel à la
connexion non fiable UDP. La spécification T.120 est utilisée pour les données.

La connexion initiale est établie entre un appelant (caller) et un port de l’appelé (callee).
H.323 spécifie la signalisation des appels et le contrôle de capacités dans deux protocoles
séparés : le protocole H.225 et le protocole H.245. H.225 couvre l’initialisation de l’appel et
la signalisation de l’appel initial entre deux participants. Le document H.225 comporte de
sous protocoles : le protocole RAS (Registration/Admission/Statut) et le protocole de contrôle
d’appel dérivé du protocole Q.931. La norme H.245 constitue le protocole de contrôle de
média que le système H.323 utilise après l’établissement de l’appel. H.245 permet aussi la
négociation et l’établissement des canaux au dessus de RTP/RTCP.

Q.931
H.245 T.120 Audio Vidéo
(H.225) RAS
(H.225)

X.224 Class 0 RTP/RTCP

TCP UDP

Network Layer

Figure I.2.3. Pile de protocoles pour une conférence H.323.

35
 La figure I.2.4 montre la séquence des actions lors de l’initialisation d’une conférence
H.323. L’appelant envoie un message d’initialisation (Setup Message) contenant son nom et
son adresse IP. L’appelé envoie un message d’alerte (Alerting Message) après avoir notifié le
participant du message reçu. Si l’appelée refuse l’appel, il envoie le message de refus
(Release Complete). Sinon, il envoie le message de connexion (Connect) contenant l’adresse
et le port sur lequel il est en écoute pour une connexion H.245.

Site A Site B

H.225/Q.931 Setup (conf name, IP addr)

Alerting

Connect (IP addr, port)

H.245 (Capacité du terminal)

Accept

RTP

RTP/RTCP

End

Figure I.2.4. Séquence de messages d’initialisation d’une conférence H.323.

2.2.3 Recommandation T.120

La recommandation T.120 décrit un modèle de système qui fournit une architecture de

communication de données multipoint dans un environnement multimédia H.32x. Elle fournit
des services d’établissement et de gestion de communications interactives (conférences)
impliquant deux participants ou davantage sur et entre un certain nombre de réseaux
différents. Elle consiste en une série de normes, auxquelles il est collectivement fait référence
comme série T.120. Nous présentons dans ce qui suit, l’architecture de communication
multipoint de la recommandation T.120 puis nous décrivons le modèle de système T.120.

36
2.2.3.1 Architecture de communication multipoint

Traditionnellement, les services téléphoniques se sont vus dans la nécessite de fonctionner

en point à point. Pour prendre en charge des activités de groupe telles que les conférences
impliquant plus de deux participants, il y a eu besoin de brancher plus de deux emplacements.
L’expression de communication multipoint résout ce problème et décrit simplement
l’interconnexion de terminaux multiples.

MCU

MCU MCU MCU

Terminal Terminal Terminal Terminal Terminal Terminal

Figure I.2.5. Architecture multipoint T.120.

L’architecture de communication multipoint du modèle T.120 adopte une structure

hiérarchique. Les différents sites participant à une conférence régie par le modèle T.120 sont
connectés à une unité de contrôle multipoint (MCU pour Multipoint Control Unit). Plusieurs
MCUs peuvent être liées ensemble de manière à former un seul domaine. La figure I.2.5
illustre cette structuration. Chaque domaine dispose d’un MCU de haut niveau qui héberge
les informations de tous les nœuds du domaine et constitue une entité critique pour la
conférence. En effet, si cette entité tombe en panne ou quitte la conférence, la conférence se
termine. Si un MCU de niveau bas tombe en panne, seul les nœuds de l’arbre dont ce MCU
est la racine, sont éliminés de la conférence.

2.2.3.2 Modèle de système T.120

Le modèle de système T.120 se compose d’une infrastructure de protocoles de

communication et des protocoles d’application qui en font usage. L’ensemble de ces

37
protocoles forme la pile représentée par la figure I.2.6. Cette pile est organisée en couches
superposées. Chaque couche de cette pile fournit des services à la couche immédiatement
supérieure et communique avec ses homologues en envoyant des unités de données
protocolaires en utilisant les services fournis par la couche immédiatement inférieure.

Application(s) d'utilisateur
(utilisant les protocoles d'application tant normalisés que non normalisés)

Application(s) d'utilisateur utilisant les Application(s) d'utilisateur utilisant les

protocoles d'application normalisés Contrôleur nodal
protocoles d'application non normalisés

Trensfert de fichiers

Image fixe T.126

entité protocolaire d'application
Entité protocolaire d'application non normalisée

Recommandation de la série T.120

sur les protocoles d'application

Commande Générique de Conférence (GCC)

T.124

Service de Communication Multipoint (MCS)

T.122/T.125

Protocoles de transport propre au réseau

T.123

Recommandation de base de la série T.120

Figure I.2.6. Modèle du système T.120.

La couche "applications d’utilisateur" ne fait pas objet d’une normalisation dans la série
des recommandations T.120. Les applications qui utilisent les services offerts par la série
T.120 seront généralement adaptées au multipoint et conçues pour utiliser les services T.120
fournis par la couche GCC et la couche MCS. Elles peuvent utiliser toute combinaison de
protocoles normalisés ou non normalisés pour communiquer avec des applications
d’utilisateur homologues.

Les protocoles d’applications comprennent un ensemble d’unités de données protocolaires

(PDU) et les actions qui leur sont associées pour la communication de l’application avec une
ou plusieurs entités homologues. La série T.120 comporte un ensemble de protocoles

38
d’application conçus pour satisfaire les besoins de la conférence multipoint. Ces protocoles
définissent des seuils d’exigences, en vue de garantir l’inter-fonctionnement des différentes
réalisations. T.127 [ ITU 96c] fournit un transfert de fichiers en mode multipoint. T.126 [ITU
97] fournit la visualisation des images fixes et leur annotation, le panneau de téléaffichage
partagé et la télécopie. La recommandation T.121 [ITU 96d] présente des modèles et des
directives susceptibles d’aider à définir de nouveaux protocoles d’application.

Le contrôleur nodal (node controller) est l’élément qui procure le rôle de gestion T.120 à
un terminal ou à un MCU. Il émet des primitives vers le fournisseur GCC, qui fait débuter et
commande la session de communication. Le contrôleur nodal lui même est hors du domaine
d’application des recommandations de la série T.120. Seule ses interfaces de communication
avec le GCC sont définies.

L’infrastructure de communication fournit la connectivité multipoint avec une remise de

données fiable. Elle peut accepter de multiples applications indépendantes qui utilisent
simultanément le même environnement multipoint. Les connexions entre nœuds peuvent être
n’importe quelle combinaison de réseaux de télécommunications à commutation de circuits,
de LAN et de réseaux de données à commutation de paquets. L’infrastructure T.120
comprend trois composantes normalisées : la commande générique de conférence (GCC,
Generic Conference Control), le service de communication multipoint (MCS, Multipoint
Communication Service) et les profils de protocole de transport pour chacun des réseaux pris
en charge.

La couche GCC fournit un ensemble de services pour l’établissement de la gestion de la

conférence multipoint. Elle fournit le contrôle d’accès et la négociation des capacités. Les
services de la couche GCC sont utilisés par les applications pour coordonner l’utilisation des
canaux et jetons MCS. Les services de la couche GCC peuvent être aussi utilisés pour
interroger une MCU ou un nœud de terminal multi-accès pour localiser une conférence.
Plusieurs applications peuvent être lancées, utilisées et fermées dynamiquement au cours
d’une conférence sur un nœud donné. La couche GCC rend aussi accessible aux applications
un service centralisé, de façon à identifier les ressources attribuées dynamiquement, telles que
canaux et jetons.

La couche "services de communication multipoint" fournit un service polyvalent de

données multipoint axé sur la connexion. Il regroupe des connexions de transport point à point
et les combine pour constituer un domaine multipoint. Dans ce domaine sont fournis un grand
nombre de canaux logiques qui peuvent effectuer la remise des données d’un utilisateur à un

39
autre, d’un utilisateur à un groupe et d’un groupe à un utilisateur. Dans un domaine MCS, les
nœuds sont organisés hiérarchiquement en une arborescence. La remise des données suit le
trajet le plus efficace et un mécanisme est fourni pour garantir que les données expédiées sont
reçues dans le même ordre à tous les nœuds.

2.3 Architecture IETF

Récemment, il y a eu un grand intérêt pour l’utilisation de l’Internet comme support des

applications multimédias distribuées en général et celle relatives à la téléconférence en
particulier. Malgré que le réseau Internet ne soit pas conçu pour ce genre d’applications, de
grands efforts ont été déployés par l’IETF pour développer des architectures et des protocoles
assurant l’échange d’informations multimédias en temps réel. Ces efforts ont été initiés par
[Deer 91] qui a introduit la notion de multicast dans les protocoles Internet en vue de
supporter la communication de groupe. Ceci a permis le développement d’une infrastructure
de routage multicast (Multicast Backbone ou Mbone ).

Application(s) utilsateur

Gestion de Conférence Agents Média

Initiation & découverte Audio / Applications

Contrôle de conférence partagées
de conférence Vidéo

SDP Contrôle Multicast

Distribué RTP / RTCP
SAP SIP HTTP SMTP RSVP fiable

UDP TCP
UDP

IP / IP Multicast

Figure I.2.7. Architecture IETF pour la téléconférence sur Internet.

Les travaux de [Zhan 93] concernant la réflexion sur des mécanismes de réservation de
ressources ont permis d’assurer une certaine qualité de service raisonnable pour la
transmission des médias sur Internet. Ces travaux ont fait du Mbone une infrastructure
capable de supporter la transmission des différents médias en temps réel. Dans l’objectif de
structurer les protocoles développés pour le support des systèmes de téléconférence sur
Internet, l’IETF a élaboré une architecture sous forme d’une pile de protocoles [Hand 97]

40
(figure I.2.7). Dans cette architecture nous distinguons trois catégories de protocoles. La
première catégorie concerne les protocoles de transport (UDP, TCP) et de routage unicast (IP)
et multicast (IP Multicast). La deuxième catégorie regroupe les protocoles relatifs au transfert
des données multimédia. La troisième catégorie comporte les protocoles relatifs à l’initiation,
au contrôle et la gestion de conférence.

2.3.1 Multicast Internet

La transmission multicast est définie comme étant la transmission d’une source vers un
nombre variable de récepteurs [Deer 91]. Le besoin de ce type de transmission s’est exprimé
essentiellement avec l’apparition des applications nécessitant une communication de groupe.
Comparée à N transmissions point à point, la transmission multicast comporte deux avantages
principaux.

Le premier avantage est qu’elle permet de rendre plus simple la gestion d’un nombre
variable de récepteurs. En effet, dans le cas de N transmissions point à point, chaque arrivée et
chaque départ d’un membre du groupe s’accompagnent de messages de signalisation
explicites vers tous les émetteurs du groupe. Dans la transmission multicast, l’arrivée ou le
départ d’un membre se fait par l’envoi d’un seul message du protocole gérant le multicast sur
réseau local (IGMP : Internet Group Multicast Protocol ou LMD : Listener Multicast
Discovery). Ce message concerne une adresse multicast qui représente l’adresse du groupe.

Le deuxième avantage de la transmission multicast est qu’elle permet de réduire le trafic

global échangé entre la source et les récepteurs. En effet, dans le cas de N transmissions point
à point, N copies du même paquet sont transmises vers les N récepteurs. Dans le cas de la
transmission multicast, une seule copie est transmise vers les N récepteurs.

A priori, quand une source émet vers un groupe, elle ne sait pas quels sont les
destinataires qui veulent recevoir ses paquets. Pour ce faire, la transmission multicast sur
Internet est assurée par deux types de protocoles. Le premier protocole concerne le réseau
local et a pour objectif de détecter la présence ou l’absence de(s) membre (s) dans le groupe.
Ce protocole porte le nom d’IGMP [Fenn 97] dans la version 4 d’IP et le nom MLD [ Deer
99] dans la version 6 d’IP.

Le deuxième type de protocole concerne le réseau à grande échelle (Internet). Il consiste

en un échange de messages entre les routeurs qui supportent un tel type de protocole et
interagit avec les protocoles multicast du réseau local (IGMP ou MLD). Plusieurs protocoles

41
multicast ont été développés et sont classifiés selon le type de la technique utilisée. Nous
distinguons plusieurs techniques pour le multicast : la technique d’inondation (Flowding), la
technique des arbres de recouvrements (Spanning Tree), la technique des plus courts chemins
inversés (RPF : Reverse Path Forwarding), la technique de l’arbre des plus courts chemins
inversés (RPM : Reverse Path Multicasting) et les techniques associées aux arbres partagées
(CBT : Core Based Tree et PIM-SM) [Ech- 01].

2.3.2 Agents médias

Les agents médias comportent les applications audio/vidéo, les applications partagées et
les protocoles de transport temps réel et de multicast fiable.

2.3.2.1 Applications audio/vidéo

Les applications temps réels audio et vidéo sont des applications qui font usage de
différentes données multimédia. Ces applications captent ces données et les transmettent à
travers le réseau en utilisant les services de RTP/RTCP. Elles constituent ainsi une interface
entre les dispositifs de capture des médias d’une part, et le réseau d’autre part. Elles doivent
être capables de buffériser les données temps-réel suffisamment de temps au niveau du
récepteur pour enlever les déphasages de temps produit par l’acheminement du réseau et de
reconstituer les relations entre les médias de manière à reproduire le plus fiable possible, la
capture des données au niveau de l’émetteur.

Ces applications doivent être aussi capables de synchroniser les différents types de médias
(audio, vidéo, texte). En effet, les flux audio et vidéo subissent des différents déphasages et
possèdent différentes qualités de services. Les données audio et vidéo capturées au niveau de
l’émetteur au même moment peuvent atteindre le récepteur à différents instants. Au niveau du
récepteur, chaque flux a besoin d’un buffer (playout buffer) pour enlever les déphasages. La
synchronisation inter-flux peut être effectuée en adaptant les buffers de manière à ce que,
après enlèvement des déphasages, les médias capturés au même moment soient reproduits au
même instant. Ceci nécessite que la base de temps des différents flux provenant du même
émetteur puisse être reproduite au niveau du récepteur (par exemple, en leur ajoutant
l’information temps relatif à leur capture et à une horloge commune).

42
2.3.2.2 Applications partagées

L’architecture IETF de conférence multimédia sur Internet ne fournit pas d’applications

génériques pour simplifier les fonctionnalités communes à ces applications. Plusieurs
applications de données ont été conçues ces dernières années selon l’approche ALF
(Application Level Approach) [Lyon 98]. Comme exemple de ces applications, nous citons
WB (White Board) [Jaco 98] qui est une application tableau blanc partagé ou NTE (Network
Text Editor) [Hand 97]. Les applications partagées nécessitent un transport de données en
mode multicast qui ne tolère pas la perte des paquets. Elles doivent avoir accès à des services
de multicast fiable.

2.3.2.3 RTP/RTCP

Le protocole RTP (Real Time Protocol) a été développé au sein du groupe de travail AVT
(Audio Video Transport) de l’IETF [Schu 96], dans l’objectif de répondre aux besoins des
applications multimédias en terme de temps. Le protocole RTP fournit un format
d’encapsulation de paquets, pour les applications de type temps réel, qui permet de gérer le
temps, le démultiplexage ainsi que l’identification du contenu des paquets. Il est
principalement utilisé dans les applications d’audio et de visioconférence sur Internet. Le
protocole RTP est conçu pour fonctionner au dessus des protocoles UDP et TCP. Il utilise les
services offerts par la couche transport, comme le transport des données de "bout en bout", le
démultiplexage de plusieurs connexions de transport sur une même connexion réseau et la
transmission multipoint des données.

Le protocole RTP peut aussi être utilisé directement comme protocole de transport au
dessus d’IP ou IP-Multicast pour accroître les performances et réduire le sur-coût généré par
les octets des en-têtes. Cette dernière solution est intéressante pour certaines applications
temps-réel qui n’utilisent pas les services offerts par UDP, tels que le contrôle d’erreurs et le
démultiplexage. Etant donnée qu’il n’existe aucune restriction sur la fiabilité du réseau sous-
jacent, l’application dans ce cas, doit elle-même gérer les problèmes de pertes de paquets, de
réceptions de paquets hors séquence ainsi que les problèmes relatifs aux délais de
transmission. Le protocole RTP peut être utilisé conjointement avec le protocole RTCP (Real
Time Control Protocol) qui fournit un ensemble minimal de fonctionnalités pour la
conférence, comme l’identification de l’émetteur et le support des passerelles entre les
différents codages. RTP peut aussi être utilisé avec moins de fonctionnalités sans aucun
protocole de contrôle.

43
2.3.2.4 Multicast fiable

Le multicast fiable est une version du multicast qui permet de s’assurer que les paquets
ont bien atteint les membres de groupe [Paul 97,Whet 97]. Il repose sur la retransmission des
paquets perdus. La détection de ces paquets se base sur le champ numéro de séquence. A fin
d’éviter la surcharge de la source par les demandes de retransmission, les approches de
multicast fiable se basent sur la transmission des demandes à tout le groupe. N’importe quel
membre du groupe ayant une copie du paquet perdu pourra répondre en le retransmettant.
Toutefois, le nombre de réponse doit être limité. Une des techniques, qui permet de limiter ce
nombre, consiste à écouter le réseau et attendre un temps aléatoire avant de répondre. La
réponse est annulée si un autre membre du groupe a répondu [Schu 98].

2.3.3 Gestion de conférence

L’architecture IETF comporte un ensemble de protocoles pour la gestion de la conférence

sur Internet. Ces protocoles sont de deux classes : les protocoles d’initiation et de découverte
de la conférence (Conference Setup & Discovery) et les protocoles de contrôle de conférence
(Conférence Course Control).

2.3.3.1 Protocoles de description et de découverte de conférence

Les protocoles d’ "Initiation et de découverte de conférence" regroupe des mécanismes

d’annoncement et d’initiation de session de conférence. Ces mécanismes sont assurés par des
protocoles spécifiques (SIP Session Initiation Protocol et SAP Session Annoncement
Protocol). Ils peuvent être aussi réalisés à l’aide du WEB (HTTP : HyperText Transfert
Protocol) ou du protocole SMTP (Simple Mail Transfert Protocol). Les mécanismes
d’annoncement et d’initiation se basent sur la description des conférences à l’aide du
protocole SDP (Session Description Protocol).

a. Protocole SDP

SDP (Session Description Protocol) [Hand97] est un protocole permettant la description

du format et du contenu d’une session multimédia. Il fournit une spécification informelle des
informations concernant une session multimédia sur Internet, ainsi qu’une description sur les
propriétés des flots de données (multimédia) transitant dans cette session. Le protocole SDP
fournit ainsi un moyen pour faire communiquer l’existence d’une session, tout en offrant une
structuration des informations nécessaires permettant aux personnes intéressées de la joindre
et d’y participer.

44
 Le protocole SDP définit clairement les termes "conférence multimédia" et "session
multimédia". Dans ce cadre, une conférence multimédia est définie comme un ensemble de
deux ou plusieurs utilisateurs communiquant entre eux via un logiciel. Quand à une session
multimédia, elle est définie comme un ensemble d’émetteurs, de récepteurs et de flots de
données échangées entre eux.

Ces sessions sont spécifiées par l’ensemble des informations suivantes :

- le nom de la session ;

- la durée de la session ;

- les informations relatives à la largeur de bande utilisée par une session ;

- et les informations permettant de contacter les personnes responsables de la session.

<type> Signification
V Version du protocole SDP
O Identificateur du propriétaire/Créateur de la session
S Nom de la session
I* Information sur la session
U* URI (Universal Ressources Identifier)
E* Adresse e-mail des personnes responsables de la session
P* Numéro de téléphone
C* Information concernant la connexion
B* Information concernant la largeur de bande
Z* Ajustements du temps selon la zone
K* Clé de cryptage
A* Attributs de la session (une ou plusieurs lignes de ce type)

Tableau I.2.1. Description des informations d’une session.

La description d’une session en SDP est entièrement textuelle et utilise les caractères de
type UTF-8 [Yerg 96]. Cette description consiste en des lignes décrites selon la syntaxe :
<type>=<value>. Le type est représenté par un seul caractère dont la valeur spécifie sa
sémantique. La valeur " value" est structurée sous forme d’un texte dont le format dépend du
caractère attribué à "type". Le tableau I.2.1 (respectivement I.2.2 et I.2.3) donne les différents
caractères pouvant être pris par "type" ainsi que la signification correspondante et ce, pour la
description d’une session (respectivement temps et média). Les caractères marqués d’une
étoile sont optionnels.

45
 <type> Signification
T Durée de la session
R* 0 ou plusieurs instants dans lesquels la session se répète

Tableau I.2.2. Description de l’aspect temps d’une session.

Dans une description SDP d’une session, nous distinguons deux types de descriptions :
une description de niveau session et une description de niveau média. La description de
niveau session débute par une ligne de type "v" (version du protocole SDP) et se termine à la
première ligne de type "m" (média) rencontrée. La description de niveau média, quand à elle,
commence par la première ligne de type "m". La figure I.2.8 décrit un exemple d’une
description de session.

<type> Signification
M Nom du média et l’adresse port
I* Titre du média
C* Information concernant la connexion (optionnelle si elle est déjà spécifiée
dans la description de niveau session)
B* Information concernant la largeur de bande
K* Clé de cryptage
A* Attributs du média (0 ou plusieurs lignes de ce type)

Tableau I.2.3. Description des médias d’une session.

Dans cette description, chaque ligne respecte une syntaxe bien précise et relative au
caractère associé au type. Ainsi, la première ligne de la figure I.1.11 précise la version du
protocole SDP utilisée : (0). La deuxième ligne précise le propriétaire de la session :
mhandley, l’identificateur de la session ; 2890844526, la version de la session 2890841807, le
type de réseau : IN pour Internet, le type d’adressage IP4 et l’adresse IP : 126.16.64.4 qui
représente l’adresse (unique) de l’hôte ou a été créé la session. La troisième ligne décrit le
titre de la session : séminaire SDP.

46
 v=0
o= mhandley 2890844526 2890841807 IN IP4 126.16.64.4
s=SDP Seminaire
i=Seminaire sur le protocole de description
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e=mjh@isi.edu
c=IN IP4 224.2.17.12
t=2873397496 2873404696
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 31

Figure I.2.8. Description SDP d’une session.

La quatrième ligne donne plus d’informations sur la session. La cinquième ligne précise
l’URL qui servira comme adresse WWW pour plus d’informations sur la session. La sixième
ligne précise l’adresse électronique des personnes responsables de la session. La septième
ligne spécifie la connexion à utiliser pour participer à la session : IN, le type d’adressage : IP4
et l’adresse de la connexion (adresse de classe D pour le cas d’une session multicast). La
huitième ligne précise les instants de début et de fin de la session. Les deux dernières lignes
spécifient les médias utilisés par la session.

b. Protocole SAP

Le protocole SAP (Session Announcement Protocol) [Hand 97] permet de définir les
règles d’annoncement d’une session sur Internet en diffusant périodiquement un paquet SAP
(figure I.2.9) à des adresses et des ports bien définis. Ce paquet consiste en un entête SAP et
une partie utile qui représente la description de la session annoncée à l’aide du protocole SDP.
D’autres alternatives sont aussi possibles pour l’annoncement d’une session à savoir : le
WWW, le courrier électronique, etc.

Entête SAP

Description SDP

Figure I.2.9. Format du paquet SAP.

c. Protocole d’initiation de session

Le protocole SIP (Session Initiation Protocol) [Hand 98] est un protocole de niveau
application pour la signalisation de sessions. Il permet de créer, modifier et terminer des

47
sessions constituées de deux ou plusieurs participants. Ces sessions peuvent être des
conférences multimédias sur Internet, des appels téléphoniques sur Internet, des applications
d’apprentissage à distance ou autres applications similaires.

Le protocole SIP peut être aussi utilisé pour initier une session et d’y inviter des personnes
avisées préalablement de l’existence de cette session. Ce protocole supporte de manière
transparente la localisation des personnes invitées, la mobilité des personnes ainsi que la
retransmission des services. Ceci permet aux utilisateurs finaux d’émettre et/ou recevoir des
appels et d’accéder aux services de télécommunication sur différents terminaux. Il permet
aussi au réseau d’identifier un utilisateur qui a changé d’emplacement. Le concept de mobilité
est basé principalement sur l’utilisation d’un identificateur unique pour chaque utilisateur.

Dans la suite, nous allons utiliser les termes "appelant" ou "caller", respectivement
("appelé" ou "callee") pour designer la personne qui invite (respectivement la personne
invitée).

Les appelants et les appelés dans une session multimédia sont identifiés dans le protocole
SIP par des adresses SIP. Ce protocole offre aux utilisateurs, un service d’enregistrement
d’adresses de leurs emplacements auprès des "serveurs SIP". Quand un appelant décide
d’effectuer un appel, il commence par localiser le serveur approprié et envoie une requête SIP
qui, dans ce cas, est une requête d’invitation. Une requête SIP peut atteindre directement
l’appelé comme elle peut être retransmise sous forme de nouvelles requêtes SIP à travers des
"proxys". Ces différents aspects et services du protocole SIP sont détaillés dans ce qui suit.

- Adressage SIP

Les objets adressés par SIP sont des utilisateurs et des hôtes, identifiés par des URLs SIP.
Les URLs SIP prennent une forme similaire aux URLs relatifs au service telnet, i.e.
utilisateur@hote. La partie utilisateur comporte le nom de l’utilisateur ou son numéro de
téléphone. La partie hôte peut être aussi bien un nom de domaine ou une adresse de réseau
numérique. Une adresse SIP peut désigner soit un seul individu, soit la première personne
disponible d’un groupe d’individus, soit tout un groupe d’individus.

- Localisation d’un serveur SIP

Quand un client décide d’envoyer une requête à un serveur SIP, il peut soit l’envoyer vers
un "serveur proxy" (proxy server), configuré localement et indépendamment de l’URI
(Universal Ressources Identifier), spécifiée dans la requête ; soit directement à l’adresse IP et
au port correspondant à l’URI de la requête. Dans le deuxième cas, le client doit déterminer le

48
protocole, le port et l’adresse IP du serveur. Pour obtenir ces informations, le client doit suivre
les étapes suivantes. En se référant au protocole spécifié par l’URI (TCP ou UDP), il doit
essayer de contacter le serveur au numéro de port qui figure dans l’URI de la requête. Si
aucun protocole n’est spécifié, le client doit essayer le protocole UDP et, au cas ou il n’arrive
pas à atteindre le serveur, il doit reformuler la requête en utilisant le protocole TCP.

- Invitation SIP

L’invitation est le principal service du protocole SIP. Une invitation SIP consiste en deux
requêtes principales : la requête INVITE suivie d’une requête ACK. La requête INVITE
formule une demande destinée à l’appelé pour joindre une conférence particulière ou entrer en
conversation avec l’appelant. Suite à l’acceptation de l’appelé, l’appelant confirme sa
participation par l’envoi de la requête ACK. Si l’appelant ne désire pas que l’appelé participe
à la conférence ou la conversation, il envoie la requête BYE au lieu de la requête ACK.

La requête INVITE contient une description de la session, décrite par exemple par le
protocole SDP. Cette description fournit à la partie appelée suffisamment d’informations pour
joindre la session. Pour une session multicast, la description de la session énumère les types et
formats des médias qui peuvent être distribués dans cette session. Pour une session point à
point, la description de la session énumère les types et formats des médias que l’appelant va
utiliser. Dans les deux cas, si l’appelé décide d’accepter l’appel, il répond en émettant à
l’appelant une liste similaire comprenant les médias qu’il va utiliser. Dans le cas d’une
session multicast, l’appelé renvoie la description de l’appelant.

Une invitation SIP peut s’effectuer de deux manières : soit via un "proxy server" (figure
I.2.10), soit via un "redirect server" (figure I.2.11). Dans la figure I.2.10, le "proxy server"
accepte la requête INVITE (étape 1) de la part d’un appelant, il contacte par suite le service de
localisation (étape 2) et obtient plus de précisions sur la localisation de la personne appelée
(étape 3). Le "proxy server" envoie ensuite la requête INVITE à l’adresse ou à l’ensemble des
adresses qui ont été fournis par le service de localisation (étape 4).

49
 cs.tu.berlin.de
cs.tu.berlin.de
cs.tu.berlin.de

hgs@play
cs.tu.berlin.de
henning (3)
(2)
cz@cs.tu.berlin.de
INVITE INVITE hgs@play
henning@cs.colombia.edu (4)
(1)

200 OK (7) 200 OK (6)

Figure I.2.10. Invitation SIP via un "proxy server".

Au niveau du serveur, l’agent utilisateur alerte la personne appelée et envoie une

indication de succès au "proxy server" (étape 6), qui la redirige à son tour vers l’appelant
(étape 7). L’appelant confirme la réception de ce message par l’envoi de la requête ACK au
"proxy server" qui est transmise ensuite à l’appelée (étape 8 et 9). Cette même requête peut
aussi bien être envoyé directement à l’appelant sans passer par le "proxy server".

cs.tu.berlin.de
Location Server
cs.tu.berlin.de
cs.tu.berlin.de

play.cs.columbia.edu
cs.tu.berlin.de
henning (3)
(2)
cz@cs.tu.berlin.de
INVITE
henning@cs.colombia.edu
(1)

300 Moved
lion play.cs.columbia.edu (4)

ACK
henning@cs.columbia.edu
(5)

INVITE play@cs.columbia.edu
(6)
play
200 OK (7)

ACK play@cs.columbia.edu
(8)

Figure I.2.11. Invitation SIP via un "redirect server".

50
 Dans la figure I.2.11, le serveur "redirect server" accepte la requête INVITE (étape 1),
contacte le service de localisation (étapes 2 et 3) comme dans le premier cas. Toutefois, au
lieu que le "redirect server" retransmet cette requête vers l’appelé dont l’adresse a été fournie
par le service de localisation, il l’envoie à l’appelant (étape 4). Celui-ci avise le "redirect
server" par une requête ACK (étape 5) et envoie une nouvelle requête INVITE à l’appelé
(étape 6). Dans cet exemple, l’appel est réussi (étape 7 et 8). Les messages "200 OK" et "300
moved" font partie des réponses aux requêtes SIP. Ces réponses sont bien définies dans la
norme relative à ce protocole.

- Localisation d’un utilisateur

Une personne peut se déplacer entre différents hôtes. Le protocole SIP offre aux
utilisateurs un service d’enregistrement de leurs différents emplacements. Ainsi, suite à une
invitation, un serveur de localisation peut retourner plusieurs adresses d’un utilisateur étant
donné que ce dernier peut être connecté à plusieurs hôtes.

Les actions entreprises suite à la réception d’une liste d’adresses diffèrent selon le type du
serveur. Un "redirect server" retourne cette même liste au client. Quand au "proxy server", il
essaye séquentiellement ou parallèlement les adresses figurant dans la liste jusqu'à ce que
l’appel réussisse ou que l’appelé décline cet appel.

- Service d’enregistrement

Le protocole SIP offre le service d’enregistrement via la requête REGISTER qui permet à
une personne d’enregistrer les adresses auxquelles il peut être contacté. Cet enregistrement
peut se faire soit au niveau d’un "redirect server" ou d’un"proxy server"

2.3.3.2 Contrôle de conférence

En plus des protocoles de description, d’initiation et d’invitation, l’architecture IETF pour

la conférence multimédia comporte des blocs concernant le contrôle au cours de la conférence
(Conference Course Control). Ces blocs couvrent les aspects de réservation de ressource et du
contrôle distribué.

- Protocole de réservation de ressource

Le protocole de réservation de ressource (RSVP : Resources Reservation Protocol)

permet aux applications multimédias d’effectuer la réservation des ressources pour qu’elles
soient en mesure d’offrir des services avec des garanties strictes de performances [Zhang 93].
Le protocole RSVP est utilisé en conjonction avec le protocole IP. Il a besoin de connaître en

51
permanence les ressources disponibles du réseau, afin de prendre les décisions de routage
appropriées. Le protocole RSVP est un protocole "orienté-récepteur" dans le sens où, la
réservation des ressources est prise en charge par les récepteurs. Ceci lui permet de s’adapter
à un nombre variable et important de récepteurs. Ainsi lorsqu’un récepteur veut recevoir un
ou plusieurs flots, il doit s’abonner à un groupe multipoint correspondant. Les messages de
réservation de ressources sont envoyés en parallèle avec le flot de données de l’utilisateur.
Ces messages contiennent une description du profil des datagrammes pour lesquels la
réservation est faite. D’autre part, le protocole RSVP n’associe pas la réservation au routage.
En effet, le chemin emprunté par les paquets est découvert automatiquement et les paquets de
réservation sont émis sur cette voie.

Le protocole RSVP utilise des états transitoires pour mettre à jour la liste des réservations
en cours. En d’autres termes, cela signifie que les sources doivent périodiquement
retransmettre les messages de désignation de chemin aux différents routeurs. Ceci a pour
objectif, d’une part de rappeler à ces derniers l’existence des flots, et d’autre part pour se faire
connaître auprès des nouveaux récepteurs. De plus, ces retransmissions renforcent la
robustesse du protocole contre les pannes temporaires des routeurs, de la source ou des
récepteurs.

- Protocole de Contrôle de conférence

Une conférence multimédia peut adopter différentes formes et peut avoir différentes
tailles. Toutefois, elle est généralement de deux catégories : la première catégorie concerne les
conférences fortement couplées et la deuxième catégorie est relative à la conférence
faiblement couplée.

Les conférences faiblement couplées sont des conférences ou le flux est unilatéral. En
effet, ce type de conférence est généralement constitué d’un conférencier et de participants
qui reçoivent les données multimédia provenant du conférencier. Une session d’une
conférence faiblement couplée consiste en un échange de paquets multimédias au dessus de
RTP/RTCP et IP multicast. Ce type de conférence ne nécessite ni contrôle de membres ni
mécanismes de contrôle de la conférence au cours de son déroulement.

Les conférences fortement couplées sont des conférences où l’interaction entre les
participants est forte. Cette interaction peut adopter différentes politiques formelles respectant
des protocoles sociaux sous-jacents et des scénarios particuliers. Elles doivent intégrer des
techniques de contrôle explicite qui permettent de gérer et les membres de la conférence et les

52
ressources partagées de la conférence. Ces techniques consistent en des politiques constituant
des règles de contrôle et des mécanismes qui implémentent ces politiques et par suite le bloc
contrôle distribué de l’architecture de téléconférence sur Internet. Toutefois, peu d’intérêt a
été porté à ce bloc dans les systèmes existants.

2.4 Conclusion

Nous avons présenté dans ce chapitre les travaux de l’ITU et l’IETF concernant les
systèmes de téléconférence. Ces travaux fournissent des standards concernant les équipements
et les protocoles supportant le transport des données multimédias et les outils de travail
coopératif synchrone. Ils définissent aussi les besoins en terme de gestions et contrôle de
conférence.

53
 Chapitre 3

Systèmes de téléconférence et gestion

de "floor"

3.1 Introduction

Nous avons présenté dans le chapitre précédent les travaux de l’ITU et l’IETF concernant
les supports technologiques du travail coopératif synchrone. Les recommandations de ces
travaux ont servi de base pour le développement et l’implémentation de plusieurs systèmes de
téléconférence. Ces systèmes s’intéressent plus à l’aspect transport de données multimédia.
Cependant, peu d’intérêt est porté à l’aspect gestion et contrôle de conférence et à leur
implémentation.

Dans ce chapitre, nous présentons des systèmes de téléconférence existant. Nous

présentons ensuite un tableau comparatif entre ces systèmes en se basant sur un ensemble de
paramètres. Nous évoquons ensuite les concepts relatifs à la gestion de conférence et au
contrôle du floor comme étant des paramètres très importants dans les systèmes de
téléconférence. Enfin, nous présentons la recommandation SCCP (Simple Conférence Control
Protocol) de l’IETF, qui décrit les services de gestion de conférence et contrôle de floor que
doit supporter un système de téléconférence.

54
3.2 Produits de téléconférence

Nous présentons dans cette section des produits de conférence multimédia. Nous
distinguons deux catégories de tels produits. Cette catégorisation est basée sur le fait que le
produit respecte les standards ITU ou IETF.

3.2.1 Produits ITU

3.2.1.1 Intel Video Phone

Intel Video phone est une application créée par intel. Elle est implémentée seulement pour
la plate-forme windows. Elle est basée sur le standard H.323. La compression audio et vidéo
se font par des algorithmes réalisés par Intel et ne respecte par les standards ITU. Les données
audio et vidéo sont distribuées selon le mode unicast. En effet, cette application offre
seulement des connexions point à point utilisant une approche similaire a celle du téléphone
standard. Pour appeler une personne, il suffit de donner son adresse IP. Un appel peut être
accepté ou ignoré. Une connexion peut être interrompue à n’importe quel moment. Intel
Video Phone dispose d’une interface simple. Toutefois, il ne permet pas d’établir des
conférences de groupe ce qui limite son usage.

3.2.1.2 IBM BambaPhone

Bambaphone est un produit faisant partie de la suite de démonstrations technologiques des

recherches de IBM Bamba. Il est un peu similaire à l’application Intel. Il est implémenté
exclusivement pour Windows 95/NT. Il fournit seulement une connexion unicast point à
point. BambaPhone comporte des composants modulaires pour l’initiation d’appel, le contrôle
multimédia et le support de l’audio et la vidéo. L’application est en elle même écrite avec une
API de haut niveau de ces composants. Elle est partiellement conforme au standard H.323. Ce
qui lui pose des problèmes d’interopérabilité avec les autres applications de vidéophone. Les
algorithmes de compression audio et vidéo utilisés ne respecte aucun standard. Un appel peut
être effectué en utilisant l’adresse IP à travers une interface homme/machine peu commode.
Bambaphone tout comme Intel Vidéo Phone ne permet par de supporter la communication de
groupe

3.2.1.3 NetMeeting

NetMeeting est un logiciel de téléconférence développé par Microsoft qui supporte le

standard H.323 et comporte un codec vidéo H.263. NetMeeting permet aux participants de

55
partager des applications, d’échanger des informations entre les applications partagées à
travers un "clipboard", transférer des fichiers, collaborer sur un tableau blanc partagé et
communiquer avec un outil de chat textuel. Il supporte aussi le standard T.120 qui lui permet
d’interopérer avec les produits basés sur T.120. NetMeeting offre des services de gestion du
répertoire du groupe (directory services) via des serveurs ILS (Internet Locator Server). Ces
serveurs utilisent le protocole LDAP (Lightweight Directory Access Protocol) pour offrir de
tels services. Les utilisateurs peuvent visualiser le répertoire ILS avec NetMeeting ou à
travers une page WEB pour lister les membres qui exécutent NetMeeting. Ils peuvent ensuite
choisir de se connecter avec un membre (ou plusieurs) de la liste visualisée, en tapant les
informations relatives à leurs emplacements ou de sélectionner un autre participant. Un
utilisateur particulier peut accéder à un serveur ILS, se connecter, créer un répertoire des
utilisateurs disponibles.

3.2.1.4 CU-SeeMe

CU-SeeMe [Dorc 95] a été conçu spécialement pour des plates-formes peu puissantes de
type Macintosh et PC. Il représente l’un des produits les plus commercialisés. C’est un
système multi-utilisateurs, qui offre des services facilitant l’établissement d’une conférence.
Cu-SeeMe est basé principalement sur le standard H.323 et supporte la compression vidéo
H.263. Il offre une application tableau blanc supportant le standard T.120 et un chat textuel. Il
fournit aussi des fonctionnalités permettant le contrôle de la transmission et de la largeur de
bande.

L’architecture multi-utilisateurs CU-SeeMe n’utilise pas la transmission multipoint. Elle

est basée sur un point de contrôle central appelé réflecteur. Ce réflecteur est un programme
qui a pour rôle principal, de dupliquer et de redistribuer les flots de paquets qu’il reçoit d’un
participant à l’ensemble des autres participants d’une conférence. Il permet aussi de gérer la
conférence et contrôle les accès. Toutefois, quoique le réflecteur soit simple à réaliser, il
augmente les délais de transmission.

3.2.2 Produits Internet

3.2.2.1 VIC/VAT

Les outils VIC (Videoconferencing Tool) et VAT (Visual Audio Tool) ont été développés
au laboratoire LBL (Lawrence Berkeley Laboratories) [Mbon 02]. Ce sont deux applications
qui peuvent s’exécuter indépendamment l’une de l’autre. Toutefois, elles peuvent s’exécuter

56
en même temps. Pour cela, un troisième outil a été développé pour la coordination entre ces
deux applications. Cet outil porte la dénomination SD (Session Directory). Il fournit les
informations sur les conférences supportées par VIC et VAT.

VIC et VAT sont implémentés au dessus de l’architecture MBONE (Multicast Backbone)

et bénéficie ainsi de la diffusion restreinte. La structure de ces outils est tout à fait ouverte
dans le sens ou, elle n’impose aucune restriction pour la participation à la conférence.
L’algorithme de compression adoptée par VIC est conforme à la norme H.261. Cependant,
plusieurs standards d’algorithme de compression peuvent être supportés par cet outil (MPEG,
JPEG). Les outils VIC et VAT utilisent les services de transport de RTP.

3.2.2.2 IVS/RODEO

IVS (INRIA Visioconference System) [Turl 95, IVS 03] est un système de visioconférence
qui a été développé dans le cadre du projet européen MICE. Il est actuellement utilisé par un
très grand nombre de sites universitaires de recherche et par des industriels [Sass 94]. IVS est
le premier système de visioconférence dans lequel la compression est réalisée au niveau
logiciel. Ceci a permis de réduire considérablement le coût de cette opération par rapport à
celle réalisée par des codecs physiques. IVS adopte le standard H.261 pour la compression
vidéo. Cet outil dispose aussi de techniques lui permettant de décomposer le flot H.261
produit par le codec, en des paquets afin de pouvoir les transmettre via le protocole UDP. Ce
découpage se base sur le principe de la mise en trame par l’application (ALF : Application
Level Framing). Ce principe a pour objectif de minimiser les accès mémoires et le nombre de
paquets sur le réseau. Pour avoir un format d’encapsulation commun avec les applications
multimédia développées sur Internet, IVS s’est basé sur le protocole standard RTP. Cet outil
adopte aussi des techniques de contrôle de débit au niveau des codecs permettant un
ajustement de ce dernier en fonction des capacités du réseau. Il intègre aussi un algorithme de
contrôle de congestion. Rendez-vous, le successeur d’IVS, intègre des mécanismes de
synchronisation basée sur RTP et un ordonnancement spécifique des traitements sur les flux
audio et vidéo de l’application.

3.2.2.3 CONFCNTLR

ConfCntlr [Perr 97] est un outil Mbone qui s’exécute avec d’autres outils de
visioconférence tel que VIC et VAT pour améliorer l’utilisation de la vidéo et de l’audio. Les
outils Mbone VIC et VAT disposent d’interfaces séparées et ne peuvent pas être contrôlés à
distance. Ces outils ne permettent pas à un utilisateur sur un site de lancer la conférence sur

57
un autre site ou changer des paramètres sur un site distant une fois l’outil lancé. ConfCtrl est
conçu pour remédier à ce type de problèmes en permettant un contrôle local et distant des
outils audio et vidéo et fournit une seule interface pour les deux outils VIC et VAT. A l’aide
de ConfCtrl, les utilisateurs sur un site donné peuvent lancer des sessions audio et vidéo sur
d’autres sites et peuvent spécifier les valeurs des paramètres. Ils peuvent aussi changer les
paramètres audio et vidéo sans relancer ses outils.

3.2.2.4 CONFMAN

Confman [From 98, Conf 04] permet une initiation et une manipulation aisées des
conférences multimédias sur Internet. Le noyau du système Confman est composé de sous-
systèmes supportant chacun différents services. Le contrôle de conférence est un de ces
services. Ce service permet l’initiation de la conférence et la gestion d’un répertoire
d’adresses qui contient les adresses des membres de la conférence. D’autres services sont
fournis par ces outils parmi lesquels, il y a : l’annoncement en se basant sur les concepts de
"session directory" et des services téléphoniques tel que l’attente d’appel et le transfert
d’appel. La communication dans cet outil est supportée par le protocole CCCP (Confman
Conference Control Protocol). Ce protocole manipule des données échangées entre les sites
concernant les jointures, les départs de participant et la terminaison de la conférence. L’outil
Confman présente une interface à l’utilisateur pour interagir avec son noyau.

Les produits de téléconférence que nous avons présentés s’intéressent généralement à

l'aspect transport de données multimédias et à l’aspect compression. Le tableau I.3.1 décrit
une comparaison entre les produits de téléconférence présentés en fonction des
caractéristiques décrite dans la première colonne. Par exemple, le produit Intel Video Phone
n’adopte pas de format standardisé pour la vidéo. Il est destiné à des environnements
Microsoft. Il utilise le mode de transmission point à point (unicast). Il se base sur le protocole
RTP pour la synchronisation des données multimédias. Il ne supporte pas ni travail de groupe
ni la gestion et contrôle de conférence ni les outils de partage de données.

A partir de cette étude comparative, nous constatons que peu d’intérêt est porté à la
gestion de conférence et au contrôle de floor. Nous présentons dans la section suivante les
principaux aspects relatifs à ces deux aspects au sein d’une conférence multimédia.

58
 Produits Intel Video IBM Bamba Cu-Seeme VIC VAT IVS/Rodeo CONFCNTLR CONFMAN
Phone Phone

Caractéristiques

Format vidéo Non H.263 H.261 H.261 Vidéo non H.261 Vidéo non traitée Vidéo non
standardisé supportée supportée

Environnement Windows Windows Windows UNIX UNIX UNIX UNIX UNIX

NT/2000 NT/2000 NT/2000

Mode de Unicast Unicast Multicast Multicast Multicast Multicast Multicast Multicast

transmission

Synchronisation Basée sur Basée sur Basée sur Non Non Basée sur Non supportée Non
des médias les les les supportée supportée les supportée
estampilles estampilles estampilles estampilles
de RTP de RTP de RTP de RTP

Travail de groupe Non Non Supporté Supporté Supporté Supporté Supporté Supporté
supporté supporté

Gestion de Non Non Supporté Non Non Non Non supportée Supportée
conférence supportée supportée supportée supportée supportée

Contrôle de floor Non Non Non Non Non Non Non supporté Non supporté
supporté supporté supporté supporté supporté supporté

Application Non Non Supportée Non Non Non Non supportée Non
partagée supportée supportée supportée supportée supportée supportée

Tableau I.3.1. Comparaison entre les produits de téléconférence.

3.3 Concepts de gestion et de contrôle de conférence

Rappelons que l’objectif des systèmes de téléconférence multimédia (MMTS pour

MultiMedia Teleconferencing System) est de permettre à un groupe de personnes,
géographiquement distribuées, de travailler ensemble moyennant des ressources partagées.
Les systèmes de téléenseignement constituent un bon exemple des MMTSs. Dans de tels
systèmes, l’enseignant initie une session de classe virtuelle. Cette session peut être jointe
ensuite par différents étudiants. Ces étudiants peuvent quitter la session ou être expulsés par
l’enseignant. Une fois le cours terminé, l’enseignant met fin à la session.

59
 Durant le cours, c’est le professeur qui émet ses médias et est vu et entendu par tous les
étudiants. Il manipule un ensemble de ressources dans le but d’assurer son cours (télépointeur,
slides, tableau blanc, etc.). En vue de comprendre certains points du cours, un étudiant peut
demander la parole. L’enseignant lui donne le droit de la parole. Ceci permet à cet étudiant
d’être vu et entendu par les autres membres de la classe et d’avoir accès à certaines
ressources.

A travers cet exemple de MMTS, nous distinguons principalement deux principaux

aspects dans la gestion et le contrôle de la conférence multimédia. Le premier aspect concerne
la gestion du groupe constituant la conférence. Cet aspect porte généralement la dénomination
gestion de conférence [Domm 99]. Le deuxième aspect concerne le contrôle des ressources
partagées de la conférence. Cet aspect est géré généralement à l’aide du concept de floor en
respectant des politiques implémentées par des mécanismes appropriés [Domm 97]. Dans la
suite, nous traitons la gestion de la conférence, le contrôle de floor puis nous donnons un bref
aperçu sur les politiques et les mécanismes de contrôle de floor.

3.3.1 Gestion de conférence

La gestion de conférence concerne des fonctionnalités telles que la création, la

modification et la terminaison de la conférence. Les propriétés de la conférence sont aussi
prises en charge par la gestion de la conférence. Ces propriétés concernent généralement le
modèle de la conférence, les listes de participants et de leurs droits et la politique de la
conférence. Elles sont établies lors de la création de la conférence [Rodr 02].

Il existe plusieurs modèles de conférence multimédia. Comme exemple de ces modèles

nous citons le modèle dial-in et le modèle dial-out. Dans le premier modèle, les utilisateurs
joignent la conférence eux même. Dans le deuxième modèle, l’initiateur de la conférence
fournit une liste de participants à un serveur qui effectue des appels pour les inviter [Kuts 02].

Toutefois, ces deux modèles sont centralisés dans le sens où toutes les informations du
groupe sont localisées au niveau d’un seul serveur et toutes les opérations de gestion de la
conférence se passent via ce serveur. D’autres modèles sont distribués et ne comportent pas de
serveur détenant toute l’information de la conférence. Cette information est distribuée sur tous
les sites des participants.

La liste des droits des utilisateurs fournit des informations sur les privilèges des
participants de la conférence. Ces listes peuvent aussi comporter des informations concernant

60
les personnes ayant le privilège d’acceptation ou de refus de nouveaux participants ainsi que
le privilège d’intercepter et de répondre aux requêtes concernant les ressources partagées. Ces
deux privilèges font généralement partie des fonctions d’un modérateur de conférence [Hilt
01].

Toutefois, les MMTS peuvent adopter une certaine souplesse de façon à ce que ces
privilèges soient distribués sur un ensemble de participants. La gestion de conférence peut
aussi comporter des informations concernant les participants autorisés à joindre la conférence,
les participants qui peuvent se connecter en mode écoute seulement et les participants non
autorisés. La gestion de la conférence doit supporter aussi l’initialisation des fonctions
concernant le control de la conférence [Rodr 01].

3.3.2 Contrôle de floor

Le floor est défini comme étant une permission temporaire accordée dynamiquement aux
utilisateurs d’un groupe d’un MMTS dans le but d’assurer un usage mutuellement exclusif des
ressources partagées au sein de la conférence. C’est une entité logique qui représente une
ressource partagée dans une conférence multimédia. Cette ressource peut être le droit de
parole, l’accès a une bande étroite de vidéo, un pointeur, un focus dans une application
partagée.

[ Domm 97] définit le contrôle de floor comme étant une technologie qui apporte des
solutions aux conflits dans des espaces de travail partagés ainsi qu’à la coordination des
activités de cette espace. Il permet aux utilisateurs d’utiliser les ressources partagées d’une
conférence sans conflit. Toutefois, il ne faut pas confondre le contrôle de floor avec le
contrôle de la concurrence qui est généralement relative au contrôle d’accès a des bases de
données de type read-write et write-write. Ces interactions sont généralement résolues à l’aide
des transactions garantissant les propriétés d’atomicité, de consistance, d’isolation et de
durabilité.

Un MMTS qui assure la gestion de la conférence sans prendre en charge le contrôle de

floor est analogue à une infrastructure de transport sans contrôle de trafic. Le contrôle de floor
est ainsi un aspect très important dans un MMTS. En effet, dans des réunions coopératives
face à face (réelle), les participants partagent le même espace spacio-temporel. Ils ont par
conséquent différents moyens pour contrôler les interventions sur les ressources partagées
ainsi que leurs activités. Ces moyens naturels consistent en des répliques et indications non-

61
verbales (regards fixes, élévation de ton, etc.) qui permettent aux participants de mener la
conversation ainsi que d’autres activités à tour de rôle (turn-taking) [Sein 97, Tros 00].

Dans une session virtuelle d’un MMTS, la communication explicite basée sur les
conventions culturelles, sociales et pragmatiques ne peuvent pas être perçues de la même
manière que dans une réunion réelle. Ceci est dû à l’absence de la conscience mutuelle
(awarness) des activités de groupes, des évènements et de l’espace de travail distant. De plus,
le manque de la présence personnelle peut imposer certaines limitations au niveau de la
qualité de la conférence.

La télé-présence peut être améliorée par des techniques de middleware qui facilite le
travail coopératif. Ces techniques consistent en des politiques qui réglementent l’échange du
floor et des mécanismes qui implémente ces politiques. La métaphore du floor ainsi que les
problèmes concernant le contrôle du "floor" n’ont pas été adressés d’une manière assez
compréhensive [Wu 02].

3.3.2.1 Politiques

Les approches de contrôle de floor reposent sur les politiques utilisées pour assurer ce
contrôle. [Domm 99] définit une politique comme étant l’ensemble des règles et méthodes qui
permettent de déterminer la séquence de décision d’affectation du floor aux participants d’une
conférence. La conception d’une politique d’un MMTS doit prendre en compte deux facteurs
essentiels. Le premier facteur concerne la capacité de MMTS à utiliser les informations de la
conférence disponible en vue de prendre les décisions adéquates. Le deuxième facteur
concerne les types des informations disponibles au MMTS pour la prise de ces décisions. La
prise de décisions dans les politiques de contrôle de floor consiste en la manière avec laquelle
le floor est échangé ainsi que la sélection du prochain détenteur de floor. Peu de travaux
concernant les politiques de sélection ont été proposés et implémentés.

Parmi les politiques de sélection les plus évidentes, nous distinguons la politique premier
arrivé – premier servi. Cette politique requiert des mécanismes permettant de comparer et de
mémoriser les requêtes selon leur ordre d’arrivée, assurant ainsi la propriété d’équité.
Toutefois, une politique doit prendre en compte aussi le paramètre temps en vue d’éviter la
famine. [Domm 04] identifie les politiques suivantes : la politique à base d’agenda, la
politique à base de temporisateur, la politique à base d’ordre prédéfini, la politique à base
d’élection, la politique Ad hoc et la politique à base de tirage au sort.

62
 Dans la politique à base d’agenda, le floor est affecté selon un plan donné ou un ordre de
tâches défini avant le lancement d’une session de la conférence. Dans la politique orientée
temps les requêtes de floor et son usage se font selon des temporisateurs définis par des
conditions ou des évènements du système. Chaque détenteur du floor dispose de ses propres
contraintes temporelles. Dans la politique ordre prédéfini, le floor est accordé et demandé
selon une séquence basée sur un chemin dans une topologie de sites collaboratifs. La politique
premier arrivée premier servi fait partie de ce type de politique [Schu 04].

La politique d’élection consiste à allouer le floor en se basant sur la technique de vote du

prochain détenteur. La politique Ad hoc mémorise toutes les requêtes pour chaque ressource
dans une file et les traite selon la priorité, le temps et les critères de QOS. La politique du
tirage au sort consiste à utiliser des tickets pour chaque utilisateur selon un schéma aléatoire
pour l’affectation du floor.

[Fluc 95] propose une classification plus simple des approches de politiques de contrôle
de floor. Celle ci consiste en quatre catégories principales :

- Politique sans contrôle : Chaque membre du groupe peut accéder aux ressources
communes sans contrôle. La découverte et la résolution de conflits dépendent du bon sens,
la bonne foi et du comportement social des membres du groupe. Cette approche est
convenable pour les petits groupes.

- Politique de "contrôle de floor" présidée : Dans cette politique, un membre du groupe

remplit la fonction de modérateur de la conférence et se voit attribuer les privilèges de
contrôle du floor.

- Politique de "contrôle de floor" explicite : le "floor" est donné ou libéré sur la

demande d’un membre. Tant que le "floor" est pris, les requêtes des autres membres sont
mises dans une file d’attente. Généralement, ces requêtes sont traitées selon le principe
"premier arrivé - premier servi".

- Politique de "contrôle de floor" implicite : le système donne le "floor" à un membre du

groupe une fois qu’il commence à utiliser une certaine ressource. La ressource est ainsi
verrouillée pour les autres membres. Une fois que le participant arrête l’utilisation de la
ressource, le "floor" est libéré.

Cette classification résume l’ensemble des différentes situations de contrôle et de

coordination entre les interactions des participants au sein d’une conférence.

63
3.3.2.2 Mécanismes de réalisation

Les politiques définissent les règles d’échange de floor entre les participants d’un MMTS.
Ces politiques sont implémentées par des mécanismes qui consistent en des techniques
algorithmiques permettant de réguler le contrôle de bas niveau et de synchroniser les
évènements entre les sites. Ces mécanismes sont basés sur les techniques d’exclusion
mutuelle et d’accès multiple. [Shen 94] identifie les mécanismes suivants : La négociation, le
passage du jeton, l’étiquetage temporel, le verrouillage, le blocage, la réservation et la
détection de dépendance.

Le mécanisme de négociation comme son nom l’indique, consiste en un échange

d’informations entre les sites en vue de résoudre le conflit concernant une ressource
indépendamment de son contexte. Le mécanisme de passage de jeton considère le floor
comme un jeton envoyé d’un participant à un autre dans un ordre défini préalablement. Le
mécanisme de demande de jeton impose aux utilisateurs de demander le floor du détenteur ou
du modérateur.

Le mécanisme d’étiquetage temporel consiste à affecter à chaque demande de floor une

information temporelle selon une horloge globale logique et ce, dans le but d’ordonner les
requêtes. Le mécanisme de verrouillage en deux temps considère le floor comme un verrou et
consiste à verrouiller la ressource pour une activité donnée et à la déverrouiller une fois cette
activité est terminée.

Le mécanisme de blocage se base sur le concept de sémaphores distribués permettant de

gérer la ressource comme une section critique. Le mécanisme de réservation consiste à
allouer une ressource au participant selon l’ordre des réservations et l’intervalle de temps
demandé. Le mécanisme de détection de dépendance consiste à ordonner les requêtes de floor
selon une sémantique causale des données sous-jacents aux requêtes.

Nous donnons dans le tableau I.3.2 la correspondance entre les différentes classes de
politique et les mécanismes. Ce tableau donne pour chaque politique les mécanismes qui
peuvent l’implémenter.

64
 Mécanismes Négocia- Passage Demande Etiquetage Verroui blocage Reserva- Détection
tion jeton Jeton temporel -llage tion Dépendance
Politiques
Sans contrôle *

Explicite * * * *

Implicite * *

Présidée *

Tableau I.3.2. Correspondance politiques/mécanismes.

Nous présentons dans ce qui suit les travaux effectués par l’IETF dans le domaine de la
gestion et contrôle de conférence. Ces travaux sont décrits dans la spécification SCCP (Simple
Conference Control Protocol).

3.4 Recommandation SCCP

Le document SCCP [Born 01] définit les services requis par un protocole de gestion et de
contrôle de conférence. Il fait partie du bloc de "gestion de la conférence" de l’architecture
IETF concernant la conférence multimédia sur Internet présentée au chapitre 2. Cette
architecture comprend des éléments de contrôle uniquement pour des conférences faiblement
couplées. Ce type de conférence est généralement constitué d’un conférencier qui diffuse sa
présentation et un ensemble de participants qui la reçoivent. Ainsi, un participant n’interagit
ni avec le conférencier ni avec un autre participant.

Or une conférence peut adopter une politique respectant un "protocole social" sous-jacent
ayant un scénario spécifique où l’interaction entre les différents participants est forte. Les
conférences de ce type sont désignées par le terme "conférences fortement couplées". Le
protocole SCCP définit les besoins ainsi que les services requis par ce type de conférence. La
définition de ces services repose sur les recommandations de l’ITU-T de la série H.323 qui les
regroupe en trois catégories :

- les services relatifs à la gestion des membres participant à la conférence ;

- les services relatifs au "contrôle de floor" ;

65
 - les services de gestion de sessions média/applications qui constituent la conférence.
Ce type de services permet la négociation et le changement des paramètres de manière
coordonnée entre tous les participants.

3.4.1 Initiation de la conférence

Rappelons que l’architecture IETF de la conférence multimédia fournit une catégorisation

de la gestion de la conférence. Cette gestion comprend deux principaux aspects : l’initiation
de la conférence (Conference Setup) et le contrôle et la gestion au cours de la conférence. Les
mécanismes d’initiation de conférence tel que SIP (Session Initiation Protocol), fournissent
les moyens pour dispatcher un état initial aux systèmes finaux impliqués dans la conférence.
Le contrôle et la gestion d’une conférence, tel que c’est recommandé par SCCP ont pour
objectif de gérer l’état de la conférence tout au long de son déroulement. Dans le cas où une
conférence est initiée par SIP, l’état géré par SCCP doit incorporer l’état initial. Cet état inclut
la configuration des sessions médias qui peuvent résulter des processus de négociation.

3.4.2 Terminologie de SCCP

Selon le document SCCP, une conférence est constituée d’un ensemble de participants.
Un "participant" est défini comme étant une personne prenant partie à la conférence. Un
participant SCCP utilise un système désigné par "Membre". Ce système englobe l’ensemble
du matériel et logiciel lui permettant de participer à la conférence. Un membre SCCP est
spécifique à un seul participant. Le site ou l’ensemble des sites interconnectés localement,
qu’utilise un participant représente le "système final" et joue le rôle d’interface entre le
participant et la conférence. Le système final SCCP exécute tous les logiciels requis par la
téléconférence et, l’ensemble constitue le membre SCCP.

Le contrôle et la gestion de la conférence sont assurés par l’ "entité SCCP". Une telle
entité est une instanciation d’une implémentation SCCP s’exécutant sur un système final
SCCP et concerne un seul membre. Une entité SCCP représente un participant spécifique
utilisant le protocole SCCP dans la conférence. Un participant SCCP interagit avec l’entité
SCCP via un composant nommé "Contrôleur de conférence". Ce composant lui permet de
choisir une politique bien déterminée. Il interagit d’une part avec l’entité SCCP en vue
d’implémenter la politique souhaitée et d’autre part avec le participant pour réaliser ses
requêtes. Chaque participant SCCP est identifié par son "UCI" (Universal Communication
Identifier). Cet identificateur est utilisé pour inviter un participant via SIP.

66
 SCCP définit la notion de "présence" comme étant l’information qui représente le fait
qu’une personne est en train d’utiliser un système final dans l’objectif de représenter cette
personne dans une ou plusieurs conférence. La présence correspond ainsi au fait que la
personne est connectée au système final et qu’elle est disponible pour la conférence.

Les informations d’une conférence ainsi que celles relatives à ses participants sont
disponibles dans chaque membre SCCP et sont désignées par le "Contexte de conférence". Un
"profil" de conférence, représentant une description initiale de la conférence, spécifie les
affectations des rôles aux différents membres, les intervalles de temps des interventions
relatives aux différents participants ainsi que les attributs de la conférence (ouverte/fermée,
conduite/anarchique, etc.). Les informations relatives aux différents floors de la conférence
sont accessibles par toute entité SCCP via des requêtes appropriées sur le "Contexte de floor".

Une conférence peut être constituée d’une ou de plusieurs "sessions application/média".

Pour les données temps réel, ces sessions sont généralement des sessions RTP. D’autres
protocoles définissent leurs propres concepts de session. Ces sessions peuvent être aussi
désignées par "groupe application" ou "groupe agent média".

3.4.3 Services de SCCP

Dans cette section, nous présentons les services décrits par le document SCCP. Ces
services sont groupés en trois catégories : services de gestion de la conférence, services de
"contrôle de floor" et services de gestion des sessions média/application.

3.4.3.1 Services de gestion de conférence

L’entité SCCP est responsable de la gestion des informations contenues dans le contexte
de conférence. Ces informations concernent les membres SCCP de tous les participants de la
conférence. Le document SCCP décrit un ensemble d’opérations pour la manipulation des ces
informations. Un participant dans une conférence multimédia peut effectuer une opération
d’invitation (invite) à un autre participant pour participer à une conférence tout en respectant
la politique adoptée. Il peut aussi joindre (join) dynamiquement une conférence, la quitter
(leave) sans créer des discordances ou la terminer (terminate).

3.4.3.2 Services de contrôle de floor

L’entité SCCP fournit des services pour le contrôle et la synchronisation de l’état de la

conférence. Elle doit supporter le "mapping" des "protocoles sociaux" en des règles régissant

67
une politique donnée. Le document SCCP énumère juste les services devant être fournis pour
le contrôle du floor. Il ne spécifie pas comment réaliser une politique à laide l’entité SCCP.

Au cours d’une conférence, un participant peut donner un floor à un autre participant

(give). Il peut le demander (Ask), tester (test) son état (libre, non libre, inhiber), l’inhiber
(inhibit), le retirer (grab) à un autre participant ou le rendre (release). Il peut aussi demander
la liste des floors et leurs détenteurs.

3.4.3.3 Services de gestion des sessions applications/médias

SCCP fournit des fonctionnalités de gestion de l’ensemble des sessions média/application

qui constituent la conférence. Les paramètres de ces sessions sont stockés au niveau du
contexte de conférence et sont accessibles par des fonctions bien appropriées. SCCP permet la
création d’une nouvelle session média/application. Il permet aussi la négociation d’une
session média/application nouvellement créée ou le changement de la configuration d’une
session déjà créée. Une entité SCCP peut joindre une session média/application, la quitter ou
la terminer.

Nous tenons à noter que le document SCCP spécifie uniquement les services de manière
informelle. Il ne fournit pas une spécification du comportement dynamique ainsi que les
mécanismes nécessaires pour l’implémentation.

3.4 Conclusion

Nous avons présenté dans ce chapitre des produits de téléconférence. Nous avons ensuite
procédé à une comparaison entre ces produits en se basant sur un ensemble de paramètres.
Parmi ces paramètres, nous avons mis le point sur la gestion et le contrôle de conférence.
Nous avons présenté les concepts relatifs à ces deux concepts.

La gestion et le contrôle de conférence sont décrits de manière informelle dans les

standards de l’IUT et l’IETF. Toutefois, aucun travail ne fournit une description formelle du
comportement relatif à ces deux concepts. C’est dans ce sens que nous nous proposons de
décrire formellement le comportement d’une entité de gestion de conférence et de contrôle de
floor en se basant sur la recommandation SCCP.

La formalisation est une étape d’un grand intérêt pour le développement des systèmes et
applications complexes. Elle permet d’aboutir à des spécifications claires, consistantes et

68
vérifiables. Ceci permet de faciliter la réalisation des systèmes spécifiés et d’assurer leur bon
fonctionnement.

69
Deuxième Partie

Architecture,
spécification et
implémentation

70
 Chapitre 1

Formalisation de la gestion et du
contrôle au sein d'une conférence
multimédia

Le travail de ce chapitre a été réalisé au laboratoire LORIA de Nancy au cours d’un stage de
recherche dans le cadre du projet STIC. Ce travail a fait l’objet de la publication suivante :

M. Ouzzif, M. Erradi and A. Schaff, "An SDL Specification of Coordination Protocol within a
Teleconferencing System", ISIVC2000, Rabat, 2000.

1.1 Introduction

Nous avons présenté à travers l’étude bibliographique de la première partie, les concepts
de TCAO en général et des systèmes de téléconférence en particulier. Nous avons montré via
cette étude le besoin ainsi que le rôle de la gestion et du contrôle de conférence multimédia.
Nous avons présenté aussi la recommandation SCCP qui décrit les services que doit fournir
un protocole de gestion de conférence et de contrôle de floor. Toutefois, cette
recommandation fournit juste une description informelle de ces services et ne spécifie pas le
comportement dynamique du protocole de gestion et de contrôle de conférence. Ce
comportement doit être défini et formalisé en vue de pouvoir vérifier la consistance du
protocole et de tester ses implémentations.

Dans ce chapitre nous présentons une architecture de gestion et de contrôle de conférence

en se basant sur la recommandation SCCP. Nous spécifions, pour chaque politique (présidée

71
et explicite) le comportement du système de téléconférence sous-jacent et son protocole en
utilisant le modèle des automates à états finis.

1.2 Configuration et pile protocolaire d’un système de

téléconférence sur Internet

Nous présentons dans cette section une configuration du système de téléconférence

proposé ainsi que la pile de protocoles utilisés pour la gestion et le contrôle de conférence.

1.2.1 Configuration d’un système de téléconférence sur Internet

Rappelons que, généralement, on distingue trois approches d’architecture pour les

systèmes de travail coopératif [Kars 94] : les architectures centralisées, les architectures
distribuées (ou répliquées) et les architectures hybrides. En général, les systèmes de travail
coopératif temps-réel, sont trop demandeurs en ressources pour qu’il soit raisonnable de les
implémenter de façon centralisée.

L’architecture de gestion et de contrôle de conférence qu’on adopte est l’architecture

purement répliquée. Dans cette architecture, une copie de l’application s’exécute sur chaque
site faisant partie de la conférence. L’activité de chaque membre de la conférence est
distribuée à tous les autres participants de manière à assurer une consistance des données de la
conférence et à garder des vues synchronisées au niveau de tous les sites. Ce type
d’architecture est plus complexe à réaliser et nécessite des outils logiciels permettant de gérer
de manière transparente la distribution. Toutefois, elle présente plusieurs avantages parmi
lesquels, nous citons :

- la fiabilité : dans une architecture répliquée, une copie des informations de la

conférence est maintenue au niveau de chaque site. Ceci permet à la conférence
d’évoluer même si un site ou plusieurs tombent en panne. Ceci n’est pas le cas dans
une architecture centralisée où une unique copie de l’application ainsi que l’ensemble
des informations de la conférence sont stockés dans un seul serveur.

- la performance : les architectures répliquées requièrent moins de bande passante lors

des consultations des données de la conférence et sont moins sensibles aux variations
des latences du réseau. En effet, les participants perçoivent de bonnes performances
d’interaction avec le système vue qu’ils interagissent avec des copies locales de

72
 l’application. Dans une architecture centralisée, tous les sites interagissent avec le
serveur générant ainsi un nombre élevé de messages.

- Une meilleure interaction : avec une architecture répliquée, de nouvelles copies de

l’application peuvent facilement effectuer des interactions locales sur les informations
partagées de l’environnement. Par contre, pour une architecture centralisée, le serveur
doit créer pour chaque interaction individuelle avec un site, un thread. Ceci peut
alourdir le fonctionnement du serveur et par conséquent augmenter le temps de
réponse d’une requête. L’architecture répliquée se base ainsi sur le multicast des
annoncements occasionnels des états.

Protocoles de gestion
Protocoles de gestion
Serveur SIP Serveur SIP

Système Système final

final

Membre Membre
(UCI) (UCI)

Groupe de
travail
virtuel

Internet

Protocoles de gestion

Système
final Protocoles de gestion

Membre
(UCI) Système

Serveur SIP Membre

(UCI) Serveur
SIP

Figure II.1.1. Architecture d’une téléconférence sur Internet.

73
 L’architecture de la conférence multimédia que nous proposons est composée de plusieurs
participants identifiés par des UCIs (Universal Communication Identifier) (figure II.1.1).
Chaque participant est connecté à un réseau local et peut assurer sa présence à la conférence à
travers un ou plusieurs hôtes. L’ensemble des hôtes utilisés par un participant constitue son
système final. Ce système est exploité à l’aide d’un ensemble de logiciels et protocoles
spécifiques à la gestion et au contrôle de conférence. Ces outils, associés au système final
constituent le membre de conférence relatif à un participant donné.

Chaque membre dispose au niveau de son réseau local d’un serveur SIP permettant aux
autres participants (sur d’autres réseaux) de le localiser et de l’inviter à participer à une
opération donnée de la conférence en utilisant le protocole SIP.

1.2.2 Pile de protocoles d’un système de téléconférence sur Internet

L’architecture protocolaire de l’IETF, présentée dans la partie I (chapitre 2), concernant

les systèmes de téléconférence comporte l’ensemble des protocoles nécessaires à la
conférence multimédia sur Internet. Ces protocoles sont organisés en une pile de blocs non
superposés qui peuvent interagir horizontalement et/ou verticalement. Toutefois, cette pile
n’est pas claire, peu compréhensible et peut être interprétée de différentes manières. De plus,
peu de travaux ont été effectués au niveau du bloc de gestion et de contrôle de conférence.

L’architecture protocolaire que nous proposons est basée sur la pile de l’IETF. Elle se
présente sous forme d’une pile de protocoles répliquée sur tous les systèmes finaux d’une
conférence (figure II.1.2) [Ouzz 00a]. Elle est composée des blocs suivants : Le bloc
"Interface de Conférence" (Conference Controller selon SCCP), le bloc "Gestion et
Contrôle", le bloc "Agents Média" et le bloc "Transport". Le bloc "Interface de Conférence"
constitue une interface entre l’utilisateur et le bloc "Gestion et Contrôle". Il présente les
différentes politiques de gestion et de contrôle pouvant être supportées par le système de
téléconférence. Il permet à l’initiateur de la conférence de choisir une politique déterminée et
à un utilisateur de joindre cette conférence en respectant les règles de cette politique.

Le bloc "Gestion et Contrôle" fournit les services de gestion du groupe de participants de

la conférence et les services de contrôle d’accès à ses ressources partagées. Ces services sont
assurés par l’entité du protocole de "Gestion de Conférence et Contrôle de Floor" (entité
GCCF) qui adopte un comportement spécifique à chaque politique supportée par le système.

74
 Interface de
Conférence

Politique

Entité GCCF
Applications
C_C Coordination_GCCF Audio/Vidéo
F_C partagées

Gestion Contrôle Floor

Conférence

Gestion Média

Bloc Gestion et Contrôle

Session RTP Session RTP

SIP SAP SDP

Bloc Initiation de Conférence Bloc Agents Médias

TCP/UDP

IP / IP Multicast

Couche basse

Bloc Transport

Figure II.1.2. Architecture de gestion et de contrôle de conférence.

L’entité GCCF que nous avons conçu, est composée de quatre processus : le processus
"Gestion Conférence", le processus "Contrôle Floor", le processus "Gestion Média" et le
processus "Coordination_GCCF". Elle comporte aussi deux contextes sous forme de base de
données : le contexte de floor qui maintient localement les informations concernant les

75
différents floors de la conférence et le contexte de conférence qui détient les informations
concernant le groupe de conférence.

Le processus "Gestion Conférence" fournit les services de gestion des membres de la

conférence depuis son initiation jusqu’à sa terminaison. Il interagit principalement avec le
contexte de conférence et le bloc "Initiation de Conférence". Le processus "Gestion
Conférence" met à jour le contexte de conférence à chaque fois qu’il reçoit un message
concernant la gestion de groupe (jointure, départ, etc). En ce qui concerne son interaction avec
le bloc "Initiation de Conférence", Il peut utiliser le protocole SDP pour élaborer ou récupérer
la description d’une conférence ; Il peut faire appel aux services du protocole SAP pour
annoncer une conférence ; et Il peut utiliser les services du protocole SIP pour initier une
conférence ou inviter et localiser un participant.

Le processus "Contrôle Floor" fournit les services de coordination des interactions entre
les participants de la conférence et les services de gestion et de contrôle d’accès à ses
ressources partagées. Il interagit avec le contexte de floor pour le mettre à jour à chaque fois
qu’il reçoit un message de contrôle de floor (attribution, retrait, etc) ou pour obtenir des
informations sur les floors de la conférence. Ce processus contrôle aussi les ressources
multimédias (audio/vidéo, applications partagées) à travers le processus "Gestion Média".
Celui ci interagit avec les modules du bloc "Agents Médias" pour leur ordonner d’agir sur les
ressources de la conférence. Le processus "Coordination_GCCF" joue le rôle de
coordonnateur entre les processus "Gestion Conférence" et "Contrôle Floor" et d’interface de
l’entité GCCF vis à vis du bloc "Interface de Conférence".

Le bloc Agents média est constitué des applications audio vidéo, des applications
partagées, des sessions RTP, et du protocole de multicast fiable. Chaque application
multimédia (audio ou vidéo) dispose d’une session RTP/RTCP lui permettant d’acheminer les
paquets audio ou vidéo en temps réel. Les applications partagées interagissent avec les
connexions multicast fiables pour assurer une fiabilité du transport des données.

La figure II.1.3 montre les deux types d’interactions relatives à la gestion et au contrôle de
conférence. On distingue les interactions entre les processus "Gestion Conférence" et
"Contrôle Floor" des différents membres de la conférence (flèches en gras) et les interactions
internes à une entité GCCF (entre les processus "Coordination_GCCF", "Gestion
Conférence", "Contrôle Floor" et "Coordination_GCCF"). Les premières interactions sont
assurées par les services de transport de données (unicast ou multicast).

76
 Interface Conférence

Politique

Entité GCCF Entité

C_C Coordination_GCCF Coordination_GCCF

F_C F_C C_C

Gestion Floor Gestion Floor

Gestion Gestion
Conférence Conférence

Gestion Média Gestion Média

Bloc Gestion et Contrôle Bloc Gestion et Contrôle

Bloc Transport

Figure II.1.3. Interaction de l’entité GCCF.

1.3 Description formelle du comportement d’un MMTS

Les travaux de recherche relatifs à la gestion d’un MMTS se sont intéressés plus à l’aspect
architectural [Kaus 99], aux pré-requis en terme de services de gestion et contrôle de
conférence [Ibri 02, Wu 02, Domm 03, Domm 04, Owez 97, Hilt 01, Kaus 98a, Schu 04] et à
l’interopérabilité [Kaus 98b] entre MMTSs. Peu de travaux sont consacrés à la description
formelle du comportement d’un MMTS selon une politique adoptée. Le processus de
formalisation permet d’accomplir des spécifications claires, consistantes et sans ambiguïtés. Il
permet aussi de rendre possible la vérification des propriétés d’un système ainsi que son test
de conformité. Dans cette section, nous commençons par donner un bref aperçu sur les
techniques de description formelles. Nous présentons ensuite la description formelle du
comportement d’un MTTS selon deux politiques différentes (présidée et explicite).

1.3.1 Techniques et langages de description formelle

La description formelle des systèmes distribués et leurs protocoles constitue une étape
primordiale dans le cycle de vie de leur développement. Elle permet de décrire et de maîtriser
le comportement de chaque entité ainsi que le comportement global du système en vue
d’éviter des erreurs lors de sa mise en place. Chaque technique de description formelle est
basée sur un ensemble de modèles mathématiques appelé formalisme.

77
 Un formalisme peut être de deux types [Ango 93] : opérationnel ou descriptif. Le premier
type (qualifié également de formalisme orienté modèle) permet de décrire un système en
terme de fonctionnement (description du comment). Il est basé généralement sur la notion de
machine d’état abstraite dans laquelle, les états et les transitions possibles sont définis au
préalable. Parmi ces formalismes, nous distinguons les machines à états, les réseaux de Petri
et l’algèbre de processus. Quand aux formalismes descriptifs (ou orientés propriétés), ils
permettent de décrire les propriétés du système. Ce type de formalismes utilise généralement
la logique temporelle comme moyen de description de ces propriétés.

La spécification formelle d’un système selon un formalisme donné est élaborée par un
langage de spécification formel qui adopte ce formalisme. Nous distinguons principalement
trois langages de spécifications normalisés à savoir ESTELLE, LOTOS et SDL. Le langage
ESTELLE (Extended State Transition Language) est normalisé par l’ISO en 1989 pour la
description des services et protocoles OSI en particulier et des systèmes distribués en général
[ISO 89]. Il est basé sur les concepts de module et sous modules pour la structuration du
système et sur le concept de canaux pour l’échange des messages entre les modules.

LOTOS (Language Of Temporal Ordering Specification) est un langage formel normalisé

par l’ISO en 1988 [ISO 88b, Davi 92]. Il a été conçu pour permettre une description formelle
des services et des protocoles de communication normalisés. Ce langage est structuré en deux
parties complémentaires. La première partie fournit le modèle comportemental basé sur
l’algèbre de processus. La deuxième partie permet la spécification des données en se basant
sur le langage ACT ONE [Ehri 85].

SDL (Specification and Description Language) est un langage de spécification formelle

normalisé par l’ITU [ITU 88, Turn 93]. Il permet de décrire et de spécifier sans ambiguïté le
comportement des systèmes de télécommunication en se basant sur le concept de machine à
états finis. Il présente l’avantage de disposer de moyens graphiques pour la description des
systèmes. Il introduit quatre concepts principaux : les concepts liés à la structuration d’un
système en sous-systèmes, les concepts de communication, les concepts liés à la description
du comportement et les concepts de représentation de données. Le comportement est décrit à
l’aide des machines à états finis.

Il existe aussi des langages de spécification orientés-objets. Nous citons comme exemple
le langage Mondel. Ce langage a été développé dans le cadre du projet CRIM/BNR
(Computer Research Institute of Montréal) [Boch 90]. Une spécification Mondel suit une
méthodologie composée des étapes suivantes : identification du problème général (phase

78
informelle), identification des composants (objets), identifications des services (opérations
des objets) et définition des comportements.

Un certain nombre d’outils ont été développés pour le support des langages de
spécification formelle. A titre d’exemples, nous citons : Veda [Jard 94] qui supporte les
concepts ESTELLE, Geode [Cava 88] de Verilog pour le langage SDL et SPIN/Promela qui
n’est pas spécifique à un langage normalisé et supporte le formalisme de machines à états
finis. Ces outils offrent des fonctionnalités de vérification et de génération de cas de tests.

1.3.2 Spécification formelle de MMTS à politique présidée

Nous décrivons dans cette section un MMTS selon la politique présidée. Nous
commençons par une spécification informelle élucidant les règles de cette politique, nous
présentons ensuite sa spécification formelle.

1.3.2.1 Description informelle

Les fonctionnalités de gestion de conférence et de contrôle de floor dans la politique

présidée que nous considérons, sont assurées par un membre du groupe désigné par le terme
"modérateur". Ce membre crée et initie la conférence à laquelle il associe les floors relatifs à
ses ressources partagées. Rappelons qu’un floor est une permission temporaire accordée
dynamiquement aux utilisateurs d’un groupe d’un MMTS dans le but d’assurer un usage
mutuellement exclusif des ressources partagées au sein d’une conférence. Nous considérons
dans notre cas que le floor concerne la prise de parole dans le sens où le participant qui
dispose du floor est celui qui est vu et entendu chez les autres membres de la conférence.
Une fois la conférence créée, de nouveaux participants peuvent la joindre dynamiquement.
Quand un nouveau membre joint la conférence, le modérateur lui envoie les contextes de
conférence et de floor.

Lorsqu’un participant désire utiliser une ressource partagée, il envoie une requête de
demande de floor qui est enregistrée au niveau du modérateur. Quand ce dernier décide
d’accorder le floor à un participant, il commence par l’inviter en utilisant le service
d’invitation du protocole SIP. Si le participant concerné répond à l’invitation, le modérateur
lui passe le floor en lui accordant un délai de prise de parole bien précis. Deux cas peuvent se
présenter après : soit que le participant restitue le floor dans le délai qui lui est imparti, soit

79
qu’il dépasse ce délai. Dans le deuxième cas, le modérateur lui retire le floor. Le modérateur
peut aussi inviter un participant à prendre la parole sans que ce dernier la demande.

Le modérateur ainsi que les participants mettent à jour les contextes de conférence et de
floors à chaque fois qu’ils reçoivent des messages concernant la gestion de conférence ou des
messages concernant le contrôle de floor. Ceci permet d’assurer une consistance de
l’information au niveau de tous les sites. Pour ce faire, le mode de transmission utilisé est le
mode multicast. Ceci permet d’assurer la réception des messages de gestion et de contrôle de
floor par tous les participants de la conférence.

1.3.2.2 Description formelle

La description formelle de la politique présidée que nous avons présentée précédemment

consiste à décrire le protocole de communication de l’entité GCCF régi par cette politique.
Nous présentons en premier lieu le PDU (Protocol Data Unit) échangé entre les entités
GCCF. Nous identifions ensuite les primitives de service de ce protocole, puis nous décrivons
le comportement des différents processus de l’entité GCCF pour ce protocole.

a. PDU

L’information de gestion de conférence et contrôle de floor (information GCCF) échangée

entre les processus de l’entité GCCF est codée dans des paquets GCCF adoptant le format de
la figure II.1.4.

Conf_ID Group_Address Info_Participant Type_Media ID_Floor

IP_Multicast Port

Name IP_Address

Audio Video Text

Figure II.1.4. Paquet GCCF.

Il existe deux types de messages utilisés par l’entité GCCF : les messages de gestion de
conférence, échangés entre les processus relatifs à la gestion de conférence et les messages de

80
contrôle de floor échangés entre les processus de contrôle de floor. Chacun des processus
"Gestion Conférence" et "Contrôle Floor", utilise les champs appropriés à ses primitives. Ces
champs sont les suivants :

- Conf_Id: ce champ désigne l’identificateur de la conférence. Cet identificateur est généré

par l’entité GCCF à partir du nom de l’initiateur de la conférence et son adresse IP. Ce
champ sert à identifier de manière unique une conférence ;

- Group_Address: ce champ comporte les informations relatives à la communication de

groupe. Il est composé de deux parties. La première désigne l’adresse IP Multicast pour le
transfert en mode restreint des messages de gestion de conférence et de contrôle de floor.
La deuxième partie désigne le port de la conférence ;

- Info_Participant : ce champ est composé de deux informations concernant le participant :

son nom et son adresse IP ;

- Type_Media : ce champ est composé de trois champs sous forme de flags. Ils désignent
les types de médias supportés par la conférence ;

- ID_Floor : ce champ désigne l’identificateur de floor. Il permet de représenter un floor

relatif à une ressource ou plusieurs ressources partagées de manière unique.

b. Services GCCF

Rappelons que l’entité GCCF d’un MMTS fournit les services de gestion de conférence et
de contrôle de floor de manière distribuée. Ceci est assuré par l’échange en mode multicast
d’un ensemble de primitives de services. Ces services sont de deux types : les services de
gestion de conférence et les services de contrôle de floor.

- Services de gestion de conférence

L’entité GCCF permet la gestion du contexte de conférence contenant les informations

concernant tous les participants d’une conférence. Il offre les opérations suivantes pour
effectuer la gestion de conférence :

- Créer une nouvelle conférence (GCCF_Create_Conf) : permet au modérateur ou à

l’initiateur de créer une conférence ;
- Joindre une conférence (GCCF_Join) : permet à un nouveau participant de joindre
dynamiquement la conférence. Le message correspondant à une invocation de cette
primitive est envoyé au groupe de la conférence déclenchant la mise à jour des contextes
de conférence et de floor ;

81
 - Quitter la conférence (GCCF_Leave) : permet à un participant de quitter dynamiquement
la conférence. Les contextes de conférence et de floor au niveau de tous les membres du
groupe sont mis à jour lors de la réception d’un message GCCF_Leave ;
- Inviter un participant (GCCF _Invite) : permet à un participant d’inviter un autre
participant du groupe à participer à la conférence. Elle fait appel aux services d’invitation
et de localisation du protocole SIP ;
- Répondre à une invitation (GCCF _Accept) : cette primitive exprime qu’un participant
accepte l’invitation effectuée à l’aide de GCCF_Invite ;
- Arrêter une conférence (GCCF_Pause) : permet d’arrêter la conférence pendant une
durée de temps bien déterminée ;
- Reprendre la conférence (GCCF_Resume) : permet de reprendre une conférence arrêtée
à l’aide de la primitive GCCF_Pause ;
- Exclure un participant (GCCF_Remove) : permet, dans le cas d’une conférence présidée,
au modérateur d’éliminer un participant de la conférence ;
- Demander le contexte de conférence (GCCF_Request_Conference_Context) : cette
primitive permet à un participant d’émettre une requête de demande de contexte de
conférence ;
- Répondre à une demande de contexte de conférence (GCCF_Give_Confernce_Context) :
permet de retourner le contexte de conférence ;
- Terminer une conférence (GCCF_Terminate) : permet de terminer une conférence.
- Services de contrôle de floor
L’entité GCCF fournit des facilités de contrôle en vue de supporter la synchronisation des
interactions des participants. Elle permet aussi de supporter la conduite de conférence en
utilisant les fonctionnalités de contrôle de floor en vue de "mapper" les "protocoles sociaux"
(i.e. les règles pour accéder aux objets application tels que les streams audiovisuel). Les
services de contrôle de floor sont :
- Créer un floor (GCCF_Create_Floor) : cette primitive de service permet de créer un
nouveau floor dans la conférence. Elle est utilisée par le modérateur ou l’initiateur de la
conférence ;
- Attribuer un floor (GCCF_Give_Floor) : cette primitive permet d’accorder le floor à un
participant ;

82
 - Retirer un floor : GCCF_Grab_Floor: cette primitive permet au modérateur ou au
système de retirer le floor à un participant ;
- Libérer un floor (GCCF_Release_Floor) : cette primitive permet à un participant de
rendre le floor au modérateur et de le donner au prochain utilisateur ;
- Demander le floor (GCCF_Ask_Floor) : cette primitive permet de demander le floor au
détenteur de floor ou au modérateur ;
- Notifier la réception d’une demande de floor (GCCF_Ask_Floor_Pending) : cette
primitive permet de notifier un participant que sa demande a bien été reçue ;
- demander le contexte de floor (GCCF_Request_Floor_Context) : cette primitive permet
à un participant de demander des informations concernant les floors de la conférence ;
- Retourner le contexte de floor (GCCF_Give_Floor_Context) : cette primitive permet de
répondre à une demande de contexte de floor.

Le tableau II.1.2 montre les champs du PDU GCCF qui peuvent être utilisés par chaque
primitive GCCF.

Conf_ID Group_Adress Info_Participant Media_Type ID_Floor

GCCF_Create_Conf * * * *
GCCF_Terminate *
GCCF_Join * * *
GCCF_Leave * *
GCCF_Invite * *
GCCF_Accept * *
GCCF_Pause *
GCCF_Resume *
GCCF_Remove * *
GCCF_Request_Conference_Context *
GCCF_Give_Conference_Context * * * *
GCCF_Create_Floor * *
GCCF_Give_Floor * * *
GCCF_Grab_Floor * * *
GCCF_Release_Floor * * *
GCCF_Ask_Floor * * *
GCCF_Ask_Floor_Pending * * *
GCCF_Request_Floor_Context * *
GCCF_Give_Floor_Context * * *

Tableau II.1.2. Primitives et champs.

83
 c. Comportement

Nous décrivons le comportement de l’entité GCCF à l’aide du formalisme des automates à

états finis communiquant. Un automate d’états finis permet de représenter le comportement
des processus sous forme d’états évoluant sous l’effet d’actions. Selon [Beau 91], un automate
à états finis est un quadruplet <E, T, t, e0> où E représente un ensemble fini d’états, T un
ensemble fini d’actions, e0 un élément particulier de E appelé état initial et t une application
de E*T vers E, appelée fonction de transition. La fonction t indique l’état auquel l’automate
doit passer quand une action se produit à un état donné.

Les actions peuvent correspondre à des émissions ou des réceptions de messages. Dans ce
cas l’automate est représenté par un sextuplent : (E, e0, I, O, A, t) où I représente l’ensemble
fini d’évènements en entrée, O l’ensemble fini d’évènements en sortie, A la fonction de
génération de l’événement en sortie et t la fonction de transition de E*I dans E. Pour
modéliser un système distribué à l’aide de ce concept, il suffit de modéliser chacun de ses
processus à l’aide d’automates et d’identifier leurs points d’interactions. Ces interactions
peuvent être effectuées à travers des canaux de communication utilisant les files d’attentes.
On parle dans ce cas d’automates d’états finis communiquant.

Rappelons que l’entité GCCF de la pile de protocoles que nous avons élaborée pour un
MMTS comporte quatre processus. Nous donnons pour chacun de ces processus, la
description de son comportement sous forme d’un automate d’états finis et nous décrivons les
interactions possibles au sein de l’entité GCCF.

Le processus "Coordination_GCCF" joue le rôle d’interface de l’entité GCCF et présente

l’ensemble des services de gestion de conférence et de contrôle de floor au bloc "Interface de
Conférence". Son comportement (figure II.1.5) consiste à recevoir les messages GCCF de
"l’Interface de Conférence" et de les dispatcher aux processus "Gestion Conférence" et
"Contrôle Floor". Il reçoit aussi des messages internes de l’entité GCCF de la part de ces deux
processus pour les notifier à "l’Interface de Conférence" et assure la coordination entre eux.

Le processus "Coordination_GCCF" interagit avec deux acteurs principaux (via

"l’interface de conférence") dans la politique présidée : le modérateur et le simple participant.
Il adopte ainsi deux comportement différents que nous modélisons par les états
"Moderateur_Coordination" et "Participant_Coordination". Le premier état est atteint de l’état
initial ("Initial_Coordination") suite à une demande de création de conférence émise par le
modérateur et le deuxième, suite à une demande de jointure par un simple participant.

84
 Initial_Coordination
? GCCF_Join
/ ? GCCF_Create_Conf / - ? GCCF_ Create_Floor
! Join to P2 ! Create_Conf to P2 ! Create_Floor to P3
- ? GCCF_Ask_Floor ! Join to P3 ! Create_Conf to P3 - ?Ask_Floor from P3
! Ask_Floor to P3 ! GCCF_Ask_Floor
- ? Ask_Floor_Pending from P3 / - ? GCCF_Ask_Floor_Context
! GCCF_Ask_Floor_Pending ! Ask_Floor_Context to P3
- ? Invite From P2 / - ? Give_Floor_Context from P3
! GCCF_Invite GCCF_Give_Floor_Context
- ? GCCF_Accept / - ? GCCF_Invite /
! Accept to P3 ! Invite to P2
- ? GCCF_Not_Accept / - ? Accept from P3 /
Participant_Coordination Moderateur_Coordination
! Not_Accept to P2 ! GCCF_Accept
- ? Give_Floor from P3 / - ? Not_Accept from P3 /
! GCCF_Give_Floor ! GCCF_Not_Accept
? GCCF_Leave
- ? GCCF_Release_Floor / - ? GCCF_Give_Floor /
/
! Release_Floor to P3 ! Give_Floor to P3
! Leave to P2
- ? Grab_Floor from P3 / - ? Release_Floor from P3 /
! Leave to P3
! GCCF_Grab_Floor ! GCCF_Release_Floor
? GCCF_Terminate /
! Terminate to P2
! Terminate to P3

Final_Coordination

P2 est le processus "Gestion Conférence"

P3 est le processus "Contrôle Floor"

Figure II.1.5. Comportement du processus "Coordination_GCCF" présidé.

A l’état "Moderateur_Cordination", le processus "Coordination_GCCF" reçoit des

messages GCCF concernant les décisions du modérateur selon la politique présidée. A titre
d’exemple, quand le modérateur invite un participant, son bloc "Interface Conférence"
invoque la primitive "GCCF_Invite". Ceci entraîne l’envoi du message interne "Invite" au
processus "Gestion Conférence". A ce même état, le processus "Coordination_GCCF" reçoit
des messages internes à l’entité GCCF et notifie "l’Interface de Conférence" relatif au
modérateur. Par exemple, à la réception du message interne "Ask_Floor" du processus
"Contrôle Floor", il notifie "l’Interface de Conférence" à l’aide de la primitive
"GCCF_Ask_Floor".

A l’état "Participant_Coordination", le processus "Coordination_GCCF" reçoit des

messages GCCf de "l’Interface Conférence" concernant un simple participant selon la
politique présidée. A titre d’exemple, quand un participant libère le floor, son bloc "Interface
de Conférence" invoque la primitive "GCCF_Release_Floor". Ceci entraîne l’envoi du
message interne "Release_Floor" au processus "Contrôle Floor". A ce même état, le processus
"Coordination_GCCF" reçoit des messages internes et notifie le participant à travers
"l’Interface de Conférence". Par exemple, à la réception du message interne "Invite" du
processus "Gestion Conférence", il notifie "l’Interface Conférence" à l’aide de la primitive
"GCCF_Invite". L’état "Final_Coordination" est atteint suite à la terminaison de la conférence
par le modérateur ou à un départ d’un participant.

85
 Initial_Conf
? Create_Conf from P1 /
? Join from P1 /
! Update_CC .
! GCCF_Update_CC (join)
to ALL

? GCCF_Invite / ? Invite /
! Invite to P1 ! SIP_Invite
Activate_Timer Activate_Timer

- ? GCCF_Update_CC (Join) / - ? GCCF_Update_CC (Join) /

Update_CC Update_CC
Participant_Conf Moderateur_Conf - ? GCCF_Update_CC(Leave) /
- ? GCCF_Update_CC(Leave) / - ? SIP_OK /
Update_CC ! GCCF_Invite Update_CC
- ? GCCF_Update_CC (Join) /
Update_CC
- ? Accept from P1/ Atente_Conf
- ? GCCF_Update_CC(Leave) /
! GCCF_Accept Update_CC
- ? Not_Accept
! GCCF_Not_Accept
- ? Timeout / !. - ? GCCF_Accept
! Accept to P1
- ? Timeout / .
- ? GCCF_Not_Accept /
! Not_ Accept to P1
- SIP_Cancel / ! Not_Accept

- ? Leave from P1 /
? Terminate from P1 /
! GCCF_Update_CC (Leave)
! GCCF_Terminate to
- ? GCCF_Terminate / !.
ALL
Final_Conf

P1 est le processus GCCF_Coordination

GCCF_Update_CC signifie GCCF_Update_Conference_Contexte

Figure II.1.6. Comportement du processus "Gestion conférence" présidé.

Le processus "Gestion Conférence" supporte les fonctionnalités de gestion des utilisateurs

et de la conférence. Selon la politique présidée, ce processus permet au modérateur de créer
la conférence. Une fois créée, le processus "Gestion Conférence" offre la possibilité aux
participants de joindre la conférence. Ces derniers peuvent ensuite la quitter dynamiquement.
Le processus "Gestion Conférence" peut ainsi offrir des services relatifs à un modérateur ou à
simple participant. Nous modélisons le comportement de ce processus à l’aide de trois
principaux états (figure II.1.6) : l’état "Moderateur_Conf" relatif au modérateur, l’état
"Participant_Conf" relatif à un simple participant et l’état "Attente_Conf" qui représente l’état
où le processus est en attente d’une réponse de son homologue au niveau d’une entité GCCF
distante ou d’un serveur SIP.

Lors de son instantiation, le processus "Gestion Conférence" commence à l’état initial

"Initial_Conf". Il peut ensuite créer une conférence ("Create_Conf") ou joindre une
conférence existante ("Join"). Ceci entraîne la mise à jour du contexte de conférence local et
l’envoi d’un message de mise à jour du contexte de conférence à tous les membres du groupe
constituant la conférence.

Lors d’une invitation exprimée par le modérateur envers un participant, le processus

"Gestion Conférence" relatif au premier acteur, commence par invoquer le service de

86
localisation et d’invitation du protocole SIP (?Invite/ !SIP_Invite) et se met en attente. Une
fois le participant localisé (?OK_SIP), le processus "Gestion Conférence" relatif au
modérateur envoie un message GCCF d’invitation (!GCCF_Invite) à celui du participant.
Celui-ci notifie le participant (?GCCF_Invite/!Invite to P1) qui peut accepter ou non
l’invitation (?Accept from P1 ou ?Not_Accept from P1). Selon cette réponse, il envoie un
message GCCF (!GCCF_Accept ou !GCCF_Not_Accept) au processus "Gestion Conférence"
au niveau du modérateur qui met à jour le contexte de conférence. Le processus "Gestion
Conférence" atteint l’état final suite à la terminaison de la conférence par le modérateur ou au
départ d’un participant.

Initial_Floor
? Join from P1/ !. ? Create_Conf from P1 /
! Send_Media to P4
Update_FC

? Ask_Floor from P1 / - ? GCCF_Release_Floor /

! GCCF_Ask_Floor ! GCCF_Update_FC to
! Activate_Timer - ? Create_Floor From P1 /
All
! GCCF_Update_FC to ALL
! Send_Media
? GCCF_Update_FC / Update_FC
! Release_Floor to P1
Update_FC - ? GCCF_Ask_Floor /
Participant_Floor Update_FC Moderateur_Floor
! Ask_Floor to P1
! GCCF_Ask_Floor_Pending
Update_FC
- ? Ask_Floor_Context
? Timeout /
? GCCF_Ask_Floor_Pending from P1 / ! Give_Floor_Context
!
! Ask_Floor_Pending Attente_Floor GCCF_Grab_Floor

? GCCF_Reject_Floor / ? Give_Floor from P1

! Reject_Floor
- ? Release_Floor /
! GCCF_Release_Floor
! Stop_Send_Media
- ? GCCF_Grab_Floor
! Stop_Send_Media
! GCCF_Release_Floor
! Grab_Floor
! GCCF_Give_Floor
! Stop_Send_Media to P4
! GCCF_Update_FC to ALL
! GCCF_Reject_Floor
? GCCF_Give_Floor / Update_FC
! Give_Floor to P1 Activate_Timer
Update_CF
Detenteur_Floor ? GCCF_Terminate /
!.

? Terminate /
- ? Leave / !. ! GCCF_Terminate to
- ? GCCF_Terminate / !. ALL
Final_Floor
P1 est le processus Coordination_GCCF
P4 est le processus Gestion_Media
GCCF_Update_FC signifie SCCP_ Update_Floor_Context

Figure II.1.7. Comportement du processus "Contrôle Floor" présidé.

Le processus "Contrôle Floor" offre des services de contrôle de floor (figure II.1.7). Il
permet au modérateur de créer des floors et de les associer aux ressources correspondantes. Il
permet aux participants de demander et de libérer un floor. Les requêtes relatives à un floor
sont mises dans une file d’attente du contexte de floor. Le processus "Contrôle Floor" permet
au modérateur de consulter le contexte de floor et de contrôler la détention du floor. Il lui
offre aussi la possibilité de donner le floor aux participants et de les leurs retirer s’ils
dépassent le temps qui leur a été accordé. Nous modélisons le comportement de ce processus

87
en deux états relatifs au participant ("Participant_Floor" et "Attente_Floor"), un état relatif au
modérateur ("Moderateur_Floor") et un état ou le processus est en attente d’une réponse du
processus "Coordination_GCCF" ou d’un processus "Contrôle Floor" homologue distant
("Attente_Floor").

Le processus "Contrôle Floor" peut demander le floor et passer à l’état "Attente_Floor"

(?Ask_Floor du processus "Coordination_GCCF"/ !GCCF_Ask_Floor au modérateur). Si le
modérateur lui accorde le floor, son processus "Contrôle Floor" transite à l’état
"Détenteur_Floor". A partir de cet état, le processus "Contrôle Floor" retourne à l’état
"Participant_Floor" si le participant correspondant respecte le délai (?Release_Floor du
Processus "Coordination_GCCF"/!SCCP_Release_Floor au modérateur) ; ou si le modérateur
lui retire le floor ( ?GCCF_Grab_Floor du processus "Contrôle Floor" relatif au modérateur).

Lorsque le modérateur accorde le floor à un participant ( ? Give_floor du processus

"Coordination_GCCF"/ ! GCCF_Give_Floor au processus "Contrôle Floor" du participant
concerné), le processus "Contrôle Floor" du modérateur transite de l’état "Moderateur_Floor"
à l’état "Attente_Floor". Il peut émettre une requête pour retirer le floor à un participant qui
n’a pas respecté le délai accordé pour la détention du floor ( ! GCCF_Grab_Floor suite à
l’expiration du temporisateur). Le processus "Contrôle Floor" atteint l’état final quand le
modérateur décide de terminer la conférence ( ? Terminate à l’état "Moderateur_Conf") ; ou
s’il reçoit un message de départ d’un participant ( ? Leave à l’état "Participant_Floor").

Le processus "Gestion Média" constitue une interface entre le processus "Contrôle Floor"
et le bloc "Agents Média". Son comportement consiste à recevoir des messages du processus
"Contrôle Floor" et d’envoyer des messages au bloc "Agents Média". Chaque fois qu’un
processus "Contrôle Floor" détient le floor, il donne l’ordre au processus "Gestion Média"
d’envoyer les médias. Une fois qu’il perd le floor il donne l’ordre d’arrêter l’envoi des médias
(figure II.1.8).

Initial_Media

? Send_Media /
! Send_Media
to Media Agent

? Send_Media /
! Send_Media to Media Agent
Envoi_Media

? Stop_Send_Media /
! Stop_Send_Media to Media Agent
Arret_Envoi_Media

Figure II.1.8. Comportement du processus SCCP_Media.

88
 P1 Modérateur P2 Modérateur P3 Modérateur P4 Modérateur SIP P1 Participant P2 Participant P3 Participant P4 Participant SIP

GCCF_Create_Conf
Create_Conf

Create_Conf
Send_Media
GCCF_Join
GCCF_Create_FLoor Join
Create_Floor GCCF_Update_FC Join

GCCF_Update_CC
GCCF_Ask_Floor
Ask_Floor
GCCF_Ask_Floor
Ask_Floor
GCCF_Ask_Floor
Ask_Floor_Pending

GCCF_Ask_Floor_Context
Ask_Floor_Context

Give_Floor_Context

GCCF_Give_Floor_Context

GCCF_Invite
Invite

SIP_Invite
SIP_Invite
SIP_OK
SIP_OK
Accept
GCCF_Accept

GCCF_Give_Floor
Give_Floor
Stop_Send_Media

GCCF_Give_Floor
Send_Media
GCCF_Update_FC
Give_Floor
GCCF_Give_Floor
GCCF_Reject_Floor

SCCP_Release_Floor
Release_Floor
Stop_Send_Media
GCCF_Release_Floor
Release_Floor

GCCF_Update_FC
GCCF_Release_Floor

Send_Media

GCCF_Leave
Leave

Leave

GCCF_Terminate GCCF_Update_CC

Terminate

Terminate

GCCF_Terminate

Figure II.1.9. Scénario d'une conférence présidée.

La figure II.1.9 présente un scénario sous forme de MSC (Message Sequence Chart) d’une
conférence régie par la politique présidée. Ce scénario comporte deux acteurs : le modérateur
et un participant. Chacun de ces acteurs est représenté par les processus de son entité GCCF
(P1 pour "Coordination_GCCF", P2 pour "Gestion Conférence", P3 pour "Contrôle Floor" et
P4 pour "Gestion Média").

Le modérateur crée la conférence en invoquant la primitive "GCCF_Create_Conf ". Il crée

ensuite le floor relatif aux ressources médias en invoquant la primitive
"GCCF_Create_Floor". Ceci entraîne l’envoi du message de notification de mise à jour du

89
contexte de floor à tous les participants (l’envoi multicast, matérialisé par la flèche en
double).

Le participant joint la conférence en invoquant la primitive "GCCF_Join" puis demande le

floor en invoquant la primitive "GCCF_Ask_Floor". Cette demande est transmise au
modérateur qui consulte le contexte de floor à l’aide de la primitive
"GCCF_Ask_Floor_Context" et invite le participant à l’aide de la primitive "GCCF_Invite".
Cette invitation fait appel à la primitive d’invitation SIP. Le participant accepte l’invitation en
invoquant la primitive "GCCF_Accept" suite à laquelle le modérateur lui donne le floor en
utilisant la primitive "GCCF_Give_Floor". Le participant rend ensuite le floor en utilisant la
primitive "GCCF_Release_Floor". Il quitte la conférence en invoquant la primitive
"GCCF_Leave". Le modérateur termine la conférence en faisant appel à la primitive
"GCCF_Terminate".

1.3.3 Spécification formelle de MMTS à politique explicite

Dans cette section, nous décrivons un MMTS régi par une politique explicite. Nous
commençons par décrire le protocole sous-jacent à cette politique de manière informelle puis,
nous présentons ensuite la description formelle de l’entité GCCF correspondante.

1.3.3.1 Description informelle

La politique explicite part du principe qu’il n' y a pas de membre de la conférence chargé
de la gestion et du contrôle de la conférence. Tous les participants sont sur le même pied
d’égalité. Le floor est donné ou libéré sur la demande d’un membre de la conférence. Tant
que le floor est pris, les requêtes de demande de floor sont mises dans une file d’attente.
Généralement, ces requêtes sont traitées selon le principe du "premier arrivé - premier servi".

Une conférence d’un MMTS régi par une politique explicite peut être initiée par le
premier participant qui prend l’initiative de la créer. Celui ci devient immédiatement détenteur
du floor. Lorsqu’un nouveau participant joint la conférence, il diffuse un message de jointure
à tous les membres de la conférence. Seul le détenteur de floor lui envoie les contextes de
floor et de conférence. Ces contextes vont être mis à jour à chaque fois qu’il y a modification
au niveau de la conférence ou des floors. Ces mises à jour se font de manière distribuée grâce
à l’envoi de messages en mode multicast.

90
 Le floor est demandé explicitement par un participant qui désire intervenir dans une
session de la conférence. Le floor est immédiatement accordée à ce participant si la file est
vide et si le détenteur du floor le libère. Si ce n’est pas le cas, la demande du participant est
mise dans la file d’attente. Cette file n’est pas centralisée au niveau d’un seul site. Elle est
construite dynamiquement et est organisée de manière distribuée. Elle est basée sur
l’information "suivant" de façon à ce que chaque participant ayant effectué une demande est
pointé par celui qui l’a immédiatement devancé.

1.3.3.2 Description formelle

Le processus "Coordination_GCCF" constitue une interface de l’entité GCCF (figure

II.1.10). Son comportement consiste à recevoir des messages GCCF répondant à des
demandes de services de "l’Interface de Conférence" et de les aiguiller, selon leur nature au
processus "Gestion Conférence" ou "Contrôle Floor". Nous modélisons son comportement par
un état principal "Participant_Coordination". Ce processus commence à l’état
"Initial_Coordination" et passe à l’état "Participant_Coordination" s’il recoit une demande de
création de conférence ou une demande de jointure de "l’Interface de Conférence" (?
GCCF_Create_Conf ou ? GCCF_Join)

Initial_Coordination

- ? GCCF_Join /
! Join to P2
! Join to P3
- ? GCCF_Create_Conf /
- ? GCCF_ Create_Floor
! Create_Conf to P2
! Create_Floor to P3
! Create_Conf to P3
- ? GCCF_Release_Floor /
! Release_Floor to P3
- ? GCCF_Ask_Floor /
! Ask_Floor
- ? Give_Floor /
! GCCF_Give_Floor Participant_Cordination Final_Coordination
- ? Grab_Floor from P3 / - ? GCCF_Leave /
! GCCF_Grab_Floor ! Leave to P2
! Leave to P3
- ? GCCF_Terminate /
! Terminate to P2
! Terminate to P3

P2 est le processus "Gestion Conférence"

P3 est le processus "Contrôle Floor"

Figure II.1.10. Comportement du processus "Coordination_GCCF" explicite.

A l’état "Participant_Coordination", le processus "Coordination GCCF" peut recevoir des

requêtes GCCF de "l’Interface de Conférence" qu’il transmet au processus "Gestion
Conférence" et/ou "Contrôle Floor" sous forme de messages internes. Par exemple, lorsqu’un
participant veut demander le floor, son "Interface Conférence" invoque la primitive

91
"GCCF_Ask_Floor" que le processus "Coordination_GCCF" transmet au processus "Contrôle
Floor" à l’aide du message interne "Ask_Floor". A ce même état, le processus
"Coordination_GCCF" peut recevoir des messages internes des autres processus de l’entité
GCCF et les notifient à "l’Interface Conférence" sous forme de messages GCCF
(?Give_Floor/!GCCF_Give_Floor). Le processus "Coordination_GCCF" peut atteindre l’état
final s’il reçoit des demandes de départ ou de terminaison de la part de "l’Interface
Conférence" (?GCCF_Leave ou ?GCCF_Terminate").

Le processus "Gestion Conférence" de la politique explicite que nous avons spécifiée

commence à l’état "Initial_Conf" (figure II.1.11). Il passe à l’état "Participant_Conf" suite à la
réception des messages internes relatifs à la création ou à la jointure ( ? Create_Conf ou
?Join). Une fois à l’état "Participant_Conf", son comportement consiste à mettre à jour le
contexte de conférence à chaque fois qu’il y a une jointure ou un départ d’un participant. Le
processus "Gestion Conférence" transite à l’état final s’il reçoit un message interne relatif au
départ d’un participant ou à la terminaison de la conférence.

Initial_Conf

- ? Create_Conf /
Update_CC
- ? Join /
! GCCF_Update_CC(join)
to ALL

- ? GCCF_Update_CC (join) /
! GCCF_Give_CC
Update_CC
- ? GCCF_Update_CC (leave) / Participant_Conf Final_Conf
Update_CC - ? Leave /
!.
- ? Terminate /
!.

Figure II.1.11. Comportement du processus "Gestion Conférence" explicite.

La figure II.1.12 présente le comportement du processus "Contrôle Floor". Son automate

commence à l’état "Initial_Floor" à partir duquel il peut transiter à deux états possibles : l’état
"Detenteur_Floor" s’il s’agit d’une entité GCCF relative au participant ayant pris l’initiative
de créer la conférence (réception du message interne "Create_Conf"); ou à l’état
"Participant_Floor" s’il reçoit un message interne relatif à une jointure.

Le processus "Contrôle Floor" peut passer de l’état "Participant_Floor" à l’état

"Attente_Floor" si le participant correspondant demande le floor ( ? Ask_Floor). Il passe à

92
l’état "Detenteur_Floor" s’il reçoit un message lui accordant le floor de la part de l’entité
GCCF du dernier participant ayant eu le floor ( ?GCCF_Give_Floor).

Lorsque le détenteur du floor le libère, son processus "Contrôle Floor" retourne à l’état
"Participant_Floor" ( ? Release_Floor). Cette même transition peut être dûe à la réception
d’un message de retrait de floor (GCCF_Grab_Floor). La demande de retrait de floor est
effectuée par l’entité GCCF relative au dernier participant ayant libéré le floor suite à
l’expiration du temporisateur. Le processus "Contrôle Floor" atteint l’état final suite au
départ d’un participant ou suite à la terminaison de la conférence.

Initial_Floor
? Join /
? Create_Conf from P1 /
! .
! Send_Media

- ? GCCF_Grab_Floor /
! Grab_Floor
- ? GCCF_Ask_Floor /
! GCCF_Give_Floor to suivant - ? Timeout /
! Ask_Floor Detenteur_Floor Participant_Floor
! Stop_Send_Media ! GCCF_Grab_Floor
- ? Release_Floor /
! GCCF_Give_Floor
! Stop_Send_Media
Activate_Timer

? Ask_Floor /
? GCCF_Give_Floor ! GCCF_Ask_Floor to ALL - ? Leave /
! Give_Floor ! .
Attente_Floor
! Send_Media

Final_Floor

Figure II.1.12. Comportement du processus "Contrôle Floor" explicite.

La figure II.1.13 présente un scénario d’une conférence régie par la politique explicite que
nous avons spécifiée. Ce scénario comporte trois participants représentés chacun par les
processus de l’entité GCCF correspondante. Le premier participant crée la conférence et
obtient le floor. Le deuxième et le troisième participant joignent ensuite cette conférence. Le
deuxième participant demande le floor en diffusant une requête de demande de floor à tout le
groupe. Cette demande est traité par le détenteur du moment qu’il n y a pas de participants en
file d’attente. Celui ci libère le floor et l’accorde au deuxième participant.

Le deuxième et le premier participants demandent ensuite le floor. Ceci implique que la

file est constituée de deux éléments alors que le floor est pris par le deuxième participant. Le
deuxième participant libère ensuite le floor, l’accorde au troisième participant et active un
temporisateur. Ce dernier dépasse le temps qui lui a été accordé et l’entité GCCF lui retire le
floor pour qu’il soit accordé au premier participant.

93
 P1 P2 P3 P4 P1 P2 P3 P4 Participant P1 P2 P3 P4 Participant
Participant 1 Participant 1 Participant 1 Participant1 Participant 2 Participant 2 Participant 2 2 Participant 3 Participant 3 Participant 3 3

GCCF_Create_Conf
GCCF_Join
Create_Conf
GCCF_Join
Create_Conf Join GCCF_Update_CC (join)
Send_Media
Join Join GCCF_Update_CC (join)
Give_Floor
GCCF_Give_Floor Join
GCCF_Update_FC (join)
GCCF_Update_FC (join) GCCF_Update_FC (join)

GCCF_Give_Floor_Context

GCCF_Update_CC(join)

GCCF_Give_Conference_Context

GCCF_Update_FC (join)

GCCF_Give_Floor_Context
GCCF_Update_CC (join)

GCCF_Give_Conference_Contexte

GCCF_Ask_Floor
Ask_Floor

GCCF_Ask_Floor

Ask_Floor
GCCF_Ask_Floor

GCCF_Release_Floor
Release_Floor
Stop_Send_Media
Stop_Send_Media
GCCF_Give_Floor GCCF_Ask_Floor
GCCF_Update_FC

Send_Medi Ask_Floor
Give_Floo a GCCF_Ask_Floor
r
GCCF_Give_Floor
GCCF_Ask_Floor
Ask_Floo
r
GCCF_Ask_Floor

GCCF_Ask_Floor

Ask_Floor
GCCF_Ask_Floor

GCCF_Ask_Floor

Ask_Floor

GCCF_Ask_Floor

GCCF_Release_Floor

Release_Floo
r
Activate_Timer
GCCF_Give_Floor

Give_Floor
GCCF_Give_Floor
Timeout

GCCF_Grab_Floor

Grab_Floor
GCCF_Grab_Floor

GCCF_Give_Floor

Give_Floor
GCCF_Give_Floor

GCCF_Leave
Leave

Leave

GCCF_Update_CC

GCCF_Terminate
Terminate
GCCF_Terminate

Terminate

Figure II.1.13. Scénario d'une conférence explicite.

94
 Le troisième participant quitte ensuite la conférence et le premier participant lui met fin.
Notons que toutes ces interactions se passent entre les entités GCCF et que les participants
n’interagissent avec le système que pour demander ou libérer le floor.

1.4 Conclusion

Nous avons présenté dans ce chapitre une architecture de gestion et de contrôle de

conférence ainsi que la spécification formelle des protocoles sous-jacent. Cette spécification,
basée sur les machines à états finis, permet une description claire, exacte et consistante. Elle
sert aussi de base pour la vérification des propriétés relatives à la gestion et au contrôle au
sein des systèmes de téléconférence.

95
 Chapitre 2

Vérification de propriétés de la
gestion et du contrôle au sein d’une
conférence multimédia

Le travail de ce chapitre a été réalisé au LIFC de Besançon au cours d’un stage de recherche
dans le cadre du projet STIC. Ce travail a fait l’objet de la publication suivante :

M.Ouzzif, M.Erradi, "Formal Description and Validation of Teleconferencing Management

and Control Protocol", IEEE, IWCSE, Marrakech, December 2002.

2.1 Introduction

Nous avons présenté dans le chapitre 1 une spécification formelle de la gestion et du

contrôle au sein d’une conférence multimédia selon deux types de politique (présidée et
explicite). Les systèmes spécifiés doivent respecter des règles au cours de leur
fonctionnement. Par exemple, un participant d’une conférence (présidée ou explicite) ne doit
pas monopoliser la parole. Ces règles doivent être d’abord identifiées puis exprimées de
manière précise et non ambiguë en vue de pouvoir les vérifier. On distingue deux catégories
de règles, des règles qui font appel à des contraintes temporelles et d’autres à caractère
général. Ceci nous emmène vers le choix du langage LTL (LogiqueTemporelle Linéaire) pour
exprimer le premier type de ces règles.

Dans ce chapitre, nous commençons par identifier les règles que doit respecter un système
de téléconférence (présidée et explicite). Nous présentons ensuite la description LTL de ces
règles que nous vérifions à l’aide de l’outil Promela/SPIN.

96
2.2 Description des propriétés

Les propriétés identifiées sont décrites de manière informelle dans un premier temps, puis
formellement en utilisant la LTL.

2.2.1 Description informelle

Les propriétés que nous avons identifiées sont décrites ci-dessous [Ouzz 02a] :

- Propriété 1 : "Lorsqu’un modérateur dispose du floor, les autres membres de la

conférence ne doivent pas l’avoir".

- Propriété 2 : "Lorsqu’un participant dispose du floor, le modérateur ainsi que les autres
participants ne doivent pas l’avoir".

- Propriété 3 : "Lorsqu’un participant reçoit le floor, il doit le libérer pour ne pas le

monopoliser".

- Propriété 4 : "Si un participant ne reçoit pas le floor, il doit être notifié que sa demande a
été rejetée".

- Propriété 5 : "Les participants doivent être en mesure de demander le floor".

- Propriété 6 : "Un participant doit être informé que le floor lui a été accordé".

- Propriété 7 : "Un modérateur doit être capable de retirer le floor à son détenteur".

- Propriété 8 : "Un participant doit être informé que le floor lui a été retiré".

- Propriété 9 : "Lorsqu’un participant dispose du floor, c’est lui qui doit envoyer ses
médias".

- Propriété 10 : "Lorsqu’un participant envoie ses médias, les autres participants doivent
être en réception".

Les propriétés décrites ci-dessus concernent la politique présidée. Toutefois les propriétés
2, 3, 5, 6, 8, 9 et 10 doivent être aussi vérifiées par un MMTS régi par la politique explicite.

2.2.2 Description formelle en LTL

Nous utilisons la LTL pour la description formelle des propriétés décrites ci-dessus. Ce
formalisme est une extension de la logique classique. Il permet de valider des protocoles de
communication en se basant sur des techniques d’expression des relations entre des

97
évènements. La syntaxe de la logique temporelle est la même que celle des prédicats, excepté
qu’elle utilise des opérateurs supplémentaires [Pnue 77]. Ces opérateurs sont décrits comme
suit :

- [p] : qui signifie que la propriété p vient de devenir vraie ;

- O p : qui signifie après p ;
- p : qui signifie que p est vraie maintenant et dans le futur ;

-  p : qui signifie que la propriété p est vraie à un moment donné dans le futur.

Généralement, les propriétés prennent les formes (p  q) ou (p  q), où p et q

sont des propositions. La première écriture exprime que, chaque fois que le système vérifie p,
il doit vérifier q. La deuxième écriture exprime que chaque fois que le système vérifie p, il
doit dans toutes les exécutions futures, vérifier q.

Pour pouvoir décrire les propriétés identifiées en LTL dans un MMTS régi par la politique
présidée, nous considérons une conférence constituée d’un modérateur et de trois participants.
Chaque membre (participant ou modérateur) est représenté par son entité GCCF constituée de
quatre processus. Les propriétés sont décrites en fonction des états des automates relatifs aux
processus de l’entité GCCF de chaque membre. Nous utilisons pour cela quatre tableaux de
quatre cases chacun :

- le tableau "Etat_Coordination" représente les états des processus "Coordination_GCCF"

des quatre membres ;
- le tableau "Etat_Conf" représente les états des processus "Gestion Conférence" ;
- le tableau "Etat_Floor" représente les états des processus "Contrôle Floor" ;
- le tableau "Etat_Media" représente les états des processus "Gestion Média".
Le modérateur est représenté par la case 0 dans les quatre tableaux et les participants par
les cases restantes.

Nous maintenons le même scénario pour le cas d’un MMTS régi par la politique explicite
en considérant le modérateur comme un simple participant.

- Propriété 1 : "Lorsqu’un modérateur dispose du floor, les autres membres de la

conférence ne doivent pas l’avoir".

Pour cette propriété, nous utilisons les propositions suivantes :

98
 Moderateur_Detenteur qui exprime que le modérateur est à l’état "Detenteur_Floor"
(Etat_Floor[0]= "Detenteur_Floor").

Detenteur_i qui exprime que le participant "i" est à l’état "Detenteur_Floor"

(Etat_Floor[i]= "Detenteur_Floor" avec 1<=i<=3)

Selon les opérateurs de la logique temporelle, la propriété 1 s’écrit :

(Moderateur_Detenteur  ! Detenteur1  ! Detenteur_2  ! Detenteur_3)

- Propriété 2 : "Lorsqu’un participant dispose du floor, le modérateur ainsi que les autres
participants ne doivent pas l’avoir".

Dans un MMTS régi par la politique présidée, la propriété 2 s’écrit comme suit :

(Detenteur_1  ! Moderateur_Detenteur  ! Detenteur_2  ! Detenteur_3)

(Detenteur_2  ! Moderateur_Detenteur  ! Detenteur_1  !Detenteur_3)
(Detenteur_3  ! Moderateur_Detenteur  ! Detenteur_1  ! Detenteur_2)

Dans un MMTS régi par la politique explicite, la propriété 2 s’écrit comme suit :

(Detenteur_0  ! Detenteur_1  ! Detenteur_2  ! Detenteur_3)

(Detenteur_1  ! Detenteur_0  ! Detenteur_2  ! Detenteur_3)
(Detenteur_2  ! Detenteur_0  ! Detenteur_1  ! Detenteur_3)
(Detenteur_3  ! Detenteur_0  ! Detenteur_1  ! Detenteur_2)

- Propriété 3 : "Lorsqu’un participant reçoit le floor, il doit éventuellement le libérer pour

ne pas le monopoliser".

Dans un MMTS régi par la politique présidée, la propriété 3 s’écrit comme suit :

(Moderateur_Detenteur   (! Moderateur_Detenteur))
(Detenteur_i   (! Detenteur_i)) pour 1<=i<=3

Dans un MMTS régit par la politique explicite, la propriété 3 s’écrit comme suit :

(Detenteur_i   (! Detenteur_i)) pour 0<=i<=3

- Propriété 4 : "Si un participant ne reçoit pas le floor, il doit être notifié que sa demande a
été rejetée".

Pour cette propriété, nous utilisons les propositions suivantes :

99
Attente_Floor_i qui exprime le processus "Contrôle Floor" relatif au participant "i" est à
l’état "Attente_Floor" (Etat_Floor[i]= "Attente_Floor" avec 1<=i<=3)

Non_Detenteur_i qui exprime le processus "Contrôle Floor" relatif au participant "i" est à
l’état "Participant_Floor" (Etat_Floor[i]= "Participant_Floor" avec 1<=i<=3)

La propriété 4 s’écrit comme suit :

(Attente_Floor_i   Non_Detenteur_i) pour 1<=i<=3

- Propriété 5 : "Les participants doivent être en mesure de demander le floor".

Dans un MMTS régi par la politique présidée, la propriété 5 s’écrit comme suit :

(Non_Detenteur_i   Attente_Floor_i) pour 1<=i<=3

Dans un MMTS régi par la politique explicite, la propriété 5 s’écrit comme suit :

(Non_Detenteur_i   Attente_Floor_i) pour 0<=i<=3

- Propriété 6 : "Un participant doit être informé que le floor lui a été accordé".

Dans un MMTS régi par la politique présidée, la propriété 6 s’écrit comme suit :

(Attente_Floor_i   Detenteur_Floor_i)

Dans un MMTS régi par la politique explicite, la propriété 6 s’écrit comme suit :

(Attente_Floor_i   Detenteur_Floor_i)

- Propriété 7 : "Un modérateur doit être capable de retirer le floor à son détenteur".

Pour cette propriété, nous utilisons les propositions suivantes :

Moderateur_Attente_Floor_i qui exprime le processus "Contrôleur Floor" relatif au

modérateur est à l’état "Attente_Floor" (Etat_Floor[0]= "Attente_Floor")

La propriété 7 s’écrit :

(Moderateur_Attente_Floor   Moderateur_ Detenteur_Floor) )

- Propriété 8 : "Un participant doit être informé que le floor lui a été retiré".

Dans un MMTS régi par la politique présidée, la propriété 8 s’écrit comme suit :

(Detenteur_Floor_i   Non_Detenteur_Floor_i) ) pour 1<=i<=3

100
Dans un MMTS régi par la politique explicite, la propriété 8 s’écrit comme suit :

(Detenteur_Floor_i   Non_Detenteur_Floor_i) ) pour 0<=i<=3

- Propriété 9 : "Lorsqu’un participant dispose du floor, c’est lui qui doit envoyer ses
médias".

Nous utilisons dans cette propriété les propositions :

Moderateur_Diffusion qui exprime que le processus "Gestion Média" relatif au

modérateur est à l’état "Envoi_Media" (Etat_Media[0]= "Envoi_Media").

Diffusion_i qui exprime que le processus "Gestion Média" relatif au participant "i" est à
l’état "Envoi_Media" (Etat_Media[i]= "Envoi_Media", 1<=i<=3).

Dans un MMTS régi par la politique présidée, la propriété 9 s’écrit comme suit :

(Moderateur_Detenteur   (! Moderateur_Diffusion))

(Detenteur_i   (!Diffusion_i)) pour 1<=i<=3

Dans un MMTS régi par la politique explicite, la propriété 9 s’écrit comme suit :

(Detenteur_i   (!Diffusion_i)) pour 0<=i<=3

- Propriété 10 : "Lorsqu’un participant envoie ses médias, les autres participants doivent
être en réception".

Dans un MMTS régi par la politique présidée, la propriété 10 s’écrit comme suit :

(Moderateur_Diffusion  ! Diffusion _1  ! Diffusion _2  ! Diffusion _3)

(Diffusion_1  ! Moderateur_Diffusion  ! Diffusion _2  ! Diffusion _3)
(Diffusion _2  ! Moderateur_ Diffusion  ! Diffusion _1  ! Diffusion _3)
(Diffusion _3  ! Moderateur_ Diffusion  ! Diffusion _1  ! Diffusion _2)

Dans un MMTS régit par la politique explicite, la propriété 10 s’écrit comme suit :

(Diffusion_0  ! Diffusion _1  ! Diffusion _2  ! Diffusion _3)

(Diffusion_1  ! Diffusion_0  ! Diffusion _2  ! Diffusion _3)
(Diffusion_ 2  ! Diffusion_0  ! Diffusion _1  ! Diffusion _3)
(Diffusion_ 3  ! Diffusion_0  ! Diffusion _1  ! Diffusion _2)

101
2.3 Vérification des propriétés

En vue de pouvoir vérifier de manière automatique les propriétés temporelles identifiées,

il est nécessaire de décrire le protocole dans un langage de spécification exécutable. C’est
dans ce sens que nous utilisons Promela pour exprimer le protocole et SPIN pour vérifier les
propriétés.

2.3.1 Description Promela

Promela (Protocols Meta LAnguage) [Holz 91] est un langage de spécification formelle
qui permet la description des protocoles et des systèmes distribués. Une spécification Promela
consiste en un ensemble d’objets qui peuvent être de deux types : les processus et les canaux
de messages. Les processus Promela permettent de décrire le comportement du système
spécifié.

Les processus consistent en deux parties principales : la partie déclaration où on déclare

les variables permettant de représenter entre autres l’état du processus ; et la partie
comportement qui permet de décrire le comportement du processus. Cette partie fait appel à
l’ensemble des structures offertes par Promela à savoir la structure de choix et la répétition.
La description Promela d’un automate consiste en une boucle ("do … od") comportant des
alternatives représentées par la structure de choix. Chaque alternative correspond à un état de
l’automate.

Un processus se déclare en Promela à l’aide du mot clé "Proctype". Une fois déclaré, il
peut être instancié au sein du processus principal "Init" une ou plusieurs fois. L’instanciation
se fait à l’aide du constructeur "Run (processus)". Les processus d’une spécification Promela
peuvent ainsi s’exécuter en parallèle une fois le processus "Init" est lancé. La communication
entre processus se fait via des canaux qui se présentent sous forme de file d’attente. Promela
permet deux types de communication : asynchrone si la taille du canal est supérieure à 1 et
synchrone si la taille est 0.

La représentation des données dans une spécification Promela se fait par des variables
(globales ou locales). Une variable peut être de type prédéfini (bit, byte, int ou short) ou de
type tableau. Le langage Promela permet de définir d’autres types grâce au constructeur
"mtype". Ce constructeur permet de définir de nouvelles structures de données désignant des
états ou des messages.

102
 Pour décrire notre système, nous avons considéré une conférence constituée d’un
modérateur et de trois participants. Pour représenter les états des processus des entités GCCF,
nous avons considéré quatre tableaux : "Etat_Coordination", "Etat_Conf", "Etat_Floor" et
"Etat_Media". Les états des processus du modérateur sont représentés par la case 0 des quatre
tableaux et ceux des processus des participants, par les cases 1,2 et 3 de ces même tableaux.
Dans le cas d’une politique explicite, le modérateur est considéré comme un simple
participant.

La communication entre les processus se fait via plusieurs types de canaux. Nous citons à
titre d’exemple les canaux suivants :

- "Channel_Coordination_Floor [i]" : qui achemine les messages du processus

"Coordination_GCCF" au processus "Contrôle Floor" du membre "i" ;

- "Channel_Floor_Coordination [i]" : qui achemine les messages du processus

"Contrôle Floor" au processus "Coordination_GCCF" ;

- "Channel_Floor_Media [i]" : qui achemine les messages du processus "Contrôle

Floor" au processus "Gestion Média" ;

- "Channel_Moderateur_Participant_Floor [i] " (0<i<=3) qui achemine les messages du

processus "Contrôle Floor" relatif au modérateur au processus "Contrôle Floor" relatif
au participant "i" ;

- et "Channel_Participant_Moderateur_Floor" qui achemine les messages envoyés par

les processus "Contrôle Floor" des participants au processus "Contrôle Floor" du
modérateur.

Nous présentons dans ce qui suit des exemples de description Promela concernant les
processus "Contrôle Floor" dans le cas d’un MMTS présidé et d’un MMTS explicite. La
figure II.2.1 présente la description Promela du comportement du processus "Contrôle Floor"
relatif à un simple participant dans un MMTS régi par la politique présidée. Elle consiste en
un ensemble d’alternatives (if .. fi) relatives aux états de ce processus. Chaque alternative
correspond à un état et un canal bien précis. En étant à cet état et en recevant un message à
travers ce canal, le processus change éventuellement d’état, effectue un traitement et envoie
un ou plusieurs messages. Ainsi, le premier choix concerne l’état initial (Etat_Floor[i] ==
Init). Si le processus reçoit le message "Join" à travers le canal
"Channel_Coordination_Floor", il passe à l’état "Participant_Floor".

103
/** Processus "Contrôle Floor" – Comportement d’un simple participant **/

proctype CONTROLE_FLOOR (i)

{
byte message;
Etat_Floor [i]= INIT ;

do : :
if
:: (Etat_Floor[i] == INIT ) ->
CHANNEL_COORDINATION_FLOOR ? message ;
:: (message == JOIN) -> Etat_Floor[i] = PARTICIPANT_FLOOR ;
fi

:: (Etat_Floor[i] == PARTICIPANT_FLOOR) ->

CHANNEL_COORDINATION_FLOOR ? message ;
if :: (message == ASK_FLOOR ) ->
atomic {Etat_Floor[i] = ATTENTE_FLOOR ;
CHANNEL_PARTICIPANT_MODERATEUR_FLOOR[0] ! GCCF_ASK_FLOOR ;
CHANNEL_FLOOR_TIMER [I] !ACTIVATE_TIMER }
:: (message == LEAVE) -> Etat_Floor[i] = FINAL_FLOOR ;
fi

:: (Etat_Floor[i] == PARTICIPANT_FLOOR) ->

CHANNEL_MODERATEUR_PARTICIPANT_FLOOR [i]? message ;
if :: (message == GCCF_TERMINATE) -> Etat_Floor[i] = FINAL_FLOOR ;
:: (message == GCCF_UPDATE_FC) -> UPDATE_FC ;
fi

:: (Etat_Floor[i] == ATTENTE_FLOOR ) ->

CHANNEL_ MODERATEUR_PARTICIPANT_FLOOR [I] ? message ;
if :: (message == GCCF_GIVE_FLOOR) ->
atomic {Etat_Floor[i] = DETENTEUR_FLOOR ; CHANNEL_FLOOR_COORDINATION ! GIVE_FLOOR ; }
:: (message == GCCF_REJECT_FLOOR) ->
atomic {Etat_Floor[i] = PARTICIPANT_FLOOR ; CHANNEL_FLOOR_COORDINATION ! REJECT_FLOOR ; }
:: (message == GCCF_ASK_FLOOR_PENDING) ->
CHANNEL_FLOOR_COORDINATION ! ASK_FLOOR_PENDING;
fi

: : (Etat_Floor[i] == DETENTEUR_FLOOR ->

CHANNEL_CORDIANTION_FLOOR[I] ? message ;
if :: (message == RELEASE_FLOOR ->
atomic {Etat_Floor[i] = PARTICIPANT_FLOOR ;
CHANNEL_MODERATEUR_PARTICIPANT_FLOOR [I] ! GCCF_RELEASE_FLOOR ;
CHANNEL_FLOOR_MEDIA ! STOP_SEND_MEDIA ;
}

: : (Etat_Floor[i] == DETENTEUR_FLOOR ->

CHANNEL_MODERATEUR_PARTICIPANT_FLOOR[I] ? message ;
if :: (message == GCCF_GRAB_FLOOR ->
atomic {Etat_Floor[i] = PARTICIPANT_FLOOR ;
CHANNEL_PARTICIPANT_MODERATEUR ! GCCF_RELEASE_FLOOR ;
CHANNEL_FLOOR_MEDIA ! STOP_SEND_MEDIA ;
}

fi
…………..
……….
….

Figure II.2.1. Comportement du processus "Contrôle Floor" relatif au simple participant.

104
 A l’état "Participant_Floor", le processus peut demander le floor ("Ask_Floor") ou quitter
la conférence ("Leave"). Ces deux messages sont reçus à travers le
"Channel_Coordination_Floor". Dans le premier cas, il transite à l’état "Attente_Floor". Dans
le deuxième cas, il passe à l’état final. Il peut aussi recevoir (tout en étant à l’état
"Participant_Floor") les messages de terminaison ("GCCF_Terminate") ou de mise à jour de
contexte de floor ("GCCP_Update_FC") à travers le canal
"Channel_Moderateur_Participant_Floor".

A l’état "Attente_Floor", le processus "Contrôle Floor" peut recevoir le floor du

modérateur ("GCCF_Give_Floor"), une notification de rejet de floor ("GCCF_Reject_Floor")
ou une notification de traitement de demande de floor en cours
("GCCF_Ask_Floor_Pending"). Ces messages sont reçus à travers le canal
"Channel_Moderateur_Participant_Floor". Le premier message permet au processus
"Contrôle Floor" le passage à l’état "Detenteur_Floor".

De l’état "Détenteur_Floor", le processus "Gestion Floor" peut retourner à l’état

"Participant_Floor" s’il libère le floor (réception du message "Release_Floor" du processus
"Coordination_GCCF") ou s’il reçoit un message de retrait de floor ("GCCF_Grab_Floor") du
modérateur.

La figure II.2.2 décrit le comportement du processus "Contrôle Floor" relatif à un

modérateur. Lors de la réception d’un message de création ("Create_Conf") à l’état "Init", le
processus "Contrôle Floor" transite à l’état "Moderateur_Floor"). De cet état, ce processus
peut donner le floor (réception de "Give_floor" du processus "Coordination_GCCF" et envoie
de "GCCF_Give_Floor" au participant concerné) et passe à l’état "Attente_Floor". Il diffuse
ensuite le message de mise à jour du contexte de floor à tous les autres participants (diffusion
du message "GCCF_Update_FC"), envoie le message de rejet de demande de floor aux autres
participants ("GCCF_Reject_Floor") et active le temporisateur. Il peut aussi (au même état
"Moderateur_Floor") recevoir un message de création de floor ("Create_Floor") ou de
terminaison de conférence à travers le canal "Channel_Coordination_Floor".

A l’état "Attente_Floor", le processus "Contrôle Floor" peut recevoir des messages de

différents canaux : le message "Timeout" du canal relatif au temporisateur suite à lequel il
envoie une demande de retrait de floor au participant détenteur de floor ou le message de
libération de floor ("GCCF_Release_Floor").

105
/** Suite du processus "Contrôle Floor" realtif à une poltique présidé – Comportement du modérateur **/

:: (Etat_Floor[i] == INIT ) -> CHANNEL_COORDINATION_FLOOR ? message ;

if :: (message == CREATE_CONF) ->
atomic {Etat_Floor[i] = MODERATEUR_FLOOR ; CHANNEL_FLOOR_MEDIA ! SEND_MEDIA ; }

:: (Etat_Floor[i] == MODERATEUR_FLOOR ) -> CHANNEL_ COORDINATION_FLOOR ? message ;

if :: (message == GIVE_FLOOR) ->
atomic
{ CHANNEL_COORDINATION_FLOOR ? IDENT ;
CHANNEL_MODERATEUR_PARTICIPANT [IDENT] ! GCCF_GIVE_FLOOR ;
CHANNEL_FLOOR_MEDIA ! STOP_SEND_MEDIA ;
j=1 ;
do :: (j !=N) -> CHANNEL_MODERATEUR_PARTICIPANT_FLOOR [J] !GCCF_UPDATE_FC
:: (j ==N) -> break ;
od
j=1 ;
do :: (j !=N) and (j !=ident) -> CHANNEL_MODERATEUR_PARTICIPANT_FLOOR [J] ! GCCF_REJECT_FLOOR ;
:: (j ==N) -> break ;
od
UPDATE_FC; CHANNEL_FLOOR_TIMER !ACTIVATE_TIMER ;
}

:: (message == CREATE_FLOOR) ->

atomic { j=1 ;
do :: (j !=N) -> CHANNEL_MODERATEUR_PARTICIPANT_FLOOR [J] !GCCF_UPDATE_FC
:: (j ==N) -> break ; od }

:: (message == ASK_FLOOR_CONTEXT) ->

CHANNEL_FLOOR_COORDINATION ? GIVE_FLOOR_CONTEXT ;

:: (message == TERMINATE) ->

atomic { j=1 ;
do :: (j !=N) -> CHANNEL_MODERATEUR_PARTICIPANT_FLOOR [J] ! TERMINATE ;
:: (j ==N) -> break ; od }

:: (Etat_Floor[i] == MODERATEUR_FLOOR ) -> CHANNEL_ PARTICIPANT_MODERATEUR_FLOOR ? message ;

if :: (message == GCCF_ASK_FLOOR) ->
atomic { CHANNEL_PARTICIPANT_MODERATEUR_FLOOR ? PARTICIPANT;
CHANNEL_FLOOR_COORDINATION ! ASK_FLOOR ;
CHANNEL_MODERATEUR_PARTICIPANT_FLOOR [PARTICIPANT] ! GCCF_ASK_FLOOR_PENDING ; }

:: (Etat_Floor[i] == ATTENTE_FLOOR ) -> CHANNEL_ TIMER_FLOOR ? message ;

if :: (message == TIMEOUT) -> CHANNEL_MODERATEUR_PARTICIPANT [DETENTEUR] ! GCCF_GRAB_LOOR ;

:: (Etat_Floor[i] == ATTENTE_FLOOR ) -> CHANNEL_PARTICIPANT_MODERATEUR_FLOOR [I] ? message ;

if :: (message == GCCF_RELEASE_FLOOR) ->
atomic { j=1 ;
do :: (j !=N) -> CHANNEL_MODERATEUR_PARTICIPANT_FLOOR [J] !GCCF_UPDATE_FC
:: (j ==N) -> break ;
od
CHANNEL_FLOOR_MEDIA ! SEND_MEDIA ; CHANNEL_FLOOR_COORDINATION !RELEASE_FLOOR ;
UPDATE_FC ;
fi
fi

od

Figure II.2.2. Comportement du processus "Contrôle Conférence" relatif au modérateur.

106
 proctype CONTROLE_FLOOR (I)

{ byte message, suivant;

Etat_Floor [i]= INIT ;

do : :
if
: : (Etat_Floor[i] == INIT -> CHANNEL_CORDINATION_FLOOR ? message ;
if : : (message == CREATE_CONF) ->
atomic {Etat_Floor[i] = DETENTEUR_FLOOR ; Detenteur =i ;
CHANNEL_FLOOR_MEDIA ! SEND_MEDIA ; }
: : (message == JOIN) ->
atomic {Etat_Floor[i] = PARTICIPANT_FLOOR ;
j=3
do :: (j>0) -> CHANNEL_FLOOR_ [j]! GCCF_UPDATE_FC(JOIN) ; j=j-1 ; od }
fi

: : (Etat_Floor[i] == PARTICIPANT_FLOOR -> CHANNEL_COORDINATION_FLOOR [I]? message ;

if : : (message == ASK_FLOOR ->
atomic { j=3
do :: (j>0) -> CHANNEL_FLOOR_ [j]! GCCF_ASK_FLOR ; j=j-1 ; od
ETAT_FLOOR[I]=ATTENTE_FLOOR ; }
:: (message == LEAVE -> Etat_Floor[i] = FINAL_FLOOR ;
fi

: : (Etat_Floor[i] == DETENTEUR_FLOOR -> CHANNEL_FLOOR [I]? message;

if : : (message == GCCF_GRAB_FLOOR ->
atomic {Etat_Floor[i] == PARTICIPANT_FLOOR ;
CHANNEL_FLOOR [SUIVANT] ! GIVE_FLOOR ;
CHANNEL_FLOOR_MEDIA [I] ! STOP_SEND_MEDIA ; }
: : (message == GCCF_ASK_FLOOR ->
if :: (dernier =1) -> CHANNEL_FLOOR_MANAGER[I] ! DEMANDEUR ;
suivant=demandeur ;
dernier=0 ;
fi
fi

: : (Etat_Floor[i] == DETENTEUR_FLOOR -> CHANNEL_COORDINATION_FLOOR [I]? message;

if : : (message == RELEASE_FLOOR ->
atomic {Etat_Floor[i] == PARTICIPANT_FLOOR ;
CHANNEL_FLOOR [SUIVANT] ! GIVE_FLOOR ;
CHANNEL_FLOOR_MEDIA [I] ! STOP_SEND_MEDIA ;
fi

: : (Etat_Floor[i] == ATTENTE_FLOOR -> CHANNEL_FLOOR [I]? message ;

if : : (message == GCCF_ASK_FLOOR ->
if :: (dernier=1) -> CHANNEL_FLOOR_MANAGER[I] ! DEMANDEUR ;
suivant=demandeur ;
dernier=0 ;
fi
:: (message == GIVE_FLOOR ->
atomic {Etat_Floor[i] == DETENTEUR_FLOOR ;
CHANNEL_FLOOR [SUIVANT] ! GIVE_FLOOR ;
CHANNEL_FLOOR_MEDIA [I] ! STOP_SEND_MEDIA ;

fi
………
fi
od
}

Figure II.2.3. Comportement du processus "Contrôle Floor" dans une politique explicite.

107
 La figure II.2.3 présente la description Promela du processus "Contrôle Floor" d’un
MMTS régi par la politique explicite. Ce processus peut prendre trois principaux états : l’état
"Participant_Floor", l’état "Détenteur_Floor" et l’état "Attente_Floor". Il échange des
messages avec le processus "Coordination_GCCF" pour exprimer les demandes d’un
participant et avec les processus "Contrôle Floor" homologues pour contrôler la détention du
floor entre les participants. Par exemple, étant à l’état "Participant_Floor" et recevant le
message de demande de floor du processus "Coordination_GCCF" ("Ask_Floor"), le
processus "Contrôle Floor" diffuse le message GCCF de demande de floor à tous les
participants et passe à l’état "Attente_Floor".

2.3.2 Vérification à l’aide de SPIN

SPIN est un outil permettant l’analyse de la consistance de la logique des systèmes

concurrents et plus particulièrement les protocoles de communication. A partir d’une
spécification en Promela, SPIN peut soit exécuter des simulations aléatoires, soit générer un
validateur. Il utilise les outils suivants :

- Un simulateur : qui exécute une simulation aléatoire et affiche un résultat si

l’exécution se termine. Il établit la liste des processus par ordre de création.
L’exécution des actions est non déterministe.

- L’analyseur : permet d’effectuer des parcours des exécutions possibles des

spécifications. Deux techniques sont proposées : la première technique consiste à
explorer de manière exhaustive de toutes les séquences exécutables possibles ; la
deuxième technique analyse l’état de la mémoire qui permet de prévenir un éventuel
dépassement.

- La "supertrace" ou Bit State Space, qui s’applique sur des systèmes de grande taille.
Elle consiste à réduire l’encombrement mémoire en codant la présence d’un état sur un
bit.

Cet outil permet de vérifier des propriétés exprimées en logique temporelle avec un
processus " never" qui permet de spécifier, sur l’ensemble des exécutions, des contraintes
telles que : "toujours", "fatalement", etc.

Nous présentons dans cette section des exemples de déroulement de vérification à l’aide
de l’outil SPIN. Les figures II.2.3 présente la propriété 2 pour la politique présidée. Dans
chaque exécution de vérification, nous commençons par écrire les propositions utilisées par la

108
propriété à l’aide de la macro instruction "#define" dans la partie réservée à la définition des
symboles (Symbol Definition). Nous écrivons ensuite la propriété en question dans la partie
Formula et nous générons l’automate de la propriété (Partie Never Claim) puis nous lançons
le processus de vérification. Le résultat apparaît en bas de la fenêtre.

([] Detenteur_1->!Moderateur_Detenteur && !Detenteur_2 && !Detenteur_3)

Use Load to open a file or template

#define Moderrateur_Detenteur (Etat_Floor[0]= Detenteur_Floor)

#define Detenteur_1 (Etat_Floor[1]= Detenteur_Floor)
#define Detenteur_2 (Etat_Floor[2]= Detenteur_Floor)
#define Detenteur_3 (Etat_Floor[3]= Detenteur_Floor)

/*
* Formula As Typed:
[] (([] Detenteur_1->!Moderateur_Detenteur && !Detenteur_2 && !Detenteur_3) )
* To The Negated Formula []
!(([] Detenteur_1->!Moderateur_Detenteur && !Detenteur_2 && !Detenteur_3) )
* (Formalizing violations of the original)
*/
never { /* !(([] Detenteur_1->!Moderateur_Detenteur && !Detenteur_2 && !Detenteur_3) )*/

Figure II.2.4. Vérification de la propriété d’exclusion mutuelle du floor dans un MMTS présidé.

109
 ([] Detenteur_0->!Detenteur_1 && !Detenteur_2 && !Detenteur_3)

Use Load to open a file or template

#define Detenteur_0 (Etat_Floor[0]= Detenteur_Floor

#define Detenteur_1 (Etat_Floor[1]= Detenteur_Floor)
#define Detenteur_2 (Etat_Floor[2]= Detenteur_Floor)
#define Detenteur_3 (Etat_Floor[3]= Detenteur_Floor)

/*
* Formula As Typed:
[] (([] Detenteur_1->!Detenteur_0 && !Detenteur_2 && !Detenteur_3) )
* To The Negated Formula []
!(([] Detenteur_1->!Detenteur_0 && !Detenteur_2 && !Detenteur_3) )
* (Formalizing violations of the original)
*/
never { /* !(([] Detenteur_1->!Detenteur_0 && !Detenteur_2 && !Detenteur_3) )*/

Figure II.2.5. Vérification de la propriété d’exclusion mutuelle du floor dans un MMTS explicite.

2.4 Conclusion

Dans ce chapitre, nous avons identifié les propriétés que doit respecter un système de
téléconférence (présidé ou explicite). Nous avons ensuite décrit ces propriétés en logique
temporelle linéaire que nous avons vérifiées à l’aide de l’outil Promela/SPIN. Ceci nous a
permis d’obtenir des spécifications cohérentes et vérifiées et qui répondent aux besoins requis.
Ces spécifications vont servir de base pour l’implémentation. Celle-ci passe par
l’identification du mécanisme approprié à la politique utilisée.

110
 Chapitre 3

Mécanismes de réalisation

Le travail de ce chapitre a été réalisé au LIFC de Besançon au cours d’un stage de recherche
dans le cadre du projet STIC. Ce travail a fait l’objet de la publication suivante :

M. Ouzzif, M. Tréhel, "Insertion de Nouveaux Participants à une Conférence sur un Réseau ;

Adaptation d’Algorithmes d’Exclusion Mutuelle Distribués à Jeton", ISIVC2000, Rabat,
2000.

3.1 Introduction

Les protocoles de gestion de conférence et de contrôle de floor se basent sur deux

concepts fondamentaux : les politiques et les mécanismes. Les politiques définissent les règles
d’interaction entre les participants d’une téléconférence. Les mécanismes permettent
l’implémentation de ces politiques. Ces mécanismes reposent généralement sur les techniques
d’exclusion mutuelle et les techniques d’accès multiple. Les algorithmes d’exclusion mutuelle
distribués peuvent assurer de tels aspects. Toutefois, ils sont généralement statiques. Pour
pouvoir les adopter comme mécanismes de contrôle de conférence, il faut les adapter de
manière à supporter l’insertion et la suppression dynamiques des sites participants. Dans ce
chapitre, nous présentons les améliorations que nous apportons à deux algorithmes
d’exclusion mutuelle distribués basés sur le jeton.

Nous commençons par présenter les versions initiales de chaque algorithme (Le Lann et
Naimi-Tréhel) avec les modifications apportées pour le support de l’insertion dynamique
comme première étape. Nous donnons ensuite les modifications concernant le support de la
suppression dynamique.

111
3.2 Algorithmes d’exclusion mutuelle

Les algorithmes d’exclusion mutuelle permettent de gérer l’accès à une section critique
partagée entre plusieurs processus. Dans les systèmes monoprocesseur, l’exclusion mutuelle
est gérée par les sémaphores, les moniteurs ou autres constructeurs de ce type. Dans les
systèmes distribués, l’exclusion mutuelle doit être mise en œuvre à l’aide d’algorithmes
distribués. Ces algorithmes peuvent être classifiés en deux catégories : les algorithmes
d’exclusion mutuelle basés sur la permission et les algorithmes basés sur le jeton.

Dans la famille des algorithmes basés sur la permission [Lamp78, Rica 81, Maek 85], le
droit d’entrer en section critique pour un site donné est assuré par le concept de permission.
Ce droit est représenté par un nombre de permissions devant être accordées par les autres
sites. Une permission est un message échangé entre un site émetteur d’une requête et un site
accordant sa permission à cette requête. Les algorithmes basés sur la permission emploient le
protocole suivant : Pour qu’un site i puisse exécuter sa section critique, il doit d’abord
demander la permission à un ensemble Ei de sites et ne peut exécuter sa permission que s’il a
reçu toutes les permissions attendues. Dans ces d’algorithmes, à tout instant, un seul site peut
exécuter sa section critique et ce, lorsqu’il reçoit un nombre suffisant de permissions des
autres sites. Cette classe d’algorithmes regroupe deux catégories : les algorithmes broadcast,
les algorithmes de type multicast. Les algorithmes de type broadcast se basent sur le fait
qu’un site envoie sa demande de permission à tous les sites impliqués dans l’exclusion
mutuelle. Les algorithmes multicast se basent sur la demande restreinte de la permission.

Les algorithmes basés sur le jeton reposent sur l’unicité de ce jeton. Le site qui détient le
jeton exécute sa section critique. Dans cette catégorie, les différents algorithmes se
distinguent par la manière dont le jeton circule entre les demandeurs. Le premier algorithme
basé sur le jeton a été élaboré par Le Lann [Lann 77]. Dans cet algorithme un jeton unique
circule d'un site à l’autre. L’ensemble des sites forme un anneau logique. Suziki et Kasami
[Suzu 85] transforment l’algorithme de Ricart et Agrawela basé sur la permission en un
algorithme basé sur le jeton. Dans l’algorithme Ricart et Agrawela, la permission est
confirmée par le message reply. Ce message joue le rôle de jeton dans l’algorithme de Suziki
et Kasami et est doté d’une file d’attente composée des sites demandeurs du jeton. Makki
[Makk 94] propose une approche similaire à celle d’une file d’attente du jeton, dans laquelle
chaque site envoie sa requête au possesseur du jeton au lieu de l’envoyer à tous les sites du
système. Ceci permet de réduire le coût de communication. L’algorithme de Singhal [Sing 89]

112
emploie une heuristique afin de deviner quel est le site du système qui possède le jeton ou les
sites qui sont susceptibles de l’avoir. Ceci permet de réduire le coût de communication.
L’algorithme Naimi et Tréhel [Naim 87] organise les sites du système en une structure
arborescente (logique) et dynamique et permet une meilleure performance de l’ordre de O(log
(N)) messages par exécution de section critique.

3.3 Insertion dynamique de sites dans des algorithmes à jeton

Les algorithmes d’exclusion mutuelle distribués supposent que le groupe de sites ne peut
pas évoluer dans le temps. Or, pour pouvoir adopter de tels algorithmes comme mécanismes
de contrôle de floor, il faut pouvoir insérer et retirer dynamiquement des sites relatifs à des
participants. Cette section décrit l’insertion de nouveaux participants dans deux algorithmes
d’exclusion mutuelle distribués fondés sur le concept du jeton. Ces algorithmes nous ont
parus plus pratiques à adapter aux modifications de la liste des participants [Ouzz 00b]. Une
solution simple consiste à arrêter l’activité du groupe et de modifier statiquement la liste des
sites. Nous avons rejeté cette idée et nous avons opté pour une insertion dynamique des sites.
Pour chaque algorithme, nous décrivons dans un premier temps la stratégie d’insertion de
manière informelle puis nous donnons l’algorithme correspondant à cette stratégie.

3.3.1 Adaptation de l’algorithme Le Lann pour l’insertion dynamique

Nous adoptons deux hypothèses principales pour les algorithmes d’exclusion mutuelle
distribués basés sur le jeton (en particulier Le Lann). Ces hypothèses concernent la
communication et la section critique. Pour la communication entre les sites, nous supposons
qu’il n y a ni duplication, ni modification, ni perte de messages. En ce qui concerne la section
critique, nous supposons qu’un site qui entre en section critique en sort au bout d’un temps
fini.

3.3.1.1 Algorithme initial Le Lann

L’algorithme Le Lann est le premier algorithme basé sur le jeton [Lann 77]. Dans cet
algorithme, les sites d’un système sont organisés sous forme d’un anneau logique dans lequel
un jeton unique circule séquentiellement d’un site à un autre. Lorsque le jeton visite un site,
deux cas se présentent : soit que le jeton est retenu par ce site pour marquer l’utilisation de la
section critique ; soit que le jeton est renvoyé immédiatement par ce site (qui n’utilise donc
pas la section critique) à son successeur dans l’anneau. Le jeton circule de manière continue

113
entre les sites même s’il n y a aucune demande. La figure II.3.1 décrit l’algorithme tel qu’il
est présenté par Le Lann. Il consiste en trois instructions : l’attente du jeton, l’entrée en
section critique si la variable requête est mise à vrai et l’envoi du jeton au successeur.

Attendre (jeton)
Si requête Alors
<Section Critique>
Fsi
Envoyer (jeton)

Figure II.3.1. Algorithme Le Lann.

Quand un site veut entrer en section critique, il met une variable requête à vrai. Quand il
obtient le jeton, il entre en section critique si requête est vrai. Sinon, il passe le jeton au
suivant.

3.3.1.2 Algorithme Le Lann avec insertion de nouveaux nœuds

a. Présentation informelle

Nous supposons que lorsqu’un processus Pi veut joindre l’anneau, il choisit un processus
Pj déjà existant et émet la demande d’entrée vers Pj. A la réception de cette demande, Pj ajoute
le processus à sa file de demandeurs. L’idée de l’algorithme est qu’un processus ne peut
insérer les nouveaux arrivés que lorsqu’il détient le jeton. Ceci permet de ne pas insérer un
nouveau site plusieurs fois. Après avoir réalisé cette opération, il peut entrer ou non en section
critique et remet par la suite le jeton à son successeur. Supposons que l’anneau soit formé des
processus P1, P2, …, Pi-1, Pi , Pi +1, …, Pn : Pi-1 est le prédécesseur de Pi, Pi+1 est le successeur
de Pi. Nous supposons aussi que, avant la réception du jeton, Pi peut recevoir un certain
nombre de demandes d’entrées de la part de Pe1, Pe2 , …, Pem (figure II.3.2).

Une fois que Pi reçoit le jeton de la part de Pi-1, il insère les nouveaux arrivés un par un. Il
retire ainsi Pe1 de la file, envoie le message (Change_Successeur, Pe1), à Pi-1 et attend
l’acquittement (Ack). En recevant le message (Change_Successeur, Pe1), Pi-1 modifie son
successeur qui devient Pe1 et envoie l’acquittement (Ack) à Pi. Ce dernier envoie par la suite
le message (Init_Pred-Succ, Pi-1, self) à Pe1, lui indiquant d’initialiser son prédécesseur à Pi-1
et son successeur à Pi (self), puis attend l’acquittement. Lorsque Pi reçoit l’acquittement, il
modifie son prédécesseur par Pe1. Cette opération va être réitérée jusqu’à ce que la file soit
vide. Après avoir fini l’opération d’insertion, le processus détenteur du jeton entre en section
critique s’il le désire, puis envoie le jeton à son successeur.

114
 P3
.........
Pi-1

(1)
P2 (2)

Pi .........

P1 Pe1 Pe2 Pm
(3)

Pn Pi+1
.........

Figure II.3.2. Insertion de nouveaux participants dans l’anneau Le Lann.

b. Algorithme Le Lann modifié

La figure II.3.3 présente l’algorithme Le Lann permettant d’insérer dynamiquement des

sites. Quand un processus Pi reçoit le jeton, il commence par insérer les éléments de sa file
dans l’anneau. Ceci consiste à retirer à chaque fois un élément de la file, envoyer un message
de changement de successeur à son prédécesseur, envoyer un message de mise à jour du
prédécesseur et du successeur de l’élément retiré et le considérer ensuite comme son nouveau
prédécesseur. Une fois cette opération réalisée pour tous les éléments de la file, le processus
entre en section critique et envoie le jeton au successeur.

Processus Le Lann modifié pour insertion dynamique de site

Debut
Attendre (jeton) du predecesseur ;
Tant_que (file non vide) Faire
nouveau_element := Retirer(tete_file, file) ;
Envoie (Change_Successeur , nouveau_element) à predecesseur ;
Tant_que (non (ack_recu)) Faire rien F_tant_que ;
ack_recu :=faux ;
Envoie (Init_Pred_Succ, predecesseur, self) à nouveau_element ;
Tant_que ( not (ack_recu)) Faire rien F_tant_que;
ack_recu :=faux ;
predecesseur := nouveau_element ;
F_tant_que;
Si requete Alors
<SECTION CRITIQUE> ;
Fsi
Envoie jeton à successeur ;
Fin.

Figure II.3.3. Insertion de nouveaux participants dans l’algorithme Le Lann.

La figure II.3.4 présente la procédure d’écoute et de traitement de message. Cette

procédure peut être considérée comme un sous processus qui s’exécute en permanence sur
chaque site. Elle peut recevoir quatre types de message : le message "Change_Successeur", le
message "Ack", et le message "Init_Pred_Succ". Le message "Change_Successeur" permet de

115
mettre à jour le successeur du processus ayant reçu ce message au paramètre "succ". Le
message d’acquittement "Ack" qui dénote un acquittement attendu, permet de continuer
l’exécution du processus en attente de cet acquittement. Le message "Init_Pred_Succ" qui
permet d’initialiser les variables prédécesseur et successeur d’un nouveau élément inséré au
paramètre "pred" et "succ". Le message de jointure "joindre" permet à un processus de joindre
le groupe des processus de l’algorithme. Le processus ayant reçu ce message ajoute
l’identificateur du processus voulant joindre le groupe à sa file.

Procédure de traitement du message reçu

Debut
Cas message_recu
(Change_Successeur, succ) : Debut
successeur :=succ ; Envoie (Ack) à emetteur ;
Fin
(Ack ) : ack_recu :=vrai ;
(Init_Pred_Succ, pred, succ) : Debut
successeur :=succ ; predecesseur := pred ;
Envoie (Ack) à emetteur ;
Fin
(Joindre, ident) : Ajout_Element_File (file, ident) ;
F_cas
Fin.

Figure II.3.4. Traitement des messages relatifs à l’insertion de nouveaux participants dans l’algorithme Le Lann.

Du point de vue performance en terme de nombre de messages, cet algorithme en

nécessite trois pour chaque insertion d’un nouveau participant.

3.3.2 Adaptation de l’algorithme Naimi-Tréhel pour l’insertion dynamique

3.3.2.1 Algorithme initial Naimi-Tréhel

Bien qu’il s’agisse encore d’un algorithme à jeton, la structure de données utilisée est
totalement différente de celle de l’algorithme de Le Lann qui fonctionne sur un anneau.
L’algorithme de Naimi-Tréhel structure l’ensemble des sites en une arborescence dynamique.
Une requête est acheminée le long des arcs, du demandeur de la section critique vers la racine.
Le site qui est à la racine accepte la requête s’il n’y a personne en attente ou la met en attente.
Le nombre moyen de messages est considérablement réduit et est de l’ordre Log(n) [Naim
96].

a. Principe

Comme pour les autres algorithmes, on suppose que le réseau est complet et qu’il n’y a
pas d’erreurs sur les messages. Les sites sont structurés en arborescence virtuelle. Chaque site

116
connaît son père dans l’arborescence. Une demande d’entrée en section critique de la part
d’un site non racine, est transmise de père en père, et arrive finalement à la racine. Ce site
racine peut être dans une des 3 situations :

- Il possède le jeton mais ne l’utilise pas. Dans ce cas, il envoie son "OK" au demandeur
qui pourra entrer en section critique.

- Il possède le jeton et l’utilise : le site demandeur est mis en attente.

- Il est en attente du jeton, propriété d’un autre site. Le site demandeur est aussi mis en
attente.

Les sites qui font une demande d’entrée en section critique sont structurés en une file
d’attente virtuelle distribuée. Chaque site connaît son suivant dans cette file. Le premier
élément de la file possède le jeton. Quand un site sort de la section critique, il transmet le
jeton à son suivant dans la file (s’il y en a un).

Quand les messages de requête ou de "OK" sont en transit, l’arborescence Naimi-Tréhel et

la file d’attente des demandeurs sont détruites. Elles se reconstruisent différemment quand les
messages arrivent à leurs destinataires. Le demandeur devient la nouvelle racine et le père des
sites situés sur le parcours du demandeur à l’ancienne racine, devient le demandeur lui même.

b. Exemple

Nous présentons l’algorithme Naimi-Tréhel à travers un exemple dans un premier temps,

puis nous donnons ensuite son code. Dans cet algorithme, chaque site possède quatre
variables : "père", "suivant", "jeton", "demande". La variable "père" précise le père d’un site
dans l’arborescence (= nil à la racine). La variable "suivant" représente le suivant dans la file
des demandeurs (= nil s’il n’y en a pas). La variable "jeton" est vrai pour le site qui est en tête
de la file des demandeurs (c’est la racine si la file est vide). La variable "demande" est vraie
pour les sites qui ont demandé la section critique. L’exemple présenté ci-dessous se déroule
en cinq situations.

- Première situation : situation initiale

Le site 1 dispose du jeton. Le père de chaque site est le site 1. Personne n’a encore
demandé le jeton (figure II.3.5).

117
 1 1 2 3 4 5
pere nil 1 1 1 1

suivant nil nil nil nil nil

2 3 4 5 jeton V F F F F

demande F F F F F

Figure II.3.5. Situation initiale.

- Deuxième situation : le site 2 demande à entrer en section critique

Le site 2 met sa variable "demande" à vrai. Il n’est pas racine et transmet alors sa
demande à son père. Il devient ainsi racine et attend le jeton avant d’entrer en section critique.
Quand le site 1 reçoit la requête émise par le site 2, il met la variable "jeton" à faux, répond
"OK" au site 2 et modifie la variable "père" qu’il met à la valeur 2. Ceci est dû au fait qu’il
possède le jeton et qu’il n’a pas fait de demande pour entrer en section critique. Quand le site
2 reçoit le message "OK", il met sa variable "jeton" à vrai. Il peut alors entrer en section
critique (figure II.3.6).

2 1 2 3 4 5
pere 2 nil 1 1 1

suivant nil nil nil nil nil

1 jeton F V F F F

demande F V F F F

3 4 5

Figure II.3.6. Demande de la section critique par le site 2.

- Situation 3 : le site 3 demande à entrer en section critique

Le site 3 met sa variable "demande" à vrai. Il n’est pas racine et transmet alors sa
demande à son père, qui est le site 1. Il devient ainsi racine et attend le jeton avant d’entrer en
section critique. A ce stade, l’arborescence est détruite puisque les sites 2 et 3 sont tous deux
racines. Elle va se reconstruire à l’arrivée des messages en transit. Quand le site 1 reçoit la
requête du site 3, il envoie la requête à son père qui est le site 2, puis modifie sa variable
"père" qui prend comme valeur l’identificateur du demandeur.

Quand le site 2 reçoit la requête du site 3, il ne lui cède pas le jeton puisqu’il a une
demande en cours (il est en section critique). Il met alors le site 3 comme son suivant dans la
file. Ce qui signifie qu’il devra donner le jeton au site 3 quand il quittera la section critique.
Sa variable "père" prend comme valeur l’identificateur demandeur (figure II.3.7).

118
 3 1 2 3 4 5
pere 3 3 nil 1 1

suivant nil 3 nil nil nil

2 1 jeton F V F F F

demande F V V F F

4 5

Figure II.3.7. Demande de la section critique par le site 3.

- Situation 4 : le site 4 demande à entrer en section critique

Le site 4 met sa variable "demande" à vrai. Il n’est pas racine et transmet alors sa
demande à son père, qui est le site 1. Il devient racine et attend le jeton avant d’entrer en
section critique. A ce stade, l’arborescence est détruite puisque les sites 4 et 3 sont tous deux
racines. Elle va se reconstruire à l’arrivée des messages en transit. Quand le site 1 reçoit la
requête émise par le site 4, il envoie la requête à son père qui est le site 3, puis modifie sa
variable "père" qui prend comme valeur l’identificateur du demandeur.

Quand le site 3 reçoit la requête du site 4, il met le site 4 comme son suivant dans la file
(puisqu’il n’a pas le jeton). Ceci signifie qu’il devra donner le privilège au site 4 quand il
quittera la section critique (qu’il n’a pas encore). Sa variable "père" prend comme valeur
l’identificateur du demandeur.

4 1 2 3 4 5
pere 4 3 4 nil 1

suivant nil 3 4 nil nil

3 1 jeton F V F F F

demande F V V V F

2 5

Figure II.3.8. Demande de la section critique par le site 4.

- Situation 5 : le site 2 quitte la section critique

Le site 2 met sa variable "demande" à faux. Il perd le jeton, envoie le message "OK" à son
suivant (site 3) dans la file. Quand le site 3 reçoit le message "OK", il met sa variable "jeton"
à vrai, et rentre en section critique (figure II.3.9).

119
 4 1 2 3 4 5
pere 4 3 4 nil 1

suivant nil nil 4 nil nil

3 1 jeton F F V F F

demande F F V V F

2 5

Figure II.3.9. Libération de la section critique par le site 2.

c. Algorithme
L’algorithme Naimi-Tréhel (figure II.3.10) consiste en quatre procédures. La première
procédure permet l’initialisation des différentes variables de l’algorithme. La deuxième
procédure concerne la demande de la section critique. Celle ci consiste à mettre la variable
demande à vrai et de retransmettre la demande au père.

Const N = … ; moi= … ;
Type mess = (req, ok) ; site= 1..N  {nil} ;
Var pere, suivant : site ; jeton, demande : booléen ;

Procedure Initialisation
Dedut
pere := ; (la valeur est la même pour chaque site autre que la racine et vaut nil à la racine)
suivant :=nil ;
jeton := (pere = nil) (vrai pour la racine, faux sinon)
demande := faux
FIN
Procedure Demander_Section_Critique Procedure Liberer_Section_Critique
Debut Debut
demande :=vrai ; demande :=faux ;
Si (pere <> nil) Alors Si (suivant<>nil) Alors
Envoie (req, moi) à père Envoie (ok, moi) à suivant
pere :=nil suivant :=nil ;
Fsi jeton :=faux
Fin Fsi
Fin
Procedure Traitement_Message(message : mess, demandeur : site)
Debut
Cas message
req :
Si pere = nil Alors
Si demande Alors suivant :=demandeur
Sinon jeton :=faux ;
Envoie (ok, demandeur) à demandeur
Fsi
Sinon Envoie (req, demandeur) à pere
Fsi ;
pere :=demandeur
ok : jeton :=vrai
Fin

Figure II.3.10. Algorithme Naimi-Tréhel.

120
 La troisième procédure permet de libérer la section critique. Elle remet les variables
demande et jeton à faux et envoie le message "OK" au suivant de la liste de sites en attente du
jeton. La quatrième procédure permet de traiter les messages "REQ" et "OK". Le traitement
du message "REQ" par un site racine en section critique consiste à mettre le site émetteur en
file d’attente en le considérant comme son suivant. Un site racine qui n’utilise pas la section
critique passe le jeton au site demandeur (Envoie("OK", demandeur)). Un site non racine se
contente de transférer le message "REQ" à son père dans l’arborescence. Le traitement du
message "OK" représente l’acquisition du jeton (matérialisé par jeton=vrai) par le récepteur
qui entre de ce fait en section critique.

3.3.2.2 Algorithme Naimi-Tréhel avec insertion de nouveaux nœuds

a. présentation informelle

Lorsqu’un nouveau site désire joindre l’ensemble des sites de l’arborescence Naimi-Téhel,
il diffuse un message de jointure à tous les sites. Seul le site Pi qui dispose du jeton le prend
en compte. Tant qu’il dispose de ce jeton, il continue à insérer les nouveaux arrivés en les
prenant comme fils dans l’arborescence. Une fois que Pi sort de la section critique, il envoie le
jeton à un site Pj et met sa variable "jeton" à faux.

Pj
(1) envoi du jeton
(2) Envoi de l'acquittement de
réception du jeton
(3) Envoi de la liste des sites
stockés

(1)
Pi (2)

(3)

Figure II.3.11. Insertion de nouveaux sites dans l’arborescence Naimi-Tréhel.

Le problème qui se pose est que, entre l’instant où le jeton est envoyé par P i et l’instant où
le jeton est reçu par Pj, aucun site de l’arborescence ne dispose du jeton et les nouveaux
arrivés ne peuvent pas être insérés. Il est alors logique que Pi les stocke provisoirement. Ceci
impose que Pi soit connu. Cela se fait par l’introduction d’une variable "jeton_envoyé" qui
sera vrai entre le moment de l’envoi et le moment de l’acquittement de l’envoi. Une fois qu’il
reçoit l’acquittement, il arrête de stocker les nouveaux arrivés et envoie la liste stockée à P j. Pj
aura sans doute déjà inséré certains éléments de cette liste, il n’insérera donc que ceux qu’il

121
n’as pas encore inséré. La figure II.3.11 donne une idée de ce problème. Le site Pi détient le
jeton et le site Pj attend le jeton.

Dans un premier temps, le processus Pi disposant du jeton, peut recevoir des demandes de
jointure de la part des processus Pe1, …, Pen. Ces derniers seront insérés par Pi dans
l’arborescence, et mémorisés dans une liste "Liste_Sites_Inseres". N’ayant plus le jeton (jeton
envoyé), il mémorise les nouveaux arrivés, Pen+1, …, Pek, …, Pel dans une liste
"Liste_Sites_Stockes". En recevant le jeton, Pj envoie un acquittement à Pi et commence à
insérer les nouveaux arrivés Pek, … , Pel, …, Pem tout en les mémorisant dans sa liste
"Liste_Sites_Inseres". Pi lui envoie sa liste "Liste_Sites_Stockes" après la réception de
l’acquittement envoyé par Pj. En recevant la liste des sites stockés envoyée par Pi, Pj ôte les
sites de cette liste de sa liste des sites insérés et insère le reste des sites dans l’arborescence.

b. Algorithme

En plus des variables utilisées dans l’algorithme Naimi-Tréhel, on fera usage des variables
suivantes :

- "Jeton_Envoye" : variable booléenne mise à vrai après l’envoi du jeton et qui reste à vrai
jusqu’au moment où on va autoriser le destinataire à transmettre à son tour le jeton.
- "Liste_Sites_Stockes" : c’est l’ensemble des nouveaux arrivés qui sont mémorisés par un
site juste après l’envoi du jeton.
- "Listes_Sites_Inseres" : c’est l’ensemble des nouveaux arrivés qui sont insérés par un site
disposant du jeton.
- "Autorisation" : cette variable mise à vrai traduit le fait qu’il ne sert plus à rien de savoir
qui est l’émetteur du jeton à Pj (ce site émetteur a mis "Jeton_Envoye" à faux) et par
conséquent, Pj est autorisé à envoyer le jeton à un autre site.

On fera aussi usage des messages suivants :

- (Ack) : message envoyé par un site pour accuser la réception.

- (Inserer, L) : message envoyé par un site i à un site j pour lui demander d’insérer les sites
en les considérant comme ses fils.
- (Joindre, Element) : message envoyé par un nouveau site (element) pour joindre
l’ensemble des sites.
- (Initialiser_Pere, Element) : message envoyé par un site i à un site j pour lui demander
d’initialiser son père à "element".

122
 Les figures II.3.12 et II.3.13 décrivent le code de l’algorithme permettant l’insertion
dynamique des sites dans l’arborescence Naimi-Tréhel. La première figure présente la partie
initialisation de l’algorithme et la procédure de libération de la section critique modifiée. Dans
cette procédure, nous ajoutons trois instructions. La première instruction remet la variable
"autorisation" à sa valeur initiale (faux) étant donnée que le site en question était autorisé à
envoyer le jeton et qu’il a consommé cette autorisation. La deuxième instruction remet la liste
"Liste_Sites_Stockes" à vide et la troisième instruction remet la variable "Jeton_Envoye" à
vrai. Ces deux instructions permettent au site de garder les nouveaux arrivés tant que l’accusé
de réception du jeton n’est pas reçu.

Const N = … ; moi= … ;
Type mess = (req, ok, inserer, ack, initialiser_pere, joindre) ;
site= 1..N  {nil} ;
liste_sites : liste de sites ;
Var pere, suivant : site ; jeton, demande, jeton_envoye, autorisation : booléen ;
liste_sites_inseres, liste_sites_stockes : liste_sites ;

Procedure Initialisation
Debut
pere := … ; (la valeur de père est la même pour chaque site autre que la racine et vaut nil à la racine)
suivant :=nil ;
Si pere = nil Alors jeton := vrai ; autorisation :=vrai ;
Sinon jeton :=faux ; autorisation :=faux ;
Fsi
jeton_envoye :=faux ;
liste_sites_stockes :=vide ;
liste_sites_inseres :=vide ;
Fin

Procedure Liberer_Section_Critique
Debut
demande:=faux;
Tant_que (non(autorisation)) faire rien F_Tant_que
Si ((suivant = nil) et autorisation) Alors
autorisation :=faux ;
Envoie (ok, moi) à suivant ;
suivant := nil ;
jeton :=faux ;
liste_sites_stockes :=vide ;
jeton_envoye :=vrai ;
Fin

Figure II.3.12. Insertion de nouveaux sites dans l’algorithme Naimi-Tréhel.

La figure II.3.13 présente la procédure de traitement des messages reçus par un site dans
cet algorithme. Nous présentons les modifications apportées au traitement de chaque message
de l’algorithme Naimi-Tréhel initial ainsi que le traitement des messages introduits par la
gestion de l’insertion dynamique :

123
- La réception du message "OK" entraîne l’envoi de l’accusé de réception (Ack) à
l’émetteur de ce message et la remise de la lite des sites insérés ("Liste_Sites_Inseres") à
vide pour qu’il puisse y mettre les nouveaux arrivés après réception du jeton.
- A la réception de l’accusé (Ack), le site en question met sa variable "Jeton_Envoye" à
faux pour qu’il arrête la mémorisation des sites au cours de la période de transmission du
jeton. Il envoie ensuite la liste de ces sites mémorisés ("Liste_Sites_Stockes") au nouveau
site détenteur du jeton et la remet à vide pour une éventuelle utilisation.
- La réception du message d’insertion "Inserer" permet au site en question d’insérer les sites
reçus en paramètre en les considérant comme ses fils (insertion sans redondance).
- La réception du message "Joindre" permet au site récepteur d’ajouter le site reçu en
paramètre à sa liste "Liste_Sites_Inseres" s’il dispose du jeton et de le garder dans la liste
des sites stockés s’il ne le possède pas.
- La réception du message "Initialiser_Pere" permet au site récepteur d’initialiser sa
variable "Pere" au paramètre reçu.

Procedure Traiter_Message (message : mess, element :site, liste : liste_sites )

Debut
Cas message
req : …

ok : debut
jeton := vrai ;
Envoie (Ack,moi, []) à element ;
liste_sites_inseres :=vide ;
fin ;
ack : debut
jeton_envoye :=faux ;
l :=liste_sites_stockes ;
Envoie(inserer, moi, L) ;
liste_sites_stockes :=vide ;
fin
inserer : debut
autorisation :=vrai ;
pour_tout element de (L – liste_sites_inseres) faire
Envoie(initialiser_pere, self, []) à element ;
joindre_element : debut
Si jeton Alors liste_sites_inseres :=liste_sites_inseres  {element} ;
Envoie(initialiser_pere, self, []) à element ;
Si jeton_envoye Alors
liste_sites_stockes :=liste_sites_stockes  {element} ;
Fsi
Fsi
initialiser_pere : pere :=element ;
Fin

Figure II.3.13. Traitement des messages relatifs à l’insertion dans l’algorithme Naimi-Tréhel.

124
 c . Eléments de preuve

Exclusion mutuelle
Il n’y a pas de changement puisque, au plus un site a le jeton et il faut le jeton pour entrer
en section critique.
Vivacité
Il s’agit de montrer qu’un site qui veut entrer en section critique y entre au bout d’un
temps fini. Il n’y a aucun changement puisque notre travail a consisté à insérer les nouveaux
arrivés mais seulement quand un site a obtenu le jeton. Notre travail n’a aucunement modifié
l’obtention du jeton.
Insertion

Il s’agit de montrer qu’un site qui veut entrer dans la liste des participants va y entrer une
fois et une seule au bout d’un temps fini.

Lemme 1 : Au plus un site a la variable "Jeton_Envoye" à vrai.

Preuve :
Premier cas :
La demande d’entrée du participant Pe arrive au site Pj qui possède le jeton. Pj insère
alors le nouveau participant Pe dans l’arborescence avec Père(Pe)=Pj. il faut vérifier que
Pe ne va pas entrer plusieurs fois. Or le seul autre site qui peut prendre en compte
l’insertion est le site Pi qui a envoyé le jeton à Pj.
Cas 1.1 La demande d’insertion de Pe arrive après que Pi ait reçu l’Accusé ("Ack")
de Pj. Il n’y a aucun problème dans ce cas et Pi ignore la demande de Pe.
Cas 1.2 La demande de Pe arrive à Pi avant que Pi ait reçu l’accusé de Pj . Dans ce
cas Pi met Pe dans la liste des sites stockés : "Liste_Sites_Stockes".
Quand Pi reçoit l’accusé de Pj, il envoie à Pj la liste "Liste_Sites_Stockes". Puisque
Pe a été inséré par Pj, il se trouve aussi dans la liste "Liste_Sites_Inseres". Or Pj
insère les nouveaux arrivés qui se trouvent dans la liste "Liste_Sites_Stockes" moins
"Liste_Sites_Iinseres". Il n’insère donc pas deux fois Pe et personne d’autre que lui
ne l’insère.
Deuxième cas:
Aucun site ne possède le jeton. Notre algorithme fait alors entrer Pe dans la liste des sites
"Liste_Sites_Stockes" du site Pi qui était le dernier à posséder le jeton. Au bout d’un
temps fini, Pj reçoit le jeton et envoie l’accusé à Pi. Pi transmet alors la liste
"Liste_Sites_Stockes" à Pj qui va mettre les éléments de ("Liste_Sites_Stockes" moins

125
 "Liste_Sites_Inseres") dans la liste des participants. Pe n’étant pas dans la liste des sites
insérés, il va être inséré une fois et une seule fois.

d . Performances

Dans l’algorithme Naimi-Tréhel modifié, pour chaque insertion d’un nouveau site, il faut
n+2 messages (au pire des cas) : n messages diffusés par le nouveau site, un message
autorisation, et un message "Initialiser_Pere" reçu par le nouveau site.

On adopte la stratégie dans laquelle un site enregistre la demande et le premier qui obtient
le jeton réalise l’insertion et demande aux autres sites de ne pas prendre en compte son
insertion. Cela va nous permettre d’éviter le dialogue entre le prédécesseur et le site qui a le
jeton. Toutefois, cette stratégie s’avère plus coûteuse en nombre de messages et nécessite plus
de synchronisations.

3.4 Suppression dynamique de sites dans des algorithmes à jeton

3.4.1 Suppression dans l’algorithme Le Lann

a. Présentation informelle

Nous adoptons la même idée qu’on a considérée pour l’insertion dynamique de nouveaux
nœuds. Un processus désirant quitter le groupe de nœuds dans l’algorithme Le Lann doit
attendre tout d’abord la réception du jeton. En effet, un processus ne peut quitter l’anneau
qu’après avoir inséré les nœuds stockés dans la file.

P3
......... (1)
Pi-1

P2

Pi .........

P1 Pe1 Pe2 Pem

(2)

Pn Pi+1
......... (3)

Figure II.3.14. Suppression de sites de l’anneau Le Lann.

La figure II.3.14 montre la suppression du processus Pi de l’anneau. Nous supposons que

Pi a reçu des demandes d’entrées de la part de Pe1, Pe2 , …, Pem, avant la réception du jeton.
Quand Pi reçoit le jeton de la part de Pi-1, il insère les nouveaux arrivés ayant été stockés dans

126
la file, un par un (le dernier élément inséré est Pem). Une fois cette étape terminée, il met à
jour le successeur du dernier élément inséré en lui attribuant l’identificateur de P i+1 et le
prédécesseur de Pi+1 qui devient Pem.

b. Algorithme Le Lann modifié pour la suppression dynamique

La figure II.3.15 présente la procédure de départ que nous proposons pour que
l’algorithme Le Lann puisse supprimer dynamiquement des sites de l’anneau. Quand un
processus Pi reçoit le jeton, il commence par insérer les éléments de sa file dans l’anneau. Une
fois cette étape terminée, il procède au changement du successeur de son prédécesseur par son
successeur et du prédécesseur de son successeur par le dernier élément inséré de la file.

Procedure Quitter ()
Debut
Attendre (jeton) de predecesseur ;
Tant_que (file non vide) faire
nouveau_element := Retirer(tete_file, file) ;
Envoie (Change_Successeur , nouveau_element) à predecesseur ;
Tant_que (not (ack_recu)) Faire rien F_Tant_que
ack_recu :=faux ;
Envoie (Init_Pred_Succ, predecesseur, self) à nouveau_element ;
Tant_que not (ack_recu) Faire rien F_Tant_que;
ack_recu :=faux ; predecesseur := nouveau_element ;
F_Tant_que
Envoie (Changer_Successeur, successeur) à predecesseur ;
Tant_que (not (ack_recu)) Faire rien F_Tant_que
ack_recu :=faux ;
Envoie (Changer_Predecesseur, predecesseur) à successeur ;
Tant_que (not (ack_recu)) Faire rien F_Tant_que
ack_recu :=faux ;
Envoie jeton à successeur ;
Fin.
Figure II.3.15. Suppression de sites dans l’algorithme Le Lann.

Procedure Traiter_message
Debut
Cas message_recu
(change_successeur, succ) : Debut
successeur :=succ ;
Envoie (ack) à emetteur ;
Fin ;
ack : ack_recu :=vrai ;
(init_pred_succ, pred, succ) : Debut
successeur :=succ ;
predecesseur := pred ;
Envoie (ack) à emetteur ;
Fin
(joindre, ident) faire ajout_element_file (file, ident) ;
Fin_Cas
Fin.

Figure II.3.16. Traitement des messages relatifs à la suppression dans l’algorithme Le Lann..

127
 La figure II.3.16 décrit le traitement des messages pour le support de la suppression
dynamique d’un site dans l’algorithme Le Lann. Nous ajoutons le traitement du message
"Changer_Predecesseur" qui permet de changer le prédécesseur du site récepteur de ce
message par le nouveau prédécesseur reçu en paramètre.

3.4.2 Suppression dans l’algorithme Naimi-Tréhel

3.4.2.1. Présentation informelle

Rappelons que la structure de l’organisation des sites de l’algorithme d’exclusion mutuelle

distribué Naimi-Tréhel, est une structure arborescente. Chaque nœud (à part la racine)
possède un père, éventuellement des fils et un suivant. Le départ d’un site sans procédure
préalable (à l’improvise) peut entraîner des situations de blocage au niveau d’un sous-groupe
de sites ou de l’ensemble de l’arborescence. La figure II.3.17 montre un exemple de situation
de blocage du sous-groupe constitué des sites P2, P3 et P4 et, P5, qui devient isolé de
l’arborescence. En effet, ces sites ne peuvent plus faire partie de la liste des demandeurs du
jeton du fait que leurs demandes (REQ) ne peuvent pas atteindre la destination (le site P1) et
être acheminées vers la racine.

Racine Racine

P1 Départ P1

P2 P3 P2 P3

P4 4 5 P5 P4 4 5 P5

Figure II.3.17. Isolement d’un sous-groupe.

La figure II.3.18 montre une deuxième situation de blocage où l’ensemble des sites de
l’arborescence est bloqué. C’est le cas ou le site P7 quitte le groupe. En effet, lorsque le site
P8 libère le jeton, il envoie le message de libération "Ok" qui n’atteint pas la destination (son
suivant : P7). En d’autres termes, le jeton échangé entre les sites de l’arborescence est perdu.
De ce fait, le départ d’un site doit suivre une procédure et doit se faire en consentement avec
les autres sites.

128
 Une des solutions envisageables pour éviter ce type de situations est de gérer un départ
(ou plusieurs) comme une décision collective entre les sites. Ceci suppose que ce changement
se fait périodiquement et nécessite un arrêt momentané de l’activité des sites (envoie de
messages de demandes, de libération ou d’exécution de section critique). La décision peut être
par exemple le résultat de vote entre les sites pour accepter ou refuser le changement de
configuration [Vill 03]. L’activité des sites reprend dès que la configuration est modifiée et
considérée comme configuration valable. Nous estimons que cette solution est statique.

Racine

P1 P6

P7 Départ

P2 P3

P8

P4 P5

Figure II.3.18. Blocage de l’ensemble des sites.

La solution que nous considérons est plutôt une solution dynamique et consiste à changer
la configuration de l’arborescence chaque fois que cela est possible. La décision de départ
n’est pas dans ce cas une décision collective mais individuelle. Quand un site veut quitter le
groupe, il envoie un message de départ ("Quitter") à tous les sites de l’arborescence. Seuls les
sites fils de l’émetteur traitent ce message et changent leur information père par le nouveau
père reçu en paramètre (père de l’émetteur). Toutefois, si le père du site quittant le groupe,
veut lui aussi quitter le groupe, ceci peut entraîner une configuration non valide. Dans la
figure II.3.19, si le site Pi et le site Pi-1 expriment le besoin de quitter le groupe, ils diffusent le
message de départ ("Quitter"). Etant donnée qu’on ne peut pas assurer l’ordre de la réception
des messages, deux cas peuvent se présenter. Les sites Pi+1 et Pi+2 reçoivent le message de
départ de Pi avant celui de Pi-1. Dans ce cas le problème n’est pas posé. En effet, les sites vont
adopter Pi-1 comme nouveau père dans un premier temps puis Pi-2 dans un deuxième temps.

129
 Pi-2

Pi-1 Départ Pi-2

Départ
Pi Pi+1 Pi+2

Pi+1 Pi+2

Figure II.3.19. Situation normale de départ de deux sites.

Dans le deuxième cas, Les sites Pi+1 et Pi+2 reçoivent le message de départ de Pi-1 avant
celui de Pi. Ces sites ne vont pas traiter le message "Quitter" envoyé par Pi-1 du moment que
ce ne sont pas ses fils. Ils vont par contre traiter le message "Quitter" reçu par Pi et changer le
père par Pi-1. Or ce dernier site a déjà quitté l’arborescence. Ce qui fait que les sites Pi+1 et Pi+2
seront dans une situation de blocage. En effet il n’auront plus de père et seront isolés du
groupe (figure II.3.20).

Pi-2

Pi-2

Pi-1 Départ

Pi

Départ
Pi

Pi+1 Pi+2

Pi+1 Pi+2

Figure II.3.20. Isolement d’un sous-groupe suite à deux départs simultanés.

La solution que nous adoptons pour résoudre ce problème est de considérer le départ d’un
site comme étant une section critique. En d’autres termes, un seul site peut effectuer un départ
à un instant donné. Nous traitons ainsi la gestion de ces départs à l’aide de l’algorithme
Naimi-Tréhel classique (initial). Il y aura donc deux arborescences formées par les sites : la
première arborescence concerne la section critique relative à une ressource partagée gérée par
un premier jeton et la deuxième arborescence, relative au départ des sites, gérée par un
deuxième jeton (jeton des départs).

130
 Un site voulant quitter l’arborescence des sites Naimi-Tréhel envoie une demande de
départ vers le père au niveau de l’arborescence relative aux départs. Cette demande va être ré
acheminée vers la racine. Suite à cette demande, tous les sites l’ayant reçu deviennent des fils
du site demandeur dans l’arborescence relative à la gestion des départs. Si le jeton des départs
est libre, le site demandeur entame la procédure de départ. Sinon, il prend place dans la file
d’attente relative aux départs.

La procédure de départ consiste à diffuser le message de départ ("Quitter") à tous les sites.
Ce message n’est traité que par les fils du site ayant diffusé ce message dans l’arborescence
de gestion des départs. Le traitement de ce message par un site récepteur, consiste à changer
le père par le père du site ayant diffusé le message et de lui envoyer un accusé. Une fois que
tous les fils lui ont envoyé cet accusé, le site ayant procédé au départ passe le jeton de départ à
son suivant et quitte le groupe. Toutefois, un site disposant du jeton de la section critique
relative à la ressource partagée ainsi que la racine de son arborescence ne peuvent pas quitter
le groupe tant qu’il sont dans l’une de ces deux situations. C’est la seule restriction que nous
adoptons pour la procédure de départ. En effet, si le possesseur du jeton relatif à la ressource
partagée entame la procédure de départ, cela peut entraîner la perte de ce jeton. Il ne doit ainsi
entamer cette procédure qu’après avoir libérer le jeton relatif à la ressource partagée. Pour ce
qui est de la racine, son départ entraîne une situation ou on aura deux (ou plusieurs)
arborescences isolées les unes des autres. Ce qui entraîne une situation non valide pour
l’algorithme Naimi-Trehel (figure II.3.21).

Départ
Racine

Figure II.3.21. Départ de la racine.

3.4.2.2 Algorithme Le Naimi-Trehel modifié

Etant donné que nous gérons les départs des participants à l’aide de l’algorithme de
Naimi-Trehel, nous devons traiter deux arborescences simultanément : l’arborescence relative
à la ressource partagée et l’arborescence relative aux départs. Pour cela nous distinguons entre

131
les variables de gestion de la ressource partagée et celles de la gestion des départs. Pour la
gestion de la ressource partagée, nous aurons besoin des variables suivantes :

- "Pere_RP" : c’est la variable "Pere" relative à la ressource partagée.

- "Suivant_RP" : c’est la variable "Suivant" relative à la ressource partagée.
- "Demande_RP" : c’est la variable "Demande" relative à la ressource partagée.
- "Jeton_RP" : c’est la variable "Jeton" relative à la ressource partagée.
- "nb_fils" : c’est le nombre de fils dans l’arborescence relative à la section critique.

Les variables relatives à la gestion de la jointure dynamique restent les mêmes, à savoir :
"Jeton_Envoye", "Liste_Sites_Stockes", "Autorisation".

Les variables relatives à la gestion des départs sont les suivants :

- "pere_D" : c’est la variable "Pere" relative a la gestion des départs

- "Suivant_D" : c’est la variable "Suivant" relative a la gestion des départs
- "Demande_D" : c’estla variable "Demande" relative a la gestion des départs.
- "Jeton_D" : c’est la variable "Jeton" relative à la gestion des départs.

On fera aussi usage des messages suivants :

- (Ack) : message envoyé par un site pour accuser la réception.

- (Inserer, L) : message envoyé par un site i à un site j pour lui demander d’insérer les sites
en les considérant comme ses fils.
- (Joindre, element) : message envoyé par un nouveau site (element) pour joindre
l’ensemble des sites.
- (Initialiser_Pere, element) : message envoyé par un site i à un site j pour lui demander
d’initialiser son père à "element".

Les figures II.3.22 et II.3.23 décrivent le code de l’algorithme permettant la suppression

dynamique des sites dans l’arborescence Naimi-Tréhel. La première figure présente les
procédures d’initialisation, de demande et de libération des sections critiques relatives à la
ressource partagée et à la gestion des départs. Les procédures relatives à la gestion de la
ressource partagée ne subissent pas de modification par rapport à l’algorithme d’insertion
dynamique des sites. Nous modifions seulement les variables en les suffixant par "RP". Dans
la procédure de demande de section critique relative à la gestion des départs, nous ajoutons la
restriction imposant que le site ne doit pas détenir le jeton ou être racine. La procédure de
libération de cette section critique est semblable à l’algorithme Naimi-Tréhel initial.

132
 Const N = … ; moi= … ;
Type mess = (req_RP, ok_RP, req_D, ok_D, inserer, ack, initialiser_pere, joindre, quitter, ack_quiter) ;
site= 1..N  {nil} ;
liste_sites : liste de sites ;
Var pere_RP, suivant_RP : site ; jeton_RP, demande_RP, jeton_envoye, autorisation : booléen ;
pere_D, suivant_D : site ; jeton_D, demande_D : booléen ;
liste_sites_inseres, liste_sites_stockes : liste_sites ;
nb_fils : entier ;

Procedure Initialisation
Debut
pere_RP := … ; (la valeur de père est la même pour chaque site autre que la racine et vaut nil à la racine)
pere_D := … ; (la valeur de père est la même pour chaque site autre que la racine et vaut nil à la racine)
suivant :=nil ;
Si pere_RP = nil Alors jeton_RP := vrai ; autorisation :=vrai ;
Sinon jeton_RP :=faux ; autorisation :=faux ;
Fsi
Si pere_D = nil Alors jeton_D := vrai ; autorisation :=vrai ;
Sinon jeton_D :=faux ; autorisation :=faux ;
Fsi
jeton_envoye :=faux ; liste_sites_stockes :=vide ; liste_sites_inseres :=vide ;
nb_fils= … (0 si non racine, N si nombre de sites autres que la racine
Fin

Procedure Demander_Section_Critique () Procedure Demander_Section_Critique_D ()

Debut Debut
Demande_RP :=vrai ; Si ((pere_RP <> nil) et (jeton_RP <> vrai)) Alors
Si (pere_RP <> nil) Alors Demande_D :=vrai ;
Envoie (req_RP, moi) à pere_RP ; Si (pere_D <> nil) Alors
Pere_RP :=nil ; Envoie (req_D, moi) à pere_D
Fsi Pere_D :=nil
Fin Fsi
Fsi
Fin

Procedure Liberer_Section_Critique () Procedure Liberer_Section_Critique_D ()

Debut Debut
Demande_RP:=faux; Demande_D :=faux ;
Tant_que (non(autorisation)) faire rien F_Tant_que Si (suivant<>nil) Alors
Si ((suivant_RP = nil) et autorisation) Alors Envoie (ok_D, moi) à suivant_D ;
autorisation :=faux ; suivant _D:=nil ;
Envoie (ok_RP, moi) à suivant_RP ; jeton_D :=faux
Suivant_RP := nil ; Fsi
Jeton_RP :=faux ; Fin
liste_sites_stockes :=vide ;
jeton_envoye :=vrai ;
Fin

Figure II.3.22. Suppression de sites dans l’algorithme Naimi-Tréhel.

La figure II.3.23 présente les traitements de tous les messages échangés entre les sites
Nous ajoutons le traitement des messages "Quitter" et "Ack_Quitter". Le traitement du
premier message consiste à modifier les informations "Pere" et "Suivant" par celles reçues en
paramètres (Liste_Sites).

133
 Procedure Traiter_Message (message : mess, element :site, liste : liste_sites )
Debut
Cas message
req_RP : Si pere_RP = nil Alors
Si demande_RP Alors suivant_RP := element
Sinon jeton_RP :=faux ; Envoie (ok_RP, element) à element Fsi
Sinon Envoie (req_RP, element) à pere_RP Fsi ;
pere_RP :=element ;
nb_fils=nb_fils-1 ;

req_D : Si pere_D = nil Alors

Si demande_D Alors suivant_D := element
Sinon jeton_D :=faux ; Envoie (ok_D, element) à element Fsi
Sinon Envoie (req_D, element) à pere_D Fsi ;
pere_D :=element ;

ok_RP : jeton_RD := vrai ;

Diffuser (quitter,moi,(per_RP, suivant_RP)

ok_D : jeton_D := vrai ;

Envoie (Ack,moi, []) à element ;
liste_sites_inseres :=vide ;

ack : jeton_envoye :=faux ; L :=liste_sites_stockes ;

Envoie(inserer, moi, L) ;
liste_sites_stockes :=vide ;

inserer : autorisation :=vrai ;

Pour_tout element de (L – liste_sites_inseres) faire
Envoie(initialiser_pere, self, []) à element
nb_fils=nb_fils+1 ;
F_Pour

joindre_element : Si jeton_RP Alors liste_sites_inseres :=liste_sites_inseres  {element} ;

Envoie(initialiser_pere, self, []) à element ;
nb_fils = nb_fils+1 ;
Sinon
Si jeton_envoye Alors liste_sites_stockes :=liste_sites_stockes  {element} ;
Fsi
Fsi

initialiser_pere : pere_RP :=element ;

quitter : pere_RP := Retirer_tete_liste(liste_sites) ;

suivant_RP := Retirer_tete_liste(liste_sites) ;
Envoie(ack_quitter)à element ;

ack_quitter : nb_fils=nb_fils-1 ;
Si (nb_fils=0) alors Envoie(ok_D,moi) à suivant_D ;
suivant_D=nil ;
jeton_D=faux ;
Fsi
Fin

Figure II.3.23. Traitement des messages relatifs à la suppression dans l’algorithme Naimi-Tréhel.

Le message "Ack_Quitter" permet au site récepteur de décrémenter le nombre de ses fils.

Quand ce nombre devient nul, il envoie le jeton relatif à la gestion des départs à son suivant.

134
3.5 Conclusion

Dans ce chapitre, nous avons présenté des améliorations que nous avons apportées à des
algorithmes d’exclusion mutuelle distribués, en vue de supporter l’insertion et la suppression
dynamiques des sites participants. Les algorithmes obtenus peuvent ainsi servir comme
mécanismes pour l’implémentation de protocoles de gestion et de contrôle de floor dans des
systèmes de téléconférence multimédia.

135
 Chapitre 4

Conception et implémentation

Le travail de ce chapitre a été réalisé au LAAS de Toulouse au cours d’un stage de recherche
dans le cadre du projet STIC. Ce travail a fait l’objet des publications suivantes :

- M. Oualla, M. Ouzzif and M. Erradi, "Implementation of a Multimedia Teleconferencing

system over Internet", IWCSE, Marrakech, December 2002.
- M.Ouzzif et M. Erradi, “Un Protocole de Floor Control basé sur un mécanisme d’exclusion
mutuelle distribué dynamique”, NOTERE’04, Saidia, Maroc, 2004.

4.1 Introduction

Nous avons présenté dans les chapitres précédents des spécifications formelles relatives à
deux systèmes de téléconférence. Le premier système obéit à une politique présidée. Le
deuxième est régi par une politique explicite. Nous avons ensuite vérifié ces deux systèmes en
élaborant et en validant des propriétés temporelles. Nous avons aussi élaboré des algorithmes
pouvant servir de mécanismes à ces politiques. Ces spécifications, claires et précises, nous ont
facilité la conception et la réalisation de ces systèmes que nous présentons dans ce chapitre.

Nous commençons par décrire la conception et la réalisation d’un système de

téléconférence multimédia régi par la politique présidée. Nous présentons ensuite la
réalisation d’un système à politique explicite effectuée au dessus de l’environnement Platine
du LAAS. Nous terminons par la description d’une application CSCL (Computer-Supported
Cooperative Learning) qu’on a réalisée au dessus du deuxième système. Cette application
permet la préparation coopérative entre étudiants pour un examen.

136
4.2 Conception et réalisation d’un système à politique présidée

Nous présentons dans cette section la conception d’un système de gestion et de contrôle
de floor d’une téléconférence régie par la politique présidée en utilisant la notation standard
UML (Unified Modeling Language) [Rumb 00, Roqu 00]. Nous présentons ensuite la
réalisation de ce système que nous avons effectuée à l’aide de Java et JMF (Java Media
Framework) et que nous avons déployée sur un réseau local sous LINUX.

4.2.1 Conception UML

La méthodologie de conception que nous adoptons consiste en plusieurs étapes. Nous

commençons par identifier les acteurs du système et leurs cas d’utilisation. Nous identifions
ensuite les interfaces à partir des scénarios d’interactions des acteurs avec le système. Ces
interfaces nous permettent de dégager le diagramme de classes et leurs attributs. Nous
élaborons ensuite les diagrammes de transitions d’états pour chaque classe afin de compléter
le modèle de classes par les opérations. Enfin, nous décrivons les interactions acteurs/système
à l’aide des diagrammes de séquences. Nous présentons dans cette section les principaux
diagrammes correspondant aux modèles élaborés.

4.2.1.1 Acteurs du système

Un acteur représente l’abstraction d’un rôle joué par une entité externe (utilisateur,
dispositif matériel ou autre système) qui interagit directement avec le système étudié. Les
acteurs qui interagissent avec le MMTS sont :

- Le modérateur : il s’agit d’une personne qui gère la conférence (création, terminaison,

etc.), et contrôle l’accès aux ressources de la conférence (audio, vidéo, tableau blanc,
etc.).

- Le simple participant : cet acteur a pour rôle de participer à la conférence et d’exploiter

les ressources disponibles après avoir reçu la permission d’y accéder.

- Le participant : cet acteur généralise les deux acteurs précédents. Un participant peut être
un modérateur (ou chairman) ou un simple participant.

137
4.2.1.2 Diagrammes de cas d’utilisation

Un cas d’utilisation représente un ensemble d’actions réalisées par le système et peut

produire un résultat observable pour un acteur donné. Il exprime les interactions
acteur/système et apporte une valeur ajoutée notable à l’acteur concerné.

La figure II.4.1 présente les cas d’utilisations relatifs à un modérateur. Elle comporte deux
principaux cas d’utilisation : le cas "Gérer Conférence" et le cas "Contrôler Floor". Le
premier cas permet au modérateur de créer, d’arrêter, de reprendre ou de terminer une
conférence. Le deuxième cas lui permet d’attribuer le floor (relatif à une ressource) ou de le
retirer à un participant ayant dépassé le temps qui lui a été accordé pour la détention du floor.

Créer

Arrêter (Paus e)

gérer conférence

Reprendre (Res um e)

Modérateur

Terminer

Donner floor

Contrôler floor

Retirer floor

Figure II.4.1. Cas d’utilisation relatifs au modérateur.

La figure II.4.2 présente les cas d’utilisation relatifs à un simple participant. Elle comporte
deux principaux cas d’utilisation : le cas "Participer à Conférence" et le cas "Exploiter Floor".
Le premier cas permet au participant de joindre ou de quitter la conférence. Le deuxième cas
lui permet de demander ou de libérer le floor.

138
 Joindre Conférence

Participer à conférence

Quitter Conférence

Sim ple
Participant

Dem ander floor

Exploiter floor

Libérer floor

Figure II.4.2. Cas d’utilisation relatifs à un simple participant.

4.2.1.3 Diagramme de classes

Le diagramme de classes est le diagramme le plus important dans toutes les méthodes de
conception orientées objets. Il sert de base pour les outils de génération automatique du code.
C’est également le diagramme qui comporte la plus grande gamme de notations et de
variantes. Il est composé de classes et de relations qui les lient. Ces relations peuvent être de
différents types (agrégation, héritage, etc.). La figure II.4.3 décrit le diagramme de classes du
système régi par la politique présidée. Nous modélisons l’entité GCCF à l’aide de la classe
"Entité GCCF". Cette classe est composée des classes "Coordination_GCCF", "Gestion
Conférence", "Contrôle Floor" et "Gestion Média" qui modélisent la gestion et le contrôle de
conférence du MMTS.

La classe "Coordination_GCCF" représente l’interface de l’entité GCCF et offre un

ensemble de méthodes mises à la disposition de la classe "Interface Conférence". Celle-ci
modélise l’interface entre le participant et l’entité GCCF. La classe "Gestion Conférence"
fournit l’ensemble des méthodes permettant la gestion d’une conférence (création, jointure,
départ, etc.). La classe "Contrôle Floor" offre l’ensemble des fonctionnalités permettant de
contrôler l’accès aux ressources, chacune représentée par un floor donné (demande de floor,
attribution de floor, libération de floor, etc.). La classe "Gestion Média" offre les opérations
de contrôle d’envoi des médias (audio/vidéo) et de contrôle des applications partagées.

Chaque participant est modélisé par une instance de la classe "Participant". Cette classe
regroupe toutes les informations relatives à un participant (modérateur ou simple participant).
Elle généralise les classes "Modérateur" et "Simple Participant". L’ensemble des instances de

139
la classe "Participant" constitue le contexte de conférence modélisé par la classe "Contexte
Conference". Celle-ci offre les méthodes permettant la consultation et la mise à jour du
contexte de conférence.

Figure II.4.3. Diagramme de classes.

Le contexte de floor est modélisé par la classe "Contexte Floor". Elle est composée d’un
ou de plusieurs floors modélisés par la classe "Floor". Cette classe dispose d’une structure
"Liste_Demandeurs" et offre les opérations de gestion de cette liste (Ajout/Retrait). Chaque
instance de la classe "Floor" correspond à une ressource ou plusieurs modélisées par la classe
"Ressource".

140
4.2.1.4 Diagrammes de séquences

Un diagramme de séquence UML permet de décrire la séquence des messages échangés

entre les acteurs externes et les différentes classes du système. Chaque diagramme de
séquence correspond à un cas d’utilisation bien précis.

a. Diagrammes de séquences relatifs au modérateur

Nous présentons dans cette section des exemples de diagrammes de séquences relatifs au
cas d’utilisation de contrôle de floor concernant le modérateur.

- Diagramme de séquence d’attribution de floor

Le diagramme de séquence relatif au cas d’utilisation de l’attribution du floor est décrit

dans la figure II.4.4. Le modérateur invoque cette opération ("Donner_Floor") sur "l’Interface
de Conférence" via son interface "Fenêtre Modérateur".

: Fenetre : Interface Conference : Coordination_GCCF :Controle Floor : Gestion Media : Contexte_Floor : Floor : Controle Floor Gestion Media (Simple : Coordination_GCCF Interf ace Conf erence
Moderateur (Moderateur) (Moderateur) (Moderateur) (Moderateur) (Simple Participant) Participant) (Simple Participant) (Simple Participant)

Donner_Floor

GCCF_Give_Floor

Give_Floor

Stop_Send_Media

GCCF_Update_Floor_Context

Deverrouiller_Floor

GCCF_Give_Floor

Give_Floor

GCCF_Give_Floor

Stop_Send_Media

GCCF_Update_Floor_Context

Verrouiller

Figure II.4.4. Diagramme de séquence d’attribution du floor.

Suite à cette demande, la classe "Interface de Conférence" invoque le service

d’attribution de floor sur la classe "Coordination_GCCF" qui délègue cette tâche à la classe

141
"Contrôle Floor". Celle-ci demande l’arrêt d’envoi des médias à la classe "Gestion Média",
met à jour le contexte de floor et envoie le floor à la classe "Contrôle Floor" relative au
participant désigné par le modérateur. Cette dernière classe notifie l’attribution du floor à la
classe "Coordination_GCCF" qui achemine cette notification vers la classe "Interface de
Conférence".

- Diagramme de séquence de retrait de floor

Les interactions relatives au retrait du floor par un modérateur à un participant ayant

dépassé le temps qui lui a été alloué, sont représentées par le diagramme de séquence de la
figure II.4.5.

: Fenetre : Interface Conference : Coordination_GCCF : Controle_Floor : Gestion Media : Contexte_Floor : Floor : Controle Floor : Coordination_GCCF : Gestion Media : Interface Conference
Moderateur (Moderateur) (Moderateur) (Moderateur)) (Moderateur) (Simple Participant) (Simple Participant) (Simple Participant) (Simple Participant)

Retirer_Floor

GCCF_Grab_Floor

Grab_Floor

GCCF_Grab_Floor

Grab_Floor

GCCF_Grab_Floor

Stop_Send_Media

GCCF_Release_Floor

Release_Floor
GCCF_Update_Floor_Context
GCCF_Release_Floor

Rendre_Floor
Deverrouiller_Floor

Send_Media

GCCF_Update_Floor_context

Verrouiller_Floor

Figure II.4.5. Diagramme de séquence de retrait de floor.

Le modérateur invoque le service de retrait de floor via son interface sur la classe
"Interface de Conférence". Celle-ci achemine cette demande à la classe
"Coordination_GCCF" qui la transfère à la classe "Contrôle Floor". Cette classe envoie la
demande de retrait de floor à la classe "Contrôle Floor" relative au participant détenteur du
floor. Cette dernière classe demande l’arrêt d’envoi des médias à la classe "Gestion Media",
met à jour le contexte de floor et envoie le message de libération de floor à la classe "Contrôle

142
Floor" du modérateur. Celle-ci met à jour le contexte de floor et ordonne l’envoi des médias
du modérateur à la classe "Gestion Media".

b. Diagrammes de séquences relatifs à un simple participant

Nous présentons dans cette section des exemples de diagrammes de séquences relatifs au
cas d’utilisation de contrôle de floor concernant un simple participant.

- Diagramme de séquence de demande de floor

Le diagramme de séquence relatif à la demande du floor est décrit à la figure II.4.6. Le

participant émet cette demande à travers son interface vers la classe "Interface de
Conference". Cette demande est ensuite envoyée à la classe "Coordination_GCCF" qui la
transfère vers la classe "Contrôle Floor". Cette classe envoie la demande de floor à son
homologue au niveau du modérateur et met à jour le contexte de floor.

: Fenetre : Interf ace Conf erence : Coordination_GCCF : Controle Floor : Controle Floor : Coordination_GCCF : Contexte Floor
SimpleParticipant (Simple Participant) (Simple Participant) (Simple Participant) (Moderateur) (Moderateur)

Demander_Floor

GCCF_Ask_Floor

Ask_Floor

GCCF_Ask_Floor

Ask_Floor

GCCF_Update_Floor_Context

Figure II.4.6. Diagramme de séquence de demande de floor.

- Diagramme de séquence de libération de floor

Le diagramme de séquence relatif à la libération du floor est décrit à la figure II.4.7. Le

participant émet cette demande à travers son interface vers la classe "Interface de
Conference". Cette demande est ensuite acheminée vers la classe "Coordination_GCCF" puis,
déléguée à la classe "Contrôle Floor". Celle-ci met à jour le contexte de floor, arrête l’envoi
des médias relatifs au participant et envoie la notification de libération de floor à son
homologue au niveau du modérateur. En recevant cette notification, la classe "Contrôle Floor"
relative au modérateur met à jour le contexte de floor et demande à la classe "Gestion Média"
d’envoyer les médias relatifs au modérateur.

143
 : Fenetre : Interface Conference : Coordination_GCCF Controle Floor Gestion Media : Contexte_Floor : Floor : Controle Floor : Coordination_GCCF Gestion Media Interface Conference
Simple Participant (Simple Participant) (Simple Participant) (Simple Participant) (Simple Participant) (Moderateur) (Moderateur) (Moderateur) (Moderateur)

Liberer_Floor

GCCF_Release_Floor

Release_Floor

Stop_Send_Media

GCCF_Update_Floor_Context

Deverrouiller_Floor

GCCF_Release_Floor

Release_Floor

GCCF_Release_Floor

Send_Media
GCCF_Update_Floor_context

Verrouiller_Floor

Figure II.4.7. Diagramme de séquence de libération de floor.

4.2.2 Réalisation

Nous présentons dans cette section l’implémentation du MMTS régi par la politique
présidée à travers les interfaces qu’il fournit aux usagers. Cette implémentation a été effectuée
en utilisant le langage Java et l’API JMF par-dessus LINUX [Oual 02]. Nous commençons
par présenter les interfaces préliminaires à une participation dans une conférence. Nous
donnons ensuite les interfaces affichées au cours de la participation d’un usager.

4.2.2.1 Interfaces préliminaires à une participation

Les interfaces préliminaires à une participation à la conférence sont les suivants :

l’interface de saisie des informations d’un usager, l’interface de choix création/jointure de
conférence, l’interface de création de la conférence et l’interface de jointure d’une conférence.

a. Interface de saisie des informations d’un usager

La première interface qui s’affiche lors de l’exécution de l’application de téléconférence

multimédia à politique présidée est celle de la saisie des informations relatives à un
participant (figure II.4.8).

144
 Figure II.4.8. Interface de saisie des Informations d’un utilisateur.

Cette interface permet à un usager nouvellement connecté de fournir ses informations

(nom, adresse, adresse IP, etc.) au système. Ces informations permettent à l’utilisateur de
s’identifier auprès des autres participants. L’usager peut valider ses informations en appuyant
sur le bouton "Suivant" ou quitter l’application en appuyant sur le bouton "Quitter". Dans le
premier cas, les informations sont prises en compte par le système et sont mises dans le
contexte de conférence. Le système affiche ensuite l’interface "Conférence Directory".

b. Interface "Conference Directory"

L’interface "Conference Directory" (Répertoire de conférence) offre deux fonctionnalités

principales (figure II.4.9). La première fonctionnalité permet à un modérateur de créer une
nouvelle conférence (bouton créer) et de l’ajouter au répertoire des conférences. Ceci entraîne
ensuite l’affichage de l’interface "Création d’une conférence" (figure II.4.10). La deuxième
fonctionnalité permet à un simple usager de joindre une conférence déjà existante. Les
conférences existantes sont affichées dans une liste figurant dans la partie gauche de
l’interface "Conference Directory". Notons que ces deux fonctionnalités font partie des
aspects d’initiation et d’annoncement de conférence supportées par des protocoles tel que
SDP et SAP. Nous tenons à préciser que nous n’avons pas implémenté de tels types de

145
protocoles. Nous avons cependant utilisé une base de données centralisée pour maintenir les
informations des conférences créées.

Figure II.4.9. Interface "Conference Directory".

c. Interface "Création d’une conférence"

L’interface de "Création d’une Conférence" permet à un usager d’introduire les

informations d’une nouvelle conférence. Chaque conférence est identifiée par un
identificateur unique et dispose des informations suivantes : le nom de la conférence, son
adresse multicast, son port, son objet et sa politique (présidée par défaut dans ce cas). Ces
informations sont sauvegardées dans une base de données de conférences.

L’usager peut aussi spécifier les ressources à utiliser dans cette conférence (audio/vidéo)
et outils de coopération (tableau blanc ou chat). L’usager ayant introduit ces informations
devient le modérateur de la conférence créée.

146
 Figure II.4.10. Interface "Création d’une conférence".

d. Interface "Joindre une conférence"

L’interface "Joindre une conférence" permet à un usager d’introduire les informations de

la conférence à joindre (figure II.4.11). Ces informations concernent l’adresse multicast et le
port de la conférence. Notons que la jointure d’une conférence à partir de l’interface
"Conference Directory" n’est pas supportée par le système. Cette interface permet aussi à
l’usager de préciser les ressources et les outils à utiliser. Une fois ces informations validées,
l’usager est considéré comme étant un simple participant.

Figure II.4.11. Interface "Joindre une conférence".

147
4.2.2.2 Interfaces de gestion du déroulement de la conférence

Les interfaces de gestion et de contrôle de la conférence au cours de son déroulement sont

de deux types : l’interface du modérateur et l’interface du simple participant.

a. Interface du modérateur (ou chairman)

L’interface du modérateur offre plusieurs fonctionnalités de gestion et de contrôle de la

conférence et qui sont regroupées en des composantes (figure II.4.12). Ces composantes sont
représentées par des panneaux. Ces panneaux sont : le panneau "Vidéo", le panneau "Audio",
le panneau "Floor", le panneau "Group Information", le panneau "Ressource" et le panneau
"Buttons". Les panneaux "Vidéo" et "Audio" (en haut et à gauche de l’interface) permettent
de présenter la vidéo et d’écouter l’audio d’un participant détenteur du floor. Le panneau
"Floor" permet au modérateur de donner le floor (bouton "Give Floor"), retirer le floor
(bouton "Grab Floor"), demander l’état du floor (bouton "Floor state") ou demander des
informations concernant un floor (bouton "Floor Infos").

Figure II.4.12. Interface "Chairman".

148
 Le panneau "Group information" permet de consulter la liste de tous les utilisateurs
connectés et leurs informations ("All Users"), consulter la liste des demandeurs de floor
("Floor Callers") ou supprimer un utilisateur de la conférence ("Remove User"). Le panneau
"Ressources" permet d’activer ou désactiver une ressource. Le panneau "Buttons" contient un
ensemble de boutons pour terminer, initialiser, arrêter ou reprendre une conférence. Un label,
situé dans le coté droit de ce panneau sert à mentionner le nom du participant qui détient le
floor.

b. Interface d’un simple participant

L’interface relative à un simple participant est présentée à la figure II.4.13. Cette interface
comporte les mêmes panneaux que l’interface du modérateur. La différence réside dans le
panneau "Floor" et le panneau "Bouttons". Dans le premier panneau, le participant dispose
seulement des fonctionnalités lui permettant de demander ou de libérer le floor. Le deuxième
panneau offre uniquement les fonctionnalités de connexion ou de départ d’un simple
participant.

Figure II.4.13. Interface "Simple Participant".

149
4.3 Réalisation d’un système à politique explicite

Nous présentons dans cette section l’implémentation d’un système de téléconférence

multimédia régi par une politique explicite. Cette implémentation consiste en une intégration
d’une couche de gestion et contrôle par-dessus les modules audio et vidéo de Platine en se
basant sur un mécanisme d’exclusion mutuelle distribué [Ouzz 04].

4.3.1 Environnement Platine

Platine est un environnement générique de travail collaboratif développé au LAAS

(Laboratoire d’Automatique et d’Analyse des Systèmes de Toulouse) dans le cadre d’un projet
européen. Son objectif est de permettre à plusieurs utilisateurs de travailler sur un problème
nécessitant quelques instants de réflexion ou de travail commun, tout en étant
géographiquement distribués [Baud 02]. Platine est constitué de cinq outils implémentant les
besoins d’un travail coopératif : l’outil de visioconférence, l’outil tableau blanc, l’outil de
partage d’applications, l’outil de gestion de session et l’outil de configuration hors-ligne. La
figure II.4.14 présente l’architecture de Platine.

L’outil de visioconférence permet un dialogue informel entre les membres d’une même
session de travail. Il offre des fonctionnalités de connexion/déconnexion, de sélection du type
de médias (audio/vidéo) et de spécification du débit émis de la vidéo en nombre d’images par
seconde. Tous les utilisateurs de la visioconférence ont les mêmes privilèges. Le groupe de
travail se définit par une adresse IP (multicast ou unicast selon les conditions d’utilisation) et
par un numéro de port [Baud 01a].

L’outil tableau blanc est une application client/serveur fonctionnant sous TCP et conçue
pour offrir les fonctionnalités d’un tableau blanc classique d’une salle de cours ou de réunion.
Le but est de partager des documents statiques variés, utilisés dans le cadre d’une présentation
de travail. Le responsable de la réunion affiche des documents que tous les autres participants
pourront sauvegarder localement en fin de session. Cet outil est en fait un éditeur graphique
partagé, utilisant comme fond d’écran, un document pré-existant enregistré au format GIF ou
JPEG.

L’outil de partage d’applications est utilisé par un participant pour diffuser une image de
l’application métier sur laquelle il travaille. Cet outil effectue une capture d’écran diffusée à
l’ensemble des participants de la session et fonctionne selon un modèle client/serveur. Le

150
serveur de partage est lancé sur la machine qui est également serveur d’applications métiers.
Seules les copies d’écrans sont diffusées comme cela se produit dans une salle de réunion
classique équipée d’un vidéo projecteur.

Visioconference
Gestion de Partage Configuration
Tableau blanc
session d'application hors-ligne

RTP/RTCP
Multicat
Environnement PLATINE Fiable

Transport

Figure II.4.14. Architecture de l’environnement Platine.

Le gestionnaire de session est un outil dont l’interface est présente uniquement sur le
poste du responsable de la session. Son rôle est de gérer les différents outils de la plate-forme.
Pour ce faire, il transmet des ordres à l’ensemble des participants ou à un participant identifié
tels que :

- Réduire et restaurer : ordre qui permet d’iconifier ou de restaurer la fenêtre d’un des
outils de la plate-forme sélectionné. Cet ordre est utilisé par le responsable pour attirer
l’attention d’un ou de plusieurs participants sur un outil à un moment donné.
- Montrer ou cacher : met en avant ou en arrière plan un outil de la plate-forme pour un
participant ou pour l’ensemble des participants.
- Verrouiller ou déverrouiller un outil : autorise un accès en lecture ou en lecture/écriture
sur un outil de la plate-forme.
- Quitter : ferme définitivement l’application sélectionnée chez un participant ou pour tous
les participants

L’outil de configuration hors-ligne permet au responsable de la session de configurer une

session de travail.

4.3.2 Architecture du système

L’architecture du MMTS à politique explicite que nous avons réalisé est composée de
Platine comme environnement de base auquel on a intégré un module de "Gestion de

151
Conférence et de Contrôle de Floor" pour gérer les ressources demandées par les applications
coopératives (figure II.4.15). Nous distinguons ainsi les cinq blocs suivants :

- Le bloc "Applications Coopératives" : qui implémente une application de travail

collaboratif (téléenseignement, télétravail, etc.).
- Le bloc de "Gestion de Conférence et de Contrôle de Floor" : qui fournit des services
permettant le contrôle de la détention d’une ressource de l’application coopérative.
- Le bloc "Platine" qui consiste en l’environnement Platine et ses outils.
- Le bloc "RTP/RTCP" qui permet la transmission en temps réel des données.
- Le bloc "Transport" qui regroupe l’ensemble des protocoles permettant d’acheminer les
données entre les différents sites (TCP/UDP et IP/IP-Multicast).

Applications Cooperatives

Environnement
Gestion de Conférence et PLATINE
Contrôle de Floor RTP/RTCP
Multicat Fiable

Transport

Figure II.4.15 Architecture du MMTS réalisé.

Le bloc "Applications Coopératives" peut interagir avec le bloc de "Gestion de

Conférence et Contrôle de Floor" ou directement avec le bloc "Platine" si aucun control n’est
requis. Le bloc "Gestion de Conférence et Contrôle de Floor" interagit d’une part avec le bloc
de "Transport" pour l’envoi des messages de contrôle et d’autre part avec le bloc Platine pour
contrôler l’usage de ses outils par le bloc "Applications Coopératives". Le bloc "Platine" peut
aussi interagir avec le bloc "RTP/RTCP" et "Transport" pour la transmission des données
multimédias. Notons que nous avons intégré dans Platine deux nouvelles primitives pour
permettre l’envoi et l’arrêt de transmission des médias : "Start_Send_Media" et
"Stop_Send_Media".

Pour implémenter le bloc "Gestion de Conférence et Contrôle de Floor", nous avons

utilisé le mécanisme d’exclusion mutuelle distribué décrit au chapitre 3 (section 3.4.2). En y
intégrant les primitives de "Gestion de Conférence et Contrôle de Floor", les procédures de
demande et de libération de la section critique relative à la ressource partagée
(Demander_Section_Critique_RP et Libérer_Section_Critique_RP) nous ont servis pour le

152
contrôle d’acquisition et de libération du floor. Etant donné qu’on s’est intéressé au floor
relatif aux canaux des médias (audio et vidéo), le bloc "Gestion de Conférence et Contrôle de
Floor" fait appel aux primitives offertes par Platine : "Start_Send_Media" et
"Stop_Send_Media". L’acquisition du "floor" entraîne l’invocation de la primitive
"Start_Send_Media". La libération du "floor" entraîne l’invocation de la primitive
"Stop_Send_Media".

4.3.3 Implémentation

Nous avons réalisé une implémentation qui permet le contrôle de l’outil visioconférence
en gérant un floor relatif aux modules de transmission de l’audio et de la vidéo. Ce contrôle
est assurée par la classe "Gestion_Conference_Controle_Floor" implémentant le bloc
"Gestion de Conférence et Contrôle de Floor" en JAVA. Cette classe implémente le
mécanisme d’exclusion mutuelle distribué dynamique (algorithme Naimi-Tréhel modifié) et
interagit d’une part, avec les classes de l’outil de visioconférence de Platine et d’autre part,
avec une classe implémentant une application coopérative. Cette application se présente
comme une interface comportant les boutons de prise et de libération de la parole. Le
mécanisme d’exclusion mutuelle permet un ordonnancement des requêtes des utilisateurs de
la session coopérative.

Un utilisateur voulant participer à ce système commence par spécifier l’adresse multicast

du groupe (Adresse destinataire de la fenêtre "a", figure II.4.16) ainsi que les formats de
l’audio et de la vidéo utilisés (menu "Audio Device" et "Video Device" fenêtre "a" de la
figure II.4.16). Une fois qu’il appuie sur le bouton "Start", il joint la conférence spécifiée par
l’adresse multicast et la fenêtre de contrôle de la parole est affichée (fenêtre "b" de la figure
II.4.16) ainsi que les fenêtres audio et vidéo des différents participants qui sont connectés
(fenêtre "c" et "d" de la figure II.4.16). L’acquisition du "floor" par un participant implique
la diffusion de ses médias (audio/vidéo), à lui seul, chez les autres. Le floor est géré par le
système et est délivré selon l’ordre des requêtes émises par les participants.

La fenêtre de contrôle de la parole constitue une implémentation simple du bloc

"Applications Coopératives" et interagit avec la classe Gestion_Conference_Controle_Floor"
pour le contrôle de l’outil visioconférence de l’environnement Platine. Cette implémentation
peut être étendue pour supporter le contrôle de floor relatif à d’autres ressources (tableau
blanc, application partagée, etc.).

153
 c

Figure II.4.16. Interface du système à politique explicite.

4.4 Application au télé-enseignement

Nous présentons dans cette section l’implémentation d’une application CSCL (Computer-
Supported Cooperative Learning). Cette application permet d’accompagner des étudiants
dans leur processus d’apprentissage. Elle leur fournit un environnement synchrone pour la
préparation des exercices d’un cours ou d’un examen. Elle est réalisée par-dessus le système à
politique explicite que nous avons présenté dans la section 4.3.

4.4.1 Caractéristiques d’une application de préparation coopérative

L’accompagnement des étudiants dans la résolution des exercices est un aspect très
important dans leur processus d’apprentissage. Cet aspect est généralement supporté de
manière asynchrone dans les systèmes d’enseignement à distance. Les étudiants effectuent

154
leurs exercices individuellement et les envoient à l’enseignant. Toutefois, les interactions et la
communication entre les étudiants d’un groupe de travail constituent un moyen efficace pour
l’assimilation d’un cours à travers des exercices ou la préparation d’un examen. Dans le but
de faciliter la résolution des exercices en groupe via une application CLCS, [Haak 02]
identifie les caractéristiques requises par une telle application :

- La préparation des exercices : cette caractéristique concerne l’enseignant (ou le

responsable du groupe). Ce dernier doit être en mesure de construire des exercices avec
différentes structures que doit offrir l’application. Un exercice peut être caractérisé par
une description des tâches, des données initiales, un processus de résolution, une
caractérisation du résultat attendu et la taille du groupe.
- La gestion de l’apprentissage : l’application doit offrir aux étudiants des moyens pour
sélectionner des exercices, soumettre des solutions et consulter l’état d’un exercice
(résolu, soumis, évalué). Elle doit aussi leur offrir les moyens pour récupérer la solution
(partielle ou totale) d’un exercice.
- L’apprentissage coopératif : l’application doit supporter des outils de visualisation et
d’édition communes. Des supports didactiques doivent être offerts pour chaque étape
requise dans le processus de résolution d’un problème. L’application doit aussi offrir des
techniques de conduite de la résolution d’un problème structuré.
- La gestion de groupe : les étudiants doivent être capables de joindre et de quitter
dynamiquement des groupes de préparation. L’application doit faciliter la négociation des
exercices, des dates et du temps entre les membres du groupe.
- La gestion de la visioconférence : L’application doit permettre aux étudiants d’échanger
des données audio et vidéo. Cette fonctionnalité nécessite la gestion des sessions de
visioconférence. Cette administration passe par la gestion des membres de la session, leurs
connectivités et la maintenance des informations sous-jacentes.
- La coordination des interactions : cette caractéristique permet le contrôle des
interventions des membres du groupe et leurs accès aux ressources sans conflit. Celle-ci
peut être assurée à l’aide de la métaphore de floor.

4.4.2 Réalisation d’une application de préparation coopérative

Nous discutons dans cette section la mise en œuvre d’une partie des caractéristiques
mentionnées ci-dessus à travers notre implémentation. Pour supporter la préparation des

155
exercices, nous implémentons un outil permettant la gestion d’une base de données des
exercices. Cet outil offre un ensemble de services à l’enseignant, ou à l’étudiant responsable
du groupe. Ces services concernent la création et la suppression et l’insertion d’une
description d’un exercice, la copie d’une description d’un exercice et l’édition d’un exercice
existant (figure II.4.17). Cet outil permet aussi à l’étudiant de consulter des exercices et leur
stade de résolution.

Figure II.4.17. Editeur de l’exercice.

156
 Comme moyen d’édition et de visualisation commune, nous implémentons un tableau
blanc qui permet d’offrir les fonctionnalités classiques d’un tableau de classe et offre la
possibilité de discuter conjointement un exercice via des schémas graphiques et du texte
(figure II.4.18). Pour les trois dernières caractéristiques, nous utilisons le système de
téléconférence à politique explicite que nous avons présenté dans la section 4.3. Ce système
permet de supporter la gestion de groupe, l’envoi des données multimédias, la coordination
des interventions des différents membres du groupe et le contrôle des floors relatifs aux
ressources partagées.

Figure II.4.18. Tableau blanc.

157
 L’architecture que nous adoptons pour l’application de préparation coopérative des
exercices est une architecture client/serveur. Du côté client, elle comporte quatre
composantes : l’interface de l’application, la composante "Gestion de conférence et Contrôle
de Floor", la composante "Agent de Gestion du Contexte de Préparation" ("AGCP"), et la
composante de transport. La première composante présente à l’utilisateur l’ensemble des
fonctionnalités de gestion des exercices (pouvant être des applets). La deuxième composante
permet la gestion et le contrôle des interactions des membres et des ressources. La
composante "AGCP" exécute les fonctionnalités offertes par l’interface. Du côté du serveur,
nous distinguons trois composantes : la composante de "Gestion du Contexte de Préparation"
("GCP"), la composante JDBC et la base de donnée. La première composante comporte
l’ensemble des services (pouvant être des servlets) qui répondent aux demandes des
"AGCPs". La deuxième composante permet l’interaction entre la composante "GCP" et la
base de donnée. La base de donnée permet de stoker le contexte de la préparation.

Responsable Etudiant

Services de
Connexion au Création d'un
Création Connexion au Consultation préparation
système exercice
d'une session système d'un exercice
de préparation
Service de JDBC
création d'une
préparation

Service de
création d'un
Agent de Gestion du Contexte de
Gestion de Conférence et Controle de Floor
.....
exercice
Préparation

Service de
consultation
Base de
d'un exercie données
Transport

Serveur de préparation
Client

Figure II.4.19. Architecture de l’application de préparation coopérative des exercices.

4.5 Conclusion

Dans ce chapitre, nous avons présenté la conception UML et la réalisation d’un système
de téléconférence régi par la une politique présidée. Nous avons ensuite décrit
l’implémentation d’un système à politique explicite. La première implémentation est basée
essentiellement sur la spécification formelle (Partie II chapitre 1 section 1.3.2) qui nous a

158
facilité la conception et la réalisation. La deuxième implémentation est basée sur un
mécanisme d’exclusion mutuelle distribué et fait usage de l’environnement Platine. Cette
implémentation nous a servi de base pour la réalisation de l’application CSCL pour la
préparation coopérative des exercices. Notons que d’autres applications ont été effectués par-
dessus les systèmes de téléconférence (présidée et explicite) pour le télétravail et le suivi
synchrone d’un cours donnée par un enseignant (classe virtuelle).

159
Conclusion générale

Dans ce travail de thèse, nous avons commencé par présenter un état de l’art sur les
systèmes coopératifs, les normes concernant les systèmes de téléconférence multimédia et les
produits basés sur ces standards. Cette étude nous a permis de mettre en évidence le besoin et
le rôle de la gestion et du contrôle du déroulement d’une téléconférence. Ceci requière deux
principaux aspects auxquels nous nous sommes intéressés : la gestion de conférence et le
contrôle du "floor". Conformément aux objectifs de cette thèse, nous avons apporté une
contribution au niveau des points suivants:
- La définition d’une architecture de gestion et de contrôle de conférence multimédia ;
- La spécification formelle de protocoles de gestion de conférence et de contrôle de
"floor" (protocoles GCCF) ainsi que leur vérification ;
- L’élaboration de mécanismes de réalisation des protocoles spécifiés ;
- L’implémentation de ces protocoles.

Au niveau de la définition de l’architecture, nous avons proposé une nouvelle architecture

qui se présente sous forme d’une pile de protocoles structurée en cinq blocs : le bloc interface
de conférence, le bloc Gestion et contrôle de conférence, le bloc agents médias, le bloc
initiation de conférence et le bloc transport. Nous avons identifié deux composantes
principales au niveau du bloc de gestion et de contrôle à savoir : la composante de gestion de
conférence et la composante contrôle de "floor". La première composante concerne la gestion
des membres de la téléconférence, la deuxième composante permet la coordination des
interventions des participants et le contrôle de l’accès aux différentes ressources partagées
(audio, vidéo, tableau blanc etc.). L’ensemble de ces deux composantes constitue l’entité de
gestion de conférence et de contrôle de "floor" (Entité GCCF).

Au niveau de la spécification formelle de protocoles de gestion de conférence et de

contrôle de floor, nous avons commencé par décrire informellement deux politiques de
gestion et de contrôle de téléconférence à savoir : la politique présidée et la politique
explicite. Ces poltiques permettent de réglementer les interactions entre les différents
participants de la conférence. Nous avons ensuite décrit formellement le comportement de

160
l’entité de gestion de conférence et de contrôle de floor selon ces deux politiques. Les
descriptions formelles ont été élaborées à l’aide du formalisme de machines à états finis
communicants. L’objectif de cette description formelle est d’aboutir à des spécifications
claires, exactes, consistantes et vérifiables. Nous avons aussi identifié des propriétés
temporelles qui répondent aux besoins attendus des systèmes de téléconférence en terme de
sûreté, de vivacité et d’exclusion mutuelle. Nous avons décrit ces propriétés en logique
temporelle linéaire et nous les avons vérifiées automatiquement, à l’aide de l’outil
Promela/Spin.

Au niveau des mécanismes de réalisation, nous nous sommes basés sur les techniques
d’exclusion mutuelle et de la gestion des accès multiples. Nous avons considéré plus
particulièrement les algorithmes d’exclusion mutuelle distribués basés sur l’échange du jeton.
Nous avons apporté des améliorations à deux de ces algorithmes à savoir : Le Lann et Naimi-
Tréhel. Ces améliorations ont pour objectif de supporter l’insertion et la suppression
dynamique de sites. Ainsi, nous avons établi des techniques permettant d’ajouter et de
supprimer un site de l’anneau régissant l’algorithme Le Lann. Nous avons ensuite ajouté des
procédures permettant d’insérer et de supprimer un site de l’arborescence Naimi-tréhel. Les
algorithmes ainsi obtenus peuvent servir de mécanismes d’implémentation de protocoles de
gestion et de contrôle de "floor".

Au niveau de l’implémentation, nous avons réalisé, dans un premier temps un système

de téléconférence basé sur la politique présidée. Cette implémentation a été effectuée à l’aide
de java et JMF (Java Media Framework) par-dessus un réseau local sous Linux. Nous avons
aussi implémenté un système à politique explicite en utilisant le mécanisme d’exclusion
mutuelle distribué que nous avons élaboré. Cette implémentation a été effectué par-dessus les
outils audio et vidéo de l’environnement Platine. Nous avons utilisé ces deux implémentations
pour la réalisation d’une application CSCL (Computer Supported Cooperative Learning).
Cette application permet l’accompagnement des étudiants dans leur processus d’apprentissage
pour la préparation des exercices relatifs à un cours.

Comme perspective à ce travail, nous prévoyons trois volets différents. Le premier volet
concerne le passage à l’échelle. En effet, les implémentations mentionnées ci-dessus, ont été
effectuées sur des réseaux locaux (Linux ou Microsoft). Nous projetons ainsi les déployer sur
Internet. Le deuxième volet prévoit l’étude des besoins de ces systèmes en vue de supporter la
mobilité des participants. Dans des plateformes mobiles, le participant doit pouvoir retrouver

161
le même environnement du système de téléconférence après un éventuel déplacement. La
gestion de la conférence et des ressources partagées doit prendre en compte ces aspects. Le
dernier volet concerne la mise en œuvre d’autres applications coopératives au-dessus des
systèmes implémentés. Ces applications concernent le télétravail (exemple de séance
parlementaire à distance) et le télé-enseignement (classe de cours virtuelle).

162
Bibliographie

Références

[Ande 00] G. Anderson, N. Graham and T. Wright, "Linking Conceptual and

Implementation Architectures of Multiuser Interactive Systems", ICSE’00,
2000.
[Ango 93] Paul Angosto, Benoît Caillaud, Michel Delaure, Rémi Guestchel, Bernard
Jouga, Dominique Le Foll, Jean-Jacques Maret, Pierre Rocher, Gilles Vaucher,
"L’ingénierie des protocole", InterEditions 1993.
[Bann 93] L.J Bannonand K. Kuutti, "CSCW: An Initial Exploration", Scandinavian
Journal of Information Systems, Vol 5,3-24, 1993.
[Baec 94] R. Baecker, G. Glass, A. Mitchell and I. Posner, "SASSE: The Collaborative
Editor", In Proceeding of ACM Conference on Human Factors in Computing
Systems, Volume 2, pp. 459-460, 1994.
[Baud 01a] V. Baudin, K. V. Royo, P. Owezarski, T. Gayraud, S. Owezarski, "Une
Visioconférence sur IP", 4 èmes Journées Réseaux 2001 (JRES’2001), Lyon,
10-14 décembre 2001.
[Baud 01b] V. Baudin, K. V. Royo, P. Owezarski, T. Gayraud, S. Owezarski, "Une
Approche Synchrone pour uneTélé-expertise Distribuée", Premières journées
francophones sur les modèles formels de l'interaction, MFI’01, Toulouse,
2001.
[Baud 02] V. Baudin, S. Owezarski, "Plate-forme de Télé-ingénierie Coopérative
Synchrone Distribuée", Rapport LAAS 02517, 2002.
[Bell 96] N. Bellamine, "Contributions Méthodologiques à la Conception de
Collecticiels", Thèse de Doctorat, Université Toulouse I, 1996.
[Boch 90] G.v. Bochmann, M. Barbeau, M. Erradi, L. Lecompte, P. Mondain-Monval
and N.Williams, "Mondel: An Object-Oriented Specification Language".
Publication 748. Département d'informatique et de recherche opérationnelle,
Université de Montréal. November 1990.

163
[Borm 01] C. Bormann, J. Ott and H. Kutscher, "SCCP: Simple Conference Control
Protocol", Internet Draft, draft-ietf-mmusic-sccp-01-txt, February 13, 2001.
[Bour 00] G. Bourgin, "Un Support Informatique à l’Activité Coopérative Fondé sur la
Théorie de l’Activité", Thèse de Doctorat Informatique, Université des
Sciences et Technologies, 2001.
[Bout 01] C. Bouthier et G. Cannals "Le Contexte Comme Base de Conscience de
Groupe", CTE, Troyes, 2001.
[Bowe 95] J. Bowers and G. Button, "Workflow from Within and Without", European
Conference on Computer Supporter Cooperative Work (ECSCW’ 95), 1995.
[Cava 88] A. Cavalli, E. Paul, "Exhaustive Analysis and Simulation for Distributed
Systems", Both sides of the same coin, Distributed computing, 1988.
[Chou 95] R. Choudary and P. Dewan, "A Genaral Multi-User Undo/Redo Model",
European Conference on Computer Supporter Cooperative Work (ECSCW’
95), 1995.
[Cout 99] J. Coutaz, F. Bérard, E. Carraux and W. Astier "CoMedi: Using Computer
Vision to Support Awarness and Privacy in Media Spaces", ACM Conference
on Human Factors and Computing Systems (CHI’99), ACM Press, pp 13-14,
1999.
[Cout 01] J. Coutaz, "Architecture Logicielle Conceptuelle des Systèmes Interactifs",
Livre, Analyse et Conception de l’IHM : Interaction Homme-Machine pour les
SI, Hermès, 2001.
[Crow 95] T. Crowley, P. Milazzo, E. Baker, E. Forsdick and R. Tomlinson, "MMConf:
An Infrastructure for Building Shared Multimedia Applications", Proceeding
of ACM Conference on CSCW, 1995.
[Davi 92] R. David, H. Alla, "Du Grafcet aux réseaux de Petri", Editions Hermes, Paris,
1992.
[Davi 98] B. David, "Apports de la Technologie Informatique à l’Ingénierie
Concourante : Cas du Workflow et du Groupware", L’entreprise
Communicante, Paris : Hermès, 1998.
[Deco 96] D. Decouchant, V.Quint et M Romero, "Groupware and Authoring", Acdemic
press, 1996.
[Deer 91] S. Deering, "Multicast Routing in a Datagram Internetwork", Phd Thesis,
Stanford University, California, USA, 1991.

164
[Deer 99] S. Deering., W.Fenner and B.Haberman, "Multicast Listener Discovery (MLD)
for IPv6", RFC 2710, October 1999.
[Dewa 00] P. Dewan, "An Integrated Approach to Designing and Evaluating
Collaborative Applications Infrastructures", Journal of Computer-Supported
Cooperative Work (JCSCW), 2001.
[Dix 93] A. Dix, J. Finlay, G. Abowd and R. Beale "Human Computer Interaction",
Prentice-Hall, 1993.
[Domm 97] H.-P. Dommel and J.J. Garcia-Luna-Aceves, "Floor Control for Multimedia
Conferencing and Collaboration", Multimedia Systems (ACM/Springer), Vol.
5, No. 1, January 1997.
[Domm 99] H.-P. Dommel and J.J. Garcia-Luna-Aceves, "Efficacy of Floor Control
Protocols in Distributed Multimedia Collaboration", Cluster Computing
Journal, Special issue on Multimedia Collaborative Environments, Vol. 2, No.
1, 1999.
[Domm 03] H.-P. Dommel, "Peer-to-Peer: Technology and Trends", Magazine of the
Association of Internet Professionals, Apr/May 2003.
[Domm 04] H. P. Dommel and S. Verma, "Multipoint Synchronization Protocol", Proc.
IEEE Int. Conference on Systems, Man and Cybernetics (SMC'04), The
Hague, The Netherlands, Oct. 10-13, 2004.
[Dorc 95] T. Dorcey, "The CU-SeeMe Desktop Videoconferencing Software",
ConneXions – The Interoperability Report, Vol. 9, No 3,1995.
[Dour 96] P. Dourish, "Open Implementation and Flexibility in CSCW Toolkits",
Computer Science Thesis, University College of London, Londres, 1996.
[Dour 98] P. Dourish, "Introduction: The State of Art of Computer Supported
Cooperative Work", the Journal of Collaborative Computing, 7 N° 1 et 2
(Interaction and Collaboration in MUDs, 1998.
[Ech- 01] M. D. Ech-chrif El Kettani, "KBT : Conception d’une Architecture Générique
de Protocoles de Routage Multipoint Inter Domaine", Thèse de Doctorat
d’Etat, soutenue à l’Ecole Mohammadia des Ingénieurs, 2001.
[Ehri 85] H. Ehrig and B. Mahr, "Fundamentals of Algebraic Specification 1 –
Equations and Initial Semantics", Volume 6 of EATCS Monographs on
Theoretical Computer Science, Springer-Verlag, Berlin, 1985.
[Elli 91] C. Ellis, S. Gibbs and G. Rein, "Groupware: Some Issues and Experiences",
Communications of the ACM, 34(1)38-58, 1991.

165
[Elli 94] C. Ellis, and J. Wainer, "A Conceptual Model of Groupware", In Proc.
CSCW’94, ACM Press, 1994.
[Elli 99] C. Ellis, "Workflow Technology", Computer Supported Cooperative Work,
Beaudouin-Lafon, Trends in Software, 1999.
[Fenn 97] W. Fenner, "Internet Group Management Protocol, Version 2", RFC 2236,
IETF, 1997.
[Finn 97] K. Finn, A. Sellen and S. Wilbur, "Video Mediated Communication",
Lawrence Erlbaum Associates, 1997.
[Fluc 95] F. Fluckiger, "Understanding Networked Multimedia Applications and
Technology", Prentice Hall, New York, 1995.
[From 98] M. Fromme and H. Pralle, "An Address Resolution and Key Exchange Protocol
for Conferencing Applications on the Internet, Confman 2.0", Interactive
Distributed Multimedia Systems and Telecommunication Services, 5th
International Workshop, IDMS'98, Oslo, Norway, 1998.
[Gree 95] S. Greenberg, C. Gutwin and A. Cockburn, "Sharing Fisheye Views in
Relaxed-WYSIWIS Groupware Applications", Proceeding of Graphics
Interface, Distributed by Morgan Kaufmann, pp. 22-24, Toronto 1995
[Gree 98] S. Greenberg and M. Roseman, "Using a Room Metaphor to Ease Transitions
in Groupware", Technical Report 1999-425, Department of Computing and
Information Science, University of Calgary, Calgary, 1998.
[Greg 99] W. Greg, "Architecture for Synchronous Groupware", Technical Report 1999-
425, Department of Computing and Information Science, Queen’s University
Kingston, Ontario, 1999.
[Greif 88] I. Greif, "CSCW: What does it mean?", CSCW’ 88. Proceedings of the
Conference on Computer-Supported Cooperative Work, September 26-28,
1988, Portland, Oregon, ACM, New York, NY, 1988.
[Gutw 95] C.Gutwin and S. Greenberg, "Support of Awarness in Real-time Descktop
Conferences", Proceeding of the 2nd New Zealand Computer Science
Research Students’ Conference, University of Waikato, April 1995.
[Gutw 00] C.Gutwin and S. Greenberg, "The Mechanism of Colaboration: Developing
Low Cost Usability Evaluation Methods for SharedWorkspaces", IEEE 9th
Internationnal Workshop on Enabling Technologies: Infrastructure for
Collaborative Entreprises (WET-ICE’00), 2000.

166
[Hahn 91] U. Hahn and M. Jarke, "Teamwork Support in a knowledge-Based Information
System Environment", IEEE Transactionson Software Engineering, 17(5), pp
467-482, Mai 1991.
[Haak 03] J. M. Haake, T. Schümmer, and A. Haake, "Supporting Collaborative
Exercises for Distance Education", Proceedings of the 36th Hawaii
International Conference on System Sciences (HICSS’03), 2003.
[Hand 97] M. Handley, V. Jacobson, "SDP : Session Description Protocol", RFC 2327,
1997.
[Hand 98] M. Handley, V. Jacobson, "SIP : Session Initiation Protocol", RFC 2543,
1998.
[Hilt 01] Volker Hilt, Claudia Schremmer, Christoph Kuhmünch, Jürgen Vogel,
"Creation and Use of Multimedia Teachware in synchronous and
asynchronous Teleteaching", WI-Schwerpunkthef, Virtuelle Aus- und
Weiterbildung" 43 (01/2001), pp. 23-33, February 2001.
[Hoft 98] G.H.T. Hofte, "Working Aport Together", Volume. N° 001, Electronique ed,
Ensschede, The Netherlands: Telmatica Institut, 1998.
[Holz 91] G.J. Holzmann, "Design an Validation of Computer Protocol", Prentice-Hall,
1991.
[Ibri 02] A. Ibriz and M. Erradi, "Cooperative Session Control over SIP", Internet and
Information Technology, CIIT’02, Virgin Island, USA, 2002.
[ISO 88] International Organisation for Standardisation (ISO), IS 8807 "Information
Processing Systems, Open Systems Interconnection, LOTOS – A Formal
Description Technique Based on the Temporal Ordering of Observational
Behavior", July 1988.
[ISO 89] International Organization for Standardization (ISO), "ESTELLE, A Formal
Description Technique based on Extended State Transition", International
Standard, ISO-9074, 1989.
[ITU 88a] International Telecommunication Union, "Pulse Code Modulation (PCM) for
Voice Frequencies", ITU-T Recommendation G.711, 1988.
[ITU 88b] International Telecommunication Union, "SDL User Guidelines". IUT-T
Z100, 1988.
[ITU 93a] International Telecommunication Union, "Recommandation H.320, Narrow-
band Visual Telephone Systems and Terminal Equipment", ITU-T
Recommendation H.320, 1993.

167
[ITU 93b] International Telecommunication Union, "Recommandation H.261 : Codec
Vidéo pour services audiovisuels à p* 64 kbits/s", ITU-T Recommendation
H.261, 1993.
[ITU 95a] International Telecommunication Union, "Adaptation of H320 Visual Telepone
Terminals to B-ISDN Environments", ITU-T Recommendation H.321, 1995.
[ITU 95b] International Telecommunication Union, "Visual Telephone Systems and
Equipment for Local Area Networks Which Provide a Non-Guaranteed Quality
of Service", ITU-T Recommendation H.322, 1995.
[ITU 95c] International Telecommunication Union, "Control Protocol for Multimedia
Communication", ITU-T Recommendation H.245, 1995.
[ITU 95d] International Telecommunication Union, "Media Stream Packetization for
Visual Telephone Systems on Non-Guaranteed Quality of Service LANs", ITU-
T Recommendation H.225, 1995.
[ITU 95e] International Telecommunication Union, "Recommendation H.263 : Video
Coding for Low Bitrate Communication", ITU-T Recommendation H.263,
1993.
[ITU 96a] International Telecommunication Union, "Recommendation H.323 : Visual
Telephone Systems and Equipment for Local Area Networks which Provide a
Non-guaranteed Quality of Service", ITU-T Recommendation H.323,
November 1996.
[ITU 96b] International Telecommunication Union, "Data Protocols for Multimedia
Conferencing", ITU-T Recommendation T.120, November 1996.
[ITU 96c] International Telecommunication Union, "Multipoint Binary File Transfer
Protocol", ITU-T Recommendation T.127, November 1996.
[ITU 96d] International Telecommunication Union, "Generic Application Template",
ITU-T Recommendation T.121, November 1996.
[ITU 97] International Telecommunication Union, "Multipoint Still Image and
Annotation Protocol", ITU-T Recommendation T.126, November 1997.
[Jaco 98] V. Jacobson ans S. McCanne, "Using the LBL Network Whiteboard",
Technical Report; Lawrence Berkley Laboratory, 1998.
[Jard 94] C. Jard, "Contribution à la Vérification Dynamique des Protocoles",
Documents d’habilitation, IRISA+IFSIC, Université de Rennes 1, 1994.

168
[Joha 88] R. Johansen, "Current User Approaches to Groupware", Groupware:
Computer support for business teams. pp 12-44, New York: The Free Press,
1988.
[John 82] P. Johnson-Lenz and T. Johnson-Lenz, "Groupware: The Process and Impacts
of Design Choices", In Studies of Computer-Mediated Communication
Systems: A Synthesis of the Findings. Final Report of a Workshop, pages 45-
55. Computerized Conferencing and Communications Center, New Jersey
Institute of Technology, 1982.
[Kana 95] JR. Kanawati, "Un Modèle de Protection de Données pour les Applications
Coopératives", Journées jeunes chercheurs en systèmes réparties, Rennes,
1995.
[Kars 94] A. Karsenty, "Le Collecticiel: de l’Interaction Homme-Machine à la
Communication Home-Machine-Homme", TSI Technique et Sciences
Informatiques, 13(1):105-127, 1994.
[Kaus 98a] N., Crowcroft J. "General Conference Control Protoco" , 6th IEE conference
on telecommunication, 29th march – 1st april, Edinburgh, UK, 1998, pp 143-
152
[Kaus 98b] Kausar N., Crowcroft J. – "Floor Control Requirements from Reliable IP
Multicast" 8th IFIP Conference on High Performance Networking (HPN'98)
The Millennium Push of Internet, Vienna September 21-25, 1998
[Kaus 99] N., Crowcroft J. "An Architecture for Conference Control Functions" , Data
communication and voice networks Conference, SPIE Symposium ,19-22nd
September 1999, Boston MA
[Kuts 94] D. Kutscher, J. Ott and C. Bormann, "Session Description and Capability
Negociation", Internet Draft, IETF, 2002.
[Lamp 78] L. Lamport "Time, clocks and the ordering of events in a distributed
system", Communications of the ACM, Vol.21, N° 7, pp 558-565, July 1978.
[Lann 77] G. Le Lann "Distributed Systems - Towards a Formal Approach",IFIP
Congress, pp 155-160, 1977.
[Laur 00] Y. Laurillau et L. Nigay "Modèle de Navigation Collaborative Synchrone pour
l’Exploration des Grands Espaces d’Information", IHM’00, 2000.
[Laur 02a] Y. Laurillau et L. Nigay "Clover Architecture for Groupeware", CSCW’02,
New Orleans, USA, 2002.

169
[Laur 02b] Y. Laurillau et L. Nigay "Architecture Clover pour les Collecticiels", IHM’02,
Poitiers, France, 2002.
[Lauw 90] J.C Lauwers, K.A. Lantz and A.L. Romanow, "Replicated Architectures for
Shared Window Systems: a Critique ", In Proceedings of the Conference on
Office Information Systems ACM COIS’90, Boston, MA, USA, pp 249-260,
ACM Press, 1990.
[Lian 90] L. Liang, S.T. Chanson and G.W. Neufeld, "Process Groups and
Communications: Classifications and Requirements", IEEE Computer, pp. 56-
66, 1990.
[Lyon 98] F. Lyonnet, "Support des Applications Multimedia sur l’Internet Incluant des
Liens Sans-Fils", Thèse de Doctarat, Université Nice – Sophia, 1998.
[Mack 99] MW. Mackay, "Media Space: Environments for Informal Multimedia
Interaction", Computer Supported Cooperative Work, Beaudouin-Lafon,
Trends in Software, 1999.
[Maek 85] M. Maekawa "A N Algorithm for Mutual Exclusion Decentralized
Systems", ACM Transactions on Computer Systems, Vol. 3, N° 2, pp 145-159,
May 1985.
[Makk 94] K. Makki, "An Efficient Token-based Distributed Mutual Exclusion
Algorithm", Journal on Computer and Hardware Engineering, December 1994.
[Mant 94] M. Mantei, R. Baeker, A. Sellen, W. Buxton and T. Milligan, "Experience in
the Use of Media Space", In ACM SIGCHI Conference on Human Factors in
Computing Systems, pp 203-208, 1991.
[Mari 94] J. Mariani, T. Rodden and J.Trevor, "The Use of Adapters to Support Sharing",
Technical Report, Lancaster University, 1994.
[Minö 93] S. Minör and B. Magnusson, "A Model for Semi-Synchronous Collaborative
Editing", Proceeding ACM Conference on CSCW, 1993.
[Naim 87] M. Naimi, M. Tréhel "An Improvement of the log (n) Distributed Algorithm
for Mutual Exclusion", 7 th International Conference on Distributed
Computing, pages 371-375, 1987.
[Naim 96] M. Naimi, M. Tréhel and A. Arnold, "A O(log(n)) Distributed Mutual
Exclusion Algorithm Based on Path Reversal", Parallel and Distributed
Computing 34, pp 1-13, 1996.
[Ohmo 92] T. Ohmori, K. Maeno, S. Sakata, H. Fukuora and K. Watab, "Distributed
Cooperative Control for Sharing Application Based on Multiparty Desktop

170
 Conferencing System: MERMAID", IEEE Proceedings of the international
Conference on Distributed Computing Systems, Berlin, 17(1): 538-546, June
1992.
[Oual 02] M. Oualla, M. Ouzzif and M. Erradi, "Implementation of a Multimedia
Teleconferencing system over Internet", IWCSE, Marrakech, December 2002.
[Ouzz 00a] M. Ouzzif, M. Erradi and A. Schaff, "An SDL Specification of Coordination
Protocol within a Teleconferencing System", ISIVC2000, Rabat, 2000.
[Ouzz 00b] M. Ouzzif, M. Tréhel, "Insertion de Nouveaux Participants à une Conférence
sur un Réseau ; Adaptation d’Algorithmes d’Exclusion Mutuelle Distribués à
Jeton", ISIVC2000, Rabat, 2000.
[Ouzz 02a] M. Ouzzif, M.Erradi, "Formal Description of Teleconferencing Management
and Control Protocol", IEEE, IWCSE, Marrakech, December 2002.
[Ouzz 04] M.Ouzzif et M. Erradi, "Un Protocole de Floor Control basé sur un
mécanisme d’exclusion mutuelle distribué dynamique", NOTERE’04, Saidia,
Maroc, 2004.
[Owez 97] Philippe Owesarski, Veronique Baudin et Michel Diaz, « Conception et
développement d’un système synchrone de télé-formation professionnelle ».
Calculateurs parallèles, Volume 9, numéro 2, 1997.
[Pale 02] L. Palen and J. Grudin, "Discretionary Adoption of Group Support Software:
Lessons from Calendar Application", Livre – Organisational Implementation
of Colaboration Technology, MUNK, 2002.
[Paul 97] S. Paul, K. Sabnani D.J.C Lin and S. Bhattacharyya, "Reliable Multicast
Transport Protocol (RMTP)", IEEE Journal on Selected Areas in
Communications, Vol. 15, N°.3, pp 407-42, 1997.
[Perr 97] M. Perry, "CONFCNTLR: A Video Conference Controller", masters thesis in
San Francisco State University, December 1997.
[Pnue 77] A. Pnueli, « The Temporal Logic of Programs », In Wizard V. Oz an Mihalis
Yannakakis, editors, Proceedings of the 18th Symposium on Foundations of
Computer Science, pages 46-57, 1977.
[Rica 81] Glenn Ricart, Ashok K. Agrawala "An Optimal Algorithm for Mutual
Exclusion in Computer Networks", CACM 24 (1) : 9-17, 1981.
[Roqu 00] P. Roques, F. Vallée, "UML en action : De l’analyse des besoins à la
conception en Java". Deuxième Tirage, Eyrolles, 2000.

171
[Rumb 99] J. Rumbaugh, I. Jacobson, G. Booch, "The Unified Modeling Language
Reference Manual", Addison-Wesley, 1999.
[Rodr 01] L.M. Rodriguez Peralta, T. Villemur, K.Drira, "An XML architecture for a
synchronous session model ", PDPTA’01, 2001.
[Rodr 02] L.M. Rodriguez Peralta, T. Villemur, K.Drira, J.Mmolina, "Managing
dependencies in dynamic collaborations using coordination diagrams",
OPODIS’02, 2002.
[Salb 95] D. Salber, "De l’interaction Individuelle aux Systèmes Multi-utilisateurs
L’exemple de la Communication Homme-Homme-Médiatisée", Thèse de
Doctorat Informatique, Université Joseph Fourier, Grenoble, 1995.
[Sass 94] M.A.Sasse, Claus-Dieter Schulz, Thierry Turletti "Remote Seminars through
Multimedia Conferencing : Experiences from the MICE project",
INET/JENC5 1994.
[Schu 96] H. Shulzrine, "RTP: A Transport Protocol for Real-Time Appliactions", IETF
RFC, 1996 ConneXions- The Interoperability Report, Vol. 8, No 10, October
1994.
[Schu 98] H.Schulzrinne, "A Comparison of SIP and H.323 for Internet Telephony",
proceedings of the Network operating System Support for Digital Audio and
Video (NOSSDAV '98), Cambridge, 1998.
[Schu 04] H. Schulzrinne, K. Singh and X. Wu, "Programmable Conference Server",
Columbia University Technical Report CUCS-040-04, New York, NY, Oct
2004.
[Sein 97] L. Seinturier, L. Duchien and g. Florin, "A Design and an Observational
Approach for Group BehaviourDesign Patterns", Proceedings of the European
Conference on Technologies of Object-Oriented Languages and Systems
(Tools Europe 97), Paris 1997.
[Shen 94] H. Shen, "Access Control for Collaborative Environment", PhD Thesis, Purdue
University, Lafayette, 1994.
[Sing 89] M. Singhal "A Heuristically Aided Algorithm for Mutual Exclusion in
Distributed Systems", IEEE Transactionson Computers 38 (5),, pp 651-662,
1989.
[Suzu 85] I. Suzuki and T. Kasami "A Distributed Mutual Exclusion Algorithm",
ACM Transactions on Computer Systems, volume 3, pp 334-349, 1985.

172
[Stef 87] M. Stefik, D.G. Bobrow, g. Foster, S. Lanning and D. Tartar, "WYSIWIS
Revised: Early Experiences with Multiuser Interfaces", ACM Transaction on
Office Information Systems, 5(2): 147-186, April 1987.
[Tarp 97 ] F. Tarpin-Bernaud, "Apports des Collecticiels à l’Ingénierie Concourante",
PRIMECA’97, La Plagne, 1997.
[Tros 00] D. Trossen, "Scalable Group Communication in Tithgly Coupled
Environmentsl", PhD Thesis, University of Technology, Aschen, Germany,
Sept 2002.
[Turl 95] T. Turletti, "The INRIA Videoconferencing System (IVS)", ConneXions- The
Interoperability Report, Vol. 8, No 10, October 1994.
[Turn 93] Kenneth J. Turner, "Using Formal Description Techniques : An Introduction to
ESTELLE, LOTOS and SDL", John Wiley, 1993.
[Vill 03] T. Villemur, L. M. Rodriguez Peralta, K. Drira, "Conception d'un service de
gestion de session orienté modèle pour des groupes collaboratifs synchrones",
CFIP’03, 2003.

[Whet 97] B. Whetten, T. Montgomery and S.Kaplan, "A High Performance Totally
Multicast Protocol", Theory and Practice in Distributed Systems, LNCS, 1997.
[Whit 00] S. Whittaker, B. Nardi and E. Bradner, "Interaction and Outeraction: Instant
Messaging in Action ", CSCW’00, 2000.
[Wu 02] X. Wu, "Use SIP and SOAP for Conference Floor Control", Internet Draft,
IETF, Feb 2002.
[Yerg 96] F. Yergeau, "UTF-8, A Transformation format of Unicode and ISO 10646",
RFC 2044, October 1996.
[Zafe 01] A. Zafer, "A Collaborative Editor", Mémoire de Master Scientifique en
Informatique, Université de Virginie, 2001.
[Zhan 93] L. Zhang, S. Deering, D. Estrin, S. Shenker, D. Zappala, "RSVP: A New
Resource ReSerVation Procol", Proc. IEEE Network, 1993.

Sites WWW

[Blac 01] http://www.blackboard.com.

173
[Bliz 02] http://www.blizzard.com/worlds-starcraft.shtml.

[Clix 00] http://www.l-3.de/en/index.html

[Conf 04]http://www.rvs.uni-hannover.de/products/confman/v2.0/

[East 02] http://www.eastgate.com.

[Grov 04] http://www.groove.net/

[Idso 02] http://www.Idsoftware.com/quake.

[Inte 03] http://www.interwise.com/.

[IVS 03] http://www-sop.inria.fr/rodeo/ivs.html

[Mbon 02] http://www.softlab-nsk.com/Pro/Mbone.html

[Qual 02] http://www.Qualcomm.com.

[Usab 02] http://www.usabilityfirst.com/glossary/cat_40.txl

[VNC 02] Virtual Network Computing application: http://www.uk.research.att.com/vnc

[Webc 03] http://niobe.fernuni-hagen.de/WebAssign.

174