Ben Slama Sofiene

Cycle de formation des ingnieurs en Tlcommunications
Option :
Rseaux et Services Mobiles
Rapport de Projet de fin dtudes
Thme :
Intgration des services vocaux aux services daccs aux donnes

Ralis par :
Ben Slama Sofiene

Encadrants :
M. Choukaier Zied (SUPCOM) M. Bel Habib Najib (NewTech) M. Zouari Mourad (IT.Com)
Travail propos et ralis en collaboration avec
&
Anne universitaire : 2006/2007
Ddicaces
La vie nest quun clair, Et un jour de russite est un jour trs cher.
A mon cher pre SlahEddine et ma chre mre Dahbia,
Pour lducation et le grand amour dont ils mont entour depuis ma naissance. Et pour leurs patiences et leurs sacrifices. A mes chers frres : Walid, Bacem, Naceur ; A ma chre soeur : Naziha ; A tous mes proches ; Au petit Achref ; A tous ceux qui m'aiment ; A tous mes ami (e) s; A tous ceux que jaime. Je ddie ce mmoire.
Sofiene BEN SLAMA
SupCom 2006/2007
Remerciements
Remerciements
Cest avec un grand plaisir que je rserve cette page en signe de gratitude et Je tiens exprimer mes sincres gratitudes et respects mes encadreurs Mr.
de profonde reconnaissance tous ceux qui mont aid de prs ou de loin la ralisation de ce travail.
Zied Choukaier, Matre de confrence lcole suprieure des communications de Tunis, et Mr Bel Habib Najib et Zouari Mourad, directeurs des socits
NewTech et IT.COM, Pour leurs encouragements et les prcieux conseils quils nont cesss de me prodiguer tout au long de ce projet.
Suprieure de Communication de Tunis (Supcom) qui de prs ou de loin na pargn aucun effort pour que nos travaux se termine dans les bonnes conditions.
Je nomettrai jamais dexprimer toute ma gratitude tout le staff de lEcole
mes meilleurs et vifs remerciements sadressent aux membres du jury pour avoir accept dvaluer ce projet.
Enfin
Sofiene BEN SLAMA
SupCom 2006/2007
ii
TABLE DES MATIERES
TABLE DES MATIERES
Liste des Figures et des Tableaux ......................................................................................... vi Glossaires .................................................................................................................................. viii Introduction Gnrale ................................................................................................................1 Chapitre I : Rseau de nouvelle gnration (NGN) et Voix sur IP (VoIP) ..................3
I.1. Introduction ...............................................................................................................................4 I.2. Les rseaux de nouvelles gnrations........................................................................................5 I.2.1. Dfinition........................................................................................................................... 5 I.2.2. Principe gnrale et vue densemble ................................................................................. 6 I.2.3. Les entits fonctionnelles du cur de rseau NGN........................................................... 7 I.2.3.1. Le Media Gateway...................................................................................................... 7 I.2.3.2. Le serveur dappel ou Media Gateway Controller ..................................................... 7 I.2.3.3. Le Signalling Gateway ............................................................................................... 7 I.2.4. Les protocoles de NGN ..................................................................................................... 7 I.2.4.1. Les protocoles de contrle dappel............................................................................. 8 I.2.4.2. Les protocoles de commande de Media Gateway ...................................................... 9 I.2.4.3. Les protocoles de signalisation entre les serveurs de contrle ................................. 10 I.3. Exemples des services offerts par les NGNs ...........................................................................11 I.4. La Voix sur IP..........................................................................................................................12 I.4.1. Dfinition et vue densemble........................................................................................... 12 I.4.2. Principaux composants darchitecture VoIP ................................................................... 13 I.4.3. Architecture VoIP............................................................................................................ 14 I.4.4. Caractristiques de la Voix.............................................................................................. 15 I.4.4.1. Un sens dlicat.......................................................................................................... 15 I.4.4.2. La conversation orale : une exigence dinteractivit ................................................ 15 I.4.5. Les paramtres de la voix sur IP...................................................................................... 15 I.4.5.1. Les diffrents chantillonnages ................................................................................ 16 I.4.5.2. Le dlai de transit ..................................................................................................... 17 I.4.5.3. La gigue de phase ..................................................................................................... 18 I.4.5.4. La perte de donnes .................................................................................................. 18 I.4.6. Les dfauts de la communication IP............................................................................... 18 I.5. Conclusion ...............................................................................................................................19
SupCom 2006/2007
iii
TABLE DES MATIERES
Chapitre II : Les protocoles de signalisation de VoIP et le langage VoiceXML ......20

II.1. Introduction ............................................................................................................................21 II.2. Les protocoles de contrle dappel.........................................................................................21 II.2.1. Architecture centralise.................................................................................................. 22 II.2.1.1. MGCP- Media Gateway Control Protocol .............................................................. 22 II.2.1.2. MEGACO/H.248..................................................................................................... 23 II.2.1.3. Net2Phone ............................................................................................................... 23 II.2.1.4. SCCP ....................................................................................................................... 23 II.2.2. Architecture distribue ................................................................................................... 23 II.2.2.1. Le protocole H.323.................................................................................................. 24 II.2.2.1.1. Les diffrents composants de H.323 ................................................................ 25 II.2.2.2. Le protocole SIP...................................................................................................... 28 II.2.2.2.1. Topologie de protocole SIP.............................................................................. 28 II.2.2.2.2. Les messages SIP ............................................................................................. 30 II.2.2.2.2.1. Les requtes de base SIP ............................................................................... 30 II.2.2.2.2.2. Les autres requtes SIP ................................................................................. 30 II.3. Avantages et Inconvnients H323, SIP et MGCP..................................................................31 II.4. VoiceXML et application vocale ...........................................................................................32 II.4.1. Introduction .................................................................................................................... 32 II.4.2. Prsentation de VoiceXML............................................................................................ 33 II.4.3. Dfinition ....................................................................................................................... 33 II.4.4. Concept de base.............................................................................................................. 34 II.4.5. Caractristiques .............................................................................................................. 34 II.4.5.1. Modle darchitecture ............................................................................................. 34 II.4.5.2. Avantages ................................................................................................................ 35 II.4.5.3. Inconvnients .......................................................................................................... 35 II.4.6. Systmes de dialogue oral homme-machine .................................................................. 35 II.4.6.1. Principes gnraux .................................................................................................. 35 II.4.6.2. Architecture gnrale .............................................................................................. 36 II.4.6.2.1. Reconnaissance automatique de la parole........................................................ 37 II.4.6.2.2 Comprhension smantique .............................................................................. 38 II.4.6.2.3 Interprteur pragmatique ................................................................................... 38 II.4.6.2.4 Contrleur du dialogue...................................................................................... 38 II.4.6.2.5 Contrleur de la tche ....................................................................................... 38 II.4.6.2.6 Gnrateur textuel ............................................................................................. 39 II.4.6.2.7 Synthtiseur de la parole ................................................................................... 39 II.4.6.3. Dfis dun systme de dialogue .............................................................................. 39 II.5. Conclusion..............................................................................................................................40
Chapitre III : Conception Objet de lapplication...............................................................41

III.1. Introduction...........................................................................................................................42 III.2. Cadre gnrale de lapplication ...........................................................................................42 III.2.1. Description.................................................................................................................... 43 III.2.2. Exemple de fonctionnement dune application VoiceXML ......................................... 43 III.3. Etude thorique .....................................................................................................................44 III.3.1. Formalisme UML.......................................................................................................... 44 III.3.1.1. Diagramme des cas dutilisation : DCU ................................................................ 45 III.3.1.2. Diagramme de squence : DES.............................................................................. 45 III.3.1.3. Diagramme dactivit : DAC ................................................................................. 45
SupCom 2006 /2007
iv
TABLE DES MATIERES

III.3.1.4. Diagramme de collaboration : DCO ...................................................................... 45 III.3.2. Identification et Reprsentation des cas dutilisation ................................................... 45 III.3.2.1. Cas dutilisation dinscription................................................................................ 46 III.3.2.2. Cas dutilisation didentification........................................................................... 46 III.3.2.3. Choix dquipe....................................................................................................... 46 III.3.2.4. Conception de site.................................................................................................. 47 III.3.3. Diagramme de collaboration :....................................................................................... 48 III.3.4. Diagramme dactivit.................................................................................................... 49 III.3.5. Diagramme de squence ............................................................................................... 50 III.3.5.1. De lappellent jusqu' lappel............................................................................... 50 III.3.5.2. Demande dinscription........................................................................................... 52 III.3.5.3. Cycle dauthentification......................................................................................... 53 III.3.5.4. Droulement de lapplication................................................................................. 53
Chapitre IV : Ralisation .........................................................................................................56

IV.1. Introduction...........................................................................................................................57 IV.2. Plate forme Voxeo pour VoiceXML ...................................................................................57 IV.2.1. Vue global sur Voxeo ................................................................................................... 57 IV.2.2. IVR ............................................................................................................................... 58 IV.2.3. Ralisation dune application VoiceXML .................................................................... 59 IV.3. Asterisk PBX ........................................................................................................................63 IV.3.1. Interprtation dun fichier VXML par lAsterisk ......................................................... 64 IV.3.2. Configuration de service Voice XML sur lAsterisk.................................................... 64 IV.3.3. Droulement dappel au niveau dAsterisk .................................................................. 65 IV.3.3.1. Fichiers de configuration dAsterisk ..................................................................... 65 IV.3.3.2. Fichiers de configuration de VoiceXML Browser ................................................ 67 IV.3.3.3. Paramtrage de Soft phone VoIP........................................................................... 67 IV.3.3.4. Rponse dAsterisk un appel entrant .................................................................. 69 IV.4. Site Sportif ............................................................................................................................70 IV.5. Conclusion ............................................................................................................................76
Conclusion gnrale et perspectives.....................................................................................77 Bibliographie ..............................................................................................................................79 Annexe .........................................................................................................................................80
SupCom 2006 /2007
Liste des Figures et des Tableaux
Liste des Figures

Figure I.1 : Principe gnral darchitecture dun rseau NGN ........................................................5 Figure I.2 : Architecture physique dun rseau NGN. .....................................................................6 Figure I.3 : Principaux composants dune solution de communication IP ....................................13 Figure I.4 : Architecture VoIP .......................................................................................................14 Figure II.1 : Intelligence uniquement auprs des "matres"...........................................................22 Figure II.2 : Intelligence partage entre les serveurs et les clients. ...............................................24 Figure II.3 : Topologie d'un rseau VoIP H.323.........................................................................25 Figure II.4 : Diagramme fonctionnel dune passerelle ..................................................................26 Figure II.5 : Diagramme fonctionnel dun Gatekeeper..................................................................26 Figure II.6 : Diagramme fonctionnel dune MCU .........................................................................27 Figure II.7 : Topologie d'un rseau VoIP SIP.............................................................................28 Figure II.8 : Proxy SIP ...................................................................................................................29 Figure II.9 : Modle darchitecture de VoiceXML........................................................................34 Figure II.10 : Architecture gnrale dun systme de DHM .........................................................36 Figure II.11 : Description dun module de reconnaissance de la parole........................................37 Figure III.1 : Serveurs vocaux de nouvelle gnration :................................................................42 Figure III.2 : Fonctionnement dune application VoiceXML........................................................43 Figure III.3 : Positionnement des neuf diagrammes dUML.........................................................44 Figure III.4 : Cas dutilisation dinscription ..................................................................................46 Figure III.5 : Cas dutilisation didentification ..............................................................................46 Figure III.6: Cas dutilisation de slection dquipe prfr Handballeuse..................................47 FigureIII.7 : Cas dutilisation de slection dquipe prfr Footballeuse...................................47 Figure III.8 : Cas dutilisation de conception de site .....................................................................48 Figure III.9 : Diagramme de collaboration ....................................................................................49 Figure III.10 : Diagramme dactivit .............................................................................................49 Figure III.11 : Diagramme de squence (appellent appel) ........................................................52 Figure III.12 : Diagramme de squence (inscription)....................................................................52 Figure III.13 : Diagramme de squence (identification)................................................................53 Figure III.14 : Diagramme de squence (conception de site) ........................................................54 Figure IV.1 : Plate forme Voxeo....................................................................................................58 Figure IV.2 : Composants des IVRs ..............................................................................................58 Figure IV.3 : Directeur d'application de Voxeo.............................................................................59 Figure IV.4 : Attribution dun numro de tlphone un fichier VXML .....................................59 Figure IV.5 : Attribution de fichier VXML est russi ...................................................................60 Figure IV.6 : Les diffrents points d'accs au fichier VXML. ......................................................61 Figure IV.7 : Apple dune application VoiceXML par FWD........................................................61 Figure IV.8 : Interface de programmation VXML ........................................................................62 Figure IV.9 : Exemple dun fichier VXML. ..................................................................................62 Figure IV.10 : Dtection des erreurs pour un fichier VXML. .......................................................63 Figure IV.11 : Interconnexion dAsterisk PBX .............................................................................64 Figure IV.12 : Les fichiers de configurations pour Asterisk .........................................................65
SupCom 2006 /2007
vi
Liste des Figures et des Tableaux

Figure IV.13 : Extensions.conf ......................................................................................................66 Figure IV.14 : VoiceXML Configuration......................................................................................66 Figure IV.15 : SIP Configuration...................................................................................................67 Figure IV.16 : Paramtrage de Softphone......................................................................................68 Figure IV.17 : X-Lite (Softphone VoIP)........................................................................................68 Figure IV.18 : Rponse dAsterisk pour lappel 1225...................................................................69 Figure IV.19 : Ouverture de site ....................................................................................................70 Figure IV.20 : Identification ou inscription ...................................................................................70 Figure IV.21 : Page dinscription...................................................................................................71 Figure IV.22 : Les messages dalertes. ..........................................................................................71 Figure IV.23 : Choix de type de service sportif.............................................................................72 Figure IV.24 : Page service football : choix dune League disponible..........................................72 Figue IV.25 : Choix dquipe : Page de la League anglaise..........................................................73 Figure IV.26 : Page dquipe Arsenal............................................................................................73 Figure IV.27 : Excution de Skype VoIP ......................................................................................74 Figure IV.28 : Dmarrage de Skype ..............................................................................................74 Figure IV.29 : Numrotation de Skype..........................................................................................75 Figure IV.30 : Liens de tlchargement des Softphone VoIP .......................................................75
Liste des Tableaux

