Memoire Laye Baba

Mise en place de Services à Valeur Ajoutée et d’un serveur de Streaming
Table des matières
PARTIE I : Les Services à Valeur Ajoutée
I LES RESEAUX MOBILES ………………………………………………………………12

1. Présentation ………………………………………………………………………..12
2. Les équipements terminaux ………………………………………………………..18
2.1 Les terminaux mobiles …………………………………………………...18
2.2 Le modem GPRS …………………………………………………………19
3.Les commandes AT ………………………………………………………………...22
II LES SERVICES A VALEUR AJOUTEE ……………………………………………...25

1. Définition …………………………………………………………………………..25
2. Réglementation …………………………………………………………………….25
3. Le service SMS mobile …………………………………………………………….28
4. Le service WAP ……………………………………………………………………33
MISE EN PLACE DE SERVICES A VALEUR AJOUTEE ……………………………..44

1. Etude du logiciel KANNEL………………………………………………………..44
1.1. Architecture de Kannel …………………………………………………...44
1.2. Kannel : passerelle SMS ………………………………………………….48
1.3. Kannel : passerelle WAP …………………………………………………49
1.4. Kannel et sécurité …………………………………………………………51
2. Installation et configurations ……………………………………………………….52
2.1. Pré requis …………………………………………………………………52
2.1. Installation ………………………………………………………………..52
3.1. Configurations ……………………………………………………………53
3. Mise en place de services SMS …………………………………………………….56
4. Mise en place de service WAP…………………………………………..………….57
PARTIE 2 : La Technologie du Streaming
I. LES DEUX METHODES DE STREAMING……………………………………………63

1. Streaming statique (ou pseudo-streaming)………………………………………....63
2. Streaming dynamique (ou « vrai » streaming) ……………………………………..63
II. LES DIFFERENTES ETAPES DU STREAMING …………………………………….64

1. Encodage ……………………………………………………………………………64
1.1 Compression avec un codec ……………………………………………….64
1.2 Multiplexage dans un conteneur …………………………………………..65
2. Diffusion des données sur le réseau - Buffering ……………………………………65
3. Lecture du média …………………………………………………………………...67
III TECHNOLOGIES UTILISEES POUR LE STREAMING …………………………..67

1. Real Networks ………………………………………………………………………67
2. Microsoft et Windows Media Player ……………………………………………….68
Abdoulaye Ly & Baba Ngom - 1- DUT 2 TELECOMS

3. Apple et Quicktime …………………………………………………………………68

4. Format mpeg4 ………………………………………………………………………68
5. Des solutions alternatives …………………………………………………………..69
IV. LES PROTOCOLES …………………………………………………………………….69
V. STREAMING UNICAST ET STREAMING MULTICAST …………………………..71

1. Streaming unicast …………………………………………………………………...71
2 Streaming multicast ………………………………………………………………….71
VI FORMATS DE FICHIERS, INCRUSTATION EN HTML …………………………..72

1 Streaming URLs et metafiles ………………………………………………………..72
1.1 Avantage des meta-files …………………………………………………...74
a. Exemples 1: URL sur un stream …………………………………….75
b. Exemples 2: URL sur une meta-file ………………………………...75
1.2 Que se passe-t-il lorsqu'
on clique sur l'
URL d'
un stream? ………………..75
1.3 Que se passe-t-il lorsqu'
on clique sur l'
URL d'
une meta-file ……………..76
2 Incrustation par <EMBED> ou <OBJECT> ………………………………………..76
VII QUELQUES REALISATIONS ………………………………………………………...79

1 RTN web-radio ………………………………………………………………………79
2 RTN Web-Tv et RTN vidéosurveillance …………………………………………….89
CONCLUSION………………………………………………………………………………100


Je dédie ce travail à :
Mes parents que je ne saurais remercier assez.
Mes frères et sœurs
Ainsi qu’à tous les membres de ma famille
Mes amis
Mes promotionnaires
Et Toute l’équipe de la RTN

Je dédie ce travail à :
Mes parents en guise de remerciements pour leur dévouement à mon
éducation et surtout aux sacrifices consentis pour la bonne marche de mes
études.
Serigne Saliou Mbacké (que dieu lui accorde longue vie et une santé de fer)
Mes frères et sœurs
Toute ma famille du sens restreint au sens large
Tous mes amis
Mes promotionnaires
Et toute l’équipe de la RTN


!
"
#" !

Avant-propos
L’Université Cheikh Anta Diop de Dakar compte plusieurs Ecoles et Instituts Supérieures
parmi lesquels l’Ecoles Supérieure Polytechnique. Celle-ci est constituée de six départements à
savoir :
le département Génie Chimique,
le département Génie Civil,
le département Génie Electrique,
le département de Gestion
le département Génie Mécanique
le département Génie Informatique
Ce dernier propose plusieurs cycles d’étude dont le cycle DUT (Diplôme Universitaire de
Technologie) en Télécommunications et Réseaux.
Les étudiants de ce cycle doivent effectuer un stage de moyenne durée en fin de
formation. Ce stage obligatoire vise à consolider les connaissances théoriques acquises et la
familiarisation des futurs diplômés avec le milieu du travail.
A l’issue de ce stage doit être présenté et soutenu devant un jury un mémoire de fin de
cycle portant sur le sujet traité.
C’est dans ce cadre que s’inscrit notre stage (du 05 juin au 15 juillet 2007) au sein de RTN
(Réseaux et Techniques Numériques).

SOMMAIRE
Réseaux et Techniques Numériques (R .T .N) est une nouvelle société sénégalaise spécialisée
en logiciels libres et centrée sur les services informatiques, techniques numériques et télécoms.
Elle est dirigée par une équipe de professionnels qualifiés, d’ingénieurs en téléinformatique, de
techniciens en informatique et réseaux, et des certifiés en administration réseaux et linux.
La RTN est devenue une société SARL depuis le premier janvier 2007.Cependant ses domaines
de compétences ont largement augmentés. Elle a pour objectif de dispenser toute une gamme
de formations ouvertes aux étudiants et aux professionnels, mais aussi d’assurer des services
assez diversifiés surtout dans le domaine de la télécommunication et des réseaux, auprès des
entreprises.
La RTN a une double vocation : la formation et la prestation de services .Elle dispense des
formations rigoureuses basées sur des supports de cours, fruits de recherches approfondies. Ces
supports testés et avérés permettent aux apprenants d’être aussitôt opérationnels. L’objectif
de RTN est de conseiller et de former le personnel des entreprises qui veulent disposer des
logiciels libres et adaptés à leur besoin minimisant ainsi les coûts d’investissements en réseaux
informatiques tout en leur apportant une sécurité avancée

Introduction
A l’ère des Nouvelles Technologies de l’Information et de la Communication, de toutes les

technologies, la téléphonie mobile est celle qui a connu le plus de succès.
Dans le monde entier les téléphones mobiles sont devenus pratiquement monnaie courante et
restent à la portée de toutes les bourses.
En parallèle, les entreprises disposent de plus en plus d’agents mobiles qui ont besoin de rester
connecté au système d’information de l’entreprise. Les employés doivent envoyer le plus
rapidement possible leur dernières commandes, ou dossiers, tout en étant à plusieurs centaines
de kilomètres de leur entreprise.
C’est pour cela que de nouvelles technologies de téléphonie et services mobiles ont vu le jour.
Allant de la voix à l’envoi de mini-messages, les services à valeurs ajoutées sont tournés
aujourd’hui vers les SMS surtaxés et l’internet mobile et font appel à de nouveaux protocoles
et langages.
Le monde des télécommunications étant une course permanente aux nouveaux services qui
entraînent de nouveaux abonnés. Ces nouveaux services que proposent les opérateurs et qui
tendent aujourd’hui vers le streaming et d’autres prestations innovantes augmentent les besoins
de transferts de données ce qui implique le développement de réseaux adaptés mais aussi de
nouveaux codecs.
Notre séjour à la RTN consistait à mettre en place des services à valeur ajoutée basés sur les
SMS, le WAP et le Streaming.

PARTIE I :
LES SERVICES A VALEUR AJOUTEE

I. LES RESEAUX MOBILES

Les téléphones portables sont totalement tributaires de réseaux de stations fixes (ou de base)
interconnectées entre elles et aussi avec le réseau téléphonique général.
Loin de se limiter à un rôle de transmission, un réseau mobile assure une foule de fonctions qui
en font un énorme système informatique dont les postes mobiles ne constituent, en fin de
compte, que de simples terminaux.
Bien plus encore que celles des téléphones, ce sont les possibilités du réseau de chaque
opérateur qui déterminent les services pouvant être offerts à ses clients.
1. Présentation
Nous allons ici vous présenter les architectures techniques des trois réseaux GMS, GPRS et
UMTS en utilisant un schéma évolutif et une description simplifiée ...
Architecture réseau GSM

Le réseau GSM a pour premier rôle de permettre des communications 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
- BSS Base Station Sub-system assure et gère les transmissions radios
· Le sous système d'acheminement
- NSS Network Sub System (on parle aussi de SMSS Switching and Management Sub-
System 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
- OSS Operation Sub-System) qui permet à l'

opérateur d'
exploiter son réseau.
La mise en place d'

un réseau GSM (en mode circuit) 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.
La mise en place d’un réseau GSM représente 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
des ensembles BTS – 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 – BSC – 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 …
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.
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 deux nouvelles entités :
· Le nœud de service
- le SGSN.
· Le nœud de passerelle

- le GGSN.
Une troisième entité
- 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.
La mise en place d'

un réseau GPRS va permettre à un opérateur de proposer de nouveaux
services de type " Data " à 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 SSGN 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 Kbit/s même s'
il est limité à
48 Kbit/s en mode descendant. (limite actuelle des terminaux GPRS).
Le 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 max. en GSM : 9.6 Kbit/s).
Le réseau GPRS constitue finalement une étape vers le réseau UMTS.

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 :
· 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).
· 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.
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
UMTS vient compléter ces deux réseaux par une offre de services Voix et Data
paquets, et l'
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 Mb/s. 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.
Après le GSM le réseau GPRS constituait finalement une étape vers le réseau
UMTS. 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é

2.Les équipements terminaux
2.1. Les terminaux mobiles
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 mêmes 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 en
sus.
- Classe B : Gestion de la mobilité des deux services mais seulement un des services peu être
utilisé. Le mobile sera donc correctement localisé en GSM et GPRS mais l’utilisation du GPRS
empêche une communication GSM et réciproquement.
- Classe C : le mobile ne peu utiliser que le GSM ou le GPRS, il doit se re-localiser 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 disponible 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 soit présent sur la cellule.
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 :
2.2. Le Modem GSM/GPRS
Présentation du modem Wavecom:

Il s'
agit d'
un modem téléphonique GSM fonctionnant dans les bandes de fréquences 900MHz et
1800MHz. Il intègre les fonctions de transmission de données/voix/SMS et la fonction de FAX.
.

Caractéristiques principales:
Bi-bande 900/1800 MHz
Tension d'alimentation: 5V à 32V
Transmission: données, SMS, voix, FAX
Programmable par commande AT
Puissance de sortie: 2W en GSM 900MHz et 1W en GSM 1800MHz
Paramétrage du modem
Le modem GSM Fastrack se paramètre directement à partir des commandes AT et utilise le
connecteur RS232. Le montage pour le paramétrage du modem est le suivant:
Remarque: la carte SIM doit être préalablement insérée dans le modem

La saisie des commandes AT se fait directement dans la fenêtre du mode hyper terminal du PC
(sous linux on utilisera minicom). Les commandes utilisées pour les tests sont présentées ci-
après.

Saisie du code PIN:

