Raport Pfe Benali Darbaoui

Dveloppement du Service VoD sous La Plateforme Mobicents NSN
AVANT-PROPOS
Noms et prnoms des lves Ingnieurs stagiaires :
Omar Benali : omar.benali86@gmail.com Imad Darbaoui : darbaoui@gmail.com

Intitul de travail :
Dveloppement du service vido la demande (VoD) sous la plateforme mobicents
Etablissement daccueil : NOKIA SIEMENS NETWORK. Lieu : Rue Abou Inane, Rabat. Tlphone : 0537219040 Fax : 0537261531
Superviseurs du projet :
M. Fouad Lahjomri lENSA de Tanger M. Naoufal Raissouni lENSA de Ttouan
Rsum
L'industrie des tlcommunications est en plein expansion. Introduire ou intgrer un service dans le march s'avre de plus en plus difficile vue les contraintes d'infrastructure et les normes propritaire qu'il faut respecter d'autant plus que les cots de production deviennent de plus en plus considrables. C'est dans cette vision que l'IMS s'est introduit dans le march. En effet, avec son architecture rpartie l'IMS permet de mettre en place de nouveaux services surtout avec les nouveaux besoins des usagers qui demandent des d'applications et de services sophistiqus (push-to-talk, messagerie instantane, confrence audio et vido, jeux en ligne,etc). Ainsi les serveurs d'application proposent un environnement adquat pour le dploiement de ces services tout en utilisant des solutions open source indpendamment de l'infrastructure qui est mise en place. Dans ce contexte, notre travail consiste concevoir et dvelopper un service vido la demande (VoD) en se basant sur la plate-forme de communication mobicents .
Mots cls: NGN, IMS, Mobicents , JAIN SLEE, SIP, VoIP, VoD, RTP,RTSP, MGCP.
Abstarct
The telecommunications industry is rapidly expanding. Introducing or integrating new services in the market is becoming more difficult given the constraints of infrastructure and proprietary standards that must be respected ,especially that the production costs have been risen. Only in this perspective that the IMS was introduced considerably into the market. In fact, with its distributed architecture, it allows to implement new services, particularly with the new user needs with a set of sophisticated applications and services (push to talk, instant messaging, audio conferencing and video, online games, ...).Thus the application server offers a suitable environment for the deployment of such services while using open source solutions, and regardless of the infrastructure which is used. In this context, our work is to design and develop a video on demand service based on the mobicents communication platform.
Key words: NGN, IMS, Mobicents , JAIN SLEE, SIP, VoIP, VoD, RTP,RTSP, MGCP.
Table des matires

Introduction gnrale.11 Chapitre 1 : Contexte gnral du projet12 1. Lentreprise d'accueil : Nokia Siemens Network..12 1.11.21.32. Prsentation de lorganisme daccueil.....12 La stratgie de Nokia Siemens Networks....13 Secteur dactivit de NSN...14
Prsentation du projet et droulement du stage....15 2.12.22.3contexte du projet15 Lobjectif du projet et le droulement du stage...16 Lintrt du projet....17
Chapitre 2 : Les rseaux NGN..18 1. Introduction..18 2. Larchitecture en couche NGN ....18 3. Les entits fonctionnelles au cur du rseau....20 3.13.23.34. 5. La Media Gateway (MG)........20 La Signalling Gateway (SG)...........20 Le serveur dappel...21
Les Familles protocolaires21 NGN Multimedia: IMS....22 5.15.2Introduction.22 Architecture de lIMS.23 5.2-1. 5.2-2. Structuration en couche de larchitecture IMS... 23 Protocoles dfinis dans larchitecture IMS..24
Chapitre 3 : Le Protocole SIP25 1. 2. Introduction...25 SIP Composants26 2.12.23. Agent utilisateur......26 SIP Serveurs27
Messages SIP28 3.13.23.3Principales mthodes SIP....28 Extension des mthodes SIP...29 Rponses SIP...30
4.
Protocole RTSP.....31 4.14.24.34.44.5RTSP et les protocoles de transport.....32 RTP et RTCP...32 RTSP et HTTP.....32 Fonctionnalits de RTSP.....33 Paramtres de RTSP....33
Chapitre 4 : La Plateforme Mobicents..35 1. 2. Introduction.....35 La Technologie JAIN...36 2.1- Avantages et intrts de JAIN..37 2.2- Les couches dabstractions...38 2.3- Les diffrentes APIs de JAIN....39 2.4- JAIN SIP API.....41 3. JAIN SLEE....42 3.1- Introduction.....42 3.2- La spcification de JAIN SLEE..42 3.3- Les composantes de bases du JAIN SLEE..44 3.3.1- Ladaptateur de ressource.....44 3.3.2- Le routeur dvnements..45 3.3.3- Lvnement..46 3.3.4- Les services et Les profils.46 3.3.5- Lactivit et le contexte dactivit.47 3.3.6- Composants SBB (Service Building Block) ...47 3.3.7- Composants de gestion et de contrle des services.48 4. Mobicents Media server....49 4.1- Mobicents Media Server..50 4.2- Buts de Mobicents Media Server.....50 4.3- Architecture de Serveur Medias...51 4.4-Les Type de Media Supporter par Mobicnets MediaServer.51 Chapitre 5 : Conception et dveloppement du service..53 1. Travaux lis...53 1.11.22. IPTV/VoD Standardisation....53 IPTV/VoD bas sur l'IMS...54
Architecture et considrations d'implmentation....55
2.12.22.32.43.
le client....56 Le serveur Mobicents......56 le serveur de streaming Darwin......56 Mobicents media server (MMS).....57
Ralisation et prsentation...57 3.13.2Conception du service.....57 Atelier de travail.....61 3.2-1. le Langage JAVA..61 3.2-2. SVN..62 3.2-3. Apache Maven..62 3.2-4. Apache ANT.....62 3.2-5. Lenvironnement de dveloppement Eclipse62 3.3Scnario..63
Conclusion et perspectives....67 Bibliographie.....68 Annexe A......69 Annexe B... ..72
Liste des figures et des tableaux

Figure 1: Figure 2: Figure 3: Figure 4: Figure 5: Figure 6: Figure 7 : Figure 8: Figure 9: Figure 10: Figure 11: Figure 12: Figure 13: Figure 14: Figure 15: Figure 16: Figure 17: Figure 18: Figure 19: Figure 20 : Figure 21 : Figure 22 : Figure 23: Figure 24 : Figure 25 : Figure 26 : Figure 27 : Figure 28 : Figure 29 : Figure 30 : Figure 31 : Figure 32 : Figure 33 : Tableau 1: Tableau 2: Tableau 3: Diagramme de GANTT du projet.17 Architecture de rseau NGN.20 Architecture de lIMS23 Entits dun rseau SIP..26 Exemple de message SIP...28 Etablissement et libration de session SIP....31 Exemple dune session RTSP34 Architecture de Mobicents35 Architecture de la plateforme de communication Redhat/JBoss.36 Architecture de Base de JAIN..37 Architecture en couche de JAIN..39 Diffrents APIs de JAIN..40 Architecture JAIN SIP.41 Les diffrentes JAIN SIP API..42 Architecture de Jain SLEE...44 Rle de ladaptateur de ressource.45 profile et table de profile...46 Activit et contexte dactivit...47 Flux dvnements dans un SBB..48 Architecture de Mobicents Media Server..51 Architecture IPTV/VOD propose par l'ETSI TISPAN...55 Architecture du service VoD....56 Cas dutilisation de Mobicents Media Server...57 Call flow pour le service VoD...61 Dmarrage de Mobicents media server63 Dmarrage du serveur Mobicents JSLEE64 Dploiement du service.64 Client Sip X-lite.65 Lecteur du flux mdia65 Interface dadministration Mobicents....71 Configuration de X-lite pour Default74 Configuration x-lite pour Network75 dploiement de MGCP Dmo76 Les six mthodes du noyau SIP.....29 Rponses SIP.30 Comparaison entre le systme de communication et le systme dentreprise...43
Introduction gnrale
Le monde de tlcommunications est en croissance rapide et le march de tlcommunications soriente de plus en plus vers la convergence fixes et mobiles, vers un rseau tout IP. Le concept cl pour assurer cette convergence est le concept IMS (IP Multimdia Subsystem) qui permet loffre des services pour les deux rseaux fixes et mobiles. Lenvironnement de service des oprateurs de tlcommunications est aujourdhui particulirement complexe avec lintgration de services trs divers provenant du monde Internet. Cette complexit provient du mariage entre les tlcommunications et linformatique. Le rseau intelligent autour du rseau tlphonique a longtemps t le vecteur de cette intgration et a permis un certain succs ce mariage avec larrive de services comme la carte prpaye ou le numro vert. Cependant, modifier un service ou crer un nouveau service accessible par le rseau tlphonique ncessite la modification de tous les nuds du rseau qui sont des commutateurs trs complexes. De plus, les fournisseurs de services ont toujours tendance dvelopper des services propritaires suivant leurs propres normes. Ces contraintes rendent les modifications et la cration de nouveaux services difficiles et trs longues dans le contexte dun march trs concurrentiel. Dailleurs, ces services sont trs coteux du fait de la complexit et du nombre de commutateurs modifier dans le rseau. Dans ce contexte, NSN a t dcid d'utiliser la plate-forme Mobicents qui est un framework open source VoIP. Cette plateforme doit offrir une multitude d'interfaces (e.g. SIP) afin de faciliter l'ajout des nouveaux services qui est le but de ce stage. Ainsi le travail prsent dans ce mmoire de fin d'tude porte sur la documentation et la comprhension de la l'architecture et la logique mtier de Mobicents ainsi que la conception et le
dveloppement d'un service video la demande (VoD). Le premier chapitre consiste prsenter le contexte gnral dans lequel s'est droul le projet. Le deuxime chapitre dcrit les rseaux de la nouvelle gnration et leurs volutions vers le concept IMS. Le troisime chapitre prsente le protocole SIP que nous adopterons pour notre projet et qui a t retenu par le 3GPP pour l'architecture IMS comme protocole pour le contrle de session et le contrle de service. Le quatrime chapitre traitera du contexte technique : les concepts de Mobicents et l'architecture JAINSLEE. Le cinquime chapitre sera rserv la phase du dveloppement des services et leurs implmentations. Nous terminerons notre travail par une conclusion et perspective.
Chapitre 1 Contexte gnral du projet

Dans ce chapitre, nous allons prsenter l'entreprise d'accueil, Nokia Siemens Network. Ensuite nous exposerons le sujet, l'objectif et le droulement du stage.
1. Lentreprise d'accueil : Nokia Siemens Network

