Opérations relatives à la connexion

Nous identifions quatre opérations principales.

— Initiation d’une connexion

Un client peut envoyer à la centrale une demande de connexion avec un autre client dont la présence a été vérifiée (voir Annexe B). Plusieurs connexions peuvent être établies au cours de la même session.

Notons ce que nous entendons par connexions parallèles: deux ou plusieurs connexions pou- vant être établies simultanément. Les connexions séquentielles désignent une exécution suc- cessive de connexions. Autrement dit, le client ne peut initier une connexion que si aucune autre connexion n’est en cours.

Les connexions sont ici parallèles (le client peut mettre en attente un appel qui est en cours et initier une nouvelle connexion A ou A/V).

Enjeux d’établir plusieurs connexions

Nous supposons que la centrale est capable de gérer autant de demandes de connexions possibles et que la bande passante du client peut satisfaire les demandes de connexions (le cas échéant, les flux média vont être interrompus en gardant les connexions actives). Le problème qui pourrait se poser est du côté client: disponibilité des ressources du client (CPU, réseau, écran). Le client doit contribuer à ce niveau.

Afin d’initier une connexion:

— Prérequis: le client B doit être présent. — Messages de signalisation:

Plusieurs messages sont échangés. La figure 3.1 présente la machine d’état englobant les états et les messages pour cette opération.

Client à la centrale: le message de demande de connexion indique le client à appeler (client B). Il comporte aussi le média à partager (choisi par le client A), l’adresse IP du client A, le port de réception du média ainsi que l’identificateur de la session.

Centrale au client: la centrale échange avec les clients plusieurs messages provisoires avant d’établir la connexion. Tous ces messages réfèrent à la session en mentionnant l’identificateur de la session.

— La centrale achemine la demande de connexion au client B. Le message d’invitation contient l’information sur le client appelant ainsi que le média à partager.

— Le client B peut accepter la demande de connexion. Il envoie un message à la centrale contenant son adresse IP et le port de réception du média.

— Après avoir reçu la réponse du client B, la centrale envoie une notification au client A l’informant si la demande de connexion est acceptée ou refusée.

— La centrale, ayant déjà les informations des codecs supportés par les deux clients, établit un codec commun pour le média choisi. Elle envoie par la suite à chacun des

Chapitre 3. Description et simulation d’un cas d’étude 19 deux clients la description de l’autre client (adresse IP et port de réception du média) ainsi que le codec à utiliser. La centrale attribue enfin un identificateur de connexion. Cet identificateur sera unique et commun entre les deux clients pour cette connexion puisqu’il s’agit de la même connexion.

Dans cette approche, le client communique à coup sûr. Une alternative serait de proposer la connexion des deux côtés, et d’annuler si l’un des clients refuse. Le nombre d’opérations ne devrait néanmoins pas être sensiblement différent.

Intérêt de l’identificateur de connexion:nous verrons par la suite que les clients pourront faire une variation en cours d’appel (ajout d’un flux média, changement de codec). Le client devrait donc aviser la centrale du changement. Puisqu’un client peut avoir plusieurs connexions au cours de la même session, un identificateur de connexion s’avère obligatoire. Aussi, le client doit informer la centrale en cas de rupture de connexion.

— Informations connues de la centrale à la fin de cette opération: la centrale connait le nombre de connexions actives pour chacun des clients A et B.

— Rejet d’une connexion

Le rejet d’une connexion peut être fait de la part de la centrale ou du client: — Côté client:

— Choix du client: le client refuse l’appel.

— Le client ne répond pas: la centrale attribue un temps de vie à la demande de connexion durant lequel le client doit donner suite à la demande.

— Rejet de l’appel dans le cas où l’appareil client n’est plus capable d’accepter de nou- velles connexions.

— Côté centrale:

— La centrale reçoit la demande de connexion du client initiateur, mais avant de l’ache- miner au deuxième client, ce dernier n’est plus présent.

— Le client peut envoyer à la centrale une information de statut (occupé, ne pas déran- ger). Sur la base de cette information, la centrale peut décider de refuser ou d’accepter la demande de connexion.

Client A présent

Demande de connexion envoyée à la centrale

Demande envoyée au client B

Client B accepte?

Informations reçues par la centrale

Description du pair reçue par le client

Clients ont chacun la description du pair

Envoyer demande de connexion {média, IP, port}

{micro, caméra}

Acheminer la demande de connexion à B

non

oui Notifier client A

Client B envoie ses informations de connectivité {IP, port}

Refus de la demande

La centrale choisit un codec commun

Envoyer la description du pair au client Vérifier ressources

Figure 3.1 – Machine d’état pour l’initiation de connexion

— Modification de paramètres

Cette opération correspond à une variation lors d’une communication: ajout, suppression ou modification d’un paramètre au cours de la communication (changement de codec par

Chapitre 3. Description et simulation d’un cas d’étude 21 exemple, adaptation aux conditions du réseau). L’opération peut être initiée par le client ou par la centrale.

— Prérequis: la connexion est en cours. — Messages de signalisation:

Les messages peuvent être échangés de bout en bout ou par l’intermédiaire de la centrale. Pour notre cas d’étude, nous choisissons une synchronisation de bout en bout.

Un client ne peut pas exécuter automatiquement une variation sans passer par ces deux étapes:

— Annoncer: le client voulant faire une modification doit envoyer une requête de modi- fication et en attendre la réponse. Le message contient l’information sur la variation (le nouvel état du paramètre à varier), ainsi que les identificateurs de la session et de la connexion.

— Accepter: le client recevant une requête de modification répond avec un message d’ac- ceptation (ou refus) de la modification.

L’avantage de se coordonner de bout en bout est de permettre aux clients de modifier une connexion courante en cas de redémarrage de la centrale.

Les clients avisent par la suite la centrale du changement par rapport à la connexion. — Informations connues de la centrale: nouvel état du paramètre modifié.

— Rupture de connexion

Cette opération est établie de bout en bout. Les clients peuvent rompre l’appel et aviser la centrale par la suite; elle n’intervient pas au cours de la rupture. La centrale a le rôle de mettre à jour la liste des connexions actives après chaque rupture de connexion.

— Prérequis: la connexion est en cours. — Messages de signalisation:

Client à la centrale: identificateurs de sessions et de connexion, action de supprimer la connexion.

Centrale au client: pas de message de retour (le précédent est un message informatif de la part du client).

— Informations connues de la centrale:

— nombre de connexions actives pour le client; — nouvel état du client.