La commande AT+CPIN=1234 est nécessaire à chaque mise sous tension du modem. La
demande du code pin peut être désactivée par la commande AT+CLCK="SC",0,1234 (un
'
1'à la place du '
0'réactive la demande du code pin).
La vitesse de transmission du modem:

La valeur par défaut est 9600 b/s, et peut être modifiée par la commande AT+IPR=XXXX.
Format des données et parité:

La valeur par défaut est 8 bits de données et un bit de stop, et peut être modifiée par la
commande AT+ICF=x,y , ou x représente le format des données et y le type de parité.
La réponse automatique après deux sonneries
La commande ATS0=2 configure le modem en mode réponse automatique après deux
sonneries.
Ce mode peut être mémorisé par la commande AT&WS0 .
Remarque: La commande AT&V affiche la configuration interne du modem.

3. LES Commandes AT
La firme Hayes, fabricant de modems, a développé un protocole pour la commande d'

un
modem externe à partir d'
un ordinateur. Le protocole définit diverses commandes permettant
par exemple :
• de composer un numéro de téléphone

• de commander le raccordement du modem à la ligne (l'
équivalent de décrocher le
téléphone)
• de connaître l'
état de la ligne : tonalité d'
invitation à transmettre, ligne occupée...
• de spécifier le type de transmission et le protocole de liaison à utiliser
• de régler le volume sonore du haut-parleur interne du modem
• d'
envoyer les caractères transmis simultanément vers l'
écran
• d'
afficher certains renseignements concernant le modem
• de manipuler les registres internes du modem
Les commandes AT sont des commandes que l'

on peut directement envoyer au modem, lorsque
celui-ci est en mode Command, ce qui se produit :
• à la mise sous tension ;

• à la fin d'
une communication ;
• après l'
exécution d'
une commande autre que AT0 ou AT&T ;
• lors de la réception, alors que le modem est en mode on-line, d'
une séquence
d'
échappement (constituée de l'
envoi de 3 caractères identiques aux caractères stockés
dans un registre interne du modem) ;
• lors de la transition ON vers OFF de la ligne DTR (si D1, &D2 ou &D3 sont activés).

Ci-après, un résumé des commandes AT ; toutes les commandes doivent être précédées de AT.
Par exemple, ATA signifie "répondre".
• A/ réexécuter la commande précédente

• AT? lire le contenu du registre sélectionné
• A répondre
• Dn compose le numéro de téléphone n
• En commande de l'
écho
• Hn contrôle la prise de ligne et la déconnexion
• In identification du modem
• P sélectionne la numérotation par impulsions
• Qn contrôle du code "résultat" renvoyé par le modem après exécution de la
commande ; ce code est constitué soit de 1 à 3 chiffres (code court), soit d'
une chaîne
de caractères plus explicite (code étendu)
• &Dn option DTR (Data Terminal Ready)
• &Fn restaure la configuration par défaut du modem
• &Kn contrôle du flux d'
informations
• &Mn sélection du mode
• &Pn contrôle de la numérotation par impulsions
• &Qn sélection du mode
• &Tn test et diagnostic
• &Sn option DSR (Data Set Ready)
• &V afficher la configuration actuelle
• &Wn mémoriser la configuration actuelle
• &Yn sélectionne la configuration par défaut
• &Zn=x mémorise le numéro de téléphone x dans le registre n
• %En contrôle automatique fallback/fallforward
• \An sélectionne la taille maximum de bloc MNP
• T sélectionne la numérotation par tonalités
• Vn forme du code "résultat"
• Wn contrôle du code de résultat de connexion
• Xn contrôle du code "résultat" étendu
• Yn déconnexion avec long délai
• \Bn transmettre break au modem distant

• \Jn ajustement de la cadence DCE

• \Kn contrôle du break
• &Cn contrôle du DCD (Data Carrier Detect)
• Zn reset
Exemples d'utilisation des commandes AT
Composition de numéro de téléphone : ATDT(555)555-5555

(Attention parfois il faut mettre le signe ";" point virgule à la fin du numéro)
Répondre : ATA
Raccrocher : ATH
Exemples de codes "résultat"
• Forme étendue : OK, forme courte : 0, signification : confirmation d'

exécution d'
une
commande
• Forme étendue : CONNECT, forme courte : 1, signification : envoyé lorsque la
connexion est établie à 300bps
• Forme étendue : RING, forme courte : 2, signification : détection de la tonalité de
sonnerie
• Forme étendue : BUSY, forme courte : 7, signification : ligne occupée
• Forme étendue : CONNECT56000, forme courte : 82, signification : cadence de
transfert 56000bps

II. LES SERVICES A VALEUR AJOUTEE

1. Définition
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 Sénégal le fonctionnement et la mise en place de services à valeur ajoutée sont sous le
contrôle et la supervision de ARTP (Agence de Régulation des Télécommunications et des
Postes).
Leur déploiement fait l’objet d’une loi qui fixe la liste et les conditions requis pour mettre en
place ce type de services.
La législation des services à valeur ajoutée est régie par l’article 19 du code des
télécommunications 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 fixée comme suit :
1/ Messagerie électronique :
L'
échange, la lecture et le stockage d'
informations, sous forme de messages de données, entre
des machines se trouvant dans des sites distants. Le destinataire du message n'
est pas
nécessairement présent au moment de l'
envoi du message.
Elle est régie par les recommandations de l'
Union Internationale des Télécommunications X-
400 et X- 500 de l'
UIT-T.
2/ 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 appropriés.

Elle est régie par la recommandation de l'

Union Internationale des Télécommunications X-
485 de l'
UIT-T.
3/ 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 appropriés.
4/ Echange de données informatisé (EDI) :

L'
échange de données formatées de manière standard entre les différentes applications tournant
sur les ordinateurs de partenaires commerciaux avec un minimum d'
interventions manuelles.
5/ 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 possibilité d'
archivage et d'
accès à ces documents.
6/ Services d'information on-line :

L'
accès à des informations en ligne, en temps réel et sans intervalles d'
attente.
7/ 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.
8/ 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.
9/ 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.

10/ 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.
11/ Services mobiles :
Il s’agit des services suivants :
- 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 à un 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.

3. LE SERVICE SMS MOBILE
Présentation
Longtemps dédaignés, les mini-messages se taillent maintenant un étonnant succès, générant

un trafic et un chiffre d’affaires plus que significatifs.
Au-delà du simple échange de « petits mots » de 160 caractères au maximum, certains ont vu
là le plus court chemin vers des applications que l’on ne pensait pas voir naître avant
l’avènement des mobiles de « troisième génération ».
Baptisé SMS (Short Message Service), ce service s’inspire, en beaucoup plus perfectionné, du
principe des récepteurs de radiomessagerie ou pagers.
Les postes téléphoniques RNIS sont capables, on le sait, de recevoir des mini-messages sur leur
afficheur, et il en va exactement de même des téléphones portables GSM 900 ou 1800.
Simplement, un téléphone mobile n’étant pas nécessairement joignable en permanence et
pouvant (par définition) se déplacer un peu partout dans le monde, la mise en œuvre technique
est plus complexe.
Le principe de base est que les messages doivent être confiés à un centre de messagerie (SMSC
ou Short Message Service Center) du réseau GSM. C’est lui qui se chargera de les faire
parvenir dès que possible à leurs destinataires, où qu’ils se trouvent. Dès que possibles signifie
en l’occurrence dès que le mobile sera tout à la fois sous tension, dans une zone couverte par
un réseau GSM, et autorisé à communiquer sur celui-ci.
Tant que ces conditions ne sont pas remplies, le message est archivé par le centre de
messagerie jusqu’à concurrence de la durée de validité qui a été spécifiée par son émetteur
(souvent 72 heures, mais éventuellement beaucoup plus ou beaucoup moins).

Lorsque le destinataire est joignable (ou le devient), il ne faut bien souvent que quelques
secondes pour que le message apparaisse sur l’écran de son portable, annoncé par un signal
sonore et un pictogramme évocateur. En cas de saturation durable des réseaux, toutefois, un
délai de plusieurs heures, voire même de quelques jours, n’aurait rien d’invraisemblable…
Selon le degré de perfectionnement du mobile utilisé, un « accusé de réception » peut

cependant s’afficher lorsque le SMS a effectivement atteint sa destination. Et pour peu que
l’abonné mobile bénéficie d’une option « Monde » (souvent gratuite), ses SMS l’atteindront en
principe même à l’étranger.
L’envoi d’un SMS ne nécessite pas un grand déploiement coté opérateur car le trafic SMS
n’emprunte pas les mêmes canaux que les communications vocales (il transite par des canaux
de « signalisation » beaucoup moins sollicités).
Du coût les tarifs des SMS sont de plus en plus en baisse car le prix de revient chez l’opérateur
est insignifiant.
Les SMSC sont identifiés chacun par un numéro d’appel international rappelant celui d’un
portable, et dont voici quelques exemples :
+2216600990 (TIGO)
+2216380010 (Orange)
Composés normalement sur un téléphone, ils aboutissent pourtant sur message vocal « numéro
non attribué ». Ils ne sont en effet accessibles que depuis un téléphone GSM, et uniquement en
les programmant dans la carte SIM au moyen du menu des « paramètres SMS ».
Au surplus, chaque opérateur peut refuser l’accès à des SMSC autres que le sien, tout en
mettant celui-ci à la disposition de ses seuls clients. Là encore, on sera souvent mieux loti,
dans son propre pays, en étant client d’un opérateur étranger.
Des « passerelles » sont parfois disponibles depuis le réseau téléphonique ordinaire, accessible
par modem ou depuis un téléphonique fixe.

Plusieurs protocoles existent pour déposer des SMS auprès de ces centres, cela au prix d’une
courte communication téléphonique filaire. Bien que l’on puisse trouver des logiciels
permettant d’accéder à ces passerelles depuis un simple PC, il est infiniment plus facile de
transiter par des sites internet. Les opérateurs nationaux offrent sur leur site web l’envoi (de
plus en plus souvent payant….) de SMS vers leurs abonnés, parfois même avec un accusé de
réception par e-mail lorsque le message est effectivement arrivé à bon port.
Quelques sites indépendants permettent l’envoi de SMS gratuits, mais bien souvent au prix
d’une pression publicitaire plus ou moins insidieuse. Certains opérateurs GSM étrangers
offrent, pour leur part, la possibilité d’envoyer, sans frais, des SMS à des abonnés d’une foule
de pays. Ce n’est certes pas le moins étonnant que d’être ainsi mieux servi, et cela
gratuitement, par un opérateur du bout du monde, que par celui auquel on paie un abonnement
mensuel conséquent. Il est d’ailleurs fort tentant de voir ici l’une des raisons de ces
mystérieuses disparitions de SMS en provenance de certains pays.
Mais les applications des mini-messages vont bien plus loin que la simple communication entre
personnes.
Différents services de diffusion d’informations (boursière, météorologiques, d’actualité, de
trafic routier, etc.) sont en effet basés sur ce système fiable et peu coûteux.
Certains sont gratuits (du moins pendant une période d’essai …), d’autres payants, tandis que
l’on constate une certaine dérive publicitaire.
Les opérateurs eux-mêmes se servent largement de SMS pour informer leurs clients prépayés
du crédit dont ils disposent, pour signaler l’arrivée d’un message dans la une boîte vocale, pour
diffuser des flashs promotionnels, pour souhaiter la bienvenue à des visiteurs étrangers, mais
aussi beaucoup plus discrètement, pour modifier des abonnés dans la carte SIM ou le
téléphone lui-même. Une application à succès est ainsi le téléchargement de mélodies, de
sonneries personnalisées, de petits graphismes, ou de répertoires de numéros.
En attendant de décollage des services internet mobiles de « troisième génération »,

d’intéressantes possibilités ont même été imaginées pour recevoir et envoyer des e-mails au
moyen de SMS, et donc à relativement peu de frais. Il faut dire que la limite de 160 caractères

peut, sous certaines conditions, être repoussée jusqu’à 640 par « concaténation » (mise à bout
de plusieurs SMS).
Ajoutons, pour conclure, que les SMS commencent à se tailler un franc succès dans les milieux
industriels, pour des applications de télécommande et de télésurveillance de sites distants.
SMS ET SVA
Au Sénégal les SMS représentent un élément considérable dans le marché des services à valeur
ajoutée où ils sont utilisés pour mettre en place divers services fournis à des usagers (via leur
téléphone GSM) et dans lequel ils ont fait naître un nouveau jargon :
SMS-MO ou Short Message Service Mobile Originated :

Désigne un SMS émis par un Utilisateur depuis son terminal mobile.
SMS-MT ou Short Message Service Mobile Terminated :

Désigne un SMS reçu par Utilisateur sur son terminal mobile.
Numéro Court :
Désigne le code à 5 chiffres qui identifie le Service de l’ Editeur. Ce numéro court est
préalablement réservé par l’ Editeur auprès d’ un opérateur.
L’ utilisateur qui souhaite utiliser un service envoie un SMS-MO contenant un texte libre ou
prédéfini (mot-clef, paramètres) au Numéro Court dédié au Service.
Des fourchettes tarifaires sont associées aux différentes tranches de Numéros Courts dédiées
aux services SMS multi-opérateurs permettant à l'
utilisateur final une meilleure visibilité
tarifaire.
Le premier chiffre du Numéro Court indique le palier tarifaire du service associé.
Racine :
Désigne les 4 derniers chiffres d’ un Numéro Court.
Application :
Désigne une fonctionnalité accessible à l’ utilisateur dans le cadre d’ un service. Une

Mise en place de Services à Valeur Ajoutée et d’ un serveur de Streaming
Application est activée par au moins un mot clef spécifique envoyé par l’ Utilisateur via un
SMS-MO. Ce mot clef peut être complété par les paramètres permettant au Client de préciser
sa requête.
On distingue 3 catégories d’ Applications :
Les Applications de catégorie 1 permettent à un client d’ obtenir un contenu ou de

participer à un événement par l’ intermédiaire de la Plate-forme de services de l’ Editeur. La
cinématique d’ une Application de catégorie 1 correspond au schéma suivant : en réponse à un
SMS-MO émis par un client, l’ Editeur envoie un ou plusieurs SMS-MT vers ce même Client.
Les Applications de catégorie 2 permettent à un Client d’ échanger de manière

indirecte des SMS avec d’ autres utilisateurs identifiés et inscrits au service. Les échanges de
SMS entre utilisateurs doivent obligatoirement s’ effectuer via la Plate-forme de services de
l’ Editeur. La cinématique d’ une application de catégorie 2 correspond au schéma suivant : en
réponse à un SMS-MO émis par un client, l’ Editeur envoie systématiquement un ou plusieurs
SMS-MT vers un ou plusieurs utilisateurs inscrits au Service.
Les Applications de catégorie 4 permettent de proposer à des utilisateurs,

préalablement inscrits, l’ envoi de SMS-MT.
Le principe s’ appuie sur l’ envoi d’ un SMS, par le client, d’ un mot clé suivi de texte vers un
numéro court pour bénéficier d’ une application proposé par un éditeur. Cette application
sera mise à sa disponibilité et en guise de rémunération, le SMS envoyé par le client, avec
l’ aide de l’ opérateur sera surtaxé.

4. LE WAP
Les briques technologiques
Les architectures WAP reposent sur quatre briques technologiques principales. Ces briques
sont nécessaires pour transporter des services WAP vers le téléphone mobile. La fourniture de
services WAP nécessite :
La mise en place de serveurs Web et applicatif,
l’ intégration d’ une passerelle ou serveur WAP,
Le réseau de l’ opérateur,
l’ utilisation par le client d’ un terminal compatible WAP, c’ est à dire qui héberge un
navigateur WAP.
Les similitudes avec les architectures Web s’ expliquent facilement. En effet, ces deux
architectures remplissent la même mission qui est de générer des documents à partir de
différentes sources de données et de les transmettre à un navigateur dédié.
• Le serveur Web
Dans l ’ architecture WAP, le serveur Web permet de générer les pages qui seront transmises
au terminal mobile via la passerelle WAP. Le serveur Web doit donc accéder à des serveurs
applicatifs ou à des bases de données afin de générer le contenu des pages transmises. La
fonction initiale du serveur Web qui est la transmission de pages HTML est ici étendue afin de
transmettre des pages encodées au format de document spécifique du WAP, le WML.
• La passerelle/serveur WAP
La passerelle WAP est l’ élément qui différencie le WAP du Web. Elle assure deux
fonctionnalités principales :
elle réalise la connexion entre le réseau informatique et le réseau téléphonique sans fil,
elle code et décode les requêtes et les réponses entre le terminal mobile et le serveur
Web.

Cette seconde fonctionnalité est spécifique au WAP. Afin de réduire la taille des données
transmises, les requêtes et les réponses sont encodées dans un format binaire compact. Les
fichiers au format WAP sont compilés par la passerelle avant d ’ être envoyés vers le terminal
qui se charge de les décoder puis de les interpréter.
Certains constructeurs incorporent également un serveur applicatif dans leur passerelle afin d ’
offrir des services complémentaires. Dans ce cas, on parle de serveur WAP ; il est en mesure de
produire lui-même les documents qui seront transmis au téléphone mobile.
Certaines passerelles exécutent par exemple des servlets (applications écrites en JAVA) ou
interprètent un langage script afin de générer dynamiquement des pages aux formats
compatibles WAP.
• Le réseau de l’opérateur mobile

L’ opérateur fournit les services de transmission radio nécessaires au fonctionnement des
mobiles. Au Sénégal, Orange et Tigo se partagent le marché actuel.
Toutes les transmissions de données WAP utilisent donc le réseau d’ un opérateur pour
atteindre le mobile.
• Le navigateur (sur le téléphone mobile ou l’assistant personnel)
Le navigateur se charge de décoder les informations transmises par la passerelle WAP afin
d’ afficher les pages pour l’ utilisateur. Il joue le même rôle qu’ un navigateur Web tel
qu’ Internet Explorer ou Netscape Navigator. Les navigateurs disponibles sur le marché des
téléphones mobiles sont présentés dans les chapitres suivants.
Le protocole WAP
• Présentation générale

Le mode d’ échange des données du protocole WAP est basé sur le modèle client- serveur
utilisé par le Web.
L ’ architecture du protocole WAP définie par le WAP Forum est organisée en cinq couches.
Elles se situent toutes au-dessus des différentes normes de communications sans fil telles que
GSM, CDMA, iDEN, Flex, ce qui permet d ’ assurer l ’ indépendance du protocole vis à vis
des solutions matérielles adoptées par l ’ opérateur télécom.

• La couche application (Wireless Application Environment)
Cette couche a pour but d’ offrir un environnement de développement et d ’ utilisation, où l ’

interopérabilité entre opérateurs, fournisseurs de services et constructeurs de terminaux est
assurée. Elle est basée sur une combinaison de techniques issues du Web et de la téléphonie.
Elle définit l’ interface utilisateur sur le terminal mobile. Les « outils » spécifiés dans cette
couche permettent le développement d ’ applications basées sur le protocole WAP.
L’ environnement prend en compte:
WML: Il s’ agit du langage d’ encodage des données qui sont affichées par le navigateur
WAP. WML est pour le WAP ce que HTML est pour le Web. La version courante est la 1.1.
WMLScript: c’ est l’ équivalent du Javascript pour le WAP. Il s’ agit d’ un langage script

côté client. La version actuelle est la 1.1.

WTA (Wireless Telephony Applications) : Il s’ agit de l’ ensemble d’ interfaces pour la

réalisation d’ applications téléphoniques. Ces interfaces doivent par exemple permettre
d’ accéder directement aux fonctions de téléphonie du téléphone : composer un numéro, activer
la boîte vocale etc.
• La couche session (Wireless Session Protocol)
Cette couche intermédiaire relie la couche application à deux modes de session possibles :
Le premier est orienté connexion et opère au-dessus de la couche transaction.
Le second est orienté non-connexion et agit directement au niveau de la couche

transport.
Ces deux protocoles permettent d’ utiliser des sessions de « longue durée » avec arrêt et reprise,
de mettre en place des communications initiées par le serveur (push) et de négocier les
caractéristiques de la suite de l ’ échange d ’ informations.
• La couche transaction (Wireless Transaction Protocol)
Cette couche contrôle trois types de transactions :

les transactions à sens unique sans acquittement (non fiables).
les transactions à sens unique avec acquittement (fiables).
les transactions à double sens avec acquittement (fiables).
Ces trois types de transaction peuvent être asynchrones et les acquittements peuvent être mis en
attente temporairement et regroupés, afin de réduire le nombre de messages.
Cette couche sert d ’ interface avec le monde IP : elle permet d ’ encapsuler les données dans
des paquets UDP.
• La couche sécurité (Wireless Transport Layer Security)
Cette couche a été définie pour être employée avec la couche transport. Elle assure la sécurité
des échanges de données.

Le chapitre « WAP et sécurité » développe la présentation de cette couche essentielle aux

applications transactionnelles sécurisées.
• La couche transport (Wireless Datagram Protocol)
Elle est à la base de la pile protocolaire WAP. Cette couche permet d ’ interagir avec les
protocoles de transfert des données proposées par les opérateurs télécoms. Elle assure aux
autres couches du protocole WAP l ’ indépendance vis à vis du type de réseau sans fil utilisé
pour l ’ acheminement des données sur le réseau de téléphonie mobile.
• Les différentes configurations des couches
La pile des couches précédentes peut varier d ’ une implémentation à une autre suivant le type
de services souhaités et le support. Les applications peuvent interagir avec différents niveaux
de la pile.
• Le Pull et le Push

Pour accéder à l’ information, l ’ utilisateur peut aller la chercher directement : on parle de « pull
». Il peut aussi (grâce à un abonnement), la recevoir sans demande particulière : on parle alors
de « push ».
Le modèle du « pull » correspond à celui mis en oeuvre sur le Web. L ’ utilisateur saisit dans
son navigateur l ’ adresse du site qu ’ il souhaite consulter. La consultation de pages WML à
l’ aide d ’ un navigateur compatible WAP utilise aussi ce modèle.
Les adresses de la passerelle WAP et du service d ’ accès employé sont préalablement

configurés dans les paramètres de connexion du terminal.
L’ utilisateur saisit dans le navigateur du terminal l ’ adresse du site à consulter ou la

sélectionne dans la liste des signets enregistrés sur son terminal. La requête générée est
véhiculée vers le site recherché au format WTP jusqu ’ à la passerelle WAP (1).
Cette dernière assure la conversion (2) de cette requête du format WTP au format HTTP qui est
le protocole utilisé sur le Web. Le serveur Web reçoit la requête HTTP et génère en retour
l’ information au format WML issues des contextes applicatifs (bases de données, autres
serveurs Web, serveurs applicatifs… ).
Puis il envoie (4) les données WML véhiculées au format HTTP vers la passerelle WAP qui
assure la conversion (5) des données du format HTTP au format WTP. Les données
WML/WTP sont reçues par le terminal et affichées par le navigateur compatible WAP.

Dans ce modèle, la passerelle WAP assure uniquement la conversion des protocoles

HTTP/WTP. Si un serveur WAP est utilisé, la génération d ’ information peut se faire
directement au niveau de ce serveur sans utiliser de serveur Web. Cependant l ’ utilisation d ’
un serveur Web permet de disposer de méthodes communes Web/WAP d ’ accès aux données
comme l ’ utilisation de la technologie XML.
Aujourd’ hui le « Push » est réalisé sur les téléphones portables à la norme GSM par l’ envoi de
messages courts SMS. Ce procédé est limité à l’ envoi de texte de 160 caractères. La mise en
place de solutions « Push » n ’ est pas réalisable sur l ’ actuel standard WAP 1.1.
Elle le sera quand le futur standard WAP 1.2, en cours de spécification, sera opérationnel. Le
principe consiste à utiliser une nouvelle brique technologique : la passerelle Push Proxy qui
peut être incorporée directement dans un serveur WAP. Le serveur initiateur envoie l ’
information à cette passerelle au format XML (1). Cette passerelle (2) assure l ’ envoi de l ’
information au terminal mobile (3) et informe le serveur initiateur sur son acheminement.
Les différentes architectures
Les architectures suivantes présentent les différentes possibilités d’ intégration des briques
technologiques qui composent une plate-forme WAP.
La norme GSM est basée sur des communications radios. Le lien entre le monde de la radio et
celui de l’ informatique s ’ effectue au travers d ’ un modem.

Dans les exemples suivants, nous considérons tout d ’ abord que l ’ accès distant (RAS 7 ),
c’ est à dire la connexion aux modems s ’ effectue au même niveau que celui de la passerelle
WAP.
• Passerelle WAP hébergée chez l’opérateur
Cette architecture est la solution par défaut proposée par les opérateurs de téléphonie mobile
pour accéder aux services WAP. L’ opérateur héberge dans ce cas le service d’ accès distant
(accès réseau IP) et la passerelle.
Les services WAP référencés sur les portails des opérateurs utilisent ce type de solution dont la
mise en œ uvre est simple. En outre tous les services WAP publiques peuvent utiliser ce modèle
quelle que soit la localisation du serveur Web qui héberge l’ application. Ce modèle repose sur
la volonté des opérateurs de laisser leur passerelle ouverte sur Internet. C ’ est la position qui a
été annoncée par France Telecom et SFR lors du séminaire « La technologie WAP en France »
organisé par Euroforum les 28 et 29 Mars dernier.
• Passerelle WAP hébergée chez un fournisseur d ’accès.
Avec hébergement des serveurs Web :

Cette solution permet d’ être indépendant des opérateurs de téléphonie mobile (Orange et Tigo
pour le Sénégal). Dans ce modèle, seule la connectivité GSM/RTC des opérateurs est utilisée.
L’ utilisateur compose ainsi directement le numéro du fournisseur d’ accès qui dispose en
interne de modems et d’ une passerelle WAP. Le fournisseur d'
accès WAP joue le rôle d’ un
opérateur télécom alternatif spécialisé dans la connexion à Internet via le WAP. Cette solution
permet de s’ affranchir de certaines contraintes rencontrées chez les opérateurs de téléphonie
mobile.
Sans hébergement des serveurs Web :
Les fournisseurs d’ accès proposent également la connexion à des services sur l ’ Internet via
leurs passerelles.

Dans cette architecture, les fournisseurs d’ accès WAP jouent le même rôle que les fournisseurs
d’ accès Web. Leur mission est ici de faciliter l’ accès à des services WAP hébergés sur
l’ Internet via leur passerelle. Cette architecture permet aux clients de garder l’ entière maîtrise
des services hébergés sur leur serveurs Web. Dans tous les cas, le client doit porter une grande
attention à la politique de refacturation des communications.
• Passerelle WAP en interne
L’ intérêt de cette solution est de garder la maîtrise des connexions WAP. Les applications
WAP peuvent ainsi accéder à certaines informations spécifiques qui ne sont pas visibles depuis
le serveur Web. Les accès aux contenus et donc aux données de l ’ Intranet peuvent ainsi être
contrôlés plus efficacement. Il est important de noter que dans le cadre de l’ implémentation de
services d ’ Intranet WAP sensibles, il est préférable d’ effectuer l’ accès RAS depuis des
modems directement chez le client.
• Séparation RAS/Passerelle
Il est également possible de mettre en place des architectures WAP pour lesquelles, les
services de connexion par modem sont séparés de la plate-forme WAP. L’ utilisateur passe alors
par une passerelle publique sur l ’ Internet afin de pouvoir accéder à des services WAP.
Plusieurs sociétés proposent ainsi des passerelles en libre accès.

III MISE EN PLACE DE SERVICES A VALEUR AJOUTEE
1. 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 (Red Hat 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.
1.1. 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 :
• Les centres SMS (SMSC), utilisant divers protocoles.

• Les serveurs HTTP, pour les contenus WAP et SMS et fournit le contenu des « WAP
push ». HTTP est utilise pour le “pull”, et PAP pour le push .
• Les terminaux WAP, implementant la pile de protocole WAP et (pour le « push »)
WAP Push client.
Figure 4-1. interfaces externes de Kannel

Il existe plusieurs vendeurs de Centres SMS et la plupart d’ entre eux utilise 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 sont :
- 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’ empêche
certaines connections permettent à l’ usager de spécifier lui-même 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
requête HTTP lente priver d’ autres requêtes d’ être 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 au 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 requêtes 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
œ uvre.
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 connection 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.
Figure 4-2. Boxes of pull Kannel
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 grâce à un système de « battement de cœ ur (semblable au ping) »

• Le bearer box
Le bearerbox reçoit les messages UDP envoyés depuis les téléphones, les ré achemine vers les
wapboxes, 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 même adresse IP sera acheminé vers le même
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 4-4. architecture du Bearerbox

• LE Wap Box
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. WTLS 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
push).Pour le push confirmé, s’ il est orienté-session, la passserelle 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
réquête résultante utilise un support IP.
1.2. KANNEL Passerelle SMS
Le SMS, Short messaging Service, est un moyen d’ envoi de messages courts (160 caractères) à
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 d ‘appels, 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 1-2. Position logique de la passerelle SMS entre un mobile et un serveur de contenu.
Une passerelle SMS peut aussi être utilisé pour relayer les messages SMS du réseau GSM vers
un autre type de réseau.
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 connection 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 d ‘envoyer
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.
1.3. KANNEL Passerelle Wap
WAP, abréviation de Wireless Application Protocol, est une collection de diverses 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
généraux de protocole à quelques octets par demande, au lieu des centaines habituelles
d’ octets. Ainsi, WAP définit une nouvelle pile de protocole à employer. 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.

Fig3. Position logique de la passerelle WAP (et de PPG) entre un téléphone et un serveur de contenus
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.
1.4. Kannel et sécurité

En ce qui concerne l’ accès à distance au bearbererbox Kannel utilise SSL pour les transactions
sécurisées entre le bearerbox et les smsbox et wapbox auxquels il est connectés.
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. Installations et configurations
2.1 Pré requis
Kannel exige l'

environnement de logiciel suivant :
• 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é)
• La bibliothèque de Gnome XML (connue sous le nom de gnome-xml et libxml), version
2.2.5 ou plus nouveau. Voir http://xmlsoft.org/xml.html.
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.
Les besoins en matériel sont plus pelucheux. Quelques benchmarkings ont prouvé qu'
avec une
architecture raisonnablement rapide de PC (par exemple 400MHz Pentium II avec RAM
128MB), le hic de l'
exécution de SMS est toujours du côté de SMSC, même par exemple avec
les raccordements multiples additionnant une canalisation avec 400 msg/sec.
2.2 Installation
Obtenir le code source