Tableau I.1 : Codecs en fonction de leurs vitesses dchantillonnage...........................................16 Tableau I.2 : Bilan de bande passante en fonction du codec .........................................................16 Tableau II.1 : Avantages et Inconvnients des protocoles de signalisation de VoIP ....................31 Tableau III.1 : Diagramme UML...................................................................................................45
SupCom 2006 /2007 vii
Glossaires
Glossaires
A
ATM: Asynchronous Transfer Mode. ASR: Automatic Speech Recognizer. ADSI: Active Directory Service Interfaces.
B
BICC: Bearer Independant Call Control.
C
CPL: Call Processing Language. CGI: Common Gateway Interface.
D
DTMF: Dual-tone multi-frequency.
F
FWD: Free World Dialup.
G
GK: Gatekeeper.
H
HTTP: Hypertext Transfer Protocol. HTML: Hypertext Markup Language.
I
IVR: Interactive Voice Response. IP: Internet Protocol. IETF: Internet Engineering Task Force.
SupCom 2006 /2007 viii
Glossaires
L
LAN: Local Area Network. LS: Location Server.
M
MG: Media Gateway. MGC: Media Gateway Controller. MGCP: Media Gateway Control Protocol. MRCP: Media Resource Control Protocol. MCU: Multipoint Controller Unit. MMUSIC: Multiparty Multimedia Session Control.
N
NGN: Next Generation Networks.
O
OSI: Open Systems Interconnection.
P
PSTN: Public Switched Telephone Network. PPP: Point to Point Protocol. PABX: Private Automatic Branch eXchange. PBX: Private branch exchange. PDA: Personal Digital Assistant.
R
RTC: Rseau tlphonique commut. RTP: Real-time Transfert Protocole. RTCP: Real-time Transfert Control Protocole. RAS: Rseau Associatif et Syndical. RNIS: Rseau numrique intgration de services. RTSP: Real Time Streaming Protocol.
S
SS7: Signalling System 7. SIP: Session Initiation Protocol. SMTP: Simple Mail Transfer Protocol. SG: Signalling Gateway. SIGTRAN: Signalling Transport, Informational: RFC 2719. SCTP: Stream Control Transmission Protocol. SCCP: Skinny Client Control Protocol. SDP: Session Description Protocol.
SupCom 2006 /2007
ix
Glossaires
SSML: Speech Synthesis Markup Language. SRGS: Speech Recognition Grammar Specification. SISR: Semantic Interpretation for Speech Recognition.
T
TDM: Time Division Multiplexing. TCP: Transmission Control Protocol. TTS: Text To Speech.
U
UIT: Union Internationale des Tlcommunications. UDP: User Datagram Protocol. UMTS: Universal Mobile Telecommunications System. UAC: User Agent Client. UAS: User Agent Serveur. URL: Uniform Resource Locator. UML: Unified Modeling Language.
V
VoIP: Voice Over Internet Protocol. VPN: Virtual Private Network. VXML: Voice Extensible Markup Language.
W
WAN: Wide Area Network. W3C: The World Wide Web Consortium.
SupCom 2006 /2007
Introduction gnrale
Introduction Gnrale
Les volutions profondes vcues et le dveloppement de nouvelles gammes de services semblent tres des facteurs favorables lvolution progressive du monde des tlcommunications vers un nouveau modle de rseaux et de services appel NGN (Next Generation Networks). Ce nouveau concept propose le transport de plusieurs informations diffrentes sur un support mode paquet, on parle donc de la convergence Voix/donnes et fixe/Mobile. Lutilisation dun rseau en mode paquet pour transporter de la voix, avec des contraintes de temps rel, a ncessit ladaptation de la couche contrle. En effet, ces rseaux en mode paquet taient gnralement utiliss comme rseau de transport mais noffraient pas de services permettant la gestion des appels et des communications. Cette volution a conduit donc lapparition de nouveaux protocoles tels que H.323 et SIP, concernant la gestion des flux multimdia, au sein de la couche contrle. Dialoguer est un art de vivre , cet adage est certainement vrai, non seulement dans la vie quotidienne, mais galement dans laspect communicatif entre lhomme et le systme dinformation. La notion d' application vocale couvre une zone plus vaste dans l'ensemble des applications informatiques. Nous dfinissons une application vocale comme une application informatique utilisant la parole pour raliser/accomplir certaines tches. Dans ce type d'applications, l'utilisateur peut dialoguer avec l'application en utilisant seulement les mots cls, une phrase courte et simple, ou toute la complexit de la langue. Cest dans ce contexte que dcline lobjectif de notre projet de fin dtude, propos dans le cadre dune collaboration entre lcole suprieure des communications de Tunis, les socits IT.COM et NEWTECH , pour la ralisation des IVRs : les rponses vocales interactives soit sur une plateforme Web Voxeo ou sur lAsterisk PBX. Il sagit de prsenter un tat de lart concernant dune part la notion des rseaux NGNs ainsi que les diffrents protocoles de signalisation, de contrle et de commande dappels, dautre part le langage VoiceXML afin de nous permettre moyennant des Soft phones VoIP dappeler une application vocale prdfinie. Ce mmoire sorganise en quatre chapitres et se termine par une conclusion, ouvrant sur des perspectives : Le premier chapitre introduit le concept NGN, il prsente dans un premier volet les protocoles de signalisation de contrle et de commande dappel. Le deuxime volet porte sur la notion de la voix sur IP et de ses exigences comme tant un service directement li aux NGNs.
SupCom 2006/2007
Introduction gnrale
Le second chapitre se focalise davantage sur les protocoles de contrle dappel savoir les protocoles H.323 et SIP. Nous dtaillerons alors leurs architectures ainsi que leurs caractristiques. Et la fin de ce chapitre nous expliquons la notion dapplication vocale ainsi que le langage VoiceXML. La reprsentation et la conception de travail faire seront proposes dans le troisime chapitre qui se divise en deux parties : la premire pour la description de lapplication aussi bien que lintroduction dutilisation de VoiceXML comme un langage de programmation pour le dveloppement des IVRs dans un rseau tout IP, la seconde consacr une tude thorique de travail raliser exprimentalement en dtaillant quelques diagrammes UML qui vont tre raliser travers Rational Rose comme logiciel. Le quatrime chapitre sadresse laspect pratique en prsentant lexprimentation de toutes nos approches thoriques. Nous exposons tout dabord la plate forme Voxeo comme un outil de dveloppement des IVRs, nous prsentons par la suite lAsterisk PBX, la notion de VoiceXML Browser ainsi que son utilisation avec lAsterisk pour linterprtation des fichiers VoiceXML. Enfin la ralisation dun petit site web dans le but est de fournir des infos vocales sportives par lutilisation des numros spcifiques travers des Soft phones VoIP bien dfinies. Le bilan gnral de ce mmoire est prsent dans la conclusion et diverses perspectives sont galement proposes.
SupCom 2006/2007
Chapitre I : Rseau de nouvelle gnration (NGN) et voix sur IP (VoIP)
Chapitre I
Rseau de nouvelle gnration (NGN) et Voix sur IP (VoIP)
SupCom 2006/2007
Chapitre I
Rseau de nouvelle gnration (NGN) et Voix sur IP (VoIP)
I.1. Introduction
Depuis linvention du tlphone par Alexander Graham Bell en 1876, de nombreux progrs et rvolutions se sont oprs dans le domaine des tlcommunications. Aujourdhui, d ailleurs, nous vivons dans lre des tlcommunications et il est devenu impensable de se sparer des services offerts par ce secteur. Les volutions profonds vcus et le dveloppement de nouvelles gammes de services semblent tres des facteurs favorable lvolution progressive du monde des tlcommunications vers un nouveau modle de rseaux et de services appel NGN (Next Generation Networks). Cest dans ce contexte que ce premier chapitre est consacr la prsentation des rseaux de nouvelles gnrations (NGN Next Generation Network). Dans une premire section nous nous sommes intresss larchitecture des rseaux NGNs, aux diffrents lments qui le composent ainsi quaux diffrents protocoles en concurrence. La seconde section met laccent sur un service directement li lvolution vers les rseaux NGNs ; savoir le service de la voix sur IP (VoIP).
SupCom 2006/2007
Chapitre I : Rseau de nouvelle gnration (NGN) et voix sur IP (VoIP) I.2. Les rseaux de nouvelles gnrations
I.2.1. Dfinition
Les NGNs sont dfinis comme un rseau de transport en mode paquet permettant la convergence des rseaux Voix/donnes et Fixe/Mobile ; ces rseaux permettront de fournir des services multimdia accessibles depuis diffrents rseaux daccs. Afin de sadapter louverture des nouveaux services, les NGN sont bass sur une volution progressive vers le tout IP . Ils sont modliss par une architecture en couches indpendantes (transport, contrle, services et accs) dialoguant via des interfaces ouvertes et normalises [1].
Couche Service (oprateur et tiers) Interfaces ouvertes et normalises
Primtre NGN
Couche Contrle Interfaces ouvertes et normalises Couche Transport (mode paquet)
Cur de rseau
Rseau daccs multiple
Connexe aux NGN

Terminaux
Figure I.1 : Principe gnral darchitecture dun rseau NGN La couche Accs , qui permet laccs de lutilisateur aux services via des supports de transmission et de collecte divers : cble, cuivre, fibre optique, boucle locale radio, xDSL, rseaux mobiles. La couche Transport , qui gre lacheminement du trafic vers sa destination. En bordure du rseau de transport, des Media Gateways et des Signalling Gateways gre respectivement la conversion des flux de donnes et de signalisation aux interfaces avec les autres ensembles du rseau ou les rseaux tiers interconnects. La couche Contrle , qui se compose de serveurs dits Softswitch grant dune part les mcanismes de contrle dappel (pilotage de la couche transport, gestion des adresses), et dautre part laccs aux services (profils dabonns, accs aux plates formes de services valeur ajoute). La couche Services , qui regroupe les plates-formes dexcution de services et de diffusion de contenus. Elle communique avec la couche contrle du coeur de rseau via des interfaces ouvertes et normalises, indpendantes de la nature du rseau daccs
SupCom 2006/2007

utilis. Les services et contenus eux-mmes sont par ailleurs dvelopps avec des langages convergents et unifis.
I.2.2. Principe gnrale et vue densemble

Les principales caractristiques des rseaux NGN sont lutilisation dun unique rseau de transport en mode paquet (IP, ATM,) ainsi que la sparation des couches de transport des flux et de contrle des communications, qui sont implmentes dans un mme quipement pour un commutateur traditionnel. Ces grands principes se dclinent techniquement comme suit concernant les quipements actifs du coeur de rseau NGN :
A/ Remplacement des commutateurs traditionnels par deux types dquipements distincts :
Des serveurs de contrle dappel dits Softswitch ou Media Gateway Controller (correspondant schmatiquement aux ressources processeur et mmoire des commutateurs voix traditionnels). . Des quipements de mdiation et de routage dits Media Gateway (correspondant schmatiquement aux cartes dinterfaces et de signalisation et aux matrices de commutation des commutateurs voix traditionnels), qui sappuient sur le rseau de transport mutualis NGN.
B/ Apparition des nouveaux protocoles de contrle dappel et de signalisation entre ces quipements (de serveur serveur et de serveur Media Gateway).
Figure I.2 : Architecture physique dun rseau NGN.
SupCom 2006/2007

I.2.3. Les entits fonctionnelles du cur de rseau NGN I.2.3.1. Le Media Gateway (MG)
Le Media Gateway est situe au niveau du transport des flux mdia entre le rseau RTC et le rseau en mode paquet, ou entre le coeur de rseau NGN et les rseaux daccs. Il a pour rle : Le codage et la mise en paquets du flux mdia reu du RTC et vice-versa (conversion du trafic TDM (Time Division Multiplexing) en trafic IP (Internet Protocol)). La transmission, selon les instructions du Media Gateway Controller, des flux mdia reus de part et d'autre.
I.2.3.2. Le serveur dappel ou Media Gateway Controller (MGC)

Dans un rseau NGN, le MGC possde de l'intelligence et cest lui qui gre : Lchange des messages de signalisation transmise de part et d'autre avec les passerelles de signalisation, et linterprtation de cette signalisation. Le traitement des appels : dialogue avec les terminaux H.323, SIP, communication avec les serveurs dapplication pour la fourniture des services. Le choix du MG de sortie selon l'adresse du destinataire, le type d'appel, la charge du rseau, etc. La rservation des ressources dans le MG et le contrle des connexions internes au MG (commande des Media Gateways).
I.2.3.3. Le Signalling Gateway (SG)

La fonction Signalling Gateway a pour rle de convertir la signalisation change entre le rseau NGN et le rseau externe interconnect selon un format comprhensible par les quipements chargs de la traiter, mais sans linterprter (ce rle tant dvolu au Media Gateway Controller). Notamment, elle assure ladaptation de la signalisation par rapport au protocole de transport utilis (ex. : adaptation TDM /IP). Cette fonction est souvent implmente physiquement dans le mme quipement que la Media Gateway, do le fait que ce dernier terme est parfois employ abusivement pour recouvrir les deux fonctions MG + SG.
I.2.4. Les protocoles de NGN

La convergence des rseaux voix/donnes ainsi que le fait dutiliser un rseau en mode paquet pour transporter des flux multimdia, ayant des contraintes de temps rel , a ncessit ladaptation de la couche Contrle. En effet ces rseaux en mode paquet taient gnralement utiliss comme rseau de transport mais noffraient pas de services permettant la gestion des appels et des communications multimdia. Cette volution a conduit lapparition de nouveaux
SupCom 2006/2007

protocoles, principalement concernant la gestion des flux multimdia, au sein de la couche Contrle. On peut classer les protocoles de contrle en diffrents groupes :
Les protocoles de contrle dappel permettant ltablissement, gnralement linitiative

dun utilisateur, dune communication entre deux terminaux ou entre un terminal et un serveur ; les deux principaux protocoles sont H.323, norme de lUIT et SIP, standard dvelopp lIETF.
Les protocoles de commande de Media Gateway qui sont issus de la sparation entre les
couches Transport et Contrle, permettent au Softswitch ou Media Gateway Controller de grer les passerelles de transport ou Media Gateway. MGCP (Media Gateway Control Protocol) de lIETF et H.248/MEGACO, dvelopp conjointement par lUIT et lIETF, sont actuellement les protocoles prdominants.
Les protocoles de signalisation entre les serveurs de contrle (ou Media Gateway
Controller) permettant la gestion du plan contrle : Au niveau du coeur de rseau avec des protocoles tels que BICC (Bearer Independant Call Control), SIP-T (SIP pour la tlphonie) et H.323. A linterconnexion avec les rseaux de signalisation SS7, gnralement via des passerelles de signalisation ou Signalling Gateways par lutilisation de protocole tel que SIGTRAN. De plus, linterconnexion de ces rseaux de donnes avec les rseaux existants de tlphonie (TDM avec signalisation SS7) a ncessit le dveloppement de protocoles ddis linterconnexion des rseaux et au transport de la signalisation SS7 sur des rseaux en mode paquet.
I.2.4.1. Les protocoles de contrle dappel

Deux protocoles candidats :
Protocole H.323
Le standard H.323 de lUIT-T spcifie les composants, les mthodes et les protocoles pour permettre la communication en temps rel de donnes multimdia travers les rseaux commutation de paquets, notamment les rseaux technologie IP [2]. H.323 assure la communication entre plusieurs composants du rseau : Les terminaux H.323 sont des systmes multimdia (tlphone, PC) permettant de communiquer en temps rel . le Gatekeeper gre les terminaux H.323 (identification et traduction dadresses) et les tablissements dappels La passerelle H.323 (Gateway) permet dinterfacer le rseau IP avec le rseau tlphonique classique. Lunit de contrle MCU (Multipoint Controller Unit) gre les connexions multipoint (ex. : appels de confrence). Il se dcompose en un Multipoint Controller (MC), affect
SupCom 2006/2007

la signalisation, et un Multipoint Processor (MP), ddi la transmission proprement dite. H.323 sappuie sur 3 points de normalisation : Des protocoles de communications : RTP, RTCP, Des protocoles de signalisation : RAS, H.245, Q.931. Des codecs audio : G.711, G723.1, G.728,, et des codecs vido : H.261, H.263.
Le protocole SIP
SIP : Session Initiation Protocol est un protocole de contrle qui peut tablir, modifier et terminer des sessions multimdia, aussi bien des confrences que des appels tlphoniques sur des rseaux en mode paquets. Il est sous forme de texte, tout comme http ou SMTP, et a pour rle dinitier des sessions de communications interactives. Ces sessions peuvent inclure aussi bien de la voix, de la vido, des jeux interactifs... L'architecture de SIP est base sur des relations client/serveur. Les principales composantes sont : Les terminaux : sont des appareils pouvant mettre et recevoir de la signalisation SIP. Le Redirect Server : tablit la correspondance entre ladresse SIP du terminal appel et la ou les adresses o il pourra effectivement tre joignable. Le Proxy Server : remplit la mme fonction quun Redirect Server. Le Registrar : est essentiel dans tout rseau SIP ou lon veut utiliser les services de localisation.
I.2.4.2. Les protocoles de commande de Media Gateway

Deux protocoles candidats :
Le Media Gateway Control Protocol: MGCP

Ce protocole dfini par lIETF (RFC 2705), a t conu pour des rseaux de tlphonie IP utilisant des passerelles VoIP. Il gre la communication entre les Media Gateway et les Media Gateway Controller . Ce protocole traite la signalisation et le contrle des appels, dune part, et les flux mdia dautre part. Les diffrents lments qui utilisent MGCP sont : Signalling Gateway : Elle ralise linterface entre le rseau de tlphonie (signalisation SS7) et le rseau IP. Elle termine les connexions des couches basses de SS7 et transmet les messages ISUP au MGC. Media Gateway Controller (MGC) ou Call Agent : Il opre lenregistrement, la gestion et les contrles des ressources des Media Gateway. Elle coordonne ltablissement, le contrle et la fin des flux mdia qui transitent par le Media Gateway. Media Gateway (MG) : Il est le point dentres ou de sortie des flux mdia linterface avec les rseaux IP et tlphoniques. Elle effectue la conversion des mdias entre le mode circuit (tlphonique) au mode paquet (IP).
SupCom 2006/2007

