Raport Pfe Benali Darbaoui

5/12/2018 Raport Pfe Benali Darbaoui - slidepdf.com

http://slidepdf.com/reader/full/raport-pfe-benali-darbaoui 1/74

Développement du Service VoD sous La Plateforme Mobicents NSN

1

AVANT-PROPOS

Noms et prénoms des élèves – Ingénieurs stagiaires :

Omar Benali : [email protected] Imad Darbaoui : [email protected]

Intitulé de travail :

Développement du service vidéo à la demande (VoD) sousla plateforme mobicents

Etablissement d’accueil : NOKIA SIEMENS NETWORK.

Lieu : Rue Abou Inane, Rabat.

Téléphone : 0537219040Fax : 0537261531

Superviseurs du projet : M. Fouad Lahjomri à l’ENSA de Tanger

M. Naoufal Raissouni à l’ENSA de Tétouan




2

Résumé

L'industrie des télécommunications est en plein expansion. Introduire ou intégrer un

service dans le marché s'avère de plus en plus difficile vue les contraintes d'infrastructure et

les normes propriétaire qu'il faut respecter d'autant plus que les coûts de production

deviennent de plus en plus considérables. C'est dans cette vision que l'IMS s'est introduit dans

le marché. En effet, avec son architecture répartie 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 sophistiqués (push-to-talk, messagerie instantanée, conférence

audio et vidéo, jeux en ligne,etc). Ainsi les serveurs d'application proposent un environnement

adéquat pour le déploiement de ces services tout en utilisant des solutions open source

indépendamment de l'infrastructure qui est mise en place.

Dans ce contexte, notre travail consiste à concevoir et développer un service vidéo à la

demande (VoD) en se basant sur la plate-forme de communication mobicents .

Mots clés: NGN, IMS, Mobicents , JAIN SLEE, SIP, VoIP, VoD, RTP,RTSP, MGCP.




3

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. Infact, 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.




4

Table des matièresIntroduction générale………………………………………….………………………………11

Chapitre 1 : Contexte général du projet………………………………………………………12

1. L’entreprise d'accueil : Nokia Siemens Network……….…………………………….…12

1.1- Présentation de l’organisme d’accueil.…………….……………………...12

1.2- La stratégie de Nokia Siemens Networks..………………………………..13

1.3- Secteur d’activité de NSN………………………………………………...14

2. Présentation du projet et déroulement du stage………………………………………....15

2.1- contexte du projet…………………………………………………………15

2.2- L’objectif du projet et le déroulement du stage…………………………...16

2.3- L’intérêt du projet………………………………………………………....17

Chapitre 2 : Les réseaux NGN………………………………….…………………………….18

1. Introduction………………………………………………………………………………..18

2. L’architecture en couche NGN …………………………………………………………....18

3. Les entités fonctionnelles au cœur du réseau……………………………………………....20

3.1- La Media Gateway (MG)……………....………………………………....20

3.2- La Signalling Gateway (SG)………….........……………………………..20

3.3-

Le serveur d’appel………………………………………………………...21 4. Les Familles protocolaires………………………………………………………………21

5. NGN Multimedia: IMS.………………………………………………………………...22

5.1- Introduction……………………………………………………………….22

5.2- Architecture de l’IMS…………………………………………………….23

5.2-1. Structuration en couche de l’architecture IMS.…..……… 23

5.2-2. Protocoles définis dans l’architecture IMS.……….………24

Chapitre 3 : Le Protocole SIP…………………………………………………………………25

1. Introduction.………………………………………………………………….……….25

2. SIP Composants………………………………………………………………………26

2.1- Agent utilisateur…………………………………………………….….....26

2.2- SIP Serveurs………………………………………………………………27

3. Messages SIP……………………………………………………………………………28

3.1- Principales méthodes SIP…………………………………………….…...28

3.2- Extension des méthodes SIP…………………………….………………..29

3.3- Réponses SIP…………………………………………………….………..30




5

4. Protocole RTSP……………………………………………………………………...…..31

4.1- RTSP et les protocoles de transport………………...……………………..32

4.2- RTP et RTCP………………………………………………………….…..32

4.3- RTSP et HTTP…………………………………………………...………..32

4.4- Fonctionnalités de RTSP……………………………...…………………..33

4.5- Paramètres de RTSP………………………………………..……………..33

Chapitre 4 : La Plateforme Mobicents………………………………………………………..35

1. Introduction………………………………………………………………………….....35

2. La Technologie JAIN……………………………………………………….…………..36

2.1- Avantages et intérêts de JAIN……………………………………………..37

2.2- Les couches d’abstractions…………………………….…………………..38

2.3- Les différentes APIs de JAIN………………………..……………………..39

2.4- JAIN SIP API………………………………………………………...……..41

3. JAIN SLEE……………………………………………………………………………....42

3.1- Introduction……………………………………………………...…………..42

3.2- La spécification de JAIN SLEE……………………………………………..42

3.3- Les composantes de bases du JAIN SLEE…………………………………..44

3.3.1- L’adaptateur de ressource………….……………...………….44

3.3.2- Le routeur d’évènements………………………………..……45

3.3.3- L’évènement…………………………………………………..46

3.3.4- Les services et Les profils………………………….…………46

3.3.5- L’activité et le contexte d’activité……………….……………47

3.3.6- Composants SBB (Service Building Block) ………...………47

3.3.7- Composants de gestion et de contrôle 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 développement du service………………………………………..53

1. Travaux liés…………………………………………………………………………...53

1.1- IPTV/VoD Standardisation……………………..………………………..53

1.2- IPTV/VoD basé sur l'IMS………………………….……………………..54

2. Architecture et considérations d'implémentation……………………..………………..55




6

2.1- le client……………………………………….……….…….…………….56

2.2- Le serveur Mobicents……………………….………..……….…………..56

2.3- le serveur de streaming Darwin……………..…….………….…………..56

2.4- Mobicents media server (MMS)………………….………….…………...57

3. Réalisation et présentation……………………………………………………….……..57

3.1- Conception du service………………………………...…………………..57

3.2- 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. L’environnement de développement Eclipse…………………62

3.3- Scénario…………………………………………………………………..63

Conclusion et perspectives…………………………….………………………….…………..67

Bibliographie……………………………….………………………………………..………..68

Annexe A…………………..……………………………………………..…………………..69

Annexe B…………………………………………………………... ………………………..72




7

Liste des figures et des tableaux

Figure 1: Diagramme de GANTT du projet…………………………………………….17

Figure 2: Architecture de réseau NGN………………………………………………….20

Figure 3: Architecture de l’IMS…………………………………………………………23 Figure 4: Entités d’un réseau SIP………………………………………………………..26

Figure 5: Exemple de message SIP…………………………………………………...…28

Figure 6: Etablissement et libération de session SIP…………………………………....31

Figure 7 : Exemple d’une session RTSP…………………………………………………34

Figure 8: Architecture de Mobicents……………………………………………………35

Figure 9: Architecture de la plateforme de communication Redhat/JBoss…………….36

Figure 10: Architecture de Base de JAIN………………………………………………..37

Figure 11: Architecture en couche de JAIN……………………………………………..39

Figure 12: Différents APIs de JAIN……………………………………………………..40

Figure 13: Architecture JAIN SIP……………………………………………………….41

Figure 14: Les différentes JAIN SIP API………………………………………………..42

Figure 15: Architecture de Jain SLEE…………………………………………………...44

Figure 16: Rôle de l’adaptateur de ressource…………………………………………….45

Figure 17: profile et table de profile……………………………………….……………..46

Figure 18: Activité et contexte d’activité………………………………….……………..47

Figure 19: Flux d’événements dans un SBB……………………………….…………….48

Figure 20 : Architecture de Mobicents Media Server……………………….…………….51

Figure 21 : Architecture IPTV/VOD proposée par l'ETSI TISPAN……….……………..55

Figure 22 : Architecture du service VoD…………………………………….……...……56 Figure 23: Cas d’utilisation de Mobicents Media Server………………………………...57

Figure 24 : Call flow pour le service VoD.………………………………….…………….61

Figure 25 : Démarrage de Mobicents media server………………………………………63

Figure 26 : Démarrage du serveur Mobicents JSLEE……………………………………64

Figure 27 : Déploiement du service……………………………………………………….64

Figure 28 : Client Sip X-lite……………………………………………………………….65

Figure 29 : Lecteur du flux média…………………………………………………………65

Figure 30 : Interface d’administration Mobicents.………………………….……………..71

Figure 31 : Configuration de X-lite pour Default…………………………………………74

Figure 32 : Configuration x-lite pour Network ……………………………………………75

Figure 33 : déploiement de MGCP Démo…………………………………………………76

Tableau 1: Les six méthodes du noyau SIP.………………………………………….…...29

Tableau 2: Réponses SIP……………………………………………………………….…30

Tableau 3: Comparaison entre le système de communication et le système d’entreprise...43




8

Introduction générale

Le monde de télécommunications est en croissance rapide et le marché de

télécommunications s’oriente de plus en plus vers la convergence fixes et mobiles, vers un

réseau tout IP. Le concept clé pour assurer cette convergence est le concept IMS (IP

Multimédia Subsystem) qui permet l’offre des services pour les deux réseaux fixes et mobiles.

L’environnement de service des opérateurs de télécommunications est aujourd’hui

particulièrement complexe avec l’intégration de services très divers provenant du monde

Internet. Cette complexité provient du mariage entre les télécommunications et

l’informatique. Le réseau intelligent autour du réseau téléphonique a longtemps été le vecteur

de cette intégration et a permis un certain succès à ce mariage avec l’arrivée de services

comme la carte prépayée ou le numéro vert. Cependant, modifier un service ou créer un

nouveau service accessible par le réseau téléphonique nécessite la modification de tous les

nœuds du réseau qui sont des commutateurs très complexes.

De plus, les fournisseurs de services ont toujours tendance à développer des services

propriétaires suivant leurs propres normes. Ces contraintes rendent les modifications et la

création de nouveaux services difficiles et très longues dans le contexte d’un marché très

concurrentiel. D’ailleurs, ces services sont très coûteux du fait de la complexité et du nombre

de commutateurs à modifier dans le réseau.

Dans ce contexte, NSN a été décidé 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

présenté dans ce mémoire de fin d'étude porte sur la documentation et la compréhension de

la l'architecture et la logique métier de Mobicents ainsi que la conception et le

développement d'un service video à la demande (VoD).Le premier chapitre consiste à présenter le contexte général dans lequel s'est déroulé le

projet. Le deuxième chapitre décrit les réseaux de la nouvelle génération et leurs évolutions

vers le concept IMS. Le troisième chapitre présente 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 contrôle de session et le contrôle de service. Le quatrième chapitre traitera du contexte

technique : les concepts de Mobicents et l'architecture JAINSLEE. Le cinquième chapitre

sera réservé à la phase du développement des services et leurs implémentations. Nous

terminerons notre travail par une conclusion et perspective.




9

Chapitre 1

Contexte général du projet

Dans ce chapitre, nous allons présenter l'entreprise d'accueil, Nokia Siemens Network.