Le code source de Kannel est disponible pour le téléchargement chez

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
Compiler kannel :
Se positionner dans le répertoire ou est décompressée (dans notre cas /usr/local/gateway/)
kannel et lancer les commandes :
#./configure
# make
Installer kannel
Dans le répertoire d’ installation on tape :
# make install
2.3Configurations:
Le fichier de configuration peut être divisé en trois parties :
configurations de bearerbox,
configurations de smsbox
et 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
Groupe core :
group = core
admin-port = 13000
admin-password = f00bar
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"
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
Configurations du wapbox
Il contient un seul groupe :wapbox
group = wapbox
bearerbox-host = localhost
log-file = "/var/log/wapbox.log"
log-level = 0
syslog-level = none
Configurations du smsbox
Groupe smsbox
Il définit la configuration de Kannel qui gère l’ envoi et la réception de sms .
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. La 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 = jeux
post-url= "http://localhost/credit/jeux.php?sender=%p&text=%r"
catch-all = true
max-messages = 3
concaténation = true
Parmi es variables qui spécifient le type de traitement on peut citer :
post-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 bearbox:
/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. Mise en place de service SMS

Pour mettre en place un service SMS il faudra :
-ajouter un groupe sms-service :
group = sms-service
-définir un mot clé
keyword = motclé
-définir le type d’ application associé
Configuration d’un jeux SMS