Le protocole alternatif : MEGACO/H.248
Le groupe de travail MEGACO (Media Protocol Control) a t constitu en 1998 pour complter les travaux sur le protocole MGCP au sein de lIETF. Depuis 1999, lUIT et lIETF travaillent conjointement sur le dveloppement du protocole MEGACO/H.248 ; cest un standard permettant la communication entre les Media Gateway Controller (MGC) et les Media Gateway (MG). Il est driv de MGCP et possde des amliorations par rapport celui-ci :
Support de services multimdia et de vidoconfrence. Possibilit dutiliser UDP ou TCP. Utilise le codage en mode texte ou binaire.
Une premire version de H.248 a t adopte en juin 2000 (RFC 3015 de lIETF). Limplmentation de H.248 permet une grande modularit ; en effet, ce protocole est tendu par des packages rpondant des besoins spcifiques. Ce systme permet de couvrir un nombre trs important dapplications, mais complique aussi grandement linter fonctionnements dquipements dorigine diffrente. Ainsi un constructeur peut implmenter, suivant ses besoins, tel ou tel package qui ne sera pas obligatoirement choisi par un autre constructeur.
I.2.4.3. Les protocoles de signalisation entre les serveurs de contrle A/ Au cur de rseau (NGN) BICC (Bearer Independant call control)
Ce protocole a pour objectif la gestion de la communication entre les serveurs de contrle, indpendamment du type de support, permettant aux oprateurs de raliser une migration de leurs rseaux RTC/RNIS vers des rseaux en mode paquet. En vue, donc, dune migration des rseaux tlphoniques (SS7) vers une architecture NGN, une recommandation de lUIT, le protocole BICC, doit tendre le protocole de signalisation actuellement implment sur les rseaux tlphoniques, lISUP. En effet BICC est en grande partie issu de lISUP ; les recommandations font dailleurs directement rfrence lISUP, quant sa dfinition mais aussi pour linteroprabilit avec H.323. La premire version de ce protocole, BICC CS1 (BICC Capability Set 1) dfinit le transport de signalisation sur un rseau ATM en tant que rseau de transit. La seconde version de ce protocole, BICC CS2, largit normment son rayon daction et les capacits. Il permet : Lutilisation dun rseau IP comme rseau de transit. Il sagit de tunnelling de messages de signalisation par le protocole BICC sur un rseau de transport IP, de passerelle passerelle (Signalling Gateway), donc transparent pour les MGC du rseau IP.
Protocole SIP entre Media Gateway Controller: SIP-T

LInternet Draft SIP-T (SIP pour la tlphonie) de lIETF dfinit la gestion de la tlphonie par le protocole SIP ainsi que linterconnexion avec le RTC : cependant uniquement avec le protocole SS7 ISUP. SIP-T prconise :
SupCom 2006/2007
10

Lencapsulation des messages ISUP lintrieur de messages SIP, permettant la transmission de faon transparente de la signalisation ISUP dans le cas de transit par un rseau IP. Le renseignement de len-tte du message SIP par les informations contenues dans le message ISUP, permettant dacheminer le message correctement travers le rseau IP et de terminer les appels sur un terminal SIP.
B/ A linterconnexion avec les rseaux de signalisation SS7

SIGTRAN (Signalling Transport, Informational : RFC 2719) dvelopp par un groupe de travail de lIETF. Ce groupe dfinit le protocole de contrle entre : Les Signalling Gateways, qui reoivent la signalisation SS7 sur TDM, et la convertissent en SS7 sur IP. Les Media Gateway Controllers, qui interprtent la signalisation SS7 sur IP. Les Signalling Points du rseau IP (serveurs de contrle dappel). Ce protocole utilise une nouvelle couche de transport appele Stream Control Transmission Protocol (SCTP) permettant de pallier les dfauts du protocole TCP pour la gestion des messages de signalisation.
I.3. Exemples des services offerts par les NGNs

Les NGN offrent les capacits, en termes dinfrastructure, de protocole et de gestion, de crer et de dployer des nouveaux services multimdia sur des rseaux en mode paquet. La grande diversit des services est due aux multiples possibilits offertes par les rseaux NGN en termes de : Support multimdia (donnes, texte, audio, visuel). Mode de communication, Unicast (communication point point), Multicast (communication point-multipoint), Broadcast (diffusion). Mobilit (services disponibles partout et tout le temps). Portabilit sur les diffrents terminaux. Parmi ces services offerts on cite : La messagerie instantane La messagerie unifie La diffusion de contenus multimdia La voix sur IP (VoIP) . On se concentrera dans cette section la prsentation du service de la voix sur IP qui fait une importance partie pour llaboration de lobjet de notre projet de fin dtude.
SupCom 2006/2007
11
Chapitre I : Rseau de nouvelle gnration (NGN) et voix sur IP (VoIP) I.4. La Voix sur IP (VoIP)
I.4.1. Dfinition et vue densemble
VoIP signifie textuellement Voice Over IP, en franais : Voix sur IP. Le principe consiste encapsuler un signal audio numris (en gnral la voix) dans le protocole IP (Internet Protocol). La principale application de ce principe est la tlphonie Internet (tlphonie IP).A la diffrence des tlphones analogiques filaires (RTC) distribus par les centraux tlphoniques, la VoIP permet d'tendre la tlphonie sur tout rseau numrique ou analogique acceptant le protocole TCP/IP (Ethernet, RNIS, PPP, etc.). La transmission de la voix sur IP Voice Over IP - VoIP consiste essentiellement considrer les chantillons de voix comme des donnes particulires galement susceptibles dtre transportes de faon banalise sur un rseau IP. Lapproche VoIP sapplique donc au transport de la voix sur Internet, sur un Intranet dentreprise ou dans le cadre dun Extranet. La transmission de la voix par lintermdiaire du protocole IP a dbut avec IBM en 1996 sous la forme dapplications dites de tlphonie sur Internet (Internet Telephony) permettant deux internautes de communiquer oralement via leur PC. Ces premires applications taient caractrises par une qualit de voix trs mauvaise: retards importants souvent suprieurs une seconde, chos, paroles saccades, qui en rendaient lintrt essentiellement exprimental et ludique. Vu lvolution profonde du secteur de tlcommunication et lintroduction du concept NGN, la voix sur IP est considr un service directement li ce nouveau paradigme. Cest un service qui est apparue depuis longtemps mais qui na pas encore eu le succs escompt, et cela pour diffrentes raisons : La jeunesse des protocoles de signalisation (SIP, H.323, Megaco) de voix sur IP et la gestion de la qualit de service qui commence seulement maintenant tre mature ne permettaient pas de dployer de services tlphoniques sur IP. Le seul fait de transporter la voix sur IP napporte pas de valeur ajoute pour lutilisateur final, par rapport au service de voix classique. Les services associs la voix sur IP nont pas encore la maturit ncessaire pour pousser lvolution vers ces nouveaux rseaux. La ncessit dinterconnecter les rseaux IP aux rseaux TDM/SS7 implique des cots lis aux quipements dinterconnexion (passerelles) et le prix des terminaux (IP phones) annihile lavantage financier apport par le transport en IP. Le cot des terminaux IP reste encore suprieur celui des quipements classiques (pas encore dconomies dchelle suffisantes). Cependant lvolution de la technologie et des protocoles et lapparition de services associs au monde IP devraient permettre lmergence de la voix sur IP. De plus, lvolution des terminaux communicants multimdia est un argument supplmentaire lvolution des rseaux tlphoniques vers la voix sur IP ; ainsi lUMTS, dans le release 5, gnralise le transport en IP au rseau voix.
SupCom 2006/2007
12

I.4.2. Principaux composants darchitecture VoIP
Les principaux composants fonctionnels dune solution de communication IP sont [4] : La capacit de commutation n'est plus dvolue la matrice de commutation d'un PABX et s'appuie sur les quipements de rseau local et tendu. Elle n'est pas ddie la fonction PABX et peut tre issue d'un autre constructeur, elle volue naturellement en fonction de lvolution du rseau. Livre blanc : Communications IP La fonction de signalisation, de gestion des abonns et des fonctionnalits tlphoniques est dvolue un ou plusieurs serveurs hbergeant l'application LAN PBX. Il sagit gnralement dun serveur entirement standardis et exploit sous Linux ou Windows 2000. La voix ne transite pas par ce serveur. Cette solution est gnralement complte par des quipements contrleurs de mdia en charge de la compression, la paquetisation ou le mixage (confrence) des flux voix, vidos et donnes. Les clients peuvent tre des tlphones respectant le standard Ethernet (filaire ou wireless) ou par des logiciels installs sur des postes de bureautiques (Softphones), des PDA. Les clients peuvent nanmoins vouloir utiliser leurs combins mobiles, des quipements de visioconfrences, des logiciels de messagerie instantane, etc., pour communiquer. L'accs au rseau, l'intgration d'quipements de tlphonie classique est ralis par des passerelles intgres dans des quipements ddis, des routeurs, des commutateurs LAN, etc. Cette infrastructure peut tre complte par des applications (messagerie, serveur vocal interactif, etc.) entirement logicielles et dialoguant sur IP avec le reste de l'infrastructure de tlphonie.
Figure I.3 : Principaux composants dune solution de communication IP
SupCom 2006/2007
13

I.4.3. Architecture VoIP
Le schma suivant reprsente les diffrents blocs utiliss lors de ltablissement dune communication IP
Figure I.4 : Architecture VoIP
SupCom 2006/2007
14

I.4.4. Caractristiques de la Voix
Le systme vocal est complexe et bas sur des ondes sonores de frquences diffrentes. Le spectre des frquences perues par loreille humaine stale de 100 Hz 20 KHz. Cette fourchette est, cependant, rduire si lon veut distinguer les frquences utiles des frquences audibles. En effet, la quasi-totalit dun message sonore est comprhensible dans la fourchette 330-3400 Hz. Qui est dailleurs utilise par le tlphone standard [3].
I.4.4.1. Un sens dlicat

Contrairement la vue, louie est plus exigeante. En effet, un film dont le rafrachissement serait 25 images/sec, ne troublerait pas une personne habitue 30 images/sec. De mme, la qualit dune image photographique argentique compare celle dun appareil numrique, bien que diffrente pour les puristes, peut tre accepte. Si lon se concentre sur laspect conversation orale, on remarque, daprs diffrentes tudes, que la marge de manoeuvre est beaucoup plus rduite et une dgradation au-del de 10% pourrait tre nfaste.
I.4.4.2. La conversation orale : une exigence dinteractivit

Une conversation entre deux personnes respecte deux principes : intelligibilit et interactivit. Couper la parole quelquun ne se fait pas, mais cest un gage dinteractivit et de dialogue. En termes de transmission numrique, cela se traduit par le terme duplex. Une conversation full duplex assure cette interactivit car chaque locuteur peut parler en mme temps, ce qui arrive quand deux personnes parlent de leur propre exprience sans scouter
I.4.5. Les paramtres de la voix sur IP

Les aspects dterminants pour la qualit de la voix sur un rseau sont le traitement de la voix, la clart, le dlai de bout en bout et lcho. Ils dpendent des diffrents composants de la chane de transmission, de leur paramtrage, de larchitecture gnrale de la chane, et dans le cas de la VoIP des flux concurrents. Ces aspects sont les suivants : Traitement de la voix : lors de l'mission du signal, la voix est traite, c'est--dire code et ventuellement compresse, avant d'tre transmise. La clart et la mesure de fidlit de la voix reue par rapport la voix mise. Le dlai de bout en bout est le temps de propagation de la voix travers le rseau de lmetteur vers le rcepteur. Lcho est le son mis par lmetteur qui lui revient. La problmatique de qualit de la voix sur IP est particulire car la voix attend de son transporteur autre chose que les donnes. La transmission de donnes classique (fichiers, messages, transactions ) ne supporte aucune perte en ligne sous peine de graves consquences pour linterprtation et lutilisation de ces donnes par lquipement rcepteur, mais elle supporte en revanche une drive importante en termes de dure dacheminement. Peu importe quun paquet arrive avec 100 ms de retard. Le comportement attendu pour la voix est exactement inverse : 1% ou 2% de perte de donnes de voix en ligne ne sont pas trop gnants pour la qualit du service de VoIP, mais en revanche une variation frquente de 100 ms sur le dlai de transit est catastrophique et rend le service inutilisable.
SupCom 2006/2007
15

La voix attend donc du transport IP linverse de ce quexigent les donnes. Et cette formulation nest quun raccourci car en fait le transport de la voix exige beaucoup plus : il bnficiera videmment de lintgrit exige pour le transport des donnes laquelle est garantie par les rseaux modernes bien quil puisse sen affranchir dans une certaine limite mais exigera beaucoup plus au niveau des autres paramtres, notamment en ce qui concerne la stabilit du rseau dans le temps. Nous prsenterons la suite les principaux paramtres influents en VoIP, dans lordre les chantillonnages (codecs), le dlai de transit, la gigue de phase et les pertes de donnes.
I.4.5.1. Les diffrents chantillonnages

Le paramtre dchantillonnage ou codecs (pour compression / dcompression) est structurant en VoIP. Le codec dtermine quelle vitesse la voix est chantillonne et dimensionne par la mme le flux de donnes numriques que va gnrer la transformation dun chantillon temporel de voix analogique. Les codecs sont rpertoris par leur nom lITU. Les codecs les plus utiliss et leurs vitesses dchantillonnage sont les suivants [5] : Codecs G.711 G.726 G.726 G.728 G.729 G.723.1 MPMLQ G.723.1 ACELP Vitesse dchantillonnage 64 Kbps 32 Kbps 24 Kbps 16 Kbps 8 Kbps 6.3 Kbps 5.3 Kbps
Tableau I.1 : Codecs en fonction de leurs vitesses dchantillonnage Le choix du codec est un compromis entre la qualit de services souhaits et la capacit de linfrastructure IP dlivrer une bande passante et des paramtres de QoS qui vont impacter cette qualit. Le paramtre le plus dterminant auquel on sintresse pour commencer est la bande passante que lon met en regard du nombre de communications simultanes couler. Le tableau suivant permet deffectuer rapidement le bilan de bande passante en fonction du codec choisi :
Echantillonnage (codec) Dlai Codec Dbit Intervalle volume de donnes de voix (kbps) chantillonnage chantillonnage par chantillonnage de (ms) (ms) codec (octets) G.711 64 20 1 180 G.726 32 20 1 80 G.726 24 20 1 60 G.728 16 20 25 40 G.729 8 20 25 20 G.723.1 6.3 30 67.5 24 G.723.1 5.3 30 67.5 20
SupCom 2006/2007
16

Calcul de bande passante ncessaire volume de Dur de donne donne Nombre Bande Bande s de s de de passante passante voix voix paquet Bande Ethernet Bande Ethernet dans dans passante passante par avec avec RTP RTP second IP/UDP/RT IP/UDP/RT IP/UDP/cRT IP/UDP/cRT (octets) (ms) e P (kbps) P (kbps) P (kbps) P (kbps) 160 20 50 80.0 87.2 65.6 72.8 80 20 50 48.0 55.2 33.6 40.8 60 20 50 40.0 47.2 25.6 32.8 60 30 33 26.7 31.5 17.1 21.9 20 20 50 24.0 31.2 9.6 16.8 24 30 33 17.1 21.9 7.5 12.3 20 30 33 16.0 20.8 6.4 11.2
Bande passant e RTP/IP pour 10 canaux (kbps) 800 480 400 267 240 171 160
Bande passant e RTP/IP pour 32 canaux (kbps) 2560 1536 1280 853 768 546 512
Tableau I.2 : Bilan de bande passante en fonction du codec Le choix du codec G.711 permet de bnficier rseau constant de la meilleure qualit de service, tandis que les compressions G.726, G.728, G.729 et G.723 apportent avec elles des diminutions initiales de la QoS.
I.4.5.2. Le dlai de transit

