Plateforme d'envoi/ réception de MMS avec Mbuni (passerelle Open Source ) (Sénégal )

Présenté par : Encadreur :

Souleymane THIONGANE
& Ousseynou NDOYE

Lieu de stage : Ecole Supérieure Polytechnique de Dakar (ESP)

Sujet:

MEMOIRE DE FIN DE CYCLE
Pour l'obtention du :

DIPLOME UNIVERSITAIRE DE TECHNOLOGIE en TELECOMS ET
RESEAUX (DUTTR)

ECOLE SUPERIEURE POLYTECHNIQUE

DEPARTEMENT GENIE INFORMATIQUE
Centre de Dakar

Année universitaire : 2008 - 2009

REPUBLIQUE DU SENEGAL

* *

M. Ibra DIOUM

Souleymane THIONGANE Ousseynou NDOYE

1

DEDICACES

Souleymane THIONGANE

Je dédie ce mémoire :

A mes chers parents, Mamadou Dicko et Aïssata Boury, qu'Allah vous préserve

A mes fr~res et soeurs, particuli~rement Diouldé, la nouvelle mariée, heureux ménage

A mes cousins, particulièrement Abdoulaye qui est comme un frère, merci pour tout ton soutien,

A mes frères de Koulloukoum, les salafis du Sénégal, Ahmad THIONGANE, Balla DIACK, Cheikh NIANG et tous les autres

Au reste de ma famille et tous ceux qui me connaissent A tous les étudiants de ma promotion

A tous mes « filleuls ».

Ousseynou NDOYE

Je dédie ce modeste travail à :

Toute ma famille, particulièrement à mes parents pour le soutien ,les conseils et encouragements portés à mon égard .Je trouverai jamais les moyens de vous payer cette dette.

A Toutes mes mamans et grand- mqres parce que j'en ai tellement que je ne saurai les énumérer toutes.

A Mon grand frère Assane DIOP à qui je dirai qu'ALLAH vous bénisse votre famille et vos biens , à mes oncles : Moussa TOP et Libasse SYLLA pour leur soutien.

A Tous mes amis , promotionnaires et « filleuls» .

A Toute Akhlou Beyti Rassoul , tout en priant pour Cherif Ousseynou LAHI ,qu' ALLAH lui comble de Sa miséricorde et l'accueille dans Son paradis eternel .

2

Souleymane THIONGANE Ousseynou NDOYE

REMERCIEMENTS

Nous remercions :

1' Tout d'abori notre Seigneur, ALLAH, sans qui nous

ne serions capables de faire ce modeste travail

1' Nos papas pour leur soutien sans faille durant tous

nos cursus scolaires

1' Nos mamans pour l'importance qu'elles portent pour

l'éducation de leurs enfants et pour leur

compréhension

1' Toute la famille des Télécoms et Réseaux promotion

2007-2009 pour tout le soutien qu'elle nous a apporté.

3

Souleymane THIONGANE Ousseynou NDOYE

1' Les Filleuls Télécoms et Réseaux de la promotion

2008-2010 , tout en vous disant que vous êtes les

meilleurs de l'ESP alors prouvez pour le restant de l a

formation.

1' Notre encadreur M. Ibra DIOUM pour l'aide

précieux qu'il nous a apporté tout au long du stage.

1' Tous ceux qui, de prés ou de loin, ont participé à la

réalisation de ce document.

Table des matières

Table des figures 9

Avant-propos 9

INTRODUCTION ..10

Chapitre 1 : PRESENTATION

I. LES RESEAUX MOBILES 11

1. PRESENTATION 11

2. LES EQUIPEMENTS TERMINAUX 21

II. LES SERVICES A VALEURS AJOUTEES 22

1. DEFINITION 22

2. LA REGLEMENTATION 23

4

Souleymane THIONGANE Ousseynou NDOYE

Chapitre 2 : L'ETAT DE L'ART DES MMS

I. PRESENTATION DU PROTOCOLE WAP 25

1. DEFINITION 25

2. GENERALITES 25

II. PRESENTATION DU SERVICE MMS 27

A. QU'EST CE QUE LE MMS ? 27

1. Définition et Apports 27

2. Contenus des MMS 28

3. Concurrence directe 29

B. FONCTIONNEMENT 29

1. Architecture 29

2. Fonctionnement du service 33

3. MMS et Services à Valeurs Ajoutées 41

Chapitre 3 : LES PLATEFORMES UTILISEES

I. PRESENTATION 43

1. KANNEL 43

2. MBUNI 51

II. INSTALLATIONS ET CONFIGURATIONS. 53

1. PRE-REQUIS 53

2. KANNEL 55

3. MBUNI 59

Chapitre 4 : FONCTIONNEMENTS DE LA PASSERELLE

I. LE MMSC 80

1. MMS PROXY 80

2. MMS RELAY 82

3. INTERFACE MAIL / SMTP 83

II. LA PASSERELLE SVA 85

CONCLUSION 92

5

Souleymane THIONGANE Ousseynou NDOYE

ANNEXES 93

ANNEXE A : LE PROTOCOLE WAP 87

ANNEXE B : LES LANGAGES : WML, SMIL 90

ANNEXE C: Le COURRIER ELECTRONIQUE .

6

Souleymane THIONGANE Ousseynou NDOYE

Table des figures

Figures :

7

Figure 1 :

	13
Figure 2 :	16
Figure 3 :	18
Figure 4 :	27
Figure 5 :	31
Figure 6 :	33
Figure 7 :	36
Figure 8 :	38
Figure 9 :	39
Figure10 :	40
Figure 11 :	.45
Figure 12 :	47
Figure 13 :	48
Figure 14 :	49
Figure 15 :	51
Figure 16 :	92
Figure 17 :	93
Figure 18 :	94
Souleymane THIONGANE
Ousseynou NDOYE

Tableaux :

Tableau 1 : 23

Tableau 2 : 69

Tableau 3 : 72

Tableau 4 : 77

Tableau 5 : 68

Tableau 6 : 85

Tableau 7 : 95

Tableau 8 : 101

Avant-propos

L?école supérieure polytechnique (E.S.P) forme en deux années d?études des techniciens supérieurs, et en cinq ans des ingénieurs dans plusieurs spécialités.

Dans le cadre de leur formation les étudiants de fin de chaque cycle sont tenus d?effectuer un stage pratique au sein d?une entreprise ou d?un service informatique.

Ce stage est effectué dans le but :

n De fournir aux étudiants la possibilité de mettre en oeuvre les connaissances théoriques acquises tout au long de leur formation.

n D?initier les futurs techniciens supérieurs aux réalités du milieu professionnel et de leur permettre de se faire la main sur des projets d?envergures.

Au terme de ce stage un mémoire et un rapport de stage doivent être rédigés sur un problème qui a été étudié durant ce stage.

C?est à l'issue d'un stage effectué

9

Souleymane THIONGANE Ousseynou NDOYE

INTRODUCTION

L?avènement des réseaux mobiles dans le domaine de la téléphonie a donné naissance à plusieurs types de services permettant ainsi à d?autres types de media de communication, qui ne sont pas necessairement la « voix », de voir le jour . En effet, le MMS (Multimedia Message Service) est l?un des moyens de communication les plus recents utilises par les telephones mobiles. Il a ete cree en 2002 par le le trio français SFR, Orange et Bouygues. Ce media avait pour objectif d'aller au delà de ce qui a ete possible avec le SMS. Il a permis, l'envoi de contenu multimedia (textes, images, sons, videos ou encore tout autre contenu interpretable par les telephones portables comme des jeux java par exemple).

Cependant, avec la CTI (Convergence Telecommunications-Informatique), des plateformes proprietaires et libres existent de nos jours pour mettre en place le service MMS.

C?est dans cette optique que nous allons, dans ce présent document, présenter les éléments nécessaires à la mise en oeuvre (réseaux, protocoles, serveurs, plateformes, langage, etc.) avant de passer à la pratique.

Chapitre 1 :

PRESENTATION

I. Les Réseaux Mobiles

1. Présentation

a. Historique

> 1979: Attribution de la bande 900 MHz aux services mobiles terrestres par la CAMR

> 1982-1985: La CEPT crée le Groupe Spécial Mobile (GSM) chargé de définir un système numérique de communication avec les mobiles pour l?horizon 1990. Il préconise d?utiliser la bande attribuée sous la forme: 890- 915 MHz sens montant 935 - 960 MHz sens descendant

> 1987 : Signature d?un protocole d?accord MoU (Memorandum of Understanding) par des opérateurs de 12 pays européens et choix de la combinaison des technologies de transmission TDMA et FDMA

> 1988-1990: Production des spécifications du GSM et développement des équipements

> 1991: Premières communications GSM sur l?interface radio au salon Mondial des Télécommunications de Genève

> 1992: Premiers réseaux en Europe et premier ROAMING entre Telecom Finlande et Vodafone UK

> 1994: Plus de 100 signataires des Accord MoU et plus de 3 Million d?abonnés. La norme s?étend à 1800 MHz (DCS 1800 en EUROPE)

> 1995: Spécifications du PCS 1900 MHz aux USA/Canada. 188 Membres du MoU de 69 pays

> 1997: GSM dans 110 pays, 240 opérateurs, plus de 70 millions d?abonnés et 31% du marché

> 2002: Plus de 700 Millions d?abonnés à travers le monde

b. Acteurs de la téléphonie mobile

11

Souleymane THIONGANE Ousseynou NDOYE

>

Constructeurs (Nokia, Siemens, Alcatel...)

ü Infrastructure réseau/radio

ü Terminaux

Opérateur

ü Offre de services mobiles

> Sociétés d'ingénierie

ü Assistance à la planification et à l?optimisation

ü Recherche de sites

> Installateurs

ü Déploiement d?équipements et maintenance

> Régulation et Administrateurs

ü Attribution des licences

ü Définitions des services de Télécommunications

ü Attributions des fréquences

> Organismes de normalisation UIT

ü Définition des fonctions des systèmes

ü Définition d?interfaces normalisées

c. Multiplexage

> FDMA (Frequency Division Multiple Access)

La méthode d?accès FDMA, repose sur un multiplexage en fréquences (divise la bande de fréquences en plusieurs sous bandes). Chaque communication est placée sur une fréquence dite porteuse, ou carrier, qui est la fréquence spécifique du canal et chaque porteuse ne peut transporter que le signal d?un seul utilisateur. Cette méthode nécessite une séparation entre les porteuses pour éviter les interférences. Cette méthode essentiellement utilisée par les réseaux analogiques tels que l?AMPS qui comporte 823 porteuses, avec une séparation de 30 KHz entre les porteuses adjacentes.

> TDMA (Time Division Multiple Access)

La méthode d?accès TDMA, offre la totalité de la bande de fréquences à chaque utilisateur
pendant une fraction de temps donnée, appelée time slot ou intervalle de temps. L?émetteur de
la station mobile stocke les informations avant de les transmettre sur le slot, autrement dit

dans la fenêtre temporelle qui lui est consacrée. Les différents slots étant regroupés en une trame, le système offre ainsi plusieurs voies de communication aux différents utilisateurs. La succession des slots dans les trames forme le canal physique de l?utilisateur. Le récepteur enregistre les informations à l?arrivée de chaque slots et reconstitue le signal à la vitesse du support de transmission.

Remarque :

La combinaison des deux techniques est possible. Une bande de fréquence déjà divisée par le FDMA en sous bande centrées autours de différentes porteuses. Chaque sous bande est ensuite partagée en slots, suivant la méthode TDMA ce qui permet d?augmenter considérablement le nombre d?utilisateurs dans le réseau.

d. Architecture GSM

Le réseau GSM a pour premier rôle de permettre des communications, en mode circuit entre abonnés mobiles (GSM) et abonnés du réseau téléphonique commuté (RTC - réseau fixe). Le réseau

GSM s'interface avec le réseau RTC et comprend des commutateurs. Le réseau GSM se distingue par un accès spécifique : la liaison radio.

Le réseau GSM est composé de trois sous ensembles:

> Le sous système radio ou Base Station Sub-system (BSS) : assure et gère les transmissions radios

> Le sous système d'acheminement ou Network Sub-System (NSS) : on parle aussi de Switching and Management Sub-System (SMSS) pour parler du sous système d'acheminement. Le NSS comprend l'ensemble des fonctions nécessaires pour appels et gestion de la mobilité.

> Le sous-système d'exploitation et de maintenance ou Operation Sub-System (OSS) qui permet à l'opérateur d'exploiter son réseau.

La mise en place d'un réseau GSM va permettre à un opérateur de proposer des services de type Voix à ses clients en donnant l'accès à la mobilité tout en conservant un interfaçage avec le réseau fixe RTC existant. Ceci nécessite un investissement considérable.

A l?heure actuelle les réseaux GSM ne cessent d?évoluer afin d?assurer une qualité de
couverture toujours plus importante. La couverture du réseau est assurée par la multiplication

13

Souleymane THIONGANE Ousseynou NDOYE

des ensembles BTS #177; BSC. Nous verrons par la suite que le réseau GSM est une base pour la mise en place des réseaux GPRS et UMTS, même si pour le réseau UMTS au-delà du coût élevé d?achat des licences, nous verrons que l?ensemble BTS a BSC #177; MSC devra être changé ou modifié à la base. Rappelons ici rapidement qu?une BTS couvre environ 500m de zone en ville et 10 km de zone en campagne. Cela donne un aperçu du coût et du temps nécessaires pour la mise en place de la simple architecture technique du mode UMTS ...

Figure 1 : Architecture Réseau GSM

Ci dessus un rappel de l?architecture GSM, en encadré bleu les éléments de couverture, en ellipse bleue les éléments de gestion du réseau, en ellipse bleue pointillée, les éléments du réseau GSM qui seront utiles pour les réseaux GPRS et UMTS.

Unstructured Supplementary Service Data (USSD)

L'USSD, (Unstructured Supplementary Service Data) peut se traduire en Données de Service Supplémentaires Peu Structurées. Il s'agit d'une fonctionnalité des téléphones GSM. Il est généralement associé aux services de téléphonie de type temps réel ou de messagerie instantanée. Il n'y a aucune possibilité d'enregistrement et transfert qui est typique aux messages courts « normaux », autrement dit, il n y a pas de SMSC présent sur le circuit de traitement. Les temps de réponse pour des services basés USSD interactifs sont généralement plus rapides que ceux utilisés pour SMS.

En comparaison, USSD est semblable à Telnet, tandis qu?un SMS est semblable à un mail.

USSD est typiquement utilise comme « un declencheur » pour invoquer les appels de services independants qui n'exigent pas les depenses d'utilisation aeriennes et complementaires d'un SMSC, comme un service de rappel de service (un suivi de consommation, credit restant sur votre compte), ou le service de menu interactif (par exemple des cours de la bourse, des resultats sportifs).

USSD est une norme pour transmettre l'information sur des canaux de signaux GSM.

Il est surtout utilise comme une methode de suivi du solde disponible et d'autres informations semblables pour les services GSM prepayes comme les comptes mobiles (par exemple #123# pour les mobicartes d?Orange).

Exemples de codes USSD:

· #100# Service de Rechargement de la VoD de la TV d?Orange

· #101# : Numero MSISDN

· #120# : Service Rappel-moi

· #123# : Orange

· #125# : Portail de paiement mobile de Orange money