Ensuite nous exposerons le sujet, l'objectif et le déroulement du stage.

1. L’entreprise d'accueil : Nokia Siemens Network

1.1- Présentation de l’organisme d’accueil.

NSN est issue d'une fusion stratégique opérée en juin 2006 entre Siemens Networks et

Nokia Networks Business Group. La nouvelle structure (une joint-venture détenue à 50-50

par les deux groupes) a donné naissance à un géant mondial des réseaux de

télécommunications qui a pour ambition de connecter pas moins de 5 milliards de personnes à

l'horizon 2015. Autant dire connecter la population de la planète.

Cette nouvelle société, Nokia Siemens Networks est le leader en fourniture de

solutions de communication et d'intégration de services pour la téléphonie 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 combinés de 17.1

milliards €, durant l'exercice 2006, font de Nokia Siemens Networks l'une des plus grandes

sociétés d'infrastructure de télécommunications. Nokia Siemens Networks compte 600 clients,

elle opère dans 150 pays. Son siège 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 développés séparément

dans le Maroc depuis 1988 pour ce qui concerne les transmissions et à partir de 1994 pour des

réseaux mobiles et fixes. L'antenne marocaine, qui est dirigée par Youssef Chraïbi, directeur

pour le Maroc de Nokia Siemens Networks (douze années d'expérience chez Nokia

Networks), est basée à 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 régionaux 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 département CSI de NSN qui fait l'intégration de services. En effet, l'ingénierie




10

des services devient un domaine stratégique de par l'avènement des réseaux large bande à

intégration de services et des communications mobiles qui permettent d'imaginer un nombre

de services très important. De ce point, les acteurs sur le marché des télécommunications

créent tout un département au sein de leurs entreprises pour répondre à cette croissance

considérable de la demande d’invention de nouveaux services de communication.

Ces derniers ont besoin d'être intégrés dans un réseau déjà existant qui fonctionne

suivant un ensemble de règles et sous différents protocoles de communication. Le métier

d'intégration élabore une documentation écrite détaillée sur les étapes et les procédures à

respecter, par les différents intervenants. Il associe une grande capacité de production à la

flexibilité de ses chaînes qui s'adaptent aux produits, aux délais et aux quantités. A tout

moment de la production, l'intégration réalise des "auto-tests" pour valider la qualité du travail

et vérifier la compatibilité et l'interopérabilité du nouveau système avec les plateformes et les

composants déjà déployés. Aussi, une simple intégration nécessite un ensemble de tests sur la

capacité, la surcharge du système, les bugs et les erreurs possibles qui peuvent être produites

lors de la mise en place de la solution en production.

1.2- La stratégie de Nokia Siemens Networks.

Selon Simon Beresford-Wylie, Directeur général de Nokia Siemens Networks, «On

commence déjà à être l'un des leaders de l'industrie, nous avons un objectif bien clair: devenir

numéro UN. Nous voulons être numéro UN en tant que fournisseur des réseaux de

communication à nos clients, la société numéro UN à connecter le monde via des modules de

connections pour les communications fixes et mobiles, et numéro UN en tant que poste de

travail pour nos employés. Nous voulons aussi être reconnus pour nos hautes valeurs d'éthique

et d'intégrité. » .

« Puisque le marché change et nos clients font face à des challenges commerciaux

complexes, nous aurons aussi besoin de changer vers Nokia Siemens Networks » a déclaré

Mr. Guenter Landers, Directeur de la Sous-région Afrique du Nord Est & Ouest Nokia

Siemens Networks. « Apporter l'Internet et la connectivité à une large majorité de gens d'ici

l'an 2015 nécessitera de trouver de nouveaux moyens pour réduire les frais de connections,

particulièrement dans les marchés très prometteurs. Nokia et Siemens ont annoncé lors de la

création de la nouvelle société le 19 Juin 2006, qu'ils rechercheront des estimations de

synergies de coûts de 1.5 milliards d'Euros par an d'ici l'an 2010 afin de construire une Nokia

Siemens Networks forte et compétitive. ». Ainsi, c'est dans cette logique que le groupe a




11

construit un institut international totalement consacré à la formation afin de promouvoir son

expertise technique et en matière de gestion de ses professionnels.

1.3- Secteur d’activité de NSN

L'infrastructure des télécommunications continuera à avoir le rôle majeur à jouer dans

la capacité de Nokia Siemens Network et dans son aptitude de créer, fournir et livrer les

meilleures solutions de bout en bout dans le monde pour les clients. Elle a ainsi cinq unités de

travail: accès sans fil, accès à large bande, noyau technique et applications, IP/Transport, et

Systèmes de Soutiens des Opérations. Ces unités de travail fournissent une large gamme de

produits et d'applications pour les réseaux fixes, mobiles et convergents. En outre, la nouvelle

société répond à une demande de services toujours croissante à travers son « Unité de

Services ».Le portefeuille des produits proposés couvrira toutes les gammes de produits, services,

solutions ayant relation avec l'infrastructure du réseau de télécommunications. Il conduira à la

convergence IP et fournir des solutions de bout en bout, pour répondre aux besoins des clients

mondiaux.

Nokia Siemens Networks Maroc collabore étroitement avec Maroc Telecom; premier

opérateur mobile et fixe au Maroc. Elle fournit principalement à son client Maroc Telecom,

les équipements Nokia Siemens Networks du réseau radio GSM34 ainsi que les prestations de

services associés qui sont :

Recherche et négociation des sites, constructions des sites et implémentation

d'infrastructure GSM pour les projets clés en main totale.

Implémentation de l'infrastructure GSM pour les projets clés en main partiels.

Drive-test et entretien de la qualité de service du réseau pour le contrat

d'optimisation radio.

Redéploiement 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 concentrée autour de

trois pôles principaux :

Le Network Planning :

Il représente le cœur du travail de Nokia Maroc. Il s'occupe de la partie technique:

(Planification du réseau, dimensionnement, optimisation et maintenance du réseau BSS36 de




12

l'opérateur client). Le groupe de Network Planning est divisé en zones géographiques, c'est à

dire, une équipe s'occupant du projet de Casablanca, une autre de celui de Rabat et une

troisième pour la zone Nord Est. Ces différentes équipes sont supervisées par un manager.

Équipe commerciale :

Cette équipe se charge de toutes les procédures financières, l'établissement des comptes de

Nokia Siemens Networks et la planification du budget établi tous les six mois.

Équipe de déploiement et d’intégration :

Cette équipe se charge de négocier l'installation des nouveaux sites avec les propriétaires dans

le cas des contrats TK, de la supervision de la construction des sites et de la fourniture dumatériel. Elle se charge aussi de la mise en place et l'implémentation des services à valeurs

ajoutées pour les clients selon les marchés conclus.

2. Projet et déroulement du stage

2.1- contexte du projet

IMS est acceptée par la plupart des acteurs de l'industrie des télécommunications

comme l'architecture de la convergence des réseaux de prochaine génération. L'IMS joue le

rôle de couche logique intermédiaire entre, d'un côté, les terminaux et les réseaux de transport

orientés IP et, de l'autre, les services applicatifs télécoms. Elle met en œuvre certaines

fonctions techniques (mécanismes de contrôle et signalisation) entre différents équipements

au cœur d'un réseau d'opérateur, en recourant au protocole de signalisation SIP standardisé par

l’IETF.

Aujourd’hui, les services IPTV et vidéo à la demande (VoD) sont mis en place par les

fournisseurs de services à leurs abonnés. Les fournisseurs de services qui ont l'intention

d'évoluer vers un réseau basé sur l'IMS qui offre des services comme l'IPTV et la vidéo à la

demande, devrait évoluer l'architecture de telle sorte que l'IPTV et VoD soient proposés

comme des services de communication multimédia sur leur réseau IMS.

Instinctivement, cette combinaison de l'IPTV / VoD et l'IMS semble être un bon ajustement,

l'IMS est conçue pour fournir des services de communication multimédias, et IPTV / VoD

sont des services de communication multimédia.

La solution VoD est une harmonie évidente dans l'architecture IMS, car il est en soi un




13

service de communication point à point basée 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 réseau IMS pour s'adapter au service

IPTV est moins évident par rapport au service VoD.

L'émergence du réseau de prochaine génération (NGN) a créé le besoin de

convergence conduit par les SDP et les APIs Java qui se trouvent à l'avant-garde du

développement d'applications pour les opérateurs télécoms. Les spécifications des APIs telles

que JAIN (Java Advanced Intelligent Network) et Java Téléphonie API ont équipé les

développeurs d'applications pour les systèmes et les réseaux NGN.

2.2- Objectif du projet et le déroulement du stage

L'objectif de ce projet est le développement 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 réseaux de nouvelle génération: (convergence

fixe/mobile, convergence vers le tout IP,…). L'objectif du stage est de maîtriser mobicents et

notamment la solution VOIP qu'il offre, pour voir comment l'open source peut offrir, à travers

le développement des services via SIP, une alternative commerciale à moindre coût. Cette

plateforme de services peut donc être une solution robuste et performante adoptée par les

opérateurs dans les réseaux intelligents de nouvelles générations.

Ce stage a été programmé pour une durée de trois mois .Comme on peut le voir sur le

diagramme suivant, le travail a été réparti en 6 grandes étapes :




14

Figure 1: Diagramme de GANTT du projet

2.3- Intérêt 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 propriétaires.

Ainsi, il s'avère intéressant d'étudier les solutions lowcost comme étant une autre alternative

offrant des services multimédia.

Conclusion

Le long de ce chapitre nous nous sommes intéressés à l'organisme d'accueil NSN, ses

activités principales ainsi qu'à son plan stratégique. Ensuite nous avons situé le projet du

stage, son objectif et son contexte technique. Dans ce qui suit, nous allons dans les réseaux de

prochaine génération, et leur évolution IMS.




15

Chapitre 2

Les réseaux NGN

1. Introduction

L’évolution progressive du monde des télécoms vers des réseaux et des services de

nouvelle génération est aujourd’hui une tendance forte qui suscite l’intérêt d’une majorité

d’acteurs. Elle résulte de la conjonction d’un ensemble de facteurs favorables dont :

• les évolutions profondes du secteur des télécommunications ;

• le développement de gammes de services nouveaux ;

• les progressions technologiques d’envergure dans le domaine des réseaux de données.

Pour s’adapter aux grandes tendances qui sont la recherche de souplesse d’évolution du

réseau, la distribution de l’intelligence dans le réseau, et l’ouverture à des services tiers, il est

nécessaire de s’adapter à une évolution vers un nouveau modèle de réseaux et de services

appelé NGN (NextGeneration Networks).

Les NGN sont basés sur une évolution progressive vers le « tout IP » et sontmodélisées en couches indépendantes dialoguant via des interfaces ouvertes et normalisées.

Les réseaux de télécommunications traditionnels évolueront vers un modèle ouvert, distribué,

fortement basé sur le protocole IP et la transmission en mode paquet en général. Cette

évolution technologique, tout en étant transparente pour les utilisateurs, se fera de manière

progressive pour les opérateurs. .

Dans ce chapitre nous présentons une description de l’ensemble de ces nouveaux