Nous allons voir comment on peut configurer un jeux sms avec kannel .
#ajoutons un groupe sms-service :
group = sms-service
#définissons un mot clé
keyword = jeux
#définir le type d’ application associé
post-url =“ http://localhost/credit/jeux.php?sender=%p&text=%r“
où :
jeux.php est le programme de traitement
sender et text sont des variables renseignées transmises au programme
%p représente le numéro de l’ expéditeur du message
%r représente ce qui vient après le mot clé
Dans cette optique il est tout à fais facile de mettre en place tout type de service SMS que l’ on
désire allant aux jeux jusqu’ aux virement bancaire car kannel est capable de récupérer toutes
les composantes du messages.
Alors nous allons mettre en exécution le jeu configuré ci-dessus :
Il s’ agit (probablement par la publicité) de demander l’ actuel roi des arènes .Et pour favoriser
la participation de plusieurs joueurs, nous allons rendre plus facile la question en donnant des
indices.

Il s’ agira ensuite d’ éditer le fichier php qui permettra, lorsque les variables sender et text sont
renseignées de les mettre dans une base de donnée et d’ envoyer une phrase comme : « votre
participation est prise en compte, bonne chance ! » ou bien « réponse enregistrée , rejouer
pour augmenter votre chance ! »
Le tirage au sort se fera à la fin du jeu ou périodiquement en choisissant au hasard un numéro
parmi ceux enregistrés dans la base de données.
Administration d’une machine par SMS

Nous avons eu à mettre en place un système qui permet de pouvoir démarrer des services sur
une machine ou bien d’ exécuter une commande système .Le mécanisme est semblable à celui
du jeux SMS mais à la différence que les paramètres seront transmis au shell qui se chargera de
l’ exécution .
Démarrage d’un service
La procédure est la suivante :
#ajoutons un groupe sms-service :
group = sms-service
#définissons un mot clé
keyword = service
#définir le type d’ application associé
exec = service %s %s
où :
service est la commande service
le premier %s représente la première chaîne de caractère après le mot clé
le second %s représente la seconde chaîne après le mot clé
Ainsi lorsqu’ on envoie à partir d’ un mobile : service ldap restart le système exécutera la
même commande.
NB : Pour éviter de rendre vulnérable le système, nous allons réserver l’ accès à ce service qu’ a
un seul utilisateur(l’ administrateur) en mettant sont numéro seul dans white-list
#réservons aux administrateurs l’ accès à ce service
white-liste = "http://localhost/list.txt"
Evidemment dans list.txt il y a les numéro de ceux qui peuvent utiliser le service.
4. Mise en place de service WAP

Le wap push
La configuration du Wap Push se fait comme suit
• Ajout d’ un groupe Ppg (Push Proxy Gateway ) dans Kannel.conf
# PPG CORE SETUP, for defining the push request interface

group = ppg
ppg-url = /cgi-bin/sendsms
ppg-port = 8080
concurrent-pushes = 100
users = 1024
trusted-pi = true
#ppg-allow-ip = 127.0.0.1
ppg-allow-ip = "*.*.*.*"
service-name = wap
default-smsc = http
• Ajout d’ un groupe d’ utilisateurs Wap-push

group = wap-push-user
wap-push-user = baba
ppg-username = laye
ppg-password = passer
allow-ip = 62.254.217.163
• Démarrer le bearerbox et le wapbox

bearerbox /etc./kannel.conf
wapbox /etc./kanel.conf
Le contenu du push se présente sous forme de document xml et se présente comme suit :
<?xml version="1.0"?>
<!DOCTYPE pap PUBLIC "-//WAPFORUM//DTD PAP//EN"
"http://www.wapforum.org/DTD/pap_1.0.dtd">
<pap>
<push-message push-id="9fjeo39jf084@pi.com">
<address address-
value="WAPPUSH=+2214870830/TYPE=PLMN@ppg.carrier.com"/>
</push-message>
</pap>

Ainsi les messages push pourront être envoyés via un navigateur web,en
s’ authentifiantd’ abord, puis en entrant le numéro de téléphone du destinataire et le contenu du
message push ou en tapant une commande shell selon la syntaxe suivante :
test/test_ppg -q http://ppg-host-name:ppg-port?username=ppg-
username’&’
password=ppg-password [content_file] [control_file]
exemple:
test/test_ppg -q http://127.0.0.1:8080?username=laye’ &’
password=passer /usr/local/gateway/gw/test/test_ppg.txt /etc/kannel.conf
Wap pull
o Les OTA settings

La configuration du wap pull se fait en configurant simplement le groupe wapbox.
La configuration des mobiles pourra se faire automatiquement en envoyant par SMS les
paramètres nécessaires à la configuration du mobile ou en les entrant manuellement.
Un message contenant les paramètre de configuration Wap d’ un terminal est appelé OTA
(Over- the -Air) le langage utilisé est le XML .
Un groupe portant le nom de ota-settings devra au préalable être ajouté dans le fichier de
configuration de kannel :
group = ota-setting
location = http://wap.company.com
service = "Our company’s WAP site"
ipaddress = 10.11.12.13
phonenumber = 013456789
bearer = data
calltype = analog
connection = cont
pppsecurity = off
authentication = normal

login = wapusr
secret = thepasswd
Le fichier contenant les configurations se présente ainsi :

<!DOCTYPE CHARACTERISTIC-LIST SYSTEM "file://gw/settings.dtd">
<CHARACTERISTIC-LIST>
<CHARACTERISTIC TYPE="ADDRESS">
<PARM NAME="BEARER" VALUE="GSM/CSD"/>
<PARM NAME="PROXY" VALUE="10.11.12.13"/>
<PARM NAME="PORT" VALUE="9201"/>
<PARM NAME="CSD_DIALSTRING" VALUE="+12345678"/>
<PARM NAME="PPP_AUTHTYPE" VALUE="PAP"/>
<PARM NAME="PPP_AUTHNAME" VALUE="yourusername"/>
<PARM NAME="PPP_AUTHSECRET" VALUE="yourauthsecret"/>
<PARM NAME="CSD_CALLTYPE" VALUE="ISDN"/>
<PARM NAME="CSD_CALLSPEED" VALUE="9600"/>
</CHARACTERISTIC>
<CHARACTERISTIC TYPE="URL"
VALUE="http://wap.company.com/"/>
<CHARACTERISTIC TYPE="NAME">
<PARM NAME="NAME" VALUE="Your WAP Company"/>
</CHARACTERISTIC>
</CHARACTERISTIC-LIST>
On pourra donc envoyer les paramètres de configuration à un mobile en tapant dans un URL :
http://smsbox.host.name:13013/cgi-bin/sendota?
username=foo&password=bar&to=0123456&
text=MyURLEncodedXMLdocument&type=settings
• Le site wap
La création d’ un site wap est semblable à celle d’ un site web seulement les pages seront écrites
en WML au lieu de HTML.
Exemple de page en WML :
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml">
<wml>
<card id="main" title="Hello, world" newcontext="true">
<p>Bienvenue sur le site wap de RTN.</p>
</card>
</wml>

