REPUBLIQUE FRANCAISE LIBERTE* EGALITE* FRATERNITE UNIVERSITE D AVIGNON ET DES PAYS DE VAUCLUSE CENTRE D ENSEIGNEMENT ET DE RECHERCHE INFORMATIQUE PROJET N 17 CAHIER DE CHARGE DU PREMIER SEMESTRE LOGICIEL DE TELEPHONIE SUR IP Présenté par : Chryst Girel MPIBI FOULISSIA Noureddine SERGHINI ERICK BRUNO YOUMBI TUTEUR: Rachid El AZOUZI Année Académique 2009-2010 1
I. PRESENTATION 1. Présentation du Projet 2. Intérêt du Projet 3. Problématique II. ETUDE DE L EXISTANT 1. Fonctionnement du programme initial 2. Outils utilisés a) Protocoles b) Codecs c. Quelques API JAVA III. AJOUTS ET AMELIORATIONS 1. Transferts de Fichiers 2. La Visioconférence 3. Transfert d appel vers des postes téléphoniques fixes 4. La Qualité de service (QoS) VI. ORGANISATIONS DES TACHES 1. Répartitions des taches 2. Diagramme de Grant CONCLUSION 2
I. PRESENTATION DU PROJET 1. Présentation du projet Ce projet de première année de master est la suite du projet 10 de l année dernière. Dans ce projet, les étudiants ont commencé à réaliser leur propre logiciel téléphonique pour que tous les membres de l IUP puissent l utiliser comme téléphone standard. L objectif du projet est d implémenter un modèle de communication multimédia (voix et vidéo) en temps réel entre deux (et plusieurs) ordinateurs. Et ce, en nous basant sur la modélisation orientée objet du protocole de signalisation SIP. Il s agit de développer une application utilisant une interface graphique homme machine (interface utilisateur). Dès lors, elle permettra un échange de données multimédia (audio, vidéo et messagerie instantanée). 2. Intérêt du projet Ce logiciel devra permettre au membre de l IUP de communiquer en utilisant les technologies IP, entre deux, ou plusieurs personnes en conférence, peut importe leur localisation. Ce projet a été Commencé il y a deux ans, et il a plusieurs intérêts. Le logiciel doit être réutilisable, puisque plusieurs personnes auront à travailler dessus, le code doit donc être compréhensible, clair et facile à modifier et réutiliser. Le but final étant que le logiciel soit opérationnel à la fin. De notre part, nous devons reprendre le travail qui a déjà était fait par les anciens étudiants, le comprendre afin de lui apporter des améliorations et lui ajouter de nouvelles fonctionnalités. II. Etude de l'existant 1. Fonctionnement du programme initial Le programme récupérer, dans son état, nous permettait d implémenter les fonctionnalités suivantes : Transmission vidéo La transmission de la vidéo entre 2 entités équipés du softphone a été un des axes majeurs sur lequel on travaillé nos camarades de l année derniere. Transfert de fichier L application actuel permet d échangerdes fichiers entre les utilisateurs, on utilise pour cela le protocole TCP. Messagerie instantanée L implémentation de cette technologie de messagerie permet A l application d échanger quasiment en temps réel de messages textuels entre différents utilisateurs de l application et qui se trouvent dans un même réseau informatique 3 (typiquement l Internet).
2. Outils utilisés a) Protocoles Le protocole SIP (Session Initiation Protocol) : bien évidement c est le protocole qui doit être utilisé sa simplicité, évolutivité naturelle (par exemple SIP peut fonctionner avec n'importe quel type de codecs sa bonne rationalisation : SIP n'émet qu'une seule requête contenant toutes les informations. Une seule manière simple de prévue pour s'acquitter d'une tâche. SIP exploite les rapports de feedback de RTCP. Protocoles RTP (Real-time Transport Protocol) et RTCP (Real-time Transport Protocol) : 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. Le premier gère l'envoi de l'information et le second sert à superviser la communication afin de réaliser et d'optimiser la QoS de l'application. Ce protocole est utilisé dans l'application pour transmettre des flux audio et video. Protocole TCP utilisé notamment pour transmettre l'envoit des données de manière fiable par le réseau.protocole impléménté dans le transfert de fichier. b) Codecs Les étudiants qui ont réalisé le projet ont essayé de faire en sorte que la session RTP va échanger les données audio et video en utilisant des codecs spécifiques (négociés précédemment grâce au protocole sdp implémenté dans le package sip). Ils ont fait l'intégration de quelques codecs, afin de permettre une communication RTP.Cependant, après avoir analysé le travail réalisé dans le projet existant, nous avons trouver qu un seul codec a était implémenté : le codec ilbc. c. Quelques API JAVA 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. 4
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) ManageEnvoi (étendant un thread) : Elle s'applique à 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) Le Manuel Java de Sun avait grandement servie pour la partie JMF du projet. Voici le lien correspondant à la partie qui traite RTP : http://java.sun.com/products/java-media/jmf/2.1.1/guide/rtparchitecture.htm III. AJOUTS ET AMELIORATIONS Voici les différentes solutions que nous apportons pour résoudre les problèmes liés à l avancement de notre projet «logiciel de téléphonie sur IP». Ces solutions concernent principalement : Le transfert de fichier La visioconférence Le transfert des appels vers les postes téléphoniques fixes. 1. Transfert de fichier Principe de base Un service de communication point à multipoint offre un moyen efficace de diffuser des unités de données à un groupe de récepteurs, en ce sens qu'une seule copie de chacune de ces unités est envoyée par la source (s'il n'y pas de pertes). Le multicast IP (RFC 1112) fournit au niveau réseau un support efficace pour la diffusion non fiabilisé des paquets pour un grand nombre d'applications: visioconférence, ftp multidestinataire, mise à jour d'informations dupliquées réparties, applications coopératives et tableau blanc, simulations distribuées, Certaines de ces applications prévoient la mise en rapport d'un nombre de participants de l'ordre de plusieurs milliers et peuvent aussi, en plus del'efficacité du routage, nécessiter une grande fiabilité dans la délivrance des données. 5
On peut réaliser un transfert de fichier avec le protocole TCP entre deux pc, mais dans cette étape de projet on utilise le multicast ce qui nous ramène à utiliser le protocole MFTP. MFTP est une API en JAVA permettant de faire du transfert de fichiers en mode multicast en se basant sur les spécifications du protocole Dyram. Nous allons intégrer dans un protocole que nous avons appelé DyRAM, pour Dynamic Replier Active reliable Multicast. L'un des objectifs majeurs de DyRAM est de se passer du cache dans les routeurs et d'obtenir une latence de recouvrement faible. Et on peux presenter ce protocole comme suite : Protocole de transport multicast fiable (orienté NACK) basé sur des services actifs Services actifs déployés: Suppression globale des NACKs Recouvrement local des erreurs Réparation partielle (subcast) Election dynamique d un ré-émetteur Détection précoce des paquets perdues Le problème de la fiabilité en point à point est bien maîtrisé et des solutions satisfaisantes (du moins pour TCP) ont été déployées. Par contre l'assurance de la fiabilité dans le contexte du multicast est un problème plus ardu et les solutions sont moins évidentes, 6
surtout sur des réseaux étendus et hétérogènes. La conception de protocoles de diffusion fiable efficaces est plus difficile et doit tenir compte des contraintes imposées par la résistance au facteur d'échelle. L'implosion et la surcharge de la source par les messages de contrôle (ACK/NAK), l'exposition des récepteurs à des transmissions dupliquées ou le contrôle de congestion en sont des exemples (voir figure). Malgré plusieurs années d'efforts consacrées à la conception de protocoles de diffusion fiable au dessus d'ip multicast, il est toujours aussi difficile de fournir une solution de bout-en-bout capable de satisfaire à l'ensemble des contraintes liées au facteur d'échelle. 1. Visioconférence La visioconférence est une toute nouvelle fonctionalité que nous devrons ajouter à notre logiciel. L élément incontournable pour la réalisation d une visioconférence est le M.C.U (Multipoint Control Unit) qui permet d ouvrir une session en mode diffusif. Un multipoint control unit (MCU) est un logiciel informatique ou une machine servant à établir simultanément plusieurs communications de visioconférence ou de VoIP. Cette fonction permet à plusieurs «clients» de la conférence de se réunir dans une même «salle virtuelle» de discussion. On distingue deux principaux modes de discussion dans une communication assistée d'un MCU : le mode prise de parole et le mode partagé. Le mode prise de parole affiche la vidéo de la personne qui parle, alors que le mode partagé affiche en vignette tous les participants. Les MCU peuvent aussi servir lors de l'interconnexion entre deux clients VoIP ayant des codecs incompatibles. Celui-ci réencode alors à la volée la voix et/ou la vidéo pour assurer l'interopérabilité entre les "clients".beaucoup de MCU ne fonctionnent qu'associés à un gatekeeper. Pour bien comprendre le fonctionnement des MCU nous devons d abord comprendre comment fonctionne la communication avec un gatekeeper. Communication «point à point» entre deux clients enregistrés auprès d'un gatekeeper 7
Un GateKeeper est littéralement traduit par garde-barrière ou portier. Dans le protocole H.323, cette machine est en charge des rôles suivants: Registration : enregistrement des présences des utilisateurs ainsi que de leur adresse IP et leur numéro de téléphone. Admission : Le gatekeeper vérifie que les clients ont le droit de passer des appels et gère la bande passante. Vérification : Le gatekeeper vérifie les statuts des terminaux (disponibilité,...) 8
Communication «Multipoints» entre plusieurs clients (MCU nécessaire) Les MCU ont des capacités de traitements du signal (diffusion, enregistrement, mixage, ) ils sont utilisés pour : permettre la conférence en mixant les flux audios diffuser des messages réseau comme la tonalité, le bip de mise en attente voire réaliser des fonctions élémentaires de messagerie vocale Le MCU s'annonce auprès du gatekeeper et lui énonce ses possibilités : o o o Nombre de clients possibles. Débits (en octets/secondes) possible par client ou débit total maximal. ID H323 de connexion. Les communications seront ensuite traitées comme au cas 2, le MCU devenant alors un «simple client» au vu des appelants ; la différence se trouvant simplement dans le nombre de communications acceptées avant transmission du message «occupé». Dans le programme de l année dernière les étudiants ont utilisés des Threads ce qui est tout à fait normal vu qu il réalisait la communication entre deux interlocuteurs. Pour faire de la visioconférence nous allons implémenter du multicast voilà pourquoi nous allons utiliser des multithreads. Concrètement nous allons mettre en place un diffuseur qui permettra de 9
recevoir des connexions simultanées de plusieurs utilisateurs. Notre diffuseur devra donc gérer des connexions multiples de la voix mais aussi de la vidéo. Lorsqu'un utilisateur connecté au diffuseur demande une communication. Cette demande de communication est transmise à tous les utilisateurs connectés à ce diffuseur en temps réel. Les utilisateurs connectés au diffuseur peuvent ainsi répondre et tous les utilisateurs connectés au diffuseur reçoivent sa réponse. De même Pour envoyer la vidéo les étudiants de l'année passée utilisaient la classe RtpManager. Or cette classe est adapté pour envoyer un flux vidéo vers une destination unique car l'ajout d'un nouvel utilisateur nécessite d'ajouter une nouvelle cible dans la méthode addtarger () ce qui n'est pas pratique puisque nous voulons envoyer la vidéo vers plusieurs destination pour cela le clonage du DataSource est mieux adapté. 2. Le transfert des appels vers les postes téléphoniques fixes On peut réaliser un transfert d Appel, en utilisant des autocommutateurs (PABX) Servant aussi bien l'établissement des communications internes que des communications Externes (réseau public) vers internes à travers un standard téléphonique ou par la Sélection Directe à l'arrivé (SDA), mais aussi bien de l'interne vers l'extérieur. Avec l'arrivée de nouvelles fonctions numériques comme la VoIP qui utilise les mêmes installations qu'un réseau informatique (Switch, Routeur, câblage RJ45, etc.) et nous pourront donc intégrer la téléphonie dans un même et unique réseau. Cela va sans dire, que les coûts de gestion de la partie téléphonie sont nettement réduits. Une agence à l'autre bout du monde? Mais bien sur, avec une connexion Internet, intégrez là aussi sur votre installation principale via un réseau en VPN Une connexion Internet ASDL de 512 Mbits/s mini (1 Gbits/s recommandée) voir plus. Un Pc ou un serveur qui existe peut être déjà, à moins que vous préfériez utiliser un serveur dédié à la VoIP, Une ou plusieurs passerelles RTC/VoIP, Les postes téléphoniques SIP, Un ou plusieurs abonnement(s) pour des lignes VoIP externes Voici un aperçu de ce que peut ressembler une installation de téléphonie VoIP sur un réseau informatique déjà existant. Un petit schéma valant mieux qu'un grand discours, 10
voici un aperçu de ce que peut ressemble un réseau informatique Le programme que je vous propose d'utiliser est celui d Asterisk qui et un central téléphonique PABX IP permettant de créer une installation téléphonique privée pour un particulier comme pour une petite ou moyenne entreprise. Asterisk est un autocommutateur logiciel libre qui effectue toutes les opérations de base d'un autocommutateur matériel. En outre, Asterisk est doté d'un environnement de développement de services et d'extensions. C'est le cas du système natif d'élaboration du plan de numérotation (dialplan) incluant variables, primitives, et un langage de programmation : l'agi (Asterisk Gateway Interface) avec une API3 bien documentée. Il est aussi possible de développer dans le langage de son choix (C, Java, Perl, Python, PHP) de nouvelles primitives pour le système d'élaboration du plan de numérotation. Asterisk dispose également d'une interface de gestion sur le port TCP/5038 permettant de le superviser et de le piloter en client/serveur depuis un client Web ou d'y adjoindre des logiciels tiers. Également d'une interface de gestion sur le port TCP/5038 permettant de le superviser et de le piloter en client/serveur depuis un client Web ou d'y adjoindre des logiciels tiers. Il est très facile de communiquer entre utilisateurs équipés SIP mais ils sont encore peu nombreux. Comment communiquer avec les téléphones mobiles, les entreprises non équipée? Il faudra sans doute plusieurs dizaines d'années avant de voir la disparition des téléphones analogiques. Le vrai problème du déploiement de ces systèmes est donc lié à la capacité à communiquer avec l'ancien réseau téléphonique ou à utiliser les anciens 11
équipements. Le standard SIP permet cette interconnexion très facilement à plusieurs niveaux. Au niveau de l'ancien poste analogique On peut récupérer les anciens postes analogiques et les connecter par un petit boitier avec une interface dite FXS qui fournit le courant d'alimentation et permet le branchement direct sur le réseau Internet An niveau de la ligne d'arrivée téléphonique Avec une interface dite FXO puisque celle ci est alimentée par l'autocommutateur, on peut faire une passerelle entre le monde SIP et la téléphonie classique, c'est à dire recevoir ou émettre des appels vers l'ancien monde. En utilisant cette ligne, un mobile ou un poste local peuvent ensuite atteindre le reste du monde pour le prix d'une communication locale. L'intérêt de cette solution est de conserver l'installation téléphonique existante tout en la connectant dans les 2 sens au monde SIP. Pour ceux qui n'ont pas d'équipements ou de numéros à conserver, il existe de nombreux opérateurs qui offrent le service d'interconnexion avec la téléphonie fixe ou mobile mondiale pour des prix extrêmement intéressants. On désigne par PABX IP (PBX IP ou encore IPBX) un système qui assure l'acheminement de toute ou partie des communications en utilisant le Protocole Internet IP, en interne sur le réseau local ou le réseau étendu (WAN) de l'entreprise. L'utilisation du protocole SIP (Session Initiation Protocol) permet de configurer le système facilement avec les téléphones de bureau VoIP compatibles SIP ou avec des logiciels clients VoIP comme celui proposé par Asterisk. Ce système fonctionne en VoIP, c'est à dire en téléphonie par IP. L'utilisation du serveur IPBX permet aussi de louer des lignes VoIP chez des fournisseurs de téléphonie VoIP spécifiques via Internet. Ce système permettra aussi de relier les lignes téléphoniques classiques en RTC ou en RNIS à votre installation grâce à une ou des passerelles spécifiques avec éventuellement la gestion de lignes en SDA (Sélection Directe à l'arrivée). 12
Les principales fonctions d Asterisk serveur IPBX; Création de n internes Mise en attente et transfert des appels d'un poste vers un autre. Répondeur personnalisable avec la possibilité de gérer des horaires de renvoi. Création de groupes d'appels en simultané ou en suivi. Possibilité d'étendre le réseau vers des postes situés au quatre coins du monde via Internet et/ou par VPN (Gestion par un Nom de Domaine préférable). Gestion simplifiée de l'administration du serveur via une interface WEB intégrée (serveur Apache) sur un port spécifique et protégé par un Nom d'utilisateur et un mot de passe. Peut très bien être installé sur un pc comprenant déjà un serveur WEB pour un site. Les employés peuvent changer de bureau sans s inquiéter des branchements ni de la configuration du PABX IP, il suffit de mettre le téléphone SIP dans les cartons (ou sous le bras) et de le rebrancher dans le nouveau local. Choisissez entre plusieurs téléphones SIP au lieu d être restreint au choix d un revendeur. Ou utiliser le Client VoIP d Asterisk. > Recevez et/ou passez des appels par le biais du RTC standard grâce aux passerelles VoIP existant. 3. Qualité de service (QoS) Dans notre application, la QoS consiste a l utilisation de la meilleur paire de codecs (audio et vidéo) selon l état du réseau. La négociation de codecs avec le protocole SIP se fait à l ouverture de la session dans la requête INVITE. Lors de ce choix de codec, les entités non pas conscience de l état du réseau car le choix est fait avant toute communication RTP/RTCP c est RTCP qui permet de récupérer des informations du réseau. Pour une bonne gestion de la QoS il est nécessaire d enrichir notre base de données des codecs audio(g.711 à 64 kb/s, G.726 à 32 kbit/s, GSM à 13 kb/s, ) et des codecs vidéo (H261 à 64 kb/s, H263 à 64 kb/s,.). 13
VI. ORGANISATIONS TACHES 1. Répartitions des taches 2. Diagramme de Grant Conclusion Les differentes solutions énoncé plus hauts pour améliorer notre logiciel de téléphonie sur IP seront developpé au cours du semestre prochain, notre logiciel dans sa vesrion final apportera une révolution certaine dans le monde de la téléphonie sur IP. Notre équipe de projet vous remercie de nous avoir fait confiance en acceptant de nous attribuer ce projet et de lire ce document. Nous espérons que les différents points évoqués au cours des précédentes parties répondront de manière exhaustive à vos attentes. 14