IF SIC Wengo SAS

Université de Rennes 1 40-42 quai du Point du Jour

Campus de Beaulieu 92100 Boulogne Billancourt
35042 Rennes

Développement d'une application de VoIP

Sous la responsabilité de : Fabien Penso

Jérôme Wagner (Wengo) Master informatique option GL
Yves Le Traon (IRISA) Année 2004/2005

Date 13/06/05
Diffusion Publique sauf page indiquée
Nombre de pages 31
Table des matières
Introduction.........................................................................................................................................1
Contexte du stage...........................................................................................................................1
Présentation du document..............................................................................................................1
Wengo.................................................................................................................................................2
La société........................................................................................................................................2
Le sujet du stage.............................................................................................................................3
Subject of the internship.................................................................................................................3
La téléphonie sur Internet....................................................................................................................4
Introduction....................................................................................................................................4
Les technologies actuelles..............................................................................................................4
Skype.........................................................................................................................................4
GnomeMeeting..........................................................................................................................5
MSN et Yahoo!..........................................................................................................................5
Solutions matérielles.................................................................................................................5
SIP, le futur de la téléphonie sur IP ?..................................................................................................6
Introduction....................................................................................................................................6
Stacks SIP existantes......................................................................................................................7
État des lieux de l'architecture Wengo..............................................................................................10
Plateforme réseau.........................................................................................................................10
Le Wengophone, application cliente............................................................................................11
Conception d'un softphone « idéal ».................................................................................................13
Évaluation des fonctionnalités.....................................................................................................13
Conception des fonctionnalités....................................................................................................14
Conception de l'historique du softphone.................................................................................15
Conception de la « contact list »..............................................................................................16
Conception de la partie téléphonie..........................................................................................17
Développement de l'IHM.........................................................................................................18
Implémentation.............................................................................................................................20
Les choix de l'implémentation.................................................................................................20
Rigueur durant le projet...........................................................................................................20
Intégration de la bibliothèque phAPI.......................................................................................21
Non implémenté......................................................................................................................22
Capture d'écran........................................................................................................................23
...........................................................................................................................................................24
Idées sur la plateforme « idéale » de téléphonie................................................................................24
Problèmes structurels liés à Wengo..................................................................................................26
Conclusion........................................................................................................................................28
ANNEXES........................................................................................................................................29
 Remerciements

Je tiens à remercier tout particulièrement M. Maurice Yerles, responsable de la

formation continue de l'université de Rennes, qui a été le premier à penser que le
projet dans lequel je m'engageais me serait bénéfique. Je tiens aussi à remercier
M. Yves Le Traon, maître de conférences à l'université de Rennes 1, qui a appuyé ma
candidature auprès du milieu universitaire, et sans qui je n'aurais pas été accepté
dans ce cursus.

Au sein de la société Wengo, je tiens à remercier mon responsable M. Jérôme

Wagner pour son ouverture d'esprit ainsi que l'équipe dirigeante qui a pensé dès le
début que ma présence serait positive pour leur projet. J'espère que j'aurai démontré
la nécessité et l'importance des réflexions à mener autour des architectures
logicielles. Je remercie également l'équipe avec qui j'ai collaboré pendant ces 4 mois
et qui a toujours été attentive à mes demandes et mes questions.

Enfin, je tiens à remercier à titre personnel M. Pascal Courtois, ingénieur du

CNAM, qui m'a toujours poussé à engager un jour une formation de ce type, et qui
aura fini par arriver à ses fins.
1. Introduction

1.1. Contexte du stage

Ce stage de fin d'études valide une formation continue entreprise dans une
filière de Master Informatique spécialisé développement logiciel à l'IFSIC
(Université de Rennes 1, France), Institut de Formation Supérieure en Informatique
et Communication.

Le sujet du stage se focalisait initialement sur la modélisation de la

plateforme informatique de la société Wengo, prestataire spécialisé dans la
téléphonie sur IP. Il s'est orienté finalement vers la modélisation et la conception
de leur logiciel de téléphonie (softphone). La version actuelle du logiciel ayant été
développé avec des contraintes temporelles importantes, il n'a pas été possible de
prendre le temps nécessaire à une réflexion globale sur la partie développement et
son architecture logicielle. La société Wengo a pensé qu'il serait intéressant de
mener à bien cette réflexion pendant la durée de mon stage. Afin de valider la
conception logicielle que j'ai entreprise, j'ai pris l'initiative d'en implémenter une
version fonctionnelle.

Le stage s'est déroulé sur une période de 4 mois, du 14 mars 2005 au 14

juillet 2005.

1.2. Présentation du document

Ce document a pour but, d'une part de valider l'utilisation de méthodes de

travail et de modélisation vues en cours et leurs utilisations dans un milieu
professionnel, d'autre part de faciliter à mes supérieurs hiérarchiques des prises de
décisions concernant les orientations futures de leurs applications, tant sur les
méthodes de travail à envisager que sur des problématiques plus concrètes suite à
des problèmes rencontrés pendant la phase de développement passée.

1
2. Wengo

2.1. La société

La société WENGO SAS, filiale à 70% de l’opérateur 9Télécom, est un

opérateur de services de communication sur internet. Elle se spécialise en
particulier dans toutes les technologies liées à la téléphonie sur Internet et a
démarré en janvier 2005 son activité commerciale via le site http://www.wengo.fr.
A la date de la rédaction de ce rapport, la société comporte une vingtaine
d'employés, dont quatre fondateurs. Une campagne nationale publicitaire a
démarrée le 6 juin 2005 et pour une période de deux mois ; elle inclut des
publications dans plusieurs quotidiens nationaux ainsi que des sites webs reconnus
(Le Monde, Yahoo!, etc).

La société s'oriente vers la vente d'abonnement de crédit téléphonique à

