MASSON Jérôme

CHOQUET Mathieu
HACHICHA Nabil

Tuteur : Rachid ELAZOUZI

Cahier des Charges

LOGICIEL DE
TELEPHONIE IP

Master 1
Année 2006-2007
 SOMMAIRE :

Remerciements ............................................................................................. 3

Introduction ............................................................................................. 4-5

JMF ............................................................................................. 6-7
Protocole de Transmission ............................................................................................. 8-10
QoS ............................................................................................. 11-12
Codecs ............................................................................................. 13-18

Conclusion ............................................................................................. 19
Bibliographie ............................................................................................. 20
 Remerciements

Nous remercions l'IUP d'avoir mis à notre disposition tout le matériel nécessaire.

Nous remercions le corps professoral pour l'ensemble des cours donnés.

Nous remercions notre tuteur Mr Elazouzi Rachid pour ses conseils , sa disponibilité et son
aide pour recadrer le projet à chaque étape afin d'être sûr de correspondre le plus possible à
l'objectif fixé.

Nous remercions aussi javasun pour son outil jmf.

 Introduction

L’évolution de la téléphonie ne se limite pas aux téléphone fixes ou GSM

conventionnels, elle touche aussi l’informatique où, grâce aux nouvelles technologies
permettant des débits de plus en plus élevés et l’optimisation de certains protocoles
de transfert, elle a permis à de multiples applications utilisant la voix et l’image en
temps réel de se développer, et cela sur différents aspects pratiques.

Notre projet consiste en la mise en place d'un logiciel de téléphonie sur IP.
Dans ce projet, ce logiciel devra à posteriori permettre à tous les membres de l’IUP
de l’utiliser comme téléphone standard. Ceci grâce à la mise en commun de plusieurs
projets réalisés à l'IUP comme le projet proxy SIP et celui sur Asterisk. Le but de ce
projet est de fournir un logiciel gratuit pour téléphoner partout dans le monde. Parmi
les dispositifs présent dans ce logiciel :
– Une grande variété de codecs (G711, , LPC10-15, GSM, et SPEEX)
– Les protocoles RTP et RTCP
– Le protocole SIP
– Le protocole SDP
– D'autres fonctionnalités techniques incluant l'appui de la tonalité etc.
– Un manuel d'utilisateur complet lisible de l'application qui explique tout ce
qu’un utilisateur (ou un développeur) devrait savoir.

En effet, la motivation majeure à l'élaboration de ce projet vient du fait que le

protocole SIP* devient le standard des télécommunications multimédia** (son,
image, etc.). SIP représente également le standard ouvert de VoIP (Voice Over IP,
voix sur IP) interopérable et le plus étendu. En d'autre termes, il s'agit d'une
technologie qui permet au réseau (et surtout aux personnes qui en dépendaient) de
consulter la disponibilité des autres. Au-delà de cela, la technologie SIP permet
aujourd'hui aux personnes de choisir leur moyen de communication avec les autres :
par téléphone, messagerie instantanée, e-mail ou vidéoconférence inter-bureaux en
temps réel.
Des solutions plus au moins adaptées à ce protocole existent déjà, l'originalité
de notre projet consiste à offrir un logiciel fort de part sa conception, documenté et
extensible à d'autres architectures (mise en place de passerelles vers des solutions
existantes, en l'occurrence skype etc.). Il faut savoir aussi que le Laboratoire
informatique d'Avignon (LIA) a un besoin majeur de test, c'est pour cela que le but de
cette première phase de réalisation est de produire une plateforme simple et efficace
qui permet d'être une base pour les différents tests.
 Ce projet s'étale sur trois ans, et par conséquent, nous serons au cœur de la
conception, c'est ce qui nous donne à notre charge une grande responsabilité quand au
choix des différents modules et technologies. Un autre facteur majeur à la réalisation
de ce projet est le besoin (exprimé par notre tuteur) d'un logiciel ou bien d'une
solution qui sera maîtrisable et améliorable de manière dynamique et non fastidieuse
comme c'était le cas l'année dernière avec un projet qui avait au départ les mêmes
intentions (développer un certain nombre d'extensions pour un logiciel de téléphonie
sur ip) et qui s'est voué malheureusement à l'échec, car les étudiants qui voulaient
faire des améliorations travaillaient sur un logiciel mal documenté et mal conçu.
Donc le besoin d'avoir une maîtrise du projet par l'IUP est un élément très important,
qui est à l'origine de ce projet.