concepts NGN. Il inclut aussi une synthèse des évolutions technologiques majeures et le détail

des nouveaux concepts liés aux NGN.

2. L’architecture en couche NGN

Une des caractéristiques principales du modèle NGN est de dissocier les services des

réseaux physiques. Chaque élément fonctionnel d'une couche peut être offert séparément et

peut évoluer indépendamment. Les éléments fonctionnels qui constituaient un commutateur

classique ont été séparés suivant leur fonction primaire en couches différentes : une coucheavec les fonctions de transport, une couche avec les fonctions de contrôle de service, une




16

couche de management, service et application.

Ainsi l’architecture NGN se caractérise par :

Une couche Accès : qui permet l’accès de l’utilisateur aux services via des supports de

transmission et de collecte divers : câble, cuivre, fibre optique, boucle locale radio, xDSL,

réseaux mobiles.

Une couche de transport en mode paquet (ATM : Asyncronous Transfert Mode, IP : Internet

Protocol ...):Cette couche gère l’acheminement du trafic vers sa destination. En bordure du

réseau de transport, des « media gateways » et des « signallinggateways » gèrent

respectivement la conversion des flux de données et de signalisation aux interfaces avec les

autres ensembles réseau ou les réseaux tiers interconnectés.

Une couche Contrôle indépendante des ressources physiques : Elle se compose de

serveurs dits « softswitch » gérant d’une part les mécanismes de contrôle d’appel (pilotage de

la couche transport, gestion des adresses), et d’autre part l’accès aux services (profils

d’abonnés, accès aux plates-formes de services à valeur ajoutée).

Une couche Services :Elle regroupe les plates-formes d’exécution de services et de diffusion

de contenus. Elle communique avec la couche contrôle du cœur de réseau via des interfaces

ouvertes et normalisées, indépendantes de la nature du réseau d’accès utilisé. Les services et

contenus eux-mêmes sont par ailleurs développés avec des langages convergents et unifiés.

Des interfaces ouvertes et standardisées entre les différentes couches : Les éléments

fonctionnels communiquent via des interfaces ouvertes qui peuvent être des protocoles

normalisés.

L'externalisation des fonctions de contrôle de la couche de transport : Les

principales caractéristiques des réseaux NGN résident dans l’utilisation d’un réseau unique de

transport en mode paquet (IP, ATM,…) et de la séparation des couches de transport des flux et

de contrôle des communications.




17

Figure 2: Architecture de réseau NGN.

3. Les entités f onctionnelles au cœur du réseau

On distingue entre deux types d’équipements actifs dans le cœur du réseau NGN,

lesServeurs de contrôle d’appel dits Soft Switch ou Media Gateway Controller, les

équipements de médiation et de routage dits Media Gateway.

3.1- La Media Gateway (MG)

Les Gatewaysjouent un rôle essentiel en assurant non seulement l'acheminement du

trafic, mais aussi l'inter fonctionnement avec les réseaux externes et avec les divers réseaux

d'accès. La Media Gateway est située au niveau du transport des flux média entre le réseau

RTC et les réseaux en mode paquet, ou entre le cœur de réseau NGN et les réseaux d'accès.

Elle a pour rôle le codage et la mise en paquets du flux média reçu du RTC et vice versa

(conversion du trafic TDM IP) et aussi la transmission, suivant les instructions du Media

Gateway Controller, des flux média reçus de part et d'autre.




18

3.2- La Signalling Gateway (SG)

La fonction Signalling Gateway a pour rôle de convertir la signalisation échangée entre

le réseau NGN et le réseau externe interconnecté selon un format compréhensible par les

équipements chargés de la traiter, mais sans l'interpréter (ce rôle étant dévolu au Media

Gateway Controller). Notamment, elle assure l'adaptation de la signalisation par rapport au

protocole de transport utilisé. Cette fonction est souvent implémentée physiquement dans le

même é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 d’appel

Dans un réseau NGN, c'est le MGC qui possède « l'intelligence ». Il gère:

• L'échange des messages de signalisation transmise de part et d'autre avec les passerelles

de signalisation, et l'interprétation de cette signalisation.

• Le traitement des appels qui s’opère 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

réseau, etc.

• La réservation des ressources dans le MG et le contrôle des connexions internes au MG

(commande des Media Gateways).

Il apparait donc dans l'architecture des réseaux NGN que le serveur d'appel, aussi appelé Soft

Switch ou Media Gateway Controller (MGC) est le nœud central qui supporte l'intelligence de

communication.

4. Les Familles protocolaires

La convergence des réseaux voix/données ainsi que le fait d'utiliser un réseau en mode

paquet pour transporter des flux multimédia, ayant des contraintes de « temps réel », a

nécessité l'adaptation de la couche Contrôle. En effet ces réseaux en mode paquet étaient

généralement utilisés comme réseau de transport mais n'offraient pas de services permettant la

gestion des appels et des communications multimédia. Cette évolution a conduit à l'apparition

de nouveaux protocoles, principalement concernant la gestion des flux multimédia, au sein de

la couche Contrôle.

On peut classer les protocoles de contrôle en différents groupes:

• Les protocoles de contrôle d'appel permettant l'établissement, généralement à l'initiative




19

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 développé à

l'IETF.

• Les protocoles de commande de Media Gateway qui sont issus de la séparation entre les

couches Transport et Contrôle permettent au Soft Switch ou Media Gateway Controller de

gérer les passerelles de transport ou Media Gateway. MGCP (Media Gateway Control

Protocol) de l'IETF et H.248/MEGACO, développé conjointement par l'UIT et l’IETF, sont

actuellement les protocoles prédominants.

• Les protocoles de signalisation entre les serveurs de contrôle (ou Media Gateway

Controller) permettant la gestion du plan contrôle au niveau du cœur de réseau avec des

protocoles tels que BICC (BearerIndependant Call Control), SIP-T (SIP pour la téléphonie) et

H.323. L'interconnexion avec les réseaux de signalisation SS7 se fait généralement 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 réseaux de données avec les réseaux

existants de téléphonie (TDM avec signalisation SS7) a nécessité le développement de

protocoles dédiés à l'interconnexion des réseaux et au transport de la signalisation SS7 sur des

réseaux en mode paquet.

5. NGN Multimedia: IMS.

5.1- Introduction.

Dans un réseau de télécommunications IMS, la notion de commutation disparaît 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'enchaîner ou se marier, tant au niveau du contenu

(voix, images, vidéo et texte) qu'au niveau du nombre d'interlocuteurs. L'IMS rend plus aisé le

déploiement de tout type de service télécoms s'appuyant sur un transport IP (téléphonie,

visioconférence ou partage de contenu).

Le principal avantage que doit amener IMS aux opérateurs réside dans sa capacité de

facilitation d’implémentation et de lancement de nouveaux services. Sans IMS, la mise en

œuvre d’un nouveau service implique de lourdes contraintes pour un opérateur sur son réseau

: développement et intégration de nouvelles interfaces réseaux, de nouvelles applications, de

nouvelles interfaces de facturation, etc. A cela s’ajoute les nouvelles capacités liées à l’usagedu protocole SIP permettant à l’opérateur de proposer toute une gamme de services innovants.




20

5.2- Architecture de l’IMS.

5.2.1- Structuration en couche de l’architecture IMS.

L’architecture IMS [1] peut être structurée en couches. La figure 3décrit les différentes

couches de l’IMS.

Figure 3 : Architecture de l’IMS.

Quatre couches importantes sont identifiées :

La couche Accès: Celle – ci peut représenter tout accès haut débit tel que :

UTRAN, CDMA2000, xDSL, réseau câble, Wireless IP, WiFi, etc.

La couche Transport: Elle représente un réseau IP quipourra intégrer des

mécanismes de QoS avec MPLS, Diffserv, RSVP, etc. La couche transport consiste

donc en des routeurs reliés par un réseau de transmission.

La couche contrôle: Cette couche consiste en des contrôleurs de session

res ponsables du routage de la signalisation entre les usagers et de l’invocation de

services. Ces nœuds s’appellent des Call State Control Function (CSCF). IMS

Introduit donc un environnement de contrôle de session sur le domaine paquet.




21

La couche application: Elle introduit les applications (services à valeur ajoutée)

proposées aux usagers. L’opérateur peut se positionner grâce à sa couche Contrôle

en tant qu’agrégateur de services offerts par l’opérateur lui-même ou par des tiers.

La couche application consiste en des serveurs d’application (AS, Application

Server) et des Multimédia resourcefunction (MRF) que les fournisseurs appellent

serveurs de média IP (IP MS, IP Media Server).

5.2.2- Protocoles définis dans l’architecture IMS.

Les protocoles définis dans l’architecture IMS peuvent être classés en trois catégories :

Protocoles d’authentification et de sécurité : Ce sont les interfaces (Cx, Dx et Sh)

de l’architecture IMS qui utilisent les fonctions d’authentification. Dans toutes ces

interfaces, le protocole d’authentification utilisé est Diameter.

Protocoles utilisés dans le plan média : IMS emploie le protocole temps réel RTP et

le protocole de contrôle temps réel RTCP (Real Time Control Protocol) pour la

livraison de médias.

Protocoles de signalisation ou de contrôle de session : Le protocole choisi par

3GPP pour le contrôle de session est le protocole d’initiation de session SIP défini

dans RFC 3261[2].

Conclusion

Dans ce chapitre, nous avons présenté le réseau NGN et sont évolution vers le concept IMS.

On peut dire que la migration vers les NGN apparaît comme un choix inévitable du fait de la

convergence voix/données/image et fixe/mobile. Elle a déjà attiré l’intérêt d’un certain

nombre d’acteurs, en Europe et dans d'autres pays. Encore faut-il anticiper pour suivre et

analyser ses impacts.

Dans le chapitre suivant nous présentons 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

contrôle de session et le contrôle de service.




22

Chapitre 3

Le Protocol SIP

1. Introduction

SIP (Session Initiation Protocol) est un protocole de signalisation défini par l’IETF

(Internet Engineering Task Force) permettant l’établissement, la libération et la modification

de sessions multimédias (RFC 3261). Le protocole SIP tel qu'il est connu est la réunion de

deux protocoles s'inspirant des protocoles de gestion de vidéoconférence. SIPv1 est un

mécanisme pour mettre en place des communications point à point ou multicast. Ce protocolerepose sur des échanges de message en mode texte. Son concept est l'enregistrement auprès de

serveurs de conférence. De l'autre côté, le protocole SCIP (Simple Conference Invitation

Protocol) a notamment les codes de réponse. L'identification des utilisateurs se fait grâce à 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 obsolète par le RFC3261

publié en Juin 2002. SIP a été étendu afin de supporter de nombreux services tels que la

présence, la messagerie instantanée (similaire au service SMS dans les réseaux mobiles), le

transfert d’appel, la conférence, les services complémentaires de téléphonie, etc.