travers son portail, et qui peuvent être utilisés par le biais d'un logiciel Wengo
développé en interne (Wengophone). Ce logiciel permet en outre de s'appeler
gratuitement entre utilisateurs abonnés. Les inscriptions sont ouvertes à tous, et il
n'est pas nécessaire de payer pour utiliser le logiciel. On peut aussi utiliser une
« boîte noire » branchée à sa connexion ADSL, et sur laquelle on a la possibilité de
brancher n'importe quel téléphone filaire classique.

La plateforme Wengo se base principalement sur des logiciels libres, tant

pour le « backoffice » que pour les logiciels spécifiques développés en interne
(python, twisted, etc), ainsi que l'outil de téléphonie mis à la disposition des
internautes et qui est diffusé sous licence GPL. De plus, et contrairement à
beaucoup de ses concurrents, Wengo utilise des protocoles normalisés pour la
partie téléphonie (SIP1, RTP 2) ; il est donc possible d'accéder à ses serveurs grâce à
n'importe quel client de téléphonie standard, sans toutefois pouvoir jouir de toutes
les fonctionnalités offertes par le Wengophone.

1Session Initiation Protocole : protocole de signalisation pour la téléphonie sur IP, la

présence, la messagerie instantanée, etc. Les spécifications sont disponibles dans le RFC
2543.
2Real-time Transport Protocole :protocole de transport des flux médias associés à la
téléphonie sur IP.

2
 2.2. Le sujet du stage

Le sujet du stage initial devait débuter par la modélisation des composants

existant au sein de la plateforme Wengo, et continuer en se spécialisant sur la
modélisation des développements effectués autour du Wengophone. Après une
prise en main de l'infrastructure réseau et des différents serveurs qui rentrent en
jeu dans le cadre d'appels téléphoniques par le biais de Wengo, il a été évident qu'il
serait difficile de modéliser avec des méthodes d'architecture logicielle orientées
objet telles que UML3 les développements actuels.

Le stage s'est finalement orienté autour de la modélisation idéale à avoir

pour un logiciel de téléphonie sur IP. Mon travail durant ce stage a été
d'accompagner les développeurs actuels sur la conception à avoir pour leur logiciel,
de proposer des schémas de description et de fournir une implémentation de la
modélisation. Les points clés autour de cette modélisation sont :

• L'utilisation de « design patterns » et de méthodes qui permettront

d'envisager un avenir serein pour les phases de développement à venir
• La modularité de la conception et des développements associés
• La clarté de la documentation du code source fourni

L'implémentation choisie de développer ne sera pas distribuée aux

utilisateurs, elle permet simplement de valider le modèle conceptualisé, et de
donner un exemple concret associé aux documents UML afin d'en faciliter leur
compréhension. Elle sera donc vue comme un « proof of concept » de la
modélisation proposée, et une réponse à des questions de faisabilité sur certaines
fonctionnalités qui n'existent pas à ce jour dans la version disponible publiquement.

2.3. Subject of the internship

The subject of the internship as planned as first should have started with the
modeling of the existing components within the Wengo plateform, and then focus
around the modeling of the developments of the softphone software: the
Wengophone. After the study of the network infrastructure and the few servers
used during a phonecall through Wengo, it was obvious it would be difficult to make
a proper modelisation of the current developments of the Wengophone.

The internship has finaly been focused around the modelisation of a « ideal »
phone software. My work during that internship has been to help the developers to
understand how to move their current softphone to a better modelisation, and
provide them documentation, UML description and clean source code of my own
version of a softphone.

3Unified Model Language: outil de spécification d'architectures logicielles

3
3. La téléphonie sur Internet
3.1. Introduction

La téléphonie sur IP (VoIP), grâce en partie à la démocratisation de l'internet

haut-débit, est un des domaines amenés à fortement se développer dans les mois
et les années à venir. Certains acteurs du marché tels que Skype ont déjà réussi à
s'implanter avec une rapidité impressionnante en proposant des applications
multiplateformes et qui permettent aux internautes de s'appeler mutuellement
gratuitement. De plus, la VoIP remet en question les démarches des opérateurs
traditionnels (France Telecom) historiques en proposant des tarifs jusqu'à 50 fois
inférieurs pour les appels internationaux.

Les prochaines étapes se dirigeront sans doute autour des interconnexions

entre opérateurs VoIP afin qu'un utilisateur A puisse appeler directement un
utilisateur B localisé sur un réseau différent. Il est à noter que l'utilisation d'outils
propriétaires tels que Skype rend difficile cette interopabilité et qu'il serait plus sain
que des logiciels basés sur des protocoles libres reprennent le dessus. L'ajout de la
vidéo aux outils existants concentre aussi toute l'attention, certains offrant déjà
cette fonctionnalité.

Un des problèmes techniques actuel est lié à l'implémentation de NAT 4 et les

conséquences que cela a sur la possibilité de connecter deux clients en direct pour
l'envoi des flux médias. On est dans ce cas dans l'obligation de passer par un tiers
(appelé proxy, ou relais) pour permettre le passage du flux. On peut noter
cependant que de plus en plus de routeurs implémentent SIP (le protocole de
signalisation) et que ce problème devrait être réglé à l'avenir.

Des aspects juridiques importants existent aussi sur les codecs utilisés dans
les flux audios et vidéos ; en effet, la plupart des protocoles utilisés sont soumis à
des brevets et ce problème est encore plus ennuyeux pour les développeurs de
logiciels libres.

3.2. Les technologies actuelles

3.2.1. Skype

Skype est, parmi les acteurs actuels spécialisés dans la téléphonie sur IP,
devenu rapidement une référence. Son principe se base sur la diffusion massive
de leur client, et ils simplifient au maximum son téléchargement. Le site
http://www.skype.com/ propose directement de l'obtenir. Le client est simpliste,
accessible à un maximum d'utilisateurs, et a d'ailleurs déjà convaincu plusieurs
millions de personnes. Le site indique plus de 120 millions de téléchargements
au moment de la rédaction de ce document.

Les fondateurs de Skype ont par le passé développé le logiciel KaZaA, un

