Vous êtes sur la page 1sur 74

Développement du Service VoD sous La Plateforme Mobicents

NSN

AVANT-PROPOS

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

Omar Benali : omar.benali86@gmail.com

Imad Darbaoui : darbaoui@gmail.com

Intitulé de travail :

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

Etablissement d’accueil : NOKIA SIEMENS NETWORK.

Lieu : Rue Abou Inane, Rabat. Téléphone : 0537219040 Fax : 0537261531

Superviseurs du projet :

M. Fouad Lahjomri à l’ENSA de Tanger

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

1
1

Développement du Service VoD sous La Plateforme Mobicents

NSN

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.

2
2

Développement du Service VoD sous La Plateforme Mobicents

NSN

Abstarct

The telecommunications industry is rapidly expanding. Introducing or integrating new services in the market is becoming more difficult given the constraints of infrastructure and proprietary standards that must be respected ,especially that the production costs have been risen. Only in this perspective that the IMS was introduced considerably into the market. In fact, with its distributed architecture, it allows to implement new services, particularly with

the new user needs with a set of sophisticated applications and services (push to talk, instant

messaging, audio conferencing and video, online games,

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.

).Thus

Key words: NGN, IMS, Mobicents , JAIN SLEE, SIP, VoIP, VoD, RTP,RTSP, MGCP.

3
3

Développement du Service VoD sous La Plateforme Mobicents

NSN

Table des matières

Introduction 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

4
4

Développement du Service VoD sous La Plateforme Mobicents

NSN

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……………………………………………………

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

42

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……………………

4.3- Architecture de Serveur Medias…………………………….………………

50

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

5
5

Développement du Service VoD sous La Plateforme Mobicents

NSN

 

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……………………………………………

3.2-1.

…………

61

 

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

6
6

Développement du Service VoD sous La Plateforme Mobicents

NSN

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

7
7

Développement du Service VoD sous La Plateforme Mobicents

NSN

Introduction générale

sous La Plateforme Mobicents NSN Introduction générale Le monde de télécommunications est en croissance rapide et

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.

8
8

Développement du Service VoD sous La Plateforme Mobicents

NSN

Chapitre 1

Contexte général du projet

Mobicents NSN Chapitre 1 Contexte général du projet Dans ce chapitre, nous allons présenter l'entreprise

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

9
9

Développement du Service VoD sous La Plateforme Mobicents

NSN

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

10
10

Développement du Service VoD sous La Plateforme Mobicents

NSN

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

11
11

Développement du Service VoD sous La Plateforme Mobicents

NSN

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 du maté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

12
12

Développement du Service VoD sous La Plateforme Mobicents

NSN

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 :

13
13

Développement du Service VoD sous La Plateforme Mobicents

NSN

du Service VoD sous La Plateforme Mobicents NSN Figure 1: Diagramme de GANTT du projet 2.3-

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.

14
14

Développement du Service VoD sous La Plateforme Mobicents

NSN

Chapitre 2

Les réseaux NGN

La Plateforme Mobicents NSN Chapitre 2 Les réseaux NGN 1. Introduction L’évolution progressive du monde des

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 sont

modé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 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 couche avec les fonctions de transport, une couche avec les fonctions de contrôle de service, une

15
15

Développement du Service VoD sous La Plateforme Mobicents

NSN

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

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.

Protocol

):Cette

16
16

Développement du Service VoD sous La Plateforme Mobicents

NSN

du Service VoD sous La Plateforme Mobicents NSN Figure 2: Architecture de réseau NGN. 3. Les

Figure 2: Architecture de réseau NGN.

3. Les entités fonctionnelles 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.

17
17

Développement du Service VoD sous La Plateforme Mobicents

NSN

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

18
18

Développement du Service VoD sous La Plateforme Mobicents

NSN

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’usage du protocole SIP permettant à l’opérateur de proposer toute une gamme de services innovants.

19
19

Développement du Service VoD sous La Plateforme Mobicents

NSN

5.2- Architecture de l’IMS.

5.2.1- Structuration en couche de l’architecture IMS.

L’architecture IMS [1] couches de l’IMS.

peut être structurée en couches. La figure 3décrit les différentes

structurée en couches. La figure 3décrit les différentes Figure 3 : Architecture de l’IMS. Quatre couches

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 responsables 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.

20
20

Développement du Service VoD sous La Plateforme Mobicents

NSN

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.

21
21

Développement du Service VoD sous La Plateforme Mobicents

NSN

Chapitre 3 Le Protocol SIP

La Plateforme Mobicents NSN Chapitre 3 Le Protocol SIP 1. Introduction SIP (Session Initiation Protocol) est

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 protocole repose 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.