Il remplacera à terme les protocoles ISUP (utilisé pour le contrôle d’appel dans le

Réseau Téléphonique Commuté) et INAP (utilisé pour le contrôle de service dans

l’architecture Réseau 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/vidéo à travers le protocole

RTP (Real-Time Transport Protocol).

Par ailleurs, SIP n'est pas un protocole de réservation de ressources, il ne peut donc pas

assurer la QoS, il s'agit d'un protocole de contrôle d'appel et non de contrôle du média.

SIP n'est pas non plus un protocole de transfert de fichier tel que HTTP, utilisé afin de

transporter de grands volumes de données. Il a été conçu pour transmettre des messages de

signalisation courts afin d'établir, maintenir et libérer des sessions multimédia.




23

2. SIP Composants.

SIP supporte des fonctionnalités pour l'établissement et la fin des sessions multimédia :

la localisation, la disponibilité, l'utilisation des ressources, et les caractéristiques de

négociation. Pour la mise en œuvre de ces fonctionnalités, SIP offre plusieurs composants, qui

peuvent être divisés en deux : User Agents (UA) et les serveurs.

Figure 4: Entités d’un réseau SIP

2.1- Agent utilisateur (UA, User Agent).

Il s’agit d’une application sur un équipement de l’usager qui émet et reçoit des

requêtes SIP. Il se matérialise par un logiciel installé sur un PC, sur un téléphone IP ou sur une

station mobile UMTS (UE, User Equipment).

Il est formé de deux parties différentes, l'User Agent Client (UAC) et le User Agent

Server (UAS). UAC est une entité logique qui crée des requêtes SIP et reçois des réponses à

cette demande. AS est une entité logique qui crée des réponses aux requêtes SIP. Les deux

sont inclus dans tous les agents utilisateurs, afin de permettre la communication entre les

agents utilisateurs grâce à des communications client-serveur.




24

2.2- SIP Serveurs.

Les composants serveur de l'infrastructure SIP peuvent être divisés en trois types:

Le serveur proxy (Proxy server) : Il reçoit des requêtes de clients qu’il traite lui-même ou

qu’il achemine à d’autres serveurs après avoir éventuellement réalisé certaines modifications

sur ces requêtes.

Le serveur de redirection (Redirect server) : Il s’agit d’un serveur qui accepte des requêtes

SIP, traduit l'adresse SIP de destination en une ou plusieurs adresses réseau et les retourne au

client. Contrairement au Proxy server, le Redirect server n'achemine pas de requêtes SIP. Dans

le cas d’un renvoi d’appel, le Proxy server a la capacité de traduire le numéro de l’appelé dans

le message SIP reçu, en un numéro de renvoi d’appel et d'acheminer l’appel à cette nouvelle

destination, et ce, de façon transparente pour le client origine ; pour le même service, leRedirect server retourne le nouveau numéro (numéro de renvoi) au client origine qui se charge

d’établir un appel vers cette nouvelle destination.

L’enregistreur (Registrar) : Il s’agit d’un serveur qui accepte les requêtes SIP REGISTER.

SIP et dispose de la fonction d’enregistrement d’utilisateurs. L’utilisateur indique par un

message REGISTER émis au Registrar, l’adresse où il est joignable (e.g, adresse IP). Le

Registrar met alors à jour une base de données de localisation. L’enregistreur est une fonction

associée à un Proxy server ou à un Redirect server. Un utilisateur peut s’enregistrer sur

différents UAs SIP ; dans ce cas, l’appel lui sera délivré sur l’ensemble de ces Uas.

Il existe également un autre type de serveur aux fonctions bien particulières 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, tantôt en tant que serveur (réception

de requêtes) tantôt en tant que client (création de messages en réponses aux requêtes et non

une simple transmission). Il conserve en mémoire l'état des transactions et dispose d'un

contrôle total sur les messages (modification des en-têtes, du corps des messages). Ainsi, un

B2BUA est capable de fournir des fonctionnalités telles que : le contrôle d'appel (facturation,

déconnexion automatique d'appel, transfert d'appel, etc.), l'interconnexion de réseaux (avec

adaptation éventuelle au niveau du protocole), la dissimulation d'entités réseau (adresses

privées, topologie réseau, etc.) ou encore la traduction de codec entre deux parties [3]. Le

B2BUA constitue donc un élément 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 différentes "entités SIP" sont des abstractions




25

logiques et non physiques, une implémentation peut tout à fait les combiner au sein d'une

seule et même application machine. L'intérêt de séparer ces fonctionnalités réside

essentiellement dans l'équilibrage de la charge de traitement au niveau de déploiements à

grande échelle.

3. Messages SIP

3.1- Principales méthodes SIP

Le protocole SIP repose sur le même modèle de transactions que HTTP à base de

requêtes/réponses. Ces transactions consistent en un échange de messages tel que celui de

l’exemple représenté dansla figure 5 qui sont constitués de différents en-têtes spécifiant

l'appelant, l'appelé, le sujet de l'appel et la route empruntée pour la délivrance de ce message.

Chaque transaction est constituée d'une requête qui invoque une méthode particulière sur le

serveur et d'au moins une réponse.

Figure 5: Exemple de message SIP

Il existe six méthodes dans le noyau SIP qui sont décrites dans le tableau 1.




26

Tableau 1: Les six méthodes du noyau SIP .

3.2-Extension des méthodes SIP

De nombreuses extensions sont venues compléter le jeu de méthodes originelles afin d'offrir

davantage de fonctionnalités, nécessaires par exemple pour que les réseaux SIP puissent inter-opérer avec d'autres technologies comme la téléphonie traditionnelle PSTN, mais aussi pour

fournir les services que la téléphonie sur IP promettait.

Les méthodes étendues de SIP sont présentées comme suit :

SUBSCRIBE : permet la souscription d’un UA (user agent).

NOTIFY : utilisé pour la notification d’un user agent.

PUBLISH : permet de publier l’état d’un UA.

MESSAGE : permet le transfert des messages instantanés.UPDATE: permet à un terminal SIP de mettre à jour les paramètres d’une session

MultiMedia.

INFO : permet de transférer des informations de signalisation durant l'appel. Parmi les

exemples d'information figurent les digits DTMF, les informations relatives à la

taxation d'un appel.




27

3.3- Réponses SIP

Après avoir reçu et interprété une requête SIP, le destinataire de cette requête retourne une

réponse SIP. Il existe six classes de réponses qui sont regroupées dans le tableau suivant :

Tableau 2: Réponses SIP




28

Exemple d’établissement et de libération de session SIP :

Figure 6: Etablissement et libération de session SIP

4. Protocole RTSP.

Dans cette partie, nous nous intéressons au protocole RTSP (Real-Time StreamingProtocol). RTSP a été développé par Real Networks, Netscape et l’Université de Columbia au

sein du MMUSIC working group de l’Internet Engineering Task Force (IETF). Il est

implémenté aujourd’hui dans les produits de ces sociétés. Le but du protocole RTSP est de

mettre à disposition de l’utilisateur une télécommande qui lui permettra de commander le flux

multimédia en cours. Cette télécommande lui servira à commander un ou plusieurs serveurs

en parallèle et pourra être partagée simultanément entre plusieurs utilisateurs.

RTSP a pour but d’établir et de contrôler un ou plusieurs flux synchronisés de contenucontinu de multimédia, tels l’audio et le vidéo par exemple. Même si la s pécification de RTSP




29

lui permet de prendre en charge la distribution de ce contenu multimédia, la distribution de ce

flux sera en général prise en charge par RTP, RTSP ayant ainsi comme seule fonction la

commande du flux. Ces flux seront définis par un protocole de présentation. La RFC2326 ne

définit pas le format de présentation.

4.1- RTSP et les protocoles de transport

RTSP n’est pas un protocole connecté. C’est le serveur qui garde tout au long d’une

session un numéro lui permettant d’identifier les flux en cours et les clients concernés par ce

flux. Les messages de contrôle RTSP seront acheminés via une connexion qui pourra utiliser

soit UDP soit TCP et sera établie sur le port 554. Les flux multimédia seront acheminés par

une connexion hors bande utilisant un protocole quelconque de la couche de transport. C’est

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 données

soumises à des contraintes de temps réel (audio, vidéo, etc.). Le rôle principal de RTP consiste

à mettre en œuvre des numéros de séquence de paquets IP pour reconstituer les informations

de voix ou vidéo même si le réseau sous-jacent change l'ordre des paquets.

En résumé, RTP permet:

• d'identifier le type de l'information transportée,

• d'ajouter des marqueurs temporels et des numéros de séquence l'information transportée,

• de contrôler l'arrivée à destination des paquets.

De plus, RTP peut être véhiculé par des paquets multicast afin d'acheminer des

conversations vers des destinataires multiples.

Le protocole RTCP est base sur des transmissions périodiques de paquets de contrôle

par tous les participants dans la session. C'est un protocole de contrôle des flux RTP,

permettant de véhiculer 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 caractères de texte. Les concepteurs deRTSP ont aussi choisi de baser leur protocole sur un protocole applicatif réussi, HTTP, ce qui




30

permettrait de réutiliser les protocoles de commerce électronique et d’authentification déjà

implémentés sur HTTP. Ceci permettrait aussi à RTSP de s’adapter aux proxys et pare-feu

configurés et optimisés pour des protocoles comme HTTP. Cependant, HTTP ne pouvait pas

d’intégrer de nouvelles entêtes afin d’atteindre les objectifs de RTSP, car HTTP ne peut pas

gérer les connexions hors bande, et il convenait plus d’avoir une certaine séparation entre le

serveur Web et le serveur multimédia. Les principaux points de différence entre RTSP et

HTTP sont les suivants :

• un serveur RTSP garde un état de la connexion avec le client au cours d’une session. A la

différence de HTTP, une session RTSP n’est pas liée à une connexion TCP, mais uniquement à

un identificateur de session,

• un serveur RTSP peut initier des requêtes ayant le client comme destinataire,

4.4- Fonctionnalités de RTSP

Le protocole RTSP permet de réaliser les scénarios suivants:

• récupération d’un contenu multimédia à partir d’un serveur. La description du contenu

multimédia est récupérée via HTTP ou une autre méthode (e-mail par exemple). La

récupération du flux multimédia peut se faire en unicast aussi bien qu’en multicast,

• invitation d’un serveur multimédia à une conférence, afin d’incorporer à la conférence

un flux multimédia existant sur ce serveur, ou d’effectuer un enregistrement d’une

partie ou de la totalité de la conférence sur le serveur invité. Cette fonctionnalité est

utile dans le cas d’une application distribuée de e-learning par exemple. Notons ici que

les protocoles SIP et H.323 peuvent aussi être utilisés pour accomplir cette tâche,

• rajout d’un contenu multimédia à une présentation en cours. Dans ce cas, lors d’une

diffusion en direct par exemple, le serveur prévient le client qu’un flux supplémentaire

est disponible pour la transmission.

4.5- Paramètres de RTSP

Parmi les paramètres importants de RTSP, nous pouvons citer:

• l’url :

rtsp_URL = ( "rtsp:"|"rtspu:" ) "//" hôte [ ":" port ] [ chemin ]

Le terme «rtsp://» spécifie que la connexion de contrôle sera établie via TCP alors, que le

terme «rtspu://» indique une connexion de contrôle établie via UDP.




31

Les requêtes RTSP sont acquittées par le récepteur dans le cas où elles ne sont pas