outil de Peer To Peer (partage de fichier sans serveur centralisé), et avaient les

4NAT: Network address translation. Mécanisme qui permet de faire correspondre les adresses
IP internes non-unique d'un domaine vers un ensemble d'adresse externes uniques et
routables.

4
 compétences nécessaires au développement d'un outil téléphonique qui se base
sur ce concept. Cela permet entre autres d'éviter de supporter les coûts de
bande passante en déléguant à des clients tiers (appelés Supernode) le rôle de
relais, et réduit donc considérablement les frais de fonctionnement.
Skype propose en outre une API complète pour les développeurs désireux
d'utiliser leur réseau pour développer des applications spécifiques. Néanmoins et
tout en étant gratuit, Skype se base sur des technologies propriétaires et est
difficilement, pour ne pas dire impossible, connectable avec d'autres fournisseurs
de voix sur IP.

3.2.2. GnomeMeeting

GnomeMeeting est un outil développé par Damien Sandras depuis 1996,

et proposé dans l'environnement GNOME (GNU/Linux). Il est libre et diffusé sous
licence GPL, et a actuellement plusieurs milliers d'utilisateurs quotidiens.

Initialement cet outil proposait des fonctionnalités de vidéoconférence

compatibles avec NetMeeting, mais se focalise désormais sur l'implémentation de
VoIP en utilisant le protocole SIP, et se vend comme un outil de téléphonie à
part entière.

3.2.3. MSN et Yahoo!

Les logiciels de messagerie instantanée tels que MSN, ou Yahoo!

Messenger proposent désormais des fonctionnalités de VoIP et de
vidéoconférences, et peuvent remplacer dans certains cas un outil de VoIP
classique. Cependant, n'étant pas focalisés sur la téléphonie, des fonctionnalités
basiques ne sont pas proposées telles que la présence d'un outil de numérotation
graphique indispensable lors d'appel sur des serveurs automatisés pour l'envoi
de DTMF 5 (« tapez 1 pour... »), la gestion d'historique des appels, les boîtes
vocales, les transferts d'appels, etc. Ils ne proposent pas non plus une qualité de
voix irréprochable.

Il sera intéressant de voir dans les années à venir si ces outils de

messagerie arriveront à faire leur place dans le marché de la VoIP. Tout comme
Skype ce sont des logiciels propriétaires, et les mêmes problématiques
d'intéropérabilité se posent.

3.2.4. Solutions matérielles

La plupart des fournisseurs d'accès ADSL haut-débit fournissent à ce jour
des solutions de téléphonies sur IP ; Free propose la Freebox, 9telecom propose
la Neufbox, etc. Ces offres intègrent la possibilité d'appeler de manière illimitée
des usagers présents chez le même fournisseur, de plus en plus souvent la
possibilité de passer des appels nationaux gratuitement et des appels
internationaux à des prix compétitifs. Il sera difficile pour des prestataires qui se
situeraient sur ce même marché d'être en compétition avec les fournisseurs
d'accès internet, sachant que les internautes connectés en haut-débit auront de
plus en plus fréquemment un système de téléphonie gratuit déjà en place.
5Dual Tone Multi Frequency

5
4. SIP, le futur de la téléphonie sur IP ?
4.1. Introduction

SIP est un protocole de signalisation utilisé en voix sur IP permettant de

transférer de la voix, de la vidéo ou des données à travers un réseau. C'est un
protocole de niveau 7 dans le modèle OSI, élaboré par l'IETF et décrit par le
document RFC 3261 6 ; il a pour but d'être un remplaçant à H323. Le protocole SIP
se charge de l'identification et de la localisation des multiples participants, et aussi
de la négociation sur les types de média utilisables par les différents participants.

En pratique, un serveur SIP sera créé par le fournisseur du service

téléphonique. L'application de téléphonie s'enregistre sur le serveur SIP qui
mémorise les informations relatives à cet utilisateur (adresse IP, identifiant, etc)
pour lui permettre de le contacter ultérieurement dans le cas d'un appel.

Chaque utilisateur est identifié grâce à une url sous la forme

sip:user@domain.com. En simplifiant, si cet utilisateur souhaite contacter une autre
personne dont l'identifiant est sip:user2@autre_domaine.com, son proxy (proxy1)
détermine en utilisant des requêtes DNS l'adresse du proxy SIP de
« autre_domaine.com » pour lui envoyer une demande de connexion vers cet
utilisateur. Si la connexion peut s'établir, Proxy1 sélectionne dans la liste des

6Voir le RFC à http://www.faqs.org/rfcs/rfc3263.html

6
protocoles qu'il supporte en commun avec Proxy2 celui que Proxy2 préfère. Ce
protocole sera utilisé par les utilisateurs pour communiquer entre eux.

Néanmoins concrètement des problèmes subsistent à cette explication

simplifiée. De plus en plus d'internautes utilisent des « firewalls » ou utilisent
Internet par le biais de réseau du type NAT. Dans le cas où les 2 utilisateurs qui
souhaitent communiquer entre eux utilisent ce type de configuration, il sera
impossible d'établir en direct un flux d'envoi de la voix (flux RTP). Il est obligatoire
d'utiliser un proxy RTP pour relayer les flux. Le schéma suivant détaille ce principe.
Le serveur qui effectue le rôle de proxy RTP doit supporter la charge
supplémentaire de bande passante que représentent ces deux flux RTP à
commuter.

4.2. Stacks SIP existantes

Le protocole SIP permet d'avoir un mode connecté vis à vis du client qui
l'utilise. Les piles SIP fonctionnent en général sur un système de « callbacks » : on
s'enregistre sur un serveur SIP et la pile SIP tourne dans son propre thread. La pile
appelle les callbacks lors d'événements spécifiques tels qu'une demande d'appel,
un changement de présence, ou un changement d'état d'un appel en cours.

Il existe de nombreuses implémentations de pile SIP, chacune étant plus ou