22
22

Développement du Service VoD sous La Plateforme Mobicents

NSN

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.

être divisés en deux : User Agents (UA) et les serveurs. Figure 4: Entités d’un réseau

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.

23
23

Développement du Service VoD sous La Plateforme Mobicents

NSN

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, le Redirect 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

24
24

Développement du Service VoD sous La Plateforme Mobicents

NSN

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.

particulière sur le serveur et d'au moins une réponse. Figure 5: Exemple de message SIP Il

Figure 5: Exemple de message SIP

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

25
25

Développement du Service VoD sous La Plateforme Mobicents

NSN

du Service VoD sous La Plateforme Mobicents NSN Tableau 1: Les six méthodes du noyau SIP

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.

26
26

Développement du Service VoD sous La Plateforme Mobicents

NSN

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 :

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

Tableau 2: Réponses SIP

27
27

Développement du Service VoD sous La Plateforme Mobicents

NSN

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

d’établissement et de libération de session SIP : Figure 6: Etablissement et 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 Streaming Protocol). 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 contenu continu de multimédia, tels l’audio et le vidéo par exemple. Même si la spécification de RTSP

28
28

Développement du Service VoD sous La Plateforme Mobicents

NSN

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 de RTSP ont aussi choisi de baser leur protocole sur un protocole applicatif réussi, HTTP, ce qui

29
29

Développement du Service VoD sous La Plateforme Mobicents

NSN

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.

30
30

Développement du Service VoD sous La Plateforme Mobicents

NSN

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.

sont utilisés les mécanismes détaillés précédemment. Figure 7 : Exemple d’une session RTSP Conclusion Dans ce

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.

31
31

Développement du Service VoD sous La Plateforme Mobicents

NSN

Chapitre 4 La Plateforme Mobicents.

Mobicents NSN Chapitre 4 La Plateforme Mobicents. 1. Introduction Mobicents est un serveur d'application

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,

Mobicents complète J2EE et assure la convergence voix/vidéo/données dans les ré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 :

etc.

favorise la convergence via cinq capacités de base : etc. Figure 8 : Architecture de Mobicents.

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.

32
32

Développement du Service VoD sous La Plateforme Mobicents

NSN

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].

La figure ci-dessous illustre cette architecture [5]. Figure 9 : Architecture de la plateforme de communication

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

33
33

Développement du Service VoD sous La Plateforme Mobicents

NSN

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].

schématique de l’architecture de JAIN [6]. Figure 10 : Architecture de Base de JAIN. 2.1- Avantages

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

34
34

Développement du Service VoD sous La Plateforme Mobicents

NSN

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 de cré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.

35
35

Développement du Service VoD sous La Plateforme Mobicents

NSN

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

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

VoIP : Serveur d’application internet.

(HLR).  VoIP : Serveur d’application internet. Figure 11 : Architecture en couche de JAIN. 2.3-

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

36
36

Développement du Service VoD sous La Plateforme Mobicents

NSN

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

projet nous avons utilisé deux APIs JAIN SLEE et JAIN SIP. Figure 12 : Différents APIs

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

37
37

Développement du Service VoD sous La Plateforme Mobicents

NSN

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.

qui n'est pas appropriée pour les développeurs. Figure 13 : Architecture JAIN SIP. La figure 14

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.

38
38

Développement du Service VoD sous La Plateforme Mobicents

NSN

du Service VoD sous La Plateforme Mobicents NSN Figure 14: Les différentes JAIN SIP API Actuellement

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

39
39

Développement du Service VoD sous La Plateforme Mobicents

NSN

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èle d’é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].

des systèmes d'entreprises et de communications [7]. Tableau 3 : Comparaison entre le système de communication

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

40
40

Développement du Service VoD sous La Plateforme Mobicents

NSN

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 :

l’architecture de JAIN SLEE et les relations entre ses différents composants : Figure 15:Architecture de Jain

Figure 15:Architecture de Jain SLEE

41
41

Développement du Service VoD sous La Plateforme Mobicents

NSN

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. Selon l'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.

pas comment cette information est passée au SLEE. Figure 16 : Rôle de l’adaptateur de ressource.

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érentes instances correspondantes.

42
42

Développement du Service VoD sous La Plateforme Mobicents

NSN

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és telles 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 la version 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.

du profil ainsi que la logique qui assure qu'un profil donné est valide. Figure 17 :

Figure 17 : profile et table de profile

43
43

Développement du Service VoD sous La Plateforme Mobicents

NSN

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.