envoyées à un groupe mutlicast. En absence d’acquittement, l’émetteur renvoie le même

message après un délai de 1 RTT (round-trip time). Les méthodes d’estimation de ce RTT sont

similaires à celles utilisées par TCP (RFC1123). Cependant, si RTSP opère en mode connecté,

les requêtes ne doivent pas être retransmises. Dans ce cas, c’est 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 réussira pas car le protocole de transport n’acheminera pas cette retransmission tant que la

retransmission au niveau couche transport n’a pas eu lieu.

La figure ci-dessous représente les différentes étapes d’une session RTSP. Nous pouvons ainsi

voir concrètement comment sont utilisés les mécanismes détaillés précédemment.

Figure 7 : Exemple d’une session RTSP

Conclusion

Dans ce chapitre nous avons présenté le protocole SIP que nous avons utilisé pour notre

projet pour le développement des services VoIP. Nous avons expliqué comment sa flexibilité

permet de créer tout type de service VoIP, en insistant plus particulièrement sur le protocole

chargé d'établissement et du control du flux multimédia continu.

Dans le chapitre suivant nous présentons la plateforme Mobicents et l'API JAIN et plus

particulièrement les détails qui se rapportent à cette technologie dont notamment son point

fort : le développement des services via SIP.

http://www.ietf.org/rfc/rfc1123.txt

http://www.ietf.org/rfc/rfc1123.txt




32

Chapitre 4

La Plateforme Mobicents.

1. Introduction

Mobicents est un serveur d'application basée sur un modèle événementiel de

haute scalabilité et un modèle de composant très robuste. C’est un projet qui comprend des

contributeurs individuels, avec l'autorisation des organismes tels que Portugal Telecom

Inovação, Telecom Italia,University of Genova, Vodafone R&D, T-Mobile, Lucent

Technologies, Open Cloud, Aepona, NEC Japan, JBoss, ...etc.

Mobicents complète J2EE et assure la convergence voix/vidéo/données dans lesréseaux de nouvelle génération. C’est la première et la seule plate-forme de VOIP libre qui a

été certifiée pour SLEE 1.0, et la meilleure architecture pour créer, déployer et gérer les

services et l'intégration des applications voix, vidéo et données à travers une plage d'adresses

IP et des réseaux de communications[4]. Elle favorise la convergence via cinq capacités 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'exécution de nouveaux servicesd’une manière simple et

rapidement ; permet le développement d'une plateforme orientée vers le marché et garantit la

rentabilité de la livraison de service.

Mobicents propose aussi un déploiement facile des applications et offre également des

fonctionnalités 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 contrôle

des applications SLEE de manière simple.

http://www.worldlingo.com/ma/enwiki/fr/Session_Initiation_Protocol

http://www.worldlingo.com/ma/enwiki/fr/Session_Initiation_Protocol




33

RedHat a récemment fait l'acquisition de la technologie Mobicents. En combinant l’offre

middleware de JBoss et de Mobicents, RedHat a créé la plate-forme de communication

RedHat/JBoss destinée au secteur des télécommunications. 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 présence. D'une manière aisée avec EclipSLEE offre un environnement

graphique de création de service pour le développement rapide des services à valeur ajoutée

de JAIN SLEE. Les spécifications de JAIN SLEE permettent aux piles populaires de

protocole telles que le SIP d'être reliées comme adapteurs de ressource. Les modules de

service de SLEE - SBBs sont des composants de logiciel qui envoient et reçoivent des

événements et exécutent la logique informatique basée sur la réception des événements et de

son état actuel. Ils ont beaucoup de similitudes à EJBs.

En plus des telecom, Mobicents convient à une variété d'exiger de domaines de

problème Event Driven Architecture (EDA) pour le volume élevé et basse signalisation de

latence. Les exemples incluent les marchés financiers, le jeu en ligne, les réseaux de

capteurs(RFID).

2. La Technologie JAIN

JAIN est un ensemble d'API JAVA qui permet de développer rapidement de nouveaux

services pour des réseaux de télécommunication voix ou données, indépendamment des

http://en.wikipedia.org/wiki/Event-driven_architecture

http://www.worldlingo.com/ma/enwiki/fr/Radio-frequency_identification




http://en.wikipedia.org/wiki/Event-driven_architecture




34

serveurs utilisés (matériel). De plus, JAIN étant basé sur la plateforme JAVA, il introduit la

portabilité des services entre systèmes et permet des accès sécurisés aux ressources des

différents réseaux.

La technologie JAIN change radicalement le marché des télécommunications en

permettant le passage de systèmes fermés et propriétaires à des systèmes ouverts offrant une

interconnexion totale des différents réseaux existant (PSTN25, IP, ATM26, GSM, WLAN27).

Ceci peut être constaté dans la figure ci-dessous qui donne une représentation schématique de

l’architecture de JAIN [6].

Figure 10 : Architecture de Base de JAIN.

2.1- Avantages et intérêts de JAIN

En fournissant un haut niveau d’abstraction par rapport au matériel, JAIN apporte de

nombreux avantages tactiques et économiques tels que :

La portabilité des services : Actuellement le développement de service est limité par

les interfaces propriétaires de chaque système. En offrant une indépendance totale




35

par rapport au matériel, JAIN permet la réutilisation des services pour tous les types

de réseaux tout en réduisant les temps et les coûts de développement. Les temps et

coûts de maintenance sont eux aussi diminués de façon significative.

La convergence des réseaux : En offrant la possibilité de développer des services

indépendamment des réseaux cibles, il est possible de fusionner les réseaux

habituellement incompatibles. Cette caractéristique permet d’augmenter la diversité

des services, de faire des économies d’échelle, d’optimiser la gestion des réseaux et

d’assurer une meilleure intégration des technologies de l’information (IT).

La sécurité d’accès : La sécurité offerte par JAVA autorise des accès à des réseaux

internes par des personnes étrangères. Cette particularité par rapport aux systèmes

actuels, permet d’accroître la diversité des services en supprimant les contraintes

découlant de la sécurité entre réseau.

2.2- Les couches d’abstractions

Le but de JAIN est de créer des services de nouvelles générations pouvant intégrer des

communications par paquet (IP, ATM), PSTN et sans-fil. Il définit donc un environnement

d’exécution indépendant du protocole de signalisation en proposant plusieurs couches

d’abstraction, une libraire de composant, des outils de développement et un environnement decréation de services.

Les trois couches d’abstractions sont :

Couche réseau :

Il s’agit d’une couche définissant le protocole de communications choisit.

Télécommunications : Réseaux 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 s’agit d’une couche représentant les logiciels chargés de la gestion des communications.

Télécommunications : Signaling Service Point (SSP).

Wireless : Mobile switching center (MSC).

VoIP : Proxy, redirect serveur, H.323 gatekeeper, media controllers.

Couche de service : Il s’agit d’une couche représentant les services de base.




36

Télécommunications : Service Control Point (SCP).

Wireless : Base Station Controllers (BSC), Home Location Register (HLR).

VoIP : Serveur d’application internet.

Figure 11 : Architecture en couche de JAIN.

2.3- Les différentes APIs de JAIN

La technologie de JAIN permet l'intégration de l'Internet et des protocoles du réseau

intelligent, désignés sous le nom « réseaux intégrés ». Deux types d’APIs ont été définis : des

APIs relatives à la standardisation des interfaces d’accès aux services et une autre classe

d’APIs propre aux conteneurs d’applications.

Les interfaces standard mettent à la disposition du langage de programmation Java tous

les protocoles de télécoms. En revanche, les conteneurs d'applications fournissent un

environnement standard d'exécution pour des services de télécommunication. Ces services

emploient typiquement ces interfaces standard pour des communications par l'intermédiaire

des adaptateurs de ressources.

JAIN contient plusieurs APIs comme on peut le voir dans la figure 12, et qui peuvent




37

être utilisées selon le service désiré. Dans ce projet nous avons utilisé deux APIs JAIN SLEE

et JAIN SIP.

Figure 12 : Différents APIs de JAIN.

SIP, un protocole actuellement populaire dans le domaine des télécoms, parce qu'il

possède l’avantage de ne pas être attaché à un médium particulier et est sensé être indépendant

du protocole de transport des couches basses. De plus, il peut être étendu et s’adapter aux

évolutions futures. JAIN offre le JAIN SIP 1.1 APIs en tant qu'élément du Java APIs pour les

communications. En utilisant le SIP, on peut développer nos propres services comme par

exemple le fameux « SIP Gateway », qui est nécessaire pour créer et contrôler les connexions.

Les spécifications définissent 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 prévues pour développer tout type de services. Elles peuvent interagir avec

d’autres sources de données tout en garantissant une bonne sécurité, il est en effet possible de

confiner les servlets à n’utiliser que par les ressources de la machine virtuelle.

La technologie JAIN SLEE permet la création 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

hébergés 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 d’abord mettre l’accent sur JAIN SIP




38

API, puisque dans notre application nous avons opté pour le protocole SIP.

2.4- JAIN SIP API

La communauté Java n’a pas tardé de s'intéresser à SIP. Il en découle de nombreuses

implémentations du protocole pour différents supports. La première implémentation fut JAIN.

Elle permet d'avoir un contrôle très fin sur les messages.

L'API inclue un ensemble d'objets et d'interfaces qui fournissent des abstractions de

haut niveau pour représenter les concepts SIP, libérant le programmeur des détails fins comme

la gestion des transactions, mais permettant l'accès aux champs importants du message SIP

(From, To, Request- URI, Contact). Ainsi, l'API a pour but de permettre aux applications

d'avoir un contrôle sur la signalisation SIP tout en cachant toute la complexité sous-jacente qui

n'est pas appropriée pour les développeurs.

Figure 13 : Architecture JAIN SIP.

La figure 14 montre qu’en plus de JAIN SIP, il existe d’autre APIs qui sont :

• JAIN SIP Lite, il s’agit d’une API haut niveau fournissant une abstraction du stack SIP, elle

peut être utilisée pour créer un agent SIP.

• JAIN SIP Servelts.




39

Figure 14: Les différentes JAIN SIP API

Actuellement seule la spécification de JAIN SIP est disponible, elle est fournie avec une

bonne documentation qui décrit toutes les méthodes de l’interface.

3. JAIN SLEE.

3.1- Introduction.

La notion de serveur d'application est un concept bien connu dans le monde de

développement. Un SA permet le développement rapide d'applications. Il assure également de

grandes performances. En offrant un Framework de travail, il facilite et accélère la création et

le déploiement des applications. J2EE AS est le leader mondial des serveurs d'applications.

Cette dernière technologie, fortement utilisée dans le domaine des IT, a l’avantage d’accroître




40

la productivité et de réduire l'effort des développeurs dans la résolution du cœur des

problèmes. Pour arriver à ce résultat des entités programmables seront utilisées pour bâtir la

solution. L'équivalent de J2EE dans le monde des Télécommunications et des applications

ayant des contraintes temps réel est JSLEE. Dans cette partie nous présentons le serveur

d'application JSLEE, nous donnons son architecture ses composants ainsi que son principe de

fonctionnement.

3.2- La spécification de JAIN SLEE

