memoire laye baba

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

Abdoulaye Ly & Baba Ngom - 1- DUT 2 TELECOMS

Table des matières

PARTIE I : LLeess SSeerrvviicceess àà VVaalleeuurr AAjjoouuttééee 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 : LLaa TTeecchhnnoollooggiiee dduu SSttrreeaammiinngg

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



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



SSOOMMMMAAIIRREE

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 :

LLEESS SSEERRVVIICCEESS AA VVAALLEEUURR AAJJOOUUTTEEEE



II.. LLEESS RREESSEEAAUUXX MMOOBBIILLEESS 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.

11.. PPrréésseennttaattiioonn

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

paquets, et l'UMTS vient compléter ces deux réseaux par une offre de services Voix et Data

complémentaires sur un mode paquet.

L'UMTS est ainsi une extension du GPRS et fonctionne également en mode paquet. La vitesse

de transmission offerte par les réseaux UMTS atteint 2 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é



22..LLeess ééqquuiippeemmeennttss tteerrmmiinnaauuxx

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.



33.. LLEESS CCoommmmaannddeess AATT

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



IIII.. LLEESS SSEERRVVIICCEESS AA VVAALLEEUURR AAJJOOUUTTEEEE

11.. DDééffiinniittiioonn

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.

22.. LLaa RRéégglleemmeennttaattiioonn 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.



33.. LLEE SSEERRVVIICCEE SSMMSS MMOOBBIILLEE

PPrréésseennttaattiioonn

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



44.. LLEE WWAAPP

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



IIIIII MMIISSEE EENN PPLLAACCEE DDEE SSEERRVVIICCEESS AA VVAALLEEUURR AAJJOOUUTTEEEE

11.. EEttuuddee dduu llooggiicciieell KKAANNNNEELL

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.

11..11.. AArrcchhiitteeccttuurree ddee KKaannnneell

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

11..22.. KKAANNNNEELL PPaasssseerreellllee SSMMSS

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.

11..33.. KKAANNNNEELL PPaasssseerreellllee WWaapp

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.

11..44.. KKaannnneell eett ssééccuurriittéé 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.

22.. IInnssttaallllaattiioonnss eett ccoonnffiigguurraattiioonnss

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

33.. MMiissee eenn ppllaaccee ddee sseerrvviiccee SSMMSS 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.

44.. MMiissee eenn ppllaaccee ddee sseerrvviiccee WWAAPP



� 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="[email protected]"> <address address-value="WAPPUSH=+2214870830/[email protected]"/> </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 :

<?xml version="1.0"?> <!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 :

<?xml version="1.0"?>

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

LLAA TTEECCHHNNOOLLOOGGIIEE DDUU SSTTRREEAAMMIINNGG



II.. LLEESS DDEEUUXX MMEETTHHOODDEESS DDEE SSTTRREEAAMMIINNGG

11.. SSttrreeaammiinngg ssttaattiiqquuee ((oouu ppsseeuuddoo--ssttrreeaammiinngg))

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

22.. SSttrreeaammiinngg ddyynnaammiiqquuee ((oouu «« vvrraaii »» ssttrreeaammiinngg))

• 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 LLEESS DDIIFFFFEERREENNTTEESS EETTAAPPEESS DDUU SSTTRREEAAMMIINNGG

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 :

11.. EEnnccooddaaggee

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.

22.. DDiiffffuussiioonn ddeess ddoonnnnééeess ssuurr llee rréésseeaauu -- BBuuffffeerriinngg

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.



33..LLeeccttuurree dduu mmééddiiaa

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.

IIIIII TTEECCHHNNOOLLOOGGIIEESS UUTTIILLIISSEEEESS PPOOUURR LLEE SSTTRREEAAMMIINNGG

Les technologies utilisées pour encoder les données en streaming et les lire :

11..RReeaall NNeettwwoorrkkss

• 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



22.. MMiiccrroossoofftt eett WWiinnddoowwss MMeeddiiaa PPllaayyeerr

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


33.. AAppppllee eett QQuuiicckkttiimmee

• 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


44.. FFoorrmmaatt mmppeegg44

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



55..DDeess ssoolluuttiioonnss aalltteerrnnaattiivveess

• 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

IIVV LLEESS PPRROOTTOOCCOOLLEESS

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.



VV SSttrreeaammiinngg uunniiccaasstt eett ssttrreeaammiinngg mmuullttiiccaasstt

Un flux de streaming peut être diffusé de deux façons : individuelle ou multiple.

11.. SSttrreeaammiinngg uunniiccaasstt

(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.).

22..SSttrreeaammiinngg mmuullttiiccaasstt

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

VVII FFOORRMMAATTSS DDEE FFIICCHHIIEERRSS,, IINNCCRRUUSSTTAATTIIOONN EENN HHTTMMLL

11.. SSttrreeaammiinngg UURRLLss eett mmeettaaffiilleess

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