Call Control APIs qui représente un appel téléphonique. Figure 18 : Activité et contexte d’activité. Un

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

44
44

Développement du Service VoD sous La Plateforme Mobicents

NSN

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.

et la version du SBB mais aussi le code Java du SBB. Figure 19 : Flux

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

45
45

Développement du Service VoD sous La Plateforme Mobicents

NSN

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

46
46

Développement du Service VoD sous La Plateforme Mobicents

NSN

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 Server

Mobicents 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 le standard 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.

47
47

Développement du Service VoD sous La Plateforme Mobicents

NSN

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 à des environnements 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é.

l'élément représentatif du canal D est activé. Figure20 : Architecture de Mobicents Media Server.

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.

48
48

Développement du Service VoD sous La Plateforme Mobicents

NSN

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.

49
49

Développement du Service VoD sous La Plateforme Mobicents

NSN

Chapitre 5

Conception et Développement du service

NSN Chapitre 5 Conception et Développement du service Au cours des dernières années, il a été

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 des outils 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.

50
50

Développement du Service VoD sous La Plateforme Mobicents

NSN

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'architecture IMS-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.

51
51

Développement du Service VoD sous La Plateforme Mobicents

NSN

du Service VoD sous La Plateforme Mobicents NSN Figure 21: Architecture IPTV/VOD proposée par l'ETSI

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:

52
52

Développement du Service VoD sous La Plateforme Mobicents

NSN

du Service VoD sous La Plateforme Mobicents NSN Figure 22 : 2.1- le client Architecture du

Figure 22 :

2.1- le client

Architecture du service VoD.

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: video_name@vod.mobicents.service . 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

53
53

Développement du Service VoD sous La Plateforme Mobicents

NSN

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 :

media server" est représenté par la figure ci-dessus : Figure 23 : Cas d’utilisation de Mobicents

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:

54
54

Développement du Service VoD sous La Plateforme Mobicents

NSN

du Service VoD sous La Plateforme Mobicents NSN IVRSbb est le SBB "child" qui s’ exécute

IVRSbb est le SBB "child" qui s’exécute par le SBB CallSbb , c'est lui qui contient le Service.

par le SBB CallSbb , c'est lui qui contient le Service. Lorsque le CallSbb reçoit le

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 :

qui s’exécute via cet évènement est la suivante : Le rôle de cette méthode est de

Le rôle de cette méthode est de déclencher le IVRSbb qui contient le service correspondant au

55
55

Développement du Service VoD sous La Plateforme Mobicents

NSN

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 :

gestionnaire Sbb-jar.xml est représenté ci-dessous : Lorsque cet évènement est créé via le CallSbb, la

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.

un demande via MGCP RA vers "Mobicents Media Server" pour établir u n flux RTP avec
56
56

Développement du Service VoD sous La Plateforme Mobicents

NSN

Apres

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:

connexion entre le client et le serveur Mobicents JSLEE , le client écoute la liste des

le serveur Mobicents JSLEE , le client écoute la liste des Le serveur Mobicents va répondre

Le serveur Mobicents va répondre avec l’adresse RTSP correspondant à cette vidéo via une méthode qui a comme évènement d’entrée un période de temps:

RTSP cor respondant à cette vidéo via une méthode qui a comme évènement d’entrée un période
57
57

Développement du Service VoD sous La Plateforme Mobicents

NSN

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:

d’appel pour l’accès au service vidéo à la demande : Figure 24 : Call flow pour

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

58
58

Développement du Service VoD sous La Plateforme Mobicents

NSN

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- SVN