La spécification JAIN SLEE fournit une norme permettant aux développeurs java

d'élaborer et de déployer des services dans des systèmes en temps réel comme les réseaux de

transmission vocale ou de données ou les systèmes d'automatisation industrielle.

En fait, les systèmes de communications sont des systèmes asynchrones basés sur le modèled’évènement, contrairement aux systèmes d’entreprises qui utilisent typiquement les méthodes

d’invocations directes. Une architecture existante d'entreprise est définie par les spécifications

de « Entreprise JavaBeans ».

Le tableau ci-dessous donne une comparaison entre les caractéristiques des systèmes

d'entreprises et de communications [7].

Tableau 3: Comparaison entre le système de communication et le système d’entreprise.

Comme le montre ce tableau, il y a des différences substantielles entre les systèmes de




41

communications et les systèmes d'entreprises. Les spécifications d'EJB répondent aux

exigences des systèmes d'entreprises, alors que la SLEE répond aux exigences des systèmes

de communications actuels.

Bien que les conteneurs existants de J2EE traitent également les événements

asynchrones (JMS), ils n'ont pas été conçus pour cela. Une SLEE, d'autre part, a été

spécifiquement conçue pour les systèmes de télécommunications à haute fréquence et qui sont

complètement asynchrones. Ainsi, une SLEE remplit les exigences des systèmes de

communications de façon bien meilleure que n'importe quel conteneur d'EJB.

3.3- Les composantes de bases du JAIN SLEE

L’API du SLEE définit une interface standard pour le développement d’applications de

télécommunications portables. Les spécifications de cet API ont été menées par David Ferry

de la société “ Open Cloud” et Swee Lim de la société “Sun Microsystems” [8].

JAIN SLEE intègre un modèle d'événement avec un composant de programmation tout

en incorporant aussi des interfaces d'administration par l'intermédiaire de JMX, un adaptateur

de ressources pour le réseau, des interfaces de profils génériques, un système de gestion de

persistance pour les états de redondance, des systèmes de contrôle d'accès concurrent comme

les minuteries, des systèmes d'alarmes et un système de suivi d'utilisation et des traces.

La figure ci-dessous présente l’architecture de JAIN SLEE et les relations entre ses différents

composants :

Figure 15:Architecture de Jain SLEE




42

3.3.1- L’adaptateur de ressource

Les adaptateurs de ressources communiquent avec les systèmes externes au SLEE, tels

que, les composants de réseau, les protocoles stacks, les bases de données, etc. Selonl'architecture du SLEE, un adaptateur de ressources est une implémentation 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 déclare tous les types d'événements qui peuvent être

produits ainsi que toutes les activités que l’adaptateur peut introduire. Quand un adaptateur de

ressources passe un événement au SLEE, il doit fournir son objet et son type ainsi qu’une

activité qui l’encapsule (figure 16). Les spécifications n'énoncent pas comment cette

information est passée au SLEE.

Figure 16 : Rôle de l’adaptateur de ressource.

3.3.2- Le routeur d’évènements

Les spécifications de SLEE définissent comment un événement émis par un producteur

d'événements est conduit et fourni à un ou plusieurs composants qui lui sont intéressés.

Pour ce faire la SLEE est équipée d’un routeur logique d’évènements. Celui -ci reçoit des

événements émis de tous les producteurs d'événements et les achemine aux différentesinstances correspondantes.




43

3.3.3- L’évènement

Les objets d'événements diffusent l'information entre les différentes entités du SLEE.

Seules les SBB consomment et produisent des événements, alors que toutes les autres entitéstelles que les adaptateurs de ressources, la SLEE elle-même peuvent les produire.

Chaque événement est représenté par un objet d'événements (sous-classe de

java.lang.Object) et un type. Le type d'événement détermine comment le SLEE conduira

l'événement, par exemple, quels sont les objets SBB qui doivent recevoir l'événement. Un

SBB reçoit les évènements du contexte d’activité qui lui est rattaché.

Le développeur doit définir une méthode abstraite pour l’exécution de chaque

évènement dont le SBB a besoin. Cette méthode est généralement exécutée par la SLEE. Dans

le cas d’un évènement initiateur, la SLEE doit créer un objet SBB avant de lui acheminer

l’évènement.

3.3.4- Les services et Les profils

Dans JAIN SLEE, un service constitue un artifice de déploiement et de gestion. Pour

définir un service, l'administrateur doit spécifier le descripteur de déploiement du service avec

notamment les informations telles que le nom (globalement unique), le fournisseur et laversion du service ainsi que tout programme (classes Java, …) faisant partie du service.

Un profil contient des données provisionnées par un administrateur par exemple. Ces

données ont un schéma qui peut être constitué d’attributs ou de propriétés. Par exemple, une

adresse mail ou un numéro de téléphone peuvent être des attributs d’un profil d’abonné. JAIN

SLEE définit aussi la notion de spécification de profil qui détermine le schéma du profil ainsi

que la logique qui assure qu'un profil donné est valide.

Figure 17 : profile et table de profile




44

3.3.5- L’activité et le contexte d’activité

Les classes d’activités comprennent les deux entités logiques, activité et contexte

d'activité, et leurs représentations d'objet en Java, objet d'activité et objet d’interface de

contexte d'activité.Une activité représente un ensemble d’événements. La représentation 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 représente un appel téléphonique.

Figure 18 : Activité et contexte d’activité.

Un contexte d'activité représente l'activité fondamentale dans la SLEE et tient

également les attributs en commun que les entités SBB veulent partager. Les objets SBB

peuvent accéder aux contextes d'activité par l'objet interface de contexte d'activité.

Un SBB peut utiliser une interface de contexte d’activité générique comme il peut étendre

cette interface pour définir des attributs supplémentaires, qu’il veut partager avec d’autres

objets.

Les objets d'activités sont produits par des événements de réseau. Les adaptateurs de

ressources écoutent ces événements et créent les objets d’activités appropriées. Ces objets sont

placés dans le contexte d'activité du SLEE. Dès lors, le SLEE est maintenant responsable de la

livraison des événements produits aux objets du SBB. Vice versa, un objet du SBB peut

accéder à l'interface du contexte d'activité pour obtenir l'accès à l'objet d'activité courante.

3.3.6- Composants SBB (Service Building Block)

Comme nous l'avons vu, le SLEE définit une architecture avec des composants. Ces




45

composants portent le nom de Service Building Block (SBB). Un SBB est un composant

logiciel qui contient une certaine logique applicative à travers l’envoi ou la réception

d’évènements. Les SBB sont des composants à mémoire pouvant se souvenir du résultat des

traitements passés et les réutiliser dans les traitements futurs. Un SBB peut être composé à

partir d’autres SBB permettant ainsi de composer des applications sophistiquées en combinant

un ensemble de SBB. Les SBB implémentent la logique applicative en se basant sur les

évènements. Un évènement représente une occurrence significative qui peut survenir à un

moment non défini dans le temps. La définition d’un 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 d’évènements dans un SBB ;

Le SBB est le composant le plus élémentaire dans la SLEE. Il est inspiré de l’EJB sur

lesquels se basent les systèmes d’entreprise « J2EE ».

Un composant SBB définit :

• Les types d’événements qu’il peut recevoir et traiter.

• Des méthodes pour traiter chaque type d’événement.

• Les relations ‘’Child ‘’ qui le rattache à des composantes SBB ‘’Child’’.

• Les données qu’il désire partager avec les autres composants par l’intermédiaire d’un

ensemble d’attributs d’activitycontext.

Le développeur d’un SBB implémente ce qu’on appelle un SBB Abstract Class de

l’interface SBB déjà définie dans les spécifications de la SLEE.

3.3.7-Composants de gestion et de contrôle des services

Pour contrôler efficacement les services, les échanges d'événement et les ressources, il




46

est nécessaire de surveiller et mesurer l'exécution, l'utilisation et la disponibilité de ces

attributs, tout en estimant leurs situations futures. Les spécifications de la SLEE définissent un

certain nombre de composantes qui peuvent être employées pour répondre à ces exigences.

• Le temporisateur : cette fonction procure à des applications la possibilité d'effectuer des

actions périodiques, ou lancer des actions et des contrôles à un temps postérieur pour s’assurer

qu’ils ont été bien accomplis. Le temporisateur contrôle un certain nombre de temporisateurs,

dont chacun est indépendant des autres.

• Le service d'alarme : des alarmes sont employées pour informer des applications de

gestion qu'un changement inattendu d'état s'est produit dans un élément de réseau. Les

composants de SBB emploient le service d'alarme pour produire des avis d'alarme destinés à

la consommation par des clients de gestion externe au SLEE. L'envoi des alarmes aux

applications de gestion est automatiquement déclenché quand un état particulier devient vrai.

Ces clients de gestion peuvent être une console de gestion de réseau ou un moteur de politique

de gestion.

• Service de mesure des statistiques : les statistiques sont des caractéristiques de

l’application ou du réseau qui sont périodiquement demandées par les applications de gestion.

Un client de gestion peut employer les paramètres 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 stockés dans des tables de profil. Les profils contiennent des données stockées dans la

SLEE.

4. Mobicents Media Server (MMS)

Dans le monde des télécommunications basé sur la VoIP, les fournisseurs offrent des

services hautement personnalisés qui combinent les médias comme l'audio/vidéo ou

messagerie instantanée. Ces services nécessitent des capacités de traitement de médias

dédiées et personnalisées. Pour cela le réseau VoIP sépare les fonctions de traitement des

médias en nœud dédié qui est responsable de traitement des médias seulement, alors que toute

l'intelligence est exécutée par le contrôleur d'appel distinct. Le nœud de traitement des flux de

média est appelé Media Server.

Dans le même temps, il y'a beaucoup de flux média dans les systèmes existants. Cela

signifie que les nœuds de traitements de média doit être capable de combler l'écart entre les

anciens systèmes traditionnels et les systèmes modernes de réseau VoIP. Ce nœud




47

généralement appelé en tant que passerelle media, mais normalement les actes de passerelle

média sont aussi appelés serveur médias.

4.1- Mobicents Media ServerMobicents Media Server est une implémentation Open Source de l'élément

responsable de la manipulation des médias dans le réseau 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 distribués et centralisés, y compris la commutation

par circuit la voix/vidéo, 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 lestandard MGCP interface permet d'utiliser le serveur de medias Mobicents en paire avec un

autre contrôleur d’appels. Le serveur Media Mobicents est équipé avec l'implémentation 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

multimédia prend en charge les variantes d'accès TDM comme l'ETSI ISUP, PRI. Le serveur

multimédia prend en charge la signalisation backhaul sur IP avec M3UA et options SUA.

Le serveur Media Mobicents est implémenté 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 spécifique et/ ou d'étendre les fonctions du

serveur de médias en installant des composants de traitements supplémentaires.

4.2- Buts de Mobicents Media Server

Le Mobicents Media Server a pour but de :

Répondre aux exigences des réseaux convergents sans fil et filaire, DSL et l'accès à

large bande par câble, ainsi que des réseaux VoIP fixe-mobile convergents à partir

d'une Media-Gatway unique.