1.1- Prsentation de lorganisme daccueil.
NSN est issue d'une fusion stratgique opre en juin 2006 entre Siemens Networks et Nokia Networks Business Group. La nouvelle structure (une joint-venture dtenue 50-50 par les deux groupes) a donn naissance un gant mondial des rseaux de tlcommunications qui a pour ambition de connecter pas moins de 5 milliards de personnes l'horizon 2015. Autant dire connecter la population de la plante. Cette nouvelle socit, Nokia Siemens Networks est le leader en fourniture de solutions de communication et d'intgration de services pour la tlphonie mobile et fixe. Elle fournit un portefeuille complet et quilibr de produits pour les solutions d'infrastructures fixes et mobiles. Elle s'adresse la demande croissante des services avec 20000 professionnels des services travers le monde. Les revenus pro-forma combins de 17.1 milliards , durant l'exercice 2006, font de Nokia Siemens Networks l'une des plus grandes socits d'infrastructure de tlcommunications. Nokia Siemens Networks compte 600 clients, elle opre dans 150 pays. Son sige social est situ Espoo, en Finlande. Elle combine Networks Business Group de Nokia et l'expertise de Siemens Communications. Fondant son business sur une forte contribution des deux partenaires mondiaux, Nokia Siemens Networks profite du know-how que les deux groupes ont dvelopps sparment dans le Maroc depuis 1988 pour ce qui concerne les transmissions et partir de 1994 pour des rseaux mobiles et fixes. L'antenne marocaine, qui est dirige par Youssef Chrabi, directeur pour le Maroc de Nokia Siemens Networks (douze annes d'exprience chez Nokia Networks), est base la fois Rabat et Casablanca, pour une plus grande proximit vis-vis des principaux clients sur le march local, et ce, en plus de bureaux rgionaux ouverts Agadir, Marrakech et Tanger. Ce stage a eu lieu au sein du sous-traitant IDC group de NSN Agdal/Rabat. Le stage t dans le dpartement CSI de NSN qui fait l'intgration de services. En effet, l'ingnierie
des services devient un domaine stratgique de par l'avnement des rseaux large bande intgration de services et des communications mobiles qui permettent d'imaginer un nombre de services trs important. De ce point, les acteurs sur le march des tlcommunications crent tout un dpartement au sein de leurs entreprises pour rpondre cette croissance considrable de la demande dinvention de nouveaux services de communication. Ces derniers ont besoin d'tre intgrs dans un rseau dj existant qui fonctionne suivant un ensemble de rgles et sous diffrents protocoles de communication. Le mtier d'intgration labore une documentation crite dtaille sur les tapes et les procdures respecter, par les diffrents intervenants. Il associe une grande capacit de production la flexibilit de ses chanes qui s'adaptent aux produits, aux dlais et aux quantits. A tout moment de la production, l'intgration ralise des "auto-tests" pour valider la qualit du travail et vrifier la compatibilit et l'interoprabilit du nouveau systme avec les plateformes et les composants dj dploys. Aussi, une simple intgration ncessite un ensemble de tests sur la capacit, la surcharge du systme, les bugs et les erreurs possibles qui peuvent tre produites lors de la mise en place de la solution en production.
1.2- La stratgie de Nokia Siemens Networks.

Selon Simon Beresford-Wylie, Directeur gnral de Nokia Siemens Networks, On commence dj tre l'un des leaders de l'industrie, nous avons un objectif bien clair: devenir numro UN. Nous voulons tre numro UN en tant que fournisseur des rseaux de communication nos clients, la socit numro UN connecter le monde via des modules de connections pour les communications fixes et mobiles, et numro UN en tant que poste de travail pour nos employs. Nous voulons aussi tre reconnus pour nos hautes valeurs d'thique et d'intgrit. . Puisque le march change et nos clients font face des challenges commerciaux complexes, nous aurons aussi besoin de changer vers Nokia Siemens Networks a dclar Mr. Guenter Landers, Directeur de la Sous-rgion Afrique du Nord Est & Ouest Nokia Siemens Networks. Apporter l'Internet et la connectivit une large majorit de gens d'ici l'an 2015 ncessitera de trouver de nouveaux moyens pour rduire les frais de connections, particulirement dans les marchs trs prometteurs. Nokia et Siemens ont annonc lors de la cration de la nouvelle socit le 19 Juin 2006, qu'ils rechercheront des estimations de synergies de cots de 1.5 milliards d'Euros par an d'ici l'an 2010 afin de construire une Nokia Siemens Networks forte et comptitive. . Ainsi, c'est dans cette logique que le groupe a
10
construit un institut international totalement consacr la formation afin de promouvoir son expertise technique et en matire de gestion de ses professionnels.
1.3- Secteur dactivit de NSN

L'infrastructure des tlcommunications continuera avoir le rle majeur jouer dans la capacit de Nokia Siemens Network et dans son aptitude de crer, fournir et livrer les meilleures solutions de bout en bout dans le monde pour les clients. Elle a ainsi cinq units de travail: accs sans fil, accs large bande, noyau technique et applications, IP/Transport, et Systmes de Soutiens des Oprations. Ces units de travail fournissent une large gamme de produits et d'applications pour les rseaux fixes, mobiles et convergents. En outre, la nouvelle socit rpond une demande de services toujours croissante travers son Unit de Services . Le portefeuille des produits proposs couvrira toutes les gammes de produits, services, solutions ayant relation avec l'infrastructure du rseau de tlcommunications. Il conduira la convergence IP et fournir des solutions de bout en bout, pour rpondre aux besoins des clients mondiaux. Nokia Siemens Networks Maroc collabore troitement avec Maroc Telecom; premier oprateur mobile et fixe au Maroc. Elle fournit principalement son client Maroc Telecom, les quipements Nokia Siemens Networks du rseau radio GSM34 ainsi que les prestations de services associs qui sont : Recherche et ngociation des sites, constructions des sites et implmentation d'infrastructure GSM pour les projets cls en main totale. Implmentation de l'infrastructure GSM pour les projets cls en main partiels. Drive-test et entretien de la qualit de service du rseau pour le contrat d'optimisation radio. Redploiement d'quipements. Fourniture, installation, mise en service de BSC35/TCSM/plateforme, de SMS/ MMS plateforme et bien d'autres plateformes. L'architecture organisationnelle de Nokia Siemens Networks Maroc est concentre autour de trois ples principaux :
Le Network Planning :
Il reprsente le cur du travail de Nokia Maroc. Il s'occupe de la partie technique: (Planification du rseau, dimensionnement, optimisation et maintenance du rseau BSS36 de
11
l'oprateur client). Le groupe de Network Planning est divis en zones gographiques, c'est dire, une quipe s'occupant du projet de Casablanca, une autre de celui de Rabat et une troisime pour la zone Nord Est. Ces diffrentes quipes sont supervises par un manager.
quipe commerciale :
Cette quipe se charge de toutes les procdures financires, l'tablissement des comptes de Nokia Siemens Networks et la planification du budget tabli tous les six mois.
quipe de dploiement et dintgration :

Cette quipe se charge de ngocier l'installation des nouveaux sites avec les propritaires dans le cas des contrats TK, de la supervision de la construction des sites et de la fourniture du matriel. Elle se charge aussi de la mise en place et l'implmentation des services valeurs ajoutes pour les clients selon les marchs conclus.
2. Projet et droulement du stage

2.1- contexte du projet
IMS est accepte par la plupart des acteurs de l'industrie des tlcommunications comme l'architecture de la convergence des rseaux de prochaine gnration. L'IMS joue le rle de couche logique intermdiaire entre, d'un ct, les terminaux et les rseaux de transport orients IP et, de l'autre, les services applicatifs tlcoms. Elle met en uvre certaines fonctions techniques (mcanismes de contrle et signalisation) entre diffrents quipements au cur d'un rseau d'oprateur, en recourant au protocole de signalisation SIP standardis par lIETF. Aujourdhui, les services IPTV et vido la demande (VoD) sont mis en place par les fournisseurs de services leurs abonns. Les fournisseurs de services qui ont l'intention d'voluer vers un rseau bas sur l'IMS qui offre des services comme l'IPTV et la vido la demande, devrait voluer l'architecture de telle sorte que l'IPTV et VoD soient proposs comme des services de communication multimdia sur leur rseau IMS. Instinctivement, cette combinaison de l'IPTV / VoD et l'IMS semble tre un bon ajustement, l'IMS est conue pour fournir des services de communication multimdias, et IPTV / VoD sont des services de communication multimdia. La solution VoD est une harmonie vidente dans l'architecture IMS, car il est en soi un
12
service de communication point point base sur le mode unicast de transmission sur IP. D'autre part, IPTV est un service de communication point multipoint bas sur le mode de transmission multicast sur IP. Concevoir l'architecture du rseau IMS pour s'adapter au service IPTV est moins vident par rapport au service VoD. L'mergence du rseau de prochaine gnration (NGN) a cr le besoin de convergence conduit par les SDP et les APIs Java qui se trouvent l'avant-garde du dveloppement d'applications pour les oprateurs tlcoms. Les spcifications des APIs telles que JAIN (Java Advanced Intelligent Network) et Java Tlphonie API ont quip les dveloppeurs d'applications pour les systmes et les rseaux NGN.
2.2- Objectif du projet et le droulement du stage

L'objectif de ce projet est le dveloppement d'un service Video la demande utilisant une open source Service Delivery Platform (SDP) : Mobicents JSLEE. Le stage s'inscrit dans le cadre des futurs projets que NSN veut mener. NSN utilise la solution Mobicents dans d'autres pays dans les rseaux de nouvelle gnration: (convergence fixe/mobile, convergence vers le tout IP,). L'objectif du stage est de matriser mobicents et notamment la solution VOIP qu'il offre, pour voir comment l'open source peut offrir, travers le dveloppement des services via SIP, une alternative commerciale moindre cot. Cette plateforme de services peut donc tre une solution robuste et performante adopte par les oprateurs dans les rseaux intelligents de nouvelles gnrations. Ce stage a t programm pour une dure de trois mois .Comme on peut le voir sur le diagramme suivant, le travail a t rparti en 6 grandes tapes :
13
Figure 1: Diagramme de GANTT du projet
2.3- Intrt du projet

Le stage traite dans sa globalit une solution VoD open source dans le but est de s'assurer de comment les solutions open source peuvent tre performantes et offrir une qualit de service aussi innovante que concurrente. Ces solutions remplacent ainsi celles des propritaires. Ainsi, il s'avre intressant d'tudier les solutions lowcost comme tant une autre alternative offrant des services multimdia.
Conclusion
Le long de ce chapitre nous nous sommes intresss l'organisme d'accueil NSN, ses activits principales ainsi qu' son plan stratgique. Ensuite nous avons situ le projet du stage, son objectif et son contexte technique. Dans ce qui suit, nous allons dans les rseaux de prochaine gnration, et leur volution IMS.
14
Chapitre 2 Les rseaux NGN
1. Introduction
Lvolution progressive du monde des tlcoms vers des rseaux et des services de nouvelle gnration est aujourdhui une tendance forte qui suscite lintrt dune majorit dacteurs. Elle rsulte de la conjonction dun ensemble de facteurs favorables dont : les volutions profondes du secteur des tlcommunications ; le dveloppement de gammes de services nouveaux ; les progressions technologiques denvergure dans le domaine des rseaux de donnes. Pour sadapter aux grandes tendances qui sont la recherche de souplesse dvolution du rseau, la distribution de lintelligence dans le rseau, et louverture des services tiers, il est ncessaire de sadapter une volution vers un nouveau modle de rseaux et de services appel NGN (NextGeneration Networks). Les NGN sont bass sur une volution progressive vers le tout IP et sont modlises en couches indpendantes dialoguant via des interfaces ouvertes et normalises. Les rseaux de tlcommunications traditionnels volueront vers un modle ouvert, distribu, fortement bas sur le protocole IP et la transmission en mode paquet en gnral. Cette volution technologique, tout en tant transparente pour les utilisateurs, se fera de manire progressive pour les oprateurs. . Dans ce chapitre nous prsentons une description de lensemble de ces nouveaux concepts NGN. Il inclut aussi une synthse des volutions technologiques majeures et le dtail des nouveaux concepts lis aux NGN.
2. Larchitecture en couche NGN

Une des caractristiques principales du modle NGN est de dissocier les services des rseaux physiques. Chaque lment fonctionnel d'une couche peut tre offert sparment et peut voluer indpendamment. Les lments fonctionnels qui constituaient un commutateur classique ont t spars suivant leur fonction primaire en couches diffrentes : une couche avec les fonctions de transport, une couche avec les fonctions de contrle de service, une
15
couche de management, service et application. Ainsi larchitecture NGN se caractrise par : Une couche Accs : qui permet laccs de lutilisateur aux services via des supports de transmission et de collecte divers : cble, cuivre, fibre optique, boucle locale radio, xDSL, rseaux mobiles. Une couche de transport en mode paquet (ATM : Asyncronous Transfert Mode, IP : Internet Protocol ...):Cette couche gre lacheminement du trafic vers sa destination. En bordure du rseau de transport, des media gateways et des signallinggateways grent respectivement la conversion des flux de donnes et de signalisation aux interfaces avec les autres ensembles rseau ou les rseaux tiers interconnects. Une couche Contrle indpendante des ressources physiques : Elle se compose de serveurs dits softswitch grant dune part les mcanismes de contrle dappel (pilotage de la couche transport, gestion des adresses), et dautre part laccs aux services (profils dabonns, accs aux plates-formes de services valeur ajoute). Une couche Services :Elle regroupe les plates-formes dexcution de services et de diffusion de contenus. Elle communique avec la couche contrle du cur de rseau via des interfaces ouvertes et normalises, indpendantes de la nature du rseau daccs utilis. Les services et contenus eux-mmes sont par ailleurs dvelopps avec des langages convergents et unifis. Des interfaces ouvertes et standardises entre les diffrentes couches : Les lments fonctionnels communiquent via des interfaces ouvertes qui peuvent tre des protocoles normaliss. L'externalisation des fonctions de contrle de la couche de transport : Les principales caractristiques des rseaux NGN rsident dans lutilisation dun rseau unique de transport en mode paquet (IP, ATM,) et de la sparation des couches de transport des flux et de contrle des communications.
16
Figure 2: Architecture de rseau NGN.
3. Les entits fonctionnelles au cur du rseau

On distingue entre deux types dquipements actifs dans le cur du rseau NGN, lesServeurs de contrle dappel dits Soft Switch ou Media Gateway Controller, les quipements de mdiation et de routage dits Media Gateway.
3.1- La Media Gateway (MG)

Les Gatewaysjouent un rle essentiel en assurant non seulement l'acheminement du trafic, mais aussi l'inter fonctionnement avec les rseaux externes et avec les divers rseaux d'accs. La Media Gateway est situe au niveau du transport des flux mdia entre le rseau RTC et les rseaux en mode paquet, ou entre le cur de rseau NGN et les rseaux d'accs. Elle a pour rle le codage et la mise en paquets du flux mdia reu du RTC et vice versa (conversion du trafic TDM IP) et aussi la transmission, suivant les instructions du Media Gateway Controller, des flux mdia reus de part et d'autre.
17
3.2- La Signalling Gateway (SG)

La fonction Signalling Gateway a pour rle de convertir la signalisation change entre le rseau NGN et le rseau externe interconnect selon un format comprhensible par les quipements chargs de la traiter, mais sans l'interprter (ce rle tant dvolu au Media Gateway Controller). Notamment, elle assure l'adaptation de la signalisation par rapport au protocole de transport utilis. Cette fonction est souvent implmente physiquement dans le mme quipement que la Media Gateway, d'o le fait que ce dernier terme est parfois employ abusivement pour recouvrir les deux fonctions MG + SG.
3.3- Le serveur dappel

Dans un rseau NGN, c'est le MGC qui possde l'intelligence . Il gre: L'change des messages de signalisation transmise de part et d'autre avec les passerelles de signalisation, et l'interprtation de cette signalisation. Le traitement des appels qui sopre par le dialogue avec les terminaux H.323, SIP voire MGCP, communication avec les serveurs d'application pour la fourniture des services. Le choix du MG de sortie selon l'adresse du destinataire, le type d'appel, la charge du rseau, etc. La rservation des ressources dans le MG et le contrle des connexions internes au MG (commande des Media Gateways). Il apparait donc dans l'architecture des rseaux NGN que le serveur d'appel, aussi appel Soft Switch ou Media Gateway Controller (MGC) est le nud central qui supporte l'intelligence de communication.
4. Les Familles protocolaires

La convergence des rseaux voix/donnes ainsi que le fait d'utiliser un rseau en mode paquet pour transporter des flux multimdia, ayant des contraintes de temps rel , a ncessit l'adaptation de la couche Contrle. En effet ces rseaux en mode paquet taient gnralement utiliss comme rseau de transport mais n'offraient pas de services permettant la gestion des appels et des communications multimdia. Cette volution a conduit l'apparition de nouveaux protocoles, principalement concernant la gestion des flux multimdia, au sein de la couche Contrle. On peut classer les protocoles de contrle en diffrents groupes: Les protocoles de contrle d'appel permettant l'tablissement, gnralement l'initiative
18
d'un utilisateur, d'une communication entre deux terminaux ou entre un terminal et un serveur. Les deux principaux protocoles sont H.323, norme de l'UIT et SIP, standard dvelopp l'IETF. Les protocoles de commande de Media Gateway qui sont issus de la sparation entre les couches Transport et Contrle permettent au Soft Switch ou Media Gateway Controller de grer les passerelles de transport ou Media Gateway. MGCP (Media Gateway Control Protocol) de l'IETF et H.248/MEGACO, dvelopp conjointement par l'UIT et lIETF, sont actuellement les protocoles prdominants. Les protocoles de signalisation entre les serveurs de contrle (ou Media Gateway Controller) permettant la gestion du plan contrle au niveau du cur de rseau avec des protocoles tels que BICC (BearerIndependant Call Control), SIP-T (SIP pour la tlphonie) et H.323. L'interconnexion avec les rseaux de signalisation SS7 se fait gnralement via des passerelles de signalisation ou SignallingGateways par l'utilisation de protocole tel que SIGTRAN. De plus il est noter que l'interconnexion de ces rseaux de donnes avec les rseaux existants de tlphonie (TDM avec signalisation SS7) a ncessit le dveloppement de protocoles ddis l'interconnexion des rseaux et au transport de la signalisation SS7 sur des rseaux en mode paquet.
5. NGN Multimedia: IMS.

5.1- Introduction.
Dans un rseau de tlcommunications IMS, la notion de commutation disparat au profit de la notion de sessions tablies avec des serveurs d'applications multiples. Au cours de ces sessions, toutes sortes d'changes peuvent s'enchaner ou se marier, tant au niveau du contenu (voix, images, vido et texte) qu'au niveau du nombre d'interlocuteurs. L'IMS rend plus ais le dploiement de tout type de service tlcoms s'appuyant sur un transport IP (tlphonie, visioconfrence ou partage de contenu). Le principal avantage que doit amener IMS aux oprateurs rside dans sa capacit de facilitation dimplmentation et de lancement de nouveaux services. Sans IMS, la mise en uvre dun nouveau service implique de lourdes contraintes pour un oprateur sur son rseau : dveloppement et intgration de nouvelles interfaces rseaux, de nouvelles applications, de nouvelles interfaces de facturation, etc. A cela sajoute les nouvelles capacits lies lusage du protocole SIP permettant loprateur de proposer toute une gamme de services innovants.
19
5.2- Architecture de lIMS.

5.2.1- Structuration en couche de larchitecture IMS.
Larchitecture IMS [1] peut tre structure en couches. La figure 3dcrit les diffrentes couches de lIMS.
Figure 3 : Architecture de lIMS. Quatre couches importantes sont identifies : La couche Accs: Celle ci peut reprsenter tout accs haut dbit tel que : UTRAN, CDMA2000, xDSL, rseau cble, Wireless IP, WiFi, etc. La couche Transport: Elle reprsente un rseau IP quipourra intgrer des mcanismes de QoS avec MPLS, Diffserv, RSVP, etc. La couche transport consiste donc en des routeurs relis par un rseau de transmission. La couche contrle: Cette couche consiste en des contrleurs de session responsables du routage de la signalisation entre les usagers et de linvocation de services. Ces nuds sappellent des Call State Control Function (CSCF). IMS Introduit donc un environnement de contrle de session sur le domaine paquet.
20
La couche application: Elle introduit les applications (services valeur ajoute) proposes aux usagers. Loprateur peut se positionner grce sa couche Contrle en tant quagrgateur de services offerts par loprateur lui-mme ou par des tiers. La couche application consiste en des serveurs dapplication (AS, Application Server) et des Multimdia resourcefunction (MRF) que les fournisseurs appellent serveurs de mdia IP (IP MS, IP Media Server).
5.2.2
Protocoles dfinis dans larchitecture IMS.
Les protocoles dfinis dans larchitecture IMS peuvent tre classs en trois catgories : Protocoles dauthentification et de scurit : Ce sont les interfaces (Cx, Dx et Sh) de larchitecture IMS qui utilisent les fonctions dauthentification. Dans toutes ces interfaces, le protocole dauthentification utilis est Diameter. Protocoles utiliss dans le plan mdia : IMS emploie le protocole temps rel RTP et le protocole de contrle temps rel RTCP (Real Time Control Protocol) pour la livraison de mdias. Protocoles de signalisation ou de contrle de session : Le protocole choisi par 3GPP pour le contrle de session est le protocole dinitiation de session SIP dfini dans RFC 3261[2].
Conclusion
Dans ce chapitre, nous avons prsent le rseau NGN et sont volution vers le concept IMS. On peut dire que la migration vers les NGN apparat comme un choix invitable du fait de la convergence voix/donnes/image et fixe/mobile. Elle a dj attir lintrt dun certain nombre dacteurs, en Europe et dans d'autres pays. Encore faut-il anticiper pour suivre et analyser ses impacts. Dans le chapitre suivant nous prsentons le protocole SIP que nous adopterons pour notre projet et qui a t retenu par le 3GPP pour l'architecture IMS comme protocole pour le contrle de session et le contrle de service.
21
Chapitre 3 Le Protocol SIP

1. Introduction
SIP (Session Initiation Protocol) est un protocole de signalisation dfini par lIETF (Internet Engineering Task Force) permettant ltablissement, la libration et la modification de sessions multimdias (RFC 3261). Le protocole SIP tel qu'il est connu est la runion de deux protocoles s'inspirant des protocoles de gestion de vidoconfrence. SIPv1 est un mcanisme pour mettre en place des communications point point ou multicast. Ce protocole repose sur des changes de message en mode texte. Son concept est l'enregistrement auprs de serveurs de confrence. De l'autre ct, le protocole SCIP (Simple Conference Invitation Protocol) a notamment les codes de rponse. L'identification des utilisateurs se fait grce des adresses e-mails dans le but de leur fournir un identifiant unique quelque soit le mode de communication choisi. Le RFC2543 initialement tabli a t rendu obsolte par le RFC3261 publi en Juin 2002. SIP a t tendu afin de supporter de nombreux services tels que la prsence, la messagerie instantane (similaire au service SMS dans les rseaux mobiles), le transfert dappel, la confrence, les services complmentaires de tlphonie, etc. Il remplacera terme les protocoles ISUP (utilis pour le contrle dappel dans le Rseau Tlphonique Commut) et INAP (utilis pour le contrle de service dans larchitecture Rseau Intelligent). Le protocole SIP n'est qu'un protocole de signalisation. Une fois la session tablie, les participants de la session s'changent directement leur trafic audio/vido travers le protocole RTP (Real-Time Transport Protocol). Par ailleurs, SIP n'est pas un protocole de rservation de ressources, il ne peut donc pas assurer la QoS, il s'agit d'un protocole de contrle d'appel et non de contrle du mdia. SIP n'est pas non plus un protocole de transfert de fichier tel que HTTP, utilis afin de transporter de grands volumes de donnes. Il a t conu pour transmettre des messages de signalisation courts afin d'tablir, maintenir et librer des sessions multimdia.
22
2. SIP Composants.
SIP supporte des fonctionnalits pour l'tablissement et la fin des sessions multimdia : la localisation, la disponibilit, l'utilisation des ressources, et les caractristiques de ngociation. Pour la mise en uvre de ces fonctionnalits, SIP offre plusieurs composants, qui peuvent tre diviss en deux : User Agents (UA) et les serveurs.
Figure 4: Entits dun rseau SIP
2.1- Agent utilisateur (UA, User Agent).

Il sagit dune application sur un quipement de lusager qui met et reoit des requtes SIP. Il se matrialise par un logiciel install sur un PC, sur un tlphone IP ou sur une station mobile UMTS (UE, User Equipment). Il est form de deux parties diffrentes, l'User Agent Client (UAC) et le User Agent Server (UAS). UAC est une entit logique qui cre des requtes SIP et reois des rponses cette demande. AS est une entit logique qui cre des rponses aux requtes SIP. Les deux sont inclus dans tous les agents utilisateurs, afin de permettre la communication entre les agents utilisateurs grce des communications client-serveur.
23
2.2- SIP Serveurs.

Les composants serveur de l'infrastructure SIP peuvent tre diviss en trois types: Le serveur proxy (Proxy server) : Il reoit des requtes de clients quil traite lui-mme ou quil achemine dautres serveurs aprs avoir ventuellement ralis certaines modifications sur ces requtes. Le serveur de redirection (Redirect server) : Il sagit dun serveur qui accepte des requtes SIP, traduit l'adresse SIP de destination en une ou plusieurs adresses rseau et les retourne au client. Contrairement au Proxy server, le Redirect server n'achemine pas de requtes SIP. Dans le cas dun renvoi dappel, le Proxy server a la capacit de traduire le numro de lappel dans le message SIP reu, en un numro de renvoi dappel et d'acheminer lappel cette nouvelle destination, et ce, de faon transparente pour le client origine ; pour le mme service, le Redirect server retourne le nouveau numro (numro de renvoi) au client origine qui se charge dtablir un appel vers cette nouvelle destination. Lenregistreur (Registrar) : Il sagit dun serveur qui accepte les requtes SIP REGISTER. SIP et dispose de la fonction denregistrement dutilisateurs. Lutilisateur indique par un message REGISTER mis au Registrar, ladresse o il est joignable (e.g, adresse IP). Le Registrar met alors jour une base de donnes de localisation. Lenregistreur est une fonction associe un Proxy server ou un Redirect server. Un utilisateur peut senregistrer sur diffrents UAs SIP ; dans ce cas, lappel lui sera dlivr sur lensemble de ces Uas. Il existe galement un autre type de serveur aux fonctions bien particulires dans la classification de SIP : le back-to-back user agent (B2BUA). Il s'agit en fait d'un serveur proxy avec tat agissant comme un user agent de bout en bout, tantt en tant que serveur (rception de requtes) tantt en tant que client (cration de messages en rponses aux requtes et non une simple transmission). Il conserve en mmoire l'tat des transactions et dispose d'un contrle total sur les messages (modification des en-ttes, du corps des messages). Ainsi, un B2BUA est capable de fournir des fonctionnalits telles que : le contrle d'appel (facturation, dconnexion automatique d'appel, transfert d'appel, etc.), l'interconnexion de rseaux (avec adaptation ventuelle au niveau du protocole), la dissimulation d'entits rseau (adresses prives, topologie rseau, etc.) ou encore la traduction de codec entre deux parties [3]. Le B2BUA constitue donc un lment capital pour fournir des services tendus, comme les applications de type Class-5 Switches, PrivateBrancheXchange (PBX) ou encore Centre d'appels. Il est important de noter que ces diffrentes "entits SIP" sont des abstractions
24
logiques et non physiques, une implmentation peut tout fait les combiner au sein d'une seule et mme application machine. L'intrt de sparer ces fonctionnalits rside essentiellement dans l'quilibrage de la charge de traitement au niveau de dploiements grande chelle.
3. Messages SIP
3.1- Principales mthodes SIP
Le protocole SIP repose sur le mme modle de transactions que HTTP base de requtes/rponses. Ces transactions consistent en un change de messages tel que celui de lexemple reprsent dansla figure 5 qui sont constitus de diffrents en-ttes spcifiant l'appelant, l'appel, le sujet de l'appel et la route emprunte pour la dlivrance de ce message. Chaque transaction est constitue d'une requte qui invoque une mthode particulire sur le serveur et d'au moins une rponse.
Figure 5: Exemple de message SIP Il existe six mthodes dans le noyau SIP qui sont dcrites dans le tableau 1.
25
Tableau 1: Les six mthodes du noyau SIP.
3.2-Extension des mthodes SIP

De nombreuses extensions sont venues complter le jeu de mthodes originelles afin d'offrir davantage de fonctionnalits, ncessaires par exemple pour que les rseaux SIP puissent interoprer avec d'autres technologies comme la tlphonie traditionnelle PSTN, mais aussi pour fournir les services que la tlphonie sur IP promettait. Les mthodes tendues de SIP sont prsentes comme suit : SUBSCRIBE : permet la souscription dun UA (user agent). NOTIFY : utilis pour la notification dun user agent. PUBLISH : permet de publier ltat dun UA. MESSAGE : permet le transfert des messages instantans. UPDATE: permet un terminal SIP de mettre jour les paramtres dune session MultiMedia. INFO : permet de transfrer des informations de signalisation durant l'appel. Parmi les exemples d'information figurent les digits DTMF, les informations relatives la taxation d'un appel.
26
3.3- Rponses SIP

Aprs avoir reu et interprt une requte SIP, le destinataire de cette requte retourne une rponse SIP. Il existe six classes de rponses qui sont regroupes dans le tableau suivant :
Tableau 2: Rponses SIP
27
Exemple dtablissement et de libration de session SIP :
Figure 6: Etablissement et libration de session SIP
4. Protocole RTSP.
Dans cette partie, nous nous intressons au protocole RTSP (Real-Time Streaming Protocol). RTSP a t dvelopp par Real Networks, Netscape et lUniversit de Columbia au sein du MMUSIC working group de lInternet Engineering Task Force (IETF). Il est implment aujourdhui dans les produits de ces socits. Le but du protocole RTSP est de mettre disposition de lutilisateur une tlcommande qui lui permettra de commander le flux multimdia en cours. Cette tlcommande lui servira commander un ou plusieurs serveurs en parallle et pourra tre partage simultanment entre plusieurs utilisateurs. RTSP a pour but dtablir et de contrler un ou plusieurs flux synchroniss de contenu continu de multimdia, tels laudio et le vido par exemple. Mme si la spcification de RTSP
28
lui permet de prendre en charge la distribution de ce contenu multimdia, la distribution de ce flux sera en gnral prise en charge par RTP, RTSP ayant ainsi comme seule fonction la commande du flux. Ces flux seront dfinis par un protocole de prsentation. La RFC2326 ne dfinit pas le format de prsentation.
4.1- RTSP et les protocoles de transport

RTSP nest pas un protocole connect. Cest le serveur qui garde tout au long dune session un numro lui permettant didentifier les flux en cours et les clients concerns par ce flux. Les messages de contrle RTSP seront achemins via une connexion qui pourra utiliser soit UDP soit TCP et sera tablie sur le port 554. Les flux multimdia seront achemins par une connexion hors bande utilisant un protocole quelconque de la couche de transport. Cest souvent le protocole RTP qui est utilis pour la transmission des flux.
4.2-RTP et RTCP
Le but de RTP et de fournir un moyen uniforme de transmettre sur IP des donnes soumises des contraintes de temps rel (audio, vido, etc.). Le rle principal de RTP consiste mettre en uvre des numros de squence de paquets IP pour reconstituer les informations de voix ou vido mme si le rseau sous-jacent change l'ordre des paquets. En rsum, RTP permet: d'identifier le type de l'information transporte, d'ajouter des marqueurs temporels et des numros de squence l'information transporte, de contrler l'arrive destination des paquets. De plus, RTP peut tre vhicul par des paquets multicast afin d'acheminer des conversations vers des destinataires multiples. Le protocole RTCP est base sur des transmissions priodiques de paquets de contrle par tous les participants dans la session. C'est un protocole de contrle des flux RTP, permettant de vhiculer des informations basiques sur les participants d'une session, et sur la qualit de service.
4.3- RTSP et HTTP

Le protocole RTSP utilise comme format les caractres de texte. Les concepteurs de RTSP ont aussi choisi de baser leur protocole sur un protocole applicatif russi, HTTP, ce qui
29

permettrait de rutiliser les protocoles de commerce lectronique et dauthentification dj implments sur HTTP. Ceci permettrait aussi RTSP de sadapter aux proxys et pare-feu configurs et optimiss pour des protocoles comme HTTP. Cependant, HTTP ne pouvait pas dintgrer de nouvelles enttes afin datteindre les objectifs de RTSP, car HTTP ne peut pas grer les connexions hors bande, et il convenait plus davoir une certaine sparation entre le serveur Web et le serveur multimdia. Les principaux points de diffrence entre RTSP et HTTP sont les suivants : un serveur RTSP garde un tat de la connexion avec le client au cours dune session. A la diffrence de HTTP, une session RTSP nest pas lie une connexion TCP, mais uniquement un identificateur de session, un serveur RTSP peut initier des requtes ayant le client comme destinataire,
4.4- Fonctionnalits de RTSP

Le protocole RTSP permet de raliser les scnarios suivants: rcupration dun contenu multimdia partir dun serveur. La description du contenu multimdia est rcupre via HTTP ou une autre mthode (e-mail par exemple). La rcupration du flux multimdia peut se faire en unicast aussi bien quen multicast, invitation dun serveur multimdia une confrence, afin dincorporer la confrence un flux multimdia existant sur ce serveur, ou deffectuer un enregistrement dune partie ou de la totalit de la confrence sur le serveur invit. Cette fonctionnalit est utile dans le cas dune application distribue de e-learning par exemple. Notons ici que les protocoles SIP et H.323 peuvent aussi tre utiliss pour accomplir cette tche, rajout dun contenu multimdia une prsentation en cours. Dans ce cas, lors dune diffusion en direct par exemple, le serveur prvient le client quun flux supplmentaire est disponible pour la transmission.
4.5- Paramtres de RTSP

Parmi les paramtres importants de RTSP, nous pouvons citer: lurl : rtsp_URL = ( "rtsp:"|"rtspu:" ) "//" hte [ ":" port ] [ chemin ] Le terme rtsp:// spcifie que la connexion de contrle sera tablie via TCP alors, que le terme rtspu:// indique une connexion de contrle tablie via UDP.
30
Les requtes RTSP sont acquittes par le rcepteur dans le cas o elles ne sont pas envoyes un groupe mutlicast. En absence dacquittement, lmetteur renvoie le mme message aprs un dlai de 1 RTT (round-trip time). Les mthodes destimation de ce RTT sont similaires celles utilises par TCP (RFC1123). Cependant, si RTSP opre en mode connect, les requtes ne doivent pas tre retransmises. Dans ce cas, cest le protocole de la couche transport qui assure la fiabilit, sinon un paquet perdu serait retransmis deux fois de suite, ce qui pourrait aggraver une ventuelle congestion. De plus, dans ce cas, la retransmission RTSP ne russira pas car le protocole de transport nacheminera pas cette retransmission tant que la retransmission au niveau couche transport na pas eu lieu. La figure ci-dessous reprsente les diffrentes tapes dune session RTSP. Nous pouvons ainsi voir concrtement comment sont utiliss les mcanismes dtaills prcdemment.
Figure 7 : Exemple dune session RTSP
Conclusion
Dans ce chapitre nous avons prsent le protocole SIP que nous avons utilis pour notre projet pour le dveloppement des services VoIP. Nous avons expliqu comment sa flexibilit permet de crer tout type de service VoIP, en insistant plus particulirement sur le protocole charg d'tablissement et du control du flux multimdia continu. Dans le chapitre suivant nous prsentons la plateforme Mobicents et l'API JAIN et plus particulirement les dtails qui se rapportent cette technologie dont notamment son point fort : le dveloppement des services via SIP.
31
Chapitre 4 La Plateforme Mobicents.

1. Introduction
Mobicents est un serveur d'application base sur un modle vnementiel de haute scalabilit et un modle de composant trs robuste. Cest un projet qui comprend des contributeurs individuels, avec l'autorisation des organismes tels que Portugal Telecom
Inovao, Telecom Italia,University of Genova, Vodafone R&D, T-Mobile, Lucent Technologies, Open Cloud, Aepona, NEC Japan, JBoss, ...etc. Mobicents complte J2EE et assure la convergence voix/vido/donnes dans les rseaux de nouvelle gnration. Cest la premire et la seule plate-forme de VOIP libre qui a t certifie pour SLEE 1.0, et la meilleure architecture pour crer, dployer et grer les services et l'intgration des applications voix, vido et donnes travers une plage d'adresses IP et des rseaux de communications[4]. Elle favorise la convergence via cinq capacits de base :
Figure 8 : Architecture de Mobicents.
Mobicents est la source ouverte la plus populaire SIP Serveur d'application pour la plateforme de Java. Il facilite l'excution de nouveaux servicesdune manire simple et rapidement ; permet le dveloppement d'une plateforme oriente vers le march et garantit la rentabilit de la livraison de service. Mobicents propose aussi un dploiement facile des applications et offre galement des fonctionnalits de gestion de la qualit et des outils de JBoss Application Server, tels que la console JMX, Jopr Plugins et SNMP adaptateur, ce qui permet la configuration et le contrle des applications SLEE de manire simple.
32

RedHat a rcemment fait l'acquisition de la technologie Mobicents. En combinant loffre middleware de JBoss et de Mobicents, RedHat a cr la plate-forme de communication RedHat/JBoss destine au secteur des tlcommunications. La figure ci-dessous illustre cette architecture [5].
Figure 9 : Architecture de la plateforme de communication Redhat/JBoss.
Mobicents permet la composition des modules de service (SBB) comme la commande d'appel, la facturation, l'approvisionnement d'utilisateur, l'administration et les dispositifs sensibles de prsence. D'une manire aise avec EclipSLEE offre un environnement
graphique de cration de service pour le dveloppement rapide des services valeur ajoute de JAIN SLEE. Les spcifications de JAIN SLEE permettent aux piles populaires de protocole telles que le SIP d'tre relies comme adapteurs de ressource. Les modules de service de SLEE - SBBs sont des composants de logiciel qui envoient et reoivent des vnements et excutent la logique informatique base sur la rception des vnements et de son tat actuel. Ils ont beaucoup de similitudes EJBs. En plus des telecom, Mobicents convient une varit d'exiger de domaines de problme Event Driven Architecture (EDA) pour le volume lev et basse signalisation de latence. Les exemples incluent les marchs financiers, le jeu en ligne, les rseaux de capteurs(RFID).
2. La Technologie JAIN
JAIN est un ensemble d'API JAVA qui permet de dvelopper rapidement de nouveaux services pour des rseaux de tlcommunication voix ou donnes, indpendamment des
33
serveurs utiliss (matriel). De plus, JAIN tant bas sur la plateforme JAVA, il introduit la portabilit des services entre systmes et permet des accs scuriss aux ressources des diffrents rseaux. La technologie JAIN change radicalement le march des tlcommunications en permettant le passage de systmes ferms et propritaires des systmes ouverts offrant une interconnexion totale des diffrents rseaux existant (PSTN25, IP, ATM26, GSM, WLAN27). Ceci peut tre constat dans la figure ci-dessous qui donne une reprsentation schmatique de larchitecture de JAIN [6].
Figure 10 : Architecture de Base de JAIN.
2.1- Avantages et intrts de JAIN

En fournissant un haut niveau dabstraction par rapport au matriel, JAIN apporte de nombreux avantages tactiques et conomiques tels que : La portabilit des services : Actuellement le dveloppement de service est limit par les interfaces propritaires de chaque systme. En offrant une indpendance totale
34
par rapport au matriel, JAIN permet la rutilisation des services pour tous les types de rseaux tout en rduisant les temps et les cots de dveloppement. Les temps et cots de maintenance sont eux aussi diminus de faon significative. La convergence des rseaux : En offrant la possibilit de dvelopper des services indpendamment des rseaux cibles, il est possible de fusionner les rseaux habituellement incompatibles. Cette caractristique permet daugmenter la diversit des services, de faire des conomies dchelle, doptimiser la gestion des rseaux et dassurer une meilleure intgration des technologies de linformation (IT). La scurit daccs : La scurit offerte par JAVA autorise des accs des rseaux internes par des personnes trangres. Cette particularit par rapport aux systmes actuels, permet daccrotre la diversit des services en supprimant les contraintes dcoulant de la scurit entre rseau.
2.2-
Les couches dabstractions
Le but de JAIN est de crer des services de nouvelles gnrations pouvant intgrer des communications par paquet (IP, ATM), PSTN et sans-fil. Il dfinit donc un environnement dexcution indpendant du protocole de signalisation en proposant plusieurs couches dabstraction, une libraire de composant, des outils de dveloppement et un environnement de cration de services. Les trois couches dabstractions sont :
Couche rseau :
Il sagit dune couche dfinissant le protocole de communications choisit. Tlcommunications : Rseaux intelligents (AIN, IN) ou SS7 avec de nombreux protocoles ISUP, TCAP, INAP Wireless : SS7 avec des applications mobiles. VoIP : SIP, MGCP, Megaco, H.323.
Couche de signalisation :
Il sagit dune couche reprsentant les logiciels chargs de la gestion des communications. Tlcommunications : Signaling Service Point (SSP). Wireless : Mobile switching center (MSC). VoIP : Proxy, redirect serveur, H.323 gatekeeper, media controllers.
Couche de service :
Il sagit dune couche reprsentant les services de base.
35

Tlcommunications : Service Control Point (SCP). Wireless : Base Station Controllers (BSC), Home Location Register (HLR). VoIP : Serveur dapplication internet.
Figure 11 : Architecture en couche de JAIN.
2.3- Les diffrentes APIs de JAIN

La technologie de JAIN permet l'intgration de l'Internet et des protocoles du rseau intelligent, dsigns sous le nom rseaux intgrs . Deux types dAPIs ont t dfinis : des APIs relatives la standardisation des interfaces daccs aux services et une autre classe dAPIs propre aux conteneurs dapplications. Les interfaces standard mettent la disposition du langage de programmation Java tous les protocoles de tlcoms. En revanche, les conteneurs d'applications fournissent un environnement standard d'excution pour des services de tlcommunication. Ces services emploient typiquement ces interfaces standard pour des communications par l'intermdiaire des adaptateurs de ressources. JAIN contient plusieurs APIs comme on peut le voir dans la figure 12, et qui peuvent
36
tre utilises selon le service dsir. Dans ce projet nous avons utilis deux APIs JAIN SLEE et JAIN SIP.
Figure 12 : Diffrents APIs de JAIN.
SIP, un protocole actuellement populaire dans le domaine des tlcoms, parce qu'il possde lavantage de ne pas tre attach un mdium particulier et est sens tre indpendant du protocole de transport des couches basses. De plus, il peut tre tendu et sadapter aux volutions futures. JAIN offre le JAIN SIP 1.1 APIs en tant qu'lment du Java APIs pour les communications. En utilisant le SIP, on peut dvelopper nos propres services comme par exemple le fameux SIP Gateway , qui est ncessaire pour crer et contrler les connexions. Les spcifications dfinissent deux types de conteneurs d'applications Java pour les communications : les Servlets SIP et la JAIN/SLEE. Les servlets SIP, similaire au servlets HTTP sont prvues pour dvelopper tout type de services. Elles peuvent interagir avec dautres sources de donnes tout en garantissant une bonne scurit, il est en effet possible de confiner les servlets nutiliser que par les ressources de la machine virtuelle. La technologie JAIN SLEE permet la cration de services disponibles, fiables et modulaires qui sont portables entre les vendeurs JAIN SLEE. Dans notre projet nous utiliserons JAIN SLEE. En fait, nos services seront par la suite hbergs par ce type de conteneur. Pour cette raison nous allons consacrer toute une partie de ce chapitre au descriptif ce composant. Mais il faut tout dabord mettre laccent sur JAIN SIP
37
API, puisque dans notre application nous avons opt pour le protocole SIP.
2.4- JAIN SIP API

La communaut Java na pas tard de s'intresser SIP. Il en dcoule de nombreuses implmentations du protocole pour diffrents supports. La premire implmentation fut JAIN. Elle permet d'avoir un contrle trs fin sur les messages. L'API inclue un ensemble d'objets et d'interfaces qui fournissent des abstractions de haut niveau pour reprsenter les concepts SIP, librant le programmeur des dtails fins comme la gestion des transactions, mais permettant l'accs aux champs importants du message SIP (From, To, Request- URI, Contact). Ainsi, l'API a pour but de permettre aux applications d'avoir un contrle sur la signalisation SIP tout en cachant toute la complexit sous-jacente qui n'est pas approprie pour les dveloppeurs.
Figure 13 : Architecture JAIN SIP. La figure 14 montre quen plus de JAIN SIP, il existe dautre APIs qui sont : JAIN SIP Lite, il sagit dune API haut niveau fournissant une abstraction du stack SIP, elle peut tre utilise pour crer un agent SIP. JAIN SIP Servelts.
38
Figure 14: Les diffrentes JAIN SIP API
Actuellement seule la spcification de JAIN SIP est disponible, elle est fournie avec une bonne documentation qui dcrit toutes les mthodes de linterface.
3. JAIN SLEE.
3.1- Introduction.
La notion de serveur d'application est un concept bien connu dans le monde de dveloppement. Un SA permet le dveloppement rapide d'applications. Il assure galement de grandes performances. En offrant un Framework de travail, il facilite et acclre la cration et le dploiement des applications. J2EE AS est le leader mondial des serveurs d'applications. Cette dernire technologie, fortement utilise dans le domaine des IT, a lavantage daccrotre
39

la productivit et de rduire l'effort des dveloppeurs dans la rsolution du cur des problmes. Pour arriver ce rsultat des entits programmables seront utilises pour btir la solution. L'quivalent de J2EE dans le monde des Tlcommunications et des applications ayant des contraintes temps rel est JSLEE. Dans cette partie nous prsentons le serveur d'application JSLEE, nous donnons son architecture ses composants ainsi que son principe de fonctionnement.
3.2- La spcification de JAIN SLEE

La spcification JAIN SLEE fournit une norme permettant aux dveloppeurs java d'laborer et de dployer des services dans des systmes en temps rel comme les rseaux de transmission vocale ou de donnes ou les systmes d'automatisation industrielle. En fait, les systmes de communications sont des systmes asynchrones bass sur le modle dvnement, contrairement aux systmes dentreprises qui utilisent typiquement les mthodes dinvocations directes. Une architecture existante d'entreprise est dfinie par les spcifications de Entreprise JavaBeans . Le tableau ci-dessous donne une comparaison entre les caractristiques des systmes d'entreprises et de communications [7].
Tableau 3: Comparaison entre le systme de communication et le systme dentreprise.
Comme le montre ce tableau, il y a des diffrences substantielles entre les systmes de
40
communications et les systmes d'entreprises. Les spcifications d'EJB rpondent aux exigences des systmes d'entreprises, alors que la SLEE rpond aux exigences des systmes de communications actuels. Bien que les conteneurs existants de J2EE traitent galement les vnements asynchrones (JMS), ils n'ont pas t conus pour cela. Une SLEE, d'autre part, a t spcifiquement conue pour les systmes de tlcommunications haute frquence et qui sont compltement asynchrones. Ainsi, une SLEE remplit les exigences des systmes de communications de faon bien meilleure que n'importe quel conteneur d'EJB.
3.3- Les composantes de bases du JAIN SLEE

LAPI du SLEE dfinit une interface standard pour le dveloppement dapplications de tlcommunications portables. Les spcifications de cet API ont t menes par David Ferry de la socit Open Cloud et Swee Lim de la socit Sun Microsystems [8]. JAIN SLEE intgre un modle d'vnement avec un composant de programmation tout en incorporant aussi des interfaces d'administration par l'intermdiaire de JMX, un adaptateur de ressources pour le rseau, des interfaces de profils gnriques, un systme de gestion de persistance pour les tats de redondance, des systmes de contrle d'accs concurrent comme les minuteries, des systmes d'alarmes et un systme de suivi d'utilisation et des traces. La figure ci-dessous prsente larchitecture de JAIN SLEE et les relations entre ses diffrents composants :
Figure 15:Architecture de Jain SLEE
41
3.3.1- Ladaptateur de ressource

Les adaptateurs de ressources communiquent avec les systmes externes au SLEE, tels que, les composants de rseau, les protocoles stacks, les bases de donnes, etc. Selon l'architecture du SLEE, un adaptateur de ressources est une implmentation propre au vendeur d'un type d'adaptateur de ressource. Une instance d'un adaptateur de ressources dans la SLEE s'appelle une entit d'adaptateur de ressources. Le type d'adaptateur de ressource dclare tous les types d'vnements qui peuvent tre produits ainsi que toutes les activits que ladaptateur peut introduire. Quand un adaptateur de ressources passe un vnement au SLEE, il doit fournir son objet et son type ainsi quune activit qui lencapsule (figure 16). Les spcifications n'noncent pas comment cette information est passe au SLEE.
Figure 16 : Rle de ladaptateur de ressource.
3.3.2- Le routeur dvnements

Les spcifications de SLEE dfinissent comment un vnement mis par un producteur d'vnements est conduit et fourni un ou plusieurs composants qui lui sont intresss. Pour ce faire la SLEE est quipe dun routeur logique dvnements. Celui-ci reoit des vnements mis de tous les producteurs d'vnements et les achemine aux diffrentes instances correspondantes.
42
3.3.3- Lvnement
Les objets d'vnements diffusent l'information entre les diffrentes entits du SLEE. Seules les SBB consomment et produisent des vnements, alors que toutes les autres entits telles que les adaptateurs de ressources, la SLEE elle-mme peuvent les produire. Chaque vnement est reprsent par un objet d'vnements (sous-classe de java.lang.Object) et un type. Le type d'vnement dtermine comment le SLEE conduira l'vnement, par exemple, quels sont les objets SBB qui doivent recevoir l'vnement. Un SBB reoit les vnements du contexte dactivit qui lui est rattach. Le dveloppeur doit dfinir une mthode abstraite pour lexcution de chaque vnement dont le SBB a besoin. Cette mthode est gnralement excute par la SLEE. Dans le cas dun vnement initiateur, la SLEE doit crer un objet SBB avant de lui acheminer lvnement.
3.3.4- Les services et Les profils

Dans JAIN SLEE, un service constitue un artifice de dploiement et de gestion. Pour dfinir un service, l'administrateur doit spcifier le descripteur de dploiement du service avec notamment les informations telles que le nom (globalement unique), le fournisseur et la version du service ainsi que tout programme (classes Java, ) faisant partie du service. Un profil contient des donnes provisionnes par un administrateur par exemple. Ces donnes ont un schma qui peut tre constitu dattributs ou de proprits. Par exemple, une adresse mail ou un numro de tlphone peuvent tre des attributs dun profil dabonn. JAIN SLEE dfinit aussi la notion de spcification de profil qui dtermine le schma du profil ainsi que la logique qui assure qu'un profil donn est valide.
Figure 17 : profile et table de profile
43
Dveloppement du Service VoD sous La Plateforme Mobicents NSN Lactivit et le contexte dactivit
3.3.5-
Les classes dactivits comprennent les deux entits logiques, activit et contexte d'activit, et leurs reprsentations d'objet en Java, objet d'activit et objet dinterface de contexte d'activit. Une activit reprsente un ensemble dvnements. La reprsentation Java de cette entit logique est l'objet d'activit cr soit par l'adaptateur de ressource ou les quipements de gestion de la SLEE. JccCall est un exemple d'objet d'activit faisant partie de Java Call Control APIs qui reprsente un appel tlphonique.
Figure 18 : Activit et contexte dactivit.
Un contexte d'activit reprsente l'activit fondamentale dans la SLEE et tient galement les attributs en commun que les entits SBB veulent partager. Les objets SBB peuvent accder aux contextes d'activit par l'objet interface de contexte d'activit. Un SBB peut utiliser une interface de contexte dactivit gnrique comme il peut tendre cette interface pour dfinir des attributs supplmentaires, quil veut partager avec dautres objets. Les objets d'activits sont produits par des vnements de rseau. Les adaptateurs de ressources coutent ces vnements et crent les objets dactivits appropries. Ces objets sont placs dans le contexte d'activit du SLEE. Ds lors, le SLEE est maintenant responsable de la livraison des vnements produits aux objets du SBB. Vice versa, un objet du SBB peut accder l'interface du contexte d'activit pour obtenir l'accs l'objet d'activit courante.
3.3.6- Composants SBB (Service Building Block)

Comme nous l'avons vu, le SLEE dfinit une architecture avec des composants. Ces
44
composants portent le nom de Service Building Block (SBB). Un SBB est un composant logiciel qui contient une certaine logique applicative travers lenvoi ou la rception dvnements. Les SBB sont des composants mmoire pouvant se souvenir du rsultat des traitements passs et les rutiliser dans les traitements futurs. Un SBB peut tre compos partir dautres SBB permettant ainsi de composer des applications sophistiques en combinant un ensemble de SBB. Les SBB implmentent la logique applicative en se basant sur les vnements. Un vnement reprsente une occurrence significative qui peut survenir un moment non dfini dans le temps. La dfinition dun SBB inclut les informations telles que le nom, le fournisseur et la version du SBB mais aussi le code Java du SBB.
Figure 19 : Flux dvnements dans un SBB ; Le SBB est le composant le plus lmentaire dans la SLEE. Il est inspir de lEJB sur lesquels se basent les systmes dentreprise J2EE . Un composant SBB dfinit : Les types dvnements quil peut recevoir et traiter. Des mthodes pour traiter chaque type dvnement. Les relations Child qui le rattache des composantes SBB Child. Les donnes quil dsire partager avec les autres composants par lintermdiaire dun ensemble dattributs dactivitycontext. Le dveloppeur dun SBB implmente ce quon appelle un SBB Abstract Class de linterface SBB dj dfinie dans les spcifications de la SLEE.
3.3.7-Composants de gestion et de contrle des services

Pour contrler efficacement les services, les changes d'vnement et les ressources, il
45
est ncessaire de surveiller et mesurer l'excution, l'utilisation et la disponibilit de ces attributs, tout en estimant leurs situations futures. Les spcifications de la SLEE dfinissent un certain nombre de composantes qui peuvent tre employes pour rpondre ces exigences. Le temporisateur : cette fonction procure des applications la possibilit d'effectuer des actions priodiques, ou lancer des actions et des contrles un temps postrieur pour sassurer quils ont t bien accomplis. Le temporisateur contrle un certain nombre de temporisateurs, dont chacun est indpendant des autres. Le service d'alarme : des alarmes sont employes pour informer des applications de gestion qu'un changement inattendu d'tat s'est produit dans un lment de rseau. Les composants de SBB emploient le service d'alarme pour produire des avis d'alarme destins la consommation par des clients de gestion externe au SLEE. L'envoi des alarmes aux applications de gestion est automatiquement dclench quand un tat particulier devient vrai. Ces clients de gestion peuvent tre une console de gestion de rseau ou un moteur de politique de gestion. Service de mesure des statistiques : les statistiques sont des caractristiques de lapplication ou du rseau qui sont priodiquement demandes par les applications de gestion. Un client de gestion peut employer les paramtres de ce service pour surveiller le taux d'utilisation de chaque application. Composant de gestion de profil : Ce service permet aux applications de rechercher des profils stocks dans des tables de profil. Les profils contiennent des donnes stockes dans la SLEE.
4. Mobicents Media Server (MMS)

Dans le monde des tlcommunications bas sur la VoIP, les fournisseurs offrent des services hautement personnaliss qui combinent les mdias comme l'audio/vido ou messagerie instantane. Ces services ncessitent des capacits de traitement de mdias ddies et personnalises. Pour cela le rseau VoIP spare les fonctions de traitement des mdias en nud ddi qui est responsable de traitement des mdias seulement, alors que toute l'intelligence est excute par le contrleur d'appel distinct. Le nud de traitement des flux de mdia est appel Media Server. Dans le mme temps, il y'a beaucoup de flux mdia dans les systmes existants. Cela signifie que les nuds de traitements de mdia doit tre capable de combler l'cart entre les anciens systmes traditionnels et les systmes modernes de rseau VoIP. Ce nud
46
gnralement appel en tant que passerelle media, mais normalement les actes de passerelle mdia sont aussi appels serveur mdias.
4.1- Mobicents Media Server

Mobicents Media Server est une implmentation Open Source de l'lment responsable de la manipulation des mdias dans le rseau VoIP. Le serveur Media Mobicents supports IP et l'interface TDM et donc agir en tant que serveur et passerelle Multimedia, et aussi fournit un support pour les services distribus et centraliss, y compris la commutation par circuit la voix/vido, etc. Mobicents Media Server est fourni avec le standard Telco MGCP interface et peut fonctionner en paire avec le serveur d'application Mobicents JAIN SLEE. Toutefois le standard MGCP interface permet d'utiliser le serveur de medias Mobicents en paire avec un autre contrleur dappels. Le serveur Media Mobicents est quip avec l'implmentation de control de media API conforme au JSR-309 qui permet d'utiliser le serveur Media avec Mobicents SIP Servlet Container. Le Mobicents Media Server comprend la fonction de signalisation de passerelle qui supporte un ensemble complet de protocoles TDM et IP de signalisation. Le serveur multimdia prend en charge les variantes d'accs TDM comme l'ETSI ISUP, PRI. Le serveur multimdia prend en charge la signalisation backhaul sur IP avec M3UA et options SUA. Le serveur Media Mobicents est implment en utilisant le noyau Jboss Microcontainer qui permet d'atteindre le maximum de flexibilit. Il donne la possibilit d'adopter le serveur MultiMedia pour une tache spcifique et/ ou d'tendre les fonctions du serveur de mdias en installant des composants de traitements supplmentaires.
4.2- Buts de Mobicents Media Server

Le Mobicents Media Server a pour but de : Rpondre aux exigences des rseaux convergents sans fil et filaire, DSL et l'accs large bande par cble, ainsi que des rseaux VoIP fixe-mobile convergents partir d'une Media-Gatway unique. Augmenter la flexibilit avec un Media-Gatway supportant une large varit de protocoles de contrle dappel et possdant une architecture qui peut voluer pour rpondre aux exigences des petits fournisseurs de services comme des grandes entreprises.
47
4.3- Architecture de Serveur Medias

Les services multimdias ont jou un rle important dans les rseaux tlphoniques traditionnels bass sur la technique de multiplexage TDM. Comme les rseaux passent des environnements bass IP, les services multimdia y passent aussi, Mobicents Media-Server, en raison de son degr de modularit lev, peut apporter des bnfices au Dveloppeur
d'applications. Nous signalons pour exemple : Si l'interconnexion au rseau tlphonique commut n'est plus ncessaire dans une architecture, l'lment reprsentatif du canal D est tout simplement supprim. Si la Mme application est dploye avec un systme SS7 dans la future, l'lment reprsentatif du canal D est activ.
Figure20 : Architecture de Mobicents Media Server.
L'architecture Media Server suppose que l'intelligence de contrle d'appel se trouve en dehors du serveur de mdias, et est gr par une entit externe. Le Media Server suppose galement que les contrleurs d'appelle utilisent des procdures de contrle tels que MGCP, MEGACO ou MSML[4]. Chaque module de contrle spcifique peut tre branch directement sur le serveur comme une unit standard de dploiement. En utilisant le MicrocontainerJboss pour dployer ces modules de contrle.
4.4-Les Type de Media Supporter par Mobicnets Media Server

Le Serveur Mobicents Media Server ne peut supporter que les fichiers audio. Pour cela MMS est capable de traiter les codecs suivant.
1. G.711 u-Law.
48
2. G.711 A-Law. 3. GSM. 4. Speex -nb. 5. G.729.
Conclusion
La technologie JAIN a un potentiel immense. Elle bouleverse compltement le march des tlcommunications en permettant un accs direct au dveloppement de services par tous les acteurs de tlcommunications dans le monde indpendamment des systmes. Avec le principe adopt par la communaut JAIN qui supprime les diffrences entre rseaux et qui apporte la scurit, il nexiste plus que deux limites la cration de services. Le premier est physique, cest la taille du rseau mondial, le second est limagination. A ce stade, la premire partie est acheve, on a vu comment la plateforme MobiCents avec ces composants JSLEE, et MMS forme un environnement trs riche pour le dveloppement et lintgration des services VoIP. On va par la suite passer la partie la plus valorisante du rapport : ltapedanalyse, de conception et de ralisation du Service VoD.
49
Chapitre 5 Conception et Dveloppement du service

Au cours des dernires annes, il a t constat une augmentation significative de la fourniture de services de tlvision et vido sur IP. Ceci est largement d la chute du cot de bande passante et l'augmentation de la capacit du rseau. IPTV, VoIP et les applications bases sur la prsence devraient tre les principaux services au sein du rseau de prochaine gnration (NGN). Vido la demande permet gnralement aux utilisateurs de slectionner et de
visionner des vidos sur demande. En outre, "Video on Demand" offre aux utilisateurs des outils tels que les contrles magntoscope : (pause, avance et retour rapide). Malgr des revenus encore modestes, le march de la vido la demande progresse danne en anne et semble aborder une phase importante de son dveloppement sous limpulsion de plusieurs facteurs encourageants (nombre dabonns au haut-dbit, succs de lIPTV, habitudes de consommation et offre plutt intressante).
1-
Travaux lis
1.1- IPTV/VoD Standardisation
La normalisation est gnralement ncessaire pour assurer l'interoprabilit entre
diffrentes implmentations et de rduire les temps de cycle d'installation et les cots associs [9]. Il ya trois groupes principaux de travail vers la normalisation de l'IPTV / VoD: ITU-T IPTV Focus Group (FG IPTV), ETSI TISPAN et de l'Open IPTV Forum. La mission de l'IPTV FG est de coordonner et de promouvoir l'laboration de normes IPTV globale prenant en compte les travaux existants des groupes d'tude de l'UIT ainsi que les normes en dveloppement des organisations, forums et consortiums. TISPAN (convergence des tlcommunications et Internet Services et protocoles pour la mise en rseau avance) a t mis en place par l'ETSI (EuropeanTelecommunications Standards Institute) en 2003 en tant qu'organisme de normalisation cl dans la cration de spcifications NGN. Open IPTV Forum est un consortium d'entreprises (environ 60 membres ce jour) qui a labor et publi un standard IPTV ouvert.
50
1.2- IPTV/VoD bas sur l'IMS

Une plate-forme IPTV-IMS est une plateforme de service qui est en mesure de fournir des services IPTV contrls et manipuls par le sous-systme de base IMS. L'architecture IMS-IPTV prsente dans cette section est base sur l'architecture IPTV-IMS de l'ETSI TISPAN. Il est le Framework le plus largement adopt bass sur IMS dans l'volution des normes et de la recherche [10]. La figure 21 montre l'architecture IPTV- IMS de l'ETSI TISPAN . Dans cette architecture, l'quipement utilisateur (UE) intragit avec quatre entits: le Proxy Call Session Control Function (PCSCF), l'IPTV Application Server (AS), le Media Control Function (MCF) et la fonction Media Delivery (MDF). L'quipement de l'utilisateur intragit avec le PCSCF utilisant SIP 3GPP pour la fonction de dcouverte de service (SDF), Service de slection de fonction (SSF) et Service Control Function (SCF). Le SDF est charg de gnrer les informations attaches au service. Le SSF fournit des informations de slection du service, c'est dire une liste des services disponibles. Le SCF effectue trois tches principales, dont l'une est l'autorisation session aux fins de l'octroi ou le refus d'une demande d'utilisation pour l'initialisation d'une nouvelle session ou la modification d'une session existante. Une autre fonction consiste effectuer un contrle de crdit qui signifie qu'il peut faire partie d'une ligne de charge du systme. La troisime fonction est de slectionner des supports de fonctions IPTV. Le MCF est responsable de la slection des rpartiteurs et gre les interactions entre l'UE et MDF. Le MCF gnre galement des informations de taxation, par exemple, pour l'utilisateur final de tarification fond sur le contenu consult. Le MDF fournit le flux de support l'utilisateur.
51
Figure 21: Architecture IPTV/VOD propose par l'ETSI TISPAN
2-Architecture et Implmentation
L'architecture du systme propose est reprsente sur la figure 22. Les diffrents composants sont expliqus ci-dessous:
52
Figure 22 : Architecture du service VoD.
2.1- le client
Le principal protocole de signalisation utilis dans cette mise en uvre est le Session Initiation Protocol (SIP), donc n'importe quelle open-source client SIP pourrait tre modifi pour ajouter un IPTV / VoD interface, ou bien utiliser un client simple avec le lecteur vido VLC. Toutes les demandes des mdias partir du client sont envoyes au serveur dans une requte SIP INVITE avec le format suivant: video_name@vod.mobicents.service . Le serveur rpond par un message 200 OK contenant l'adresse RTSP de la ressource demande. Le client VoD prend alors contact avec le serveur de streaming en utilisant l'adresse RTSP, initiant ainsi la session mdias.
2.2- Le serveur Mobicents

Le serveur d'application mobicents est charg d'authentifi les clients et de grer les demandes des vidos et la liste des vidos, c'est l o se trouve l'intelligence de l'application.
2.3- Serveur de streaming Darwin

Darwin Streaming Server est une solution Open Source qui opre avec succs sur divers systmes dexploitation (Linux, FreeBSD, Mac OS X, Windows, Solaris). Cette
53
dernire permet la diffusion "streaming en Live ou la demande de vos fichiers audio et vido. Simple d'utilisation, le serveur de streaming Darwin (dont la base repose sur celle du serveur Quicktime) permet ainsi de proposer des flux aux formats suivants : H264 (trs avantageux en termes de rapport qualit / bande passante), MPEG 4 et 3gpp (pour la tlphonie mobile), mais aussi mp3 pour "le streaming audio".
2.4- Mobicents media server (MMS)

"Mobicents media server" est responsable de la gestion des medias, il est contrl par le MGCP. MMS gre les flux RTP medias entre lutilisateur et le serveur. Le cas dutilisation de "mobicents media server" est reprsent par la figure ci-dessus :
Figure 23 : Cas dutilisation de Mobicents Media Server
3- Ralisation et prsentation
3.1- Conception du service
Pour la ralisation de ce projet, nous avons dvelopp deux SBB : CallSbb est le SBB "Root" qui reoit le message "SIP INVITE" comme vnement initial et qui dclenche le Service travers le descripteur XML de l'vnement gestionnaire Sbb-jar.xml,
comme indiqu ci-dessous:
54
IVRSbb est le SBB "child" qui sexcute par le SBB CallSbb , c'est lui qui contient le Service.
Lorsque le CallSbb reoit le message "SIP invite" de lutilisateur, la mthode qui sexcute via cet vnement est la suivante :
Le rle de cette mthode est de dclencher le IVRSbb qui contient le service correspondant au
55
message SIP Invite reu par CallSbb. Une fois que le IVRSbb reoit une invite de CallSbb , cette invite est CallCreated comme vnement initial pour cette SBB . Le descripteur XML de l'vnement gestionnaire Sbb-jar.xml
est reprsent ci-dessous :
Lorsque cet vnement est cr via le CallSbb, la mthode qui sexcute est responsable de crer la connexion avec lutilisateur , et aussi denvoyer un demande via MGCP RA vers "Mobicents Media Server" pour tablir un flux RTP avec lutilisateur.
56
Apres connexion entre le client et le serveur Mobicents JSLEE , le client coute la liste des films via le flux RTP cre par MMS. Maintenant le client peut choisir sa vido dsire en envoyant un vnement qui sappelle "Request NOTIFICATION" qui est gnr travers le Botton correspondant au numro de vido La mthode qui sexcute, est la suivante:
Le serveur Mobicents va rpondre avec ladresse RTSP correspondant cette vido via une mthode qui a comme vnement dentre un priode de temps:
57

Pour rsumer le droulement dune demande vido par un utilisateur, la figure ci-dessous illustre le flux dappel pour laccs au service vido la demande:
Figure 24 : Call flow pour le service VoD.
3.2- Atelier de travail

Les outils choisis par les dveloppeurs dpendent essentiellement de la solution architecturale du systme. Ainsi, nous prsentons dans cette partie les outils choisis pour russir le dveloppement de nos Services. En fait, le choix des outils n'est pas alatoire. Nous nous sommes bass sur un ensemble de critres de performance et de fiabilit. Les outils de travail sont comme suit:
3.2.1- le Langage JAVA

Java est le nom d'une technologie qui permet de produire des logiciels indpendants de toute architecture matrielle. En effet, Java prsente un langage informatique de programmation orient objet utilis dans tous les segments industriels majeurs. Il s'tend sur toute une gamme de priphriques, d'ordinateurs et de rseaux. Il est la fois un langage de programmation et un environnement d'excution. Le langage Java a la particularit principale d'tre portable sur plusieurs systmes d'exploitation tels que Unix, Microsoft Windows ou
58
Mac OS... Dans notre projet, toute la plateforme MobiCents est fond sur ce langage, et profite de ces caractristique savoir la portabilit et son indpendance vis--vis du matriel.
3.2.2- SVN
SVN (Subversion) est un outil d'aide au dveloppement de logiciels. Il permet une gestion efficace et riche des diffrentes versions pour un projet logiciel. Cela passe notamment par la mise en place d'un suivi, et par consquent d'un historique, pour l'ensemble des fichiers appartenant au projet. De plus, il se caractrise par son systme centralis pour le partage dinformations. L'un des autres points forts de SVN est de permettre et de favoriser un dveloppement en quipe. En effet, il permet un stockage centralis (SVN fonctionne en mode client/serveur) du code source sur un serveur et gre les accs concurrents sur les fichiers de dveloppement. Ce qui distingue SVN des autres outils de dveloppement collaboratif est la possibilit pour les dveloppeurs d'accder en mme temps un mme fichier pour le modifier, avec une prise en charge des modifications lorsque celles-ci ne gnrent pas de conflits.
3.2.3- Apache Maven

Apache Maven est un outil logiciel libre pour la gestion et l'automatisation de production des projets logiciels Java en gnral et Java EE en particulier. Maven utilise un paradigme connu sous le nom de Project Object Model (POM) afin de dcrire un projet logiciel, ses dpendances avec des modules externes et l'ordre suivre pour sa production. Un lment cl et relativement spcifique de Maven est son aptitude fonctionner en rseau [11]. Dans notre cas, il nous permet de grer l'arborescence du projet et les diffrentes dpendances avec les modules externe de notre projet.
3.2.4- Apache ANT

Ant est un projet open source de la fondation Apache crit en Java qui vise le dveloppement d'un logiciel d'automatisation des oprations rptitives tout au long du cycle de dveloppement logiciel. Dans notre projet, cet outil est fondamentale .En effet il est utilis pour la compilation et le dploiement des services sur le serveur JBOSS.
3.2.5- Lenvironnement de dveloppement Eclipse

Eclipse est un environnement de dveloppement intgr libre extensible, universel et polyvalent, permettant de crer des projets de dveloppement mettant en uvre n'importe quel
59
langage de programmation. Eclipse IDE est principalement crit en Java ( l'aide de la bibliothque graphique SWT, d'IBM), et ce langage, est galement utilis pour crire des extensions grce des bibliothques spcifiques.
3.3-Scnario de dploiement
Afin de mettre en vidence notre travail, on se propose, dans ce paragraphe, de prsenter un scnario qui va prsenter les diffrentes phases de dploiement de chaque composant. tape 1 : Dmarrer le serveur de mdias (MMS) Ceci se fait par la commande Suivant : run.bat
Figure 25 : Dmarrage de Mobicents media server tape 2 : Dmarrer le serveur Pour dmarrer le serveur mobicents JSLEE, il suffit d'aller dans le rpertoire de JBoss et taper la commande suivante : run.bat
60
Figure 26 : Dmarrage du serveur Mobicents JSLEE A la fin du dmarrage du serveur MobicentsJSLEE, nous voyons clairement que le service est bien dployer, la figure suivante montre cet tape :
Figure 27 : Dploiement du service
61
tape 3 : Dmarrer Darwin server streaming Ceci se fait, par les deux commandes :
tape 4 : Accs au service Apres le lancement du client SIP X-lite (voir son configuration dans lannexe B), le client peut accder au service en tapant le numro 555 , un message vocal liste les films disponibles et demande au client de choisir un numro correspondant un film . Dans notre cas le client a choisi le film numro 2.
Figure 28 : Client Sip X-lite Apres le choix du film, le lecteur VLC dmarre automatiquement, et film est visionn comme nous montre la figure ci-dessous.
62
Figure 29 : visionnement du flux mdia
Conclusion
Ce chapitre prsente le cur de ce rapport, du fait quil reprsente notre valeur ajoute, et notre contribution durant ce stage. En effet, nous avons aussi montr les diffrents outils utiliss, aussi nous avons labor la conception des services tape par tape, leurs implmentations ainsi que leur Tests final.
63
Conclusion et perspectives
Dans ce projet, nous avons utilis la plate-forme de communication mobicents pour dvelopper un service vido la demande, qui peut tre intgr dans le rseau IMS en se basant sur les standardisations de l'IPTV-VoD, nous avons aussi discut les diffrentes exigences pour un dploiement russi de ce service. Ainsi, nous avons montr que la solution MobiCents a franchi toute les limites en permettant de fournir une panoplie de services concurrents pour les solutions propritaires. En effet d'autres services peuvent tre prvus utilisant aussi le protocole SIP savoir vido confrence ou bien Mobicents PBX. Ceci dit qu'on peut compter sur l'open source pour composer, tester et valider les services multimdia de nouvelle gnration. Le serveur de streaming est un magasin des vidos et rpond aux demandes vido et en fait n'importe quel client, authentifis ou non authentifi peut accder la vido dans le serveur de streaming, Il y a donc un trou de scurit cette approche. Pour contourner cela nous avons besoin d'un serveur des mdias complet, plutt que d'un serveur de streaming simple. Les futurs travaux seront axs sur le dveloppement d'une architecture scurise permettra aux clients autoriss recevoir des flux mdia partir du serveur multimdia. La conduite de notre projet de fin tude a t une exprience trs particulire et une opportunit relle pour mettre en pratique un ensemble de connaissances acquises durant nos formations. Par ailleurs ce stage, a t un moyen de dvelopper plusieurs qualits aussi bien quau niveau Informatique et Tlcoms quau niveau professionnel. Finalement, les objectifs fixs au dpart ont t en grande partie ralises et nous esprons que les rsultats obtenus trouveront un bon cho.
64
Bibliographie
Bibliographie
[1] 3rd Generation Partnership Project; Technical Specification Group Services and SystemAspects, Service requirements for the Internet Protocol (IP) multimedia subsystem, Stage 2";3GPP TS 23.228, September 2005, http://www.3gpp.org/specs/TS 23.228. [2] J. Rosenberg, et al. SIP: Session Initiation Protocol, RFC 3261, June 2002. [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peter-son, J., Sparks, R., Handley, M., and Schooler, E. SIP : Session InitiationProtocol. RFC 3261 (Proposed Standard), June 2002. Updated by RFCs 3265,3853, 4320, 4916. [8]S. B. Lim and D Ferry, JAIN SLEE 1.0 Specification, final release, Sun Microsystems, Inc.and Open Cloud Limited March 2004 [9] Dikgole V, Ventura N. Video on Demand Service for Next Generation Networks. Proc. South African Telecommunications Networks and Applications Conference, (SATNAC 2008), Wild Coast Sun, South Africa. [10] Wilson P, Neco V. A Direct Marketing Platform for IMS- Based IPTV. Southern African Networks and Applications Conference (SATNAC 2009), Swaziland, 30 August 2 September 2009.
Webographie
[4] MobiCents: http://www.Mobicents.org, https://mobicents.dev.java.net [5] Redhat: http://www.fr.redhat.com/solutions/telco/communications_platform/ [6] JSLEE.org: http://www.jainslee.org [7] Sun Microsystems JAIN: http://java.sun.com/products/jain ;JBoss: http://www.jboss.org [11] Maven: http://maven.apache.org/
65
Annexe A- Installation de Mobicents

La distribution binaire de la plateforme Mobicents Jain Slee peut tre tlcharge partir du site : http://www.mobicents.org/slee/downloads.html
1.
Installation de java jdk
La Plate-forme Mobicents est crit en Java, donc, avant d'excuter n'importe quel serveur Mobicents, on doit disposer de Java RuntimeEnvironment (JRE) ou Java Development Kit (JDK) install dans le systme. En outre, le JRE ou JDK utilis pour excuter Mobicents doit tre la version 5 ou suprieure. On peut tlcharger Sun JDK6 partir du lien :
http://www.oracle.com/technetwork/java/javase/downloads/index.html
1-1- installation sous linux:

Quel que soit le fichier tlcharg, on peut l'installer sur Linux en s'assurant que le fichier est excutable, puis l'excuter:
#chmod +x dk-6u24-linux-i586-rpm.bin #./jdk-6u24-linux-i586-rpm.bin

Installation de Sun / Oracle JDK java, javaws et de javac avec la commande alternatives -install
## java ## alternatives --install/usr/bin/java java /usr/java/jdk1.6.0_24/jre/bin/java 20000 ## javaws ## alternatives --install/usr/bin/javawsjavaws/usr/java/jdk1.6.0_24/jre/bin/javaws 20000 ## javac ## alternatives --install/usr/bin/javacjavac/usr/java/jdk1.6.0_24/bin/javac 20000
On ajoute la ligne suivante au fichier ~.bashrc (ce fichier contient les programmes lancs au dmarrage du systme) :
export JAVA_HOME="/usr/java/jdk1.6.0_24"
Suivie de la commande : # source ~/.bashrc (pour la mise jour de la nouvelle version du fichier) On peut dterminer si JAVA_HOME est dfini sur le systme :
Pour choisir entre les versions java installer dans le systme, on tape la commande :
alternatives --config java # or javac or javaws
66
Enfin, pour assurer qu'on a utilis le bon JDK ou version Java (5 ou plus), et que l'excutable Java est dans notre PATH, on excute la commandejava -versiondans le terminal :
1-2- installation sous Windows :

Il suffit de tlcharger la version binaire et de l'excuter et puis ajouter le chemin du dossier des binaires de la JDK installe (../../bin ) la variable %path% de Windows, ceci avec la commande DOS :Set path=%path% ; C:\Program Files \Java\jdk1.6.0_24\jre\bin
2.
Installation et configuration de Mobicents Jain Slee
Sous linux la procdure dinstallation se rsume au tlchargement, dsarchivage et mise en place de la variable $JBOSS_HOME dans le systme. Voici la suite de commandes taper dans le terminal :
# mkdirmobicents # mv mobicents-jainslee-2.4.0.FINAL-jboss-5.1.0.GA.zip Desktop/mobicents # cd mobicents # unzip mobicents-jainslee-2.4.0.FINAL-jboss-5.1.0.GA.zip # rm mobicents-jainslee-2.4.0.FINAL-jboss-5.1.0.GA.zip

Sous Windows la procdure et plus simplifie car la procdure de dsarchivage se fait en utilisant linterface graphique du systme.
2-1-Configuration de Mobicents Jain Slee .

La configuration se rsume la mise en place d'une variable JBOSS_HOME dans le systme.
67
Pour Windows(en commande DOS):
# Set jboss_home=chemin\au\reprtoire\de\Mobicents\jboss-<version>
Pour Linux : On ajoute la ligne suivante au fichier ~.bashrc :
# export JBOSS_HOME="/home/<username>/<path>/<to>/<install_directory>"
Suivie de la commande :# source ~/.bashrc(pour la mise jour de la nouvelle version du fichier) Une autre mthode pour installer MobiCents consiste compiler soi-mme le code source partir du dpt SVN. Cette seconde mthode donne l'avantage d'accder directement aux dernires nouveauts, fonctionnalits et corrections de bugs. Pour plus de dtails sur comment installer MobiCents partir du code source, se rfrer au site web du projet sur Google Code:
http://groups.google.com/group/mobicents-public. Pour dmarrer mobicents il suffit d'aller dans le rpertoire de jboss et taper la commande :
#./bin/run.sh -c <server profile> -b <IP/host> (pour windows, on utilise run.bat)

Une fois que Mobicents est install et dmarr, allez l'adresse http://127.0.0.1:8080 pour voir linterface web du serveur Jboss .
Figure 30 : Interface dadministration Mobicents.
68
Annexe B Guide dinstallation et dutilisation de MGCP Dmo.

Le MGCP Dmo est un exemple conu pour dmontrer lutilisation des APIs JAIN MGCP, y compris la MGCP RA, dans le mme temps elle dmontre aussi diverses caractristiques et fonctionnalits de Mobicents Media Server (MMS).les MGCP message sont transmises via le protocole UDP.les commandes sont envoyes des adresses IP dfinies dans le domaine du point de terminal (en anglais :Endpoint).Les rponses sont envoys ladresse source cest -dire ladresse IP et le numro de port UDP des commandes. Cette exemple est compose de trois services. Premier Service est compos de CallSbb comme parent, qui coute SIP INVITEcomme unvnementinitial. IVRSbb, RecorderSbbetTTSSbbsont appel ses enfants (children). Et celui qui est responsable de jouer l'annonce et d'coute pour les entres DTMF de l'utilisateur. Selon le DTMF est compos par l'utilisateur, l'annonce correspondante est de nouveau diffus. Pour le tester compose le numro 2010. Deuxime service est compos seulement de ConferenceSbb agissant en tant que root,il coute au SIP INVITE mais il est moins prioritaire que la premier Service. estresponsablepour l'enregistrement vocalde l'utilisateuretde la lectureaprs30 secondes. Pour le tester composer le numro 2011. Si l'utilisateur compos 2013, le Child TTSSbb est cr. TTSSbb envoie le texte Mobicents Media Server (MMS) et MMS lit le discours correspondant ce texte l'utilisateur. Troisimeserviceestcomposseulement deConfLegSbbagissanten tant que root. Il coute pour Custom Event envoyer par ConferenceSbb quand un participant rejoint la confrence. Pour le tester composer 2012.
1. Les besoins
Pour tester ce dmo on a besoin de (ces besoins sont pour Windows et Linux) : Mobicents JAIN SLEE Server Mobicents Media Server.
69

Maven apache. Sip 11 RA & MGCP RA. Le code source de Mobicents JAIN SLEE MGCP Dmo.
1-1- Mobicents JAIN SLEE Server.

Pour Mobicents JAIN SLEE Server on a utilis la version 2.3.0.FINAL .vous pouvez le tlcharger daprs ce lien. http://sourceforge.net/projects/mobicents/files/Mobicents%20JAIN%20SLEE%20Server/2.3. 0.FINAL/
1-2- Mobicents Media Server.

Pour Mobicents Media Server vous pouvez soit tlcharger une version daprs le site web de Mobicents ou bien dutiliser la version qui vient avec Mobicents jain slee Server qui se trouve dans le dossier extra.
1-3- Maven apache.

Cet outil est utilis pour construire le service dployer pour la tlcharger consult le site web http://maven.apache.org qui contient tous les informations sur lutilisation de cette outil.
1-4- Sip 11 RA & MGCP RA.

Ce sont deux ressource dadaptation utiliss pour le service afin dtre en mis niveau et capable dtre dployer par le serveur JBoss pour quon puisse valuer ses fonctionnalits. SIP 11 RA et MGCP RA vient avec la distribution Mobicents JAINSLEE Server dans le dossier ressources
1-5- Le code source de Mobicents JAIN SLEE MGCP Dmo.
Utilisateur Linux Pour tlcharger le code source de ce Dmo dans le terminal.

[usr]$svn co http://mobicents.googlecode.com/svn/tags/servers/jain-
70
slee/2.x.y/examples/mgcp-demo/2.4.0.CR1 slee-exemple-mgcp demo2.4.0.CR1. Aprs on va utiliser Maven pour construire lunit dployable.pour cela on va se dplacer vers le dossier slee-exemple-mgcpdemo2.4.0.CR1 . qui contient les fichiers source de MGCP Dmo tlcharg.
[usr]$ cd slee-example-mgcp-demo-2.4.0.CR1 [usr]$ mvninstall
Une fois le processus termin, vous devriez avoir le fichier jar. Ce fichier se trouve dans
slee-example-mgcp-demo-2.4.0.CR1/slee/services-du/target/zmgcp-demo-services-DU2.4.0.CR1
Utilisateur Windows. Les mmes procdures que pour lutilisateur Linux sauf la dmarche car il doit tlcharger le code source manuellement partir de site web. http://mobicents.googlecode.com/svn/tags/servers/jainslee/2.x.y/examples/mgcpdemo/2.4.0.CR1
2. Configuration du SIP Client.

Pour tester ce dmo on doit avoir un client Sip dans notre cas, on a choisi le client sip X-lite PRO, mais avant de passer tester les fonctionnalits de ce dmo il faut la configurer. Pour la configuration il faut tout simplement voir les images. Pour default:
71
Figure 31 : Configuration de X-lite pourDefault Pour Network. Pour avoir accs network dans x-lite appuyer sur configuration puis System Settings, network.
72
Figure 32 : Configuration x-lite pour Network
3. Dploiement du service.
Pour dployer le service afin de le tester .on va suivre les tapes suivant. 1. Copier le fichier jar zmgcp-demo-services-DU-2.4.0.CR1 et aussi le fichier qui contient le media mgcp-demo-audio.war qui se trouve dans lemplacement suivant. slee-example-mgcp-demo-2.4.0.CR1/web/target/mgcp-demo-audio.war
Dans le rpertoire Mobicents JAIN SLEE Server. Home_MobicentsJAINSLEEServer/jboss5.1.0.GA/server/default/deploy 2. Copier les deux fichiers MGCP RA et SIP 11 RA aussi dans le mme rpertoire que mgcp-demo-audio.war et zmgcp-demo-services-DU-2.4.0.CR1 3. Lancer Mobicents Media Server. 4. Lancer Mobicents JAIN SLEE Server. 5. Lancer X-lite et composer vos numros.
73
Figure 33 : dploiement de MGCP Dmo
74

Raport Pfe Benali Darbaoui

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Raport Pfe Benali Darbaoui

Uploaded by

Copyright:

Available Formats

Dveloppement du Service VoD sous La Plateforme Mobicents NSN

Noms et prnoms des lves Ingnieurs stagiaires :

Omar Benali : omar.benali86@gmail.com Imad Darbaoui : darbaoui@gmail.com

Dveloppement du service vido la demande (VoD) sous la plateforme mobicents

M. Fouad Lahjomri lENSA de Tanger M. Naoufal Raissouni lENSA de Ttouan

Dveloppement du Service VoD sous La Plateforme Mobicents NSN

Dveloppement du Service VoD sous La Plateforme Mobicents NSN

Dveloppement du Service VoD sous La Plateforme Mobicents NSN

Table des matires

Dveloppement du Service VoD sous La Plateforme Mobicents NSN

Architecture et considrations d'implmentation....55

Dveloppement du Service VoD sous La Plateforme Mobicents NSN

Conclusion et perspectives....67 Bibliographie.....68 Annexe A......69 Annexe B... ..72

Dveloppement du Service VoD sous La Plateforme Mobicents NSN

Liste des figures et des tableaux

Dveloppement du Service VoD sous La Plateforme Mobicents NSN

Dveloppement du Service VoD sous La Plateforme Mobicents NSN

Chapitre 1 Contexte gnral du projet

1. Lentreprise d'accueil : Nokia Siemens Network

Dveloppement du Service VoD sous La Plateforme Mobicents NSN

1.2- La stratgie de Nokia Siemens Networks.

Dveloppement du Service VoD sous La Plateforme Mobicents NSN

1.3- Secteur dactivit de NSN

Dveloppement du Service VoD sous La Plateforme Mobicents NSN

quipe de dploiement et dintgration :

2. Projet et droulement du stage

Dveloppement du Service VoD sous La Plateforme Mobicents NSN

2.2- Objectif du projet et le droulement du stage

Dveloppement du Service VoD sous La Plateforme Mobicents NSN

Figure 1: Diagramme de GANTT du projet

2.3- Intrt du projet

Dveloppement du Service VoD sous La Plateforme Mobicents NSN

Chapitre 2 Les rseaux NGN

2. Larchitecture en couche NGN

Dveloppement du Service VoD sous La Plateforme Mobicents NSN

Dveloppement du Service VoD sous La Plateforme Mobicents NSN

Figure 2: Architecture de rseau NGN.

3. Les entits fonctionnelles au cur du rseau

3.1- La Media Gateway (MG)

Dveloppement du Service VoD sous La Plateforme Mobicents NSN

3.2- La Signalling Gateway (SG)

3.3- Le serveur dappel

4. Les Familles protocolaires

Dveloppement du Service VoD sous La Plateforme Mobicents NSN

5. NGN Multimedia: IMS.

Dveloppement du Service VoD sous La Plateforme Mobicents NSN

5.2- Architecture de lIMS.

Dveloppement du Service VoD sous La Plateforme Mobicents NSN

Protocoles dfinis dans larchitecture IMS.

Dveloppement du Service VoD sous La Plateforme Mobicents NSN

Chapitre 3 Le Protocol SIP

Dveloppement du Service VoD sous La Plateforme Mobicents NSN

Figure 4: Entits dun rseau SIP

2.1- Agent utilisateur (UA, User Agent).

Dveloppement du Service VoD sous La Plateforme Mobicents NSN

2.2- SIP Serveurs.

Dveloppement du Service VoD sous La Plateforme Mobicents NSN

Dveloppement du Service VoD sous La Plateforme Mobicents NSN

Tableau 1: Les six mthodes du noyau SIP.

3.2-Extension des mthodes SIP

Dveloppement du Service VoD sous La Plateforme Mobicents NSN

3.3- Rponses SIP

Tableau 2: Rponses SIP

Dveloppement du Service VoD sous La Plateforme Mobicents NSN