Le dlai de transit (ou end-to-end delay dans la dnomination anglo-saxonne) est un des paramtres critiques influenant fortement la QoS dun service de voix sur IP. Cest le temps que va mettre en moyenne un paquet IP contenant un chantillon de voix pour traverser linfrastructure entre deux interlocuteurs. Ce temps de transit comporte quatre composantes : Le dlai dchantillonnage. Le dlai de propagation. Le dlai de transport. Le dlai des buffers de gigue. Le dlai dchantillonnage est la dure de numrisation de la voix lmission puis de conversion en signal voix la rception. Ce temps dpend du type de codec choisi et varie de quelques millisecondes avec le codec G.711 (chantillonnage 64 kbps) plus de 50 ms en G.723 (chantillonnage 6,3 ou 5,3 kbps). Le dlai de propagation est la dure de transmission en ligne des donnes numrises. Cette dure est normalement trs faible par rapport aux autres composantes du dlai de transit, de lordre de quelques millisecondes. Le dlai de transport est la dure passe traverser les routeurs, les commutateurs et les autres composants du rseau et de linfrastructure de tlphonie IP. Lordre de grandeur est de plusieurs dizaines de millisecondes.
SupCom 2006/2007
17

Le dlai des buffers de gigue est le retard introduit la rception en vue de lisser la variation de temps de transit, et donc de rduire la gigue de phase. Lordre de grandeur est de 50 ms. Les lments dinfrastructure, notamment les routeurs, peuvent galement mettre en uvre des buffers de gigue.
I.4.5.3. La gigue de phase

La variation de temps de transit, ou gigue de phase, est la consquence du fait que tous les paquets contenant des chantillons de voix ne vont pas traverser le rseau la mme vitesse. Cela cre une dformation de la voix ou un hachage. La gigue de phase est indpendante du dlai de transit. Le dlai peut tre court et la gigue importante ou inversement. La gigue est une consquence de congestions passagres sur le rseau, ce dernier ne pouvant plus transporter les donnes de manire constante dans le temps. La valeur de la gigue va de quelques ms quelques dizaines de ms.
I.4.5.4. La perte de donnes

La transmission de la voix par paquets sappuie sur le protocole RTP (Real-Time Transport Protocol). Ce dernier permet de transmettre sur IP les paquets de voix en reconstituant les informations mme si la couche de transport change l'ordre des paquets. Il utilise pour cela des numros de squence et sappuie sur UDP. Les contraintes temps rel de dlai de transit voques plus haut rendent inutile la retransmission des paquets perdus : mme retransmis un datagramme RTP arriverait bien trop tard pour tre dune quelconque utilit dans le processus de reconstitution de la voix. En voix sur IP on ne retransmet donc pas les donnes perdues. Ces pertes de donnes VoIP sont dues aux congestions sur le rseau, qui entranent des rejets de paquets tout au long du rseau, ou une gigue excessive qui va provoquer des rejets de paquet dans les buffers de gigue du rcepteur, ceux-ci ne pouvant pas accueillir tous les paquets arrivs en retard. Une perte de donnes rgulire mais faible est moins gnante en voix sur IP que des pics de perte de paquets espacs mais levs. En effet lcoute humaine shabituera une qualit moyenne mais constante et en revanche supportera peu de soudaines dgradations de la QoS. Le taux de perte en VoIP est typiquement de quelques pourcents ou diximes de pourcent.
I.4.6. Les dfauts de la communication IP

Il nest pas facile de transformer un rseau dchange de donnes en une architecture de transmission synchrone, dbit constant, pour les applications critiques telle que la tlphonie. La qualit de service reste donc la question centrale de la voix sur IP. Les principaux dfauts de la transmission IP sont :
Le dlai : le dlai doit rester infrieur 400 ms aller-retour pour satisfaire les critres
dinteractivit dune communication tlphonique.
La gigue : cest la variation de dlai, ce dernier pourrait tre constant ce qui prserve la
synchronisation du signal entre lmetteur et le rcepteur ou variable ce qui dtruit la base de temps du signal et oblige le destinateur de maintenir une mmoire tampon de resynchronisation.
SupCom 2006/2007
18

Les pertes de paquets : elles sont chroniques et font partie de la transmission IP. Elles
sont nombreuses au moment de la congestion.
La qualit sonore : le phnomne dcho devient gnant lorsque le temps daller retour
du signal dpasse 40 ou 50 ms.
La fiabilit des quipements : lindustrie des tlcommunications est habitue une

fiabilit de cinq chiffres 99,999% tandis que celle du rseau des donnes est 80%.
I.5. Conclusion
Il ressort de notre premire tude quau niveau de la couche Contrle, les principales incertitudes concernent le choix des protocoles. En effet, pour chaque domaine concern, deux ou plusieurs protocoles sont en gnral en lice, lun plus ancien et plus proche de lhritage tlphonie, et lautre plus rcent et plutt hrit du monde Internet. Cette situation soulve immanquablement la question de linteroprabilit court/moyen terme entre solutions implmentant des protocoles diffrents. Quant la VoIP le principal challenge pour un tel service est de satisfaire les besoins des utilisateurs. Ces derniers sont en effet habitus la qualit de service dlivre par les systmes tlphoniques traditionnels et accepteraient difficilement une solution, mme conomique, prsentant une dgradation sensible de cette qualit de service. Dans ce premier chapitre, nous avons prsent les protocoles de signalisation ainsi que la notion de la VoIP dune faon gnral, le chapitre suivant fera lobjet dune description dtaill des diffrents protocoles de contrle dappel, de leurs architectures et de leurs spcificits, ainsi que la reprsentation de notion dapplication vocale et de principe de langage VoiceXML.
SupCom 2006/2007
19
Chapitre II : Les protocoles de signalisation de VoIP et le langage VoiceXML
Chapitre II
Les protocoles de signalisation de VoIP et le langage VoiceXML
SupCom 2006/2007
20
Chapitre II
Les protocoles de signalisation de VoIP et le langage VoiceXML
II.1. Introduction
La signalisation est une des plus importantes fonctions dans linfrastructure des tlcommunications puisquelle permet aux composants du rseau de communiquer entre eux pour tablir et terminer des appels. La voix sur IP, par exemple, dont le but est dtablir des canaux de communication vocaux entre utilisateurs, requiert alors lutilisation des protocoles de signalisation pour initier et terminer les appels. Nous nous intressons dans une premire section de ce chapitre ltude de diffrents protocoles spcifiant par une architecture centralise et distribues, ainsi quune tude comparative entre ces diffrents protocoles. La deuxime section fera lobjet de ltude de langage Voice XML et de la notion dapplication vocale.
II.2. Les protocoles de contrle dappel

Le VoIP utilise plusieurs protocoles de contrle dappel pour ltablissement des communications IP ainsi pour la transmission de flux de donnes. Il existe : larchitecture centralise et larchitecture distribue
SupCom 2006/2007
21

II.2.1. Architecture centralise
Ce modle est fort proche de la philosophie des oprateurs de tlcoms traditionnels. Il considre que l'intelligence et les fonctionnalits sont uniquement localises au sein du rseau! Ainsi, les terminaux utilisateurs (tlphones analogiques, GSM, etc.) sont "ignorants" et offrent peu ou pas de fonctionnalits propres. Par exemple, si un abonn dsire faire un transfert inconditionnel d'appels vers un autre poste, c'est au central tlphonique de l'oprateur (ou le PABX priv) qu'incombe cette tche. Dans ce mode de fonctionnement, il sera par exemple impossible pour l'abonn de savoir qui a tent de le joindre sans faire appel son oprateur Les caractristiques d'une telle architecture sont les suivantes: L'intelligence est au sein du rseau. Les terminaux des utilisateurs sont relativement "ignorants". La gestion est centralise. La rservation des ressources et la signalisation des communications sont similaires celle du PSTN. Peu de possibilits de fonctionnalits sur les terminaux utilisateurs. Les relations au sein d'une architecture centralise sont souvent qualifies de "matre/esclave".
Figure II.1 : Intelligence uniquement auprs des "matres" Parmi les protocoles existants pour ce type d'architecture, on retiendra :
II.2.1.1. MGCP- Media Gateway Control Protocol

Dfinit des protocoles de commande de passerelles de conversion de flux multimdia, le protocole MGCP sert lchange de messages de signalisation entre un contrleur de passerelles de mdias et des passerelles rparties dans un rseau IP. Pour l'tablissement et la terminaison
SupCom 2006/2007
22

des sessions, MGCP se sert de signaux et vnements. MGCP met en ouvre un organe central de gestion des appels et s'appuie sur des terminaux simplifis l'extrme. La standardisation de MGCP a t stoppe pour faire place MEGACO/H.248 ((Media Gateway Control Protocol).
Exemple :
Media Gateway Controller
RTC
Media Gateway
Flux PCM 64 Kb/s
IP
Flux RTP
Transformation dune voie tlphonique (RTC) en une voie tlphonique IP. Cest une approche reposant sur la sparation de la logique de contrle des supports multimdia.
II.2.1.2. MEGACO/H.248
Media Gateway Control (Megaco H.248): c'est le fruit d'une collaboration conjointe entre l'ITUT Study Group16 et l'organisme IETF. L'IETF identifie ce protocole comme "MEGACO" alors que l'ITU le rfrence comme l'H.248. Ce protocole est considr comme la nouvelle gnration de MGCP. Cette technologie de signalisation est destine initier les communications entre un Media Gateway (MG: le terminal sans intelligence) et un Media Gateway Controller (MGC: le centre nvralgique de l'intelligence) au travers d'un rseau de donnes IP.
II.2.1.3. Net2Phone
Net2Phone: c'est un vtran (1995) et un leader des outils de tlphonie pour PC. Il utilise une technologie propritaire qui permet de raliser des appels locaux ou internationaux seulement partir d'un ordinateur connect Internet. En effet, seuls sont possibles les appels de PC PC ou d'un PC vers un poste tlphonique traditionnel. Il n'est donc possible de joindre un utilisateur Net2phone qu' partir d'un poste Net2phone. De plus la connexion l'Internet est indispensable.
II.2.1.4. SCCP (Skinny Client Control Protocol)

Skinny Client Control Protocol (SCCP): protocole propritaire dvelopp par CISCO. Ce protocole est utilis pour le CISCO Call Manager et les tlphones IP.
II.2.2. Architecture distribue

Le modle est proche de la philosophie utilise au sein de l'Internet. Dans ce modle, les architectures informatiques sont scindes en de multiples entits afin de dlguer les tches accomplir aux systmes les plus adapts leur ralisation: par exemple le DNS pour la localisation de services. Dans un mode distribu, les terminaux utilisateurs offrent en outre de nombreuses fonctionnalits et services. Ainsi, si un abonn dsire utiliser un service de rejet d'appels slectif, il peut le faire directement via un terminal qui lui est associ, sans intervention d'une tierce partie.
SupCom 2006/2007
23

Les caractristiques d'une telle architecture sont: Intelligence distribue entre les terminaux utilisateurs et les quipements de signalisation disponibles au sein du rseau. Les terminaux sont les tlphones IP, les PC ou les passerelles VoIP. Les systmes sont flexibles et il est ais d'ajouter un nouveau service. Les systmes sont plus complexes. Les relations au sein d'une architecture distribue sont souvent qualifies de "client/serveur".
Figure II.2 : Intelligence partage entre les serveurs et les clients. Parmi les protocoles existants pour ce type d'architecture, on retiendra :
II.2.2.1. Le protocole H.323

Avec le dveloppement du multimdia sur les rseaux, il est devenu ncessaire de crer des protocoles qui supportent ces nouvelles fonctionnalits, telles que la visioconfrence : lenvoi de son et de vido avec un souci de donnes temps rel. Le protocole H.323 est lun deux. Il permet de faire de la visioconfrence sur des rseaux IP. Le standard H.323 a t conu par lITU-T. Il fait partie dune srie de recommandations qui dcrivent des transmissions multimdia mais sur des rseaux diffrents. Il spcifie les composants, protocoles et procdures permettant la mise en place dun service multimdia sur des rseaux paquets commuts sans garantie de bande passante. Ce standard est valable pour
SupCom 2006/2007
24

VoIP car il permet de transmettre uniquement la voix ou un mlange de voix et de donnes. Il est constitu par un ensemble de protocoles permettant des communications entre plusieurs entits du rseau. Ces entits sont les Gateways, Gatekeeper, les terminaux et les units de contrle multipoint MCU. La figure suivante montre un rseau dot dquipements bass sur le modle H.323. Nous allons dcrire par la suite le rle de chacun de ces quipements [6], [7].
Figure II.3 : Topologie d'un rseau VoIP H.323 II.2.2.1.1. Les diffrents composants de H.323 H.323 est un protocole de communication englobant un ensemble de normes et composants utiliss pour lenvoi de donnes audio et vido sur Internet et parmi ces composants on retiendra :
Les terminaux H.323

Les terminaux sont des clients dans un rseau H.323. Ce sont des systmes daudio (Tlphone IP, PC) ou de vido confrence utiliss pour communiquer en temps rel. Le standard H.323 requiert que chaque terminal supporte un certain nombre de fonctions (voir Figure II.4) et de codeurs qui ont t dfinis par lITU, tels que H.225, H.245, Q.931, RAS (Registration/Admission/Status) et RTP/RTCP (Real Time Protocol/Control Protocol). Les terminaux H.323 peuvent aussi avoir des fonctionnalits supplmentaires, tels que des codeurs audio/vido, le protocole T.120 pour la data-confrence et des fonctionnalits de qualit de service. Cependant, la multiplicit des options rend difficile linteroprabilit des diffrents terminaux H.323.
Les passerelles (GW : Gateway)

La passerelle ou Gateway gre linterconnexion entre le rseau IP et le rseau tlphonique classique ; elle fournit une traduction entre des formats de transmission aussi bien de signalisation que de flux multimdia. Le Gateway tablit et termine les appels aussi bien du ct du rseau IP que du ct du rseau tlphonique. Elle peut aussi effectuer le transcodage entre
SupCom 2006/2007
25

les formats audio, vido ou data. Une passerelle possde les mmes fonctionnalits quun terminal H.323 sur le rseau IP, et aussi celles dun terminal tlphonique sur le rseau de tlphonie.
Figure II.4 : Diagramme fonctionnel dune passerelle
Les portiers (GK : Gatekeeper)

Le Gatekeeper, qui est un quipement optionnel dans un systme H.323, fournit un service de contrle dappel pour les terminaux H.323. Plusieurs Gatekeepers peuvent tre prsents sur un rseau et communiquer les uns avec les autres. Le Gatekeeper est spar des autres terminaux, cependant il peut tre physiquement implment avec un terminal, un Gateway ou un autre lment du rseau non-H323.
Figure II.5 : Diagramme fonctionnel dun Gatekeeper
SupCom 2006/2007
26

Le Gatekeeper fournit les services suivants : Traduction dadresse : Le Gatekeeper fait la traduction de lalias H.323 en une adresse de transport (adresse IP + port) Cela est effectu grce une table qui est rafrachie par les messages denregistrement (Registration message). Contrle dadmission : Le Gatekeeper autorise laccs au rseau par les messages H.225 (ARQ/ACF/ARJ). Ce contrle peut tre bas sur lautorisation dappel, la bande passante disponible ou dautres critres fixs par ladministrateur. Gestion de zone : Le Gatekeeper doit garantir tous les services dcrits prcdemment pour les terminaux enregistrs. Contrle de bande passante: Le Gatekeeper peut refuser ltablissement dun appel pour cause de limitation de bande passante. Signalisation de contrle dappel: Le Gatekeeper peut choisir de faire la signalisation dappel avec le terminal par lui-mme ou de rediriger le terminal pour quil tablisse un canal de signalisation directement avec lautre terminal. De cette faon, cela permet dviter au Gatekeeper de grer les appels H.225. Autorisation dappel: Par lintermdiaire de la signalisation H.225, le Gatekeeper peut accepter ou refuser une demande dappel mise par un terminal. Gestion des appels: Le Gatekeeper peut recenser les appels en cours dans la zone quil gre et connatre ltat dans lequel les diffrents appels se trouvent.
Les units de contrle multipoints (MCU)

Le Multipoint Controller Unit gre les connexions multipoint (ex : appels de confrence). Il se dcompose en un Multipoint Controller (MC), affect la signalisation, et un Multipoint Processor (MP), ddi la transmission proprement dite.
Figure II.6 : Diagramme fonctionnel dune MCU
SupCom 2006/2007
27