Augmenter la flexibilité avec un Media-Gatway supportant une large variété de

protocoles de contrôle d’appel et possédant une architecture qui peut évoluer pour

répondre aux exigences des petits fournisseurs de services comme des grandes

entreprises.




48

4.3- Architecture de Serveur Medias

Les services multimédias ont joué un rôle important dans les réseaux téléphoniques

traditionnels basés sur la technique de multiplexage TDM. Comme les réseaux passent à desenvironnements basés IP, les services multimédia y passent aussi, Mobicents Media-Server, en

raison de son degré de modularité élevé, peut apporter des bénéfices au Développeur

d'applications. Nous signalons pour exemple : Si l'interconnexion au réseau téléphonique

commuté n'est plus nécessaire dans une architecture, l'élément représentatif du canal D est

tout simplement supprimé. Si la Même application est déployée avec un système SS7 dans la

future, l'élément représentatif du canal D est activé.

Figure20 : Architecture de Mobicents Media Server.

L'architecture Media Server suppose que l'intelligence de contrôle d'appel se trouve en dehors

du serveur de médias, et est géré par une entité externe. Le Media Server suppose également que les

contrôleurs d'appelle utilisent des procédures de contrôle tels que MGCP, MEGACO ou MSML[4].

Chaque module de contrôle spécifique peut être branché directement sur le serveur comme une unité

standard de déploiement. En utilisant le MicrocontainerJboss pour déployer ces modules de contrôle.

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.




49

2. G.711 A-Law.

3. GSM.

4. Speex -nb.

5. G.729.

Conclusion

La technologie JAIN a un potentiel immense. Elle bouleverse complètement le marché des

télécommunications en permettant un accès direct au développement de services par tous les acteurs

de télécommunications dans le monde indépendamment des systèmes.

Avec le principe adopté par la communauté JAIN qui supprime les différences entre réseaux et

qui apporte la sécurité, il n’existe plus que deux limites à la création de services. Le premier est

physique, c’est la taille du réseau mondial, le second est l’imagination.

A ce stade, la première partie est achevée, on a vu comment la plateforme MobiCents avec ces

composants JSLEE, et MMS forme un environnement très riche pour le développement et l’intégration

des services VoIP. On va par la suite passer à la partie la plus valorisante du rapport : l’étaped’analyse,

de conception et de réalisation du Service VoD.




50

Chapitre 5

Conception et Développement du service

Au cours des dernières années, il a été constaté une augmentation significative de la

fourniture de services de télévision et vidéo sur IP. Ceci est largement dû à la chute du coût de

bande passante et l'augmentation de la capacité du réseau.

IPTV, VoIP et les applications basées sur la présence devraient être les principaux

services au sein du réseau de prochaine génération (NGN).

Vidéo à la demande permet généralement aux utilisateurs de sélectionner et de

visionner des vidéos sur demande. En outre, "Video on Demand" offre aux utilisateurs desoutils tels que les contrôles magnétoscope : (pause, avance et retour rapide).

Malgré des revenus encore modestes, le marché de la vidéo à la demande progresse

d’année en année et semble aborder une phase importante de son développement sous

l’impulsion de plusieurs facteurs encourageants (nombre d’abonnés au haut-débit, succès de

l’IPTV, habitudes de consommation et offre plutôt intéressante).

1- Travaux liés

1.1- IPTV/VoD Standardisation

La normalisation est généralement nécessaire pour assurer l'interopérabilité entre

différentes implémentations et de réduire les temps de cycle d'installation et les coûts associés

[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

développement des organisations, forums et consortiums. TISPAN (convergence des

télécommunications et Internet Services et protocoles pour la mise en réseau avancée) a été

mis en place par l'ETSI (EuropeanTelecommunications Standards Institute) en 2003 en tant

qu'organisme de normalisation clé dans la création de spécifications NGN. Open IPTV Forum

est un consortium d'entreprises (environ 60 membres à ce jour) qui a élaboré et publié un

standard IPTV ouvert.




51

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 contrôlés et manipulés par le sous-système de base IMS. L'architectureIMS-IPTV présentée dans cette section est basée sur l'architecture IPTV-IMS de l'ETSI

TISPAN. Il est le Framework le plus largement adopté basés 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) intéragit avec quatre entités: 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 intéragit avec le PCSCF utilisant SIP 3GPP pour la

fonction de découverte de service (SDF), Service de sélection de fonction (SSF) et Service

Control Function (SCF). Le SDF est chargé de générer les informations attachées au service.

Le SSF fournit des informations de sélection du service, c'est à dire une liste des services

disponibles. Le SCF effectue trois tâches 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

contrôle de crédit qui signifie qu'il peut faire partie d'une ligne de charge du système. La

troisième fonction est de sélectionner des supports de fonctions IPTV.

Le MCF est responsable de la sélection des répartiteurs et gère les interactions entre

l'UE et MDF. Le MCF génère é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.




52

Figure 21: Architecture IPTV/VOD proposée par l'ETSI TISPAN

2-Architecture et Implémentation

L'architecture du système proposée est représentée sur la figure 22. Les différents composants

sont expliqués ci-dessous:




53

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 vidéo

VLC.

Toutes les demandes des médias à partir du client sont envoyées au serveur dans une

requête SIP INVITE avec le format suivant: [email protected] . Le serveur

répond par un message 200 OK contenant l'adresse RTSP de la ressource demandée. Le client

VoD prend alors contact avec le serveur de streaming en utilisant l'adresse RTSP, initiant ainsi

la session médias.

2.2- Le serveur Mobicents

Le serveur d'application mobicents est chargé d'authentifié les clients et de gérer les

demandes des vidéos et la liste des vidéos, 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 opère avec succès sur

divers systèmes d’exploitation (Linux, FreeBSD, Mac OS X, Windows, Solaris). Cette

mailto:[email protected]

mailto:[email protected]




54

dernière permet la diffusion "streaming en Live ou à la demande de vos fichiers audio et