moins respectueuse de la norme. Néanmoins beaucoup de pile libres disponibles se
focalisent sur des développements Linux, probablement pour viser une utilisation
au sein de produits embarqués, et ne fonctionnent pas sous Windows. J'ai cherché
une implémentation qui puisse être utilisée facilement et puisse se compiler sous
plusieurs plateformes (au minima Linux et Windows) et j'ai effectué de nombreuses

7
tentatives sur certaines d'entre elles, dont voici une liste non-exhaustive.

1.SipX

SipX est un ensemble d'outils autour de SIP développés par la société

Pingtel et diffusés sous licence LGPL. Après demande aux développeurs, la pile
n'est pas développée sous Windows et Pingtel n'envisage pas au moment de la
rédaction de ce document d'en maintenir une version. Après plusieurs tentatives,
j'ai réussi à compiler une version Windows mais son intégration dans C# s'est
révélée infructueuse et semblait causer des bugs incompréhensibles. Les
tentatives d'utiliser cette pile ont donc été suspendues, mais il semble qu'il serait
intéressant de suivre son développement.
Plus d'information sur SipX est disponible à l'adresse
http://www.sipfoundry.org/sipX/

2.OPAL

OPAL est une pile SIP diffusée sous licence MPL (Mozilla Public licence) qui
a été intégrée dans le projet OpenH323, et c'est celle qui est utilisée dans le
projet GnomeMeeting. Elle fonctionne nativement sous Linux et Windows et
pourrait être intégrée et utilisée dans le softphone. Suite à des contraintes de
temps je n'ai pas testé son intégration dans le code existant, mais il est probable
que cela fonctionnerait et elle mérite qu'on y prête attention.
Plus d'information sur OPAL est disponible à l'adresse
http://www.openh323.org/opal.html

3.RTC Microsoft

Microsoft dans le cadre de son « Microsoft Live Communications » diffuse

toute une gamme de composants réseaux, dont une pile SIP qui a l'avantage
d'intégrer d'autres fonctionnalités (présence, gestion des média audio et vidéo,
etc). Microsoft conseille l'utilisation de serveur SIP qui fonctionnent en mode TCP
et celui utilisé par Wengo (SER: SIP Express Router) dans sa version actuelle
fonctionne principalement en UDP ; malgré tout, il est possible d'utiliser cette
implémentation pour une version Windows du softphone.
Plus d'information est disponible à l'adresse
http://msdn.microsoft.com/library/en-
us/lcs2005/rtc/rtc_server_application_api_reference.asp

4.osip, eXosip et phAPI

osip est une pile SIP sous licence LGPL qui implémente les couches basses
du protocole SIP. EXosip est une pile SIP sous licence GPL qui simplifie
l'utilisation d'osip. Au contraire d'osip, l'utilisateur n'a pas besoin d'une
connaissance très évoluée du protocole SIP pour utiliser eXosip. Osip et eXosip
sont développés par Aymeric Moizard, et plus d'information est disponible sur
http://www.antisip.com/.

Exosip fait parti des composants qu'utilise le Wengophone actuel pour la

partie téléphonie, mais pour faciliter son utilisation il a été développé en interne

8
 un « wrapper » en C : phAPI. PhApi a l'avantage de faciliter encore plus
l'utilisation de eXosip, d'intégrer la gestion des médias, et de proposer des
fonctions haut-niveau pour décrocher ou raccrocher la ligne, passer un appel en
attente, etc. De plus en plus de fonctionnalités haut-niveau sont rajoutées au
sein de phAPI (vidéo par exemple).

Un des désavantages de phAPI est de ne pas avoir encapsulé eXosip afin

d'offrir la possibilité d'utiliser d'autres pile SIP. De plus au moment de mon
arrivée dans l'entreprise, phAPI avait quelques lacunes importantes dans le cadre
d'une bibliothèque. Par exemple, il n'est fourni aucun jeu de tests unitaires qui
permettent de valider ses fonctionnalités, et le code utilise des variables globales
ce qui interdit certains usages. J'ai donc proposé que soit utilisé un système
similaire à Glib 7 pour l' « objectisation » du code, et que soit développé un
système qui permette de valider que phAPI fonctionne (tests unitaires ou de
scénarios). Au moment de la rédaction de ce document, cela est en cours de
développement.

7Glib est une bibliothèque C bas-niveau développée dans le cadre du projet GTK et très
populaire dans les programmes développés en C. Plus d'information sur
http://developer.gnome.org/doc/API/glib/

9
5. État des lieux de l'architecture Wengo
5.1. Plateforme réseau
L'architecture réseau actuelle de Wengo se base sur le protocole SIP pour
toutes les communications avec ses clients. Le schéma réseau suivant permet
d'avoir une vue globale de l'infrastructure en ce qui concerne le Wengophone. En
simplifiant, le « backoffice » est constitué d'un serveur SIP, d'un proxy SIP
(CIRPACK), d'un proxy RTP (pour les médias), et d'un serveur « SSO » (Single
Sign-On) utilisé pour permettre aux clients d'avoir une identification unique et non
dépendante des informations SIP.

Lors du démarrage de l'application WengoPhone, on effectue dans l'ordre suivant :

• On vérifie que la version du WengoPhone utilisé par le client est à jour,

sinon on lui propose d'installer la nouvelle version
• On télécharge les informations pour se connecter au serveur SIP par le biais
du serveur SSO (requête https)
• On s'enregistre sur le proxy SIP
• On vérifie la présence de tous ses contacts

Ensuite un paquet est envoyé à intervalle régulier pour garder d'hypothétiques

firewalls ouverts, et valider que le client est toujours connecté. Le diagramme de
séquence associé à ces étapes est disponible en annexe.

10
 5.2. Le Wengophone, application cliente

L'application WengoPhone actuelle est développée en C++. Après étude du