Pour prévisualiser les pages wap on peut utiliser un émulateur wap comme Deck-it :

Partie II :
LA TECHNOLOGIE DU STREAMING

I. LES DEUX METHODES DE STREAMING
1. Streaming statique (ou pseudo-streaming)
• Il s’ effectue à partir d’ un serveur web « standard » et utilise les protocoles HTTP et

FTP basés sur TCP. Il ne nécessite donc pas de serveur spécialisé.
• Il consiste à lire progressivement le fichier multimédia pendant son téléchargement.
Après un temps de latence nécessaire au chargement des premières secondes, celles-ci
sont lues tandis que la suite du fichier se charge. Le fichier est donc simplement
proposé au téléchargement, de la même manière que tout autre type de fichier, et c'
est le
navigateur ou client (lecteur multimédia) qui se charge d'
effectuer le streaming. La
copie du fichier téléchargé est détruite par le navigateur à la fin du traitement.
• Il permet de délivrer tout type de médias mais préalablement préenregistrés : il ne peut
pas transmettre de flux en temps réel.
• Les paquets perdus sont retransmis jusqu'
à ce qu'
ils soient reçus.
• Il ne peut pas utiliser les modes de fonctionnement en broadcast ou multicast
• Il ne peut pas sauter un passage de la vidéo sans télécharger tout le début.
• Il n’ est pas arrêté par les Nat ou par les FireWall.
• Il ne s’ adapte pas à la qualité de connexion de l'
utilisateur. Il devient ainsi souvent
nécessaire de proposer sur le serveur plusieurs fichiers encodés en plusieurs qualités
(avec des résolutions différentes) afin de permettre à l'
utilisateur de choisir en fonction
des capacités de sa connexion.
2. Streaming dynamique (ou « vrai » streaming)
• Il nécessite un serveur spécialisé, appelé serveur de streaming, et utilise le protocoles

RTP / RTCP sur UDP pour diffuser le contenu.
• Il n'
est pas nécessaire de télécharger l'
ensemble du fichier. Le serveur n'
envoie à
l'
internaute que les données dont il a besoin, qui sont automatiquement effacées après
lecture.
• Ce streaming est le seul capable de transmettre du contenu en temps réel. Il convient
également pour la diffusion de médias préenregistrés.
• C’ est le support des modes broadcast et multicast (un seul flux pour plusieurs clients).

• Il n'
utilise jamais plus de bande passante que nécessaire.
• Il autorise un accès aléatoire pour les vidéos préenregistrées.
• Il ne laisse pas de copie du média sur le disque dur du client.
• La vidéo est coupée si le flux de données est supérieur à la bande passante disponible.
• Les transmissions peuvent être affectées par des pertes de données.
• Il peut être bloqué par certains NAT ou FireWall.
II LES DIFFERENTES ETAPES DU STREAMING
Le streaming est le traitement appliqué à un flux de données en temps réel transitant sur le
serveur ou à un montage vidéo ou à un fichier audio installés sur le serveur. Il procède en
plusieurs étapes :
1. Encodage
Afin de réduire le nombre de paquets de données à transmettre (et donc économiser la bande
passante nécessaire) et permettre leur lecture en temps réel, les fichiers multimédias doivent
être compressés dans un format de streaming du serveur : c'
est l'
encodage.
Cela suppose deux opérations : la compression à l’ aide d’ un codec et le multiplexage dans un

conteneur (muxeur).
1.1 Compression avec un codec
Un codec (pour "COmpression/DECompression") est un algorithme de compression utilisé

pour réduire la taille d'
un flux ou d’ un fichier (audio ou vidéo). Il génère un format de
compression spécifique. Il y a des codecs audio et des codecs vidéo.
MPEG-1, MPEG-2, MPEG-4, Vorbis, DivX, (etc.) sont des codecs.

Il existe de nombreux formats de compression.
On distingue deux types de compression :
• La compression sans perte

La compression sans perte se base sur la fréquence d'
apparition de mots binaires dans le
flux binaire représentant une image ou une source audio. Elle réduit la quantité

d'
information à transmettre aux clients en comptabilisant le nombre de fois qu'
apparaît
continuellement chacun des mots binaires les plus fréquemment rencontrés.
• La compression avec perte
La compression avec perte, quand à elle, réduit la quantité d'
information à transmettre
en dégradant sensiblement les données tout en conservant l'
information la plus
pertinente du média. Les limites des perceptions auditives et visuelles humaines aidant,
ces formats de compression permettent d'
obtenir des ratios avoisinant le 1/10 tout en
conservant une qualité visuelle ou auditive.
1.2 Multiplexage dans un conteneur
Le multiplexage consiste à encapsuler (empaqueter) ensemble les différents flux requis dans un
même fichier (conteneur) avant que celui-ci ne soit diffusé sur le réseau.
Un conteneur (ou muxeur) contient donc un ou plusieurs flux déjà encodés à l'
aide de codecs,
mais aussi d’ autres informations qui définissent comment lire les données en indiquant le nom
du codec nécessaire au décodage des flux audio et vidéo. Généralement, il y a un flux vidéo et
un flux audio. Les formats conteneur les plus avancés sont capables de gérer de l'
audio, de la
vidéo, des sous-titres, des chapitres et des métadonnées (ou tags) et de façon synchronisée pour
que les différents flux soient bien lus en même temps.
WAV, AIFF (etc.) sont des conteneurs audio (flux audio seulement).
AVI, OGG, MOV, ASF, MP4 (etc.) sont des conteneurs vidéo (flux audio et
vidéo).
Les flux contenus peuvent être encodés à l'

aide de codecs différents. Attention, tout codec n’ est
pas compatible avec tout conteneur.
Ainsi, un fichier AVI peut contenir du divx avec du mp3, ou wma, ou du mpeg, par exemple.
L'
extension du fichier donne ainsi le type du conteneur des flux présents dans le fichier et les
possibilités offertes à la lecture.
2. Diffusion des données sur le réseau - Buffering
Le fichier audio ou vidéo (le conteneur) est ensuite placé sur le serveur qui, à chaque requête
d'
un internaute, duplique le fichier demandé et le délivre sous la forme d'
un flux continu de
données (petits paquets de données marqués temporellement afin d’ être réordonnancés de
manière cohérente par le client).

C'
est le serveur de streaming qui se charge de faire correspondre une URL ("Mediafile") à un
flux temps-réel (direct) ou à un fichier préenregistré (différé):
[protocole]://[hôte]/[chemin de fichier ou d'encodeur]
Par exemple:
rtsp://www.rtn.sn/encoder/stream_1
pnm://www.rtn.sn/medialib/fichier_a
mms://www.rtn.sn/medialib/fichier_b
Protocoles : rtsp (protocole de l'

IETF, voir-ci dessous), pnm (Real Media), mms (Microsoft)
Remarque : Le métafichier SMIL, suffixe .smil ou .smi, est un type spécial de métafichier.
Techniquement parlant ce n'
est pas un métafichier, mais son but est similaire. Le fichier smil
permet de combinaison et l'
intégration de différents contenus multimédias diversifiés (images,
sons, textes, vidéo, animations, flux de texte) au sein d'
une page Web en les synchronisant afin
de permettre la création de présentations multimédias.
Plutôt que d'

incruster un lien de ce type dans un document HTML, on préfère utiliser un
metafile qui n'
est autre qu'
une référence (pointeur) vers un mediafile. La forme la plus simple
de metafile est un fichier texte contenant un URL de la forme ci-dessus.
A cause des fluctuations réseaux, des différents parcours empruntés par les paquets et des
variations de la bande passante, les paquets n'
arrivent pas toujours dans le bon ordre. Les
paquets sont donc regroupés et agencés dans le bon ordre dans une mémoire tampon (ou
buffer) créée par le lecteur média de l'
ordinateur de l'
utilisateur. Au bout de quelques secondes,
une fois que le buffer de réception possède assez d'
informations, la lecture du flux commence
et les images ou le son sont retransmis. La mémoire tampon a donc pour rôle de fluidifier le
flux. Si la connexion réseau est mauvaise, l'
arrivé des paquets sera ralentie. Lorsque le buffer
de réception est vide, la lecture s'
arrête et reprendra lorsqu'
elle possèdera assez de données pour
continuer. L'
image est alors figée.

3.Lecture du média
Les différentes opérations permettant la lecture du média sont assurées par le lecteur
multimédia de l’ utilisateur. Tout lecteur est libre (gratuit) et multiplateforme. Il dispose de
plusieurs codecs à sa disposition.
• Démultiplexage
Le conteneur est tout d’ abord démuxé (c’ est le démultiplexage) : les différents flux
audio et vidéo sont séparés et sauvegardés dans des fichiers différents.
• Décompression
Chacun de ces flux sont ensuite décodés (décompressés) en temps réel avec les mêmes
codecs que ceux utilisés pour compresser ces flux. Le lecteur multimédia peut être
amené à devoir télécharger le codec nécessaire (sous forme de plug-in) si celui-ci n’ est
pas présent dans l’ environnement et s’ il est autorisé à le faire (le codec requis peut être
« propriétaire » et donc payant … ). Ces flux sont alors restitués avec le maximum de
qualité possible à l’ utilisateur. Dans la plupart des cas, la compression est asymétrique :
la compression (en fonction de la qualité que l'
on souhaite avoir) sera plus longue et la
décompression assez rapide pour permettre une lecture presque instantanée du flux.
III TECHNOLOGIES UTILISEES POUR LE STREAMING
Les technologies utilisées pour encoder les données en streaming et les lire :
1.Real Networks
• Conteneurs : .rm et .ra, .rma (audio)

• Lecteur (de ces fichiers) : Real Player (téléchargeable gratuitement)
• Site : http://www.real.com/ ou http://www.realnetworks.com/products
• Serveur : Helix Server
• Encodeur : Real Producer (Helix Producer)
• Environnement : multi plateformes. Version de son Player pour les plateformes PC,
MAC et Linux.
• Protocoles supportés : UDP / TCP / HTTP (connexion) - RTP et RTSP

2. Microsoft et Windows Media Player
• Conteneurs : .asf, wmv et .wma (audio)

• Lecteur: Windows Media Player (et VLC Media player ?)
• Site : http://www.microsoft.com/windows/windowsmedia/fr
• Serveur : Windows Media Services
• Encodeur : Windows Media Encoder
• Environnement : version adaptée à la plupart des ordinateurs : PC, MAC, ordinateurs de
poche et Stations de travail, ainsi que sur Pocket Phone.
3. Apple et Quicktime
• Conteneur : .mov, .avi, .mpeg

• Lecteur : Quicktime Player (téléchargeable gratuitement)
• Site : http://www.quicktime.com/
• Serveur : Darwing Streaming Server
• Encodeur : QuickTime Pro
• Environnement : version PC et MAC
4. Format mpeg4
Ce format, normalisé (comme l’ est le MPEG1 ou le MPEG2) et lisible par la plupart
des lecteurs du marché, est en passe de devenir un format majeur. Malheureusement
il n’ est que très peu, pour l’ instant, utilisé dans la pratique sur les sites web. Le seul
encodeur grand public qui permet de réaliser des fichiers Mpeg4 est le Quicktime
Player en version Pro.
• Conteneur : .mp4
• Ce format est lisible par les 3 lecteurs multimédias (Quicktime player, Real One Player
et Windows Média Player)..
• Le plugins « Envivio » doit être ajouté au lecteur pour rendre lisible le fichier. Il est
téléchargeable gratuitement depuis le site : http://www.envivio.com/
• Environnement : multi plateformes