II.2.2.2. Le protocole SIP (Session Initial Protocol)
Le protocole SIP (session initial Protocol) est dvelopp par le groupe MMUSIC (Multiparty Multimedia Session Control) : Ensemble de standards dvelopps pour le support de confrences Internet multimdia faiblement contrles pour ltablissement et la supervision de confrences multimdia, peut tre compar un protocole dtablissement dappel, il permet dassocier des supports audio, vido et de donnes une session multimdia. Le protocole SIP (normalis par lIETF, R.F.C 2543) est un protocole de signalisation appartenant la couche application du modle OSI et il est apparent au protocole HTTP. Son rle est douvrir, modifier et librer les sessions. Louverture de ces sessions permet de raliser de laudio ou vidoconfrence, de lenseignement distance, de la voix (tlphonie) et de la diffusion multimdia sur IP essentiellement. SIP est rapidement apparu comme une alternative H.323. SIP est indpendant du protocole de transport utilis. Il utilise le protocole SDP (Session Description Protocol) pour la description des communications mdia. II.2.2.2.1. Topologie de protocole SIP L'architecture de SIP est base sur des relations client/serveur. Il spcifie plusieurs entits du rseau sur lequel il opre. Ces principales entits sont : les terminaux (User Agent), les serveurs Proxy SIP, les serveurs de redirection, les serveurs denregistrement, les passerelles. Les serveurs SIP intermdiaires peuvent se comporter comme Proxy serveur ou serveur de redirection.
Serveur de re-direction
Proxy SIP
SIP
Serveur denregistrement
Serveur de localisation
PSTN/ou Mobile
Clients SIP Passerelle SIP
Figure II.7 : Topologie d'un rseau VoIP SIP
SupCom 2006/2007
28

Les terminaux
Les terminaux sont donc des appareils pouvant mettre et recevoir de la signalisation SIP. On distingue essentiellement deux types de terminaux : les tlphones ou les PC quips dun logiciel adquat, dune carte son, dun microphone, etc. Un terminal SIP doit disposer dun agent qui devient client lorsquil met des requtes et reoit des rponses (UAC User Agent Client) et par consquent son partenaire devient serveur (UAS User Agent Serveur) puisquil rpond ces requtes. Les terminaux peuvent communiquer directement entre eux ou par l'intermdiaire d'autres serveurs.
Les serveurs Proxy SIP

Le serveur Proxy joue le rle de serveur dun ct (rception de requte) et de client de lautre (envoi de requte). Un serveur Proxy peut transmettre une requte, sans changement, la destination finale ou ventuellement modifier certains paramtres. Il renseigne le champ via chaque fois quune requte passe par lui afin que la rponse puisse prendre le mme chemin au retour ; ce qui ne serait pas possible avec le protocole UDP. Le Proxy peut aussi dans certains cas tre charg deffectuer dautres tches telles que lauthentification, lautorisation, la gestion des taxes, etc.
Figure II.8 : Proxy SIP Alors le Proxy SIP reoit une requte SIP, modifie son entte, la transmet au Proxy suivant ou lagent final. Il permet lacheminement des messages SIP. Existe en version stateful et stateless suivant quil garde ou non des informations au cours des sessions.
Les serveurs de redirection

Un serveur de redirection rpond une requte SIP Invite . Il tablit la correspondance entre ladresse SIP du terminal appel et la ou les adresses o il pourra effectivement tre joignable. Le serveur redirection nest pas charg daccepter les appels ni dmettre des requtes. Il ne fait que rpondre aux requtes mises par des terminaux SIP appelants.
SupCom 2006/2007
29

Cest un serveur ralisant une association dadresses vers une ou plusieurs nouvelles adresses. Un Redirect Server est consult par lUAC comme un simple serveur et ne peut mettre de requtes contrairement au Proxy Server.
Les serveurs denregistrement

Un serveur denregistrement ou registrar est un serveur qui traite les requtes Register et peut aussi avoir la fonction de Proxy. Sa fonction est de connatre lendroit o se trouve un usager et de fournir cette information au Proxy et au serveur de redirection. En effet pour pouvoir joindre un usager partir dune adresse SIP, il faut faire une correspondance avec une adresse IP qui peut tre variable (mobilit IP) : cest le rle du registrar.
Les serveurs de localisation (LS)

Il fournit la position courante des utilisateurs dont la communication traverse les RS et PS auxquels il est rattach : cette fonction est assure par le service de localisation. II.2.2.2.2. Les messages SIP II.2.2.2.2.1. Les requtes de base SIP Les requtes de base SIP appels encore mthodes , sont au nombre de six. Ces requtes de base permettent de localiser, dadresser un lment du rseau et lui transmettre les informations de signalisation : Invite : Ce message est une demande dtablissement de liaison. Le type de session, ladresse IP, le port, et le type du codec sont inscrits dans le corps du message. Lenvoi dun message invite durant une session existante donne lieu une rinvitation et est utilis pour la modification des paramtres de la session actuelle. ACK : Termine la demande de liaison (invite) il est uniquement utilis pour ceci. Si lors de la demande de liaison le corps du message invite ne contient pas les informations sur le type mdias, alors le ACK devra les contenir. Options : Demande un autre agent ces comptabilits, la rponse contiendra la liste des mthodes quil supporte, ces codecs etc. Lagent questionn rpondra ce message comme sil sagissait dune invite. Bye : Termine une communication, lagent stop lenvoi de paquets de type media (RTP). Cancel : Termine une communication en cour dtablissement. Register : Permet un agent de senregistrer ou de mettre jour sa localisation et sont URL auprs dun serveur denregistrement, celui-ci pourra son tour mettre jour le serveur de localisation, ces donnes seront utilises pour la redirection des communications. II.2.2.2.2.2. Les autres requtes SIP Afin dtendre les possibilits de SIP des nouvelles mthodes ont t ajoute, actuellement on peut en compter 8 mais il est vraisemblable que cette liste va sagrandir au fil du temps : Info : Est utilis pour transmettre de la signalisation, exemple signaux en provenance du Gateway PSTN.
SupCom 2006/2007
30

Refer : Permet un agent de demander un autre agent dexcuter une requte particulire. Prack : Ce message et une confirmation un message de rponse temporaire. Comet : Est utilis pour annoncer un agent quil doit avertir lutilisateur que certaines conditions (ex. QoS etc.) ont t runies. Subscribe : Permet de sinscrire de faons tre inform lors de lexcution dun vnement donn. Unsubscribe : Annule une inscription pralable. Notify : Est utilis pour informer les utilisateurs inscrits que un vnement a eu lieu. Message : Permet lenvoi dun message vers un utilisateur, le message qui peut tre de type HTML, texte ou autre est transport dans le corps du message.
II.3. Avantages et Inconvnients H323, SIP et MGCP

Avantages Simple mettre en uvre, messages crits en clair Interoprabilit trs bonne Grce CPL (Call Processing Language) qui utilise XML, il est trs facile dajouter des services intelligents de redirection Trs bonne possibilit de gestion de la mobilit Utilis pour la tlphonie 3G (UMTS) Maturit du protocole: Actuellement version 4 pour la dfinition. Les premires mises en uvre de V3 commencent juste apparatre Beaucoup de constructeurs utilisent H.323 Peut supporter autre chose que IP, existe aussi sur ATM Inconvnients Pas encore de grande rfrence Service supplmentaire de tlphonie inexistant En pleine maturation
SIP
H323
Protocole trs complexe, manque dinter-oprabilit Difficults avec les Firewall Support des fonctions avances de la tlphonie. Pas dans lesprit Internet
MGCP
Permet dutiliser des tlphones idiots Indpendant des protocoles de signalisation suprieurs (H.323, SIP) Bien pour les oprateurs voulant faire du RTC-IP-RTC
Pas encore de grande rfrence Service supplmentaire de tlphonie inexistant En pleine maturation
Tableau II.1 : Avantages et inconvnients des protocoles de signalisations de VoIP [8].
SupCom 2006/2007
31
Chapitre II : Les protocoles de signalisation de VoIP et le langage VoiceXML II.4. VoiceXML et application vocale
La notion d' application vocale couvre une zone plus vaste dans l'ensemble des applications informatiques. Nous dfinissons une application vocale comme une application informatique utilisant la parole pour raliser/accomplir certaines tches. Dans ce type d'applications, l'utilisateur peut dialoguer avec l'application en utilisant seulement les mots cls, une phrase courte et simple, ou toute la complexit de la langue Nous prsentons dans cette section, tout dabord, la notion de VoiceXML, ses avantages, ainsi que ses inconvnients. Nous donnons, en conclusion, des remarques importantes qui nous motivent pour faire plus de recherches portant sur le systme de dialogue.
II.4.1. Introduction
VoiceXML est le nom d'une norme de technologie propose initialement par le forum de VoiceXML [9]. Elle est base sur des veilles technologies telles que VoXML de Motorola et de SpeechML d'IBM, pour crer une nouvelle faon dinteragir avec des applications via une interface vocale, en apportant les avantages de dveloppement du WEB aux applications interactives par la parole. La premire version de VoiceXML a t labore par AT&T, Lucent Technologies, Motorola, et IBM et approuve par le W3C en mars 2000. La deuxime version est galement apparue avec laide des membres du groupe Voice Browser du W3C [10]. Au point de vue technique, VoiceXML est considr comme un langage qui permet dintgrer aisment la tlphonie et lInternet. Il s'agit d'un interprteur (browser) vocal de pages dans une forme drive du XML. Un interprteur de ce type possde une connexion au rseau tlphonique d'un ct, une connexion au rseau Internet de lautre, des ressources technologiques et un algorithme pour traiter les pages et interagir avec l'utilisateur. Les ressources technologiques couvrent la majorit de technologies vocales, savoir la synthse de la parole, la reconnaissance de la parole et l'annulation d'cho. Lobjectif principal de VoiceXML est premirement dapporter tous les avantages de dveloppement de services Web des systmes dapplication utilisant la parole pour interagir, et deuximement de permettre au dveloppeur de programmer et de grer des ressources au haut niveau. De plus, VoiceXML vise satisfaire les besoins suivants : Minimiser les interactions client/serveur en prcisant plusieurs interactions par document. Sparer le code dinteraction dutilisateur (VoiceXML) de la logique (scripts CGI Common Gateway Interface). Favoriser la portabilit de service travers des plates-formes dimplmentation. VoiceXML est un langage commun pour les fournisseurs de contenu, les fournisseurs d'outil, et les fournisseurs de plates-formes. Etre facile utiliser pour des interactions simples, mais fournir des possibilits pour supporter des dialogues complexes. Les documents VoiceXML couvrent donc les lments suivants : sortie pour la synthse de la parole TTS (Text To Speech), sortie des fichiers sonores, reconnaissance d'entre parle, reconnaissance d'entre DTMF, enregistrement d'entre parle, contrle de dialogue et caractristiques de tlphonie tels que le transfert et la dconnexion d'appel.
SupCom 2006/2007
32

II.4.2. Prsentation de VoiceXML
VoiceXML et HTML sont des langages balise (Markup Language). Mais quand un document Html est interprt par un "Web Browser" (Internet Explorer, Firefox, ) pour formater le contenu prsent sur votre ordinateur, VoiceXML est lui interprt par un "Voice Brower" pour formater le contenu prsent sur votre tlphone.
Lobjectif initial du langage VoiceXML est de permettre aux personnes disposant dun simple tlphone daccder sous forme vocale aux contenus et services du Web ainsi quaux systmes dinformations des entreprises.
VoiceXML est un langage de programmation des interactions vocales homme-machine s'appuyant sur l'architecture et les applications du Web. Les principales fonctionnalits de ce langage sont : La diffusion de fichiers audio. La diffusion de parole synthtise (synthse vocale). La dtection de codes DTMF gnrs par les touches du clavier du tlphone. La dtection de mots ou expressions prononcs par l'utilisateur (reconnaissance vocale). Lenregistrement de la parole de lutilisateur. Le contrle de lappel tlphonique (transfert de lappel, dconnexion de lappel).
II.4.3. Dfinition
VoiceXML est un langage de programmation prenne et portable, normalis par le World Wide Web Consortium (W3C). Il sert dvelopper des services de communication interactifs, convergents avec Internet. Il permet d'laborer un scnario d'accueil de l'appelant en intgrant de multiples possibilits : jeu d'un message prenregistr, reconnaissance des touches tapes sur le clavier tlphonique (DTMF, ou Dual tone multiple frequency) pour conditionner une interaction, enregistrement d'un message et transmission par e-mail, emploi de la reconnaissance et de la synthse vocales, gestion de plusieurs canaux (e-mail, SMS, fax et Web), traitement des appels entrants ou sortants, transfert d'appel, etc.
SupCom 2006/2007
33

II.4.4. Concept de base
La technologie VoiceXML apporte les fonctionnalits suivantes : cration et gestion de dialogues vocaux utilisant des voix synthtises, des sons numriss, de la reconnaissance de la parole et des sons DTMF. La ralisation de cet exploit passe par une plate-forme interface vocale du W3C. Cette plateforme VoiceXML est compose de plusieurs lments qui sont : VoiceXML pour les interactions entre une application et un utilisateur. Le langage de synthse vocale (SSML) utilis pour gnrer des annonces vocales synthtiques. La grammaire de reconnaissance de la parole (SRGS) qui guide la reconnaissance en utilisant la description des rponses possibles de l'utilisateur. Le contrle d'appel du navigateur vocal (Voice Browser CCXML) qui gre les appels tlphoniques. L'interprtation smantique pour la reconnaissance de la parole (SISR) qui dfinit la syntaxe et la smantique des balises.
II.4.5. Caractristiques II.4.5.1. Modle darchitecture

Le modle darchitecture dune application vocale, dveloppe en se fondant sur la norme VoiceXML, est illustr par la figure II.9 :
Utilisateur
Rseaux tlphoniques
Infrastructure de tlphone Reconnaissance de la parole Plate-forme dimplmentation Synthse de la parole
Interprte de VoiceXML Application Figure II.9 : Modle darchitecture de VoiceXML
SupCom 2006/2007
34

Dans ce modle, la plate-forme dimplmentation a pour but de fournir les primitives ddies aux vnements concernant les actions la fois dutilisateur et de systme. Elle se compose une infrastructure de tlphonie pour capturer et diffuser les appels tlphoniques, un module de reconnaissance automatique de la parole (ASR Automatic Speech Recognizer), et un module de synthse de la parole (TTS Text To Speech). L'interprte de VoiceXML doit traduire les vnements spcifiant dans les documents VoiceXML produits par une application en des actions concrtes sur le monde. Linterprte de VoiceXML doit galement assurer la coordination de ces actions.
II.4.5.2. Avantages
La norme VoiceXML prsente les avantages suivants : Rutilisation de qualifications : les dveloppeurs base des technologies de Web saccordent pour dire que VoiceXML est facile apprendre, en raison de sa similitude avec d'autres langages de Markup tels que HTML. Leurs comptences, par exemple pour la gnration dynamique du contenu, pourront tre rutilises afin de dvelopper des applications vocales. Facilit de construction : pour une application vocale simple, sa conception ainsi que son dveloppement peuvent tre facilement effectus en se fondant sur des environnements dvelopps de VoiceXML. La raison de cette facilit rside aux objectifs poss de cette norme. Portabilit : les applications dveloppes en VoiceXML peuvent fonctionner sur une grande varit de plates-formes et peuvent migrer facilement.
II.4.5.3. Inconvnients
Les applications base de la norme VoiceXML ne sont appropries que dans les cas o les utilisateurs savent ce qu'ils veulent. L'information qu'ils coutent est courte et au point, c'est-dire qu'elle est seulement constitue de mots cls ou de phrases simples. Cela est donc un grand inconvnient pour lutilisateur quand il veut exprimer ses demandes par des longues phrases telle application. De plus, le dialogue, entre lutilisateur et lapplication, nest constitu que par des questions/rponses, dans lesquelles lapplication garde toujours sa propre initiative. VoiceXML est conu principalement pour fonctionner avec le tlphone, qui est le dispositif de transmission le plus omniprsent. Nanmoins, les limitations, imposes par le tlphone comme un niveau sonore faible, un taux de bruit lev, etc., amnent de la faiblesse au module de reconnaissance automatique de la parole, qui peut tre prdfini et fix dans lenvironnement dexploitation de cette norme.
II.4.6. Systmes de dialogue oral homme-machine II.4.6.1. Principes gnraux