code, il a été conclu qu'il était difficile d'établir un shema UML cohérent, notamment
à cause de l'utilisation de variables globales, et de la non-objectisation du wrapper
pour l'interaction avec les bibliothèques C utilisées. Après réflexion, il a été décidé
qu'il serait plus profitable de faire tout de suite une modélisation « idéale » pour
tenter par la suite de faire tendre la version actuelle vers cette modélisation en
refactorisant par exemple le code existant.

Le softphone actuel est complètement lié avec l'environnement Qt 8 et il est

impossible d'envisager de pouvoir retirer cette dépendance. En effet, un
développeur qui doit utiliser C++ sera tenté de combler les lacunes de ce langage
par l'utilisation de bibliothèques haut-niveau, même pour la gestion de classes
basiques telles que String, Thread ou Timer (plus évoluées que celles fournies par
C++) et qui sont désormais livrées en standard dans les langages de plus haut-
niveau (Java, C#, Python, etc). L'utilisation intensive de ces classes Qt au sein de
la partie métier de l'application rend impossible son éviction. La première phase
d'une refactorisation future de cette application passera sans doute par
l'implémentation sans dépendance de ces classes de base, ou au moins leur
utilisation à travers des interfaces normalisées pour pouvoir utiliser d'autres
implémentations.

De plus, il n'existe pas de séparation réelle entre le code qui implémente le

métier de l'application et le code qui implémente la présentation du logiciel. Ainsi il
est impossible à ce jour d'implémenter des IHM différentes suivant des critères tels
que le système d'exploitation, ou même de revendre l'outil sous marque blanche.
Tous ces aspects reposent sur les possibilités de Qt d'offrir ces fonctions aux
développeurs Wengo. La deuxième phase d'une nouvelle version de cette
application passera par la séparation concrète de ces couches, en utilisant une
méthode telle que MVC ou PAC 9.

A ce jour, la fenêtre du wengophone ressemble à :

8 Qt est un framework multiplateforme de développement C++, voir

http://www.trolltech.com/
9MVC et PAC sont des méthode d'architecture conceptuelle d'IHM

11
12
6. Conception d'un softphone « idéal »
6.1. Évaluation des fonctionnalités

La première étape de la conception a consisté à prendre en compte les

fonctionnalités « métiers » actuelles du softphone pour définir un cahier des
charges technique précis et un choix des fonctionnalités qui seraient développées
dans cette nouvelle version.

La durée du stage ne me permettait pas de redévelopper l'intégralité du

softphone actuel, j'ai donc décidé de me focaliser sur certaines fonctionnalités
susceptibles d'avoir un intérêt dans le cadre d'un outil de téléphonie, ou qui
avaient un intérêt pédagogique pour mes collègues afin d'expliquer l'avantage
d'utiliser des « patrons de conception » et une architecture logicielle réfléchie.
J'ai décidé aussi d'implémenter de nouvelles fonctionnalités, principalement
celles désirées mais difficilement intégrables dans le softphone actuel suite à des
problèmes de conception.

En plus des fonctions normales attendues d'un logiciel de téléphonie (passer un

appel, recevoir un appel, etc), j'ai déterminé les fonctionnalités existantes
suivantes :

• Gestion d'un historique sur les appels (appels reçus, appels effectués,
appels en absence) avec possibilité de rejouer ces appels.
• Gestion d'une notion d'état de présence pour l'utilisateur pour pouvoir
passer en mode silence ou absent, à la manière des outils de messagerie
instantanée.
• Gestion d'une liste de contacts.

Suite à des discussions avec les développeurs actuels, j'ai ensuite déterminé les
fonctionnalités suivantes, non intégrées actuellement, et qui présentaient un
intérêt :

• Développement d'un historique modulaire qui permette d'archiver tout type

de commandes à venir (appel vidéo, envoi de SMS, lancement d'une
discussion texte, etc).
• Possibilité de se connecter sous plusieurs identités à la fois, pour pouvoir
offrir aux utilisateurs la possibilité d'utiliser un compte personnel et un
compte professionnel.
• Gestion complète des doubles appels et plus généralement des appels
multiples. La téléphonie sur IP ne limite plus cet aspect, à contrario de la
téléphonie classique, et il est donc intéressant d'en profiter.

Le schéma ci-dessous décrit de manière simplifiée les scénarios offerts par

l'application à l'utilisateur.

13
 6.2. Conception des fonctionnalités

Plusieurs outils ont été testés pour la conception UML du logiciel. Il s'avère
qu'il n'existe pas encore d'outil « idéal » pour la conception. J'ai cherché en vain un
outil qui soit rapide et complet, mais qui génère des graphes UML qui soient
exploitables ultérieurement (un graphe trop complexe ne serait pas utilisé car
difficilement compréhensible), et qui permette de garder une relation étroite entre
le code et la conception (répercussion des modifications de l'un vers l'autre et
réciproquement).

Au début du projet, le choix du langage n'étant pas encore fait, j'ai utilisé
Eclipse10 couplé avec le plugin Omondo 11 pour définir les principales fonctionnalités.
Par la suite j'ai testé Rational, Together, Poseidon, Umbrello et Dia 12, et aucun ne
m'a donné satisfaction. Au final Together est l'outil qui s'est le plus rapproché de
mes attentes ; néanmoins, certaines de ses limitations pour les diagrammes de
classes lors de l'utilisation de code C# ne m'ont pas permis, par exemple, d'afficher
les nom des relations, ou leurs cardinalités. Les diagrammes générés avec Omondo
intègrent ces informations.

Pendant la phase de conception et de modélisation du softphone, les critères

suivants ont été particulièrement pris en compte :

• Utilisation d'interface dans le cadre de la persistance des données ;

• Modularité dans la modélisation pour permettre de faire évoluer la
conception ;
• Utilisation de « design patterns » quand cela est possible pour faciliter la
compréhension ;
10Eclipse est un environnement de développement focalisé sur Java
11Omondo est un plugin UML pour Eclipse
12Différents outils pour UML dont certains sont libres

14
 • Découpage des classes de telle sorte qu'il soit aisé de mettre en place des