5.Des solutions alternatives
• VideoLAN
(GNU Open source) Logiciel libre, il intègre de très nombreux codecs (il exclue les
codecs "propriétaires", c'
est à dire payants).
o Lecteur : VLC media player (téléchargeable gratuitement)
o Site : http://www.videolan.org/)
• Cisco IP/TV
IV LES PROTOCOLES
La transmission de données en temps réel demande de bons débits réseaux. Il est plus facile de
compenser de la perte de données que de compenser de longs délais dans la réception de
données. Ce type d'
accès est très différent de celui à un simple fichier statique où la chose la
plus importante est que chaque paquet de données arrive à destination.
TCP (Transmission Control Protocol) est un protocole de transport « fiable », orienté

connexion, fournit un flux d'
octets fiable assurant l'
arrivée des données sans altérations et dans
l'
ordre, avec retransmission en cas de perte, et élimination des données dupliquées. Il gère aussi
les données « urgentes » qui doivent être traitées dans le désordre (même si techniquement,
elles ne sont pas émises hors bande). TCP essaie de délivrer toutes les données correctement et
en séquence. C'
est son but et son principal avantage sur UDP, même si ça peut être un
désavantage pour des applications de transfert ou de routage de flux en temps-réel, avec des
taux de perte élevées au niveau de la couche réseau. FTP (transfert de fichiers) et HTTP (web),
protocoles applicatifs, sont basés sur TCP/IP.
UDP (User Datagram Protocol) est un protocole de transport simple, sans connexion,
permettant un débit optimal mais « non fiable » : UDP ne vérifie pas que les paquets sont
arrivés à destination, et ne garantit pas leur arrivée dans l'
ordre. Si une application a besoin de
ces garanties, elle doit les assurer elle-même, ou bien utiliser TCP. UDP est généralement
utilisé par des applications de diffusion multimédia (audio et vidéo, etc.) pour lesquelles le
temps requis par TCP pour gérer les retransmissions et l'
ordonnancement des paquets n'
est pas
disponible.
RTP (Real Time Protocol), est un protocole fonctionnant avec UDP ou TCP, spécialisé dans le
transport de données possédant des contraintes temps réel. Il permet la diffusion de manière
synchrone des flux temps réel transportés mais n'
inclue pas le contrôle de la qualité de la
communication. RTP reconstitue l’ ordre des paquets, synchronise les média, détecte la perte de
paquets.
RTCP est chargé de la partie contrôle du flux de la connexion temps réel avec le client. Il est
souvent adjoint à l'
usage du protocole RTP pour assurer une dynamique face aux problèmes de
congestion éventuelle.
RTSP (Real Time Streaming Protocol) est un protocole de communication spécifique au

streaming. Il permet de contrôler la diffusion du contenu et permet ainsi d’ améliorer les
performances de RTP.
Celui-ci est un « canal de retour » (ou « feedback ») qui peut informer l'
émetteur sur les
propriétés temps-réel du canal, l'
état du tampon du récepteur, ainsi que demander des
changements de compression/débit pour les applications multimédia par exemple. Par
l'
intermédiaire du protocole RTSP, le client est libre d'
arrêter le flux provenant du serveur
(mode pause) ou d'
accéder directement à une partie avancée du média sans avoir à télécharger
la partie passée (mode avance rapide). Il propose également au client la possibilité de négocier
certaines options avec le serveur comme par exemple le type de protocole de transport à utiliser
(UDP ou TCP).
Pour la diffusion en masse cependant (flux en direct, radiodiffusé ou via satellite), cette voie de
retour n'
est généralement pas utilisée, mais le contenu est transmis plusieurs fois en parallèle
avec un décalage temporel suffisant pour pallier les interruptions temporaires de qualité de
réception, mais n'
excédent pas les limites des tampons des récepteurs (normalement pas plus
d'
une quinzaine de secondes d'
écart). Le récepteur peut alors reconstituer et réordonner la
séquence complète afin d'
obtenir un flux continu sans perte.

V Streaming unicast et streaming multicast
Un flux de streaming peut être diffusé de deux façons : individuelle ou multiple.
1. Streaming unicast
(Diffusion individuelle)
Connexion de point à point entre le serveur streaming et l'
utilisateur.
Le client contacte le serveur de streaming grâce au protocole RTSP. En réponse à cette requête,
le serveur retourne via RTSP une description de la session de streaming qu’ il va ouvrir. Une
session de streaming est composée d’ un ou plusieurs flux (stream), par exemple audio ou
vidéo. Le serveur informe le client du nombre de flux. Il donne aussi des informations
décrivant les flux comme le type du média et le codec de compression. Les flux sont quant à
eux diffusés séparément via le protocole RTP.
Cette méthode demande beaucoup de ressources (bande passante), car il faut allouer un flux
unique par utilisateur. Mais elle permet une grande souplesse à l’ utilisateur (celui-ci peut
choisir le débit qui convient à son infrastructure.).
2.Streaming multicast
(Diffusion multiple)
Connexion de point à multipoints entre le serveur et les différents utilisateurs.

Le serveur de vidéo envoie ici une seule copie de chaque flux qui est ensuite distribuée par un
routeur multi diffusion à plusieurs utilisateurs, ce qui permet de réduire considérablement le
trafic lors d’ une diffusion pour de nombreux clients. Cela nécessite l'
utilisation de dispositifs
permettant la distribution en multicast. L'
utilisateur quant à lui ne peut pas piloter le flux
puisqu'
il est partagé avec plusieurs utilisateurs. Le multicast est typiquement utilisé pour la
diffusion en live ou le multi conférence.
Une diffusion multicast est annoncée par un ’ ’ ficher SDP’ ’ (Session Description Protocol) qui
est téléchargé à partir d’ un serveur web classique (Apache, IIS,...). Ce fichier contient les
informations nécessaires pour recevoir le flux multicast, adresse IP du serveur, numéro du port
et les informations de description des flux (même informations que celles envoyées par RTSP
dans le cas d’ une diffusion unicast).

Actuellement, tous les routeurs ne supportent pas le multicast. Afin de permettre aux clients
situés derrière ces routeurs d’ accéder aux données multicast, il est possible d’ installer un
serveur de streaming qui va agir comme une passerelle entre multicast et unicast. Ce serveur est
connecté aux flux multicast et sert aux clients qui se connectent à lui sous la forme de flux
unicast en utilisant RTP et RTSP. Cette opération s’ effectue en temps réel, ce qui permet de
retransmettre aussi bien des vidéos préenregistrées que des images en direct.
VI FORMATS DE FICHIERS, INCRUSTATION EN HTML
1. Streaming URLs et metafiles
On parle de stream lorsqu'

un flux audio/vidéo est lu sur une interface d'
acquisition et non plus
sur un disque. Il n'
y a plus de notion de début et de fin d'
enregistrement, la référence de temps
est le temp-réel. Le media diffusé est celui présent sur l'
interface, moyennant un retard
constant.
La différence fondamentale est qu'

on ne peut, bien entendu plus télécharger le media dans son
intégralité avant de le jouer. Le player doit donc paralléliser la réception des données et leur
restitution. Cette capacité est aussi mise en oeuvre pour jouer des media de longue durée (une
bande annonce, un titre musical) préalablement enregistrés sur disque. On parle alors de lecture
anticipée. On dira aussi qu'
on "stream" un fichier.
Il existe deux manières de "streamer" un fichier. La première est d'

utiliser un streaming Server
IETF, MMS de Microsoft,
qui met en oeuvre un protocole spécifique au temps-réel (RTSP de l'
PNM de RealMedia). La seconde est d'
utiliser un simple serveur HTTP. Dans ce dernier cas,
ne reste du concept de streaming que la lecture anticipée.
Cette substitution d'

un flux temps-réel à un fichier (les Unixiens peuvent penser aux pipes)
appelle un moyen de l'
adresser de façon uniforme: un URL de flux. C'
est le streaming server
qui se charge de faire correspondre un URL soit à un flux temps-réel (direct) soit à un fichier
pré-enregistré (différé):
[protocole]://[hôte]/[chemin de fichier ou d'encodeur]
par exemple:

rtsp://host.media.com/encoder/stream_1
pnm://host.media.com/medialib/fichier_a
mms://host.media.com/medialib/fichier_b
Plutôt que d'

incruster un lien de ce type dans un document HTML, on préfère utiliser une
metafile qui n'
est autre qu'
une référence (pointeur) vers une mediafile. La forme la plus simple
de metafile est un fichier texte contenant un URL de la forme ci-dessus.
extension .ram ou .rpm de RealMedia sont des metafiles qui pointent sur une
Les fichiers d'
extension .ra (audio) ou .rm (audio/vidéo), ces dernières pouvant être streamées ou
mediafile d'
non. De même, un fichier Quicktime (.mov ou .qt) ou movie peut contenir l'
adresse d'
un autre
media. Elle est alors appelée référence movie. La table suivante tente de résumer les types de
media-file et meta-file avec leurs extension de fichier et type MIME pour chaque plate-forme.
Media Meta
Extension Type MIME Commentaire
file file
.ra audio/x-pn-realaudio mediafile (audio)
.rm audio/x-pn-realaudio mediafile (audio & vidéo)
RealPlayer meta-file pour .ra ou .rm

.ram audio/x-pn-realaudio
(helper)
audio/x-pn-realaudio- meta-file pour .ra ou .rm

.rpm
plugin (plugin)
Quicktime .mov .qt vidéo/quicktime format générique binaire
.rtsp .rts application/x-rtsp meta-file ascii
video/avi
.avi .vfw video/x-msvideo mediafile au format AVI
video/msvideo

.mpeg,
.mpg,
.mpa, video/mpeg,
.mpm, video/x-mpeg,
mediafile au format MPEG
.mpv, .m1s, audio/mpeg,
.m1v,.m1a, audio/xmpeg
.m64,.m75,
.m15,.mp2,
.wma video/x-ms-asf mediafile (audio)
.wmv video/x-ms-asf mediafile (audio & video)
mediafile (audio & video,

.asf video/x-ms-asf
MediaPlayer 3rd party codecs)
.wax video/x-ms-asf metafile pour .wma
.wvx video/x-ms-asf metafile pour .wmv
.asx video/x-ms-asf metafile pour .asf
1.1 Avantage des meta-files
L'
intérêt d'
utiliser une meta-file au lieu d'
un lien direct sur le stream est de se ramener dans
l'
espace HTTP.
En effet, la meta-file est toujours accédée via HTTP alors que le stream l'
est via un protocole
temps-réel, souvent inconnu du navigateur, comme le montrent les exemples suivants:

a. Exemples 1: URL sur un stream
RealAudio
Ce lien pointe sur un stream RealAudio:

pnm://son.radio-france.fr/chaines/france-info/flash/flash16.ra
Quicktime
Ce lien pointe sur un stream Quicktime:

rtsp://a549.q.kamai.net/3/549/191/.../qarnorthanchor_300.mov
b. Exemples 2: URL sur une meta-file
RealAudio (.ram)
Ce lien pointe sur un fichier .ram qui contient le texte suivant:

RealAudio (.rpm)
Celui-ci pointe sur un fichier .rpm qui contient le texte suivant (voir Note 1):
Quicktime (.mov)
Ce lien pointe sur un fichier .mov qui contient le texte suivant:

rtsp://a549.q.kamai.net/3/549/191/.../qarnorthanchor_300.mov
1.2 Que se passe-t-il lorsqu'on clique sur l'URL d'un stream?
Votre navigateur cherche un binding de protocole dans le système pour traiter les protocoles
PNM ou RTSP.
Il ne le trouve pas parce que ce binding n'

a pas été créé.
Vous pouvez le créer en allant dans vos Préférences ou Propriétés Internet, section «Helpers»,
«Utilitaires» ou «Protocoles», créez une nouvelle association pour le protocole PNM ou RTSP

et sélectionnez l'
application RealPlayer ou QuicktimePlayer respectivement (exemple
MacOS9). Cliquez à nouveau sur le lien: l'
application externe démarre.
Un lien direct sur un stream dépend de la bonne configuration des bindings

protocole/application sur lesquels on ne peut pas se reposer.
1.3 Que se passe-t-il lorsqu'on clique sur l'URL d'une meta-file?
abord un binding de type dans ses plugins.

Votre navigateur cherche d'
RealAudio a installé le binding .rpm audio/x-pn-realaudio-plugin => RealAudio

plugin.
QuickTime a installé le binding .mov video/quicktime => QuickTime plugin.
Dans les exemples 2.2 et 2.3, le stream est pris en charge par le plugin.
Votre navigateur cherche ensuite un binding de type dans le système.
RealAudio a installé le binding .ram audio/x-pn-realaudio => RealAudio player

