1. Projet de session – Relais de flux de
vidéo et qualité de service
Automne 2012
Professeur Alejandro Quintero
Remis au Chargé de laboratoire Aurel RANDOLPH
Pour le 28.11.2012
Noms
Matricules
Aïouadj
Djamel
1523722
YANO TCHATCHOUANG
I.
Prénoms
Claudia
Introduction
1394741

2. Dans le cadre du cours INF3405 (Réseau Informatique), nous avons été emmené à
faire un projet sur le relai de flux de vidéo. Le projet en question est composé de deux
parties : La première qui consiste à réaliser une communication entre un client et un
serveur. Le client envoi à ce serveur une requête et ce dernier doit pouvoir recevoir la
requête et envoyer un acquittement. Aussi, ce serveur doit pouvoir communiquer avec un
autre serveur de streaming dans le cas où il n’y a pas le flux demandé par le client. La
deuxième partie par contre consiste à analyser le flux de trafic vidéo en écoutant les
enregistrements de flux vidéo entre le serveur et le serveur de streaming à l’aide d’outil
d’écoute.
II.
Présentation des résultats
1) Partie A
Dans cette partie, nous avons pu programmer à l’aide du logiciel Visual Basic studio
2010 le client et le serveur dans des solutions indépendantes. Les fichiers .cpp sont remis
en annexe de ce rapport. Nous nous sommes basé sur les codes sources du laboratoire3
qui nous avaient été donnés.
Titre : Schéma présentant la communication entre le client et les deux serveurs
La logique appliquée ici est la suivante et les détails de cette dernière s’illustre dans
les codes .cpp

3. Le résultat obtenu est le suivant :

4. Titre : Schéma présentant la lecture de la vidéo par le serveur relai (à gauche) et le
client (à droite)
2) Partie B
Dans cette partie, nous avons simulé le trajet des paquets lors de l’échange entre le
serveur de relais et le serveur de streaming. À l’aide du logiciel Wireshark, voici un
exemple d’enregistrement d’échange de trafic au niveau des serveurs.

5. III. Difficultés rencontrées et suggestions
1) Difficultés rencontrées
Les difficultés rencontrées au cours de ce projet sont nombreuses et sont les suivantes :
L’énoncé du projet n’était pas clair au départ et ça nous a pris du temps pour
comprendre ce que l’on attendait de nous
Le projet n’a pas un lien direct avec le cours dans la mesure où le cours de réseau
informatique n’est pas un cours de programmation. Les étudiants qui ne sont pas à
l’aise en programmation avaient plus de difficultés.
Le logiciel utilisé pour l’analyse du trafic n’est pas fourni avec un guide. Ceci
rend l’analyse encore moins clair car, on ne sait pas trop ce qu’on fait.
Nous avons rencontrés certains messages d’erreurs (voir schéma ci-dessous) que
nous n’avons pas pu comprendre. Malgré ces erreurs, la vidéo parvenait quand
même à être lue.

6. Titre : Schéma présentant la lecture de la vidéo0004 avec des messages d’erreurs.
2) Suggestions
Avoir une séance de tutorat ou un guide d’utilisation
disponible du
logicielOmniPeek ou Wireshark tel que dans le cours de transmission de
l’information (ELE3705)
Tenir compte du niveau de programmation de chaque étudiant (Informatique et
Biomédical) lors des projets.
IV. Réponses aux questions de l’analyse
Diagramme de communication
Ci-dessous, le diagramme de communication entre le serveur de streaming
(132.207.29.194) et le serveur relais (132.207.29.125).

7. Encapsulation des trames RTP
Ci-dessous le diagramme d’encapsulation d’une trame RTP :
Ethernet
Data
IPv4
Data
UDP Data
RTP

8. Décrivez le format de l’entête du protocole RTCP et précisez les différents champs
impliqués.
Header
L’entête du protocole RTCP est constitué des champs suivants :
Le champ Version (2bits)
Le champ Padding (1 bits) qui indique s’il y a eu bourrage ou non(bourrage dont la taille
est indiquée dans le dernier octet)
Le champ Reception Report count (5 bits) qui est le nombre de compte-rendus dans le
paquet
Le champ Packet Type (8 bits) indiquant le type de paquet : RR (201) ou SD (200)
Le champ length (16 bits) longueur du paquet
Le champ SSRC (32 bits) qui identifie la source

9. Format du rapport RR (Receiver Rapport)
Suite au tri fait sur la liste des trames reçues à l’aide de WireShark, nous obtenons les
trames Receiver Report (RTCP) suivantes :
Une trame RR est constituée comme suit :
L’entête de la trame RTCP
Le champ SSRC-n (32 bits) numéro de la source dont le flux est analysé
Le champ fraction lost (8 bits)
Le champ cumulative number of packets lost (24 bits)
Le champ extended highest sequence number received (32 bits)
Le champ interarrival jitter (32 bits) qui est une estimation de l'intervalle de temps d'un
paquet de donnés RTP (il s’agit du temps de gigue)
V.
Conclusion
Tout au long de notre projet, nous avons réalisé la communication entre un client et un
serveur relais, qui est un intermédiaire entre un serveur multimédia et le client.
Suite à cela, nous avons analysé le flux vidéo entre le serveur multimédia (serveur
streaming) et le relais ce qui nous a permis de nous familiariser avec l’outil de capture de
paquets WireShark et de mieux comprendre certains protocoles tels qu’UDP, TCP,
RTCP, RTP, ainsi que leurs dérivés.