tests unitaires ;
• Indépendance de la couche métier avec la couche de présentation en
utilisant un système similaire à PAC détaillé en annexe.

6.2.1. Conception de l'historique du softphone

1. Persistance des données

L'historique permet de sauvegarder les différents événements qui arrivent

pendant l'exécution du softphone, entre autres les appels sortants et les appels
entrants. L'archivage de l'historique passe par une interface, et une
implémentation XML ainsi qu'une implémentation en mémoire ont été
développées. Cette architecture permettra à l'avenir de proposer aux utilisateurs
de sauvegarder ces informations en réseau (SOAP ou XML-RPC) pour qu'ils aient
leur historique quel que soit le poste qu'ils utilisent.

Illustration 1 schéma de persistance des données

2. Utilisation des patterns

L'historique utilise le pattern memento pour l'archivage des objets ainsi

que le pattern command 13 pour l'exécution des commandes. L'utilisation du
pattern memento permettra d'archiver différents type de commandes exécutées
et de proposer à l'utilisateur une visualisation de l'historique. La conception a été
faite de telle manière à faciliter le travail à venir des développeurs lors de
l'archivage de nouvelles commandes (initialisation d'une discussion vidéo, texte).
Le diagramme de classe suivant détaille cette partie, un diagramme de séquence
lors du passage d'un appel est disponible en annexe.

13Ces patterns sont expliqués à l'adresse http://www.dofactory.com/Patterns/Patterns.aspx

15
 ...Wengo.History.EventHistory interface
...EventCommandCaller
+EventHistory Interface pour l'invoker
+EventHistory du pattern command
peers:PeerCollection
+addMemento:void sipconnection:ISIPConnection
+save:void
mementos:HistoryMementoCollection
hasHistory:bool
AddedMemento
SoftPhone Wengo.SoftPhone

CareTaker (pattern memento)

Originator (pattern memento)

...History.HistoryMemento ...Wengo.Call.PhoneCall
+serialize:XmlElement
+unserialize:void
+isReplayable:bool
+replay:void interface
interface ...History.HistoryOriginator
+ToString:string ...Command.EventCommand
+updateDuration:void +createMemento:HistoryMemento
+execute:void +setMemento:void

Memento (pattern memento).

Classe de sauvegarde des informations ...Wengo.Command.MakeCall
des objets
+execute:void
+createMemento:HistoryMemento
concreteCommand (pattern +setMemento:void
command)

6.2.2. Conception de la « contact list »

La contact list actuelle du Wengophone permet simplement de stocker des

correspondants, sans prendre en considération la possibilité de les placer dans
des groupes à la manière des outils de messagerie instantanée. La conception
suivante prend en compte cette possibilité, et utilise le principe d'une couche de
persistance des données à la manière de l'historique pour faciliter la mise en
place ultérieure d'archivage distant.

16
Illustration 2 Diagramme de classe pour la "contact list"

Dans ce diagramme, on notera l'utilisation de classes « *Collection », elles

permettent de typer les objets gérés par la collection et de fiabiliser ainsi
l'implémentation. Étant donné la simplicité de cette partie, aucun pattern n'a été
utilisé.

6.2.3. Conception de la partie téléphonie

Pour la partie téléphonie, les fonctionnalités importantes demandées

étaient les suivantes :

• possibilité de gérer les appels multiples

• possibilité de gérer des connexions sous plusieurs identités simultanément
• possibilité d'utiliser n'importe quelle pile SIP
• possibilité de prendre en compte des comptes Wengo qui nécessitent une
identification sur un « SSO », mais aussi des comptes SIP normaux.

La conception a pris en compte toutes ces demandes. Le pattern « state »

a été utilisé à plusieurs reprises, pour la gestion d'état des connexions SIP, des
différents appels, et pour la notion de présence (connecté, absent, déconnecté).
Un diagramme complet est présent en annexe à ce rapport.

17
6.2.4. Développement de l'IHM
Le développement de la partie IHM de l'application utilise une méthode
similaire à PAC, et se compose en trois couches : la couche métier, la couche
contrôle et la couche de présentation. Cette implémentation de PAC est détaillée
de manière plus complète dans un document en annexe à ce rapport, rédigé
dans un but pédagogique pour l'équipe responsable du Wengophone actuel et
afin qu'elle puisse appliquer cette méthode à l'avenir.

Pour expliquer la conception autour de l'IHM, prenons l'exemple d'une

partie spécifique du nouveau softphone : sa gestion d'historique. La gestion de
l'historique d'un point de vue métier, en version simplifiée, comprend une classe
EventHistory. Cette classe propose de s'abonner à un type d'évènement qui
permet d'être informé de la création d'un nouveau Memento archivé (les
évènements utilisent le pattern observateur). Pour déployer une IHM d'un
softphone qui intègre cette instance d'EventHistory nous avons le schéma
suivant :

Les contrôles sont informés de changements au niveau métier par le biais

d'évènements auxquels ils se sont abonnés. La couche métier est autonome et
elle peut être exécutée seule, ce qui permet d'implémenter des tests unitaires.
Les contrôles remontent ensuite si c'est nécessaire une information à la couche
de présentation par le biais d'interface, ce qui a l'avantage de pouvoir utiliser
n'importe quelle implémentation graphique (Windows, GTK, Cocoa, Qt, etc). Un
thread à part est utilisé pour la présentation pour éviter des blocages de son
rafraîchissement.

Les objets qui constituent l'implémentation graphique ne contiennent aucune

intelligence et associent simplement des boutons sur des méthodes de la couche

18
de contrôle. Il est en conséquence très aisé de créer des implémentations avec
de nouvelles bibliothèques graphiques.