Dans l'
exemple 2.1, le stream est pris en charge par l'
application externe.
Un lien indirect, via une metafile, sur un stream dépend de la bonne configuration des bindings
type/application du système et du navigateur, en général fiables.
Note 1: Dans l'

exemple 2.2, le résultat graphique est inapproprié car le plugin n'
a pas reçu de
paramètres. Pour cela, il faut utiliser EMBED ou OBJECT, ce que fait cette page.
Note 2: QuickTime ne définit pas de type MIME pour activer l'

application externe, ceci passe
par un argument le plugin. Pour cela, il faut utiliser EMBED ou OBJECT, ce que nous allons
aborder.
2. Incrustation par <EMBED> ou <OBJECT>
La directive <EMBED> (dépréciée) ou <OBJECT> permet, à volonté, soit d'

incruster le lecteur
dans le document graphique, soit de diriger le stream vers le lecteur externe.
Ce choix est affaire de goût, cependant nous pensons que le lecteur externe est en général une
solution plus sûre parce qu'
il s'
exécute dans sa propre partition mémoire et ne risque pas

d'
entraîner le navigateur dans une erreur de programme. Ceci n'
étant pas un cours de HTML,
nous nous contenterons de diriger vers les documentations des constructeurs:
Embedding QuickTime for Web Delivery:

http://docs.info.apple.com/article.html?artnum=61011
RealAudio Web Page Embedding:
http://service.real.com/help/library/guides/productionguidepreview/HTML/htmfiles/embed.htm
Ce qui nous intéresse ici sont le respect des standards et l'

inter-opérabilité.
La directive <EMBED> est une extension Netscape et n'

a jamais fait partie de la DTD HTML.
<OBJECT> doit la remplacer. A la différence de <EMBED>, pour laquelle </EMBED> est
superflu, <OBJECT> est un crochet et doit être fermée par </OBJECT>.
Voici un code inapproprié mais universellement rencontré:
<EMBED SRC="play_now.mov"
WIDTH="70" HEIGHT="20"
CONTROLLER="false"
AUTOPLAY="false"
CACHE="false">
LOOP="false"
</EMBED>
Voici un code correct équivalent:
<OBJECT DATA="play_now.mov"
WIDTH="70" HEIGHT="20">
<PARAM name="CONTROLLER" value="false">
<PARAM name="AUTOPLAY" value="false">
<PARAM name="CACHE" value="false">
<PARAM name="LOOP" value="false">
</OBJECT>
Ceci est-il compris par tout navigateur sur tout plate-forme? Non.