Après l'entrée d?un code d'USSD dans votre téléphone GSM, la réponse de l'opérateur GSM est remontee dans les secondes suivantes. Sur les portables Orange, par exemple, l'USSD permet de demander, entre autres fonctionnalites, le suivi de consommation. Après une manoeuvre simple (#123#), le consommateur reçoit le suivi en moins de deux secondes. USSD est la base de quelques methodes de paiement comme Mobipay.

L'identification des appareils

Les telephones mobiles contiennent une carte SIM (Suscriber Identity Module) qui permet d'identifier l'utilisateur et parfois de stocker un certain nombre de numeros de telephone. Chaque appareil est identifie, quelle que soit sa marque, par un numero IMEI que l'on obtient, en entrant sur le clavier, la sequence : *#06#. Il convient de noter ce numero et de le signaler à son operateur, en cas de vol, de façon à proceder à son blocage. Cet identifiant ne doit pas être confondu avec l'IMSI (International Mobile Station Identifier) contenu en SIM.

Le code PIN est le mot de passe de la carte SIM, le code PUK etant le code de deblocage à utiliser après trois tentatives de PIN erronees.

15

Souleymane THIONGANE Ousseynou NDOYE

Cependant sur un réseau cellulaire, un appareil est identifié via un TMSI (Temporary Mobile Station Identifier). Grkce à ce système d?IMSI/TMSI, un téléphone portable ne voit pas son numéro d'appel divulgué sur le réseau, ce qui permet la confidentialité des appels : comme les TMSI changent souvent et sont parfois attribués à plusieurs appareils en même temps, une personne interceptant le trafic a très peu de chance d'associer un numéro de téléphone à un TMSI.

Services

Le réseau GSM permet plusieurs services :

· La voix

· Les données (le WAP, le Fax ou bien comme un modem filaire classique)

· Les messages courts ou SMS ainsi que leur successeur, le MMS ou Multimedia Messaging

· Service

· Le cell broadcast (diffusion dans les cellules), qui permet d'envoyer le même SMS à tous les

· abonnés à l'intérieur d'une zone géographique

· Les services supplémentaires (renvois d'appels, présentation du numéro...)

· Les services à valeur ajoutée comme par exemple les services de localisation (Location Based Services), d'information à la demande (météo, horoscope), de banque (consultation de compte, recharge de compte prépayé).

e. Architecture réseau GSM + GPRS

Figure 2 : Architecture Réseau GSM+GPRS

Un réseau GPRS est en premier lieu un réseau IP. Le réseau est donc constitué de routeurs IP. L'introduction de la mobilité nécessite par ailleurs la précision de trois nouvelles entités :

+ Le PCU (Packet Control Unit, intégré au BSC) + Le SGSN (Serving GPRS Support Node)

+ Le GGSN (Gateway GPRS Support Node).

Une quatrième entité

o Le BG joue un rôle supplémentaire de sécurité.

Le réseau GPRS vient ajouter un certain nombre de « modules » sur le réseau GSM sans changer le réseau existant. Ainsi est conservé l'ensemble des modules de l'architecture GSM, nous verrons par ailleurs que certains modules GSM seront utilisés pour le fonctionnement du réseau GPRS.

17

Souleymane THIONGANE Ousseynou NDOYE

La mise en place d'un réseau GPRS va permettre à un opérateur de proposer de nouveaux services de types donnés à ses clients. Le GPRS est en mode paquets. Le service GPRS permet de considérer le réseau GSM comme un réseau à transmission de données par paquets avec un accès radio et des terminaux mobiles. Le réseau GPRS est compatible avec des protocoles IP et X.25. Des routeurs spécialisés SGSN et GGSN sont introduits sur le réseau. La transmission par paquet sur la voie radio permet d'économiser la ressource radio :

· un terminal est susceptible de recevoir ou d'émettre des données à tout moment sans qu'un canal radio soit monopolisé en permanence comme c'est le cas en réseau GSM.

· Le débit maximal instantané annoncé pour le GPRS est de 171.2 Kbps même s'il est limité à 48 Kbps en mode descendant (limite actuelle des terminaux GPRS).

· La mise en place d'un réseau GPRS permet à un opérateur de proposer de nouveaux services de type Data avec un débit de données 5 à 10 fois supérieur au débit maximum théorique d'un réseau GSM. (Rappel débit maximal en GSM : 9.6 Kbps).

· Le réseau GPRS constitue finalement une étape vers le réseau UMTS.

f. Architecture réseau GSM + GPRS + UMTS

Figure 3 : Architecture Réseau GSM+GPRS+UMTS

Le réseau UMTS vient se combiner aux réseaux déjà existants. Les réseaux existant GSM et GPRS apportent des fonctionnalités respectives de Voix et de Data ; le réseau UMTS apporte ensuite les fonctionnalités Multimédia.

Il est important de noter deux éléments :

v' Le coût élevé de la mise en place d'un système UMTS (achat licence + modification majeures sinon totales des éléments de base du réseau (station / antenne) répartis de manière massive sur un territoire national).

v' La difficulté à définir avec précision l'architecture d'un futur réseau UMTS dans la

mesure où le 3GPP et l'UMTS Forum travaillent encore aujourd'hui à la définition des normes et des spécifications techniques.

La mise en place d'un réseau UMTS va permettre à un opérateur de compléter son offre existante par l'apport de nouveaux services en mode paquet complétant ainsi les réseaux GSM et GPRS.

19

Souleymane THIONGANE Ousseynou NDOYE

Le réseau UMTS est complémentaire aux réseaux GSM et GPRS. Le réseau GSM couvre les fonctionnalités nécessaires aux services de type Voix en un mode circuit, le réseau GPRS apporte les premières fonctionnalités à la mise en place de services de type Data en mode paquets, et l'UMTS vient compléter ces deux réseaux par une offre de services Voix et Data complémentaires sur un mode paquet.

L'UMTS est ainsi une extension du GPRS et fonctionne également en mode paquet. La vitesse de transmission offerte par les réseaux UMTS atteint 2 Mbps. L'infrastructure UMTS permet l'élargissement des fréquences ainsi que la modification du codage des données. Mais les investissements en architecture réseau sont conséquents puisque le mode de communication entre les terminaux 3G et les BTS (appelé Node B) est différent. Les modifications matérielles sont très importantes.

Sur le plan technique, les architectures des trois réseaux GSM, GPRS et UMTS sont complémentaires et interconnectées afin d'optimiser la qualité de service rendue à l'abonné.

1' Débit

L'UMTS permet théoriquement des débits de transfert de 1,920 Mbps, mais en fin 2004 les débits offerts par les opérateurs dépassent rarement 384 kbps. Néanmoins, cette vitesse est nettement supérieure au débit de base GSM qui est de 9,6 kbps.

Le débit est différent suivant le lieu d'utilisation : En zone rurale : 144 kbps jusqu'à 500 km/h ;

En zone urbaine : 384 kbps jusqu'à 120 km/h;

Dans un bâtiment : 2 000 kbps depuis un point fixe.

1' Applications et services

Grâce à sa vitesse accrue de transmission de données, l'UMTS ouvre la porte à des applications et services nouveaux. L'UMTS permet en particulier de transférer dans des temps relativement courts des contenus multimédia tels que les images, les sons et la vidéo.

Les nouveaux services concernent surtout l'aspect vidéo : Visiophonie, MMS Vidéo, Vidéo à la demande, Télévision.

2. Les équipements terminaux

Afin d?exploiter au mieux les capacités du réseau GPRS les terminaux mobiles doivent ~tre compatibles mais cela ne suffit pas toujours. En effet, deux mobiles compatibles GPRS peuvent se comporter différemment dans les mrmes conditions d?utilisation.

> Classe des terminaux

Les mobiles compatibles GPRS sont classés en 3 classes :

· Classe A : Utilisation simultanée du GSM et GPRS, le mobile peut effectuer une communication GSM sur un TS (Time Slot) et peut utiliser plusieurs TS dédiés au GPRS.

· Classe B : Gestion de la mobilité des deux services mais seulement un des services peut être utilisé. Le mobile sera donc correctement localisé en GSM et GPRS mais l?utilisation du GPRS emprche une communication GSM et réciproquement.

· Classe C : le mobile ne peut utiliser que le GSM ou le GPRS, il doit se relocaliser après le basculement d?un mode à l?autre.

Actuellement la plupart des mobiles sont de classe A, la différence se fait sur l?introduction de nouvelles technologies telles que l?EDGE et l?UMTS.

> Capacité multi-slot

Etant donné que la tarification GPRS est effectuée au volume, il est intéressant de chercher un moyen pour accélérer les transferts sans pour autant augmenter les coûts. La solution la plus simple est de transmettre sur plusieurs Time Slots simultanément.

Car comme expliqué précédemment, le GPRS utilise le support de transmission radio du GSM, 8 TS sont disponibles par porteuse radio. Ces 8 TS sont partagé entre GSM et GPRS, l?affectation des TS peut ~tre réalisée dynamiquement en fonction des besoins des utilisateurs.

L?opérateur définit un nombre de TS minimum et maximum alloué au GPRS et le réseau s?adapte au besoin de la cellule.

En théorie il serait possible d?utiliser les 8 TS d?un canal radio pour des transferts GPRS. Mais dans la pratique ce cas ne se présente que très rarement, car il supposerait que l?opérateur ait alloué la totalité du canal radio au GPRS et qu?aucun autre utilisateur ne soit présent dans la cellule.

21

Souleymane THIONGANE Ousseynou NDOYE

Les téléphones mobiles ont donc des capacités multi-slot qui sont définies par :

· un nombre maximum de TS utilisable simultanément

· un nombre maximum de TS en lien descendant

· un nombre maximum de TS en lien montant

· un écart minimum en nombre de TS entre le lien montant et descendent, les mobiles les plus performants peuvent aussi utiliser des TS simultanément sur des fréquences différentes.

Voici un tableau définissant les différentes classes de mobiles répondant aux caractéristiques ci-dessus :

Tableau 1 : Les classes de Mobiles

II. Les Services à Valeurs Ajoutées

1. Definition

Un service à valeur ajoutée est une application, cumulant des notions de Télécommunications et d?informatiques, dont l'usage fait l'objet d'une tarification qui s'ajoute à celle des services supports utilisés par l'application. Il présente donc un caractère purement commercial. Certains services à valeur ajoutée sont vendus sur des réseaux à valeur ajoutée, d'autres sont vendus sur le réseau public.

2. La Réglementation

Au Senegal le fonctionnement et la mise en place de services à valeur ajoutee sont sous le contrôle et la supervision de l?ARTP (Agence de Regulation des Telecommunications et des Postes).

Leur déploiement fait l?objet d?une loi qui fixe la liste et les conditions requises pour mettre en place ce type de services.

La législation des services à valeurs ajoutées est régie par l?article 19 du code des telecommunications dont voici un extrait :

Article premier

La liste des services à valeur ajoutée visés à l?article 19 du code des télécommunications est fixee comme suit :

· Messagerie électronique : L'echange, la lecture et le stockage d'informations, sous forme de messages de donnees, entre des machines se trouvant dans des sites distants. Le destinataire du message n'est pas necessairement present au moment de l'envoi du message. Elle est regie par les recommandations de l'Union Internationale des Telecommunications X-400 et X- 500 de l'UIT-T.

· Messagerie vocale: L'échange (la réception et/ou l?envoi) et l'enregistrement de messages vocaux dans des serveurs vocaux, accessibles à partir d?équipements terminaux appropries. Elle est regie par la recommandation de l'Union Internationale des Telecommunications X-485 de l'UIT-T.

· Audiotex: La mise à la disposition des usagers d'accès à des serveurs, interactifs ou non, pour enregistrer, lire ou écouter des messages à partir d?équipements terminaux appropries.

· Echange de données informatisé (EDI): L'echange de donnees formatees de manière standard entre les differentes applications tournant sur les ordinateurs de partenaires commerciaux avec un minimum d'interventions manuelles.

· Télécopie améliorée: La mise en place de serveurs permettant de transmettre et de reproduire à distance divers documents (lettres, photos et dessins) avec la possibilite d'archivage et d'accès à ces documents.

23

Souleymane THIONGANE Ousseynou NDOYE

·

Services d'information on-line: L'accès à des informations en ligne, en temps réel et sans intervalles d'attente.

· Services d'accès aux données, y compris la recherche et le traitement des données: L'accès à des informations stockées dans des serveurs et/ou des bases de données en utilisant notamment l'infrastructure du réseau téléphonique public ou des réseaux de transmission de données et des interfaces d'adaptation.

· Transfert de fichiers et de données: Le transport et l'échange de fichiers et de données informatiques, constitués de textes et d'images, éventuellement animées, entre des machines hétérogènes se situant sur des sites distants. Il permet également le téléchargement de fichiers et de données à partir de machines distantes.

· Conversion de protocoles et de codes: L'adaptation des protocoles utilisés par des machines différentes, dont la représentation interne des données est différente, afin de permettre la communication entre ces machines.

· Services Internet: La messagerie électronique, le transfert de fichiers, la connexion à une machine distante, le dialogue sous forme de messages écrits sur des sujets variés entre des groupes d'utilisateurs en temps réel et la recherche d'informations dans des serveurs.

· Services mobiles: ,l A¹DIBM1-A A1-IYIE1-A ANYDntA:

ü le SMS : message texte envoyé vers un téléphone mobile depuis un autre téléphone mobile ou depuis un ordinateur

ü le WAP (Wireless Application Protocol) : Protocole d'application sans fil qui permet de se connecter à Internet grâce à un téléphone mobile

ü l¹I-Mode : permet à ses utilisateurs un accès Data à des services au travers d'Internet. Service destiné à l'univers des télécoms, il peut être également déployé sur des terminaux aussi divers que les consoles de jeux, les télévisions, etc.

ü Le MMS (Multimedia Messaging Service) : service de messagerie pour les appareils mobiles qui s'apparente au SMS. Le MMS permet l'envoi automatique et immédiat de messages multimédias personnalisés de téléphone à téléphone ou d'un téléphone à en compte e-mail. Outre les contenus textuels habituels des messages courts, les messages multimédias peuvent aussi contenir des photos, des graphiques, des clips audio et vocaux.

Chapitre 2 : i ⁱr IpI
GlipLIMIs 006

I. Présentation du protocole WAP

1. Definition

Le WAP, standardisé par le WAP Forum, est un protocole de communication dont le but est de permettre aux abonnés d?un opérateur mobile d?accéder à Internet à l?aide de terminaux mobiles. En plus de la connectivité à Internet, ce protocole a été conçu pour offrir la possibilité aux opérateurs d?intégrer de nouveaux services multimédias sur leurs infrastructures.

2. Generalites

Le protocole WAP comprend deux versions. Pour la première version, on essayait de profiter du service de transmission de donnés basé sur la commutation de circuit comme pour le cas du GSM. Mais lorsqu?on est passé à la commutation de paquets dans les réseaux mobiles, en vue d?optimiser les ressources et d?améliorer la bande passante, le protocole WAP a aussi évolué pour s?adapter à cette nouvelle infrastructure.

a. Le WAP 1

Les premiers terminaux mobiles avaient des optionalités très limitées, ils ne permettaient pas
d?afficher du contenu multimédia. Pour offrir des services basés sur la transmission de

25

Souleymane THIONGANE Ousseynou NDOYE

données, le WAP, dans sa première version, a spécifié des protocoles (voir Annexe A) qui avaient pour rôle d?optimiser le contenu des serveurs et de l?adapter à ces terminaux, offrant ainsi d?autres services aux abonnées que la téléphonie et le SMS. Cependant, cette version du WAP n?a pas connu un grand succès et a été très vite délaissée à cause de son manque d?interactivité.

b. Evolution vers le WAP 2 Avec l?évolution des réseaux mobiles et l?amélioration considérable de la bande passante.

On était contraint de faire évoluer le protocole WAP pour mieux utiliser ces ressources, surtout avec la nouvelle génération des terminaux mobiles qui supportent les protocoles de transports classiques d?Internet.

Cette nouvelle version du protocole WAP introduit de nouvelles fonctionnalités multimédias, telles que le « Streaming » ou le téléchargement de contenu multimédia volumineux. Pour cela, la pile protocolaire de ce standard a été redéfini (voir annexe A).

Ainsi, les utilisateurs équipés de terminaux compatibles WAP 2 auront l?accès à des applications plus riches, avec des graphiques en couleur et des possibilités textuelles accrues.

Cette modification de la pile de protocole sur la quelle se base le WAP rend plus facile le développement et l?intégration de nouveaux services puisqu?on pourra profiter de l?expertise acquise du monde informatique et plus précisément du domaine du développement web pour implémenter des services multimédias.

c. La passerelle WAP

Afin de permettre aux terminaux mobiles d?accéder à Internet, le protocole WAP définit une architecture spécifique. Il s?agit de connecter le réseau mobile de l?opérateur à une passerelle, connue encore sous le nom de passerelle WAP ou « WAP Gateway », cette passerelle joue le rôle d?interface entre le mobile et le serveur et permet ainsi d?adapter les messages transmis au protocole de communication correspondant. Cette entité du réseau encode les documents WML ou XHTML, selon la version du protocole utilisée, avant leur envoi au mobile, et dans l?autre sens, elle crée des requ~tes HTTP à partir des requêtes WAP.

Elle est également utilisée par les fournisseurs de services pour récupérer certains paramètres de l?utilisateur, comme le MSISDN, pour contrôler l?accès à leurs services.

Pour conclure voici un schéma récapitulatif de l?architecture du réseau sur laquelle se base le protocole WAP.

Figure 4 : Architecture du protocole WAP

II. Présentation du service MMS

A. Qu'est ce que le MMS ?

1. Définition et Apports

a. Définition

Le MMS ou « Multimédia Message Service » a été conçu par les opérateurs téléphoniques et
les constructeurs en 2002 pour permettre aux utilisateurs d?échanger plus que du texte, du

27

Souleymane THIONGANE Ousseynou NDOYE

multimédia.

Concrètement, le MMS est au multimédia ce que le SMS est au message texte. Le MMS, tout comme le SMS, peut se transmettre de deux manières différentes :

· Le message échangé entre deux utilisateurs: Message interpersonnel

· Le message échangé entre un serveur de contenu et un utilisateur: Message de contenu.

b. Apports

A sa création, le MMS fut basé sur le mail tout en essayant d?éliminer toutes les contraintes rencontrées par les concepteurs du mail mobile, en mettant en place un packaging et une standardisation pour la conception et la lecture d?un MMS. Quelques apports du MMS par rapport au mail mobile :

· Adressage par le numéro du mobile (et non plus par une adresse mail, lisible de partout)

· Système de notification automatique, transparente pour l?utilisateur (comme le SMS)

· Adaptations des pièces jointes multimédia en fonction des téléphones selon la taille de l?écran ou la résolution

· Mise en forme dans le message des textes et pièces jointes (système de slides) créée directement par l?utilisateur (ou le serveur de contenu) qui envoie le message.

· Standardisation des formats, des pièces jointes mais aussi des interfaces de visualisation.

2. Contenus des MMS

Les contenus multimédia envoyés dans un MMS ne peuvent être illimités en nombre et en poids. Les poids maximum dépendent de la capacité des téléphones expéditeurs et destinataires. En général, on peut envoyer jusqu?à 100 Ko, et sur certains terminaux de dernière génération, cette taille peut aller jusqu?à 300 Ko. En ce qui concerne les formats, cela dépend du téléphone du destinataire. Il faut que celui-ci est la capacité de lire la pièce jointe (exemple : lecteur vidéo ou application java). Dans l?absolu, un MMS peut contenir:

· du texte (ASCII ou UTF-8)

· des sons (MP3, AMR)

· des images (JPEG ou GIF)

· des vidéos (MPEG-4, 3PG, WMV)

· d?autres pièces jointes en fonction des possibilités des terminaux (par exemple des applications java).

Bien évidemment, les formats dépendent des possibilités des terminaux

3. Concurrence directe

Il est évident que l'envoi de contenu peut se faire différemment que par l'envoi de MMS. Passons rapidement en revue les autres possibilités :

a. SMS

Le SMS peut contenir du texte ou des éléments de type multimédia limités à hauteur de 160 caractères maximum.

b. Push Wap

Le Push Wap est un procédé utilisé par les concepteurs de services mobiles. Ce procédé consiste à envoyer un SMS à l'utilisateur avec un lien direct de téléchargement du contenu multimédia.

Il est évident que le MMS reste d'une part beaucoup plus ergonomique et d'autre part plus accessible étant donné que les messages restent tous dans une boite de réception de MMS dans les téléphones.

c. Surf Wap

Le MMS va permettre un accès direct au contenu multimédia contrairement au surf. Ce dernier nécessite l'accès au portail puis la recherche du ou des sites désirés et ensuite la navigation dans ce site pour trouver le contenu qui nous intéresse. D'autre part, pour les mêmes raisons que le Push, les messages restent stockés dans la boite de réception des MMS donc une conservation naturelle du message.

B. Fonctionnement

1. Architecture

La figure 5 décrit l?architecture globale du service MMS. Elle implique différents réseaux et doit intégrer les systèmes de messagerie déjà existants dans ces réseaux. Le terminal mobile fonctionne dans l?environnement MMS (MMSE, Multimedia Messaging Service Environment). Cet environnement comprend des réseaux mobiles de 2ème et 3ème génération et fournit toutes les fonctions requises par le service telles que relais, stockage et notification.

29

Souleymane THIONGANE Ousseynou NDOYE

Figure 5 1 171¹IQYir1CQIPIQR0 0 6

a. Entités MMS

Les éléments impliqués dans l architecture sont:

· MMSE : L?environnement MMS représente l?ensemble des éléments MMS, sous le contrôle d?une administration donnée (fournisseur MMS) en charge de fournir le service à des usagers MMS.

· MMS User Agent : Il s?agit de l?application utilisateur présente sur la station mobile permettant de visualiser, de composer et de traiter (i.e., soumettre, recevoir et supprimer) les messages multimédia. Parmi les terminaux MMS disponibles figurent le Nokia 7650 et l?Ericsson T68i & T300.

· User Databases : Il s?agit des bases de données utilisateur contenant l?information concernant les souscripteurs au service MMS. Cette information comprend les détails de souscription et les profils d?usager.

· MMS Relay/Server : Le MMS Relay route les messages dans l?environnement MMS ou à l?extérieur de cet environnement. Le MMS Server stocke les messages en attente de récupération par leur destinataire. Les entités MMS Relay et MMS Server peuvent être implantées dans des équipements distincts ou intégrées dans le même équipement. Dans ce dernier cas, l?équipement est appelé MMSC (Multimedia Messaging Service Centre). Le MMSC s?interface à différents systèmes de messagerie tels que SMSC, système de messagerie électronique et système de messagerie unifiée.

· MMS VAS Applications : Les applications MMS VAS offrent des services à valeur ajoutée aux utilisateurs du service MMS. L?application VAS interagit avec le MMSC afin de délivrer des MMS à des MMS User Agent. Un MMS User Agent peut aussi soumettre un message à une application VAS à une adresse représentée généralement par un numéro court.

31

Souleymane THIONGANE Ousseynou NDOYE

Figure 6 : Architecture MMS

Les différentes entités de l?environnement MMS communiquent à travers un ensemble d?interfaces.

b. Les Interfaces MMS

· L?interface MM1 permet à l?agent utilisateur MMS (MMS User Agent) d?interag avec le MMSC, e.g. soumettre une messagerie multimédia, ftre notifié de l?arrivé d?un message, télécharger un message.

· L?interface MM2 est l?interface entre les entités MMS Relay et MMS Server. Elle n?est pas normalisée. La plupart des solutions des fournisseurs intègrent les deux entités dans le mrme équipement, rendant l?interface propriétaire.

· L?interface MM3 est présente entre le MMSC et les serveurs externes. Elle permet au MMSC d?échanger des messages avec d?autres serveurs de messagerie externes (Email server, SMSC, Unified Messaging Server, etc). Les protocoles pouvant être utilisés sont ceux normalisés par l?Internet tels que SMTP, HTTP, IMAP, POP, et T30.

· L?interface MM4 permet l?échange de MMS entre deux MMSCs appartenant à deux environnements MMS distincts. Le protocole utilisé est SMTP.

· L?interface MM5 permet au MMSC d?interroger le HLR pour identifier la localisation de l?usager et ainsi pouvoir lui envoyer une notification pour l?informer de l?arrivée d?un message multimédia. Le protocole utilisé est MAP. Si le MMSC s?appuie sur un SMSC pour l?envoi d?un SMS, l?interface MM5 n?est pas indispensable.

· L?interface MM6 qui n?est pas encore normalisée permet au MMSC d?accéder aux informations des bases de données des usagers MMS telles que les données de présence.

· L?interface MM7 permet le transfert de messages multimédia d?un MMSC vers des applications VAS et vice versa. Lorsque l?application envoie un MMS au MMSC, il est délivré à l?ensemble des destinataires à travers l?interface MM1. Parmi les protocoles utilisés pour la réalisation de cette interface figurent HTTP et SMTP.

· L?interface MM8 permet au MMSC d?interagir avec le système de facturation. Elle n?est pas encore normalisée. Alors que les messages courts SMS sont émis et reçus sur des canaux de signalisation du réseau SS7 entre le MSC/SGSN et le SMSC, les messages multimédia sont transmis sur les canaux de parole GSM ou dans les contextes PDP GPRS.

2. Fonctionnement du service

L?exemple suivant montre le fonctionnement du service MMS

33

Souleymane THIONGANE Ousseynou NDOYE

1.

L?utilisateur active le client MMS (application disponible sur la station mobile permettant l?envoi / la réception de MMS).

2. L?utilisateur sélectionne ou introduit l?adresse du destinataire du message multimédia.

3. L?utilisateur compose / édite le message multimédia à émettre (e.g. avec une image, du texte et /ou du son).

4. L?utilisateur émet le message multimédia à son MMSC à travers l?interface MM1.

5. Le MMSC de l?émetteur relaye le message multimédia au MMSC du destinataire à travers l?interface MM4, en supposant dans cet exemple que l?émetteur et le récepteur du message multimédia n?appartiennent pas au mrme MMSE.

6. Le MMSC destinataire émet une notification (en s?appuyant par exemple sur les services d?un SMSC) au client MMS destinataire sur l?interface MM1.

7. Le client MMS destinataire télécharge le message multimédia stocké sur le MMSC jà travers l?interface MM1.

8. Le client MMS destinataire notifie l?utilisateur de l?arrivée d?un nouveau messag multimédia.

9. L?utilisateur visualise le message sur sa station mobile.

Les étapes 1, 2, 3, 8 et 9 concernent l?interface utilisateur et sont dépendantes d?une implantation d?un constructeur donné.

Figure 7 : Envoi d'un message multimédia : Flux d'information

Le MMS UA émetteur soumet son message multimédia au MMSC auquel il est associé sur l?interface MM1 en utilisant la requ~te MM1submit.REQ. Le MMSC acquitte la requ~te par une réponse MM1-submit.RES. Cet acquittement contient l?état de la requ~te soumise au MMSC. La demande peut être acceptée ou refusée (e.g. absence de souscription, service indisponible, message incorrect, etc.).

Après acceptation de la requête, Le MMSC émetteur identifie le(s) MMSC(s) associé(s) au(x) récepteur(s).

Plusieurs possibilités existent :

35

Souleymane THIONGANE Ousseynou NDOYE

·

L?émetteur et le destinataire du MMS appartiennent au mrme MMSE. Dans ce cas, ils sont associes au même MMSC.

· L?émetteur et le destinataire appartiennent à des environnements MMS différents. Le destinataire est associe à un autre MMSC auquel le MMSC emetteur relaye le message multimédia sur l?interface M4 en utilisant la requ~te MM4forward.REQ.

· Le destinataire n?est pas un utilisateur du service MMS. Il s?agit par exemple d?un destinataire disposant du service SMS ou d?un compte de messagerie électronique. Le MMSC émetteur relaye alors le message sur l?interface M3 au serveur de messagerie du destinataire (SMSC, serveur E-mail, serveur de messagerie unifiee).

Dans le second cas, le MMSC destinataire retourne un acquittement MM4_forward.RES indiquant le statut de la demande (e.g. absence de souscription du destinataire, service indisponible, acceptation de la demande). Le MMSC destinataire emet une notification (requête MM1_notification.REQ) au destinataire l?informant de l?arrivée d?un MMS, acquittee par ce dernier (reponse MM1_notification.RES).

Le destinataire demande le telechargement du message (requête MM1_retrieve.REQ) qui lui est retourne dans la reponse MM1_retrieve.RES. Le destinataire acquitte alors la reception du message multimedia au MMSC par une requête MM1_acknowledgement.REQ.

Si le MMS UA émetteur indique dans la requ~te MM1submit.REQ la demande d?un rapport de livraison, le MMSC destinataire le genère (MM4_delivery_report.REQ) et le retourne au MMSC d?origine.

Ce dernier produit alors la requ~te MM1deliveryreport.REQ sur l?interface MM1 reçue par le MMS UA emetteur.

Si le MMS UA émetteur indique dans la requ-te MM1submit.REQ la demande d?un rapport à la lecture du message par le destinataire, le MMSC destinataire le genère (MM4readreplyreport.REQ) et le retourne au MMSC origine qui l?acquitte (MM4_read_reply_report.RES).

Enfin, le MMSC origine delivre le rapport (MM1_read_reply_originator.REQ) au MMS UA émetteur sur l?interface MM1.

a. Format et Mise en forme

· Format

Le MMS, étant basé sur le mail, il a gardé le même format : le MIME (Multipurpose Internet Mail Extensions) Donc, le MMS est un message MIME comprenant:

· le fichier SMIL (voir annexe B) qui décrit le déroulement de l'affichage des pièces jointes et des textes (à l'instar d'un fichier PowerPoint).

· Les pièces jointes envoyées dans le MMS qui sont mis en forme par le fichier SMIL (multimédia et texte).
Tout ceci est intégré dans une enveloppe (parfois différente en fonction de l'interface par laquelle le MMS sera envoyé).

Figure 8 : Enveloppe MMS

· Mise en forme

Comme cela a été dit précédemment, un message peut être envoyé avec une certaine mise en forme. Cela est possible grâce au langage SMIL qui est basé sur le XML. Celui-ci permet de définir plusieurs slides avec un agencement des pièces jointes à la guise de l'expéditeur (texte au dessus ou en dessous d'une image, bande sonore qui tourne sur une slide ...). De plus, il est également possible, de déterminer le temps d'affichage de chaque slide.

37

Souleymane THIONGANE Ousseynou NDOYE

Figure 9 : Exemple de représentation de slides

? Gestion des droits numériques sur le contenu

Lorsqu'un MMS est envoyé à un utilisateur, il a la possibilité de le garder dans sa boite de réception de messages multimédia. Cela est un avantage précieux pour l'utilisateur qui peut devenir un gros inconvénient pour les éditeurs de services. En effet, plus rien n'empêche l'utilisateur de renvoyer ou de revoir, réécouter le fichier multimédia autant de fois qu'il le souhaite.

Pour pallier à ce problème, un mécanisme de protections à été mis en place : DRM Dans ce modèle, il a été prévu 3 niveaux différents:

· Niveau 1 - Forward Lock : Usage illimité du contenu mais le contenu ne peut être retransmis.

· Niveau 2 #177; Combined Delivery : Contenu régi par des droits (3 écoutes maxi pour un son), le contenu ne peux être transmis et les droits d'accès sont inclus dans le contenu.

· Niveau 3 #177; Separate Delivery : Contenu régi par des droits, les droits d'accès sont indépendant du contenu et le contenu peut être transmis.

a. Envoi de MMS

? change

L'échange de MMS s'effectue grâce aux 2 médias : le Wap et le SMS.

L'envoi du MMS par l'utilisateur est une connexion Wap au MMSC (MMS Center) de l'opérateur. Par la suite, les caractéristiques du MMS à envoyer sont remises au MMSC (destinataire, contenu).

La réception d'un MMS se fait donc en deux temps :

· Le client MMS du mobile reçoit un SMS en binaire lui indiquant qu'un MMS est disponible

sur le MMSC de l'opérateur

· Ensuite, une connexion Wap s'effectue sur le MMSC pour récupérer le message.

Figure 10 : Echange de MMS

· Accusé de réception

De par la multiplication d'intermédiaire lors d'un envoi de MMS, il existe 4 types d'accusés de réception :

· Dépôt sur le serveur MMSC

Ce statut est généré par le serveur MMSC dès qu'il a reçu le message. Quand le message est enregistré, il envoie directement le SMS de notification à l'utilisateur

· Accusé de réception du SMS de notification

Ce statut est généré lorsque le SMS de notification a été reçu par l'utilisateur. Normalement, suite à ça, l'utilisateur télécharge directement le MMS.

· MMS « Accusé de livraison »

Statut signifiant que le MMS a bien été téléchargé par le téléphone.

· MMS Read-Reply Report

Ce statut indique que le message a été ouvert par l'utilisateur final. Attention, ce statut n'est pas compatible avec tous les terminaux, et pour ceux qui le sont, ce statut peut être désactivé par l'utilisateur.

b. Compatibilité

· Configuration requise

Pour recevoir un MMS, un utilisateur doit mettre en place quelques informations sur son mobile afin qu'il soit compatible.

Tout d'abord, le téléphone doit être obligatoirement équipé de la fonction MMS. Ensuite, l'utilisateur doit paramétrer son téléphone. Cela consiste à créer une connection wap (GPRS ou 3G) et indiquer l'adresse wap du MMSC.

39

Souleymane THIONGANE Ousseynou NDOYE

Enfin, l'utilisateur doit être déclaré sur le MMSC et chez l'opérateur comme ayant le droit et la possibilité de recevoir le MMS. Cela permet aux opérateurs d'avoir la liste des utilisateurs pouvant recevoir les MMS ou non.

Dans le cas de messages interpersonnels, si l'utilisateur final n'est pas compatible avec la fonction MMS, celui-ci reçoit donc un SMS l'invitant à aller visualiser son MMS, sur le site Internet de l'opérateur.

Dans le cas de messages de contenu, le problème ne se pose pas. En effet, les opérateurs, ayant la liste des utilisateurs compatibles, ne permettent pas l'envoi de MMS à un utilisateur non compatible.

Remarque : il est possible de se faire envoyer, par son opérateur, un SMS binaire de

paramétrage. Cela marche très simplement, on reçoit un SMS, et en l'ouvrant, celui-civa installer directement les paramètres de connexion.

? Variété des terminaux

La standardisation du MMS n'a pas été aussi bien mise en place, au départ, que d'autres normes tel que pour le SMS ou encore l'I Mode (Bouygues Telecom).

Si approximativement 6 mois ont suffi aux opérateurs mobiles français, après introduction de leurs services MMS, pour se mettre d'accord sur l'interopérabilité, on ne peut pas en dire autant quand au format des pièces jointes supportées par les différents terminaux.

Les causes de ce manque de standardisation peuvent s'expliquer par :

· d'une part, l'ouverture du MMS, qui n'a pas, tout de suite, limité les formats accessibles

· d'autre part et surtout à cause de la variété des terminaux, notamment en ce qui concerne la résolution ou la taille de l'écran. De plus, les avancées techniques aidant, les constructeurs de téléphonie mobiles font évoluer leurs modèles : ce qui empêche de niveler par le bas. Les plus grands problèmes rencontrés sont souvent :

· Poids maximum d'un MMS

· Taille des images à afficher (largeur x hauteurs et résolution)

· Les formats des pièces jointes supportés (pour les sons, les vidéos et aussi les images). Chaque constructeur a rendu disponible les caractéristiques de chacun des modèles dans un fichier XML : User Agent Profile.

Dans le cas d'un MMS Interpersonnel, le MMSC a la possibilité de connaître les caractéristiques du mobile de l'utilisateur final. Il est donc possible que celui-ci fasse des modifications de formats ou de taille avant de l'envoyer.

De plus, certains téléphones offrent la possibilité de lire plusieurs types de format ou encore de redimensionner à la taille de son écran si l'image ou la vidéo est plus grande.

Dans le cas d'un MMS de contenu, c'est au fournisseur de contenu de prendre ces modifications à sa charge. En effet, il doit envoyer directement le bon format. Bien évidemment, les deux points évoqués dans le cas d'un MMS interpersonnel seront toujours appliqués mais à une moindre mesure. En effet, un message envoyé depuis un téléphone possède déjà les contraintes du téléphone de l'expéditeur tandis qu'un message envoyé depuis des applications mise en place par un fournisseur de contenu n'a aucune contrainte. Il est donc important pour le fournisseur de contenu d'envoyer des pièces jointes à des formats convenables.

3. MMS et Services à Valeurs Ajoutées

L?interface qui nous intéresse le plus est l?interface MM7 car c?est à travers cette interface qu?on peut éventuellement intégrer de nouveaux services à valeur ajoutée. L?MM7 spécifie les différents protocoles qu?il faut respecter pour pouvoir mettre en place une application qui sera en mesure de communiquer avec L? MMSC. Il s?agit des protocoles SOAP, EAIF et HTTP.

a. Le protocole SOAP

SOAP comme « Simple Object Access Protocol » est un protocole de transmission de messages, il définit un ensemble de règles pour structurer les messages à transmettre, il est particulièrement utile pour exécuter des dialogues requête-réponse. Il n?est pas lié à une plateforme donnée ce qui le rend intéressant pour développer des applications distribuées. Il n?est pas non plus lié à un système d?exploitation particulier, ce qui donne la possibilité aux applications tournant sur des systèmes différents de dialoguer ensemble du moment qu?ils puissent formuler et comprendre les messages SOAP.

Le protocole SOAP est composé de deux parties

41

Souleymane THIONGANE Ousseynou NDOYE

·

Chapitre 3 : Les
Plateformes Utilisées

Souleymane THIONGANE
Ousseynou NDOYE

42

Une enveloppe, contenant des informations sur le message lui-même afin de permettre son acheminement et son traitement.

· Un modèle de donnés, définissant le format du message, c'est-à-dire les informations à transmettre.

Dans le cas de l?interface MM7, on utilise les messages SOAP pour transmettre les différents paramètres de l?utilisateur du service et une déclaration pour chaque fichier attaché au message. Dans cette déclaration, on spécifie le type du message, le codage utilisé, et plusieurs autres paramètres qui ont pour rôle d?informer le récepteur des caractéristiques des messages envoyés (voir Annexe C).

Ces messages sont ensuite encapsulés par le protocole HTTP.

b. Le protocole http

Le protocole HTTP est le protocole le plus utilisé sur Internet depuis 1990. A partir de la version 1.0 du protocole, on peut transférer des messages avec des en-têtes décrivant le contenu du message.

Le but du protocole HTTP est de permettre un transfert de fichiers, à la base essentiellement des fichiers HTML, mais tout autre type de fichier est possible. Les fichiers sont localisés grâce à une chaîne de caractères appelée URL.

I. Présentation

1. KANNEL

a. Etude du logiciel Kannel

La passerelle WAP Kannel est une passerelle WAP et SMS Open Source (source libre).

Lancé en mars 1999, le projet est à l?initiative de la compagnie Finlandaise WAPIT. La passerelle est actuellement disponible pour le système d?exploitation Linux (RedHat et Debian). La version courante est la version 1.4.1 Concernant les fonctionnalités SMS, la passerelle Kannel supporte les principaux protocoles SMS. La passerelle WAP ne supporte pas encore la méthode POST, le mode déconnecté pour le protocole WSP, WTLS et l?identification des clients. Au niveau de la couche transport WDP, seul le

protocole de transport UDP est supporté. La passerelle Kannel est un outil très intéressant pour développer des applications en collaboration avec le serveur Web Apache.

b. Architecture de kannel

L'interface externe de la passerelle

La passerelle possède trois interfaces chacune ne pouvant communiquer qu?avec un type d?équipement spécifique :

o Les centres SMS (SMSC), utilisant divers protocoles.

o Les serveurs HTTP, pour les contenus WAP et SMS et fournit le contenu des « WAP push »

o HTTP est utilisé pour le «pull», et PAP pour le push.

o Les terminaux WAP, implémentant la pile de protocole WAP et (pour le « push WAP Push client.

43

Souleymane THIONGANE Ousseynou NDOYE

Figure 11 : Exemple de l'interface externe

Il existe plusieurs vendeurs de Centres SMS et la plupart d?entre eux utilisent des protocoles propriétaires spécifiques, lesquels sont semblables sur le principe mais diffèrent sur quelques détails. Le principe général de ces protocoles est :

- Le client se connecte au Centre SMS

- Lorsqu? un message est arrivé à partir d?un téléphone, le SMSC l?envoi au client qui par la suite devra l?acquitter.

- Lorsque le client voudra envoyer un message, il émet une requête au SMSC qui l?acquittera.

- Lorsque le client est servi il se déconnecte Kannel est conçu pour pouvoir communiquer avec plusieurs SMSC utilisant des protocoles différents.

Chaque compte SMSC est acheté auprès d?un opérateur mobile. A chaque compte correspond aussi un numéro vers lequel sont acheminés les messages destinés au compte et apparaît comme le numéro expéditeur lorsqu? un message est envoyé via ce compte (n?emprche certaines connections permettent à l?usager de spécifier lui-mrme le numéro de l?expéditeur). Afin de pouvoir traiter le maximum de flux, Kannel a besoin de pouvoir communiquer indépendamment avec chacun des équipements reliés à ses interfaces c?est à dire en opérant par multitâche. Par exemple il ne serait pas assez intéressant de lire une requête par SMS ou WAP, chercher le contenu de la requête par HTTP, de retransmettre le contenu au destinataire et seulement ensuite pouvoir traiter la requête suivante.

Ce serait assez rapide si seulement les serveurs HTTP pouvaient agir avec une extrême rapidité mais ce n?est malheureusement pas le cas. Chaque transaction HTTP peut prendre potentiellement une durée illimité sans pour autant échouer et Kannel ne doit laisser une requ4te HTTP lente priver d?autres requites d?rtre servi Ce que Kannel va faire alors, est de lire aussi rapidement que possible toutes les requêtes provenant de ses interfaces et de les

placer dans une queue interne. Alors il essaiera de faire les requ~tes HTTP aussi vite qu?il le pourra et renvois les réponses aux clients. La réponse à un client dépendra de la durée que prendra sa requête auprès du serveur HTTP.

Le problème qui se pose est lorsque Kannel reçoit un nombre important de requ~te et qu?à la suite il soit hors service, les requites seront perdues. Alors l?idée est de mettre la liste dans une mémoire persistante (disque par exemple), mais cette implémentation n?est pas encore mise en oeuvre.

Division des fonctions : les BOXES

Kannel divise ses différentes fonctions selon trois processus appelés « boxes » basés essentiellement sur le type d?équipement externe avec lequel il veut dialoguer.

Le bearerbox implémentant le niveau porteur du WAP (couche WDP).Il permet entre autre la connexion aux différents SMSC.

Le smsbox implémentant l?essentiel des fonctionnalités de la passerelle SMS. Il reçoit les messages texte depuis le bearerbox et les interprète comme des requêtes vers des services et y répond en utilisant le chemin approprié.

Le wapbox qui implémente la pile de protocole WAP et le WAP Push (protocole de niveau applicatif). Quand le wapbox est utilisé pour le pushing, il est appelé PPG (Push Proxy Gateway). L?autre moyen d?envoi de donnée étant le pulling.

Notons qu?il n?est possible de mettre en place qu?un seul bearerbox tandis qu?il est possible de disposer de plusieurs wapbox et de smsbox.

Disposer de plusieurs wapbox et smsbox peut s?avérer bénéfique surtout lorsque la charge est très importante. Dans ce cas le bearerbox maintient une connexion avec différents wapbox et smsbox grkce à un système de « battement de coeur (semblable au ping)

45

Souleymane THIONGANE Ousseynou NDOYE

Figure 12: Boxes of pull Kannel

o Le Bearerbox

Le bearerbox reçoit les messages UDP envoyés depuis les téléphones, les réachemine vers les wapbox, reçoit les réponses envoyées par les wapboxes, et envoie le message UDP correspondant aux mobiles. Puisque pouvant être connecté à plusieurs wapboxes, le bearerbox doit être capable de router les paquets UDP. Pour cela, tout paquet provenant du même mobile sera routé vers le même wapbox durant une session. En pratique, le problème du routage est simplifié car tout paquet provenant d?une mrme adresse IP sera acheminé vers le mrme wapbox.

En effet les terminaux mobiles obtiennent des adresses de façon dynamique. Lorsque qu?un terminal désire communiquer avec la passerelle, celui-ci lui attribue automatiquement une adresse IP qui permettra son identification tout au long de la transaction. Une fois celle-ci achevée, le terminal mobile libère son adresse IP qui pourra alors être attribuée à un autre client.

Le bearerbox fait appel à plusieurs threads et fil d?attente au niveau de la passerelle, son fonctionnement interne est décrit par la figure suivante

Figure 13: Architecture du Bearerbox

o LE Wapbox

Lorsque le «pulling» est utilisé, le Wapbox lit les messages depuis le bearerbox, maintient un état interne de chaque client et émet les requêtes HTTP pour le compte des clients. Il répond aux messages conformément aux spécifications du WAP. Les fonctions de base sont assez simples mais les choses deviennent compliquées lorsque la charge commence à devenir lourde.

Au niveau de l?implémentation, seuls WTP et WSP sont pris en compte. W TLS existe mais sous forme de module. Coté transport, UDP est actuellement le seul protocole utilisé dans WDP ce qui signifie que WCMP (Wireless Control Message Protocol) n?est pas implémenté. En ce qui concerne les messages « push », ils peuvent être confirmés ou non confirmés. Dans le second cas, le PPG envoi le contenu push au bearerbox (en lui demandant de faire un SMS

47

Souleymane THIONGANE Ousseynou NDOYE

(push).Pour le push confirmé, s?il est orienté-session, la passerelle demande d? abord au mobile d?établir une session avec lui. Le PPG maintient la session et envoi les données au mobile et lui envoi aussi des confirmations si nécessaire. Outre ces deux types de push, Kannel peut aussi fonctionner comme une passerelle pull. Le Wapbox envoi les contenus push via SMS, mais la requête résultante utilise un support IP.

KANNEL comme passerelle SMS

Le SMS, Short messaging Service, est un moyen d?envoi de messages courts (160 caractères) jà partir d?un mobile GSM vers un autre. Il permet, en plus de l?envoi de texte simple,

d?envoyer des contenus avancés comme les logos d?opérateurs, les sonneries dappels, les cartes d?affaires et les configurations de mobiles.

Les services SMS sont des services initiés par des messages SMS envoyés vers un numéro de téléphone (le plus souvent court) et qui répondent à des requêtes qui leurs sont adressées. Quand les services SMS sont utilisés, le client (terminal mobile) envoie un message

SMS à un certain numéro, qui pointe vers un centre SMS précis. Ce centre SMS envoie le message à son destinataire en utilisant un protocole spécifique. Par exemple un centre SMS Nokia utilise le protocole CIMD.

En pratique chaque SMSC différent utilise un protocole différent, une passerelle SMS est utilisée pour rendre possible la connexion entre SMSC différents.

Le grand apport de Kannel est de translater chaque protocole SMSC vers le protocole http, ce qui simplifie le déploiement des services.

Figure 14 : Kannel comme passerelle SMS

Une passerelle SMS peut aussi être utilisée pour relayer les messages SMS du réseau GSM vers un autre type de réseau.

48

Souleymane THIONGANE Ousseynou NDOYE

Kannel fonctionne comme une passerelle SMS, pouvant communiquer avec plusieurs types de SMSC et routant les messages qu?il reçoit vers des fournisseurs de contenus, sous forme de requêtes http. Ces fournisseurs de contenus répondent à la requête et la réponse est retournée au mobile avec la connexion au SMSC requise et le protocole requis.

En plus du fait de servir les SMS-MO (provenant du mobile), Kannel fonctionne aussi comme une passerelle « push », les fournisseurs de contenus peuvent demander à Kannel denvoyer des messages aux terminaux.

Kannel va alors déterminer le bon SMSC vers lequel transiter le message en utilisant encore le protocole requis. De ce fait le fournisseur de contenus n?aura pas à connaître un protocole SMSC mais juste l?interface de Kannel vers lequel il enverra le message.

KANNEL comme passerelle WAP

WAP, abréviation de Wireless Application Protocol, est une collection de divers langages et outils et une infrastructure pour mettre en application des services pour des téléphones portables. Traditionnellement de tels services ont fonctionné par l'intermédiaire des appels normaux de téléphone ou des messages textuels courts (par exemple, messages SMS dans des réseaux de GSM). WAP permet de mettre en application des services semblables au World Wide Web.

~ la différence de l?attente des usagers, WAP n'apporte pas la teneur existante de l'Internet directement au téléphone. Il y a trop de problèmes techniques et autres pour que ceci ne travaille correctement. Le problème principal est que le contenu d'Internet est principalement sous forme de pages HTML, et ils sont écrits de telle façon qu'ils exigent les raccordements rapides, les unités de traitement rapides, les grandes mémoires, les grands écrans, la sortie audio et souvent également les mécanismes assez efficaces d'entrée.

En plus, les téléphones portables ont des processeurs très lents, la mémoire très petite, la largeur de bande insondable et intermittente, et les mécanismes extrêmement maladroits d'entrée. La plupart des pages existantes de HTML ne fonctionne pas sur des téléphones mobiles, et ne le feront jamais.

WAP définit un langage complètement nouveau le Wireless Markup Language (WML), qui est plus simple et beaucoup plus strictement définie que le HTML. Il définit également un langage de script, WMLScript, que tous les navigateurs doivent avoir pour le supporter. Pour rendre des choses encore plus simples pour les téléphones, il définit même son propre format à mémoire d'image (Wireless Bitmap, ou WBMP).

Le HTTP est également trop inefficace pour l'usage sans fil. Cependant, en employant un format binaire et compressé sémantiquement semblable il est possible de ramener les frais

49

Souleymane THIONGANE Ousseynou NDOYE

généraux de protocole à quelques octets par demande, au lieu des centaines habituelles

RI?RFAIAM. $ InMi, 1 $ 3 RINIQA ,QRR,NeOODISiODIRIeISIRARFROeli FP SORyer. Cependant, pour rendre des choses plus simples également pour les personnes mettant en application réellement les services, WAP présente une passerelle entre les téléphones et les serveurs fournissant le contenu aux téléphones.

Figure 15 : Kannel comme passerelle WAP

La passerelle WAP communique avec le téléphone en utilisant une pile de protocole WAP, et traduit les demandes qu'il reçoit au HTTP normal. Ainsi les fournisseurs de contenu peuvent utiliser tous les serveurs de HTTP et utiliser le savoir-faire existant au sujet de l'exécution et de l'administration de service de HTTP.

En plus des traductions de protocole, la passerelle compresse également les pages

WML dans une forme plus compacte, pour sauver la largeur de bande Over-The-Air et pour réduire plus loin les conditions de traitement du téléphone. Il compile également des programmes de WMLScript dans un format bytecode. Les dernières caractéristiques du WAP définissent quelques conversions additionnelles que Kannel commence à mettre en application.

Kannel n'est pas simplement une passerelle WAP. Il fonctionne également comme passerelle SMS. Bien que le WAP soit la technologie chaude et techniquement supérieure, les téléphones SMS existent en grand nombre et les services SMS sont ainsi tout à fait utiles. Par conséquent, Kannel fonctionne simultanément comme passerelle WAP et SMS.

Kannel et la sécurité

( QF1 11,1FRnFeIKe O?EFFqM i RIiMAWFTII, FRIERx, I] DnnIO ,AiOiMe 166/ SR,r OeM AEIKMaFAiRnM sécurisées entre le bearerbox et les smsbox et wapbox auxquels il est connecté.

Souleymane THIONGANE Ousseynou NDOYE		50

L?administration à distance peut également ~tre assurée gr~ce à une connexion sécurisée.

L?accès des utilisateurs à la passerelle peut ~tre entièrement sécurisé et contrôlé en spécifiant des utilisateurs avec mots de passe dans le fichier de configuration. De ce fait tout utilisateur désirant envoyer un SMS, par exemple, devra au préalable entrer son login et mot de passer définis dans le groupe sms-user du fichier de configuration ou même dans un autre fichier. Kannel prévoit aussi des certificats pour les connexions http sécurisées (exemple

https). Ces certificats permettent de vérifier l?authenticité d?un serveur ou d?un client.

2. MBUNI

MBUNI est une passerelle Open Source au service de la messagerie multimédia (MMS). Il intègre à la fois les fonctionnalités du réseau commutation MMS (MMSC) ainsi que la passerelle de messagerie (c'est-à-dire l'intégration de l'infrastructure MMSC), et est idéal pour les opérateurs et fournisseurs de services à valeur ajoutées basés sur le MMS.

a. Historique

· 28/07/2008: version 1.4.0 disponible

· 12/09/2007 « Commercial (non-GPL) licences mbuni » maintenant disponibles par le biais de Skycore. Cela comprend l'octroi de licences pour mbuni gestion des droits numériques (DRM) Plug-in.

· 26/07/2007 : version 1.3.0 publiée

· 28/11/2006 : version 1.2.0 est disponible!, Installateurs Binaires disponibles. Cette version inclut plusieurs corrections de bugs et améliorations (en particulier la Gateway SVA) depuis la dernière version.

· 09/03/2006 : version 1.1.0 disponible! Installateurs Binaires disponibles. Principaux changements: désormais Mbuni fonctionne à la fois en MMSC et en Passerelle SVA.

· 17/10/2005 : la version de développement de Mbuni inclut maintenant les fonctions de passerelle SVA.

· 27/07/2005 : version 1.0.0 disponible!, Installateurs Binaires disponibles.

· 27/06/2005 : version 0.9.9 publiée, installateurs binaires disponibles.

· 27/04/2005 version 0.9.8 publiée, installateurs binaires disponibles.

· 18/04/2005 Mbuni (version de développement) soutient MMS SVA (deux protocole sur l?interface MM7 : SOAP & EAIF) et la fonctionnalité MMBox.

51

Souleymane THIONGANE Ousseynou NDOYE

. 04/03/2005 version 0.9.7 publiée avec quelques nouvelles fonctionnalités et correctifs. . 05/02/2005 Première version (v0.9.6) disponible.

Le développement initial de la passerelle MMS a commencé en Septembre 2003 et a été achevé au début de 2004, et c'est dans cette période que Mbuni a commencé à explorer le monde du libre. Tout le développement initial a été réalisé parDigital Solutions, même si nous avons une dette de gratitude à Kannel, dont nous utiliserons le WAP et le SMS dans une partie de la Passerelle.

b. Fonctions

La passerelle MMS, MBUNI, est un système logiciel modulaire, conçu pour être entièrement équipé, simple et efficace, en soutenant la génération actuelle de messagerie multimédia. Mbuni fonctionne en deux modes: En tant que MMSC ou une passerelle SVA.

. Fonctionnant comme MMSC, Mbuni prévoit:
v' La messagerie entre téléphone

1' Adaptation automatique du contenu: Le serveur modifie le contenu des messages en fonction des capacités du terminal de réception

v' Passerelle email-to-MMS et MMS-to-email

1' Support pour le stockage de messages pour les abonnés (mmsbox). v' échange de messages Inter-MMSC (interface MM4)

v' Support pour des fournisseurs de services à valeurs ajoutées MMS utilisant les protocoles de l?interface MM7 (SOAP ou EAIF).

v' Soutien à l'intégration avec la base de données abonné pour permettre la manipulation d'appareils qui ne supportent pas les MMS, les combinés non provisionnés, etc.

1' Facturation

. Fonctionnant comme une passerelle SVA, Mbuni prévoit:

1' Supporte à la fois SOAP et EAIF pour une connectivité avec un opérateur MMSC

1' Connexions multiples à différents MMSC de différents types peuvent être maintenues

1' MMS de contenu peut être chargé à partir du fichier, URL ou de la sortie d'un programme

1' MM composition de SMIL: La passerelle récupérait automatiquement tous les composants référencés dans le SMIL et les ajoutait à la MM.

1' Une interface Web pour l'envoi MM.

La Passerelle est conçue et testée pour se conformer à l'Open Mobile Alliance (OMA), WAP et 3rd Generation Partnership Project (3GPP) MMS normes, y compris:

· WAP: 209

· OMA: MMS v1.2, UAProf v1.1

· 3GPP TS 23.140

II. Installations et Configurations

1. Pré-requis

a. Choix du Systèmes d'Exploitation

Les logiciels utilisés pour la majorité étant du domaine du libre, la passerelle sera installée et testée sur un environnement linux. Il est préférable de choisir le DEBIAN ETCH 4, car ce système est moins gourmant en ressource par rapport à un système UBUNTU ou FEDORA. DEBIAN est l?un des systèmes les plus utilisés en ce moment et surtout dans les milieux universitaires et sur les forums. Donc il est aisé de trouver de la documentation en ligne concernant la plus part des sujets avec cet avantage de pouvoir aussi visiter les sites et forums UBUNTU.

Mbuni est aussi en cours de développement sous MacOS X et Linux en utilisant le langage de programmation C.

Le système tourne sur un Pentium 3, 596MHZ, 128Mo.

b. Les Paquets requis et leurs installations

· Compilateur et bibliothèques de C pour la norme ANSI C, avec des prolongements normaux d'Unix tels que des douilles de schéma et des outils relatifs. (Le toolchain du GCC du GNU est recommandé)

53

Souleymane THIONGANE Ousseynou NDOYE

·

La bibliothèque de Gnome XML (connue sous le nom de gnome-xml et libxml), version 2.2.5 ou plus nouveau.

Si vous l'installez des paquets de votre distribution, vous aurez besoin de libxml2-dev en plus des bibliothèques d'exécution du paquet libxml2.

· GNU MAKE

· Une implémentation de thread POSIX (pthread.h)

· GNU Bison 1.28, si vous voulez modifier le compilateur de WMLScript (un analyseur pré-créé est inclus pour ceux qui veulent juste compiler Kannel).

· Les outils DocBook: DocBook Stylesheets , jade, jadetex, etc. ; voir le README, section « documentation », pour plus d'information (les versions pré-formatées de la documentation sont disponibles, et vous pouvez compiler Kannel lui-même même sans outils de documentation).

· GNU autoconf, si vous voulez modifier le script de configuration.

Mbuni utilise un certain nombre de bibliothèques qui font partie de Kannel source, en particulier GWLIB WAP et les bibliothèques. Pour installer Mbuni vous devrez installer Kannel (et donc de s'acquitter de ces dépendances Mbuni part avec elle).

Les composants supplémentaires suivants sont nécessaires:

· Libiconv v2.0 ou une version ultérieure, nécessaire pour la conversion de caractères

· Outils de conversion audio requis par l'adaptation du contenu du module: o Sox

o Lame (V3.93 ou plus)

o Mpg123

· AMR encodeur / décodeur

· Outils de conversion de l'image requise par le module d'adaptation de contenu: o ImageMagick

· Serveur de messagerie, tels que Postfix

· Vous aurez aussi besoin d'être sous une passerelle WAP (Kannel).

· Vous pourrez éventuellement avoir besoin d'exécuter un proxy HTTP tels que Squid car certains téléphones récents (par exemple, Nokia 6600) ne peuvent pas envoyer de MMS via le WAP, mais directement par l'intermédiaire d'un proxy HTTP sur HTTP.

· Obtenir le code source de Kannel, téléchargeable dans http://www.kannel.org/download.shtml. Il est disponible dans divers formats et vous pouvez choisir de télécharger la dernière version: gateway-1.4.1.tar.gz

· Télécharger Mbuni sur www.mbuni.org: mbuni-1.1.4.tar.gz

Les paquets cités plus haut sont plus ou moins faciles à installer, il suffit de suivre cettemethode:

#tar #177;xvzf nom-du-paquet -C /usr/local #cd /usr/local/ # cd nom_du paquet # vim Install

$ IFHQMIX IEUXtELIKI dpmEIFKEETWIRDIRQHMe pFXtM.

Cependant, avec Amr, la demarche change puisque 'il faut télécharger le patch amr et l'appliquer lors de l'installation:

# unzip 26104-520.zip

# mkdir amr

# cd amr

#unzip ../26104-520_ANSI_C_source_code.zip

0 EPLUNRn tplpFKEIJIKDISIIFK TIARMESSGIXETWI:

# patch -p1 < ../mbuni-amr-patch

# make -f makefile.gcc

# cp -f amrdecoder amrencoder /usr/local/bin

2. KANNEL

a. Installation

· Compilation: Se positionner dans le répertoire oil est décompressé (dans notre cas /usr/local/gateway/) kannel et lancer les commandes :

#./configure

55

Souleymane THIONGANE Ousseynou NDOYE

# make

· Installation: Dans le répertoire d?installation on tape :

# make install

b. Configurations

Le fichier de configuration peut être divisé en trois parties :

--> configurations de bearerbox --> configurations de smsbox --> configurations de wapbox

La partie Bearerbox a un « groupe core» et tous les groupes de Centres SMS, alors que la partie wapbox a seulement un groupe wapbox. Dans la partie smsbox il y a un groupe smsbox et puis bon nombre de groupes sms-service et sendsms-user.

? Configurations de bearerbox

Le Groupe core :

group = core

admin-port = 13000

admin-password = foobar status-password = sTat admin-deny-ip = "*.*.*.*"

admin-allow-ip = "127.0.0.1;200.100.0.*"

smsbox-port = 13003

wapbox-port = 13004

box-deny-ip = "*.*.*.*"

box-allow-ip = "127.0.0.1;200.100.0.*"

wdp-interface-name = "*" log-file = "kannel.log"

log-level = 1

access-log = "kannel.access"

unified-prefix = "+358,00358,0;+,00" white-list = " http://localhost/whitelist.txt"

Le Groupe SMSC :

Il permet de définir les SMSC que Kannel pourra utiliser

group = smsc

smsc = http

system-type = kannel

smsc-username = tester

smsc-password = foobar

port = 13015

connect-allow-ip = "*.*.*.*"

send-url = http://localhost:13015/cgi-bin/sendsms

# SMSC GSM

group = smsc

smsc = at

modemtype = nokiaphone

#wavecom | premicell | siemens | siemens-tc35 | falcom | nokiaphone | ericsson speed = 9600

sms-center = "[phone]"

device = /dev/ttyACM0

#pin = 2345

#validityperiod = 167

· Configurations du smsbox

Le Groupe smsbox :

I1: IIPfIM 1:EDFRQ1.1 ulEtIRn IIe : EQ11:101 .1 ql1 1:?envREHI1:E lPFIBIRn IIeIV V.

57

Souleymane THIONGANE

Ousseynou NDOYE

group = smsbox

bearerbox-host = localhost sendsms-port = 13013 sendsms-chars = "0123456789+"

global-sender = 13013

log-file = "/var/log/kannel/smsbox.log"

log-level = 0

access-log = "/var/log/kannel/access.log"

sendsms-url = /cgi-bin/sendsms

Groupe sendsms-user

Il permet de définir les utilisateurs pouvant utiliser l?envoi de SMS via le web. L configuration se fait en entrant un nom et un mot de passe utilisateur.

group = sendsms-user username = tester

password = foobar max-messages = 3 concatenation = true

Groupe sms-service

Il permet de définir les services SMS à utiliser. Chaque service est identifié par un mot clé et l?application qui se chargera de traiter les requêtes.

group = sms-service

keyword = esp

get-url = " http://localhost/stage/candidat.php?rep=%r"

max-messages = 3

concatenation = true

Parmi ces variables qui spécifient le type de traitement on peut citer :

get-url : définit l?application http qui traitera la requ~te.

File : donne le fichier local à retourner

text : indique le texte à retourner comme réponse à la requête

exec : permet de spécifier la commande shell à executer lorsque le mot clé est envoyé

· Démarrage de la passerelle

Pour démarrer kannel il faut agir comme suit :

- Démarrer d'abord le bearerbox:

#/usr/local/gateway/gw/bearbox /etc/kannel.conf

- Démarrer ensuite le smsbox:

#/usr/local/gateway/gw/smsbox /etc/kannel.conf

-Et ci nécessaire démarrer le wapbox par :

#/usr/local/gateway/gw/wapbox /etc/kannel.conf

3. Mbuni

a. Installation

Le téléchargement de Mbuni fait:

· On décompresse le paquet:

# tar xvzf mbuni-1.4.0.tgz #177;C /usr/local

· On se déplace dans le dossier dans lequel il est décompressé, puis on exécute ces commandes

#./bootstrap
#./configure

59

Souleymane THIONGANE Ousseynou NDOYE

# make #make check # make install

b. Configuration

Le fonctionnement de Mbuni dépend de son utilisation ou mode de fonctionnement.

Mbuni fonctionnant comme MMSC

Pour démarrer le MMSC, vous devez exécuter mmsrelay et mmsproxy. mmsfromemail devrait rtre appelé à partir d?un MTA (SMTP Mailer) pour convertir et délivrer un MMS depuis un email. L'ordre dans lequel ils sont mis en marche n'a pas d'importance.

Mbuni fonctionnant Passerelle SVA

Pour exécuter Mbuni comme Passerelle SVA, il faut lancer la commande mmsbox.

+ Fichier de configuration générale

Tous les programmes prévoient le fichier de configuration de Mbuni qui doit être passé en dernier argument sur la ligne de commande (par défaut mbuni.conf). Le fichier de configuration contrôle la plupart des aspects du fonctionnement de la passerelle.

Le format du fichier de configuration est la même que celle utilisée par Kannel. Le fichier de configuration se compose de groupes de variables de configuration. Les groupes sont séparés par des lignes vides, chaque variable est définie sur sa propre ligne. Chaque groupe commence par le nom du groupe. Les commentaires sont les lignes qui commencent par un dièse (#) et sont ignorés.

Une ligne de définition de variables est le nom de la variable, un signe égal (=) et la valeur de la variable. Le nom de la variable peut contenir n'importe quel caractère sauf l'espace blanc et le signe égal. La valeur de la variable est une chaîne de caractères, avec ou sans les guillemets (" ") autour de lui. Les guillemets sont nécessaires si la valeur commence ou se termine par des espaces ou des caractères spéciaux. La variable group marque le début d'un nouveau

60

Souleymane THIONGANE Ousseynou NDOYE

groupe avec le nom donné.

Le group core, groupe « noyau », est le groupe primaire et définit : l'emplacement du fichier de journalisation, le niveau de journalisation (une somme d?informations de débogage), l'emplacement du fichier journal, l'interface HTTP à écouter pour les connexions entrantes, hôte du proxy HTTP / port au cas échéant (l?hôte du proxy HTTP/port et le nom de l'interface HTTP sont spécifiées en utilisant exactement les mêmes paramètres que ceux utilisés par Kannel.)

group = core

log-file = log/mmsgw.log

log-level = 0 log-level

access-log = log/access.log

http-interface-name = "*" http-interface-name = "*"

Cela devrait être suivi par le groupe de configuration principal (group Mbuni).

group = mbuni

name = "My MMSC"

hostname = ds.co.ug

host-alias = mmsc

local-prefixes = 075;+25675;25675

directory-store = spool

max-send-threads = 5

send-mail-prog = /usr/sbin/sendmail -f %f %t

Le tableau ci-dessous énumère toutes les directives de configuration. La colonne Mode indique le mode de fonctionnement dans lequel le paramètre est applicable: les paramètres de configuration marqués VAS GW ne sont applicables que lors du fonctionnement en mode SAV Gateway, tandis que ceux marqués MMSC ne sont applicables que lors du fonctionnement en mode MMSC. Le reste est utilisé dans les deux modes.

Nom de la variable	Mode	Type		Description	group
TOUT	Mbuni	Variable Obligatoire		name
TOUT	Chaine de	Nom convivial pour la Passerelle, définie

61

Souleymane THIONGANE Ousseynou NDOYE

		caractères		arbitrairement, etc.	hostname
MMSC	Chaine de caractères	Hostname local. C'est ajouté comme un qualificateur à l'adresse d'expéditeur quand les MMS sont expédiés vers courrier électronique ou à un MMSC étranger via SMTP. Sa valeur par défaut est localhost		host-alias
MMSC	Chaine de caractères	hostname réduit du MMSC. Ceci est utilisé dans la FIPltARQUI ' EHP WslI HlAnsA que l' 5 / UM récupération de message (envoyé comme une partie de la notification MMS) : Par exemple si vous l'avez comme MMSC, l'URL de récupération aura la forme http://mmsc/msgtoken (aucun port est ajouté). Assurez-vous de garder cette valeur courte (car il existe des appareils qui n'aiment pas de longs URL dans des notifications de MMS) et il ne doit pas inclure des caractères nonalphanumériques comme cela peut visser l'analyse de l'URL. Si vous ne fournissez pas cette directive, la passerelle créera un long URL de la forme ( http://hostname:port/msgtoken) quand il envoie des notifications		local-prefixes
MMSC	Liste de numéro de préfixe	Les numéros de préfixes que l'on doit considérer local. Les messages destinés aux numéros ^préfixésd'un de cette liste seront livrés en local (via mmsrelay)		storage-directory
TOUT	Nom de répertoire (Chaine de caractères)	Le répertoire oil Mbuni crée des files d'attente de messages, MM Boxes, et les profils User Agent cache. Mbuni crée un ensemble de sousrépertoires ici pour chaque fonction		max-send-threads
TOUT	Entier	Combien de file d'attente traitant des processus pour démarrer. Une valeur plus haute signifie que les messages sont livrés plus rapidement.		send-mail-prog
MMSC	Chaine de caractères	Commande à utiliser pour l'envoi de messages électroniques (MMS-to-mail ou vers une passerelle MMS étrangère via SMTP). Cette commande peut inclure des variables:% f - remplace le message depuis l'adresse,% t ~ remplace l'adresse du destinataire (compatible RFC 822),% s - l'objet du message,% m - l'ID du message (REMARQUE: les caractères spéciaux du shell - &, |, $, (,), et ainsi de suite, sont enlevés après avoir substitué les variables.		strip-prefixes
TOUT	Liste de numéros de préfixes	Un point-virgule (;) sépare les chaînes de préfixes qui devraient (si trouvé) être extraits du numéro de téléphone. Seulement le premier préfixe qui correspond sera extrait.		unified-prefix
TOUT	Liste de	Une chaine pour unifier les numéros de téléphones

		numéros de préfixes		reçus, de sorte que le routage fonctionne correctement.	maximum-send- attempts
TOUT	Entier	Nombre maximum de tentatives que doit faire la passerelle pour délivrer un message avant d'abandonner (par exemple, le portable est éteint, le SVA ou le domaine de messagerie est indisponible)		default-message-expiry
TOUT	Entier	Nombre de secondes par défaut dans lequel le message expire et est effacé de la file d'attente (si elle n'est pas encore rendue).		queue-run-interval
TOUT	Réel	Nombre de secondes entre chaque exécution de la file d'attente		queue-manager- module
TOUT	Chaine de caractères	Bibliothèque qui gère la file d'attente / le stockage et le traitement de message (voir mms_queue.h pour plus de détails)		sendsms-url
MMSC	Chaine de caractères	URL du service par lequel un SMS peut être envoyé à un abonné mobile (par exemple, pour le WAP Push)		sendsms-username
MMSC	Chaine de caractères	Nom d'utilisateur servant de moyen d'authentification pour envoyer des SMS par URL		sendsms-password
MMSC	Chaine de caractères	Mot de Passe servant de moyen d'authentification pour envoyer des SMS par URL		sendsms-global-sender
MMSC	Chaine de caractères	Expéditeur optionnel à utiliser dans un SMS-URL		mms-port
MMSC	Entier	Port sur lequel écoute le mmsproxy pour des messages MMS des clients		mm7-port
MMSC	Entier	Port sur lequel écoute le mmsproxy pour des requêtes MM7 des fournisseurs de services à valeurs ajoutées. Si ce port n'est pas fourni, le sous-système MM7 n'est pas démarré.		allow-ip
TOUT	Liste d'adresses IP	Liste des adresses IP des hôtes autorisées à utiliser / accéder au Port d'envoi de MMS (interface MM1 dan s le cas du MMSC ou le port d'envoi de MMS dans le cas de la passerelle SVA		deny-ip
TOUT	Liste d'adresses IP	Liste des adresses IP des hôtes non autorisées à utiliser / accéder au Port d'envoi de MMS (interface MM1 dans le cas du MMSC ou le port d'envoi de MMS dans le cas de la passerelle SVA		mms-client-msisdn- header
MMSC	Chaine de caractères	Nom de l? en-tête HTTP envoyé / inséré par la passerelle WAP comme appartenant à la requête MMS pour indiquer le MSISDN de l'expéditeur. Il est à noter que généralement le client MMS . n'indique pas son MSISDN dans le message MMS, c?est alors à la passerelle de le découvrir et de l?insérer. Nous comptons sur la passerelle WAP pour fournir à la MSISDN comme un en-tête de requête HTTP (par défaut le nom de l?en-tête est

63

Souleymane THIONGANE Ousseynou NDOYE

				X-WAP-Network-Client-MSISDN)	mms-client-ip-header
MMSC	Chaine de caractères	Nom de l'en-tête HTTP envoyé / inséré par la passerelle WAP comme appartenant à la requête MMS pour indiquer l'adresse IP de l'expéditeur. Similaire à ce qui précède, si le MSISDN n'est pas définie, alors nous supposons que le client est identifié par une adresse IP, que nous extrairons de l'en-tête de la requête. Par défaut le nom de l'entête est X-WAP-Network-Client-IP.Si l'en-tête n'est pas trouvé, nous supposerons l'adresse comme celle vue dans l'interface MM1 de Mbuni.		allow-ip-type
MMSC	Booléen	Mettre cette directive à << false > pour empêcher Mbuni d'accepter et traiter des messages d'expéditeurs identifiés par une adresse IP (c'est-àdire non pas par MSISDN). Par défaut, ca valeur est << true >		content-adaptation
MMSC	Booléen	Définir ceci à << false > pour désactiver l'adaptation du contenu par Mbuni. Cela entrainera le MMSC à ignorer les capacités du client lors de l'envoi de messages, et pourrait causer des problèmes, donc attention! Par défaut : << true >		send-dlr-on-fetch
MMSC	Booléen	Le MMSC envoie une confirmation de réception à l'expéditeur que si le destinataire confirme la réception de l'interface MM1. Si vous voulez un rapport dès que le destinataire récupère le message (avant la réception du paquet acknowledge-ind MM1) mettre ce paramètre à << true >. Défaut: false		email2mms-relay-hosts
MMSC	Listes de numéros	Un point-virgule sépare la liste des hôtes / domaines. Lors de la réception de MMS via SMTP, la passerelle doit déterminer s'il s'agit d'un local ou d'un destinataire étranger. Pour déterminer si destinataire est locale, nous utilisons le module de résolution, si elle est fournie. (Notez que la résolution par défaut utilise les paramètres des local-prefixes pour déterminer si le destinataire est local, en retournant le nom du MMSC local, sinon, alors il vérifie ceux de chacun des relais pour voir si l'adresse du destinataire est l'un d'eux, en cochant la préfixes, le retour des correspondants au nom du proxy /relais.) Le résolveur doit retourner un nom d'hôte qui correspond aux paramétrages.		billing-library
MMSC	Chaine de caractères	Bibliothèque facultatif contenant les fonctions de facturation et le CDR. Cette bibliothèque est chargée au moment de l'exécution et devrait contenir des fonctions qui seront appelées lors de la génération de la facturation ou du CDR. Voir mms_billing.h pour plus de détails.

billing-module- parameters	MMSC	Chaine de caractères		Les paramètres à passer au module de facturation indiquée ci-dessus quand il est chargé. Il s'agit d'une chaîne de caractères génériques dont l'interprétation est tout à fait au module.	resolver-module- parameters
TOUT	Chaine de caractères	Bibliothèque facultative contenant des fonctions de résolution des MSISDN des destinataires en nom d?hôte proxy-relais qui doit traité le message (au coté du MMSC) ou le MMSC connecté qui devrait (internement) router un message de l?interface MM7 (du coté du MMSbox). Pour le MMSC Mbuni, fournir cette bibliothèque ignore les paramètres des local-prefixes citées plus haut. Si le nom d?hôte du Proxy-Relais retourné par le module est le nom d?hôte du MMSC local, donc le destinataire est considéré local. Voir mms_resolve.h pour plus de détails. (Voir mmsbox_resolve.h pour l'utilisation sous mmsbox).		notify-unprovisioned
MMSC	Booléen	Les abonnés qui ne sont pas provisionnés pour les MMS devraient recevoir des notifications (par exemple SMS) MMS quand un message est reçu pour eux.		mms-notify-text
MMSC	Chaine de caractères	Message à envoyer aux périphériques qui ne supportent pas les MMS, lorsqu'un message est reçu par l'utilisateur. Ce message est envoyé via le SEND-SMS-URL indiquée ci-dessus.		mms-notify- unprovisioned-text
MMSC	Chaine de caractères	Message à envoyer à des appareils qui ne sont pas compatible aux MMS.		mms-message-too- large-txt
MMSC	Chaine de caractères	Si un périphérique tente de récupérer un message qui, au cours de l'adaptation de contenu est déterminé à être trop grand pour le périphérique cible (sur la base des données fournies par les capacités de l'appareil), le message est rejeté, ce texte est envoyé à l'appareil comme un message MMS.		mms-to-email-html
MMSC	Chaine de caractères	Quand une MM est destiné à l'email, il faut le formater pour le rendre plus adapté aux lecteurs de courrier électronique. (Par exemple, la partie SMIL de la MM ne signifiera rien pour la plupart des lecteurs de courrier électronique)		mms-to-email-txt
MMSC	Chaine de caractères	Quand une MM est destiné à l'email, il faut le formater pour le rendre plus adapté aux lecteurs de courrier électronique. (Par exemple, la partie SMIL de la MM ne signifiera rien pour la plupart des lecteurs de courrier électronique). La passerelle en forme le message comme suit: Il génère un message multi-part MIME avec la partie principale étant une entité HTML dans lequel est

rovision

65

Souleymane THIONGANE Ousseynou NDOYE

		embarqué le MM. Le texte donné ici est marqué au bas de la page HTML.	mms-to-email-default- subject
MMSC	Chaine de caractères	Cette chaîne est placée dans le MMS convertis au courrier électronique comme une alternative à la partie HTML, pour les clients de messagerie qui ne supportent pas le HTML.	sendmms-port
VAS GW	nombre	Cette chaîne de caractères est utilisée comme objet du message par défaut lors de l'envoi de MMS à l'e-P IICIaEMDIFIVREIEMpikP H I?RNNEIbfIQI dans le message	sendmms-port-ssl
VAS GW	Booléen	Le port sur lequel La passerelle SVA écoute pour envoyer des requêtes. (Optionnel)	mmsbox-mt-filter- library
VAS ^GW	Chaine de caractères	Définir sa valeur à « true » si le SendMMS port de la passerelle SVA doit être sécurisé (HTTPS). Ceci est pris en charge uniquement si Mbuni est compilé avec le support de SSL.

Tableau 2 : Paramètres de configuration du groupe Mbuni

Configurations Spécifiques du MMSC

Cette section décrit la configuration des sections qui devront être utilisées lorsque Mbuni est configuré pour fonctionner comme un MMSC.

Configuration MM7

Les MMS-69$ INRQAPRQUXIbVillilaPPQRu I TSCNIPMIRNSIs mms-vasp. group = mms-vasp

vasp-id = newcorp

type = soap

short-code = 100

vasp-username = newscorp

vasp-password = news123

vasp-url = http://mmsc1:[e-mail]:8080/mm7

Les paramètres de configuration suivante sont pris en charge:

Variable	Type		Description	group
Chaine de	Obligatoire: mms-vasp

	caractère s			vasp-id
Chaine decaractère s	Nom d?utilisateur (arbitraire)		type
Chaine de caractère s	Cela devrait être : soap ou eaif		mm7- version
Chaine de caractère re s	Facultatif. C?est la valeur de la version MM7 à utiliser sur cette interface (valeur par défaut : "5.3.0" pour XML / SOAP, "3.0" pour EAIF). Pour SOAP, ceci est utilisé comme la valeur de la version de MM7 du noeud XML. Pour EAIF il est indiqué dans les en-têtes HTTP.		mm7- soap- xmlns
Chaine de caractere s	Uniquement valable pour les MM7/SOAP, et est utilisée dans ^lemessage SOAP pour identifier les noms de tous les MM7/SOAP. La a, v leur par défaut est http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL -5-MM7-1-0		short- code
Entier	Numéro court pour ce fournisseur SVA : les messages reçus par Mbuni à ce numéro sont acheminés au VASP par l'intermédiaire de l?interface MM7.		vasp- url
Chaine de caractère s	Les messages sortants de la VASP sont envoyés via cette URL (à l'aide de la méthode POST)		vasp- usernam e
Chaine de caractère s	Authentification HTPP entrante : Le nom d'utilisateur utilisé par le VASP pour s?authentifier à Mbuni lors de l'envoi de données		vasp- passwor d
Chaine de caractère s	Authentification HTPP entrante : Le mot de passe utilisé par le VASP pour s?authentifier à Mbuni lors de l'envoi de données		mms-to- email- handler
Booléen	Définir cette directive à « true » si tous les MMS destinés à des emails doivent être routés à travers ce VASP par le MMSC. Le message est Encapsulé comme un message MM7 et remis. Cela pourrait être utilisé pour personnaliser l'apparence de l'e-mail.		mms-to- local- copy- handler
Booléen	Définir cette directive à « true » si tous les MMS sont destinés à des utilisateurs locaux (exemple les téléphones mobiles) doivent être copiés dans ce VASP. Ceci est utile si vous voulez mettre en place une base de visualisation web (comme une solution de sauvegarde) pour vos utilisateurs.		send-
Chaine	Facultatif. Ce paramètre détermine si la chaine de caracrères User-

67

Souleymane THIONGANE Ousseynou NDOYE

uaprof

de	gent est envoyée à la VASP (pour MM7/SOAP seulement). La définir
caractère	à « ua » pour envoyer entièrement la chaine du User-Agent (c'est-à-
s	dire la valeur de l?en-tête de requête HTTP du User-Agent). Mettre
	« url » pour envoyer le profile URL du client (c'est-à-dire la valeur de l?en-tête de la requête HTTP X-WAP-Profil-tête). Laisser le champ vide afin de n?envoyer aucune d'informations.

Tableau 3 : Paramqtres de configuration de l'interface MM7

Notez qu'à l'heure actuelle, seule le régime d?authentification basique http est soutenu par Mbuni (à la fois pour les requêtes entrante et sortante).

Configuration MM4

Les passerelles MMS étrangères sont configurées pour utiliser un ou plusieurs groupes mmsproxy:

group = mmsproxy

name = "A test mms proxy" host = test.com

allowed-prefix = "075" denied-prefix = "077"

Variable	Type		Description	group
Chaine de caractères	Obligatoire: mmsproxy		nom
Chaine de caractères	Nom d'utilisateur convivial		hôte
Chaine de caractères	Nom de domaine pleinement qualifié		Allowed- prefix
Liste de numéro	Liste des préfixes de numéro de destinataire qui peuvent être fournis par l'intermédiaire de ce Proxy		denied- prefix
Liste de numéro	Liste des préfixes qui ne peuvent pas être livrés par la présente procuration		confirmed- delivery
Booléen	Spécifie si l'utilisation MM4 demande la reconnaissance de la part du MMC destinataire pour chaque message. Par défaut, c'est la valeur vrai.		send-mail- prog
Chaine de caractères	Commande à utiliser pour l'envoi de messages (par courriel) aux passerelles MMS étrangères. Cette commande ignore , pour ce proxy

			plus de manèges, de la présente procuration, le global-mail envoyer prog-cadre, et offre la même variable substitutions.	strip-
Liste de	Un point-virgule (;) sépare les chaînes de préfixes ,qui devrait (si		prefixes
numéro	trouvée) être dépouillée ,du numéro de téléphone avant de normalisation nombre et le message d'envoi, tel que décrit cidessous. Seul le premier préfixe correspondant sera dépouillé.		unified-
Numéro de	Une chaîne permettant d?unifier les numéros de téléphone reçus, de		prefix
liste	sorte que le routage fonctionne correctement. Le format précéde que la première fois le préfixe unique, tous les préfixes qui sont remplacés par le préfixe unique, séparés par des virgules (','). Par exemple, "+256, 000256,0; +, 000" devrait faire en sorte de corriger
	UG préfixes. S'il existe plusieurs préfixes unique il faut les séparer avec des points-virgules (';')

Tableau 4 : Param~tres de configuration de l'interface MM4

Quand un MM destiné à un MSISDN ne peut être livré, la passerelle recherche la liste des roxy pour voir si l?un d?eux peut traiter le message. Si elle en trouve, le message est mis sous format MIME MM4 (selon 3GPP TS 23.140) et envoyé via le protocole SMTP au proxy.

Configurations spécifiques de la passerelle MMS/SVA

Lorsque Mbuni est utilisé comme une passerelle SVA, les configurations dans cette section sont requises pour assurer le bon fonctionnement du système.

Configuration des connexions MMSC

Les connexions MMSC sont configurées à l'aide d'un ou de plusieurs groupes MMSC:

group = MMSC

id = Testone

group-id = mmc1

MMSC-url = http://mbuni:test @ 192.168.129.52:8080 / eaif

incoming-username=ndoye incoming-password=passer incoming-port=10002

type = eaif

Les paramètres de configuration prises en charge sont :

69

Souleymane THIONGANE Ousseynou NDOYE

Variable

Type	Description	group
Chaine de caractères	Obligatoire: MMSC	id
Chaine de caractères	Obligatoire: Identifie le nom pour cette connexion (utilisé dans les journaux par exemple). Pour les connexions MM7 il est aussi utilisé comme paramètre ID VASP	group-id
Chaine de caractères	Facultatif: Peut être utilisé pour regrouper différents MMCs aux fins de la réception de DLRs, etc	type
Chaine de caractères	Obligatoire: Protocole parlé par cette MMSC, parmi eux :soap pour le 3GPP MM7 SOAP, eaif pour le Nokia EAIF .	mm7- version
Chaine de caractères	Facultatif. La version MM7 à utiliser sur cette interface (les valeurs par défaut sont "5.3.0" pour MM7/SOAP, "3.0" pour EAIF.) Pour SOAP, elle est utilisée dans la balise version de MM7. Pour EAIF elle est indiquée dans les en-têtes HTTP.	mm7- soap- xmlns
Chaine de caratères	Facultatif. L'espace de noms URI pour le "MM7:" XML . Only valid for MM7/SOAP, and is used in the SOAP message to identify the namespace for all MM7/SOAP specific elements. Uniquement valable pour les MM7/SOAP, et est utilisé dans le message SOAP pour identifier les éléments spécifiques des noms de tous les MM7/SOAP . La valeur par défaut est : http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schem a/REL-5-MM7-1-0	use-mm7- soap- namespace -prefix
Booléen	Facultatif .La valeur est»true»si les balises MM7/SOAP doivent avoir le préfixe MM7. Some MMC/VAS GW implementations do not seem to like this, so you can set this to false to see what mileage you get. Certaines implémentations de la passerelle MMC / SVA ne semblent pas comme cela, on peut mettre la valeur faux pour voir le kilométrage que vous recevez.	mmsc-url
Chaine de caractères	Obligatoire : adresse URL du MMSC. Utilisé pour les messages sortants	incoming- port
Entier	Port par lequel Mbuni écoute les messages venant de la MMSC	incoming- user
Chaine de caratères	Nom d'utilisateur qui sera utilisé par la MMSC pour s'authentifier à Mbuni pour les connexions entrantes. (Utilisation du système

			d'authentification de base HTTP.)	incoming- password
Chaine de caractères	Mot de passe pour utilisé par MMSC pour s'authentifier à Mbuni pour les connexions		incoming- port-ssl
Booléen	Spécifie si le port est sécurisé (c'est-à-dire l'utilisation des requêtes sécurisées HTTP). Uniquement supporté si Mbuni est compilé avec le support de SSL.		allow-ip
Liste d?adresses IP	Liste des adresses IP des hôtes autorisées à utiliser / accéder les ports MMS		deny-ip
Liste d?adresses IP	Liste des adresses IP des hôtes qui ne sont pas autorisées à utiliser / accéder les ports MMS		allowed- prefix
Liste de numéro	Liste des préfixes de numéro de destinataire qui peuvent être fournis par l'intermédiaire de ce MMSC (utilisé pour le routage des messages en cours)		denied- prefix
Liste de numéro	Liste des préfixes qui ne peuvent pas être livrés par le biais de ce MMSC		^allowed-Liste sender- prefix
de numéro	Liste des préfixes de numéro de l'expéditeur qui peuvent utiliser cette MMSC		^denied-Liste sender- prefix
de numéro	Liste des préfixes de numéro de l'expéditeur qui ne peuvent pas utiliser ce MMSC		max- throughput
Nombre	Nombre maximum de messages par seconde (sortant), que ce MMSC peut gérer.		reroute
Booléen	Si la valeur est << true >> tous les messages reçus à partir de ce MMSC sont acheminés directement à la file d'attente sortante (jamais à un MMS Service).		reroute- mmsc-id
Chaine de caractères	Si définie (et reroute est << true >>), alors tous les messages reçus sur cette connexion seront envoyés directement par l'intermédiaire du MMSC de l'ID.		reroute- sender-to- subject
^add-Booléen	Si reroute est << true >> et cette valeur est aussi <<true>> alors tous les messages reçus sur cette connexion sont de nouveau en déroute, et l'original expéditeur est ajouté à l'objet du message en ligne.

71

Souleymane THIONGANE Ousseynou NDOYE

mm7-mt-
filter-
params

Chaine de caractères	Paramètre (s) à transmettre à l'initialisation de la fonction de filtrage MMS MT spécifiée dans la bibliothèque filtrage mmsboxmt ci-dessus. La fonction d?initialasition est appelée une fois pour chaque connexion MMC, et doit retourner aucune erreur, sinon, aucun filtrage ne sera fait sur les messages par l'intermédiaire de ce MT MMC. (Voir mmsbox_mt_filter.h pour plus de détails.)	mmsc- library
Chaine de caractères	Si type MMC est utilisé, ce paramètre constitue la bibliothèque Dynamic Shared Object (DSO) chargée d?assurer la connectivité de la console MMC. (Voir mmsbox_mmsc.h pour plus de détails sur l'exportation de symboles.)	custom- settings
	Si type MMC est utilisé, ce paramètre fournit les paramètres à fournir à la bibliothèque Dynamic Shared Object (DSO) chargée d'assurer la connectivité de la console MMC (Voir mmsbox_mmsc.h pour plus de détails sur la façon dont celui-ci est utilisé.)
no-sender- address Booléen	S?il est a «true» Mbuni n?enverra pas l?adresse d?envoi dans le message SOAP XML.

Tableau5 : Paramètres de configuration des groupes MMSC

Configuration du groupe sendmms-user

Pour ?tre en mesure d'envoyer des MMS en Mbuni via le port d?envoi MMS (si configuré), au moins un utilisateur de sendmms doit être configuré:

group = sendmms-user username = test

password = onlyweuz faked-sender = 100

Les paramètres de configuration sont les suivantes:

Variable	Type		Description	group
Chaine de caratères	Utilisateur de sendmms

username	Chaine de caratères		Nom d'utilisateur	password
Chaine de caratères	Mot de passe		faked- sender
Chaine de caractères	Facultatif. Adresses d'expéditeur utilisées.		deliver- report-url
Chaine de caractères	Facultative URL à appeler pour envoyer des messages d'état de remise de rapport à la passerelle SVA par un MMSC pour un message présenté par cet utilisateur.		read-report- url
Chaine de caractères	Facultative URL à appeler pour envoyer l?accusé de réception d?un message lu et renvoyé a la passerelle SVA par un MMSC pour un message présenté par cet utilisateur.

Le service d?envoi de MMS Le service peut ~tre invoqué en utilisant la requ~tes HTTP GET ou POST sur le port d?envoi de MMS au niveau de la passerelle SVA. L'interface attend et procède a la suivie des paramètres CGI.

La variable CGI		Description	username
Nom d?authentificIation de l?lX\ilisateur (il doit correspondre à une configuration de send-mms-user).		password
Mot de passe d'authentification (il doit correspondre à des correspondants d'envoi mms-utilisateur).		from
Cela est écarté ????? par faked-sender de send-mms-user.		to
Bénéficiaires du message.S?il ya plusieurs destinataires on peut les séparer par un espace.		subject
Objet du message		mmsc
MMSC sortante, par laquelle le message est route . Si ce n'est pas spécifié, la passerelle SVA route le message basé sur l'adresse du destinataire et les configurations allowed-prefix /denied-prefix pour les paramètres des MMSCs. Notons que la passerelle SVA estime que toute MMSC peut traiter l'email et l'adresse IP du destinataire c?est pourquoi elle route les messages vers la première MMSC configurée. Notons également que le filtrage MT MMS ne sera pas fait sur les messages envoyés via l?interface

73

Souleymane THIONGANE Ousseynou NDOYE

		send-mms sauf si une MMC de destination particulière est spécifiée à l?aide de cette variable .	dlr-url l
URL à appeler quand un rapport d'envoi de ce message est reçu		rr-url
URL à utiliser quand un rapport pour lire ce message est reçu		text
Si cela est prévu, celui-ci est utilisé comme le (texte) contenu de la MM à être envoyé. Le type de contenu de la MM est fixé à text / plain		charset
Utilisé en conjonction avec le paramètre texte, il spécifie les caractères du texte si ce n'est pas la valeur par défaut (iso-8859-1).		smil
Si cela est prévu il précise le SMIL pour le MM. Un MM est construit en dehors du SMIL comme décrit ci -dessous et le corps du MM aura un contenu du type multipart /related qui est prévu par défaut.		content-url
Si fourni ,il spécifie l'URL du contenu à transmettre
Si cela est prévu, il précise le contenu arbitraire du texte du MM. Le type de contenu est déterminé par le type du contenu de la variable CGI (voir cidessous), ou si enctype = multipart / form-data est utilisé dans la requête POST HTTP, puis le type de contenu associé à cette variable est utilisé.		content_type
Si le contenu de la variable est prévu , cette variable spécifie le type du contenu .La valeur par défaut, si aucun type de contenu n'est fourni (ou peuvent être obtenues à partir de la requête HTTP), ce qui est mis à application / octet-stream.		base-url
Si le paramètre URL de smil est prevu, ce paramètre peut être , fournis à être utilisé comme URL de base pour résoudre toutes les URL relatives spécifié dans le fichier SMIL pendant la construction du MM. Par défaut: http://localhost/		VASID
Cela sera répercuté sur la MMC comme le paramètre SVAID dans le message MM7/SOAP .		Service-code
Cela sera répercuté sur la MMC comme le paramètre de code de Service . S'il n'est pas prévu, ce paramètre n'est pas envoyé.		allow- adaptations
Ce drapeau sera remis à l'opérateur MMSC (MM7/SOAP uniquement) pour allumer / éteindre l?adaptation de contenu.		mclass
Message Class. (par exemple personnel)		priority
Message de priorité. (par exemple, Normal)

mms-direction		MT (terminaison mobile) ou MO (mobile originaires). Lors d'un réglage MO, le MMS ressemble à une file d'attente comme si elle venait du côté ^del'opérateur MMSC. Ceci est utile pour tester les configurations de service comme il imite la réception de MMS MO. La valeur par défaut est MT.	distribution
Facultatif .Doit être « true » ou « false ».Cela est défini comme le paramètre indicateur de distribution MM7/SOAP.

Tableau 6 : Paramètres de configuration du groupe sendmms-user

Remarque : Seul text, smil, content-url ou content doit être spécifié. Spécification de plusieurs peut faire des autres ignorés.

Si un rapport de livraison ou de lecture est spécifié pour l'envoi de mms (ou en tant que paramètres de demande d'envoi mms), et un rapport est envoyé à la passerelle SVA par un MMSC, la page Web est appelée (en utilisant la méthode GET de HTTP), et des informations sur le rapport qui lui est envoyé via l?ent~te X-Mbuni.

L?interface d?envoi de MMS peut également ~tre utilisée pour envoyer le contenu binaire (par exemple binaire codé MMS, image ou audio), directement à Mbuni. Cela se fait comme suit:

· Envoyer le contenu binaire, comme le corps d'une requête HTTP POST au port d?envoi de MMS. Be sure to specify the correct body content type as part of the HTTP request headers. Assurez-vous de spécifier le type correct du contenu du corps, dans l?en-tête de la requête HTTP. Ceci est interprété selon les règles énoncées ci-dessous.

· Approvisionner a toutes les requêtes URL , mais les paramètres de texte et de smil (comme décrit ci-dessus) dans le cadre de la requête URL.

Configuration du service MMS

Les messages sont acheminés vers des services basés sur le premier mot de la partie texte de la MM. C'est Mbuni, extrait la première partie de texte de la MM, et trouve le premier mot clé dans le message. Mbuni recherche ensuite dans la liste de configuration des services MMS pour un service de jumelage basé sur le mot-clé, et va chercher la réponse de l' URL associée, un fichier ou un programme.

Une simple configuration de service pourrait ressembler à ceci: group = mms-service

75

Souleymane THIONGANE Ousseynou NDOYE

name = ndoye

post-url = http://localhost/photoblog.php

catch-all = true

http-post-parameters = fx=true&images[]=%i&text[]=%t

accept-x-mbuni-headers = true

keyword = test

Une liste détaillée des paramètres de configuration pour les services MMS est donnée cidessous.

Variable	Type		Description	group
obligatoire	service mms		name
Chaine de caractères	Nom du service. Utilisé pour la connexion, envoyé également a la MMSC comme paramètre d?identification SVA MMSC, comme pour les requêtes SOAP.		keyword
Chaine de caractères	M ot de passe obligatoire. Les messages entrant dont la partie texte correspondant à ce paramètre sera acheminé par l'intermédiaire de ce service.		aliases
liste de chaînes de caractères	Un point-virgule sépare la liste des aliases des mots-clés. N'importe lequel de ces mots clés causera également un message à passer a travers le service.		catch-all
Booléen	Mettre la valeur a vrai si tel est le service par défaut (c'est-à-dire tous les autres messages acheminés par le biais de ce service en cas de différence).		accepted- mmscs
liste de chaînes de caractères	Un point-virgule sépare la liste des MMSCs (énumérés par ID). Seuls les messages provenant de ces MMSCs seront acheminés à ce service de la même manière. Laissez ce champ vide pour laisser passer tout le monde.		denied- mmscs
liste de chaînes de caractères	Les messages provenant de ces MMSCs ne seront ^jamaisacheminés vers ce service de la même manière. Laissez ce champ vide pour laisser passer tout le monde.		allowed- receiver- prefix
Chaine ^de caractères	Chaines de caractères séparées par des virgules : Liste des préfixes de codes courts des récepteurs autorisés à utiliser le service MMS.		denied-
Chaine de	Chaines de caractères séparées par des virgules : Liste des

76

Souleymane THIONGANE Ousseynou NDOYE

receiver- prefix	caractères		préfixes de codes courts des récepteurs non autorisés à utiliser ce service MMS.	get-url
Chaine de caractères	URL pour récupérer le contenu de la réponse. Aucune sXENNItXtiRn GI TSEEEP qIII II?est IIBI , P TIMBeVIn-tête X-Mbuni sont envoyées dans le cadre de la requête HTTP. Voir ci-dessous pour une explication sur la manière dont la réponse est interprétée.		exec
Chaine de caractères	Programme à exécuter pour obtenir la réponse de contenu .La réponse est attendue sur la sortie standard, et doit être de type SMIL. Voir ci-dessous pour une explication sur la manière dont est traitée le SMIL.		file
Chaine de caractères	Dossier par lequel le contenu de la réponse est obtenu .Le type de la réponse est déduit de l'extension de nom de fichier pour un cert ain nombre de type de medias bien connus (texte, SMIL,GIF, JPEG, PNG, BMP / WBMP, WAV, AMR, MP3, etc), sinon par défaut application/octet . Voir ci-dessous pour de plus amples informations sur la façon dont le contenu obtenu est converti en MM.		text
Chaine de caractères	Si cela est prévu, le contenu de la réponse est la valeur de ce paramètre, et est supposé être de type de média text / plain.		post-url
Chaine de caractères	Le contenu de la réponse est obtenu à la suite de l'envoi d'une demande de type POST HTTP à l'URL. Le type de message POST est toujours sRXP BAT B?eITRGE/H multipart / form-data (telle que celle utilisée par un navigateur Internet quand un formulaire HTML a le paramètre enctype = multipart / form-data ). If http-post-parameters field is given (see below). Si le domaine de paramètres post http est donné (voir ci-dessous), puis les paramètres sont transmis comme étant une partie des EFIXrtI GI BT-n-tête X-Mbuni . Voir ci-dessous pour une explication sur la manière dont la réponse est interprétée.		http-post- parameters
Chaine de caractères	Utilisé en conjonction avec post-url. Les paramètres sont fournis GeIBa P rP I TIIIRQEqX4Bs3HEIMAIRXLM GEns XQ MITuête GET HTTP (par exemple, message = true & myname = test & image =% i). Les valeurs de paramètres qui commencent par % sont interpolés selon les règles énumérées ci-dessus		accept-x- mbuni- headers
Booléen	0 IMBFeBDINUOL0 EX(1.GeMIIINKRnRUI B?Fn-tête HTTP XMbuni dans le service de réponse .Voir ci-dessous pour la liste des en-têtes.		pass-thro- headers
List	0 MU XQMI/XBeRPSEUNIFI GEns XQ BZAMG?eQ-tête des réponses +773 TXL, IVIB EMAEMX DSE1 G1 la réponse de service, devrions être transmis à la console MMC (avec leurs valeurs

77

Souleymane THIONGANE Ousseynou NDOYE

	correspondantes) inchangée. Notez que ces en-têtes sont fusionnées avec d'autres en-têtes générées par Mbuni.	omit-empty
Booléen	Mettre la valeur vrai si Mbuni doit envoyer une réponse vide au demandeur si l'un est spécifié par le service	suppress- reply
Booléen	Mettre la valeur a vrai si Mbuni ne renvoie pas de réponse à l'utilisateur de ce service. Notons que la requéte URL sera toujours appliquée.	assume- plain-text
Booléen	Mettre la valeur a vrai si un inconnu type de contenu dans la réponse doit être mappé au format texte.	faked-sender
Chaine de caractères	S 'il est défini, Mbuni va changer l'adresse de l'expéditeur dans le message de réponse à cette valeur, indépendamment de toute entêteX- Mbuni ou l?adresse initiale de destination.	service-code
Chaine de caractères	S'il est défini, Mbuni l?utilisera comme le paramètre de code de service à renvoyer à la MMSC (MM7/SOAP seulement) dans une réponse SubmitReq. Ce paramètre remplace l?en-tête XMbuni-ServiceCode, si la réponse est entière.

Tableau 7 : Paramètres de configuration du groupe mms-service

Notez que seul l'un des fichiers ou textes get-url, post-url, peut être spécifié.

Comment est interprété le contenu de réponse

Lorsque le contenu de la réponse du service MMS est chargée, ou un message est émis en utilisant l'interface d?envoi de mms, elle est remise en un MM basé sur le type de contenu de la réponse relevé ou déduit (dans le cas du contenu du fichier). Pour le contenu des fichiers récupérés a partir de l?URL, le type de contenu est considéré comme reçu du serveur HTTP .Pour le contenu de fichier il est déduit de l'extension du fichier. Pour le contenu d?exec, il est supposé -tre SMIL. Les règles de conversion générales sont les suivantes:

· SMIL: Si le contenu est de type application / smil, la passerelle SVA analyse le SMIL et trouve tous les contenus (par exemple, images, audio) auxquels il se réfère. Ceux-ci sont récupérés et ajoutés à la réponse MM, et correspondant a la composante SMIL modifiée (c'est-à-dire l'attribut src de modification) pour

référencer le contenu dans le MM. Notez que la passerelle SVA est assez intelligente pour comprendre une URL partielle ou des références de fichiers (par exemple images / smile.gif ou. / Test.txt), ainsi que de valeur absolue (par exemple, / images / smile.gif ou http://somehost/test . txt)

les références au sein de SMIL. Il va tenter de récupérer le contenu par rapport à l'emplacement du contenu de base SMIL dans le cas des références relatives. Pour empêcher le contenu d'être récupéré, vous pouvez préfixer une barre à l'emplacement de valeur.

Le MM resultant sera un message standard multipart / related, avec le SMIL comme l'élément de départ.

· Type de contenu MMS: si le type de contenu retourné est application / vnd.wap.mms-message, le contenu est supposé être un binaire codé MM et sera considéré comme le contenu de la réponse.

· Liste des types d'URL: Un spécial mime Mbuni de type application / vnd.mbuni.url-list a été défini et les fichiers avec l?extension .urls sont mappés à ce type de contenu (si le type de contenu ne provient pas du serveur HTTP ou par autres moyens) . Les fichiers de ce type devrait contenir une liste d'URL (file: / / et http (s): / / prise en charge), une par ligne. Mbuni chargera chaque élément de contenu à partir de l'URL et générera un MMS contenant la liste des éléments de données (multipart / miixed).

Autres types de contenu: Tous les autres types de contenu provoquent la génération d?une MM ayant le type de contenu correspondant. Lorsque le type de contenu n'est pas indiqué (ou est impossible à déterminer) dans la réponse, si le paramètre assume-plain-text est fixé, MIME de type text / plain est utilisé.

Chapitre 4 :

Fonctionnement de la
Passerelle

79

Souleymane THIONGANE Ousseynou NDOYE

I. Le MMSC

Comme indiqué, il ya trois composants du MMSC: Le Relais (mmsrelay), le

Proxy (mmsproxy) et SMTP / Email Interface (mmsfromemail). Nous allons décrire la fonction de chacun de ces éléments.

1. MMS Proxy

Cette composante (mmsproxy) est le principal point d'interaction entre la passerelle et les clients et les VASP. Il fournit une interface HTTP à travers lequel les clients peuvent envoyer des messages MMS. Les types de message attendus des clients, sur cette interface sont généralement les suivants :

· Envoi d?une requ~te: Utilisé par les clients pour soumettre un MM à la

passerelle. Quand celui-ci est reçu, le message est placé dans la file d'attente. Si le client demande une copie du MM dans la MMbox, sa requête sera exécutée.

· Transmission de la requête: utilisée par le client pour demander au MMSC de transmettre un MM. Dans ce cas, le MM est résident sur la passerelle (c?est au client de le récupérer) et est identifié par son URL. Le message est extrait et placé dans la file d'attente pour le traitement. Si une demande de placer une copie dans la MMbox est indiquée, cela est fait.

· Notification de réponse: Est envoyé par le client comme une réponse à une notification de MM à travers Wap Push. Ce message indique l'état des informations telles que si le client souhaite reporter la récupération du message, etc. Si la notification indique que le message a été récupéré, le message est supprimé de la file d'attente. Si la notification indique que la récupération a été reportée, le message est marqué de façon à ce que plus aucunes des notifications seront envoyées au client sur ce message.

· Lecture de la réception: à la demande de l'expéditeur, une confirmation de lecture peut être transmise via cette interface. Celle-ci se situe dans la file d'attente pour être livrée au destinataire

· MMbox Upload / Delete / Search: L?envoi et la suppression de l'utilisateur MMbox sont pris en charge.

· MMbox search: Les demandes de recherche de message sont traitées. Le proxy prend
le soin de retourner seulement la taille de données que le client peut gérer (comme

80

Souleymane THIONGANE Ousseynou NDOYE

l'indique le profile UA).

Tous ces messages sont envoyés au proxy comme le corps d'une requête POST HTTP. Les messages sont récupérés en fournissant l?URL dans une requ~te GET. Quand une telle demande est reçue, le proxy:

i. Localise le message: à partir de l'URL, le proxy peut dire si c'est un message dans le MMbox ou dans la file d'attente du client destinataire du message.

ii. Extrait l?URL du profile User Agent (UA) à partir d?en-têtes des requêtes HTTP. Si cela fait défaut, les informations de profile seront déduites les entêtes HTTP Accept. Le profile URL est transmise au module d'adaptation de contenu, qui exerce diverses modifications à la MM, tels que:

o Conversion des images du MM à un format pris en charge par le client

o Calibrage des images pour les ajuster à la taille de l'écran du client

o Conversion des fichiers audio du MM à un format pris en charge par le client

o aConversion des textes à un jeu de caractères pris en charge par le client

o Suppression de contenu non pris en charge.

noter que les données de profile sont mises en cache (dans storage-directory/ UserAgent_Profiles) afin de ne pas avoir à chercher à chaque fois.

iii. Le message est ensuite encapsulé et retournée au client dans une requête HTTP. Des VASPs, mmsproxy s?attend et traite :

· Les requ~tes d?envoi: Utilisé pour soumettre des messages pour la transmission par Mbuni

· Les annulations: Un message précédemment soumis peut ~tre annulé s?il n'est pas encore acheminé au processeur suivant ou au récepteur. (C'est à dire, seuls les messages qui sont encore dans la file d'attente globale peuvent être annulés.) Seul le message original soumis peut annuler un autre.

· Les remplacements: Un message soumis peut être changé #177; le VASP peut fournir un contenu différent.

Les requ~tes SOAP et EAIF de l?interface MM7 sont à la fois prises en charge.

81

Souleymane THIONGANE Ousseynou NDOYE

2. MMS Relay

Le Relais gère le routage de tous les messages (vers des téléphones, emails, VASP).

Le Relais observe la file d?attente globale pour des messages entrants (de VASP, de MMSC externes ou de clients). Pour chaque message qui arrive dans la file d'attente, le relais:

i. Détermine si le message est dû à une tentative de livraison. Une tentative est faite pour transmettre le message dès qu'il est reçu (demandes de livraison différées toutefois sont respectées).

ii. Lors de la première tentative de livraison, un appel est fait au module de facturation pour effectuer une facturation ou génération CDR. Si le module de facturation indique que l'expéditeur ne dispose pas de suffisamment de crédit, le message est supprimé et l'expéditeur reçoit une notification.

iii. Si le message est une tentative de livraison, l'émetteur global détermine, pour chaque destinataire, la façon de livrer le message:

a) Si le message est destiné à un e-mail, il est formaté au type MIME, l?adresse de l?émetteur et du récepteur étant normalisée par le RFC 822, ensuite le message est transmis à l?e-mail.

b) Si le message est destiné à un VASP (identifié par code court), alors il est envoyé en utilisant les protocoles MM7 à la VASP.

c) Si le message est destiné à un client MMS local, le message est transféré vers la file d'attente mobile/locale. Une copie du message est envoyée (au format MIME) à un hôte MMBox (s?il est configuré).

d) Si le message est destiné à une passerelle étrangère, il est codé en MIME et transmis à l?email par une livraison SMTP

e) Si le message ne peut pas être livré, l'expéditeur est informé.

Pour les messages placés dans la file d?attente mobile/locale (c'est-à-dire ceux destinés au MSISDN dans la région desservie par ce MMSC ou aux clients IP), le relais permet les fonctions suivantes:

i. La notification est envoyée au client destinataire via WAP Push

ii. La livraison d?autres notifications est rapportée aux clients via le WAP Push

Le SMS est utilisé comme moyen de transport des messages WAP Push, si le destinataire est un MSISDN, sinon, UDP est utilisé.

82

Souleymane THIONGANE Ousseynou NDOYE

Le relais maintient une file d'attente pour les messages en attente de livraison. À intervalles réguliers (voir la section de configuration), il envoie des notifications au destinataire. Il garde l'envoi de notifications jusqu?à ce que le message soit récupéré ou que le client indique qu'il souhaite reporter la réception du message. Un mécanisme de retour est utilisé pour prévenir les inondations de notifications. Un message sera retiré de la file d'attente si:

· Il arrive à expiration, due soit au terme de la période d?expiration (fixée dans le message) ou bien l?expiration du système est atteinte.. (L'expéditeur est informé de l'expiration, s'il a demandé un rapport d'envoi)

· Si le destinataire récupère le message

Gestion des files d'attente

Un simple système de gestion de la file d'attente est utilisé. Chaque file d'attente de l'entrée se compose de deux fichiers: le fichier « q » (qui est du texte brut) contient les toutes les entrées de contrôle de données (liste de destinataires, durée de la prochaine tentative de livraison, etc.), le fichier « d », qui contient les données de messages. Ce régime est semblable à celui utilisé par les MTA populaires. Les processeurs de la file d?attente fonctionnent principalement sur le fichier « q », et utilise des fichiers de verrouillage pour éviter les doublons de livraison, fichier corrompu, etc.

Voir mms_queue.h pour plus de détails.

3. Interface Mail / SMTP

Cette interface reçoit des MMS du MTA et les acheminent du proxy du destinataire ou de l?emetteur. Plus précisément:

i. Si le message est une demande d'envoi, il est mis en attente dans la file pour livraison tant que le destinataire est autorisé via cette interface (voir configuration)

ii. Si le message est une notification (par exemple, rapport d'envoi), l'interface effectue les actions nécessaires (par exemple la transmission de la réception ou de la suppression de message de la file d'attente locale)

Cette interface devrait être invoqué à partir de votre MTA comme suit:

# mmsfromemail -f adresse_emetteur #177;t adresse_destinataire -s nom_mmsc_origine fichier_conf

1 RtRcs FISIcdact qu?auFucI spFuritp I3 IcSIMNIRurciIRDcs FIttI ictIrEFI. Il _est prévu que les mesures de sécurité (par exemple les pare-IIu_C IItFIHNIrRct P BINIc SaIFI SR015¹MXIrIqDIE les messages ne pourront atteindre le MTA et être remis à cette interface, que si ils sont légitimes.

Utilités

Ia Ist SIpYNTWc FIIIRic cRP EUIIdIINIrYIFIs S)EaiFVIIrDIjRDtp i aI SIMIrIaaI. Le premier est mmssend.

mmssend peut être utilisé pour insérer un message dans la file d'attente. Il devrait être invoqué comme suit:

# mmssend-f adresse_emetteur #177;t liste_destinataire #177;m fichier_mms [-b] fichier_conf

Note:

· la liste des destinataires est une liste de plusieurs destinataires, séparés par des deux points (« : »)

· Les fichiers MMS peuvent être des fichiers binaires ou MIME. L'utilitaire essaie de
deviner lequel de ces types est utilisés en inspectant le premier octet du fichier.

· Les adresses émetteur et destinataire sont utilisées pour la livraison (ainsi les en-têtes des messages peuvent ne pas être mises à jour.

· Le drapeau « -b », si spécifié, fait une copie du message qui sera stockée dans le 0 0 6ER4 dI a?pP IttIEr IDFuc FRctrôaI c?IM IfTIFWp SRX FRcfIIP IrirDI a'RIIMI dIE l'expéditeur est locale!)

/ I P ImagI iIsvSaaFpuEcs aaaaI dilttIctI raREaaI aYIF ucI dxpIio?I4SuaRc au P a4IP )P égale à celle du système.

84

Souleymane THIONGANE Ousseynou NDOYE

II. La Passerelle SVA

La passerelle SVA se compose d'un seul programme multi-traité : mmsbox. Ce programme effectue un nombre de fonctions simultanées, y compris la réception de MM entrant des MMSC, des demandes d?envoi de services, la composition et l'envoi des réponses, et l?écoute et le traitement des requ4tes d?envoi de MMS. Les principaux modules de la passerelle sont décrits ci-dessous.

Le SAV de passerelle gère principalement deux types de messages de la file d'attente: un pour les messages entrants (reçus des MMSC), un pour les messages sortants (reçus des services ou du port send-mms). Ceux-ci sont maintenus dans le répertoire de stockage, storage-directory, et respectivement dans les répertoires mmsbox_incoming and mmsbox_outgoing. La structure de la file d'attente est la même que celle utilisée par les composant du MMSC.

Un répertoire (mmsbox_dlr) est maintenu pour le stockage URL DLR.

· Le Module SendMMS: Ce module écoute sur le port d?envoi de mms (send-mms port) pour les requêtes entrantes. Celles-ci sont reçues et transformées en MM comme décrit ci-dessus et écrites dans la file d'attente sortante. Si l'expéditeur a demandé une lecture ou un rapport de livraison (en précisant les URL nécessaires), l?URL correspondant est stockée dans le URL DLR pour une utilisation future. En cas de réussite, l'interface renvoie l? ID de la transaction de soumission de message (qui est également signalé avec un DLR).

· Le Module Gestionnaire du MMSC: reçoit des messages provenant des MMSC, et les enregistre dans la file entrante. Aussi, il observe la file d'attente des messages sortants pour les nouveaux messages, qu'il envoie à l'MMSC, en se basant sur le routage des numéros de destinataire (si l?MMSC de destination n?est pas mis)

· Le Service d'envoi: lit les messages de la file d'attente entrante, détermine le service à invoquer, reçoit le résultat et crée une réponse MM, qui est écrit dans la file d'attente sortante. Si le service a demandé une lecture ou un rapport livraison, l?URL est stockée dans les URL DLR pour une utilisation future.

CONCLUSION

Le MMS est le service mobile le plus compatible aux réseaux actuels et futurs, qui tendent vers le multimédia (UMTS ,GSM, ...) , mais aussi le moins répandu et demande des installations matérielles, coté réseau et utilisateur, plus ou moins onéreuses. Pour pallier à ce dernier critère, les plateformes libres, telle que Mbuni, vont permettre aux opérateurs de procéder aux implémentations de ce service.

Peut-on, aujourd'hui, considérer que le MMS est le réel successeur du SMS ou restera til encore longtemps dans l'ombre de ce dernier et utilisé que par une petite partie des utilisateurs ?

A l'heure actuelle , c'est encore tôt pour répondre à cette question car comme cela est mentionné dans le document, tout ce qui tourne autour du MMS n'est pas encore totalement normalisé. Pour que celui-ci devienne incontournable il va falloir, d'une part, homogénéiser les formats (notamment les pièces jointes), et d'autre part, rendre son accès plus facile (aujourd'hui, il faut être inscrit chez son opérateur et faire une manipulation sur son téléphone pour pouvoir bénéficier de ce service) tout comme le SMS, qui, rendre son utilisation accessible sans aucune installation.

Une autre contrainte, pour l'utilisateur, reste le prix du MMS déjà particulièrement élevé . Mais pour cela nous pouvons faire confiance à la concurrence au niveau des opérateurs qui, pour consever leur clientelle , offrent parfois le sevice MMS gratuitement (envoi illimité de telle heure à telle heure ou vers X numéros ...).

86

Souleymane THIONGANE Ousseynou NDOYE

ANNEXES

Annexe A : Le protocole WAP

1. Modèle en couche du protocole WAP

Le WAP Forum a défini un modèle en couche pour le protocole WAP pour permettre aux équipements WAP, issus de différentes technologies, de communiquer ensemble. Le but est de mettre en place une architecture commune pour les différentes technologies de réseaux mobiles.

Figure 16 : Pile de protocoles du WAP1

· Wireless Application Environment (WAE) : Cette couche specifie le langage de balise qui doit être utilise pour afficher les pages WAP. Dans les premières versions du WAP, le langage utilisé est le WML (Wireless Markup Language), il s?agit d?un langage similaire au HTML mais optimise pour utilisation sur des terminaux mobile portables.

· Wireless Session Protocol (WSP) : Ce protocole permet d?assurer la persistance de la connexion, il offre à la couche WAE une interface pour les services orientes session.

· Wireless Transaction Protocol (WTP) : Cette couche opère au dessus d?un service datagramme, elle prend en charge l?aspect transactionnel du système et fiabilise la transmission.

· Wireless Transport Layer Security (WTLS): Ce protocole utilise la technologie SSL pour securiser les echanges de messages entre terminaux et serveurs. Il peut, grâce à cette fonctionnalité, ~tre utilisé dans le cadre de l?authentification des cartes de paiement pour le commerce electronique.

· WDP (Wireless Datagram Protocol) : Il s?agit de la couche transport du protocole WAP, cette couche offre une interface entre le type du reseau utilise et les couches application, session et securite, ce qui permet à ces couches de fonctionner en totale independance de la technologie du reseau. Ainsi, ce modèle et toutes les applications qui pourront être developpees seront disponibles dans le cas oil un nouveau type de reseau apparaîtrait.

88

Souleymane THIONGANE Ousseynou NDOYE

2. Modification des protocoles lors de l'évolution du WAP1 au WAP2

a. WAP1

Figure 17 : Conversion des protocoles pour WAP1

b. WAP2

Figure 18 : Conversion des protocoles pour WAP2

Annexe B : LES LANGAGES : WML, SMIL

1. Le langage WML

Le Wireless Markup Language (WML) est un langage à balises conçu spécifiquement pour le WAP, de manière à pouvoir s'afficher sur un écran de téléphone portable. Il est basé sur XML. Sa syntaxe est proche de HTML. On peut noter que WML est doté de son propre format d'image, appelé Wireless Bitmap (WBMP), dérivé du format BMP, mais en noir et blanc.

2. Le langage SMIL

Le S.M.I.L (Synchronized Multimedia Integration Language) est un langage prometteur, neuf et déjà très fonctionnel. Il permet de synchroniser divers médias selon une ligne de temps. Textes, vidéo, images, son, le tous lus par Real One Player. Ses applications sont nombreuses et représentent à coup sur une avancée technologique. De plus il est open source.

Les logiciels

Pour ce qui est des lecteurs Real Player est depuis le départ et encore aujourd'hui le plus avancé et le plus compatible. Les éditeurs sont encore discrets en 2004 le logiciel libre Limsee et ses concurrents Smox editor et smox pad (Manalee) ouvre la voie.

Editeur

Lecteur

Limsee 2 Real One

Manalee Quicktime 6

Smil Composer Grins

RealSlideshow HPAS applet

Grins

TagFree SMIL Editor

Projet OPERA

Tableau 8 : Quelques éditeurs

90

Souleymane THIONGANE Ousseynou NDOYE

Le tutorial basé sur quatre exemples (applications) commentés

Les quatre démonstrations en smil qui serviront d'exemples pour le tutorial

ex 1 : Texte

ex 2 : Image

ex 3 :Son

ex 4 :Video

Exemple 1 : un texte qui défile

Comme indiqué précédemment le langage S.M.I.L permet de synchroniser du textes, du vidéo, des images, du son, ...

De façon très général il y a un fichier « .smil » qui va lancer un fichier .rt contenant du texte et/ou un fichier .rp contenant les règles de mise en page des images et/ou des fichiers son ou vidéo en rm.

Pour l'instant il n'existe pas de logiciel réellement complet pour éditer ou créer des présentation en smil, cependant le bloc-notes de Windows suffit.

Il est cependant nécessaire d?avoir des bases en html. Cependant ce tutorial reste basique et n'aborde pas par exemple les différences entre le smil1.0 et le smil2.0

La structure classique d'un fichier smil est la suivante:

<smil> <head> </head> <body> </body> </smil>

Le S.M.I.L est un langage de synchronisation, ainsi il y a des variables de temps

Les événements qui se trouvent entre les balises <par> </par> seront joués en parallèle c'està-dire simultanément.

Les événements qui se trouvent entre les balises <seq> </seq> seront joués en séquence c'està-dire les uns après les autre.

<smil> <head> </head> <seq>

événement 1

événement 2

</seq> <body> </body> </smil>

L'insertion d'un fichier texte ou d'un fichier son... ressemble à celle utiliser en html <text src="texte.rt" /> ou encore <audio src="monson.rm" />

L'exemple texte

le code du fichier smil est le suivant

<smil> <head> <meta name="title" content="Le S.M.I.L permet de jouer du texte..." />

<layout>

<region id="t1" z-index="1"/>

</layout> </head> <body> <seq>

<text src="texte.rt" region="t1" />

<text src="texte2.rt" region="t1" fill="freeze"/>

</seq> </body> </smil>

Dans la partie head on retrouve comme en html une balise meta title pour le titre. La partie layout consiste à définir des régions à l'intérieur de la présentation (nous y reviendrons).

92

Souleymane THIONGANE Ousseynou NDOYE

En jouant la présentation vous avez pu constaté que les deux textes étaient joués l'un après l'autre et nous retrouvons bien les balises <seq>. La fonction fill="freeze" indique que ce dernier texte perdure même après l'arrêt de la présentation, si on le retire la présentation revient sur un écran vide.

le code du fichier texte.rt est le suivant

<window height="350" width="300" duration="15" bgcolor="with" > <center><font size="4" face="arial">

<p>

Le S.M.I.L<br/>

<time begin="2"/>permet<br/>

<time begin="4"/>de jouer du texte<br/>

<time begin="6"/>dans real one.<br/><br/>

<time begin="8"/>Mais pas seulement...</b>

</font>

</center>

</window>

Les fichiers .rt commence toujours par le tag Windows. On y retrouve la taille de la présentation 350 pixel de haut pour 300 de large, la police arial, les paramètres de temps qui font que le texte s'affiche au fur et à mesure et la couleur du fond blanche (noir par défaut).

Le fichier texte2.rt ne fait que répéter le code du fichier smil avec comme en html l'obligation de remplacer les crochets ouvrants "<" par "&lt;" (c'est un détail).

Exemple 2 : image et texte s'enchaînent

le code du fichier smil est le suivant

<smil>

<head>

<meta name="title" content="Image et texte s'enchaînent..." />

<layout> <root-layout width="330" height="300" />

<region id="i" top="20" left="90" width="150" height="60" z-index="1"/> <region id="t1" top="100" left="5" width="330" height="400" z-index="2"/> <region id="t2" z-index="3"/>

</layout>

</head> <body> <seq>

<par>

<a href=" http://real-and-smil.com" show="new">

<img src=" http://monsite.com/monimage.jpg" region="i" fill="freeze" /></a>

<text src="texte.rt" region="t1" begin="3" fill="freeze"/>

</par>

<text src="texte2.rt" region="t2" begin="1" fill="freeze"/>

</seq> </body> </smil>

Les premiers éléments intéressant de ce fichier est de montrer qu'il est possible d'enchâsser les balises seq et par. C'est-à-dire que la présentation se découpe en deux grandes parties. Comme vous avez pu le voir une image est jouée avec un texte dessous puis une partie du code est présenté.

On a donc entre les balises seq image+texte1 puis texte2. Mais image+texte 1 doivent être joué simultanément on les place entre des balises par. Ce principe n'a pas de limite, on pourrait imaginer que la partie parallèle se découpe elle même en sous partie séquentielle...

Le second élément intéressant est de remarquer que l'image est linkée et à très peu de chose près de manière identique qu'en html.

<a href=" http://real-and-smil.com" show="new"> <img src=" http://monsite.com/monimage.jpg" region="i" fill="freeze" /></a>

Le show="new" à la même fonction que le class="blank" en html c'est-à-dire qu'il indique que la page doit être ouverte dans une nouvelle fenêtre.

Les layouts son donc des zones définies dans l'espace. Elle peut être exprimée en pixel ou en pourcentage. Le root-layout définit la taille de l'ensemble de la présentation. Les attributs possible pour une région sont :

94

Souleymane THIONGANE Ousseynou NDOYE

top= distance au bord supérieur down= distance au bord inférieur left = distance au bord gauche right = distance au bord droit

with = la largeur height = la hauteur

On les définis dans la partie head :

<region id="t1" top="100" left="5" width="330" height="400" z-index="2"/>

Par un identifiant unique ici t1. Ensuite dans la partie body il suffit de rappeler la region : region="t1"

Exemple 3 : le son de la chanson pendant les paroles défilent

le code du fichier smil est le suivant:

<smil> <head> <meta name="title" content="Texte, image et les Greyhounds" />

<layout>

<root-layout width="260" height="400" />

<region id="i" top="5" left="70" width="115" height="120" z-index="1"/>

<region id="t1" top="130" left="5" width="240" height="265" z-index="2"/>

<region id="t2" z-index="3"/>

</layout>

</head>
</body>

<seq> <par> <img src="image.rp" region="i" fill="freeze" />

<audio src=" http://monsite.com/ma_chanson.rm" />

<text src="texte.rt" region="t1" fill="freeze"/>

</par>

<text src="texte2.rt" region="t2" begin="3" fill="freeze"/>

</seq>

</seq>

</body> </smil>

L'intérêt de l'exemple son n'est ni dans le son ni dans le fichier smil. Le fichier smil est quasi identique a celui de l'exemple image et l'appel d'un fichier son se fait comme pour une image en remplaçant img src par audio src. Quant au fichier son c'est un ficher rm (real media qui est créer par helix producer (cf tutorial sur helix producer)

Sans définition de durée l'image et le texte ne disparaissent qu'après la durée du fichier son.

L'intérêt de cet exemple se cache donc dans le fichier rp. (realpix) qui sert à agencer les images.

<imfl>

<head timeformat="dd:hh:mm:ss.xyz"

duration="30.0"

bitrate="12000"

width="115"

height="120"

preroll="10.0"

/>

<image handle="1" name="image1.jpg" mime="image/jpeg"/>
<image handle="2" name="image2.jpg" mime="image/jpeg"/>
<image handle="3" name="image3.jpg" mime="image/jpeg"/>

<crossfade start="0.0" duration="1.0" target="1" dstx="0" dsty="0" dstw="320" dsth="240" aspect="true" />

<crossfade start="7.0" duration="1.0" target="2" dstx="0" dsty="0" dstw="320" dsth="240" aspect="true" />

<crossfade start="14.0" duration="1.0" target="3" dstx="0" dsty="0" dstw="320" dsth="240" aspect="true" />

<crossfade start="21.0" duration="1.0" target="1" dstx="0" dsty="0" dstw="320" dsth="240" aspect="true" />

</imfl>

96

Souleymane THIONGANE Ousseynou NDOYE

Dans la partie head on retrouve les méta informations, sur la durée, la taille, la fonction, ... Chaque image est définie par un identifiant unique.

Vient ensuite le magnifique effet de fondu enchaîné que vous avez pu voir. Start désigne évidement la durée qui sépare l'apparition de l'image du début de la présentation dstx, dsty sont des informations semblable à celle apportées par left, top etc dans l'exemple précédent. On remarquera qu'elles sont toutes identiques afin que les images soient jouée exactement au même endroit.

Il existe un grand nombre d'effets de transition et autre possible. Et ce d'autant plus depuis l'arrivée du smil2.0. Vous en trouverez une liste quasi exhaustive en parcourant les liens suivant :

sur le site de realnetwork et sur le site du wc3 (xml)

notes: cela implique l'ajout d'une ligne de code telle que celle-ci <smil xmlns=" http://www.w3.org/2001/SMIL20/Language"> Exemple 4 : Une vidéo, une image et du texte

le code du fichier smil est le suivant

<smil >

<head>

<meta name="title" content="4 media dans une présentation" /> <layout>

<root-layout height="199" width="478" backgroundColor="black"/> <region id="texte_region" width="325" height="113" left="150" top="5"/> <region id="video_region" width="170" height="113" left="5" top="5"/> <region id="image_region" width="468" height="60" left="5" top="130"/> <region id="t2" width="468" height="199" />

</layout>

</head>

<body>

<seq>

<par>

<textstream src="texte.rt" id="news" region="texte_region" fill="freeze"/>

<video src=" http://monsite.com/mavideo.rm" region="video_region" fill="freeze"/>

97

Souleymane THIONGANE Ousseynou NDOYE

<a href=" http://real-and-smil.com/embed.php" show="new">

<img src=" http://monsite.com/mabanniere.gif" region="image_region" fill="freeze" /> </a> </par>

<text src="texte2.rt" region="t2" begin="3" fill="freeze"/>

</seq> </body>

</smil>

On retrouve ici beaucoup des éléments vue précédemment. Les trois region texte, vidéo et image sont positionné dans la partie layout pour ne pas se chevaucher. Imbrication des balise seq et par.

On remarquera que même la vidéo est linkée, toujours avec du code html mais pour une fonction qui à ma connaissance n'existe pas en html.

Cette présentation comporte du texte, de l'image, du son, et de la vidéo. soit les quatre media.

A chaque fois ces éléments ne sont pas directement dans le code smil mais appelés par le code smil qui joue son rôle de mise en page et de synchronisation.

Voici la liste exhaustive des éléments qui peuvent être appelés.

Éléments	Définition
text	texte statique (.txt).
textstream	texte streamé RealText clips (.rt).
img	image : .jpg ou .gif (ne pas utiliser de JPEG progresif.
audio	son: .rm, .wma, .mov et .mpeg.
video	video :.rm, .rmvb, .avi, .wma, .mov et .mpeg.
animation	animation Shockwave Flash (.swf)
ref	Tout se qui ne rentre pas dans les autre catégorie par exemple les fichier .rp

Tableau 9 : Listes des éléments que peut joindre le SMIL

98

Souleymane THIONGANE Ousseynou NDOYE

Pour conclure je rappellerais que pour lancer les fichiers .smil en ligne il faut comme pour les fichiers .rm faire un meta fichier en .ram contenant l'adresse absolu du fichier smil.

ANNEXE C : LE COURRIER ELECTRONIQUE

Le courrier électronique repose sur un fonctionnement plus compliqué que celui du web. Pour la plupart des utilisateurs son fonctionnement est transparent, ce qui signifie qu'il n'est pas nécessaire le comprendre comment le courrier électronique fonctionne pour pouvoir l'utiliser. Néanmoins, la courte introduction ci-dessous permet d'en comprendre le principe et donne les moyens à un utilisateur de savoir comment configurer au mieux son client de messagerie ou de saisir les mécanismes fondamentaux du spam.

Fonctionnement du courrier électronique

Le fonctionnement du courrier électronique est basé sur l'utilisation d'une boîte à lettres électronique. Lors de l'envoi d'un email, le message est acheminé de serveur en serveur jusqu'au serveur de messagerie du destinataire. Plus exactement, le message est envoyé au serveur de courrier électronique chargé du transport (nommé MTA pour Mail Transport Agent), jusqu'au MTA du destinataire. Sur internet, les MTA communiquent entre-eux grâce au protocole SMTP et sont logiquement appelés serveurs SMTP (parfoisserveur de courrier sortant).

Le serveur MTA du destinataire délivre alors le courrier au serveur de courrier électronique entrant (nommé MDA pour Mail Delivery Agent), qui stocke alors le courrier en attendant que l'utilisateur vienne le relever. Il existe deux principaux protocoles permettant de relever le courrier sur un MDA :

· le protocole POP3 (Post Office Protocol), le plus ancien, permettant de relever son courrier et éventuellement d'en laisser une copie sur le serveur.

· le protocole IMAP (Internet Message Access Protocol), permettant une synchronisation de l'état des courriers (lu, supprimé, déplacé) entre plusieurs clients de messagerie. Avec le protocole IMAP une copie de tous les messages est conservée sur le serveur afin de pouvoir assurer la synchronisation.

Ainsi, les serveurs de courrier entrant sont appelés serveurs POP ou serveurs IMAP, selon le protocole utilisé.

Par analogie avec le monde réel, les MTA font office de bureau de poste (centre de tri et facteur assurant le transport), tandis que les MDA font office de boîte à lettres, afin de stocker les messages (dans la limite de leur capacité en volume), jusqu'à ce que les destinataires relèvent leur boîte. Ceci signifie notamment qu'il n'est pas nécessaire que le destinataire soit connecté pour pouvoir lui envoyer du courrier.

Pour éviter que chacun puisse consulter le courrier des autres utilisateurs, l'accès au MDA est protégé par un nom d'utilisateur appelé identifiant (en anglais login) et par un mot de

passe (en anglais password).

La relève du courrier se fait grâce à un logiciel appelé MUA (Mail User Agent).

Lorsque le MUA est un logiciel installé sur le système de l'utilisateur, on parle de client de messagerie (par exemple Mozilla Thunderbird, Microsoft Outlook, Eudora

Mail, Incredimail ou Lotus Notes).

Lorsqu'il s'agit d'une interface web permettant de s'interfacer au serveur de courrier entrant, on parle alors de webmail.

Relais Ouverts

Par défaut et pour des raisons historiques, il n'est pas nécessaire de s'authentifier pour envoyer du courrier électronique, ce qui signifie qu'il est très facile d'envoyer du courrier en falsifiant l'adresse électronique de l'expéditeur.

100

Souleymane THIONGANE Ousseynou NDOYE

Ainsi, la quasi-totalité des fournisseurs d'accès verrouillent leurs serveurs SMTP afin de n'en permettre l'utilisation qu'à leurs seuls abonnés ou plus exactement aux machines possédant une adresse IP appartenant au domaine du fournisseur d'accès. Ceci explique notamment la nécessité qu'ont les utilisateurs nomades de modifier les paramètres du serveur sortant dans leur client de messagerie à chaque changement entre le domicile et l'entreprise.

Lorsque le serveur de messagerie d'une organisation est mal configurée et permet à des tiers appartenant à des réseau quelconques d'envoyer des courriers électronique, on parle alors de relais ouvert (en anglais open relay).

Les relais ouverts sont ainsi généralement utilisés par les spammeurs, car leur utilisation permet de masquer l'origine des messages. Par conséquent, de nombreux fournisseurs d'accès tiennent à jour une liste noire contenant une liste des relais ouverts, afin d'interdire la réception de messages provenant de tels serveurs.