Pour l'affichage, l'objet graphique de la classe principale (Softphone dans ce cas

précis) se contente d'afficher un « widget » exporté par l'objet graphique qu'il
souhaite inclure graphiquement. L'objet graphique de la classe principale est
donc un emboîtement d'autres widgets. Pour comprendre le principe, voir la
capture d'écran ci-dessous, le widget exporté par l'objet graphique de
l'historique a été colorié en jaune, l'application étant gérée par l'objet graphique
de la classe principale. Cette méthode permet de définir directement dans les
objets graphiques de chaque classe la manière avec laquelle ils s'affichent, sans
que cela impacte sur les autres objets graphiques environnants.

Pour plus de détails sur la conception de l'IHM et sur l'implémentation de PAC au

sein de ce projet, je vous invite à lire le document situé en annexe à ce rapport.

19
 6.3. Implémentation
6.3.1. Les choix de l'implémentation

Le choix du langage pour l'implémentation s'est orienté vers C#. En effet, j'ai
désiré pouvoir bénéficier d'un langage objet haut-niveau multiplateforme, pourvu
d'un typage fort et statique, et qui me permette d'intégrer facilement des
bibliothèques existantes développées en C. De plus les implémentations de C# à la
manière de Java proposent une notion de ramasse-miette pour éviter les
problèmes inhérents aux allocations mémoires.

L'environnement Mono permet d'accéder entre autres aux plateformes Linux

et Mac, et d'accélérer le développement de l'application en fournissant de base un
jeu de bibliothèques complet (XML, Introspection, Serialisation, etc). De plus, les
performances actuelles de Mono ou de la plateforme « .Net » Microsoft permettent
d'envisager son utilisation même pour des logiciels pour lesquels il existe des
contraintes d'optimisations.

Un nombre important de composants .Net disponibles sur Internet

permettent enfin de combler les besoins récurrents, et sont en général diffusés
sous des licences qui permettent leur réutilisation sans restrictions. De plus
C#/.Net permet d'utiliser, sous Windows, les composants graphiques standards
(WinForms) et d'obtenir une présentation qui s'intègre bien au sein du système
d'exploitation. Ce choix permettra au final de se focaliser sur la modélisation plus
que sur l'implémentation finale, et de valider rapidement le modèle proposé.

6.3.2. Rigueur durant le projet

Pendant la phase d 'implémentation j'ai conservé une archive des

modifications apportées à l'application pour pouvoir avoir un « log » de mon
travail au jour le jour et répondre à des demandes de ma hiérarchie sur ce qui a
été effectué et ce qui est prévu. L'utilisation du système Subversion 14
comble
déjà une partie de ce besoin, mais l'utilisation d'un « ChangeLog » permet de
résumer plus succinctement les modifications apportées.

Les entrées rajoutées dans le fichier ChangeLog ressemble à :

14SVN est un outil de gestion de révision similaire à CVS mais plus récent

20
 J'ai aussi conservé une « roadmap » succincte sur les fonctionnalités ultérieures
à développer. Ces fichiers roadmad et Changelog ne sont censés être lus que par
les développeurs qui contribuent au projet.

Pour la partie documentation du code source, l'éditeur utilisé pendant la phase

d'implémentation « Visual Studio .Net 2003 » propose, entre autres, d'en faciliter
l'écriture. La documentation pour le langage C# est au format XML et ressemble
à ce qui suit :

Il est à noter que le compilateur vérifie la syntaxe de la documentation et vérifie

si les paramètres indiqués sont en phase avec le code. Il est possible ensuite de
générer automatiquement une version HTML de la documentation tirée
directement de ces commentaires. Étant donné le niveau de verbosité, le résultat
n'a pas été intégré à ce rapport, mais est disponible sur la page
http://penso.info/wengo/.

6.3.3. Intégration de la bibliothèque phAPI

Pour mon implémentation C#, j'ai décidé d'utiliser phApi. Cette
bibliothèque est multi-plateforme et il existe chez Wengo les compétences pour
résoudre des problèmes éventuels liés à son utilisation à partir d'un autre
langage. Il est à noter que la conception effectuée pour la partie SIP permet
d'intégrer plusieurs type de pile SIP, et de les utiliser en même temps. Il est
donc envisageable d'intégrer d'autres pile SIP pour comparer leur qualité.

CLI15 est implémenté de telle manière qu'il facilite l'interaction avec du

code existant, et il propose en natif d'importer des fonctions disponibles dans des

15 Voir http://www.ecma-international.org/publications/standards/Ecma-335.htm

21
bibliothèques C. La bibliothèque graphique GTK# utilise d'ailleurs ce procédé et il
est tout à fait envisageable d'automatiser la génération du code C#. En théorie,
il suffit de déclarer la fonction qu'on souhaite utiliser dans une bibliothèque
spécifique, et l'interpréteur CLI se chargera du reste. En pratique c'est un peu
plus compliqué, surtout dans le cas de passage de pointeurs comme c'est le cas
dans le cadre d'une pile SIP pour les callbacks.

Dans le cadre de la pile phAPI il est nécessaire à l'initialisation de passer

en paramètre une structure de pointeurs de fonctions utilisés en tant que
« callbacks » lors d'évènements futurs. Le principal problème lors de l'intégration
de tels procédés est de s'assurer que ces pointeurs de fonctions ne seront pas
nettoyés par le ramasse-miette de l'environnement CLI. Si un problème persiste,
vérifier à nouveau une seconde fois que les pointeurs ne sont pas « ramassés ».

Au niveau du code source on déclarera dans la classe chargée de

« wrapper » la bibliothèque C les différentes fonctions avec la syntaxe suivante :

[DllImport("phapi")]
private static extern int phInit(ref phCallbacks callback, String server, int
asyncmode);

Windows ira trouver de lui-même le fichier phapi.dll et exécutera la fonction qui

convient. Pour plus de détails sur l'importation de bibliothèque C, je vous invite à
lire les informations données à l'adresse :

http://www.mono-project.com/Interop_with_Native_Libraries

6.3.4. Non implémenté

Les contraintes de temps pour ce projet ne m'ont pas permis de tout