SVN (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

59
59

Développement du Service VoD sous La Plateforme Mobicents

NSN

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

(MMS) Ceci se fait par la commande Suivant : run.bat Figure 25 : Démarrage de Mobicents

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

60
60

Développement du Service VoD sous La Plateforme Mobicents

NSN

du Service VoD sous La Plateforme Mobicents NSN Figure 26 : Démarrage du serveur Mobicents JSLEE

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 :

que le service est bien déployer, la figure suivante montre cet étape : Figure 27 :

Figure 27 : Déploiement du service

61
61

Développement du Service VoD sous La Plateforme Mobicents

NSN

Étape 3 : Démarrer Darwin server streaming

Ceci se fait, par les deux commandes :

server streaming Ceci se fait, par les deux commandes : Étape 4 : Accès au service
server streaming Ceci se fait, par les deux commandes : Étape 4 : Accès au service

É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.

film . Dans notre cas le client a choisi le film numéro 2. Figure 28 :

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.

62
62

Développement du Service VoD sous La Plateforme Mobicents

NSN

du Service VoD sous La Plateforme Mobicents NSN Figure 29 : visionnement du flux média Conclusion

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.

63
63

Développement du Service VoD sous La Plateforme Mobicents

NSN

Conclusion et perspectives

La Plateforme Mobicents NSN Conclusion et perspectives Dans ce projet, nous avons utilisé la plate-forme de

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édia de 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.

64
64

Développement du Service VoD sous La Plateforme Mobicents

NSN

Bibliographie

VoD sous La Plateforme Mobicents NSN Bibliographie Bibliographie [1] 3rd Generation Partnership Project;

Bibliographie

[1] 3rd Generation Partnership Project; Technical Specification Group Services and SystemAspects, Service requirements for the Internet Protocol (IP) multimedia subsystem, Stage 2";3GPP TS 23.228, September 2005, http://www.3gpp.org/specs/TS 23.228.

[2] J. Rosenberg, et al. “SIP: Session Initiation Protocol”, RFC 3261, June 2002.

[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peter-son, J., Sparks, R., Handley, M., and Schooler, E. SIP : Session InitiationProtocol. RFC 3261 (Proposed Standard), June 2002. Updated by RFCs 3265,3853, 4320, 4916.

[8]S. B. Lim and D Ferry, “JAIN SLEE 1.0 Specification, final release“, Sun Microsystems, Inc.and Open Cloud Limited March 2004

[9] Dikgole V, Ventura N. Video on Demand Service for Next Generation Networks. Proc. South African Telecommunications Networks and Applications Conference, (SATNAC 2008), Wild Coast Sun, South Africa.

[10] Wilson P, Neco V. A Direct Marketing Platform for IMS - Base d IPTV. Southern African Networks and Applications Conference (SATNAC 2009), Swaziland, 30 August 2 September 2009.

Webographie

[4] MobiCents: http://www.Mobicents.org, https://mobicents.dev.java.net

[6] JSLEE.org: http://www.jainslee.org

[7] Sun Microsystems JAIN: http://java.sun.com/products/jain ;JBoss: http://www.jboss.org

[11] Maven: http://maven.apache.org/

65
65

Développement du Service VoD sous La Plateforme Mobicents

NSN

Annexe A- Installation de Mobicents

Mobicents NSN Annexe A- Installation de Mobicents La distribution binaire de la plateforme Mobicents Jain Slee

La distribution binaire de la plateforme Mobicents Jain Slee peut être téléchargée à partir du site :

1. Installation de java jdk

La 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

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 :

peut déterminer si JAVA_HOME est défini sur le système : Pour choisir entre les versions java

Pour choisir entre les versions java installer dans le système, on tape la commande :

alternatives --config java

# or javac or javaws

66
66

Développement du Service VoD sous La Plateforme Mobicents

NSN

du Service VoD sous La Plateforme Mobicents NSN Enfin, pour assurer qu'on a utilisé le bon

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 commandejava -versiondans le terminal :

on exécute la commande java -version dans le terminal : 1-2- installation sous Windows : Il

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 (

) à la variable %path% de Windows, ceci avec la commande DOS

/bin /

: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.

67
67

Développement du Service VoD sous La Plateforme Mobicents

NSN

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 .

pour voir l’ interface web du serveur Jboss . Figure 30 : Interface d’administration Mobicents. 68

Figure 30 : Interface d’administration Mobicents.

68
68

Développement du Service VoD sous La Plateforme Mobicents

NSN

Annexe B –Guide d’installation et d’utilisation de MGCP Démo.

–Guide d’installation et d’utilisation de MGCP Démo. Le MGCP Démo est un exemple conçu pour démontrer

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 que root,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.

69
69

Développement du Service VoD sous La Plateforme Mobicents

NSN

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.

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.

70
70

Développement du Service VoD sous La Plateforme Mobicents

NSN

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.

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:

71
71

Développement du Service VoD sous La Plateforme Mobicents

NSN

du Service VoD sous La Plateforme Mobicents NSN Figure 31 : Configuration de X-lite pourDefault 

Figure 31 : Configuration de X-lite pourDefault

Pour Network.

Pour avoir accès à network dans x-lite appuyer sur configuration puis System Settings, network.

72
72

Développement du Service VoD sous La Plateforme Mobicents

NSN

du Service VoD sous La Plateforme Mobicents NSN Figure 32 : Configuration x-lite pour Network 3.

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.

73
73

Développement du Service VoD sous La Plateforme Mobicents

NSN

Développement du Service VoD sous La Plateforme Mobicents NSN Figure 33 : déploiement de MGCP Démo

Figure 33 : déploiement de MGCP Démo

74
74