rm UNIVERSITY DE
M SHERBROOKE
Facultedeglnie
Departement tie genie electrique et genie informatique
GESTI0N DES INTERACTIONS BE SERVICES DE
TELEFHONIE SUR IF B A T I S SUR JAIN JCC/JCAT
Memoire cle maitrise es sciences appliquees
Speciality: gftiie electrique
Composition du jury - M. Ahmed KHOUMSI - M. Zohair CHENTOUF - Mme Soumava CHERKAOUI
1*1
Library and Archives Canada Published Heritage Branch 395 Wellington Street Ottawa ON K1A0N4 Canada Bibliotheque et Archives Canada Direction du Patrimoine de I'edition 395, rue Wellington Ottawa ON K1A0N4 CanadaYour file Votre reference ISBN: 978-0-494-42968-6 Our file Notre reference ISBN: 978-0-494-42968-6
NOTICE:
The author has granted a non-exclusive license allowing Library and Archives Canada to reproduce, publish, archive, preserve, conserve, communicate to the public by
telecommunication or on the Internet, loan, distribute and sell theses
worldwide, for commercial or non-commercial purposes, in microform, paper, electronic and/or any other formats.
AVIS:
L'auteur a accorde une licence non exclusive permettant a la Bibliotheque et Archives Canada de reproduire, publier, archiver,
sauvegarder, conserver, transmettre au public par telecommunication ou par Plntemet, prefer, distribuer et vendre des theses partout dans le monde, a des fins commerciales ou autres, sur support microforme, papier, electronique et/ou autres formats.
The author retains copyright ownership and moral rights in this thesis. Neither the thesis nor substantial extracts from it may be printed or otherwise reproduced without the author's permission.
L'auteur conserve la propriete du droit d'auteur et des droits moraux qui protege cette these. Ni la these ni des extraits substantiels de celle-ci ne doivent etre imprimes ou autrement reproduits sans son autorisation.
In compliance with the Canadian Privacy Act some supporting forms may have been removed from this thesis.
Conformement a la loi canadienne sur la protection de la vie privee, quelques formulaires secondaires ont ete enleves de cette these.
While these forms may be included in the document page count,
their removal does not represent any loss of content from the thesis.
Canada
Bien que ces formulaires
aient inclus dans la pagination, il n'y aura aucun contenu manquant.
Resume
Le secteur des telecommunications connait une avancee spectaculaire depuis quelques annees et Pavenement de la Telephonie sur IP (TsIP) a permis d'avoir une convergence se situant non seulement au niveau du contenu (convergence de la voix, des donnees et du multimedia) mais aussi au niveau architectural (convergence du reseau Internet, du reseau de telephonie classique et du reseau de telephonie cellulaire). La TsIP est une technologie qui, du fait de ses caracteristiques propres dont notamment la complexite des services, Pouverture aux tiers fournisseurs et la possibilite donnee aux utilisateurs finaux de pouvoir programmer et modifier les services, rend plus delicat le probleme des Interactions de Services (IS). Une IS, plus connue sous le terme FI (Feature Interaction), se produit quand un service modifie ou inhibe les fonctionnalites ou 1'execution d'un ou plusieurs autres services. Les IS ne sont pas un probleme nouveau et leur resolution est plus difficile dans le cas d'une architecture emergente comme la TsIP, qui peut utiliser divers protocoles de signalisation comme SIP (Session Initiation Protocol). C'est dans la perspective d'apporter une contribution de solution a ce probleme recurrent des IS et dans le cas particulier de la TsIP, que ce projet de recherche a ete effectue au Departement de Genie Electrique et de Genie Informatique de la Faculte de Genie de PUniversite de Sherbrooke.
La solution de gestion des IS presentee dans ce projet, est une solution architecturale et cooperative implementee au dessus de JCC/JCAT afin de combler la dependance au protocole SIP. Elle s'appuie sur un langage propre FIML (Feature Interaction Management Language) et des agents dits FIMA (Feature Interaction Management Agent) places dans les equipements du reseau de TsIP pour la detection et la resolution des IS. Le langage FIML garantit la confidentialite et la simplicity des services et offre une interface de cooperation qui vehicule Pinformation pertinente pour la gestion des IS. La solution utilise par ailleurs, deux PDR (Procedure de Detection et de Resolution) des IS: la premiere PDR, dite PDR hors ligne est placee dans le terminal utilisateur et opere avant Pexecution des
Remerciements
A M. Ahmed Khoumsi, directeur de ce projet de recherche, je tiens a vous remercier pour m'avoir accepte comme etudiant en maitrise recherche dans votre equipe. Je tiens 6galement a vous faire part de ma tres profonde gratitude, d'une part pour m'avoir mis sur le chemin de cet inte>essant projet de recherche et d'autre part, pour tous les efforts deployes, la disponibilite et les directives prodiguees durant la realisation de ce projet de maitrise.
A M. Zohair Chentouf, codirecteur de ce projet de recherche, je tiens a vous remercier pour les conseils et pour m'avoir guide tout au long de ce projet de recherche. Aussi, je suis tres reconnaissant pour votre disponibilM et vos directives qui m'ont permis de faire un excellent travail dans ce projet.
Je remercie enfin tout le corps enseignant du departement de genie 61ectrique et de genie informatique, et 1'ensemble du personnel administratif qui ont toujours ete a mon ecoute et pour m'avoir fourni les conditions favorables k ma formation et a mes recherches.
TABLE DES MATIERES
LISTE DES FIGURES iv LISTE DES TABLEAUX v INTRODUCTION GENERALE 1 CHAPITRE I PRESENTATION DU PROJET 4
Introduction 4 1 Definition du projet 4 1.1 Contexte et Problematique 4 1.2 Objectifetinteret 5 1.3 Contributions 6 2 Etapes du projet 7 2.1 Elements de base du projet 8
2.2 Les contributions du projet 8 Conclusion 9
PARTIE I ELEMENTS DE BASE DU PROJET 10
CHAPITRE II LA TELEPHONE SUR IP 11 Introduction 11 1 Contexte et fonctionnement de la TsIP 11
1.1 Historique de la TsIP 11 1.2 Definition et objectifs de la TsIP 12
1.3 Principe et architecture 12 1.4 Enjeux de la TsIP 14 2 Les principaux protocoles 15
2.1 Les protocoles de transport et de controle 15
2.2 Les protocoles de signalisation 17
2.2.1 Le protocole H.323 17 2.2.2 Le protocole MGCP 18 3 Le protocole SIP 18 3.1 Contexte et objectifs de SIP 18
3.2 Environnement de SIP 20 3.3 Presentation de l'appel de base de SIP 21
3.4 Raisons du choix de SIP 23 Conclusion 25
CHAPITRE III PLATES-FORMES ARCHITECTURALES DE DEVELOPPEMENT. 26
Introduction 26 1 Les principales plates-formes architecturales 26
1.1 Parlay 27 1.2 OSA 28 1.3 JAIN 29 2 L'API JAIN SIP 32
3.1 Structure de JCC 34 3.2 Enjeux du developpement avec JCC 35
Conclusion 36 CHAPITREIV INTERACTIONS DE SERVICES 37
Introduction 37
1 Generalites 37 1.1 Definition 37 1-2 Causes des IS et methodes de resolution 38
2 Etat de Part dans la telephonie classique 41 3 Etat de l'art dans une architecture SIP 43
Conclusion 44
PARTIE II LES CONTRIBUTIONS DE CE PROJET 45 CHAPITRE V LE LANGAGE FIML: NOUVELLE VERSION 46
Introduction 46 1 Definition et objectifs de FIML 46
2 Structure de FIML 47 2.1 Les donnees primitives 48 2.2 Classes, fonctions et predicats 49 2.3 Description de la classe Call 50 2.4 Description de la classe Address 51 2.5 Operateurs et regies de modelisation 55
2.6 Les principales ameliorations 58 2.6.1 Reorganisation des deux classes 58
2.6.2 Ajout de primitives 59 2.6.3 Ajout de predicats 59 3 Modelisation de services en FIML 60
3.1 Les points de traitements 60 3.2 Exemples de modeles de services 62
Conclusion 64 CHAPITRE VI SPECIFICATION ET CONCEPTION DE LA SOLUTION DE
DETECTION ET DE RESOLUTION 65 Introduction 65 1 Principe de la solution de detection et de resolution 66
1.1. Caracteristiques de la solution de detection et de resolution 66 1.2. Principe general de la solution de detection et de resolution 67
2 Procedure de detection des IS 70 3 Algorithme de detection et de resolution hors ligne 72
CHAPITRE VII REALISATION DE LA SOLUTION DE DETECTION ET DE
RESOLUTION 89 Introduction 89
1 Creation des services en JAIN JCC/JCAT 89
1.1 Liste des services 90 1.2 Conception des services 91 1.3 Mapping de JAIN SIP avec JCC/JCAT 95
2 Structure des composants de l'architecture 98
2.1 Structure du terminal utilisateur 98
2.1.1 Structure de UFIMA 99 2.1.2 Structure de SCEE 100 2.2 Structure du Proxy Server 102
2.2.1 Structure de NFIMA 103 2.2.2 Structure du SCEE 103 3 Traitement des IS 104 3.1 Traitement des IS hors ligne dans le terminal utilisateur 104
3.2 Traitement des IS en ligne dans le reseau 107
4 Tests et resultats I l l 4.1 Generalites sur les tests I l l 4.2 Au niveau du terminal utilisateur 112
4.3 Au niveau du reseau 114 Conclusion 116
CONCLUSION GENERALE 117
BIBLIOGRAPHIE 120 ANNEXE DIAGRAMMES DE SEQUENCES DE SERVICES 124
LISTE DES FIGURES
Figure II-1 Processus de transmission de la voix sur un reseau IP 13
Figure II- 2 Protocoles de TsIP et modele OSI 15 Figure II- 3 Exemple de description SDP 19 Figure II- 4 Exemple d'appel en SIP 22 Figure III-1 Architecture de JAIN 30 Figure III- 2 JAIN SIP API architecture 33 Figure III- 3 Relation entre les principaux elements de JCC 35
Figure VI- 1 Architecture de UFIMA 68 Figure VI- 2 Architecture de NFIMA 69 Figure VI- 3 Algorithme de detection-resolution hors ligne 73
Figure VI- 4 Algorithme de detection-resolution en ligne 79 Figure VI- 5 Cooperation entre les FIMA pour detecter et resoudre des IS 85
Figure VI- 6 Cooperation entre les FIMA pour detecter et resoudre des IS 86 Figure VI- 7 Architecture et repartition des FIMA dans un reseau de TsIP 87
Figure VII-1 Diagramme de sequence de SC (Simple Call) 93 Figure VII- 2 Mapping de JAIN SIP avec JCC/JCAT pour le service Simple Call 96
Figure VII- 3 Structure du terminal utilisateur 99 Figure VII-4 Structure du Proxy Server 102 Figure VII- 5 Traitement des IS hors ligne 106 Figure VII- 6 Envoi des modeles FIML au NFIMA 108
LISTE DES TABLEAUX
Tableau IV- 1 Methodes de resolution utilisees 41
Tableau V- 1 Points de traitement 60 Tableau VI-1 Exemples de detection d'lS 71
Tableau VI- 2 Application de la PDR hors ligne sur les services CFBL et CFU 75 Tableau VI- 3 Application de la PDR hors ligne sur les services F C F et CFBL 75 Tableau VI- 4 Application de la PDR hors ligne pour la detection-resolution des IS 76
Tableau VII- 1 Description du diagramme de sequence de SC 94
Tableau VII- 2 Description du mapping 97 Tableau VII- 3 Mapping des messages SIP 97 Tableau VII- 4 Traitement des IS hors ligne 107
Tableau VII- 5 Traitement des IS en ligne (l6re partie) 110
INTRODUCTION GENERALE
Mettre la technologie au service de 1'amelioration de la qualite de vie, tel est l'embleme d'un certain nombre d'institutions de R&D (Recherche et Developpement) operant dans le domaine des technologies de l'information et de la communication. Le developpement de ce secteur est tres ahurissant. En effet, en quelques annees on a assiste a l'avenement de la telephonie classique c'est-a-dire le RTC (Reseau Telephonique Commute) [34], des premiere et deuxieme generations de telephonie cellulaire, et du reseau Internet. Par ailleurs, depuis le debut du nouveau millenaire le secteur a continue sa fulgurante evolution avec de profondes mutations. On a ainsi vu Papparition de la 3G (troisieme generation de telephonie cellulaire) [40,41], la Telephonie sur IP {Internet Protocol) [31,32] et bientot 1TMS {IP Multimedia Subsystem) [44] et la 4G [43]. Toutes ces nouvelles technologies tendent a faciliter la communication en offrant une grande multitude de services avec une QdS (Qualite de Service) en nette progression.
Cependant, le developpement rapide des services de telecommunications est entrave par le probleme des IS (Interactions de Services) [1, 2, 15,17] plus connu sous le terme de FI {Feature Interaction). Une IS se produit quand un service modifie ou inhibe les fonctionnalites ou l'execution d'un autre service. Les IS ne sont pas un phenomene nouveau car ils existaient depuis l'avenement du RI (Reseau Intelligent) [42] dans la telephonie classique. Les IS, intimement liees a la technologie utilisee pour la conception des services et a l'architecture du reseau dans lequel ces services sont deployes, sont toutefois un probleme recurrent et il faut continuellement chercher de meilleures solutions.
La recherche de solutions aux IS est effectivement perpetuelle et devient tres complexe avec la convergence des nouvelles technologies. Cette convergence se situe au niveau du contenu (convergence de la voix, des donnees et du multimedia) et aussi au niveau architectural (convergence du reseau Internet, du reseau RTC et du reseau de telephonie
de communication et son facile deploiement, la telephonie sur IP est une technologie largement utilisee a travers le monde [31,32] ; elle peut etre utilisee avec plusieurs protocoles normalises dont le protocole SIP {Session Initiation Protocol) [21-23], retenu dans ce projet a cause de ses promesses et ses nombreux avantages. En outre, la telephonie sur IP est concue avec un certain nombre de plates-formes architecturales de developpement bien interessantes, dont notamment les plates-formes JAIN JCC/JCAT {Java API (Application Programming Interface ) for Integrated Networks Java Call Control/Java Coordination And Transaction) [28-30] qui ont ete choisies pour ce projet. Cette nouvelle technologie dite emergente, permet de concevoir des services tres interessants et complexes et cela tend a rendre plus difficile la resolution des IS. C'est ainsi que des travaux de recherche sont faits constamment afin d'apporter des solutions a ce probleme recursif.
C'est dans cette optique que ce projet de recherche a ete effectue avec pour propos la gestion des IS de telephonie SIP batis sur JAIN JCC/JCAT. Ce projet de recherche a ete realise au Departement de Genie Electrique et de Genie Informatique de la Faculte de Genie de l'Universite de Sherbrooke. Le present document qui en est le memoire se compose de deux parties :
La premiere partie traite des elements de base du projet; elle comprend trois chapitres : - Le premier chapitre est introductif et donne une bonne presentation du projet. Les
objectifs et interets du projet seront exposes d'une part, et d'autre part les differentes etapes du projet.
- Le deuxieme chapitre est consacre a la Telephonie sur IP. Le contexte et le fonctionnement de la Telephonie sur IP seront presentes en detail en premier lieu, les principaux protocoles utilises en deuxieme lieu, et en dernier lieu une description du protocole SIP sera donnee.
Le troisieme chapitre sera l'occasion de donner des details sur les plates-formes architecturales de developpement et les raisons de leurs choix.
- Le quatrieme chapitre se consacre aux IS. D'abord, un apercu de l'etat de l'art de ce probleme recurrent sera expose. Ensuite, les travaux sur lesquels ce projet de recherche s'est base pour apporter les contributions seront presentes. Puis, les
types et les origines des IS, et les methodes de resolution seront evoques. Enfin, plus d'attention sera accordee aux IS dans 1'architecture SIP.
La deuxieme partie traite des contributions du projet. Elle comprend trois chapitres.
- Le cinquieme chapitre ou le premier de la seconde partie, traite de FIML (Feature
Interaction Management Language) [16,17]. Les objectifs et la structure de ce
langage sont exposes d'une part, et d'autre part un certain nombre de services et de preferences seront decrits avec ce langage.
- Le sixieme chapitre sera 1'occasion de decrire les specifications et la conception de la solution de detection et de resolution des IS proposee. Des architectures des solutions hors ligne et en ligne seront presentees.
- Le septieme chapitre et dernier du projet presente 1'implementation de la solution. La realisation des services de Telephonie sur IP et la structure de la solution de detection et de resolution des IS seront presentees d'une part et d'autre part les tests et resultats seront evoques.
II est a noter qu'en annexe, des diagrammes de sequences de UML (Unified Modeling
CHAPITRE I
PRESENTATION DU PROJET
Introduction
Les nouvelles technologies de communication de ces dernieres annees sont tres captivantes et offrent des services complexes et bien interessants. C'est notamment le cas de la Telephonie sur IP {Internet Protocol). Cette technologie, bien repandue, offre effectivement un large eventail de services qui ne sont toutefois pas en marge du probleme des IS (Interactions de Services) qui existent depuis quelques decennies et auxquelles des solutions ont ete apportees. Cependant, du fait de leur recurrence, les IS sont un phenomene sans vraiment de solution definitive et la recherche de solutions doit etre continuelle. Ce projet de recherche se propose d'apporter une contribution a la resolution des IS dans la Telephonie sur IP et le present chapitre se consacre a la presentation du dit projet.
De prime abord, les objectifs et l'interet du projet de recherche seront discutes, puis les differentes etapes du projet seront presentees.
1 Definition du projet
1.1 Contexte et Problematique
La Telephonie sur IP est une technologie de communication permettant de faire passer la voix, le multimedia et les donnees sur le reseau Internet. Plusieurs protocoles sont standardises et le choix de ce projet s'est arrete sur le protocole SIP (Session Initiation Protocol) a cause de ses promesses et ses nombreux privileges. Comme mentionne dans [23], le protocole SIP remplit principalement les fonctionnalites de : la localisation des usagers, revaluation de la disponibilite des usagers, revaluation des capacites des terminaux, l'etablissement de session et la gestion de session. La Telephonie sur IP offre un grand nombre de services interessants et complexes. Ces services sont le plus souvent developpes par differentes compagnies dans differents reseaux, chaque reseau pouvant avoir une architecture specifique. Les services, lorsque mis ensemble, peuvent engendrer des interferences dites interactions de services (IS). La Telephonie sur IP, pour offrir une qualite de service a la hauteur du RI (Reseau Intelligent), est amenee a trouver une solution efficace et optimale au probleme des IS.
Une IS, plus connue sous le terme de FI (Feature Interaction), se manifeste lorsque deux ou plusieurs services, qui fonctionnent correctement lorsque considered separement, se comportent d'une maniere inattendue et eventuellement indesirable lorsqu'ils sont executes ensemble [3]. Une IS peut etre desirable, mais le propos de ce travail ne considere que les IS indesirables. Afin de mieux illustrer ce qu'est une IS, l'exemple suivant note dans [17] est considere. C'est le cas de trois abonnes A, B, et C. L'abonne A s'est inscrit au service de Filtrage d'Appels au Depart (en anglais, Originating Call Screening (OCS)) lui permettant d'interdire des appels depuis son telephone vers une liste d'adresses L. L'utilisateur B a pour sa part le service de Redirection d'Appels (an anglais, Call Forwarding Unconditional (CFU)) lui permettant de rediriger ses appels. La situation suivante est supposee dans cet exemple: B a redirige ses appels vers C et que C se trouve dans la liste L. Lorsque A appelle B, son appel sera transfere vers C et il communiquera avec un abonne se trouvant dans sa liste d'adresses interdites. II y a la une IS car le service OCS de A et le service CFU de B ont donne lieu a une communication entre A et C qui, normalement, est interdite.
Les IS ne sont pas un obstacle nouveau. Le RI en connaissait et des solutions ont ete trouvees [4,7]. II s'agit principalement de pouvoir les detecter et les resoudre. Detecter une IS, c'est reperer une interaction entre plusieurs services tandis que la resolution consiste a eliminer et supprimer LIS detectee. Cependant, la resolution des IS dans les architectures emergentes, dont la Telephonie sur IP, est embryonnaire et d'une difficulte croissante en raison de la rapide evolution de ces types d'architectures.
1.2 Objectif et interet
Le propos du present travail est de trouver une solution optimale et aussi claire, pour gerer les IS de Telephonie sur IP basee sur le protocole SIP. La recherche de solutions dans le but de resoudre le probleme des IS prend de plus en plus de Fampleur. Plusieurs auteurs s'y sont interesses et des solutions sont proposees, specialement dans les travaux de recherche
architecturale et cooperative, est bien interessante mais plusieurs points sont a ameliorer. Voici les trois elements que ce projet de recherche s'est fixe pour objectifd'ameliorer :
L'algorithme de detection-resolution en ligne : Cet algorithme, dont le principe de base est la collaboration entre les differents equipements utilises dans le reseau de telecommunications, presente quelques faiblesses. II est effectivement decrit de maniere textuelle et pourrait etre decrit plus formellement afin de pouvoir F analyser et F ameliorer de maniere rigoureuse.
Le langage propre FIML (Feature Interactions Management Language), dont Fobjet est de produire une interface de cooperation qui vehicule Finformation pertinente pour le traitement des IS [16], est a revoir de sorte a F ameliorer. Ce langage propose dans [14-17] presente principalement deux trous : d'une part, les variables, les predicats et les fonctions ne sont pas clairement definis, ce qui amene a considerer par exemple une fonction comme un predicat et vice versa, et d'autre part plusieurs variables ou predicats peuvent etre regroupes, ce qui clarifiera davantage le langage.
- L'implementation de la solution directement sous FAPI (Application Programming Interface) JAIN SIP peut etre vue comme une faiblesse. Cette API, de niveau protocole et definissant ce que doivent fournir les piles (Stacks) de signalisation [20], est dependante du protocole utilise, ce qui peut etre considere comme une restriction.
Ce projet de recherche se propose done d'apporter une solution qui surmonte les faiblesses des trois points evoques ci-dessus, dans le but de mieux gerer les IS de telephonie SIP batis sur les plates-formes JAIN JCC/JCAT (Java API (Application Programming Interface )for Integrated Networks Java Call Control/Java Coordination And Transaction).
1.3 Contributions
Trois contributions sont apportees et qui sont respectivement reliees aux faiblesses des trois points mentionnes dans la section 1.2.
D'abord, une revision du langage FIML s'impose. Une proposition d'amelioration faite dans [14-17] servira de base. Cette revision a pour but, d'une part de mieux definir et decrire les classes, les variables, les primitives et les predicats de ce langage propre, et d'autre part de l'optimiser par regroupement de certains parametres tres proches. Ceci permettra de ne plus prendre par exemple une fonction pour un predicat et vice versa, de mieux decrire les services, et surtout de faire une combinaison des modeles de services qui favorisera une detection efficace des IS.
Ensuite, une reformulation de maniere plus rigoureuse de l'algorithme de detection resolution en ligne (c'est-a-dire lorsque les services sont en execution) propose dans [17] sera faite. Ceci dans le but de remplacer son expression textuelle par une representation plus formelle sous forme algorithmique et de diagramme d'etats-transitions. Ceci permettra de mieux analyser et optimiser l'algorithme.
Pour ces memes raisons, la procedure de detection-resolution hors ligne (c'est-a-dire lors de la specification et la conception des services) sera elle aussi decrite sous forme algorithmique et de diagramme d'etats - transitions.
Enfin, la derniere contribution principale de ce projet de recherche consiste a faire un appariement (mapping) de JAIN SIP avec la nouvelle API JCC/JCAT. Les services et les applications seront developpes au dessus de JCC et non pas directement au de dessus de JAIN SIP. L'API JCC permettra de combler la dependance de JAIN SIP au protocole SIP, car elle fournit une abstraction des protocoles utilises, et des mecanismes pour la gestion, le traitement et le controle des communications. Ainsi, cet appariement respectera les soucis de portabilite et d'interoperabilite, conformes aux contraintes des NGN (Next Generation Networks).
2 E tapes du projet
2.1 Elements de base du projet
Cette premiere partie est consacree a l'etude bibliographique afin d'acquerir toutes les connaissances techniques necessaires a la bonne realisation de notre projet. II s'agit d'une analyse des besoins du projet afin de mieux apporter des contributions.
D'abord une etude bibliographique de la Telephonie sur IP sera faite. Le contexte et les objectifs de cette nouvelle technologie emergente seront donnes. Elle est largement deployee a travers le monde du fait de ses avantages et souvent en utilisant differents protocoles qui seront abordes. De ces differents protocoles, le protocole SIP est celui dont Putilisation connait la plus forte expansion; une attention specifique sera d'ailleurs accordee a ce protocole afin de mieux le comprendre et dormer les raisons de son choix.
Ensuite, ce sera l'occasion d'aborder les plates-formes architecturales de developpement. Ce sera le moment d'etudier les plates-formes JAIN JCC/JCAT. II y sera expose surtout les raisons pour lesquelles JCC/JCAT est choisie. Aussi l'impact de la gestion des IS sur cette plate-forme et non directement sur JAIN SIP sera evoque.
Enfin, l'etat de l'art des IS sera presente, c'est-a-dire une etude des recents travaux de recherche sur le probleme des IS. II y sera discute les types et origines des IS, evoque un certain nombre de propositions de methodes pour la detection et la resolution des IS, particulierement les methodes relatives aux architectures emergentes telle la telephonie SIP.
2.2 Les contributions du projet
La seconde partie du projet de recherche decrit les contributions qui ont ete brievement mentionnees dans la section 1.3. Les apports sont faits sur la base des travaux de recherches realises dans [14-17]). II s'agit principalement de:
Revision du langage FIML suggere
- Revoir les descriptions des deux algorithmes de detection-resolution (en ligne, hors ligne) d'lS
- Implementer les services et les solutions de detection-resolution d'IS au dessus de la plate-forme JCC/JCAT et non directement sur JAIN SIP.
Conclusion
Le present chapitre a permis d'avoir une bonne presentation du projet de recherche. Le projet a ete subdivise en deux grandes parties a savoir l'etude des elements de base et les contributions apportees. Le projet de recherche a permis d'apporter des contributions a 1'amelioration de solutions au probleme recurrent des IS, particulierement dans la Telephonie sur IP basee sur le protocole SIP.
PARTIE I
CHAPITRE II
LA TELEPHONIE SUR IP
Introduction
Les technologies de 1'information et de la communication connaissent une importante evolution en cette aube du nouveau millenaire. Avec la convergence voix-donnees-multimedia de ces recentes annees, les telecommunications subissent une grande revolution qui se situe a differents niveaux dont notamment le niveau architectural et le niveau des services fournis. La Telephonie sur IP (TsIP) est un des resultats de cette convergence. C'est une technologie qui permet de faire passer la voix, les donnees et le multimedia sur un reseau IP. Les communications sont transmises dorenavant en mode paquet et non plus en mode commutation de circuit comme dans le RTC. Cette technologie utilise de nouveaux protocoles qui permettent de fournir de tres interessants services.
Afin de mieux elucider tous les contours de cette technologie emergente, le contexte et le fonctionnement de la TsIP seront d'abord discutes, ensuite les principaux protocoles utilises seront evoques, et finalement une attention particuliere est accordee au protocole SIP (Session Initiation Protocol), celui qui est choisi pour ce projet de recherche.
1 Contexte et fonctionnement de la TsIP 1.1 Historique de la TsIP
Le RTC est un systeme de transfert de la voix utilisant la commutation de circuit, c'est-a-dire qu'un circuit est dedie durant toute la communication [45,46]. Cette methode de commutation permet d'offrir une qualite de service acceptable. Cependant, ce systeme connait quelques difficultes notamment la large bande passante tres couteuse et surtout inefficacement utilisee. Les systemes bases sur le protocole IP presentent des inconvenients moindres essentiellement au niveau des couts de communication. Ces reseaux reposent sur
L'avenement de la numerisation du signal analogique a ete une revolution au niveau des systemes de telecommunications. En effet, cela a permis la numerisation et le decoupage de la voix en paquets de donnees, ce qui a suscite un grand engouement dans l'industrie des telecommunications qui voyait la, une possibilite de transmettre la voix sur un reseau a commutation de paquets. C'est alors que naquit la Telephonie sur IP. C'est une technologie en pleine emergence qui transforme la telephonie. Elle marque un tournant dans le monde de la communication en permettant la transmission de la voix sur un reseau IP. Cette technologie a publiquement vu le jour en Fevrier 1995 avec la mise sur le marche par Vocaltec de son logiciel de telephone IP [47].
1.2 Definition et objectifs de la TsIP
La TsIP est une technologie de communication permettant de faire passer la voix, le multimedia et les donnees sur un reseau IP en particulier le reseau Internet. Contrairement au RTC, elle utilise la commutation de paquets, ce qui permet une utilisation plus efficace de la bande passante. Elle est plus que de la VsIP (Voix sur IP) comme le grand public a souvent tendance a les confondre. En fait, la VsIP consiste principalement a la transmission grace au protocole IP, des paquets de donnees correspondant a des echantillons de voix numerises [48]. On parte de TsIP quand en plus de transmettre la voix, on peut associer des donnees, du multimedia et surtout des services de telephonie en 1'occurrence, l'utilisation des combines telephoniques, les fonctions des centraux telephoniques (transfert d'appel, messagerie vocale ...) et 1'interconnexion avec les reseaux RTC et de telephonie cellulaire [32]. Elle a principalement pour objectif de [31]:
Remplacer les infrastructures de communication existantes. Reduire les couts de communication.
Simplifier la gestion et la maintenance des infrastructures. Deployer rapidement les services de telephonie.
Realiser la convergence RTC- Reseau de telephonie cellulaire- Internet
1.3 Principe et architecture
Le principe de la TsIP est principalement de transporter les paquets d'informations sur un reseau IP en l'occurrence le reseau Internet. En ce qui concerne la voix, l'empaquetage est
fait suivant un processus de numerisation et de compression bien propre. La figure suivante donne plus de details.
1 - Acquisition
Voix: Signal analogique
2 - Numerisiiiion 3 - Compression
4 - Habillatie ties entiles
Ajoul de: eniclcs 5 I mission el tidiispon |
MEM
Paquets IP 6 - Reception rI
RiseauxI I
I
6 Reception (suite)III •
Mise en ordre 7 Conwision 8 - RestitutionVoix- Signal analogique Figure II-1 Processus de transmission de la voix sur un reseau IP Source [49] La TsIP, dans l'objectif de communiquer avec le RTC et le reseau de telephonie cellulaire, utilise des passerelles (en anglais Gateway), des garde-barrieres (en anglais Gatekeeper) et
classiques et cellulaires. La passerelle, pour effectuer ces taches, utilise des protocoles et des codecs pour la compression - decompression et l'empaquetage. Garde-barriere : Elle est optionnelle et remplit essentiellement les roles de : controle des appels, gestion de la bande passante, enregistrement des adresses, resolution et translation des adresses. Elle est le plus souvent integree avec la passerelle, d'ou son caractere optionnel et dans ce cas, elle est consideree comme la partie intelligente de la passerelle. Le couple passerelle/garde-barriere le plus en vogue de nos jours est Asterisk [49].
Terminaux de TsIP : il s'agit du terminal pour l'utilisateur final. II peut etre un ordinateur implementant un logiciel de TsIP (en anglais softphone) ou un telephone IP qui est un telephone fixe connecte au reseau Internet et non au reseau RTC.
1.4 Enjeux de la TsIP
La TsIP est largement utilisee a travers le monde grace a ses nombreux avantages. Elle offre effectivement plusieurs possibilites tant pour les operateurs que pour les utilisateurs. Les principaux elements qui plaident en sa faveur sont:
le deploiement rapide et facile.
la reduction des couts de communication (pour le consommateur) et d'investissement (pour les entreprises) [48].
la simplification de la gestion du reseau : elle est realisee grace aux interfaces web qui existent pour les reseaux IP et aussi grace a 1'implementation logicielle des commutateurs telephoniques [48].
Pitinerance aisee des utilisateurs : En raison de l'utilisation du reseau IP, particulierement Internet, les utilisateurs finaux peuvent acceder a tous les services partout ou ils sont en mesure de se connecter au reseau.
La TsIP n'a pas que des avantages. Elle presente egalement des insuffisances dont principalement:
La dependance de l'electricite : Au niveau de la telephonie classique, les combines telephoniques n'ont nullement besoin de l'electricite pour etre operationnels; ce qui est un grand avantage en cas de coupure electrique. Ce n'est generalement pas le cas des terminaux de TsIP.
La securite : La TsIP n'est pour 1'instant pas regulee partout dans le monde et aussi il est frequent de rencontrer des attaques de virus et meme des attaques de pirates sur le reseau Internet, ce qui est un grand risque pour les communications [48].
2 Les principaux protocoles
La TsIP utilise plusieurs protocoles afin d'acheminer les informations d'un bout a l'autre. La figure ci-dessous montre a quel niveau se situent ces differents protocoles dans le modele OSI (Open Systems Interconnection).
Figure II- 2 Protocoles de TsIP et modele OSI Source [31 ]
Au dessus du protocole IP qui est au niveau 3 (couche reseau), la TsIP utilise des protocoles de transport et de controle, et des protocoles de signalisation.
la source et a la destination de controler l'etat de la transmission. II presente ainsi l'avantage de gerer un transfert fiable. Quant a UDP, il fonctionne en mode non connecte et ne fait pas de correction d'erreurs (done non fiable) [50].
En ce qui concerne le transport des paquets representant la voix, deux principaux protocoles sont normalises afin de respecter le caractere temps reel de la communication vocale. II s'agit de RTP (Real-time Transport Protocol) et RTCP (Real-time Transport Control Protocol) qui peuvent utiliser TCP ou UDP. Le choix se porte toutefois sur UDP en raison de sa non correction d'erreurs (la correction d'erreur necessite la retransmission des paquets errones ou perdus, ce qui n'est pas conforme avec le caractere temps reel de la communication vocale) et surtout car TCP n'est pas multicast (multi diffusion). A ces deux protocoles, s'ajoute le protocole RTSP (Real Time Streaming Protocol) pour le multimedia temps reel (ce protocole n'est pas un protocole de transport, mais de niveau superieur utilise pour le controle a distance des serveurs multimedia).
Le protocole RTP : II a ete developpe par 1TETF (Internet Engineering Task Force) afin de faciliter le transport temps reel de bout en bout des flots de donnees audio et video sur les reseaux IP [46]. II est encapsule le plus souvent dans un datagramme UDP et a principalement pour objectif d'organiser les paquets a l'entree du reseau et de les controler a la sortie, ceci de maniere a reordonner les flux avec leurs caracteristiques de depart [46]. II permet par ailleurs d'identifier le contenu des donnees et l'identite de la source emettrice. Le protocole RTCP : C'est un protocole de controle des flux RTP. II transmet
periodiquement des paquets de controle aux participant. II permet ainsi aux recepteurs d'envoyer des rapports sur la QdS comprenant le nombre de paquets perdus, le delai aller-retour et l'ecart entre ces delais; ces informations permettent a la source de s' adapter afin d'ameliorer la QdS [46]. En somme, RTP et RTCP est un couple qui va de paire : RTP transporte les paquets representant la voix des utilisateurs et RTCP transporte la supervision de la transmission.
Le protocole RTSP : II a egalement ete propose par 1TETF. C'est un protocole de niveau session (modele OSI) pour visualiser en continu des flux multimedia a partir d'un serveur distant (par exemple, le transfert de la video). II offre un controle sur les flux audio et video recus en simulant les fonctions d'un
magnetoscope comme pause, avance rapide, retour rapide [32]. Le flux multimedia controle par RTSP peut utiliser RTP, mais notons que RTSP est independant du mecanisme de transport (RFC 2326).
2.2 Les protocoles de signalisation
La TsIP, contrairement au RTC, n'a pas un reseau distinct pour la signalisation (le RTC utilise un reseau specifique pour la communication entre utilisateurs et le reseau SS7 pour la signalisation). En effet, il existe des protocoles standardises pour la signalisation dont notamment H.323, MGCP, MeGaCo et SIP. Les trois premiers sont presentes brievement dans les sous-sections 2.2.1 et 2.2.2. Le protocole SIP sera presente plus en detail dans la section 3 de ce chapitre.
2.2.1 Le protocole H.323
Le protocole H.323 a ete defini a l'origine par la commission 16 de l'UIT-T. C'est une extension de la norme H.320 (norme traitant de la visiophonie sur les reseaux numeriques et autres reseaux a commutation de circuit) afin de 1'adapter aux reseaux a commutation de paquets [50]. II specifie quatre principaux elements qui permettent de fournir des services de communication multimedia point a point et point a multi points. II s'agit des terminaux, des passerelles, des garde-barrieres et des unites de controle multi points (en anglais MCU {Multipoint Control Unit)). Ces dernieres fournissent un support pour les conferences et peuvent se communiquer afin d'echanger les informations de conference. Une communication en H.323 s'effectue essentiellement en cinq phases [46]:
etablissement d'appel
echange de capacite et reservation eventuelle de la bande passante etablissement de la communication audio visuelle
invocation eventuelle de services en cours d'appel (par exemple, transfert d'appel, changement de bande passant etc.)
2.2.2 Le protocole MGCP
MGCP fonctionne sur les couches 3 et 4 du modele OSI, particulierement avec IP et UDP, et traite surtout des problemes d'interconnexion avec le RTC [48]. C'est la combinaison de deux anciens protocoles : SGCP {Simple Gateway Control Protocol) de Lucent et IPDC {Internet Protocol Device Control) de Cisco [31]. II definit l'architecture d'un reseau de passerelles en se basant sur les agents d'appels dits MGC {Media Gateway Controller) qui sont des unites de traduction de signalisation (pour permettre l'interoperabilite des composants) et qui se chargent des operations de controle d'appel.
II faut mentionner que l'UIT et 1'IETF se sont mis ensemble pour developper un protocole similaire dit MeGaCo {Media Gateway Control) en reunissant certains points de MGCP et d'autres de H.323. MeGaCo est aussi connu sous le terme H.248. La principale difference entre MGCP et MeGaCo est que le premier nomme ne permet pas la conference multimedia.
3 Le protocole SIP
3.1 Contexte et objectifs de SIP
Le protocole d'etablissement de session SIP fut defini pour la premiere fois par la RFC 2543 etablie par le groupe de travail MMUSIC {Multiparty Multimedia Session Control) de PIETF. II a ete inspire du protocole HTTP et developpe au point culminant de la bulle Internet, ce qui a grandement contribue a accroitre sa notoriete [23]. Standardise par 3 GPP {3rd Generation Partnership Project) pour le reseau IMS, il est de nos jours largement utilise en TsIP et vise a devenir le protocole de reference de cette technologie de communication.
SIP est normalise pour etablir, modifier et terminer une session d'appel. Le concept de
session fut introduit initialement dans la RFC 2327 (decrivant SDP {Session Description
Protocol)) et defini comme un ensemble de flux transportant divers types de media entre la source et la destination (une conversation telephonique et un echange de donnees entre deux usagers sont des sessions). SIP permet la mobilite personnelle, c'est-a-dire que les usagers ont acces aux differents services peu importe le lieu et le terminal utilise. II definit un ensemble de primitives pour [23]:
La localisation des usagers : II s'agit de determiner seulement les parametres techniques permettant de localiser l'usager (adresses IP, etc.).
La disponibilite des usagers : obtenir des informations permettant de savoir si un usager est accessible et s'il a 1'intention ou non d'accepter une communication.
La capacite des terminaux : II s'agit de determiner les types de media et leurs parametres qui peuvent etre utilises par l'usager destinataire.
L'etablissement de la session : atteindre le destinataire et le mettre en relation avec l'emetteur a travers une session.
La gestion de la session : C'est la supervision du transfert du flux en cours de communication, le relachement de la communication, la modification des parametres de session et 1'invocation des services.
Plusieurs protocoles sont utilises en plus de SIP au cours d'une session. Au niveau de la couche quatre du modele OSI, UDP est le plus utilise meme si TCP prend de plus de plus une grande place. SIP ne transporte pas les donnees echangees au cours d'une session comme la voix ou le multimedia, tache realisee par le couple RTP/RTCP.
Par ailleurs, le protocole SDP est utilise pour la description de la session. II est considere comme faisant partie integrante de SIP. II definit une syntaxe normalisee afin de fournir les informations necessaires a la negotiation des flux media, notamment le type de media, l'adresse multicast de la session (en cas de conference), le port de destination, certaines informations de session (nom, breve description) et l'horaire de session. La figure ci-dessous presente un exemple de description SDP. On remarque que la description consiste en un ensemble de lignes «type » = « valeur ». Par exemple, le type « c » donne des informations sur la connexion et le type « s » donne le nom de la session.
_ _ _
o=usherb 2890844526 2890842807 IN IP4 192.168.0.101
s= redaction de memoire
e-usherb(5),faculte.com c=INIP4 192.168.0.101
3.2 Environnement de SIP
L'environnement SIP a une architecture utilisant le modele client-serveur et qui comprend essentiellement les elements suivants :
Les agents utilisateurs : constitues d'une partie client UAC (User Agent Client) et d'une partie serveur UAS (User Agent Server), ils designent les agents que Ton retrouve dans les telephones IP, les softphones et les passerelles. En theorie, on peut etablir une communication directement entre deux agents utilisateurs mais cela necessite de connaitre l'adresse IP du destinataire. Le UAC initie et envoie des requetes SIP pour demander l'etablissement de la session, tandis que le UAS recoit et repond aux requetes SIP, accepte, redirige ou refuse des appels.
Le serveur mandate (en anglais, proxy server): c'est un dispositif qui recoit d'un cote les requetes et les retransmet d'un autre cote. Rigoureusement, il devrait etre presque entierement transparent vis-a-vis des messages des agents utilisateurs, se contentant de les relayer et d'y apporter des changements mineurs [23].
Le serveur d'enregistrement: ce serveur (registrar server en anglais), sert a memoriser la localisation courante des agents utilisateurs. Etant donne que l'adresse IP d'un agent utilisateur peut changer dans de nombreuses circonstances, le registrar server, afin d'atteindre le terminal de l'utilisateur a partir de son adresse SIP, memorise l'association entre une adresse IP eventuellement dynamique et l'adresse SIP, qui est elle statique. Les adresses SIP sont dites URI (Uniform Resource Identifier) et ont principalement deux formes, l'une similaire a une adresse de courrier electronique et 1'autre contenant un numero telephonique [45].
Le serveur de redirection : Ce serveur (en anglais Redirect server) recoit des requetes SIP d'un agent utilisateur, repond ou rejette selon les cas. Lorsque le
destinataire d'une requete a change de localisation, le serveur de redirection
repond a l'emetteur en lui dormant l'adresse de la nouvelle localisation du destinataire. Un redirect server peut etre utilise en conjonction avec un registrar server pour rediriger les appels vers la localisation courante de l'utilisateur appele. II permet dans ce cas de faciliter le deploiement des grands reseaux de telephonie residentielle.
Ces trois types de serveurs peuvent etre mis ensemble dans une meme entite physique.
3.3 Presentation de l'appel de base de SIP
Le protocole SIP emploie des messages afin d'etablir la communication. Un message SIP peut etre une requete ou une reponse et contient des entetes. La requete SIP est aussi dite methode c'est-a-dire une primitive permettant d'envoyer une demande au serveur.
Les champs d'entete sont des parties du message specifiant des informations telles que la source, le destinataire, le chemin pris par le message, le type et la taille du corps du message etc.
Les requetes SIP : elles sont envoyees par le UAC vers un serveur SIP (ou vers un UAS). Une requete SIP est caracterisee particulierement par sa premiere ligne indiquant la methode de la requete. Le protocole SIP definit un grand eventail de methodes dont notamment (RFC 3261):
- ACK: Pour confirmer la reception d'une reponse finale d'un serveur. - BYE : Pour relacher un appel.
- CANCEL : Pour annuler une requete precedente tant que le serveur n'a pas envoye de reponse finale.
- INVITE: Pour initier un nouvel appel
- MESSAGE : Pour l'envoi de messages instantanes
- SUSCRIBE : Pour demander une notification d'evenements
- REGISTER : Permet aux clients d'enregistrer leur localisation sous forme d'une ou plusieurs adresses aupres du registrar server.
Les reponses SIP : Un serveur SIP repond a une requete SIP au moyen de une ou plusieurs reponses. La majorite des reponses, dont les codes sont de la forme 2xx, 3xx, 4xx, 5xx et 6xx, sont des reponses «finales » et terminent la transaction courante. Une transaction etant une requete demandant une action specifique et l'ensemble des reponses qu'elle suscite jusqu'a la reception de la
Afin de mieux elucider la communication en SIP a travers les requetes et reponses, la figure II-4 ci-dessous donne un bon apercu de l'echange entre deux utilisateurs A et B, echange impliquant un redirect server et un proxy server. On suppose dans cet exemple, que A et B se sont deja enregistres au niveau d'un registrar server en utilisant la requete REGISTER.
TJA de A
UAC
UAS
i_S INVITE B@university.ma
302 MOVED TEMPORARILY Contact: B@university.ca
ACK B@university.ma
Redirect Server
G 3 INVITE B@university.ca j TJA de B
100 TRYING 180 RINGING
in
200 OK ACK Proxy Server INVITE B@gel.university.ca 100 TRYING 180 RINGING 200 OK ACK Call/Media Session BYE 200 OK Proxy Server R V Hft.
?nn OK UAS UACFigure II- 4 Exemple d'appel en SIP Source [51]
Dans l'echange ci-dessus, A est l'initiateur de l'appel et B est le destinataire. Afin de mieux expliquer cet echange, les notations suivantes sont considerees : UACA et UASA, les UAC et UAS de l'utilisateur A etUACH et UASB ceux de Putilisateur B.
A l'etape 1, l'utilisateur A initie un appel vers B a travers son numero de telephone ou son SIP URI: UACA envoie la requete INVITE avec l'adresse de B au redirect serveur, lequel apres verification, trouve que B a change d'adresse temporairement. Le redirect serveur renvoie k UACA , une reponse 302 MOVED TEMPORARILY avec la nouvelle adresse de B (etape 2). Le UACA confirme au redirect serveur en etape 3 par la methode ACK. Une fois la nouvelle adresse de B recue, le UACA envoie une nouvelle requete INVITE a B qui
passe par un proxy server (etape 4). Le proxy server envoie une reponse 100 TRYING a UACA (etape 5) et transmet la requete INVITE a UASB (etape 6). Le UASB recoit INVITE et repond auproxy server par 100 TRYING et 180 RINGING (etapes 7 et 8), lequel transmet la reponse 180 RINGING a UACA. A ce stade, le telephone de B sonne et l'utilisateur A est en attente d'une reponse. Lorsque l'utilisateur B repond a l'appel, le UASB envoie une reponse 200 OK (etape 10) passant par le proxy server qui le transfere directement a
UACA (etape 11). Ce dernier confirme la reception du 200 OK en envoyant la requete ACK qui passe de nouveau par le proxy server avant d'arriver a UASB (etapes 12 et 13). Apres l'etape 13, la session est dite ouverte et les utilisateurs A et B peuvent avoir une communication a travers les protocoles RTP/RTCP (etape 14). Lorsque B a termine et raccroche, le UACB envoie la requete BYE a UASA qui passe par le proxy server (etapes 15 et 16). Le UASA repond au BYE en envoyant 200 OK a UACB qui passe une fois de plus par le proxy server (etapes 17 et 18) et l'appel prend fin. II est a noter qu'il s'agit du meme proxy server qui est utilise bien que la figure peut laisser penser autrement.
3.4 Raisons du choix de SIP
Plusieurs protocoles sont utilises en TsIP mais SIP est grandement utilise de nos jours et tend a devenir le protocole de reference en TsIP pour plusieurs raisons.
SIP est tres proche de HTTP : Cette similitude permet a SIP d'etre plus proche du reseau Internet que ses principaux concurrents grace notamment aux applications Web qui sont largement basees sur le protocole HTTP. Par ailleurs, Putilisation des SIP URI permet a un terminal SIP de rediriger un appel vers une page Web ou une URL de type email. Ceci facilite l'integration d'applications audio et video avec les autres applications informatiques.
SIP est simple : La simplicite de l'appel de base SIP est frappante en comparaison a d'autres protocoles comme H.323. Aussi, SIP est simple a
SIP est independant du protocole de transport: il peut utiliser TCP tout comme UDP et a par ailleurs l'avantage de mieux traverser les NAT (Network Address Translation) que des protocoles comme H.323.
SIP supporte la presence (c'est-a-dire le statut de l'usager, par exemple est il absent, occupe, non connecte,...) et la messagerie instantanee a travers l'extension SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions).
SIP permet le controle des boucles : Ce controle est surtout fait a travers les proxy servers. Ces derniers a travers l'entete Via, verifient s'ils sont deja dans la liste des equipements traverses. En effet, lorsqu'un/?raxy server achemine une requete, il ajoute son nom sur la liste des proxys contenue dans les entetes Via; lorsqu'il achemine une reponse, il inverse le processus et retire son nom de la liste.
Flexibility pour la creation et la personnalisation des services avec SIP
SIP est populaire car il a ete normalise par le 3GPP pour le reseau IMS (IP Multimedia Subsystem) et est aussi utilise par plusieurs open source comme Asterisk.
Le protocole SIP n'a pas que des avantages, certaines faiblesses plaident en sa defaveur, en l'occurrence.
La transmission de tonalites DMTF est plus aisee en H.323 qu'en SIP.
L'absence de reelle securite dans SIP : Cette absence est devenue vraiment une evidence et des solutions sont proposees telle que celle suggeree par le groupe de travail SIPPING de 1TETF traitant de «Remote Configuration of SIP Phones ».
Conclusion
La TsIP est une technologie de communication utilisant la commutation de paquets dans les reseaux IP. Elle permet la convergence des reseaux RTC, de telephonie cellulaire et Internet. Elle est de plus en plus deployee a travers le monde et a un avenir tres prometteur en raison de ses nombreux avantages tels que la reduction des couts de communication et l'offre de services tres attrayants. Cette technologie peut utiliser divers protocoles dont notamment H.323, MGCP et SIP, protocole choisi pour ce projet de recherche a cause de ses privileges compares a ces principaux concurrents.
La TsIP connait toutefois quelques points a ameliorer arm de fournir une QdS assez proche de celle fournie par le Reseau Intelligent au niveau de la telephonie classique.
CHAPITRE III
PLATES-FORMES ARCHITECTURALES DE
DEVELOPPEMENT
Introduction
L'avenement du Reseau Intelligent (RI) a permis au RTC de fournir un plus grand nombre de services a l'utilisateur final et surtout de faciliter la creation, la gestion et le deploiement de ces services. Ces services sont cependant stockes et controles par les fournisseurs et operateurs avec leurs interfaces proprietaries, ce qui ne permet pas ou reduit considerablement leur personnalisation par les utilisateurs finaux. Ces derniers, depuis quelques annees, encourages par la revolution des technologies de communication, sont tres demandeurs en nouveaux et attrayants services. Pour les satisfaire, il serait interessant d'implementer ces services au niveau des terminaux (hormis quelques services specifiques), ce qui leur permettrait de controler, modifier et personnaliser ces services. C'est dans ce sens que des plates-formes architecturales de developpement sont creees et normalisees par le secteur des telecommunications. Le present chapitre donne un apercu de quelques unes de ces formes. On evoquera en premier lieu les principales plates-formes architecturales, puis les API JAIN SIP et JCC/JCAT.
1 Les principales plates-formes architecturales
La separation entre la couche service et les commutateurs a ete initiee par le RI a travers Pexternalisation des services en dehors des commutateurs et leur commande par des points de gestion de services [34,42]. Les reseaux emergents ont conforte cette vision et exploite les recentes avancees dans les domaines des telecommunications et du Genie Logiciel. C'est ainsi que des environnements dits « Environnements de creation et d'execution des services » sont mis au point afin de rendre partiellement transparentes aux concepteurs de services, les couches sous jacentes et les contraintes propres aux architectures reseau. Ces environnements sont dependants de la plate-forme architecturale utilisee. II existe plusieurs plates-formes architecturales pour le developpement des services dont notamment Parlay, OSA {Open Services Access), et JAIN qui seront respectivement presentees dans les sous-sections 1.1, 1.2 et 1.3.
1.1 Parlay
Le groupe Parlay est un consortium cree en 1998 par un ensemble d'entreprises oeuvrant dans le domaine des technologies de Pinformation. II a pour objectif de creer un ensemble d'API permettant aux tiers fournisseurs (fournisseurs non proprietaires) d'acceder et d'utiliser les services et composants de Poperateur reseau (le proprietaire du reseau) [54-55]. Ces API sont simples, independantes des reseaux, et surtout extensibles, permettant ainsi une bonne interoperabilite entre les reseaux et leur utilisation par plusieurs applications.
Les API Parlay ont une specification orientee objets et definie en UML {Unified Modeling Language), ce qui permet leur deploiement a travers des technologies telles que CORBA, DCOM {Distributed Component Object Model) et Java/RMI {Remote Method Invocation). Ces API Parlay sont structurees en deux interfaces [55-56]:
Framework interface: Elle permet Pacces securise aux differents services du reseau. Elle doit etre vue comme la partie garantissant ou non Pacces aux ressources et services du reseau.
Service interface : Cette interface fournit les fonctionnalites reseaux aux differentes applications clientes. Une fois Papplication du client (par exemple le tiers fournisseur) authentifiee par le framework interface, elle peut utiliser un service particulier de Parlay a travers le Service interface. Le Service interface definit principalement les services de capacite reseau suivants: controle d'appel, messagerie, interaction avec les usagers et localisation des usagers. Chaque service dispose d'un gestionnaire responsable du controle, de la creation des objets et de la notification des evenements.
Le groupe Parlay a recemment ajoute une nouvelle API, dite Web Services API, denommee
Parlay-X, dont les specifications ont ete definies conjointement avec l'ETSI {European
1.2 OSA
OS A avait initialement pour definition Open Services Architecture, mais cette definition a ete revue pour s'etablir a Open Services Access. OSA est basee sur le concept de Parlay et est developpee par 3 GPP {3rd Generation Partnership Project) pour mieux satisfaire les exigences des reseaux cellulaires de troisieme generation [55]. Ces deux API (Parlay et OSA) s'apparentent a plusieurs niveaux et le groupe Parlay et 3 GPP travaillent dorenavant de concert, de sorte a aligner les deux standards sous une seule API sous le terme OSA/Parlay ou Parlay/OSA.
L'architecture OSA comporte toutefois des fonctionnalites specifiques relatives aux reseaux cellulaires. OSA a beaucoup evolue et gagne grandement de l'importance grace aux opportunites susceptibles dans le domaine des services avec les PDA {Personal Digital Agenda). Elle a ete proposee afin de faciliter le developpement et le test des services a
l'exterieur du reseau de telecommunications. Par ailleurs, les API OSA offrent la securite et l'integrite dont les operateurs ont besoin avant d'ouvrir leur reseau de telecommunications aux tiers fournisseurs et aux developpeurs independants de services, ce qui a permis l'augmentation du nombre de ces fournisseurs et developpeurs ces dernieres annees. L'architecture OSA est constitute de trois principales parties [55]:
Application Server (AS) : C'est l'entite qui loge les differentes applications. Framework: Cette entite est responsable de la gestion de la securite et est unique dans une architecture OSA, contrairement aux AS qui peuvent etre en grand nombre. Elle fournit aux applications des mecanismes de base tels que rauthentification avant Faeces aux ressources et fonctionnalites du reseau. Service Capability Server (SCS) : Ce serveur fournit aux applications toutes les fonctionnalites requises pour la construction des services a travers les SCF {Service Capability Features). II peut y avoir plusieurs SCF dans une passerelle
OSA (une passerelle OSA est l'ensemble forme par le Framework et le SCS).
Les SCF constituent l'interface entre les services et le reseau et assurent la gestion des utilisateurs et les sessions d'acces aux services. L'architecture OSA definit plusieurs SCF dont notamment 1'interaction avec l'utilisateur, la localisation de l'utilisateur, le controle des sessions avec l'utilisateur, le
traitement des caracteristiques du terminal utilisateur et la gestion des comptes clients et de la QdS.
1.3 JAIN
JAIN {Java API for Integrated Networks) est un ensemble d'API base sur le langage Java, concu pour faciliter la creation des services et produits des reseaux de telecommunications emergents. Le terme Integrated Networks fait reference a la possibility pour JAIN d'integrer les protocoles IP et du RI. JAIN est une communaute creee par plusieurs entreprises et industriels oeuvrant dans le domaine des technologies de l'information et de la communication, avec l'initiative de Sun Microsystems. Le propos de JAIN est d'apporter la convergence des services (JAIN integre les reseaux de telephonie classique, de telephonie cellulaire et les reseaux IP), la portabilite et de fournir un acces securise aux reseaux de telephonie et de donnees.
JAIN comprend deux groupes de travail [52-53]:
Le PEG {Protocols Expert Group) : ce groupe est responsable de la specification des interfaces pour les protocoles des trois types de reseaux.
L'AEG {Application Expert Group) : ce groupe est charge des API Java pour la creation de services sur les protocoles couverts par le travail du PEG.
Services API Untrusted third- party applications JSCE (JAIN Service Creation Environment) Trusted third - party applications Services Call Control/Session KPT
JSLEE (JAIN Service Logic Execution Environment)
JCC/JCAT
( E S ^ (MGCA
Network
Figure III- 1 Architecture de JAIN Source [26]
L'architecture de JAIN, comme le montre la figure III-l est divisee en trois principales couches d'abstraction : la couche reseau, la couche signalisation et la couche service.
La couche reseau : elle definit le protocole de communication choisi. II y a par exemple des protocoles pour le RTC (INAP (Intelligent Network Application Part), TCAP (Transaction Capabilities Application Part)), pour les reseaux cellulaires (MAP (Mobile Application Part)) et pour les reseaux IP (SIP, MGCP).
La couche signalisation : elle represente les logiciels charges de la gestion des communications. II y a par exemple les proxy servers et les passerelles pour les
reseaux IP. Elle communique avec la couche reseau a travers une interface dite interface JAIN definissant ce que doivent fourair les piles de signalisation. Cette interface a pour objet d'apporter une independance des vendeurs ou equipementiers (par exemple, differentes piles SIP provenant de differents vendeurs seront compatibles apres implementation de l'interface JAIN). On a ainsi des API comme JAIN TCAP, JAIN MAP, JAIN MGCP et JAIN SIP. Cette derniere sera l'objet de la section 2.
La couche service : elle represente les services de base. II s'agit notamment des serveurs d'application dans le cas des reseaux a commutation de paquets. L'interfacage entre cette couche et la couche de signalisation est faite par l'API JCC/JCAT (Java Call Control/Java Coordination And Transaction) pour cacher la diversite des protocoles aux developpeurs de services. Cette interface traduit ainsi Findependance des protocoles de communication utilises. Plus de details sur JCC/JCAT seront presentes dans la section 3.
Les operateurs et tiers fournisseurs, developpant leurs services et applications dans Fenvironnement JSCE (JAIN Service Creation Environment), accedent a la couche service a travers des API services. Ces API services peuvent etre divisees en deux grandes parties.
La premiere partie, juste au dessus de JCC/JCAT, est l'API JSLEE (JAIN Service Logic Execution Environment). C'est un environnement d'execution qui offre un niveau d'abstraction plus important que JCC/JCAT. Cette API permet de developper des services plus rapidement en combinant des services deja existants et offre une independance du reseau (tout service developpe pour cet environnement fonctionnera dans un autre reseau implementant aussi JSLEE). Elle specifie des modeles pour le cycle de vie des services et leurs composants, et aussi des mecanismes pour le deploiement des services, la gestion des interfaces et la transmission asynchrone entre applications.
applications non sures. JSPA est aussi utilisee pour les specifications Parlay implementees en Java.
2 L'API JAIN SIP
JAIN SIP est une API de bas niveau developpee en Java et se situant juste au dessus de la pile SIP. Elle a ete definie afin de permettre une interoperabilite entre les differentes piles SIP des differents vendeurs ou equipementiers, et supporte les differentes fonctionnalites decrites dans la RFC 3261 et ses extensions [24,29]. Elle permet aux developpeurs de services et applications d'avoir un acces complet a la pile du protocole SIP et peut etre utilisee dans un terminal utilisateur, un proxy server ou un registrar server. Ce projet s'interesse a cette API car le developpement se fera au dessus de JCC/JCAT qui est au dessus de JAIN SIP.
L'API JAIN SIP a une architecture contenant plusieurs interfaces pouvant etre regroupees en quatre principaux paquetages (en &ng\ai$,, package) [29, 30,53] :
Le package javax.sip.header : il regroupe un ensemble d'interfaces pour les entetes SIP dont notamment les interfaces ContactHeader, FromHeader, ToHeader.
Le package javax.sip.address : il contient les interfaces pour representer les SIP URL
Le package javax.sip.message : il contient les interfaces pour representer les messages SIP. II est a noter que les adresses, les entetes et les messages SIP ont ete abordes dans le chapitre precedent.
Le package javax.sip: il contient les principales interfaces modelisant l'architecture de JAIN SIP vues du cote du developpeur des applications et du cote du vendeur de la pile SIP. Les interfaces SipStack, SipProvider et SipListener sont essentiellement mentionnees.
L 'interface SipProvider est l'entite de transmission des messages et doit etre implementee par le vendeur de la pile SIP. On peut avoir plusieurs SipProviders dans une meme architecture JAIN SIP.
L'interface SipStackpeut etre vue comme celle gerant 1'architecture de JAIN SIP. Elle doit etre aussi implementee par le vendeur de la pile SIP. Cette interface est le point central permettant la creation des SIP Providers. Elle encapsule la gestion dynamique des caracteristiques de la pile SIP comme les Listening Points implemented par l'interface ListeningPoint. Un Listening Point est une representation Java d'un port que le SipProvider utilise pour l'envoi et la reception des messages SIP. Lorsque le SipProvider recoit des messages a partir du SipStack a travers les Listening Points, il cree des evenements SIP (SIP Events) qu'il delivre a l'interface SipListener.
L'interface SipListener est toujours implementee par Papplication du developpeur. Son principal objectif est la gestion des messages. Elle implemente ainsi des methodes comme processRequest pour la gestion des requetes SIP et processResponse pour la gestion des
reponses SIP.
3 L'API JCC/JCAT
JCC/JCAT est une API fournissant aux developpeurs des applications, une abstraction commode, orientee objet, bien puissante pour la manipulation des appels (un appel devant etre vu comme une communication de donnees ou de multimedia entre plusieurs parties). L'objectif primaire de cette API est de cacher la multiplicite des protocoles de signalisation utilises comme le montre la figure III. 1. JCC est une interface pour la creation, le controle, la maintenance et la manipulation des sessions de communication dans les reseaux emergents, et JCAT fournit les elements necessaires permettant aux applications d'etre invoquees facilement et de retourner des resultats pendant ou durant les appels. L'utilisation de JCC/JCAT permet de reduire grandement le temps de developpement et de test des applications [25,28]. Le reste de cette section aborde uniquement JCC (Java Call Control) car c'est la partie de l'API utilisee dans ce projet. Effectivement, JCAT est beaucoup plus orientee pour des applications utilisant AIN/IN (Advanced Intelligent Network/ Intelligent Network), ce qui n'est pas le cas de ce projet.
3.1 Structure de JCC
JCC definit quatre objets qui modelisent les principaux elements pour la manipulation et le traitement des services. II s'agit de : Provider, Address, Call et Connection [25]. Les deux premiers nommes sont logiquement statiques et les deux derniers sont logiquement crees dynamiquement pour chaque appel.
Provider: represente la « fenetre » a travers laquelle une application voit le traitement d'un appel. Le Provider peut passer par trois etats possibles. II est dans l'etat IN SERVICE, lorsqu'il est en service et disponible pour utilisation, dans l'etat OUT OF SERVICE lorsqu'il est indisponible temporairement pour utilisation, et dans l'etat SHUTDOWN lorsqu'il est indisponible de facon durable.
Address : represente une adresse logique d'une des parties participant a un appel (par exemple, une adresse IP, un numero de telephone).
Call: represente un appel et est une connexion dynamique des entites logiques et physiques mettant ensemble des adresses. Cet objet peut etre dans l'etat IDLE, ACTIVE ou INVALID.
La figure ci-dessous donne une bonne illustration de la relation entre ces differents objets lors d'un appel a deux parties.
Chaque appel (Call) prend en compte une Connection origine y et une Co«nec?/o«djstination/
f Connection J
La Connection utilise une Address
( Address j
( Provider J
A Call
Le Provider cree un appel (Call)
( Connection j
s^
( Address j
Figure III- 3 Relation entre les principaux elements de JCC
3.2 Enjeux du developpement avec JCC
Comme mentionne plus haut, JCC est une interface permettant d'avoir une independance du protocole de signalisation utilise. Par ailleurs, elle permet la rapide creation des services par les tiers fournisseurs pour les reseaux emergents.
En ce qui concerne ce projet de recherche, les services seront developpes au dessus de JCC et non directement au dessus de l'API JAIN SIP, ce qui permettra d'eliminer la dependance a SIP. Pour ce faire, un mapping de certaines methodes propres a l'interface JAIN SIP doit etre fait. C'est le cas par exemple de routeCall ou routeConnection qui remplacera le traitement de la requete INVITE, de release en lieu et place de BYE ou CANCEL, de
answer en lieu et place de 200 OK. On donnera plus de detail a travers des exemples de