développer. L'application avait pour but d'être la preuve qu'une réflexion sur la
conception permettrait d'avoir une implémentation qui fonctionne mieux que la
version publique actuelle. Les fonctionnalités qui ne représentent pas de
difficultés en terme de développement ont donc été mises de côté. Afin de
finaliser l'application les fonctionnalités suivantes sont à envisager :

• Possibilité d'éditer les informations des comptes utilisés pour se connecter.

• Possibilité d'éditer les informations sur les personnes présentes dans la
« contact-list ».
• Système d'installation automatique basé sur XML et MSI (installation
Windows).
• Possibilité de bloquer un utilisateur.
• La présence des utilisateurs de la contact-list (impossible à implémenter,
phAPI était « buggué » au moment de la tentative de le développer).
• Implémenter l'envoi de SMS qui s'effectue à travers une requête HTTP sur
un serveur Wengo.

De plus, n'étant pas maître d'oeuvre sur les pile SIP, il faudrait développer des

22
tests unitaires qui valident les fonctionnalités minimales nécessaires à leur
utilisation au sein du softphone.

6.3.5. Capture d'écran

La capture suivante montre la nouvelle application développée lors d'un appel

téléphonique.

23
7. Idées sur la plateforme « idéale » de téléphonie

La plateforme idéale de téléphonie passera forcément par un système

similaire au P2P pour la diffusion des flux audios et vidéos (RTP). Skype utilise déjà
cette méthode. Les tarifs de la téléphonie seront amenés à l'avenir à être réduits
au minimum et les prestataires devront trouver des techniques qui permettent
d'abaisser les coûts de maintenance par utilisateur. De plus, la mise en place d'un
système « à-la » Peer-To-Peer oblige à prendre immédiatement en compte les
problématiques de chiffrement des flux des contenus.

En résumé, la solution devrait respecter les points suivants :

• Chiffrement des flux médias entre les utilisateurs

• Utilisation de la bande passante par utilisateur faible pour l'opérateur
• Utilisation d'un réseau similaire au P2P pour les échanges en relation avec les
flux médias.

Le schéma suivant donne une idée de l'architecture réseau qui remplirait ces
fonctionnalités.

Sont présents sur ce schéma :

24
 • Des clients utilisateurs du service Wengo
• Des « supernoeuds » qui peuvent jouer le rôle de proxy RTP aujourd'hui
supporté par Wengo uniquement.
• Le proxy SIP hébergé chez Wengo qui centralise la réception des commandes
(passer un appel, etc)
• Un proxy RTP de secours hébergé par Wengo

Les supernoeuds sont des clients Wengo qui ont activé la possibilité de jouer
le rôle de relais, et qui respectent un nombre de critères minimum pour être élu à
ce titre (connectivité rapide, tourner en permanence, latence réduite, etc). Un
réseau P2P indépendant et connectant les différents supernoeuds permet, avec la
connaissance d'un seul d'entre eux, d'avoir une liste des supernoeuds existants.

Chaque client est chargé de conserver en mémoire une liste de supernoeuds

avec lesquels il a une connectivité correcte en terme de latence. Lors de la
demande de connexion avec un autre client, le client fournirait l'adresse du
supernoeud qu'il souhaite utiliser au lieu de son adresse IP propre, et demanderait
au supernoeud l'ouverture d'un port de relais.

L'élaboration complète d'un système basé sur le P2P dépasse le sujet de ce

stage et de ce rapport, néanmoins voici quelques points qui demandent réflexion :

• Possibilité d'utiliser une connexion en direct dans le cas où deux utilisateurs se

trouvent derrière sur le même réseau de type NAT.
• Ne pas surcharger un supernoeud en terme de nombre de connexions, et de
bande passante (celle-ci pouvant être configurée par l'utilisateur du
supernoeud).
• Le chiffrement systématique à l'aide du protocole SRTP entre les
communiquants, étant donné qu'il est probable que le flux passe par un
supernoeud.
• L'algorithme qui permet à des clients de connaître les supernoeuds qui leur
sont proches, et de tester la connectivité qu'ils ont avec eux

25
8. Conclusion

Mes priorités pendant ce stage ont été de laisser des documents et du code
source exploitables à l'avenir par l'équipe actuelle. Un effort a été fait dans la
documentation du code source développé et j'ai expliqué régulièrement à mes
collègues le travail effectué pour qu'ils puissent en prendre le contrôle
ultérieurement.

Ce stage m'a permis de confronter l'expertise acquise pendant la formation

avec les besoins concrets d'une entreprise, et de voir la difficulté d'utiliser toutes
les techniques disponibles pour les architectures logicielles. Peu d'outils permettent
par exemple d'utiliser de l'OCL pour générer des scénarios de tests dans le langage
utilisé dans l'implémentation, peu d'outils permettent de coupler efficacement les
diagrammes UML et le code source, etc. L'existence de modélisation semi-formelle
type UML facilite grandement la collaboration entre développeurs mais se bute
toujours à la liberté d'interprétation de la part de certains en raison de la
connaissance approximative de sa norme, d'autant plus pour la version à venir
(2.0) encore peu connue.

Pour la fiabilité d'un logiciel, pour faciliter sa pérennité, et pour assurer la

non intégration de nouveaux bugs pendant sa phase de conception, il est
absolument indispensable de prévoir des tests divers, unitaires et fonctionnels.
Néanmoins, en pratique, il est difficile d'appliquer cette règle sans une volonté forte
de la part des responsables. En effet les développeurs sont peu enclins à le faire
d'eux-même, les tests sont peu gratifiants vis à vis de leur hiérarchie, et ils
pourront difficilement montrer la valeur ajoutée de leur travail.

Tout au long de mon stage j'ai insisté sur l'importance d'avoir une
architecture logicielle réfléchie, particulièrement dans une société dont la raison
d'exister provient des outils qu'elle développe et qui souhaite capitaliser cette
expérience.

Je remercie les dirigeants de Wengo pour m'avoir donné leur confiance.

26
ANNEXES