Un systme de dialogue oral homme-machine (dsormais SDHM, ou par simplicit, systme de dialogue) est un systme informatique qui est capable dinteragir naturellement (cest--dire dune faon qui semble naturelle lhomme, principalement en langue naturelle) avec lutilisateur principal via des modalits dinteraction vocale pour accomplir une tche concrte. Evidemment, un systme de dialogue est une application vocale mais elle doit tre capable de comprendre non seulement les mots cls, mais galement des phrases compltes, c'est--dire que l'utilisateur peut vraiment dialoguer avec elle.
SupCom 2006/2007
35

Un SDHM doit se comporter en respectant bien les trois processus principaux : perception, action et cognition. La perception est bien videmment traduite au cours de reconnaissance automatique de la parole et de comprhension des noncs de lutilisateur. Tout ce que le systme peut comprendre par sa propre manire formelle conduit directement laction du systme dans son propre monde. Evidemment, laction du systme peut satisfaire ou non les souhaits de lutilisateur et donc le processus de cognition est exig afin dassurer une satisfaction maximale si possible. Les composants minimaux dun SDHM doivent se charger des tches comme la reconnaissance, la synthse de la parole, la comprhension, la coordination des tours de parole ou bien le contrle de dialogue et la manipulation de tches lmentaires ou bien le contrle de tche. Nous dtaillons maintenant ces composants dans la section suivante dcrite larchitecture gnrale dun SDHM.
II.4.6.2. Architecture gnrale

En utilisant les principes abords la section prcdente, nous proposons une architecture gnrique ddie au systme de dialogue, illustre par la figure II.10 :
nonc oral
nonc oral
Reconnaissance de la parole
Synthtiseur de la parole
Chane orthographique Comprhension smantique Schma smantique Interprteur pragmatique Actes Contrleur de la tache Action sur Gnrateur le monde
Contrleur de dialogue
Figure II.10 : Architecture gnrale dun systme de DHM L'objectif principal de notre architecture est de sparer le plus nettement possible les composants dun SDHM, afin que nous puissions les manipuler aisment. En gnral, nous visons
SupCom 2006/2007
36

effectivement deux caractristiques principales : distribu et modulaire. Chaque composant doit tre modulaire pour que des changements dun des autres ne laffectent pas. Pour la mme raison, ils sont distribus en tirant profit de la puissance de plusieurs machines diffrentes. Les dfis du systme de dialogue oral homme-machine prsent dans la section suivante sont considrs en donnant cette architecture des facilits de mise en oeuvre. Notre architecture se compose de sept modules diffrents. Nous abordons maintenant ces modules en dtail : II.4.6.2.1. Reconnaissance automatique de la parole Les signaux sonores que lutilisateur prononce arrivent au systme et sont capturs par des interfaces spciales (une carte tlphonique, une carte de son). Ces signaux sont transmis au module de reconnaissance automatique de la parole afin de les convertir en une chane de caractres de confiance. Cette chane orthographique est transmise immdiatement au module de comprhension smantique. Normalement, le module de reconnaissance de la parole peut retourner une liste de n meilleures chanes orthographiques qui reprsentent les meilleures candidates reconnues par ordre de ses scores de confiance. Le score de confiance est calcul directement partir des scores acoustiques de chaque mot dans la chane de rsultat et caractrise donc cette chane. Au niveau le plus bas, le score acoustique dun mot est effectivement mesur partir du score de phonme.
Modlisation de langage
Parole
Acquisition et modlisation du signal
n-candidats Reconnaissance acoustique
Figure II.11 : Description dun module de reconnaissance de la parole Un module de reconnaissance se compose normalement de trois composants principaux illustrs ci-dessus Le premier est pour acqurir le signal sonore de lnonc de lutilisateur et le modliser sous une forme gnralement frquentielle en gardant des paramtres pertinents. Ces paramtres sont utiliss dans le composant de reconnaissance acoustique qui identifie les sons prsents dans le signal. La reconnaissance acoustique est effectue en utilisant normalement la modlisation par modles de Markov cachs [11] concernant des phonmes, diphones, syllabes, etc. Il est ensuite ncessaire de mettre en correspondance une suite dlments acoustiques avec une forme lexicale en utilisant le composant de modlisation de langage. Il permet donc de spcifier le positionnement d'un mot dans lnonc de lutilisateur par diffrentes techniques de modlisation base soit de grammaire, soit de statistique, soit la combinaison des deux [12]. Selon la demande de chaque application, le rsultat obtenu peut tre soit une chane textuelle, soit une liste des n meilleures chanes textuelles.
SupCom 2006/2007
37

En ce qui concerne la dpendance lutilisateur, actuellement, il existe plusieurs moteurs de reconnaissance ayant un modle acoustique dj adapt aux utilisateurs, lenvironnement, au canal de communication. Cela apporte donc lindpendance du locuteur lapplication vocale. II.4.6.2.2 Comprhension smantique Le module de comprhension smantique a la charge de caractriser la chane de caractres envoys par le module de reconnaissance de la parole. Il doit lanalyser pour produire un schma smantique qui symbolise ce que lutilisateur vient de prononcer au systme. Comme pour un humain, il est certain quil y aura des erreurs ce niveau l : le systme (ce module) ne peut tout comprendre ou peut les comprendre de manire diffrente La comprhension doit tre effectivement effectue par lanalyse syntaxique et smantique. Lanalyse syntaxique est base de grammaire formelle, de grammaire transformationnelle, ou de grammaire en chane Plusieurs approches diffrentes sont galement utilises au cours des analyses smantiques comme grammaire smantique [13], grammaire de cas [14], grammaire fonctionnelle [15] II.4.6.2.3 Interprteur pragmatique Le schma smantique sorti du module de comprhension arrive ensuite dans un central qui coordonne les modules principaux du systme : interprtation, contrleur du dialogue et contrleur de la tche. Ces trois modules peuvent mutuellement interagir afin dobtenir des donnes ncessaires pour laction. Le central transfre tout dabord le schma smantique au module dInterprteur pragmatique et attend des actes de dialogue en rponse. Ce module doit rsoudre des problmes concernant la rfrence (noms propres, expressions de dsignation, anaphores, dictiques, etc.), les prsuppositions et les implicatives conventionnellesen se fondant sur des connaissances de lhistorique (acquises par les tours prcdents de parole), des rfrents de contexte obtenus en interagissant avec le contrleur de la tche. Le central retrouve la sortie de ce module des actes de dialogue qui sont ensuite pris et traits par le module de contrleur du dialogue. II.4.6.2.4 Contrleur du dialogue Le contrleur du dialogue assure effectivement un rle important dans un systme de DHM : Coordonner toutes les interactions entre lutilisateur et le systme. Assurer lavancement, la cohrence de dialogue. Etre le pont qui relie la parole et laction relle dans le monde. En effet, lacte de dialogue sorti du module dinterprteur pragmatique est analys et trait par le contrleur du dialogue. En sappuyant sur les tours prcdents de la parole, il doit dterminer le but souhait par lutilisateur. Afin de bien conduire le dialogue au but pos, il doit galement calculer la stratgie applique pour gnrer lacte (laction et de mme, la rponse) du systme. A la sortie de ce module, on trouvera lacte de dialogue du systme et des donnes supplmentaires qui sont tous transfrs au module de gnration. Bien videmment, des interactions ncessaires au contrleur de la tche peuvent tre invoques au cours de ces calculs pour quil puisse avoir suffisamment de connaissances cibles sur laction du systme. II.4.6.2.5 Contrleur de la tche Le contrleur de la tche est un module concernant purement lapplication relle. Il doit reprsenter des tches, des services viss par le systme. Au point de vue de la conception logicielle, nous considrons ce module comme une application relle enrichie par les interfaces
SupCom 2006/2007
38

ente cette application et les composants du systme de dialogue. Toutes les actions, vises par le systme, doivent tre traites dans ce module. Il contient donc des objets, des donnes, des connaissances indispensables au systme vis. Toutes ces informations sont servies dautres modules en cas de ncessit via des commandes du central. II.4.6.2.6 Gnrateur textuel Lacte de dialogue, gnr par le contrleur du dialogue, est pris par le module de gnration textuelle. Ici, il traduit cet acte en une chane de caractres et/ou des actions concrtes qui y sont cods. Bien videmment, la gnration peut avoir besoin des donnes supplmentaires comme le but souhait par lutilisateur, la stratgie de dialogue, des donnes dtailles stockes dans le contrleur de la tche La chane de caractres est ensuite transfre au module de la synthse de la parole. II.4.6.2.7 Synthtiseur de la parole Ce module neffectue que la conversion dune chane de caractres en des signaux sonores reprsentant sa prononciation. La synthse de la parole est alors dfinie comme la production automatique de la parole, grce soit une transcription graphme-phonme des phrases lire, soit la concatnation des morceaux prenregistrs. Les signaux sonores de sortie seront conduits vers les dispositifs viss par le systme de dialogue, par exemple les haut-parleurs, le tlphone, etc.
II.4.6.3. Dfis dun systme de dialogue