* Session Initiation Protocol

** Wikipédia : http ://www.wikipedia.org
JMF
 Le début du second semestre fût en majeur partie consacré à l'etude de JMF et
de son API par le groupe projet.
Le découpage suivant a été mis en évidence : un étudiant se chargerait de
RTP/RTCP ainsi que de la QoS tandis que la gestion des codecs (GSM, SPEEX,
ILBC et G.711) incombait aux deux autres.

La majeure partie des problèmes rencontrés par chacun de nous ont été le fait
que cette API, aussi bien documentée, ne possédait pourtant de projet en faisant
l'usage ou du moins pas assez de documentation sur les codecs (codage) et une
utilisation explicite des parties RTP/RTCP.

API JMF : http://java.sun.com/products/java-media/jmf/2.1.1/apidocs/index.html

Manuel pour cette partie :

http://java.sun.com/products/java-media/jmf/2.1.1/guide/RTPArchitecture.html

Cette page nous a grandement servit dans le découpage du projet (partie JMF).
Il fallait donc traiter d'un coté RTP et de l'autre intégrer les codecs mais comment ?

Fonctionnement technique

L'application est organisée autour de six package:

Protocole de transmission
 Protocole de transmission
L'envoi de l'information et la récupération de la qualité de la transmission se
font grâce à deux protocoles qui vont de paire RTP et RTCP.
Le premier gère donc l'envoi de l'information et le second nous servira à
superviser la communication afin de réaliser et d'optimiser la QoS de l'application.

RTP (Real-time Transport Protocol) : description en Annexe 1

RTCP (Real Time Control Protocol) : description en Annexe 2

Cette partie est donc découpée en deux sous-parties l'envoi et la réception.

Les classes correspondantes sont :

ManageEnvoi (étendant un thread)

Elle s'applique donc à l'envoi d'un flux via un RTPManager configuré au

préalable après récupération de la capture par les codecs (audio ou vidéo)

ManagerReception (étendant un thread)

Elle s'applique à la réception du flux. En recevant ce flux, elle recrée ainsi le

flux de sortie en utilisant la méthode update du codec servant à avertir d'une arrivée
de streams (NewStreamEvent)