À notre connaissance, ceci est à la fois conforme aux recommandations du W3C et accepté par
les navigateurs supportant l'
architecture de plug-ins introduite par Netscape. C'
est-à-dire
quasiment tous, sauf Windows Internet Explorer 5.5 SP2 and 6.0 et au-delà (voir
http://developer.apple.com/quicktime/compatibility.html).
En effet, Windows Internet Explorer ne supportera plus les plugins. Mais il existe un contrôle
ActiveX QuickTime fourni par Apple. Pour charger ce contrôle ActiveX, il faut inclure le
<OBJECT> du plugin (pour les autres navigateurs) à l'
intérieur d'
un <OBJECT> ActiveX (pour
Windows Explorer 5.5 et au-delà).
<OBJECT CLASSID="clsid:02BF25D5-8C17-4B23-BC80-D3488ABDDC6B"
CODEBASE="http://www.apple.com/qtactivex/qtplugin.cab"
<PARAM name="SRC" value="play_now.mov">
<OBJECT DATA="play_now.mov"
</OBJECT>
</OBJECT>
Remarque: Ce code provoque le chargement automatique du contrôle ActiveX mais ne

dispense pas de l'
installation par l'
utilisateur de Quicktime for Windows.
En principe, le code ci-dessus est universel vis-à-vis du système et du navigateur.
Il nous reste à le finaliser pour choisir l'

ouverture dans le player externe ou dans le plugin. Pour
cela, nous ajoutons:
<PARAM name="HREF" value="fishcam.mov">

<PARAM name="TARGET" value="QuickTimePlayer">

ce qui, en nous référant à la documentation Quicktime, ouvre notre movie dans l'
application
externe QuickTimePlayer; ou bien:
<PARAM name="HREF" value="fishcam_window.html">

<PARAM name="TARGET" value="_blank">
ce qui instruit le plugin d'

ouvrir un fichier HTML dans une nouvelle fenêtre du navigateur,
fichier HTML qui à son tour incrustera notre movie (étape superflue, un simple lien sur ce
fichier HTML aurait suffit, mais nous avons voulu rapprocher les deux appels au plugin dans le
même document en profitant de l'
universalité de l'
argument HREF).
VII QUELQUES REALISATIONS

1. RTN web-radio
Nous avons choisi de faire la configuration dans deux systèmes différents. En effet, nous
avons configuré le serveur de diffusion (SHOUTCAST) sur une machine linux (FEDORA
CORE 3) et le seurveur d’ encodage sur une machine Windows (Windows XP).
Etape 1 : Installation de Shoutcast sur Linux
SHOUTcast, de Nullsoft, est un système de diffusion d’ audio en continu ("le Streaming") pour
les plates-formes Windows et Unix. Il permet à quiconque dispose d'
un logiciel audio comme
Winamp et d’ une connexion Internet, de diffuser du son de façon continue sur le Net.
Tout d'
abord, il va nous falloir le télécharger. La version qui nous intéresse dans ce cas est :
SHOUTcast Linux server (glibc) v1.9.5. Pour cela récupérons le fichier shoutcast-1-9-5-linux-
glibc6.tar.gz par un wget par exemple :
Puis, faisons un tar -xvzf pour le décompresser

Ensuite, un petit "cd shoutcast-1-9-5-linux-glibc6" pour aller dans le répertoire nouvellement

décompressé. Un "ls" nous montre que le répertoire contient uniquement trois fichiers : un
readme.txt, le fichier de config sc_serv.conf, et l'
exécutable sc_serv déjà compilé.
Etape 2 : Configuration de Shoutcast Linux / sc_serv.conf
Ouvrons le fichier de configuration shoutcast sc_serv.conf qui est assez bien documenté mais il
faut comprendre l'
anglais. Ci-dessous nous avons fait une petite traduction des paramètres qui
sont indispensables à configurer dans ce fichier. Tout le reste n'
est que des paramètres
optionnels.
; ------- DEBUT FICHIER SC_SERV.CONF ------

; SHOUTcast Distributed Network Audio Server configuration file
; Copyright (C) 1998-2004 Nullsoft, Inc.
; All Rights Reserved.
; Last modified Mar 17 2004
; traduction par Damien Desrousseaux
; Si vous voulez gérer plusieurs fichiers de config, copiez

juste
; ce fichier sous un autre nom, et lancez sc_serv avec ce nom
; exemple :
; ./sc_serv sc_leet.conf
; ***************************
; Configuration obligatoire
; ***************************
; MaxUser. Le nombre maximum d'auditeurs autorisés

simultanément.
; Mettez une valeur raisonnable par rapport à votre bande
passante (si
; vous avez 256kbps en upload, et voulez broadcaster en 24kbps,
vous
; choisirez 256kbps/24kbps=10 auditeurs maximum.) Mettre une
plus haute
; valeur ruinerait votre RAM et le stream deviendrait inaudible
quand plus
; d'auditeurs que le seuil se connecteront.
MaxUser=32
; Password. SHOUTcast ne demande jamais de mot de passe à un

auditeur,
; le mot de passe est requis pour diffuser au serveur, et pour
; administrer le serveur via l'interface web. Ce mot de passe
ne doit comporter
; que des chiffres et lettres, et c'est le même mot de passe

dont vous aurez besoin

; pour utiliser le Plug-in SHOUTcast Source pour Winamp. CETTE
VALEUR
; NE PEUT PAS ETRE VIDE.
Password=passer
; PortBase. C'est le numéro du port sur lequel sera votre

serveur. Cette
; valeur, et cette valeur+1 doivent être disponibles. Si vous
avez une erreur
; quand le serveur DNAS lance un socket au démarrage, vérifiez
que rien d'autre
; ne tourne sur le même port sur votre machine (telnet
localhost portnumber -- si vous
; avez une connexion refusée alors c'est bon ce port n'est pas
utilisé). Ports < 1024
; peuvent demander d'être en root sur les *nix machines. Le
port par défaut est 8000.
PortBase=8000
; ------- FIN FICHIER SC_SERV.CONF ------
Une fois que nous avons bien rempli notre fichier de configuration, sauvegardons et fermons le.
Il ne nous restera plus alors qu'
à lancer le serveur Shoutcast avec la commande : "./sc_serv", et
voilà le serveur est en écoute et fonctionne :
NB : Lançons le avec "./sc_serv &" pour qu'

il tourne en fond et laisse notre invite de
commandes tranquille.

Maintenant allons dessus avec notre navigateur Internet sur le port que nous lui avons indiqué.
Ceci montre que tout fonctionne bien:
Voilà, nous venons de mettre en place un serveur radio Shoutcast sous Linux très simplement.
A présent il nous restera plus qu'
à diffuser avec le Plug-in winamp
Étape 3 :configuration winamp et shoutcast-dsp
Nous allons configurer Winamp : afin que le plugin shoutcast-dsp-1-9-0-windows.exe

fonctionne. La première chose à faire c’ est d’ installer "Winamp".
Après avoir téléchargé winamp535_full_emusic-7plus.exe, lançons son programme

d’ installation en double cliquant dessus

Après avoir accepté les termes de la licence, et cliqué sur "I Agree", on se laisse guider par
l'
installation. Une fois notre installation terminée, lançons Winamp.
Voici l’ interface obtenue :
Maintenant, allons au menu "Options" puis "Préférences..." comme ceci

Ou simplement, un "Ctrl+P" avec les raccourcis clavier. Dans les deux cas, on arrivera à cette
fenêtre :
On remarquera alors qu' y a pas de plug-in dans la partie "Effets/ DSP". On va y remédier
il n'
en installant celui-ci. Téléchargeons le : "shoutcast-dsp-1-9-0-windows.exe". On va le lancer
en double-cliquant dessus. On obtiendra ceci à la fin de l'
installation :

A présent, dans "Effets/ DSP" on remarquera qu'

il y a "Nullsoft SHOUTcast Source DSP
v1.9.0 [dsp_sc.dll]", nous allons cliquer dessus :
Et une fois que nous cliquons dessus, nous avons ceci qui apparaît

Il ne nous reste plus qu'

à passer à la configuration de "SHOUTcast".
Étape 4 :la configuration de SHOUTcast :
Cette configuration est pour une connexion avec le serveur SHOUTcast d’ adresse www.rtn.sn
Nous avons ici quatre onglets à voir :
Main : pour l’ instant il ne devrait rien se passer dans cette fenêtre car la connexion avec le
serveur Shoutcast n’ est pas encore établie.
Output : sélectionnons “Output 1 . Le paramètre “ Connect at startup” permet la connexion

automatique avec le serveur dès le lancement de winamp.
Sous Output configuration : mettons l’ adresse IP ou le nom et le port que le serveur Shoutcast
va utiliser (le port 8000 est celui par défaut mais nous, nous avons utilisé le port 8001). Il nous
faut ensuite mettre le mot de passe du serveur shoutcast.
Le paramètre "Automatic Reconnection on Connection Failure" permet de lancer une

tentative de reconnexion automatique en cas de perte de connexion.

Encoder :
!" # $% &

Input : c’ est la source du flux, mettons “ Winamp” dans « Input Device ». Avec le choix de
« Soundcard Input », tout ce qui est sur la carte son est encodé et envoyé pour être diffusé.
' % (

On peut cocher la case " ", comme ça il se mettra en route tout seul.
On peut maintenant y accéder par l’ url suivante :
http://www.rtn.sn:8001/listen.pls
2. RTN Web-Tv et RTN vidéosurveillance
Historiquement, le premier sur le marché du streaming vidéo a été Realnetworks. C'

est pour
cette raison principale que nous utilisons aujourd'
hui un de leur serveur. L'
autre raison
principale, qui explique en partie pourquoi nous l'
utilisons encore, est que c'
est le seul système
de Vidéo Streaming a être vraiment Multiplateformes. Puis viennent d'
autres avantages comme
la possibilité d'
utiliser le langage SMIL pour diffuser des objets Multimédias synchronisés, de
diffuser n'
importe quel format ou presque (Real, Quicktime, Windows Media, etc.) et d'
être
sensiblement plus performant, plus souple, plus ouvert, bref plus complet.
Le Serveur de diffusion
• Téléchargement Real Helix Server:
Le téléchargement de Real Helix Server peut se faire sur le site officiel de Realnetworks
http://www.realnetworks.com/
D’ après les informations que nous avons renseigné sur le site, Realnetworks nous a
envoyé par mail une clé de licence requise pour l’ installation du logiciel et une url pour
le téléchargement du logiciel.
Au cours de l’ installation, il nous sera demandé de renseigner le chemin complet du

fichier contenant la clé de licence.
Installation:
Rendons exécutable le fichier téléchargé :
chmod +x rs-8-01-linux-libc6.bin
#Ensuite, exécutons le:
./rs-8-01-linux-libc6.bin
Nous avons choisi comme répertoire d’ installation /usr/local/real/ mais rien ne nous empêcher
de choisir un autre comme /opt/real/
Console d’ installation:
-----------------------------------------------------------
Extracting files for RealNetworks installation......
Welcome to the RealServer Setup for UNIX
Setup will help you get RealServer running on your computer.
Setup will step you through the installation process by displaying

informational screens. Please follow the navigational controls
below:
Key Behavior
=== ========
N Next
P Previous
X Exit
F Finish (Express Installation)
Each input requires the execution of the key above

followed by the [ENTER] key. Enter [N]ext to continue:

-----------------------------------------------------------
If a RealServer license key file has been sent to you,
please enter its directory path below. If you have not
received a RealServer license key file, then this server
WILL NOT OPERATE until a license key file is placed in
the server's License directory. Please obtain a free
Basic RealServer license or purchase a commercial license
from our website at http://www.real.com/. If you need
further assistance, please visit our on-line support area
at http://service.real.com/, or contact our RealServer
technical support team at (206) 674-2681.
License Key File:
/usr/local/real/5259-12-13-010XXXXXXXXXXXX.lic
-----------------------------------------------------------
Installation and use of RealServer requires
acceptance of the following terms and conditions:
Press [Enter] to display the license text...
-----------------------------------------------------------
Choose "Accept" to accept the terms of this
license agreement and continue with RealServer setup.
If you do not accept these terms, enter "No"
and installation of RealServer will be cancelled.
(Default: Accept):
-----------------------------------------------------------
Enter the complete path to the directory where you want
RealServer 8.0 to be installed. You must specify the full
pathname of the directory and have write privileges to
the chosen directory [/usr/local/real]:
-----------------------------------------------------------
Please enter a username and password that you will use
to access the web-based RealSystem Administrator, the
RealSystem monitors, and RealSystem live encoders:
Username:
------------------------------------------------------------
Please enter a port on which RealServer will listen for
PNA connections. These connections have URLs that begin
with "pnm://": (Default: 7070)
-----------------------------------------------------------


RTSP connections. These connections have URLs that begin
with "rtsp://": (Default: 554)
-----------------------------------------------------------
HTTP connections. These connections have URLs that begin
with "http://": (Default: 8080)
-----------------------------------------------------------
RealServer will listen for RealSystem Administrator
requests on the port shown. This port has been
initialized to a random value for security. Please
verify now that this pre-assigned port will not interfere
with ports already in use on your system; you can
change it if necessary. (Default: XXX2X)
------------------------------------------------------------
You have selected the following RealServer configuration:
Admin Username: admin

Admin Password: passer
Monitor Password: passermonitor
Encoder Username: realEncoder
Encoder Password: passerencoder
PNA Port: 7070
RTSP Port: 554
HTTP Port: 8004
Admin Port: XXX2X
Enter [F]inish to begin copying files, or [P]revious

to go back to the previous prompts:
RealServer installation is complete.

-----------------------------------------------------------
The RealSystem Administrator allows you to configure
and maintain RealServer through an intuitive
web-based interface. Please note that RealServer
must be running in order to use the Administrator.
Would you like to start RealServer now and launch
the RealSystem Administrator? (Default: Yes) NO
-----------------------------------------------------------
If at any time you should require technical

assistance, please visit our on-line support area

at http://service.real.com/, or contact our RealServer
technical support team at (206) 674-2681.
Starting RealServer...
Please Wait...
Sending RealSystem Administrator URL to browser...
On peut maintenant démarrer et administrer le système.
Démarrer le Serveur:
Il faut tout d’ abord se déplacer vers le répertoire d’ installation :
cd /usr/local/REAL
#Ensuite, démarrer le serveur :
Bin/rmserver --ignore-etc-hosts-problems rmserver.cfg -m64 &
Administration du Serveur:
On peut administrer notre serveur en tapant sur un navigateur l’ url suivante :
http://www.rtn.sn:18591/admin/index.html
Et mettre après le le nom d’ utilisateur et le mot de passe de l’ administrateur
18591 est la valeur du paramètre "AdminPortNumber" (numéro du port

d’ administration) qui est pris de manière arbitraire au cours de l’ installation (pour des
raisons de sécurité, il est changé à chaque installation). Ce paramètre est renseigné au
niveau du fichier de configuration /usr/local/REAL/rmserver.cfg sous cette forme.
<Var AdminPort="XXXXX"/>
où XXXXX est le le numéro du port d’ administration.
On peut l’ avoir par la commande suivante:

grep AdminPort /usr/local/REAL/rmserver.cfg
L’encodeur:
Le logiciel d’ encodage utilisé est Real Producer de RealNetworks. Nous l’ avons installé sur
une machine Windows XP.
Téléchargement et installation :
Le logiciel Real Producer peut être téléchargé gratuitement sur le site officiel de RealNetworks.
http://www.realnetworks.com/
Pour l’ installation, après avoir accepté les termes du contrat on se laisse guider par l’ assistant.
Configuration :
Après avoir installé Real Producer, lançons le :

Cochons la cage Devices et sélectionnons nos périphériques multimédias (Vidéo et Audio) :

• Pour la télévision :
Sélectionnons le périphérique correspondant à notre carte télé.
• Pour la vidéoconférences :
Sélectionnons le périphérique correspondant à notre carte webcam.

Maintenant, cliquons sur le lien d’ édition symbolisé par le crayon et renseignons quelques
champs pour la configuration et la personnalisation de notre stream.
Destination name : le nom sous lequel apparaît notre encodeur.

Stream name : le nom de notre fichier en stream

Broadcast method : méthode de diffusion utilisé.

Server address : l’ adresse ip de notre serveur de diffusion.
Path : chemin menant vers le répertoire sur lequel est installé le serveur (mais c’ est optionnel)
Port : port utilisé pour la connexion avec le serveur de diffusion.
Transport : protocole de transport utilisé (TCP :mode connecté ; UDP :mode non connecté)
Username : nom d’ utilisateur de l’ administrateur du serveur de diffusion.
Password : mot de passe de l’ administrateur du serveur de diffusion.
Cliquons maintenant sur « ok » et attendons que l’ état (status) de l’ encodeur soit prêt (ready)
pour cliquer ensuite sur « encoder ».
L’ état « broadcasting » va montrer que la diffusion a commencé.

Note : évidemment il y aura un léger décalage entre ce qui est directement lu sur le
périphérique (image à gauche) et ce qui est encodé et transmis (image à droite).
Résultat pour la télévision :

Résultat pour la vidéosurveillance :

A présent, notre serveur est en train de faire du broadcasting. En d’ autres termes, notre serveur
est en train de faire de la diffusion.
On peut maintenant y accéder par les urls suivantes :
Pour la télévision : http://www.rtn.sn:8004/ramgen/broadcast/baba.rm
Pour la vidéosurveillance : http://www.rtn.sn:8004/ramgen/broadcast/laye.rm

CONCLUSION
FINALISATION DU PROJET
Au terme des études menés sur les technologies du Wap et du Streaming nous avons eu à
intégrer ces deux techniques pour offrir à RTN une vidéo surveillance sur mobile.
Evidement les terminaux qui profiterons de cette technique devront être de troisième
génération c'
est-à-dire intégrant la vidéo.
Etant donné que l’ UMTS propose des débits allant jusqu’ à 2Mbits/s, ce serait idéal de l’ utiliser
comme support mais n’ empêche que le GPRS demeure une alternative.
PERSPECTIVES
Au Sénégal les services à valeur ajoutée connaissent actuellement un succès étonnant avec
l’ envoi de SMS surtaxés. Nous savons maintenant qu’ avec le logiciel Open Source Kannel, la
mise en place de ce type de services est chose facile.
Mais puisque les mobiles de troisième génération offrent la capacité d’ envoyer, en plus du
simples SMS texte, des contenus images, audio et vidéo, on peut envisager de réaliser un autre
type de SVA : le MMS.
Il existe un logiciel Open Source du nom de Mbunni qui permet de mettre en place cela.

Langue

Memoire Laye Baba

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Memoire Laye Baba

Transféré par

Droits d'auteur :

Formats disponibles

Mise en place de Services à Valeur Ajoutée et d’un serveur de Streaming

Table des matières

PARTIE I : Les Services à Valeur Ajoutée

I LES RESEAUX MOBILES ………………………………………………………………12

II LES SERVICES A VALEUR AJOUTEE ……………………………………………...25

MISE EN PLACE DE SERVICES A VALEUR AJOUTEE ……………………………..44

PARTIE 2 : La Technologie du Streaming

I. LES DEUX METHODES DE STREAMING……………………………………………63

II. LES DIFFERENTES ETAPES DU STREAMING …………………………………….64

III TECHNOLOGIES UTILISEES POUR LE STREAMING …………………………..67

Abdoulaye Ly & Baba Ngom - 1- DUT 2 TELECOMS

3. Apple et Quicktime …………………………………………………………………68

IV. LES PROTOCOLES …………………………………………………………………….69

V. STREAMING UNICAST ET STREAMING MULTICAST …………………………..71

VI FORMATS DE FICHIERS, INCRUSTATION EN HTML …………………………..72

VII QUELQUES REALISATIONS ………………………………………………………...79

Abdoulaye Ly & Baba Ngom - 2- DUT 2 TELECOMS

Abdoulaye Ly & Baba Ngom - 3- DUT 2 TELECOMS

Mes parents que je ne saurais remercier assez.

Mes frères et sœurs

Ainsi qu’à tous les membres de ma famille

Et Toute l’équipe de la RTN

Abdoulaye Ly & Baba Ngom - 4- DUT 2 TELECOMS

Mes parents en guise de remerciements pour leur dévouement à mon

éducation et surtout aux sacrifices consentis pour la bonne marche de mes

Mes frères et sœurs

Toute ma famille du sens restreint au sens large

Tous mes amis

Et toute l’équipe de la RTN

Abdoulaye Ly & Baba Ngom - 5- DUT 2 TELECOMS

Abdoulaye Ly & Baba Ngom - 6- DUT 2 TELECOMS

Abdoulaye Ly & Baba Ngom - 7- DUT 2 TELECOMS

Abdoulaye Ly & Baba Ngom - 8- DUT 2 TELECOMS

Abdoulaye Ly & Baba Ngom - 9- DUT 2 TELECOMS

A l’ère des Nouvelles Technologies de l’Information et de la Communication, de toutes les

Abdoulaye Ly & Baba Ngom - 10- DUT 2 TELECOMS

LES SERVICES A VALEUR AJOUTEE

Abdoulaye Ly & Baba Ngom - 11- DUT 2 TELECOMS

I. LES RESEAUX MOBILES

Architecture réseau GSM

Abdoulaye Ly & Baba Ngom - 12- DUT 2 TELECOMS

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

· Le sous système radio

- BSS Base Station Sub-system assure et gère les transmissions radios

· Le sous système d'acheminement

· Le sous-système d'exploitation et de maintenance

- OSS Operation Sub-System) qui permet à l'

La mise en place d'

La mise en place d’un réseau GSM représente un investissement considérable.

Abdoulaye Ly & Baba Ngom - 13- DUT 2 TELECOMS

ville et 10 km de zone en campagne. Cela donne un aperçu du coût et du temps nécessaires

Ci dessus un rappel de l’architecture GSM, en encadré bleu les éléments de couverture, en

Architecture réseau GSM + GPRS

Abdoulaye Ly & Baba Ngom - 14- DUT 2 TELECOMS

Une troisième entité

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

La mise en place d'

Le service GPRS permet de considérer le réseau GSM comme un réseau à transmission de

La transmission par paquet sur la voie radio permet d'

Le mise en place d'

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

Abdoulaye Ly & Baba Ngom - 15- DUT 2 TELECOMS