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 JMF...... Protocole de Transmission... 8-10 QoS... 11-12 Codecs... 13-18 Conclusion... 19 Bibliographie... 20 4-5 6-7
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