Avec une telle architecture du systme de dialogue oral homme-machine, les dfis sont: exactitude, fiabilit, flexibilit, adaptabilit, extensibilit et gnricit. Lexactitude est une exigence trs importante envers le systme de dialogue oral homme machine. Elle est manifeste par la cohrence entre un tour de parole (la rponse de la machine. Elle est manifeste par la cohrence entre un tour de parole (la rponse de la machine doit tre adquate par rapport la question pose par lutilisateur) ainsi que la cohrence dans tout le dialogue. Cela demande donc lexactitude de tous les modules dans le systme : le module de reconnaissance doit bien produire le texte de lnonc de lutilisateur, la comprhension est obligatoirement assure avec dexcellents rsultats, linterprtation doit rsoudre tous les problmes pragmatiques Nous esprons donc que, dans un temps proche, avec des progrs dans tous les domaines concerns, toutes ces exigences pourront tre satisfaites. La fiabilit rside dans le contrleur de la tche si lon ne compte que les donnes au niveau de lapplication. La flexibilit doit tre exige principalement des modules de comprhension et de synthtiseur. De plus, le systme doit sadapter non seulement aux utilisateurs, leurs exigences, mais galement au contexte diffrent (environnement, langue, etc.) et ladaptabilit est donc une exigence envisager dans tous les modules du systme. Une autre exigence quon ne peut ignorer est lextensibilit. Ce dfi nest pas encore respect dans la plupart des systmes actuels de dialogue qui sont ddis seulement des tches prdfinies. Les deux modules qui peuvent raliser un tel dfi sont videmment linterprtation et le contrleur du dialogue sils sont gnriques.
SupCom 2006/2007
39

Le dernier dfi qui peut tre considr comme la synthse de tous les dfis prcdents : la gnricit. En effet, tous les modules dans un systme de dialogue doivent tre envisags sous langle de gnricit afin dassurer les exigences mentionnes au dessus.
II.5. Conclusion
Bien que les protocoles H.323 et SIP soient issus de contextes trs diffrents, ils tendent tous les deux vers un modle leur permettant dintgrer au mieux les nouveaux outils du monde Internet . Ainsi ces protocoles permettront doffrir une meilleure adaptation de transmission de la voix sur un rseau Best effort . Nous avons essay dans ce chapitre de donner les diffrentes caractristiques des protocoles centralises et distribues tels que H.323 et SIP, ainsi que la reprsentation gnrale de langage VoiceXML et de la notion dapplication vocale. Dans la suite de ce rapport, nous essayerons de reprsenter les diffrents tapes de llaboration de ce projet par une conception objet bien dtaill et aussi lexploitation de ses diffrentes caractristiques des protocoles distribues dj tudis pour dvelopper une application une rponse vocale interactive qui utilise VoiceXML comme langage de dveloppement.
SupCom 2006/2007
40
Chapitre III : Conception Objet de lapplication
Chapitre III
Conception Objet de lapplication
SupCom 2006/2007
41
Chapitre III
Conception objet de lapplication

III.1. Introduction
Dans ce chapitre, une conception de lapplication va tre bien dtaille. Cette conception est faite dune faon globale tout en dtaillant quelques exemples de chaque module dapplication. Pour ce faire, en premier lieu cest le formalisme et la reprsentation de lapplication qui sera voqu et en second lieu, cest ltude thorique par llaboration de quelque diagramme UML qui vont tre implants laide de lAGL : Rational Rose.
III.2. Cadre gnrale de lapplication
Figure III.1 : Serveurs vocaux de nouvelle gnration
SupCom 2006/2007
42

III.2.1. Description
Cette application consiste dvelopper des IVRs (Interactive Voice Response) sur une Plate forme dinterprtation Voice XML (TTS & ASR), les tester distance par lutilisation des Softphones VoIP, ainsi que la comprhension de principe dinterprtation vocale. Le but des ces IVRs est de former un site web sportif informations vocales. Cette Plate forme dinterprtation Voice XML peut tre assemble un serveur Astrisk PBX, ensuite lajout dautres modules est ncessaire pour que linterprtation soit possible. Alors, les diffrents types des clients: PSTN, cellulaires et Internet, peuvent se connecter la Plate forme VoiceXML soit par lintermdiaire dun serveur Astrisk, soit par lutilisation des autres serveurs web, qui sont eux mme connects la Plate forme (voir Figure III.1).
III.2.2. Exemple de fonctionnement dune application VoiceXML

Dans cet exemple, lappelant compose un numro court, ici le 642. Et ainsi le message bonjour est diffus lappelant. Le fonctionnement est le suivant (voir figure ci-dessous): Un client appelle un numro spcifique. Lappel est envoy linterprteur VoiceXML. Une requte est envoye au serveur dapplications. Une rponse en page VXML est envoye au serveur vocal qui va permettre un rendu sonore.
Figure III.2 : Fonctionnement dune application VoiceXML
SupCom 2006/2007
43
Chapitre III : Conception Objet de lapplication III.3. Etude thorique

III.3.1. Formalisme UML
UML propose de dcrire un systme laide de neuf diagrammes. Chacun de ces diagrammes correspond soit la description dune partie du systme soit la description du systme selon un point de vue particulier. La figure suivante propose une reprsentation densemble du positionnement relatif des neuf diagrammes dUML. Cette prsentation des liens peut aussi constituer une aide dans la dmarche dlaboration de ces diagrammes.
Figure III.3 : Positionnement des neuf diagrammes dUML. Avec : Type de diagramme DCU DCL DOB DET DAC DES DCO DCP DDP Spcification diagramme des cas dutilisation diagramme de classes. diagramme dobjets. diagramme tat-transition diagramme dactivits. diagramme de squence. diagramme de collaboration. diagramme de composants. diagramme de dploiement.
SupCom 2006/2007
44

Tableau III.1 : Diagramme UML La conception de lapplication qui nous incombe est limite quatre diagrammes : DCU, DAC, DCO et DES puisquils permettent de mettre en vidence les fonctionnalits implanter.
III.3.1.1. Diagramme des cas dutilisation : DCU

Les cas dutilisation dcrivent le comportement du systme du point de vue utilisateur sous la forme d'actions et de ractions. Un cas d'utilisation indique une fonctionnalit du systme dclenche par un acteur externe au systme. Ce genre de diagramme permet de mettre en place et de comprendre les besoins du client. Dans ce diagramme, interviennent trois lments : les acteurs, le systme et les cas d'utilisation. L'acteur reprsente un rle jou par une personne ou un autre systme qui interagit avec le systme en cours de modlisation. UML reprsente le cas d'utilisation par un ovale.
III.3.1.2. Diagramme de squence : DES

Le diagramme de squence permet dapprhender plus facilement la succession des actions dans le temps et les contraintes temporelles des interactions entre les objets. Un diagramme de squence peut dcrire un paquetage, un cas dutilisation, une classe, une opration ou une instance. Il s'agit de la reprsentation des interactions entre les objets selon un point de vue temporel.
III.3.1.3. Diagramme dactivit : DAC

Un diagramme d'activit ne modlise pas en gnral lexact comportement interne d'un programme (comme le fait le diagramme de squences) mais montre plutt les traitements et les tapes gnraux un haut niveau d'abstraction. Les activits sont gnralement ralises par un ou plusieurs cas d'utilisation : l'activit dcrit le traitement qui doit tre entrepris et le cas d'utilisation la faon dont un acteur utilisera le systme pour accomplir tout ou partie de l'activit.
III.3.1.4. Diagramme de collaboration : DCO

Les diagrammes de collaborations se sont des diagrammes qui montrant les interactions entre objets (instances de classes et acteurs). Ils permettent de reprsenter le contexte d'une interaction, car on peut y prciser les tats des objets qui interagissent.
III.3.2. Identification et Reprsentation des cas dutilisation

Les fonctions du systme sont identifies en recherchant ces cas dutilisation qui seront mis en oeuvre par les diffrents acteurs. (Concernant le site sportif) Vu la diversit des acteurs et des fonctions, ils seront classifis de faon que ceux fonctionnent pour lun des quatre modules suivant : Identification Inscription Choix dquipe Conception de site
SupCom 2006/2007
45

III.3.2.1. Cas dutilisation dinscription
Figure III.4 : Cas dutilisation dinscription
Dans ce cas le client utilisateur doit tre connect une base de donns ensuite le remplissage dun formulaire bien dfini, le client devra connu par certains champs exacts tels que Login , Password
III.3.2.2. Cas dutilisation didentification
Figure III.5 : Cas dutilisation didentification Comme le cas dinscription le client utilisateur doit tre connect une base de donnes pour passer un test daccs un service bien dtermin suite une vrification des certains champs qui a t rempli dans le formulaire dinscription.
III.3.2.3. Choix dquipe

Aprs le test de vrification dun certains champs et que laccs au service a t autoris, le client passe ltape de slection de leur League prfr ainsi que la slection de leurs quipe favorable, mais avant tout il faut faire une slection de leurs propre type de sport adorable parmi les types disponibles sur le site.
SupCom 2006/2007
46
Figure III.6: Cas dutilisation de slection dquipe prfr Handballeuse
FigureIII.7 : Cas dutilisation de slection dquipe prfr Footballeuse
III.3.2.4. Conception de site

Ce cas dutilisation est la gnralisation des autres cas, il englobe toutes les fonctionnalits dj prdfinies comme linscription, lidentification et les slections.
SupCom 2006/2007
47
Figure III.8 : Cas dutilisation de conception de site
III.3.3. Diagramme de collaboration : (Typical Configuration with VoiceXML & SIP)

Ce diagramme dfini les relations entre les trois modules suivants : Signalisation et contrle dappel (ce module quest le responsable de la signalisation et de la ralisation des connexions aux pralables) Interactions voix (dans ce module on trouve lanalyseur de Voice XML ainsi que la pile SIP de signalisation). Affaires et commerce logiques (ce module est un serveur web ou il y a les pages JSP (Java server page) ainsi que les appels des services callback ).
SupCom 2006/2007
48
Signalisation et contrle dappel
Interactions Voix
Affaires et Commerces Logiques Figure III.9 : Diagramme de collaboration Avec RMI : Redman MicroConnections, Inc.
III.3.4. Diagramme dactivit
Start
Inbound call Dial Callee Callee Answers
Please enter phone number you want to reach.
Put caller on hold
Do you want to accept the call?
No Phone is X, correct? Yes Play hold music
Yes Join Caller and Callee
Accepted ?
No Put Caller to Voice Mail
Fin Figure III.10 : Diagramme dactivit
SupCom 2006/2007
49

Ce diagramme dactivit prsente le scnario dtablissement dun appel par un client VoIP, ainsi que les diffrents cas possible au cours de cet appel.
III.3.5. Diagramme de squence III.3.5.1. De lappellent jusqu' lappel

Ce diagramme est la schmatisation de scnario total denchanement dappel VoIP qui utilise SIP comme protocole de communication.
SupCom 2006/2007
50
SupCom 2006/2007
51
Figure III.11 : Diagramme de squence (appellent appel)
III.3.5.2. Demande dinscription
Figure III.12 : Diagramme de squence (inscription) Les conditions de la saisie de Login et de mot de passe sont dfinies dans le formulaire dinscription au dpart.
SupCom 2006/2007
52

III.3.5.3. Cycle dauthentification
Figure III.13 : Diagramme de squence (identification)
Lauthentification est la vrification des quelques champs dj saisis lors de ltape dinscription.
III.3.5.4. Droulement de lapplication : (conception dun site sportif)
Ce diagramme de squence dcrive lenchanement global de fonctionnement de site sportif, lauthentification, laccs au service, le choix des types dinfos couter, laccs au client VoIP tel que (X-Lite, Skype ou FWD), la numrotation..
SupCom 2006/2007
53
Figure III.14 : Diagramme de squence (conception de site)
SupCom 2006/2007
54
III.4. Conclusion
Nous avons prsent dans ce chapitre une vue globale, gnrale sur lapplication ralis qui va tre trait dans le chapitre suivant, la formulation thorique a t lieu par la prsentation et la dtermination de quelques diagramme UML qui sont raliser par Rationel Rose. Nous abordons par la suite le dernier chapitre ou il y a la ralisation de notre application, lexplication et la mise en uvre de point de vue exprimentale.
SupCom 2006/2007
55
Chapitre IV : Ralisation
Chapitre IV
Ralisation
SupCom 2006/2007
56
Chapitre IV
Ralisation
IV.1. Introduction
Dans ce chapitre, nous abordons en premier lieu, la prsentation de la Plate forme Voxeo, ainsi que son utilisation comme un outil de dveloppement des applications vocales, comment raliser une application VoiceXML? , comment le tester ? En deuxime point, nous expliquons les diffrentes tapes ainsi que la mthode des ralisations des IVRs sur lAsterisk PBX, la configuration des diffrents modules et fichiers, leur relation avec VoiceXML aussi que leurs rponses un appel SIP entrant. Et en dernier point, nous dcrivons la ralisation dun site sportif (raliser moyennant Voxeo) dont le but est de fournir des informations vocales sportives aux clients par lutilisation des numros spcifiques qui ont des relations directes avec des soft phones tels que X-Lite (SIP VoIP), Skype VoIP, FWD VoIP
IV.2. Plate forme Voxeo pour VoiceXML

Cest une Plate forme libre (Free) sur le web sous le site suivant : http://community.voxeo.com
IV.2.1. Vue global sur Voxeo

Les principales caractristiques fournies par Voxeo sont : Rponse interactive et identifications de voix. Voxeo fournit une plate-forme gratuite de dveloppement avec ressources et appui technique. Accs aux applications via le logiciel FreeWorldDialup (FWD), Skype ou SIP VoIP.
SupCom 2006/2007
57
Figure IV.1 : Plate forme Voxeo
IV.2.2. IVR (Interactive Voice Response)

Un IVR est un systme de rponse automatique personnalisable proposant lappelant une liste de services. L'IVR est une technologie permettant une interaction entre un tlphone et une base de donnes afin d'obtenir des informations ou de gnrer des actions en pressant des touches sur le tlphone. Les quipements qui constituent les IVRs comme matriels sont les suivants :(voir figure IV.2) : Les Terminales (1) Les Gateways (2) Les Softswitch et Directory (3) Les Serveurs VoiceXML (4) Les Serveurs Web (5)
Figure IV.2 : Composants des IVRs
SupCom 2006/2007
58
IV.2.3. Ralisation dune application VoiceXML
la diffrence des applications traditionnelles d'enchanement, louverture dun fichier VoiceXML partir dun web browser ne saccompagne pas par une rponse de voix. Lutilisation dun VoiceXML Browser est ncessaire pour linterprtation vocale. Pour examiner une application VoiceXML partir d'un tlphone, nous avons besoin dun nombre pour lappeler. Il y a d'abondance des approches de haut-dollar pour tracer des nombres aux applications VoiceXML, mais pour l'essai, mettre en scne, le dveloppement de Voxeo offres un grand service dattribution des numros.
Figure IV.3 : Directeur d'application de Voxeo.
Figure IV.4 : Attribution dun numro de tlphone un fichier VXML.
SupCom 2006/2007
59
Pour crer une application VoiceXML partir de la Plate forme Voxeo, on commence par choisir Create Application , puis slectionner VoiceXML 2.0 en tant que notre plateforme de dveloppement. Puis, on fournit lURL du fichier VXML, aussi bien qu'un nom pour lapplication (Voir figure IV.4 et figure IV.5).
Figure IV.5 : Attribution de fichier VXML est russi
Si lapplication a t correctement ajoute, un message Application Successufully Added apparat, si non un message derreur est envoy.
SupCom 2006/2007
60
Figure IV.6 : Les diffrents points d'accs au fichier VXML. La figure IV.6 montre les diffrentes mthodes daccs une application VoiceXML par la fourniture des numros spciaux. Laccs une application VoiceXML se fait soit par lutilisation de Skype, soit par FWD ou un client SIP VoIP. Ainsi, suite une opration de numrotation, le fichier VXML sera interprt et la conversation donnes voix va tre russie.
Figure IV.7 : Apple dune application VoiceXML par FWD Suite linstruction prcdente, la figure IV.7 explique lutilisation de lFWD comme un Soft phone VoIP pour lobtention de la voix. Ltape 1 consiste a compos le numro **86919990107208 sur le terminal puis ltape 2 permet la jointure de service.
SupCom 2006/2007
61
Figure IV.8 : Interface de programmation VXML
Figure IV.9 : Exemple dun fichier VXML.
SupCom 2006/2007
62
Au moment de clic sur view , si le fichier VXML est correct, il va tre affich sous la forme de la Figure IV.9, par contre sil est mal form, les erreurs vont tre affiches comme lindique la Figure IV.10.
Figure IV.10 : Dtection des erreurs pour un fichier VXML. Aprs avoir parler de la Plate forme Voxeo et de la faon de raliser une application VoiceXML, nous prsentons, dans la suite de ce chapitre, lAsterisk PBX puis nous dcrivons la ralisation dun site web une information vocale concernant le sport.
IV.3. Asterisk PBX

Asterisk est un PBX applicatif open source permettant d'interconnecter en temps rel des rseaux de voix sur IP via plusieurs protocoles (SIP, H323, ADSI, MGCP) et des rseaux de tlphonies classiques via des cartes d'interface tlphonique et tout ceci moindre cot. Asterisk offre toutes les fonctions d'un PBX et ses services associs comme de la confrence tlphonique, des rpondeurs interactifs, de la mise en attente d'appels, des mails vocaux, de la musique d'attente, de la gnration d'enregistrement d'appels pour l'intgration avec des systmes de facturation, etc...(Comme la montre la figure ci-dessous).
SupCom 2006/2007
63
Rseau ethernet
Rseau tlphonique
VoIP, SIP, H323, IAX Rseau ethernet
PC avec un logiciel VoIP
Asterisk PBX Rseau ethernet Adaptateur pour tlphone analogique (ATA)
Tlphone IP
Tlphone Analogique
Figure IV.11 : Interconnexion dAsterisk PBX Dans la suite nous prsentons les mthodes de fonctionnement de lAsterisk avec le langage VoiceXML, la configuration de protocole SIP ainsi que le principe dinterprtation VoiceXML. Ensuite, nous expliquons comment par lutilisation dun client SIP VoIP (X-Lite), on peut couter de la voix interprter par le PBX.
IV.3.1. Interprtation dun fichier VXML par lAsterisk

Parmi les services offerts par lAsterisk PBX, les IVRs (Interactive Voice Response) sont bass dans notre application sur le langage de dveloppement Voice XML. Mais pour que ce service soit disponible, lajout du module OpenVXI, VoiceXML Browser lAsterisk est ncessaire pour permettre linterprtation vocale. Ce module contient les TTS Text To Speech et lASR Automatic Speech Recognizer qui sont ncessaires cette opration.
IV.3.2. Configuration de service Voice XML sur lAsterisk

Pour configurer le service VoiceXML sur l'Astrisque, il suffit juste douvrir le fichier de configuration extensions.conf et le modifier.
# cd /etc/asterisk # vi extensions.conf
Aprs linstallation de fichier VXML, par exemple sous le rpertoire /tmp, il faut ajouter les nouvelles extensions au fichier de configurations (/etc/asterisk/extensions.conf) de lAsterisk.
exten exten exten exten => => => => 1225,1,Answer 1225,2,Wait (3) 1225,3,Vxml(file:///tmp/sport.vxml) 1225,4,Hangup
SupCom 2006/2007
64
Le numro 1225 est un numro arbitraire de configuration attribu lapplication VoiceXML sport.vxml . Linterprtation de fichier VXML va tre ralis automatiquement par la composition du cet numro au client SIP VoIP. Ensuite, il faut assurer le rechargement des prolongements dans l'Astrisque par lutilisation de la commande :
CLI*> extensions reload
Et en fin lappelle du service :

SIP:1225@<your server IP address>
IV.3.3. Droulement dappel au niveau dAsterisk IV.3.3.1. Fichiers de configuration dAsterisk

Les fichiers de configuration dAsterisk sont les suivant (voir figure IV.12) : Sip.conf : pour la configuration de protocole SIP. Festival.conf : pour configurer le serveur TTS (Text-To-Speech). Vxml.conf : pour la configuration de service VoiceXML. Zapata.conf : pour la configuration des canaux des communications. Extensions.conf : permet la configuration du numrotation et lattribution des fichiers VXMLs correspondants.
Figure IV.12 : Les fichiers de configurations pour Asterisk
SupCom 2006/2007
65
Figure IV.13 : Extensions.conf Au niveau de fichier extensions.conf , il faut dfinir le scnario dappel qui sera excut par lAsterisk.
Figure IV.14 : VoiceXML Configuration Au niveau du fichier de configuration de VoiceXML vxml.conf , la dclaration des paramtres dinterprtation, tels que la dfinition de type daudio (wavecodec quil peut tre gsm ou pcm), lutilisation de vido et leurs paramtres ainsi que lenregistrement de la licence pour VoiceXML Browser OpenVXI , est ncessaire.
SupCom 2006/2007
66
Figure IV.15 : SIP Configuration Le fichier sip.conf , permet de dfinir et de dclarer les clients SIP qui auront la suite la possibilit de connexion lAsterisk.
IV.3.3.2. Fichiers de configuration de VoiceXML Browser

Les configurations ralises au niveau de VoiceXML Browser sont : Dans client.cfg au niveau de MIME type : configuration de codec utilis pour laudio audio/x-wav une frquence dchantillonnage de 8 kHz et une segmentation 10 millisecondes par frames (80 chantillons par frame). Dans client.inet.cacheTotalSizeMB : configuration de laccs Internet par lutilisation du protocole http ainsi que la dtermination de la valeur de la cache suffisante. Configuration du serveur web sil est ncessaire (souvent utilis pour les communications vidos). Modification des paramtres dans client.cfg option Text To Speech pour que la conversation donnes voix soit disponible, ainsi que linstallation de Festival Flite qui permet cette option.
IV.3.3.3. Paramtrage de Soft phone VoIP (X-Lite)

Le paramtrage des Softphones VoIP est ncessaire pour quils puissent tre connects au serveur Asterisk. Les paramtres saisis au niveau de compte SIP du Softphone sont effectivement dfinis lors de la configuration du fichier : sip.conf, (tels que : Username, Display Name, Password).
SupCom 2006/2007
67
Figure IV.16 : Paramtrage de Softphone. En utilisant un client SIP VoIP (X-Lite) paramtr et suite une composition dun numro prdfinie lors du fichier de configurations dAsterisk (extensions.conf), les applications VoiceXML vont tre disponibles et toute personne connecte au serveur peut appeler un service dtermin.
(a) Figure IV.17 : X-Lite (Softphone VoIP)
(b)
SupCom 2006/2007
68
La figure IV.17-(a) est la composition du numro 1225 au Softphone X-Lite, signifie que lopration dappel est dbute, la figure IV.17-(b) est ltablissement dappel IP avec le serveur Asterisk.
IV.3.3.4. Rponse dAsterisk un appel entrant
Figure IV.18 : Rponse dAsterisk pour lappel 1225
La figure IV.18 prsente les diffrents tapes dexcutions faite par lAsterisk suivant un appel SIP entrant 1225 , tel que louverture dun fichier VXML ainsi que leur interprtation Autrement dit lAsterisk excute les tapes dj dfinie lors de la configuration de extensions.conf qui sont associ au numro dappel.
SupCom 2006/2007
69
Chapitre IV : Ralisation IV.4. Site Sportif : (raliser moyennant Plate forme Voxeo)
Ce site est ralis moyennant le langage html, java (utilisation dAPI Swing et Applet) et java script.
Figure IV.19 : Ouverture de site Aprs louverture de site, le client doit remplir les champs didentifications ncessaires pour passer la page suivante. Et dans le cas o quil nest pas inscrit, il faut passer la page dinscription pour remplir un formulaire dinscription.
Figure IV.20 : Identification ou inscription Lors de ltape de validation des champs didentifications, des messages dalertes apparaissent dans le cas o un certain champ est erron, comme login incorrect ou mot de passe incorrect
SupCom 2006/2007
70
Figure IV.21 : Page dinscription Dans la page dinscription, le client est demand de remplir un formulaire qui contient des champs ncessaires saisir et dautres champs facultatifs. De mme dans le cas de mal tablissement dun champ, les messages dalertes surgissent.
Figure IV.22 : Les messages dalertes.
Cette figure prsente lensemble des messages dalertes possibles correspondants ltape didentification ou dinscription.
SupCom 2006/2007
71
Figure IV.23 : Choix du type de service sportif Le client doit choisir son propre service sportif disponible sur la page tel que Football pour quil puisse passer la page suivante.
Figure IV.24 : Page service football : choix dune League disponible
Aprs la slection de type de service sportif, le client fait un choix de sa League prfre (FA Premier League Anglaise), aussi une slection de son quipe admirable (Arsenal).
SupCom 2006/2007
72
Figue IV.25 : Choix dquipe : Page de la League anglaise Au moment du click sur le nom de lquipe, la page correspondante est affiche, comme la montre la figure ci-dessous.
Figure IV.26 : Page dquipe Arsenal
SupCom 2006/2007
73
Figure IV.27 : Excution de Skype VoIP Suite louverture de la page dquipe choisie, le client, cette tape, excute lun des Soft phones disponibles pour tablir lopration de numrotation.
Figure IV.28 : Dmarrage de Skype
Le dmarrage des Soft phones est ralis automatiquement suite au click sur le bouton excuter .
SupCom 2006/2007
74
Suite la phase de dmarrage de Soft phone VoIP, le client fait lopration de numrotation qui consiste taper le numro de correspondance dj dfinie dans la page (voir la figure cidessous).
Numrotation
Figure IV.29 : Numrotation de Skype.
Dans le cas o le client na pas lun des ces Softphones, cette page lui permet den tlcharger un directement en le slectionnant partir de la liste de la figure IV.30 puis en cliquant sur le bouton suivant.
Figure IV.30 : Liens de tlchargement des Softphone VoIP
SupCom 2006/2007
75
IV.5. Conclusion
Dans ce chapitre nous avons prsent au premier lieu, un outil de dveloppement des applications vocales : la Plate forme Voxeo, la faon de raliser et de manipuler des applications vocales utilisant le langage VoiceXML ainsi que leurs mthodes de teste offerte (numrotation et diffrentes accs aux Soft phones VoIP). En deuxime point nous avons ralis aussi des applications vocales sur lAsterisk PBX, lexplication de leur configuration faire ainsi que leur relation avec Voice Browser VXI linterprteur de langage VoiceXML. Enfin nous avons prsent un site sportif qui permet travers lutilisation des Soft phones VoIP et on a montr suite une opration de numrotation linterprtation VoiceXML va tre russie, ainsi que la conversation donnes voix est tablie.
SupCom 2006/2007
76
Conclusion gnrale et perspective
Conclusion gnrale et perspectives

Lvolution des rseaux vers un rseau unique multiservices a ncessit llaboration de nombreux protocoles de signalisation par les communauts de recherche. Chaque solution envisage rpond un besoin ou un service spcifique. La multiplication des protocoles de signalisation pour des applications de voix par exemple, leurs utilisations par des diffrents services tel que les rponses vocale interactives IVRs . En effet, cest dans le cadre de ce thme que soriente lobjectif de notre projet de fin dtude. Nous avons prsent dans un premier volet de cette mmoire les rseaux de nouvelle gnration (NGN) : leurs architectures, les lments qui les composent et les diffrents protocoles concurrents. Par la suite, nous nous sommes intresss ltude des protocoles de la couche contrle savoir les protocoles H.323 et SIP. Nous avons abord en deuxime volet le dialogue oral homme-machine ainsi que ses proprits. Lapparition de la norme VoiceXML apporte vraiment des avantages pour construire des applications vocales simples mais nos analyses montrent quil ne rpond pas encore aux exigences de lutilisateur en raison de ses caractristiques intrinsques, de son objectif A partir de cela, nous avons donn la dfinition dun systme de dialogue oral homme-machine afin davoir une vue sur une application vocale gnrale. Ensuite, nous avons dcrit en dtail une architecture gnrale ddie au systme de dialogue avec sept modules principaux. La sparation de fonctionnalits de chaque module permet effectivement de le mettre en oeuvre de manire distribue un systme de dialogue. Afin de raliser une application vocale interactive nous avons eu recours lutilisation des outils qui utilisent VoiceXML comme langage de dveloppement tels que la plate forme Voxeo ou encore lassemblage de VoiceXML Browser OpenVXI lAsterisk PBX. Pour que linterprtation des applications vocales ralises par VoiceXML soit disponible travers lAsterisk PBX plusieurs tapes ont t tablies :
Installation de lAsterisk PBX (sur RedHat Entrprise Server 4). Installation de lOpenVXI : VoiceXML Browser. Configuration de VoiceXML Browser. En plus toutes les configurations dj expliquer au niveau de chapitre IV tels que extensions.conf , sip.conf
SupCom 2006/2007
77
Conclusion gnrale et perspective
Nanmoins, ce travail est achev, il convient de remarquer que : Actuellement, la recherche portant sur le dialogue oral homme-machine sefforce de plus en plus de modliser la capacit de communication humaine dans la machine. Le but ultime de ces travaux vise amliorer lefficacit du systme de dialogue au point de vue dialogique, cest--dire diminuer de plus en plus la distance entre un dialogue humain et un dialogue homme-machine. Mais il faut aussi considrer les problmatiques suivantes au systme de dialogue homme-machine : Sous langle du gnie logiciel, le systme de dialogue est un systme dinteraction. Il ncessite en pratique une infrastructure ayant des bonnes primitives, de manire ladapter un ensemble de systmes diffrents. La dfaillance defficacit dun systme de dialogue rside vritablement dans la sensibilit de telles erreurs (les modules de comprhension et dinterprtation ne peuvent envisager tous les contextes et peuvent donc provoquer des incomprhensions, des malentendus). Il est certain que le contrleur du dialogue doit possder des mcanismes adquats, afin de surmonter de tels problmes. La capacit de ngociation dun systme de dialogue est galement une demande considrer. Lexigence dun gestionnaire efficace dans un systme de dialogue mobilise la recherche sur des modles de dialogue. Alors des philosophes et psychologues ont propos beaucoup de thories importantes, jouant un rle dterminant dans lapparition des modles de dialogue.
SupCom 2006/2007
78
Bibliographie
Bibliographie
[1] Rapport de lETSI-NGN Starter Groupe, compte-rendu de lassemble GA38 des 2021/11/01. www.art-telecom.fr/fileadmin/reprise/publications/ngnsept02.pdf [2] Guill Professeur ESCE Angres. VoIP. 23 dcembre 1999. http://www.guill.net/reseaux/voip/voip6.html [3] Tlphonie sur Internet : Quelle respective ? Patrice Collet, Michel Dudet, Olivier Hersent, Etienne Turpin. [4] Communications IP, Livre Blanc. WHI/IPCOM, 01/03/2006 Telindus Arche, Par Laurent Auzly, [5] La qualit de service en voix sur IP. Accellent http://www.accellent-group.com [6] Etude technique, conomique et rglementaire de lvolution vers les rseaux de nouvelle gnration. http:// www.art-telecom.org/ngnsep02.pdf [7] Rseaux IP - Voix et multimdia sur IP Antoine Delley, directeur ICTnet http:// www. ICTnet.ch [8] SIP vs H.323 a Comparison of Call Functionality. http://www.packetizer.com/voip/h323_vs_sip/ [9] http://www.voicexml.com/ [10] http://www.w3.org/TR/voicexml20/ [11] Rabiner L. R., Juang B., Tutorial on hidden Markov models and selected applications in speech recognition, Proceedings of the IEEE, vol. 77, no. 2, pp. 257-285, 1989. [12] Y. Wang, M. Mahajan, X. Huang, A Unified Context-Free Grammar and N-Gram Model for Spoken Language Processing. In proceeding s of the International Conference on Acoustics, Speech and Signal Processing ICASSP 2000.pp 1639-1642. [13] A. Bonnet, Les grammaires smantiques, outils puissants pour interroger les base de donnes en langage naturel , RAIRO Informatique, vol. 14, n2, pp. 137-148, 1980. [14] Ch.J Fillmore, The case for case, in Universals in Linguitic Theory, Bach Emmon et Harms Robert T., pp. 1-90, NewYork, 1968. [15] J.Bresnan, The mental representation of grammatical relations, MIT Press, Cambridge, MA, ISBN 0-262-02158-7, 1982.
SupCom 2006/2007
79
Annexe
Annexe
Les lments du langage VoiceXML Elment
Assign Audio Block Catch Choice Clear Disconnect Else Elseif Enumerate Error Exit Field Filled Form Goto Grammar Help If Initial Link Log Menu Meta Metadata Noinput Nomatch Object Option Param Prompt Property
Objectif
Assigne une valeur une variable Lit un fichier son au sein d'un lment prompt Un conteneur pour un code excutable (non interactif) Capture un vnement Dfinit un lment de menu Efface une ou plusieurs variables d'lment de formulaire Dconnecte une session Employ dans les lments if Employ dans les lments if Raccourci pour l'numration des choix dans un menu Capture un vnement erreur Sort d'une session Dclare un champ de saisie dans un formulaire Une action excute quand les champs sont remplis Un dialogue pour la prsentation d'informations et la collecte de donnes Aller un autre dialogue dans le mme document ou un document diffrent Indique une grammaire de reconnaissance vocale ou une grammaire DTMF Capture un vnement aide Logique conditionnelle simple Dclare une logique initiale sur une entre dans un formulaire ( initiative mixte) Dfinit une transition commune tous les dialogues dans la porte du lien Gnre un message de dbogage Un dialogue pour choisir entre plusieurs destinations Dfinit un lment de mta donn en tant que couple nom/valeur Dfinit un mta information en utilisant un schma de mta donn Capture un vnement non-entre Capture un vnement non-correspondance Interagit avec une extension personnalise Indique une option dans un lment field Paramtre dans un lment object ou subdialog Place en file d'attente la synthse vocale et la sortie audio vers l'utilisateur Contrle les paramtres de la plateforme d'implmentation.
SupCom 2006/2007
80
Annexe
Record Reprompt Return Script Subdialog Submit Throw Transfer Value Var Record Enregistre un chantillon audio Joue la file d'attente sur un champ lorsque celui-ci est revisit aprs un vnement Retour d'un sous-dialogue. Dfinit un bloc de logique de script ECMAScript ct client Invoque un dialogue en tant que sous-dialogue du dialogue courant Soumet des valeurs un serveur de documents Suscite un vnement. Transfre l'appelant vers une autre destination Insre la valeur d'une expression dans une invite Dclare une variable L'lment de niveau suprieur dans chaque document VoiceXML
SupCom 2006/2007
81
Rsum
Les applications vocales subissent ces dernires annes une volution importante, puisqu'elles montrent une ractivit accrue face aux besoins des usagers de plus en plus varis. En fait ce type d'application offre aux individus l'opportunit de garder, et de manire continue, le contact avec les informations qui les intressent. C'est dans cette perspective que s'inscrit notre projet, qui a pour objectif de concevoir et de raliser un service des IVRs (Interactive Voice Response), qui se charge de surveiller les demandes des clients et de les informer par de voix chaque fois qu'un appel client est reu. Pour la ralisation de cette application, nous avons dvelopp une application web moyennant une Plateforme VoiceXML qui, une fois lance sur Internet, permette aux abonnes de dcouvrir notre service.
Mots cls: VoIP, SIP, VoiceXML, Application vocale, Asterisk PBX, Plateforme Voxeo.
SupCom Juin 2007

Ben Slama Sofiene

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Ben Slama Sofiene

Загружено:

Авторское право:

Доступные форматы

Cycle de formation des ingnieurs en Tlcommunications

Rseaux et Services Mobiles

Rapport de Projet de fin dtudes

Intgration des services vocaux aux services daccs aux donnes

Ben Slama Sofiene

Anne universitaire : 2006/2007

Je nomettrai jamais dexprimer toute ma gratitude tout le staff de lEcole

Sofiene BEN SLAMA

TABLE DES MATIERES

TABLE DES MATIERES

TABLE DES MATIERES

Chapitre II : Les protocoles de signalisation de VoIP et le langage VoiceXML ......20

Chapitre III : Conception Objet de lapplication...............................................................41

SupCom 2006 /2007

TABLE DES MATIERES

Chapitre IV : Ralisation .........................................................................................................56

SupCom 2006 /2007

Liste des Figures et des Tableaux

Liste des Figures

SupCom 2006 /2007

Liste des Figures et des Tableaux

Liste des Tableaux

SupCom 2006 /2007 vii

SupCom 2006 /2007 viii

SupCom 2006 /2007

SupCom 2006 /2007

Chapitre I : Rseau de nouvelle gnration (NGN) et voix sur IP (VoIP)

Rseau de nouvelle gnration (NGN) et Voix sur IP (VoIP)

Chapitre I : Rseau de nouvelle gnration (NGN) et voix sur IP (VoIP)

Rseau de nouvelle gnration (NGN) et Voix sur IP (VoIP)

Couche Service (oprateur et tiers) Interfaces ouvertes et normalises

Couche Contrle Interfaces ouvertes et normalises Couche Transport (mode paquet)

Rseau daccs multiple

Connexe aux NGN

Chapitre I : Rseau de nouvelle gnration (NGN) et voix sur IP (VoIP)

I.2.2. Principe gnrale et vue densemble

Figure I.2 : Architecture physique dun rseau NGN.

Chapitre I : Rseau de nouvelle gnration (NGN) et voix sur IP (VoIP)

I.2.3.2. Le serveur dappel ou Media Gateway Controller (MGC)

I.2.3.3. Le Signalling Gateway (SG)

I.2.4. Les protocoles de NGN

Chapitre I : Rseau de nouvelle gnration (NGN) et voix sur IP (VoIP)

Les protocoles de contrle dappel permettant ltablissement, gnralement linitiative

I.2.4.1. Les protocoles de contrle dappel

Chapitre I : Rseau de nouvelle gnration (NGN) et voix sur IP (VoIP)

I.2.4.2. Les protocoles de commande de Media Gateway

Le Media Gateway Control Protocol: MGCP

Chapitre I : Rseau de nouvelle gnration (NGN) et voix sur IP (VoIP)

Protocole SIP entre Media Gateway Controller: SIP-T

Chapitre I : Rseau de nouvelle gnration (NGN) et voix sur IP (VoIP)

B/ A linterconnexion avec les rseaux de signalisation SS7

I.3. Exemples des services offerts par les NGNs

Chapitre I : Rseau de nouvelle gnration (NGN) et voix sur IP (VoIP)

Figure I.3 : Principaux composants dune solution de communication IP

Chapitre I : Rseau de nouvelle gnration (NGN) et voix sur IP (VoIP)

Figure I.4 : Architecture VoIP

Chapitre I : Rseau de nouvelle gnration (NGN) et voix sur IP (VoIP)

I.4.4.1. Un sens dlicat

I.4.4.2. La conversation orale : une exigence dinteractivit

I.4.5. Les paramtres de la voix sur IP

Chapitre I : Rseau de nouvelle gnration (NGN) et voix sur IP (VoIP)

I.4.5.1. Les diffrents chantillonnages

Chapitre I : Rseau de nouvelle gnration (NGN) et voix sur IP (VoIP)

I.4.5.2. Le dlai de transit