Mini-projet: creation d`une application VoIP simple.

Mini-projet: creation d’une application VoIP simple.
Cours de Multimédia
Le but de ce mini-projet est de vous montrer les différents éléments constitutifs d’une
chaine de transmission de la voix sur un canal de type internet. Nous allons réaliser une
application simplifiée, mais qui mettra en évidence la plupart des difficultés liées à la
transmission de contenus multimédia sur canal de type IP.
Parmis les problèmes à résoudre au niveau de chacun des interlocuteurs, on peut citer
1. l’établissement de la communication,
2. l’enregistrement du signal sonore,
3. la compression des échantillons obtenus,
4. la mise sous forme de paquets des données,
5. l’envoi des données,
6. la réception des données et leur resynchronisation avec l’émetteur,
7. la dé-paquétisation des données,
8. la décompression des données,
9. l’envoi des échantillons vers le périphérique de sortie audio.
10. la fermeture de la communication.
Nous ne considérerons pas les parties liées à l’établissement de la communication, gérées
par SIP ou H323. Par ailleurs, pour des questions de temps, nous ne compresserons pas
les données transmises. Ces deux aspects seront abordés dans le cadre d’un projet. Par
ailleurs, les aspects liés à l’annulation d’écho sortent du cadre du cours de multimédia et
font appel à des notions d’estimation et de traitement du signal.
1
Travail à rendre
À la date buttoir donnée en TP, vous devez rendre par voix électronique une archive
.zip ou .tar.gz qui contient :
– vos sources .c ;
– un rapport d’environs 10 pages en .pdf .
1
L’archive ne doit contenir aucun fichier binaire (sinon, elle risque d’être rejetée par le
serveur de mail. Et un projet non reçu est un projet non rendu. . .). Le rapport doit indiquer
le fonctionnement de votre programme, comment l’utiliser en pratique, ses points forts et
ses points faibles. Votre code source doit compiler sans aucun warning avec les options
-Wall -pedantic -std=c99 -D GNU SOURCE. Un makefile est le bienvenu, sinon indiquez
clairement comment compiler votre programme.
La notation tiendra compte, entre autre,
– de la clarté du code ;
– des commentaires du code (il doit y avoir ni trop, ni trop peu) ;
– des fonctionnalités du programmes ;
– de sa robustesse aux bugs ;
– de la forme du rapport (rédaction, présentation, syntaxe, respect des règles de typographie etc.).
Avertissement : ne seront pas pris en compte
– les archives dans un format autres que .zip ou .tar.gz ;
– les rapports dans un format autre que .pdf ;
– les programmes qui ne compilent pas sous linux avec les options demandées.
2
Environnement de travail
Ce mini-projet sera réalisé en C sous Linux en utilisant différents petits programmes
que vous aurez à adapter. Les bibliothèques utilisées sont les bibliothèques de programmation système/réseau standards sous Unix, ainsi que la bibliothèque ALSA (Advanced
Linux Souns Architecture) pour la programmation de la carte son. Le compilateur est gcc.
3
Programmation système et de la carte son
Le but est ici de se familiariser avec les appels systèmes de bases permettant la creation
d’un client et d’un serveur UDP, ainsi qu’avec le programmation basique de la carte son.
3.1
ALSA
Afin de pouvoir réaliser une application de VoIP, il est nécessaire de pouvoir lire des
fichiers son et d’enregistrer la voix. Récupérer sur http://www.lss.supelec.fr/perso/
kowalski les fichiers :
– test.wav : fichier de test pour la fonction de playback.
– playback.c : permet de lire un flux audio au format PCM.
– record.c : permet d’enregistrer une séquence au format PCM.
2
1. Compiler record.c : gcc -o record record.c -Wall -pedantic -lasound -std=c99
-D GNU SOURCE.
2. Enregistrer une séquence dans un fichier nomé my record.raw : ./playback > my record.raw.
3. Compiler playback.c : gcc -o playback playback.c -Wall -pedantic -lasound
-std=c99 -D GNU SOURCE.
4. Lire le fichier my record.raw avec le programme compilé : ./playback < my record.raw
5. Comment modifier le programme pour lire un fichier mono, échantilloné à 8kHZ sur
8 bits ? Le faire et tester le bon fonctionnement.
6. Utiliser les deux programmes précédent pour créer vos fonctions d’enregistrement et
de lecture.
3.2
Client/serveur UDP
Une communication sur IP peut se faire simplement avec une architecture de type
client/serveur. On utilise ici le protocole UDP, tout à fait adapté à la voix. Récupérer sur
http://www.lss.supelec.fr/perso/kowalski les fichiers :
– udp 2 stdout.c : permet d’afficher sur la sortie standard les données reçues sur une
socket UDP.
– stdin 2 udp.c : permet d’envoyer sur une socket UDP les données saisies sur l’entrée
standard.
1. compiler les deux programmes :
(a) gcc -o udp 2 stdout udp 2 stdout.c -Wall -pedantic -lasound -std=c99
-D GNU SOURCE.
(b) gcc -o stdin 2 udp stdin 2 udp.c -Wall -pedantic -lasound -std=c99 -D GNU SOURCE.
2. Identifier le programme serveur et le programme client.
3. tester en local, avec deux terminaux X, ces deux programmes.
4
Préparation
Chercher dans la RFC 3550 le contenu de l’en-tête d’un paquet RTP type.
1. Donner la liste des champs qu’il faudra obligatoirement remplir dans le cadre d’un
application de type téléphonie classique (2 interlocuteurs).
2. Pour l’application de téléphonie classique, définir une stucture C nommée RTP packet
(à l’aide de struct), permettant de stocker toutes les information de l’en-tête RTP
ainsi que les données (payload ).
3
3. Pour l’application de téléphonie classique, écrire une fonction ayant pour paramètre
d’entrée un RTP packet et permettant de fabriquer une chaine d’octets (char) qu’il
sera possible de transmettre à un socket de type UDP ou TCP. L’en-tête de cette
fonction pourra être par exemple
void prepare_packet(RTP_packet& packet, char& packet_to_be_sent,
int& packet_length);
où packet length indique le nombre d’octets packet to be sent.
5
Transmission temps réel
Dans cette première partie, nous allons réaliser une communication à l’aide d’un protocole RTP ou pseudo-RTP à partir de fonctions qui permettent d’écrire et de lire dans un
socket UDP.
5.1
Manipulations
1. À l’aide des programmes précédent, créer un programme client TestSocketClient
permettant d’envoyer une ligne de texte à un serveur via un socket UDP. Créez
un programme serveur TestClientServer permettant de récupérer ce paquet. Pour
tester les programmes, lancer le client et le serveur sur la même machine en utilisant
l’adresse 127.0.0.1 pour le serveur.
2. Envoyer maintenant 10 lignes de texte vers le serveur. La dernière ligne indiquera la
fin de la communication. Faire en sorte que le serveur se ferme correctement.
3. Adjoindre un en-tête RTP à chacune des 10 lignes de données. Au niveau du serveur,
récupérer et interpréter l’en-tête RTP puis afficher le texte.
4. Afin de simuler des problèmes de transmission, inverser l’envoi de deux paquets (par
exemple, envoyer le paquet 4 avant le paquet 3). Au niveau du serveur, faire en sorte
de remettre tous les paquets dans l’ordre. Pour cela, vous pourrez utiliser un tampon
circulaire à n lignes et exploiter l’en-tête RTP.
5. Emetter maintenant une ligne toutes les 0.5 s. Au niveau du serveur, faire en sorte
que les lignes soient affichées également toutes les 0.5 s, avec le retard le plus faible
possible. A nouveau, le tampon circulaire pourra être utile. Etudier l’influence de la
taille du tampon circulaire sur le nombre d’inversions de paquets que vous pouvez
tolérer.
6. Simuler une variabilité de délai de transmission des paquets en émettant une ligne
toutes les 0.5 ± ∆ s, avec ∆ ∈ [−0.4, 0.4] s. Vous aurez besoin de la fonction rand.
Au niveau du serveur, les lignes devront être affichées toutes les 0.5 s.
7. Tester l’ensemble en faisant communiquer deux ordinateurs différents. Prendre garde
à spécifier le même port du côté client et du côté serveur.
4
6
Mise en place
1. Modifier vos fonctions de manière à envoyer des paquets de 11025 octets vers un socket
UDP. Avec une fréquence d’échantillonnage de 44100 Hz, quelle est la périodicité
d’envoi des paquets ? Dans un premier temps, il ne sera pas nécessaire de placer une
en-tête RTP à vos paquets.
2. Modifier vos fonctions de manière à lire les échantillons, non pas depuis un fichier,
mais depuis un socket UDP. La taille des paquets est de 11025 octets.
3. Tester vos deux programmes. Attention à l’effet larsen, si vos ordinateurs sont proches.
Faites éventuellement le test entre deux salles.
4. Quelle est l’influence de la fréquence d’échantillonnage sur la qualité de transmission ?
Quelle est l’influence de la taille des paquets envoyés ?
5. Comment faut-il procéder pour avoir une communication bidirectionnelle ? Mettre
votre solution en œuvre et la tester.
À partir de ce point, placer un en-tête RTP à chacun des paquets, de manière à pouvoir
reconstituer l’ordre d’émission des paquets au niveau du récepteur.
1. Placer un en-tête RTP et simuler une variabilité de délai de transmission au niveau
du client. Faites en sorte de compenser cette variabilité au niveau du serveur.
2. Simuler au niveau du client un retard de transmission de 50 ms, 100 ms, 200 ms,
400 ms, 1 s. Commentaires ?
3. Simuler au niveau du client 1%, 5% puis 10% de pertes de paquets. Commentaires ?
5