qui met en oeuvre un protocole spécifique au temps-réel (RTSP de l'IETF, MMS de Microsoft,

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.

Les fichiers d'extension .ram ou .rpm de RealMedia sont des metafiles qui pointent sur une

mediafile d'extension .ra (audio) ou .rm (audio/vidéo), ces dernières pouvant être streamées ou

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.

Extension Type MIME Media

file

Meta

file Commentaire

.ra audio/x-pn-realaudio � mediafile (audio)

.rm audio/x-pn-realaudio � mediafile (audio & vidéo)

.ram audio/x-pn-realaudio � meta-file pour .ra ou .rm

(helper)

RealPlayer

.rpm audio/x-pn-realaudio-

plugin �

meta-file pour .ra ou .rm

(plugin)

.mov .qt vidéo/quicktime � � format générique binaire

.rtsp .rts application/x-rtsp � meta-file ascii

Quicktime

.avi .vfw

video/avi

video/x-msvideo

video/msvideo

� mediafile au format AVI



.mpeg,

.mpg,

.mpa,

.mpm,

.mpv, .m1s,

.m1v,.m1a,

.m64,.m75,

.m15,.mp2,

video/mpeg,

video/x-mpeg,

audio/mpeg,

audio/xmpeg

� mediafile au format MPEG

.wma video/x-ms-asf � mediafile (audio)

.wmv video/x-ms-asf � mediafile (audio & video)

.asf video/x-ms-asf � mediafile (audio & video,

3rd party codecs)

.wax video/x-ms-asf � metafile pour .wma

.wvx video/x-ms-asf � metafile pour .wmv

MediaPlayer

.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

11..22 QQuuee ssee ppaassssee--tt--iill lloorrssqquu''oonn cclliiqquuee ssuurr ll''UURRLL dd''uunn ssttrreeaamm??

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.

11..33 QQuuee ssee ppaassssee--tt--iill lloorrssqquu''oonn cclliiqquuee ssuurr ll''UURRLL dd''uunnee mmeettaa--ffiillee??

Votre navigateur cherche d'abord un binding de type dans ses plugins.

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.

22.. IInnccrruussttaattiioonn ppaarr <<EEMMBBEEDD>> oouu <<OOBBJJEECCTT>>

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

VVIIII QQUUEELLQQUUEESS RREEAALLIISSAATTIIOONNSS

11.. RRTTNN wweebb--rraaddiioo

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'il n'y a pas de plug-in dans la partie "Effets/ DSP". On va y remédier

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

22.. RRTTNN WWeebb--TTvv eett RRTTNN vviiddééoossuurrvveeiillllaannccee

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



CCOONNCCLLUUSSIIOONN

�� FFIINNAALLIISSAATTIIOONN DDUU PPRROOJJEETT

AAuu tteerrmmee ddeess ééttuuddeess mmeennééss ssuurr lleess tteecchhnnoollooggiieess dduu WWaapp eett dduu SSttrreeaammiinngg nnoouuss aavvoonnss eeuu àà

iinnttééggrreerr cceess ddeeuuxx tteecchhnniiqquueess ppoouurr ooffffrriirr àà RRTTNN uunnee vviiddééoo ssuurrvveeiillllaannccee ssuurr mmoobbiillee..

EEvviiddeemmeenntt lleess tteerrmmiinnaauuxx qquuii pprrooffiitteerroonnss ddee cceettttee tteecchhnniiqquuee ddeevvrroonntt êêttrree ddee ttrrooiissiièèmmee

ggéénnéérraattiioonn cc''eesstt--àà--ddiirree iinnttééggrraanntt llaa vviiddééoo..

EEttaanntt ddoonnnnéé qquuee ll’’ UUMMTTSS pprrooppoossee ddeess ddéébbiittss aallllaanntt jjuussqquu’’ àà 22MMbbiittss//ss,, ccee sseerraaiitt iiddééaall ddee ll’’ uuttiilliisseerr

ccoommmmee ssuuppppoorrtt mmaaiiss nn’’ eemmppêêcchhee qquuee llee GGPPRRSS ddeemmeeuurree uunnee aalltteerrnnaattiivvee..

�� PPEERRSSPPEECCTTIIVVEESS AAuu SSéénnééggaall lleess sseerrvviicceess àà vvaalleeuurr aajjoouuttééee ccoonnnnaaiisssseenntt aaccttuueelllleemmeenntt uunn ssuuccccèèss ééttoonnnnaanntt aavveecc

ll’’ eennvvooii ddee SSMMSS ssuurrttaaxxééss.. NNoouuss ssaavvoonnss mmaaiinntteennaanntt qquu’’ aavveecc llee llooggiicciieell OOppeenn SSoouurrccee KKaannnneell,, llaa

mmiissee eenn ppllaaccee ddee ccee ttyyppee ddee sseerrvviicceess eesstt cchhoossee ffaacciillee..

MMaaiiss ppuuiissqquuee lleess mmoobbiilleess ddee ttrrooiissiièèmmee ggéénnéérraattiioonn ooffffrreenntt llaa ccaappaacciittéé dd’’ eennvvooyyeerr,, eenn pplluuss dduu

ssiimmpplleess SSMMSS tteexxttee,, ddeess ccoonntteennuuss iimmaaggeess,, aauuddiioo eett vviiddééoo,, oonn ppeeuutt eennvviissaaggeerr ddee rrééaalliisseerr uunn aauuttrree

ttyyppee ddee SSVVAA :: llee MMMMSS..

IIll eexxiissttee uunn llooggiicciieell OOppeenn SSoouurrccee dduu nnoomm ddee MMbbuunnnnii qquuii ppeerrmmeett ddee mmeettttrree eenn ppllaaccee cceellaa..

memoire laye baba

Documents

Transcript of memoire laye baba