vidéo.

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 (très

avantageux en termes de rapport qualité / bande passante), MPEG 4 et 3gpp (pour la

téléphonie 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 contrôlé par

le MGCP. MMS gère les flux RTP medias entre l’utilisateur et le serveur. Le cas d’utilisation

de "mobicents media server" est représenté par la figure ci-dessus :

Figure 23 : Cas d’utilisation de Mobicents Media Server

3- Réalisation et présentation

3.1- Conception du service

Pour la réalisation de ce projet, nous avons développé deux SBB :

CallSbb est le SBB "Root" qui reçoit le message "SIP INVITE" comme évènement initial

et qui déclenche le Service à travers le descripteur XML de l'événement gestionnaire Sbb-jar.xml,

comme indiqué ci-dessous:




55

IVRSbb est le SBB "child" qui s’exécute par le SBB CallSbb , c'est lui qui contient le

Service.

Lorsque le CallSbb reçoit le message "SIP invite" de l’utilisateur, la méthode qui

s’exécute via cet évènement est la suivante :

Le rôle de cette méthode est de déclencher le IVRSbb qui contient le service correspondant au




56

message SIP Invite reçu par CallSbb.

Une fois que le IVRSbb reçoit une invite de CallSbb , cette invite est CallCreated comme

évènement initial pour cette SBB . Le descripteur XML de l'événement gestionnaire Sbb-jar.xml

est représenté ci-dessous :

Lorsque cet évènement est créé via le CallSbb, la méthode qui s’exécute est responsable de

créer la connexion avec l’utilisateur , et aussi d’envoyer un demande via MGCP RA vers

"Mobicents Media Server" pour établir un flux RTP avec l’utilisateur.




57

Apres connexion entre le client et le serveur Mobicents JSLEE , le client écoute la liste des

films via le flux RTP crée par MMS.

Maintenant le client peut choisir sa vidéo désirée en envoyant un évènement qui s’appelle

"Request NOTIFICATION" qui est généré à travers le Botton correspondant au numéro de

vidéo

La méthode qui s’exécute, est la suivante:

Le serveur Mobicents va répondre avec l’adresse RTSP cor respondant à cette vidéo via une

méthode qui a comme évènement d’entrée un période de temps:




58

Pour résumer le déroulement d’une demande vidéo par un utilisateur, la figure ci-dessous

illustre le flux d’appel pour l’accès au service vidéo à la demande:

Figure 24 : Call flow pour le service VoD.

3.2- Atelier de travail

Les outils choisis par les développeurs dépendent essentiellement de la solution

architecturale du système. Ainsi, nous présentons dans cette partie les outils choisis pour

réussir le développement de nos Services. En fait, le choix des outils n'est pas aléatoire. Nous

nous sommes basés sur un ensemble de critères 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 indépendants de

toute architecture matérielle. En effet, Java présente un langage informatique de

programmation orienté objet utilisé dans tous les segments industriels majeurs. Il s'étend sur

toute une gamme de périphériques, d'ordinateurs et de réseaux. Il est à la fois un langage de

programmation et un environnement d'exécution. Le langage Java a la particularité principale

d'être portable sur plusieurs systèmes d'exploitation tels que Unix, Microsoft Windows ou




59

Mac OS...

Dans notre projet, toute la plateforme MobiCents est fondé sur ce langage, et profite

de ces caractéristique à savoir la portabilité et son indépendance vis-à-vis du matériel.

3.2.2- SVNSVN (Subversion) est un outil d'aide au développement de logiciels. Il permet une gestion

efficace et riche des différentes versions pour un projet logiciel. Cela passe notamment par la

mise en place d'un suivi, et par conséquent d'un historique, pour l'ensemble des fichiers

appartenant au projet. De plus, il se caractérise par son système centralisé pour le partage

d’informations.

L'un des autres points forts de SVN est de permettre et de favoriser un développement en

équipe. En effet, il permet un stockage centralisé (SVN fonctionne en mode client/serveur) du

code source sur un serveur et gère les accès concurrents sur les fichiers de développement.

Ce qui distingue SVN des autres outils de développement collaboratif est la possibilité pour

les développeurs d'accéder en même temps à un même fichier pour le modifier, avec une prise

en charge des modifications lorsque celles-ci ne génèrent 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 général et Java EE en particulier.

Maven utilise un paradigme connu sous le nom de Project Object Model (POM) afin de

décrire un projet logiciel, ses dépendances avec des modules externes et l'ordre à suivre pour

sa production. Un élément clé et relativement spécifique de Maven est son aptitude à

fonctionner en réseau [11].

Dans notre cas, il nous permet de gérer l'arborescence du projet et les différentes dépendances

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 développement

d'un logiciel d'automatisation des opérations répétitives tout au long du cycle de

développement logiciel.

Dans notre projet, cet outil est fondamentale .En effet il est utilisé pour la compilation et le

déploiement des services sur le serveur JBOSS.

3.2.5- L’environnement de développement Eclipse

Eclipse est un environnement de développement intégré libre extensible, universel et

polyvalent, permettant de créer des projets de développement mettant en œuvre n'importe quel




60

langage de programmation. Eclipse IDE est principalement écrit en Java (à l'aide de la

bibliothèque graphique SWT, d'IBM), et ce langage, est également utilisé pour écrire des

extensions grâce à des bibliothèques spécifiques.

3.3-Scénario de déploiement

Afin de mettre en évidence notre travail, on se propose, dans ce paragraphe, de présenter un

scénario qui va présenter les différentes phases de déploiement de chaque composant.

Étape 1 : Démarrer le serveur de médias (MMS)Ceci se fait par la commande Suivant : run.bat

Figure 25 : Démarrage de Mobicents media server

Étape 2 : Démarrer le serveur

Pour démarrer le serveur mobicents JSLEE, il suffit d'aller dans le répertoire de JBoss et

taper la commande suivante : run.bat




61

Figure 26 : Démarrage du serveur Mobicents JSLEE

A la fin du démarrage du serveur MobicentsJSLEE, nous voyons clairement que le service est

bien déployer, la figure suivante montre cet étape :

Figure 27 : Déploiement du service




62

Étape 3 : Démarrer Darwin server streaming

Ceci se fait, par les deux commandes :

Étape 4 : Accès au service

Apres le lancement du client SIP X-lite (voir son configuration dans l’annexe B), le client

peut accéder au service en tapant le numéro 555 , un message vocal liste les films disponibles

et demande au client de choisir un numéro correspondant à un film . Dans notre cas le client a

choisi le film numéro 2.

Figure 28 : Client Sip X-lite

Apres le choix du film, le lecteur VLC démarre automatiquement, et film est visionné comme

nous montre la figure ci-dessous.




63

Figure 29 : visionnement du flux média

Conclusion

Ce chapitre présente le cœur de ce rapport, du fait qu’il représente notre valeur ajoutée, et

notre contribution durant ce stage. En effet, nous avons aussi montré les différents outils

utilisés, aussi nous avons élaboré la conception des services étape par étape, leurs

implémentations ainsi que leur Tests final.




64

Conclusion et perspectives

Dans ce projet, nous avons utilisé la plate-forme de communication mobicents pour

développer un service vidéo à la demande, qui peut être intégré dans le réseau IMS en se

basant sur les standardisations de l'IPTV-VoD, nous avons aussi discuté les différentes

exigences pour un déploiement réussi 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 propriétaires. En effet d'autres services peuvent être prévus

utilisant aussi le protocole SIP à savoir vidéo conférence ou bien Mobicents PBX. Ceci dit

qu'on peut compter sur l'open source pour composer, tester et valider les services multimédiade nouvelle génération.

Le serveur de streaming est un magasin des vidéos et répond aux demandes vidéo et

en fait n'importe quel client, authentifiés ou non authentifié peut accéder à la vidéo dans le

serveur de streaming, Il y a donc un trou de sécurité à cette approche. Pour contourner cela

nous avons besoin d'un serveur des médias complet, plutôt que d'un serveur de streaming

simple. Les futurs travaux seront axés sur le développement d'une architecture sécurisée

permettra aux clients autorisés à recevoir des flux média à partir du serveur multimédia.

La conduite de notre projet de fin étude a été une expérience très particulière et une

opportunité réelle pour mettre en pratique un ensemble de connaissances acquises durant nos

formations. Par ailleurs ce stage, a été un moyen de développer plusieurs qualités aussi bien

qu’au niveau Informatique et Télécoms qu’au niveau professionnel.

Finalement, les objectifs fixés au départ ont été en grande partie réalisées et nous

espérons que les résultats obtenus trouveront un bon écho.




65

Bibliographie

Bibliographie[1] 3rd Generation Partnership Project; Technical Specification Group Services andSystemAspects, 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 (ProposedStandard), 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 AfricanNetworks 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/

http://www.3gpp.org/specs/TS%2023.228



https://mobicents.dev.java.net/

http://www.fr.redhat.com/solutions/telco/communications_platform/

http://www.jainslee.org/

http://java.sun.com/products/jain



http://www.jboss.org/

http://www.jboss.org/


http://www.jainslee.org/

http://www.fr.redhat.com/solutions/telco/communications_platform/

https://mobicents.dev.java.net/





66

Annexe A- Installation de Mobicents

La distribution binaire de la plateforme Mobicents Jain Slee peut être téléchargée à partir du site :

http://www.mobicents.org/slee/downloads.html

1. Installation de java jdkLa Plate-forme Mobicents est écrit en Java, donc, avant d'exécuter n'importe quel serveur Mobicents,

on doit disposer de Java RuntimeEnvironment (JRE) ou Java Development Kit (JDK) installé dans le

système. En outre, le JRE ou JDK utilisé pour exécuter Mobicents doit être la version 5 ou supérieure.

On peut télécharger 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 téléchargé, on peut l'installer sur Linux en s'assurant que le fichier est

exécutable, puis l'exécuter:

#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 lancés au

démarrage du système) :

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 déterminer si JAVA_HOME est défini sur le système :

Pour choisir entre les versions java installer dans le système, on tape la commande :

alternatives --config java # or javac or javaws








67

Enfin, pour assurer qu'on a utilisé le bon JDK ou version Java (5 ou plus), et que l'exécutable Java est

dans notre PATH, on exécute la commande java -versiondans le terminal :

1-2- installation sous Windows : Il suffit de télécharger la version binaire et de l'exécuter et puis ajouter le chemin du dossier des

binaires de la JDK installée (../../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 procédure d’installation se résume au téléchargement, désarchivage et mise en place de

la variable $JBOSS_HOME dans le système. 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 procédure et plus simplifiée car la procédure de désarchivage se fait en utilisant

l’interface graphique du système.

2-1-Configuration de Mobicents Jain Slee . La configuration se résume à la mise en place d'une variable JBOSS_HOME dans le système.




68

Pour Windows(en commande DOS):

# Set jboss_home=chemin\au\repértoire\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 méthode pour installer MobiCents consiste à compiler soi-même le code source à partir du

dépôt SVN. Cette seconde méthode donne l'avantage d'accéder directement aux dernières nouveautés,

fonctionnalités et corrections de bugs. Pour plus de détails sur comment installer MobiCents à partir

du code source, se référer au site web du projet sur Google Code:

http://groups.google.com/group/mobicents-public.

Pour démarrer mobicents il suffit d'aller dans le répertoire 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 démarré, allez à l'adresse http://127.0.0.1:8080 pour voir

l’interface web du serveur Jboss .

Figure 30 : Interface d’administration Mobicents.

http://127.0.0.1:8080/

http://127.0.0.1:8080/




69

Annexe B –Guide d’installation et d’utilisation de

MGCP Démo.

Le MGCP Démo est un exemple conçu pour démontrer l’utilisation des APIs JAIN MGCP, y

compris la MGCP RA, dans le même temps elle démontre aussi diverses caractéristiques et

fonctionnalités de Mobicents Media Server (MMS).les MGCP message sont transmises via le

protocole UDP.les commandes sont envoyées à des adresses IP définies dans le domaine du

point de terminal (en anglais :Endpoint).Les réponses sont envoyés à l’adresse source c’est –

à-dire l’adresse IP et le numéro de port UDP des commandes.

Cette exemple est compose de trois services.

Premier Service est composé de CallSbb comme parent, qui écoute SIP

INVITEcomme unévénementinitial. IVRSbb, RecorderSbbetTTSSbbsont appelé ses

enfants (children). Et celui qui est responsable de jouer l'annonce et d'écoute pour les

entrées DTMF de l'utilisateur. Selon le DTMF est composé par l'utilisateur, l'annonce

correspondante est de nouveau diffusé. Pour le tester compose le numéro 2010.

Deuxième service est composé seulement de ConferenceSbb agissant en tant queroot,il écoute au SIP INVITE mais il est moins prioritaire que la premier Service.

estresponsablepour l'enregistrement vocalde l'utilisateuretde la lectureaprès30

secondes. Pour le tester composer le numéro 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.

Troisièmeserviceestcomposéseulement deConfLegSbbagissanten tant que root. Il

écoute pour Custom Event envoyer par ConferenceSbb quand un participant rejoint la

conférence. Pour le tester composer 2012.

1. Les besoins

Pour tester ce démo on a besoin de (ces besoins sont pour Windows et Linux) :

Mobicents JAIN SLEE Server

Mobicents Media Server.




70

Maven apache.

Sip 11 RA & MGCP RA.

Le code source de Mobicents JAIN SLEE MGCP Démo.

1-1- Mobicents JAIN SLEE Server.

Pour Mobicents JAIN SLEE Server on a utilisé la version 2.3.0.FINAL .vous pouvez le

télécharger d’après 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 télécharger une version d’après le site web de

Mobicents ou bien d’utiliser 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 déployer pour la télécharger consulté le site web

http://maven.apache.org qui contient tous les informations sur l’utilisation de cette outil.

1-4- Sip 11 RA & MGCP RA.

Ce sont deux ressource d’adaptation utilisés pour le service afin d’être en mis à niveau et

capable d’être déployer par le serveur JBoss pour qu’on puisse évaluer ses fonctionnalités.

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 Démo.

Utilisateur Linux

Pour télécharger le code source de ce Démo dans le terminal.

[usr]$svn co http://mobicents.googlecode.com/svn/tags/servers/jain-

http://sourceforge.net/projects/mobicents/files/Mobicents%20JAIN%20SLEE%20Server/2.3.0.FINAL/



http://maven.apache.org/


http://mobicents.googlecode.com/svn/tags/servers/jain-slee/2.x.y/examples/mgcp-demo/2.4.0.CR1%20slee-exemple-mgcp%20demo2.4.0.CR1









71

slee/2.x.y/examples/mgcp-demo/2.4.0.CR1 slee-exemple-mgcp demo2.4.0.CR1.

Après on va utiliser Maven pour construire l’unité déployable.pour cela on va se

déplacer vers le dossier « slee-exemple-mgcpdemo2.4.0.CR1 ». qui contient les

fichiers source de MGCP Démo téléchargé.

[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-DU-

2.4.0.CR1

Utilisateur Windows.

Les mêmes procédures que pour l’utilisateur Linux sauf la démarche car il doit

télécharger le code source manuellement à partir de site web.

http://mobicents.googlecode.com/svn/tags/servers/jainslee/2.x.y/examples/mgcp-

demo/2.4.0.CR1

2. Configuration du SIP Client.

Pour tester ce démo on doit avoir un client Sip dans notre cas, on a choisi le client sip X-lite

PRO, mais avant de passer à tester les fonctionnalités de ce démo il faut la configurer.

Pour la configuration il faut tout simplement voir les images.

Pour default:

http://mobicents.googlecode.com/svn/tags/servers/jainslee/2.x.y/examples/mgcp-demo/2.4.0.CR1








72

Figure 31 : Configuration de X-lite pourDefault

Pour Network.

Pour avoir accès à network dans x-lite appuyer sur configuration puis System

Settings, network.




73

Figure 32 : Configuration x-lite pour Network

3. Déploiement du service.

Pour déployer 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 l’emplacement suivant.

slee-example-mgcp-demo-2.4.0.CR1/web/target/mgcp-demo-audio.war

Dans le répertoire 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 même répertoire 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 numéros.




74

Figure 33 : déploiement de MGCP Démo

Raport Pfe Benali Darbaoui

Documents

Transcript of Raport Pfe Benali Darbaoui