Lors de la génération du code, la partie RTP a été testée avec l'entrée du micro
standard sans codec de compression (ce qui donna des résultats concluants à l'iup).
Malheureusement, la majeure partie du problème résida dans le fait de faire une
partie assez générale et standardisée pour pouvoir adapter et implémenter la
connexion avec les codecs (ceci via la récupération du Processor configuré par
l'étudiant implémentant le codec).

Sur la fin du semestre, la mise en relation entre les parties RTP et codecs a été
fastidieuse voir difficile de part une mauvaise compréhension sur la manière de
récupération du flux soit lors de l'envoi soit lors de la réception.
rtp et rtpsession
Ces deux packages représentent la partie RTP du projet, qui permet de contrôler et d'acheminer la
communication audio, ils offrent la possibilité de démarrer une session rtp entre l'appelé et
l'appelant.
QoS
 QoS
La QoS est l'atout majeur sur lequel nous avions misé en début de semestre
(description et principe de la QoS en annexe 5).
Au cours de ce semestre, la partie QoS n'a été que la partie cachée du projet car
la partie RTP imposa une rigueur de fonctionnement pour avoir une base solide.

Concrètement, cette partie posa encore plus de problème que les autres car il
nous a été impossible de trouver des codes existants sur la récupération de
l'information sur la communication.
Pour la QoS, nous avons utiliser les fonctionnnalités de RTCP, grâce à sa
possbilité de FeedBack via reports qui nous permettrait de récuperer les informations
comme la gigue entre autres.

Cette partie sera décrite par la classe QoS mais elle n'apparaitra pas car
inutilisable.
Elle tentait de récuperer un feedback via l'interface report de jfm. Mais le peu
documentation et le temps ont fait défaut, cette partie ne sera qu'à l'origine de l'étude
réaliser par le groupe d'étudiant de l'année prochaine. En espérant que nos sources et
autres informations (annexes 5 et 6) leur permettront d'avancer rapidement sur ces
parties.
Codecs
 GSM
La plus grande difficulté de GSM fut de savoir comment cela fonctionner
réellement. Après d'infructueuses recherches , il est apparut que JMF réalisait ce que
l'on désirait.

Une étude plus appronfondie de l'application a permis de comprendre les

mécanismes de GSM.

Une étude approfondie de la documentation de jmf nous a finallement permis

de comprendre comment cela fonctionnait.

Les sources GSM comprennent :

● GSMEncode
● SampleDeMux
● SendMessage

Le premier code permet de coder en GSM. Il contient deux fonctions qui sont
getProcessor() et GSMEncode().
La première permet à la partie Rtp de récupérer le processor privé de la classe
GSMEncode et de pouvoir le tramsettre.
La seconde contient tout le processus de compression. Avec l'application JMF
il n'est pas nécessaire de réaliser l'un des filtres complexes de GSM (Full Rate.. cf
Annexe). En effet, l'application convertit en GSM de façon automatique.
En fait , chaque « flux » créé comprend des « tracks ». Chaque track véhicule
un type de données (vidéo , audio...). Ces tracks sont automatiquement multiplexé
par l'application. Il suffit donc de mettre un de ces tracks en GSM.

Le second code est un démultiplexeur. Il est assez général pour être utilisé pour
démultiplexé n'importe quel type de flux. Mais il faut le traiter par la suite et ici il ne
s'arrete que sur le codec GSM.
Voici les différentes fonctions et ce qu'elles font :
● getSupportedInputContentDescriptors() : cette fonction permet de récupérer
les formats supportés
● setSource(DataSource source) : cette fonction permet de vérifier que l'on
reçoit bien un stream en réception

● supports(SourceStream[] streams) : elle permet de savoir si le flux à traiter

est un flux entrant ou sortant

● isPositionable() et isRandomAccess() : ces deux fonctions permettent de

récupérer respectivement les variables positionalbe et seekable.

● GetTracks() : permet de récupérer un track du flux reçu

● getTrackLayout() : permet de récupérer le « Layout » d'un track c-a-d un

descriptif.

● setPosition(Time where, int rounding) : permet de se placer de façon

temporel dans le flux

● getMediaTime() : permet de récupérer le tps écoulé depuis le début du

média

● getDuration() : permet de récupérer le temps total

● readBytes(PullSourceStream pss, byte[] array,int numBytes) et

readBytes(PullSourceStream pss, byte[] array,int offset,int numBytes) : ces
deux fonctions permettent de récupérer les octetcs reçus et ce même avec un
offset.

● class BasicTrack. Cette classe permet de redéfinir les fonctions par rapport
à une track spécifique. Elle possède plusieurs fonctions
1. BasicTrack(SampleDeMux parser, Format format, boolean enabled,
Time duration, Time startTime, int numBuffers, int dataSize,
PullSourceStream stream, long minLocation, long maxLocation) est le
constructeur de cette classe et permet d'initialiser les divers paramètres
aux valeurs voulues.
2. GetFormat() permet de récupérer le format
3. setEnabled(boolean t) permet de basculer la variable enableb en true ou
false
 4. isEnabled() permet de récupérer enabled
5. getDuration() permet de récupérer la variable duration
6. getStartTime() permet de récupérer la variable startTime
7. getNumberOfBuffers() permet de récupérer la variable numBuffers
8. setTrackListener(TrackListener l) permet de placer la variable listener à
1
9. setSeekLocation(long location) permet de mettre la variable
seekLocation à une valeur passée en paramètre
10.getSeekLocation() permet de récupérer la variable seekLocation
11.readFrame(Buffer buffer) cette fonction est important car elle permet de
lire la frame contenue dans le buffer et dans extraire par la suite les
données nécessaires
12.readKeyFrame(Buffer buffer) lance readFrame(buffer).
13.willReadFrameBlock() renvoie false
14.getMediaSizeAtEOM() permet de récupérer la variable
mediaSizeAtEOM

● class GsmTrack extends BasicTrack : cette classe est spécifique à GSM. Elle
« étand » la classe BasicTrack afin d'avoir les mêmes variables et les mêmes
fonctions que cette dernière.
1. GsmTrack(AudioFormat format, boolean enabled, Time startTime, int
numBuffers, int bufferSize, long minLocation, long maxLocation) est le
constructeur de cette classe et agit avec un super c-a-d en appelant le
constructeur de la classe BasicTrack
2. mapTimeToFrame(double time) permet de calculer le nombre de frame par
seconde
3. mapTimeToFrame(Time t) permet de récupérer le nombre total de frame et
de les afficher avec le temps de réception
4. mapFrameToTime(int frameNumber) idem ci-dessus mais se base sur un
nombre passé en paramètre et non un temps.
Enfin le dernier n'a pas encore été intégré au projet. Mais il a pour finalité de
pouvoir envoyer des sms. En revanche pour cela il faut installer l'api JSMSEngine et
de disposer d'un modem adéquat afin de pouvoir se connecter à un portable.
Mais il a une autre utilité dans la mesure où en récupérant les informations d'un
portable donc d'un abonné (numéro de téléphone entre autre) , on pourra alors utiliser
le réseau GSM en se faisant passer pour le-dit abonné.
(pour plus de détails sur les sources consulter l'annexe 8)
codec
La session RTP va échanger les données audio en utilisant des codecs spécifiques (négociés
précédemment grâce au protocole sdp implémenté dans le pcackage sip). Ici, nous retrouvont
l'intégration de quelques codecs, afin de permettre une communication RTP.
Comme il a été convenu durant la phase d'étude de ce projet, les codec Speex, G711, iLBC et GSM
ont été intégrés

settings
Ce package est utilisée pour pouvoir tester le matériel audio et vidéo disponible dans la machine qui
exécute notre programme, en effet, il est nécessaire de tester et de s'assurer de la compatibilité du
matériels au préalable, afin d'éviter les problèmes liées aux pilotes par exemple.

video
Ce package, contient les classes nécessaires à la gestion de la vidéo et de la webcam en particulier,
il offre un choix du matériel de capture trouvé sur la machine, l'utilisateur pourra avoir un aperçu
par rapport à sa webcam, ce qui lui permet d'affiner ces réglages
 Conclusion :

Notre application sera donc codée en Java pour une interopérabilité OS

(système d'explotation) grâce à la machine virtuelle java.

Le choix de JMF ne s'est donc pas fait à la légère car cet API est bien
documentée et la possibilité d'ajouter d'autres fonctionnalités via les plugins est plus
qu'intéressante.

Dans les années à venir, les étudiants qui seront intéressés par ce projet devront
donc se consacrer à une optimisation de la QoS, mais aussi intégrer de nouveaux
codecs et autres fonctionnalités comme le téléchargement de fichiers (ftp) , un tchat ,
un répondeur , etc ... pour rendre ce logiciel complet et incontournable pour les
iupiens et iupiennes quel que soit leur statut (étudiants, professeur, chercheurs ou
intervenant).

Ce logiciel a été conçu dans le but de pouvoir accepter un maximun de

fonctionnalités aussi diverses que possibles. Il pourra devenir un centre multimédia
avec des connexions sur des radios , sur des télévisions , comprendre un agenda
complet etc etc...
Bibliographie :

http://www.cdt.luth.se/~johank/smd151/jmf/jmf2_0-guide.pdf

http://java.sun.com/products/java-media/jmf/2.1.1/apidocs/index.html

http://java.sun.com/products/java-media/jmf/2.1.1/guide/RTPArchitecture.html

http://www.rfc-editor.org/

http://jpl-conseil.typepad.com/jpl_conseil/voip_technologie/index.html

http://www.frameip.com

http://www.supinfo-projects.com/fr/2004/protocole_rtp_java_2004/3/

http://abcdrfc.free.fr/rfc-vf/rfc2327.htm