Vous êtes sur la page 1sur 93
Cycle de formation des ingénieurs en Télécommunications Option : Réseaux et Services Mobiles Rapport de
Cycle de formation des ingénieurs en Télécommunications Option : Réseaux et Services Mobiles Rapport de

Cycle de formation des ingénieurs en Télécommunications

Option :

Réseaux et Services Mobiles

Rapport de Projet de fin d’études

Thème :

Intégration des services vocaux aux services d’accès aux données

Réalisé par :

Ben Slama Sofiene

Encadrants :

M. Choukaier Zied (SUP’COM)

M. Bel Habib Najib (NewTech)

M. Zouari Mourad (IT.Com)

Travail proposé et réalisé en collaboration avec

M. Zouari Mourad (IT.Com) Travail proposé et réalisé en collaboration avec & Année universitaire : 2006/2007

&

M. Zouari Mourad (IT.Com) Travail proposé et réalisé en collaboration avec & Année universitaire : 2006/2007

Année universitaire : 2006/2007

Dédicaces

La vie n’est qu’un éclair, Et un jour de réussite est un jour très cher.

A mon cher père SlahEddine et ma chère mère Dahbia,

PPour l’éducation et le grand amour dont ils m’ont entouré depuis ma naissance.

EEt pour leurs patiences et leurs sacrifices.

AA mes chers frères : Walid, Bacem, Naceur ; AA ma chère soeur : Naziha ; AA tous mes proches ; AAu petit Achref ; AA tous ceux qui m'aiment ; AA tous mes ami (e) s; AA tous ceux que j’aime.

Sofiene BEN SLAMA

JJe dédie ce mémoire.

Remerciements

Remerciements

CC’est avec un grand plaisir que je réserve cette page en signe de gratitude et de profonde reconnaissance à tous ceux qui m’ont aidé de près ou de loin à la réalisation de ce travail.

JJe tiens à exprimer mes sincères gratitudes et respects à mes encadreurs Mr. Zied Choukaier, Maître de conférence à l’école supérieure des communications de Tunis, et Mr Bel Habib Najib et Zouari Mourad, directeurs des sociétés NewTech et IT.COM, Pour leurs encouragements et les précieux conseils qu’ils n’ont cessés de me prodiguer tout au long de ce projet.

JJe n’omettrai jamais d’exprimer toute ma gratitude à tout le staff de l’Ecole Supérieure de Communication de Tunis (Sup’com) qui de prés ou de loin n’a épargné aucun effort pour que nos travaux se termine dans les bonnes conditions.

EEnfin mes meilleurs et vifs remerciements s’adressent aux membres du jury pour avoir accepté d’évaluer ce projet.

Sofiene BEN SLAMA

TABLE

DES MATIERES

TABLE DES MATIERES

Liste des Figures et des Tableaux

vi

Glossaires

viii

Introduction Générale

1

Chapitre I : Réseau de nouvelle génération (NGN) et Voix sur IP (VoIP)

3

I.1. Introduction

4

I.2. Les réseaux de nouvelles générations

5

I.2.1. Définition

5

I.2.2. Principe générale et vue d’ensemble

6

I.2.3. Les entités fonctionnelles du cœur de réseau NGN

7

I.2.3.1. Le Media Gateway

7

I.2.3.2. Le serveur d’appel 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 contrôle d’appel

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 contrôle

10

I.3. Exemples des services offerts par les NGNs

11

I.4. La Voix sur IP

12

I.4.1. Définition et vue d’ensemble

12

I.4.2. Principaux composants d’architecture VoIP

13

I.4.3. Architecture VoIP

14

I.4.4. Caractéristiques de la Voix

15

I.4.4.1. Un sens délicat

15

I.4.4.2. La conversation orale : une exigence d’interactivité

15

I.4.5. Les paramètres de la voix sur IP

15

I.4.5.1. Les différents échantillonnages

16

I.4.5.2. Le délai de transit

17

I.4.5.3. La gigue de phase

18

I.4.5.4. La perte de données

18

I.4.6. Les défauts de la communication IP

18

I.5. Conclusion

19

TABLE DES MATIERES

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

20

II.1. Introduction II.2. Les protocoles de contrôle d’appel II.2.1. Architecture centralisée II.2.1.1. MGCP- Media Gateway Control Protocol II.2.1.2. MEGACO/H.248 II.2.1.3. Net2Phone II.2.1.4. SCCP II.2.2. Architecture distribuée II.2.2.1. Le protocole H.323 II.2.2.1.1. Les différents composants de H.323 II.2.2.2. Le protocole SIP II.2.2.2.1. Topologie de protocole SIP II.2.2.2.2. Les messages SIP II.2.2.2.2.1. Les requêtes de base SIP II.2.2.2.2.2. Les autres requêtes SIP II.3. Avantages et Inconvénients H323, SIP et MGCP II.4. VoiceXML et application vocale II.4.1. Introduction II.4.2. Présentation de VoiceXML II.4.3. Définition II.4.4. Concept de base II.4.5. Caractéristiques II.4.5.1. Modèle d’architecture II.4.5.2. Avantages II.4.5.3. Inconvénients II.4.6. Systèmes de dialogue oral homme-machine II.4.6.1. Principes généraux II.4.6.2. Architecture générale II.4.6.2.1. Reconnaissance automatique de la parole II.4.6.2.2 Compréhension sémantique II.4.6.2.3 Interpréteur pragmatique II.4.6.2.4 Contrôleur du dialogue II.4.6.2.5 Contrôleur de la tâche II.4.6.2.6 Générateur textuel II.4.6.2.7 Synthétiseur de la parole II.4.6.3. Défis d’un système de dialogue II.5. Conclusion

21

21

22

22

23

23

23

23

24

25

28

28

30

30

30

31

32

32

33

33

34

34

34

35

35

35

35

36

37

38

38

38

38

39

39

39

40

Chapitre III : Conception Objet de l’application

41

III.1. Introduction III.2. Cadre générale de l’application III.2.1. Description III.2.2. Exemple de fonctionnement d’une application VoiceXML III.3. Etude théorique III.3.1. Formalisme UML III.3.1.1. Diagramme des cas d’utilisation : DCU III.3.1.2. Diagramme de séquence : DES III.3.1.3. Diagramme d’activité : DAC

42

42

43

43

44

44

45

45

45

Sup’Com 2006 /2007

iv

TABLE DES MATIERES

III.3.1.4. Diagramme de collaboration : DCO III.3.2. Identification et Représentation des cas d’utilisation III.3.2.1. Cas d’utilisation d’inscription III.3.2.2. Cas d’utilisation d’identification III.3.2.3. Choix d’équipe III.3.2.4. Conception de site III.3.3. Diagramme de collaboration :

45

45

46

46

46

47

48

III.3.4. Diagramme d’activité III.3.5. Diagramme de séquence III.3.5.1. De l’appellent jusqu'à l’appelé III.3.5.2. Demande d’inscription III.3.5.3. Cycle d’authentification III.3.5.4. Déroulement de l’application

49

50

50

52

53

53

Chapitre IV : Réalisation

56

IV.1. Introduction IV.2. Plate forme Voxeo pour VoiceXML IV.2.1. Vue global sur Voxeo IV.2.2. IVR IV.2.3. Réalisation d’une application VoiceXML IV.3. Asterisk PBX IV.3.1. Interprétation d’un fichier VXML par l’Asterisk IV.3.2. Configuration de service Voice XML sur l’Asterisk IV.3.3. Déroulement d’appel au niveau d’Asterisk IV.3.3.1. Fichiers de configuration d’Asterisk IV.3.3.2. Fichiers de configuration de VoiceXML Browser IV.3.3.3. Paramétrage de Soft phone VoIP IV.3.3.4. Réponse d’Asterisk à un appel entrant IV.4. Site Sportif IV.5. Conclusion

57

57

57

58

59

63

64

64

65

65

67

67

69

70

76

Conclusion générale et perspectives

77

Bibliographie

79

Annexe

80

Sup’Com 2006 /2007

v

Liste des Figures et des Tableaux

Liste des Figures

Figure I.1 : Principe général d’architecture d’un réseau NGN

5

Figure I.2 : Architecture physique d’un réseau

6

Figure I.3 : Principaux composants d’une solution de communication IP

13

Figure I.4 : Architecture VoIP

14

Figure II.1 : Intelligence uniquement auprès des "maîtres"

22

Figure II.2 : Intelligence partagée entre les serveurs et les

24

Figure II.3 : Topologie d'un réseau VoIP – H.323

25

Figure II.4 : Diagramme fonctionnel d’une passerelle

26

Figure II.5 : Diagramme fonctionnel d’un Gatekeeper

26

Figure II.6 : Diagramme fonctionnel d’une MCU

27

Figure II.7 : Topologie d'un réseau VoIP – SIP

28

Figure II.8 : Proxy SIP

29

Figure II.9 : Modèle d’architecture de VoiceXML

34

Figure II.10 : Architecture générale d’un système de DHM

36

Figure II.11 : Description d’un module de reconnaissance de la parole

37

Figure III.1 : Serveurs vocaux de nouvelle génération :

42

Figure III.2 : Fonctionnement d’une application VoiceXML

43

Figure III.3 : Positionnement des neuf diagrammes d’UML

44

Figure III.4 : Cas d’utilisation d’inscription

46

Figure III.5 : Cas d’utilisation d’identification

46

Figure III.6: Cas d’utilisation de sélection d’équipe préféré Handballeuse

47

FigureIII.7 : Cas d’utilisation de sélection d’équipe préféré Footballeuse

47

Figure III.8 : Cas d’utilisation de conception de site

48

Figure III.9 : Diagramme de collaboration

49

Figure III.10 : Diagramme d’activité

49

Figure III.11 : Diagramme de séquence (appellent à appelé)

52

Figure III.12 : Diagramme de séquence (inscription)

52

Figure III.13 : Diagramme de séquence (identification)

53

Figure III.14 : Diagramme de séquence (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 d’un numéro de téléphone à un fichier VXML

59

Figure IV.5 : Attribution de fichier VXML est réussi

60

Figure IV.6 : Les différents points d'accès au fichier

61

Figure IV.7 : Apple d’une application VoiceXML par FWD

61

Figure IV.8 : Interface de programmation VXML

62

Figure IV.9 : Exemple d’un fichier

62

Figure IV.10 : Détection des erreurs pour un fichier

63

Figure IV.11 : Interconnexion d’Asterisk PBX

64

Figure IV.12 : Les fichiers de configurations pour Asterisk

65

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 : Paramétrage de Softphone

68

Figure IV.17 : X-Lite (Softphone VoIP)

68

Figure IV.18 : Réponse d’Asterisk pour l’appel 1225

69

Figure IV.19 : Ouverture de site

70

Figure IV.20 : Identification ou inscription

70

Figure IV.21 : Page d’inscription

71

Figure IV.22 : Les messages

71

Figure IV.23 : Choix de type de service sportif

72

Figure IV.24 : Page service football : choix d’une League disponible

72

Figue IV.25 : Choix d’équipe : Page de la League anglaise

73

Figure IV.26 : Page d’équipe Arsenal

73

Figure IV.27 : Exécution de Skype VoIP

74

Figure IV.28 : Démarrage de Skype

74

Figure IV.29 : Numérotation de Skype

75

Figure IV.30 : Liens de téléchargement des Softphone VoIP

75

Liste des Tableaux

 

16

Tableau I.1 : Codecs en fonction de leurs vitesses d’échantillonnage Tableau I.2 : Bilan de bande passante en fonction du codec

16

Tableau II.1 : Avantages et Inconvénients des protocoles de signalisation de VoIP

31

Tableau III.1 : Diagramme UML

45

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.

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: Réseau téléphonique commuté. RTP: Real-time Transfert Protocole. RTCP: Real-time Transfert Control Protocole. RAS: Réseau Associatif et Syndical. RNIS: Réseau numérique à intégration 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.

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 Télécommunications. 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.

Introduction générale

Introduction Générale

Les évolutions profondes vécues et le développement de nouvelles gammes de services semblent êtres des facteurs favorables à l’évolution progressive du monde des télécommunications vers un nouveau modèle de réseaux et de services appelé NGN (Next Generation Networks). Ce nouveau concept propose le transport de plusieurs informations différentes sur un support mode paquet, on parle donc de la convergence Voix/données et fixe/Mobile.

L’utilisation d’un réseau en mode paquet pour transporter de la voix, avec des contraintes de «temps réel», a nécessité l’adaptation de la couche contrôle. En effet, ces réseaux en mode paquet étaient généralement utilisés comme réseau de transport mais n’offraient pas de services permettant la gestion des appels et des communications. Cette évolution a conduit donc à l’apparition de nouveaux protocoles tels que H.323 et SIP, concernant la gestion des flux multimédia, au sein de la couche contrôle.

« Dialoguer est un art de vivre », cet adage est certainement vrai, non seulement dans la vie quotidienne, mais également dans l’aspect communicatif entre l’homme et le système d’information.

La notion d' « application vocale » couvre une zone plus vaste dans l'ensemble des applications informatiques. Nous définissons une application vocale comme une application informatique utilisant la parole pour réaliser/accomplir certaines tâches. Dans ce type d'applications, l'utilisateur peut dialoguer avec l'application en utilisant seulement les mots clés, une phrase courte et simple, … ou toute la complexité de la langue.

C’est dans ce contexte que décline l’objectif de notre projet de fin d’étude, proposé dans le cadre d’une collaboration entre l’école supérieure des communications de Tunis, les sociétés IT.COM et NEWTECH , pour la réalisation des IVRs : les réponses vocales interactives soit sur une plateforme Web Voxeo ou sur l’Asterisk PBX. Il s’agit de présenter un état de l’art concernant d’une part la notion des réseaux NGNs ainsi que les différents protocoles de signalisation, de contrôle et de commande d’appels, d’autre part le langage VoiceXML afin de nous permettre moyennant des Soft phones VoIP d’appeler une application vocale prédéfinie.

Ce mémoire s’organise en quatre chapitres et se termine par une conclusion, ouvrant sur des perspectives :

Le premier chapitre introduit le concept NGN, il présente dans un premier volet les protocoles de signalisation de contrôle et de commande d’appel. Le deuxième volet porte sur la notion de la voix sur IP et de ses exigences comme étant un service directement lié aux NGNs.

Introduction générale

Le second chapitre se focalise d’avantage sur les protocoles de contrôle d’appel à savoir les protocoles H.323 et SIP. Nous détaillerons alors leurs architectures ainsi que leurs caractéristiques. Et à la fin de ce chapitre nous expliquons la notion d’application vocale ainsi que le langage VoiceXML.

La représentation et la conception de travail à faire seront proposées dans le troisième chapitre qui se divise en deux parties : la première pour la description de l’application aussi bien que l’introduction d’utilisation de VoiceXML comme un langage de programmation pour le développement des IVRs dans un réseau tout IP, la seconde consacré à une étude théorique de travail à réaliser expérimentalement en détaillant quelques diagrammes UML qui vont être réaliser à travers Rational Rose comme logiciel.

Le quatrième chapitre s’adresse à l’aspect pratique en présentant l’expérimentation de toutes nos approches théoriques. Nous exposons tout d’abord la plate forme Voxeo comme un outil de développement des IVRs, nous présentons par la suite l’Asterisk PBX, la notion de VoiceXML Browser ainsi que son utilisation avec l’Asterisk pour l’interprétation des fichiers VoiceXML. Enfin la réalisation d’un petit site web dans le but est de fournir des infos vocales sportives par l’utilisation des numéros spécifiques à travers des Soft phones VoIP bien définies.

Le bilan général de ce mémoire est présenté dans la conclusion et diverses perspectives sont également proposées.

Chapitre I : Réseau de nouvelle génération (NGN) et voix sur IP (VoIP)

Chapitre I

géné ration (NGN) et voix sur IP (VoIP) Chapitre I Réseau de nouvelle génération (NGN) et

Réseau de nouvelle génération (NGN) et Voix sur IP (VoIP)

et voix sur IP (VoIP) Chapitre I Réseau de nouvelle génération (NGN) et Voix sur IP

Chapitre I : Réseau de nouvelle génération (NGN) et voix sur IP (VoIP)

Chapitre I

Réseau de nouvelle génération (NGN) et Voix sur IP (VoIP)

I.1. Introduction

Depuis l’invention du téléphone par Alexander Graham Bell en 1876, de nombreux progrès et révolutions se sont opérés dans le domaine des télécommunications. Aujourd’hui, d’ ailleurs, nous vivons dans l’ère des télécommunications et il est devenu impensable de se séparer des services offerts par ce secteur.

Les évolutions profonds vécus et le développement de nouvelles gammes de services semblent êtres des facteurs favorable à l’évolution progressive du monde des télécommunications vers un nouveau modèle de réseaux et de services appelé NGN (Next Generation Networks).

C’est dans ce contexte que ce premier chapitre est consacré à la présentation des réseaux de nouvelles générations (NGN Next Generation Network). Dans une première section nous nous sommes intéressés à l’architecture des réseaux NGNs, aux différents éléments qui le composent ainsi qu’aux différents protocoles en concurrence. La seconde section met l’accent sur un service directement lié à l’évolution vers les réseaux NGNs ; à savoir le service de la voix sur IP (VoIP).

Chapitre I : Réseau de nouvelle génération (NGN) et voix sur IP (VoIP)

I.2. Les réseaux de nouvelles générations

I.2.1. Définition

Les NGNs sont définis comme un réseau de transport en mode paquet permettant la convergence des réseaux Voix/données et Fixe/Mobile ; ces réseaux permettront de fournir des services multimédia accessibles depuis différents réseaux d’accès. Afin de s’adapter à l’ouverture des nouveaux services, les NGN sont basés sur une évolution progressive vers le « tout IP ». Ils sont modélisés par une architecture en couches indépendantes (transport, contrôle, services et accès) dialoguant via des interfaces ouvertes et normalisées [1].

Périmètre

NGN

Connexe

aux NGN

Couche Service (opérateur et tiers) Interfaces ouvertes et normalisées Couche Contrôle Interfaces ouvertes et
Couche Service
(opérateur et tiers)
Interfaces ouvertes et
normalisées
Couche Contrôle
Interfaces ouvertes et
normalisées
Couche Transport
(mode paquet)
Réseau d’accès
multiple
Terminaux

Cœur de

réseau

Figure I.1 : Principe général d’architecture d’un réseau NGN

La couche « Accès », qui permet l’accès de l’utilisateur aux services via des supports de transmission et de collecte divers : câble, cuivre, fibre optique, boucle locale radio, xDSL, réseaux mobiles.

La couche « Transport », qui gère l’acheminement du trafic vers sa destination. En bordure du réseau de transport, des « Media Gateways » et des «Signalling Gateways» gère respectivement la conversion des flux de données et de signalisation aux interfaces avec les autres ensembles du réseau ou les réseaux tiers interconnectés.

La couche « Contrôle », qui se compose de serveurs dits « Softswitch » gérant d’une part les mécanismes de contrôle d’appel (pilotage de la couche transport, gestion des adresses), et d’autre part l’accès aux services (profils d’abonnés, accès aux plates formes de services à valeur ajoutée).

La couche « Services », qui regroupe les plates-formes d’exécution de services et de diffusion de contenus. Elle communique avec la couche contrôle du coeur de réseau via des interfaces ouvertes et normalisées, indépendantes de la nature du réseau d’accès

Chapitre I : Réseau de nouvelle génération (NGN) et voix sur IP (VoIP)

utilisé. Les services et contenus eux-mêmes sont par ailleurs développés avec des langages convergents et unifiés.

I.2.2. Principe générale et vue d’ensemble

Les principales caractéristiques des réseaux NGN sont l’utilisation d’un unique réseau de transport en mode paquet (IP, ATM,…) ainsi que la séparation des couches de transport des flux et de contrôle des communications, qui sont implémentées dans un même équipement pour un commutateur traditionnel. Ces grands principes se déclinent techniquement comme suit concernant les équipements actifs du coeur de réseau NGN :

A/ Remplacement des commutateurs traditionnels par deux types d’équipements distincts :

Des serveurs de contrôle d’appel dits Softswitch ou Media Gateway Controller (correspondant schématiquement aux ressources processeur et mémoire des commutateurs voix traditionnels).

.

Des équipements de médiation et de routage dits Media Gateway (correspondant schématiquement aux cartes d’interfaces et de signalisation et aux matrices de commutation des commutateurs voix traditionnels), qui s’appuient sur le réseau de transport mutualisé NGN.

B/ Apparition des nouveaux protocoles de contrôle d’appel et de signalisation entre ces équipements (de serveur à serveur et de serveur à Media Gateway).

(de serveur à serveur et de serveur à Media Gateway). Figure I.2 : Architecture physique d’un

Figure I.2 : Architecture physique d’un réseau NGN.

Chapitre I : Réseau de nouvelle génération (NGN) et voix sur IP (VoIP)

I.2.3. Les entités fonctionnelles du cœur de réseau NGN I.2.3.1. Le Media Gateway (MG)

Le Media Gateway est située au niveau du transport des flux média entre le réseau RTC et le réseau en mode paquet, ou entre le coeur de réseau NGN et les réseaux d’accès. Il a pour rôle :

Le codage et la mise en paquets du flux média reçu du RTC et vice-versa (conversion du trafic TDM (Time Division Multiplexing) en trafic IP (Internet Protocol)).

La transmission, selon les instructions du Media Gateway Controller, des flux média reçus de part et d'autre.

I.2.3.2. Le serveur d’appel ou Media Gateway Controller (MGC)

Dans un réseau NGN, le MGC possède de « l'intelligence » et c’est lui qui gère :

L’échange des messages de signalisation transmise de part et d'autre avec les passerelles de signalisation, et l’interprétation de cette signalisation.

Le traitement des appels : dialogue avec les terminaux H.323, SIP, communication avec les serveurs d’application pour la fourniture des services.

Le choix du MG de sortie selon l'adresse du destinataire, le type d'appel, la charge du réseau, etc.

La réservation des ressources dans le MG et le contrôle des connexions internes au MG (commande des Media Gateways).

I.2.3.3. Le Signalling Gateway (SG)

La fonction Signalling Gateway a pour rôle de convertir la signalisation échangée entre le réseau NGN et le réseau externe interconnecté selon un format compréhensible par les équipements chargés de la traiter, mais sans l’interpréter (ce rôle étant dévolu au Media Gateway Controller). Notamment, elle assure l’adaptation de la signalisation par rapport au protocole de transport utilisé (ex. : adaptation TDM /IP).

Cette fonction est souvent implémentée physiquement dans le même équipement que la Media Gateway, d’où le fait que ce dernier terme est parfois employé abusivement pour recouvrir les deux fonctions MG + SG.

I.2.4. Les protocoles de NGN

La convergence des réseaux voix/données ainsi que le fait d’utiliser un réseau en mode paquet pour transporter des flux multimédia, ayant des contraintes de « temps réel », a nécessité l’adaptation de la couche Contrôle. En effet ces réseaux en mode paquet étaient généralement utilisés comme réseau de transport mais n’offraient pas de services permettant la gestion des appels et des communications multimédia. Cette évolution a conduit à l’apparition de nouveaux

Chapitre I : Réseau de nouvelle génération (NGN) et voix sur IP (VoIP)

protocoles, principalement concernant la gestion des flux multimédia, au sein de la couche Contrôle. On peut classer les protocoles de contrôle en différents groupes :

Les protocoles de contrôle d’appel permettant l’établissement, généralement à l’initiative d’un utilisateur, d’une communication entre deux terminaux ou entre un terminal et un serveur ; les deux principaux protocoles sont H.323, norme de l’UIT et SIP, standard développé à l’IETF.

Les protocoles de commande de Media Gateway qui sont issus de la séparation entre les

couches Transport et Contrôle, permettent au Softswitch ou Media Gateway Controller de gérer les passerelles de transport ou Media Gateway. MGCP (Media Gateway Control Protocol) de l’IETF et H.248/MEGACO, développé conjointement par l’UIT et l’IETF, sont actuellement les protocoles prédominants.

Les protocoles de signalisation entre les serveurs de contrôle (ou Media Gateway

Controller) permettant la gestion du plan contrôle :

Au niveau du coeur de réseau avec des protocoles tels que BICC (Bearer Independant Call Control), SIP-T (SIP pour la téléphonie) et H.323.

A l’interconnexion avec les réseaux de signalisation SS7, généralement via des passerelles de signalisation ou Signalling Gateways par l’utilisation de protocole tel que SIGTRAN. De plus, l’interconnexion de ces réseaux de données avec les réseaux existants de téléphonie (TDM avec signalisation SS7) a nécessité le développement de protocoles dédiés à l’interconnexion des réseaux et au transport de la signalisation SS7 sur des réseaux en mode paquet.

I.2.4.1. Les protocoles de contrôle d’appel

Deux protocoles candidats :

Protocole H.323

Le standard H.323 de l’UIT-T spécifie les composants, les méthodes et les protocoles pour permettre la communication en temps réel de données multimédia à travers les réseaux à commutation de paquets, notamment les réseaux à technologie IP [2].

H.323 assure la communication entre plusieurs composants du réseau :

Les terminaux H.323 sont des systèmes multimédia (téléphone, PC) permettant de communiquer en « temps réel ». le Gatekeeper gère les terminaux H.323 (identification et traduction d’adresses) et les établissements d’appels La passerelle H.323 (Gateway) permet d’interfacer le réseau IP avec le réseau téléphonique classique. L’unité de contrôle MCU (Multipoint Controller Unit) gère les connexions multipoint (ex. : appels de conférence). Il se décompose en un Multipoint Controller (MC), affecté à

Chapitre I : Réseau de nouvelle génération (NGN) et voix sur IP (VoIP)

la signalisation, et un Multipoint Processor (MP), dédié à la transmission proprement dite.

H.323 s’appuie 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 vidéo : H.261, H.263.

Le protocole SIP

SIP : « Session Initiation Protocol » est un protocole de contrôle qui peut établir, modifier et terminer des sessions multimédia, aussi bien des conférences que des appels téléphoniques sur des réseaux en mode paquets. Il est sous forme de texte, tout comme http ou SMTP, et a pour rôle d’initier des sessions de communications interactives. Ces sessions peuvent inclure aussi bien de la voix, de la vidéo, des jeux interactifs

L'architecture de SIP est basée 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 l’adresse SIP du terminal appelé et la ou les adresses où il pourra effectivement être joignable. Le Proxy Server : remplit la même fonction qu’un Redirect Server. Le Registrar : est essentiel dans tout réseau SIP ou l’on 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 défini par l’IETF (RFC 2705), a été conçu pour des réseaux de téléphonie IP utilisant des passerelles VoIP. Il gère la communication entre les « Media Gateway » et les «Media Gateway Controller ». Ce protocole traite la signalisation et le contrôle des appels, d’une part, et les flux média d’autre part. Les différents éléments qui utilisent MGCP sont :

Signalling Gateway : Elle réalise l’interface entre le réseau de téléphonie (signalisation SS7) et le réseau 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 opère l’enregistrement, la gestion et les contrôles des ressources des Media Gateway. Elle coordonne l’établissement, le contrôle et la fin des flux média qui transitent par le Media Gateway.

Media Gateway (MG) : Il est le point d’entrées ou de sortie des flux média à l’interface avec les réseaux IP et téléphoniques. Elle effectue la conversion des médias entre le mode circuit (téléphonique) au mode paquet (IP).

Chapitre I : Réseau de nouvelle génération (NGN) et voix sur IP (VoIP)

Le protocole alternatif : MEGACO/H.248

Le groupe de travail MEGACO (Media Protocol Control) a été constitué en 1998 pour compléter les travaux sur le protocole MGCP au sein de l’IETF. Depuis 1999, l’UIT et l’IETF travaillent conjointement sur le développement du protocole MEGACO/H.248 ; c’est un standard permettant la communication entre les Media Gateway Controller (MGC) et les Media Gateway (MG). Il est dérivé de MGCP et possède des améliorations par rapport à celui-ci :

Support de services multimédia et de vidéoconférence.

Possibilité d’utiliser UDP ou TCP.

Utilise le codage en mode texte ou binaire.

Une première version de H.248 a été adoptée en juin 2000 (RFC 3015 de l’IETF). L’implémentation de H.248 permet une grande modularité ; en effet, ce protocole est étendu par des « packages » répondant à des besoins spécifiques. Ce système permet de couvrir un nombre très important d’applications, mais complique aussi grandement l’inter fonctionnements d’équipements d’origine différente. Ainsi un constructeur peut implémenter, 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 contrôle

A/ Au cœur de réseau (NGN) BICC (Bearer Independant call control)

Ce protocole a pour objectif la gestion de la communication entre les serveurs de contrôle, indépendamment du type de support, permettant aux opérateurs de réaliser une migration de leurs réseaux RTC/RNIS vers des réseaux en mode paquet.

En vue, donc, d’une migration des réseaux téléphoniques (SS7) vers une architecture NGN, une recommandation de l’UIT, le protocole BICC, doit étendre le protocole de signalisation actuellement implémenté sur les réseaux téléphoniques, l’ISUP. En effet BICC est en grande partie issu de l’ISUP ; les recommandations font d’ailleurs directement référence à l’ISUP, quant à sa définition mais aussi pour l’interopérabilité avec H.323.

La première version de ce protocole, BICC CS1 (BICC Capability Set 1) définit le transport de signalisation sur un réseau ATM en tant que réseau de transit. La seconde version de ce protocole, BICC CS2, élargit énormément son rayon d’action et les capacités. Il permet :

L’utilisation d’un réseau IP comme réseau de transit. Il s’agit de « tunnelling » de messages de signalisation par le protocole BICC sur un réseau de transport IP, de passerelle à passerelle (Signalling Gateway), donc transparent pour les MGC du réseau IP.

Protocole SIP entre Media Gateway Controller: SIP-T

L’Internet Draft SIP-T (SIP pour la téléphonie) de l’IETF définit la gestion de la téléphonie par le protocole SIP ainsi que l’interconnexion avec le RTC : cependant uniquement avec le protocole SS7 ISUP. SIP-T préconise :

Chapitre I : Réseau de nouvelle génération (NGN) et voix sur IP (VoIP)

L’encapsulation des messages ISUP à l’intérieur de messages SIP, permettant la transmission de façon transparente de la signalisation ISUP dans le cas de transit par un réseau IP.

Le renseignement de l’en-tête du message SIP par les informations contenues dans le message ISUP, permettant d’acheminer le message correctement à travers le réseau IP et de terminer les appels sur un terminal SIP.

B/ A l’interconnexion avec les réseaux de signalisation SS7

SIGTRAN (Signalling Transport, Informational : RFC 2719) développé par un groupe de travail de l’IETF. Ce groupe définit le protocole de contrôle entre :

Les Signalling Gateways, qui reçoivent la signalisation SS7 sur TDM, et la convertissent en SS7 sur IP.

Les Media Gateway Controllers, qui interprètent la signalisation SS7 sur IP.

Les « Signalling Points » du réseau IP (serveurs de contrôle d’appel).

Ce protocole utilise une nouvelle couche de transport appelée Stream Control Transmission Protocol (SCTP) permettant de pallier les défauts du protocole TCP pour la gestion des messages de signalisation.

I.3. Exemples des services offerts par les NGNs

Les NGN offrent les capacités, en termes d’infrastructure, de protocole et de gestion, de créer et de déployer des nouveaux services multimédia sur des réseaux en mode paquet. La grande diversité des services est due aux multiples possibilités offertes par les réseaux NGN en termes de :

Support multimédia (données, 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 différents terminaux.

Parmi ces services offerts on cite :

La messagerie instantanée

La messagerie unifiée

La diffusion de contenus multimédia

La voix sur IP (VoIP)

… .

On se concentrera dans cette section à la présentation du service de la voix sur IP qui fait une importance partie pour l’élaboration de l’objet de notre projet de fin d’étude.

Chapitre I : Réseau de nouvelle génération (NGN) et voix sur IP (VoIP)

I.4. La Voix sur IP (VoIP)

I.4.1. Définition et vue d’ensemble

VoIP signifie textuellement Voice Over IP, en français : Voix sur IP. Le principe consiste à encapsuler un signal audio numérisé (en général la voix) dans le protocole IP (Internet Protocol). La principale application de ce principe est la téléphonie Internet (téléphonie IP).A la différence des téléphones analogiques filaires (RTC) distribués par les centraux téléphoniques, la VoIP permet d'étendre la téléphonie sur tout réseau numérique ou analogique acceptant le protocole TCP/IP (Ethernet, RNIS, PPP, etc.).

La transmission de la voix sur IP « Voice Over IP - VoIP » consiste essentiellement à considérer les échantillons de voix comme des données particulières également susceptibles d’être transportées de façon banalisée sur un réseau IP. L’approche VoIP s’applique donc au transport de la voix sur Internet, sur un Intranet d’entreprise ou dans le cadre d’un Extranet. La transmission de la voix par l’intermédiaire du protocole IP a débuté avec IBM en 1996 sous la forme d’applications dites de téléphonie sur Internet (Internet Telephony) permettant à deux internautes de communiquer oralement via leur PC. Ces premières applications étaient caractérisées par une qualité de voix très mauvaise: retards importants souvent supérieurs à une seconde, échos, paroles saccadées, qui en rendaient l’intérêt essentiellement expérimental et ludique.

Vu l’évolution profonde du secteur de télécommunication et l’introduction du concept NGN, la voix sur IP est considéré un service directement lié ce nouveau paradigme. C’est un service qui est apparue depuis longtemps mais qui n’a pas encore eu le succès escompté, et cela pour différentes 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 déployer de services téléphoniques sur IP. Le seul fait de transporter la voix sur IP n’apporte pas de valeur ajoutée pour l’utilisateur final, par rapport au service de voix classique. Les services associés à la voix sur IP n’ont pas encore la maturité nécessaire pour pousser l’évolution vers ces nouveaux réseaux. La nécessité d’interconnecter les réseaux IP aux réseaux TDM/SS7 implique des coûts liés aux équipements d’interconnexion (passerelles) et le prix des terminaux (IP phones) annihile l’avantage financier apporté par le transport en IP. Le coût des terminaux IP reste encore supérieur à celui des équipements classiques (pas encore d’économies d’échelle suffisantes).

Cependant l’évolution de la technologie et des protocoles et l’apparition de services associés au monde IP devraient permettre l’émergence de la voix sur IP. De plus, l’évolution des terminaux communicants multimédia est un argument supplémentaire à l’évolution des réseaux téléphoniques vers la voix sur IP ; ainsi l’UMTS, dans le release 5, généralise le transport en IP au réseau voix.

Chapitre I : Réseau de nouvelle génération (NGN) et voix sur IP (VoIP)

I.4.2. Principaux composants d’architecture VoIP

Les principaux composants fonctionnels d’une solution de communication IP sont [4] :

La capacité de commutation n'est plus dévolue à la matrice de commutation d'un PABX et s'appuie sur les équipements de réseau local et étendu. Elle n'est pas dédiée à la fonction PABX et peut être issue d'un autre constructeur, elle évolue naturellement en fonction de l’évolution du réseau. Livre blanc : Communications IP La fonction de signalisation, de gestion des abonnés et des fonctionnalités téléphoniques est dévolue à un ou plusieurs serveurs hébergeant l'application LAN PBX. Il s’agit généralement d’un serveur entièrement standardisé et exploité sous Linux ou Windows 2000. La voix ne transite pas par ce serveur. Cette solution est généralement complétée par des équipements contrôleurs de média en charge de la compression, la paquetisation ou le mixage (conférence) des flux voix, vidéos et données. Les clients peuvent être des téléphones respectant le standard Ethernet (filaire ou wireless) ou par des logiciels installés sur des postes de bureautiques (Softphones), des PDA. Les clients peuvent néanmoins vouloir utiliser leurs combinés mobiles, des équipements de visioconférences, des logiciels de messagerie instantanée, etc., pour communiquer. L'accès au réseau, l'intégration d'équipements de téléphonie classique est réalisé par des passerelles intégrées dans des équipements dédiés, des routeurs, des commutateurs LAN, etc. Cette infrastructure peut être complétée par des applications (messagerie, serveur vocal interactif, etc.) entièrement logicielles et dialoguant sur IP avec le reste de l'infrastructure de téléphonie.

IP avec le reste de l'infrastructure de téléphonie. Figure I.3 : Principaux composants d’une solution de

Figure I.3 : Principaux composants d’une solution de communication IP

Chapitre I : Réseau de nouvelle génération (NGN) et voix sur IP (VoIP)

I.4.3. Architecture VoIP

Le

communication IP

schéma

suivant

représente

les

différents

blocs

utilisés

lors

de

l’établissement

d’une

différents blocs ut ilisés lors de l’établissement d’une Figure I.4 : Architecture VoIP Sup’Com 2006/2007 14
différents blocs ut ilisés lors de l’établissement d’une Figure I.4 : Architecture VoIP Sup’Com 2006/2007 14

Figure I.4 : Architecture VoIP

Chapitre I : Réseau de nouvelle génération (NGN) et voix sur IP (VoIP)

I.4.4. Caractéristiques de la Voix

Le système vocal est complexe et basé sur des ondes sonores de fréquences différentes. Le spectre des fréquences perçues par l’oreille humaine s’étale de 100 Hz à 20 KHz. Cette fourchette est, cependant, à réduire si l’on veut distinguer les fréquences utiles des fréquences audibles. En effet, la quasi-totalité d’un message sonore est compréhensible dans la fourchette 330-3400 Hz. Qui est d’ailleurs utilisée par le téléphone standard [3].

I.4.4.1. Un sens délicat

Contrairement à la vue, l’ouie est plus exigeante. En effet, un film dont le rafraîchissement serait 25 images/sec, ne troublerait pas une personne habituée à 30 images/sec. De même, la qualité d’une image photographique argentique comparée à celle d’un appareil numérique, bien que différente pour les puristes, peut être acceptée.

Si l’on se concentre sur l’aspect conversation orale, on remarque, d’après différentes études, que la marge de manoeuvre est beaucoup plus réduite et une dégradation au-delà de 10% pourrait être néfaste.

I.4.4.2. La conversation orale : une exigence d’interactivité

Une conversation entre deux personnes respecte deux principes : intelligibilité et interactivité. Couper la parole à quelqu’un ne se fait pas, mais c’est un gage d’interactivité et de dialogue. En termes de transmission numérique, cela se traduit par le terme duplex. Une conversation full duplex assure cette interactivité car chaque locuteur peut parler en même temps, ce qui arrive quand deux personnes parlent de leur propre expérience sans s’écouter…

I.4.5. Les paramètres de la voix sur IP

Les aspects déterminants pour la qualité de la voix sur un réseau sont le traitement de la voix, la clarté, le délai de bout en bout et l’écho. Ils dépendent des différents composants de la chaîne de transmission, de leur paramétrage, de l’architecture générale de la chaîne, 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 traitée, c'est-à-dire codée et éventuellement compressée, avant d'être transmise.

La clarté et la mesure de fidélité de la voix reçue par rapport à la voix émise.

Le délai de bout en bout est le temps de propagation de la voix à travers le réseau de l’émetteur vers le récepteur.

L’écho est le son émis par l’émetteur qui lui revient.

La problématique de qualité de la voix sur IP est particulière car la voix attend de son transporteur autre chose que les données. La transmission de données classique (fichiers, messages, transactions …) ne supporte aucune perte en ligne sous peine de graves conséquences pour l’interprétation et l’utilisation de ces données par l’équipement récepteur, mais elle supporte en revanche une dérive importante en termes de durée d’acheminement. Peu importe qu’un paquet arrive avec 100 ms de retard. Le comportement attendu pour la voix est exactement inverse : 1% ou 2% de perte de données de voix en ligne ne sont pas trop gênants pour la qualité du service de VoIP, mais en revanche une variation fréquente de 100 ms sur le délai de transit est catastrophique et rend le service inutilisable.

Chapitre I : Réseau de nouvelle génération (NGN) et voix sur IP (VoIP)

La voix attend donc du transport IP l’inverse de ce qu’exigent les données. Et cette formulation n’est qu’un raccourci car en fait le transport de la voix exige beaucoup plus : il bénéficiera évidemment de l’intégrité exigée pour le transport des données laquelle est garantie par les réseaux modernes bien qu’il puisse s’en affranchir dans une certaine limite mais exigera beaucoup plus au niveau des autres paramètres, notamment en ce qui concerne la stabilité du réseau dans le temps.

Nous présenterons à la suite les principaux paramètres influents en VoIP, dans l’ordre les échantillonnages (codecs), le délai de transit, la gigue de phase et les pertes de données.

I.4.5.1. Les différents échantillonnages

Le paramètre d’échantillonnage ou codecs (pour compression / décompression) est structurant en VoIP. Le codec détermine à quelle vitesse la voix est échantillonnée et dimensionne par la même le flux de données numériques que va générer la transformation d’un échantillon temporel de voix analogique. Les codecs sont répertoriés par leur nom à l’ITU. Les codecs les plus utilisés et leurs vitesses d’échantillonnage sont les suivants [5] :

Codecs

Vitesse d’échantillonnage

G.711

64

Kbps

G.726

32

Kbps

G.726

24

Kbps

G.728

16

Kbps

G.729

8 Kbps

G.723.1 MPMLQ

6.3

Kbps

G.723.1 ACELP

5.3

Kbps

Tableau I.1 : Codecs en fonction de leurs vitesses d’échantillonnage

Le choix du codec est un compromis entre la qualité de services souhaités et la capacité de l’infrastructure IP à délivrer une bande passante et des paramètres de QoS qui vont impacter cette qualité. Le paramètre le plus déterminant auquel on s’intéresse pour commencer est la bande passante que l’on met en regard du nombre de communications simultanées à écouler. Le tableau suivant permet d’effectuer rapidement le bilan de bande passante en fonction du codec choisi :

 

Echantillonnage (codec)

 
     

Délai

 

Codec

Débit

Intervalle

volume de données de voix par échantillonnage de codec (octets)

(kbps)

échantillonnage

échantillonnage

(ms)

(ms)

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

Chapitre I : Réseau de nouvelle génération (NGN) et voix sur IP (VoIP)

 

Calcul de bande passante nécessaire

 

volume

               

de

Duré de

Bande

Bande

donnée

donnée

Nombre

Bande

Bande

passant

passant

s de

s de

de

passante

passante

e

e

voix

voix

paquet

Bande

Ethernet

Bande

Ethernet

RTP/IP

RTP/IP

dans

dans

par

passante

avec

passante

avec

pour 10

pour 32

RTP

RTP

second

IP/UDP/RT

IP/UDP/RT

IP/UDP/cRT

IP/UDP/cRT

canaux

canaux

(octets)

(ms)

e

P (kbps)

P (kbps)

P (kbps)

P (kbps)

(kbps)

(kbps)

160

20

50

80.0

87.2

65.6

72.8

800

2560

80

20

50

48.0

55.2

33.6

40.8

480

1536

60

20

50

40.0

47.2

25.6

32.8

400

1280

60

30

33

26.7

31.5

17.1

21.9

267

853

20

20

50

24.0

31.2

9.6

16.8

240

768

24

30

33

17.1

21.9

7.5

12.3

171

546

20

30

33

16.0

20.8

6.4

11.2

160

512

Tableau I.2 : Bilan de bande passante en fonction du codec

Le choix du codec G.711 permet de bénéficier à réseau 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 délai de transit

Le délai de transit (ou end-to-end delay dans la dénomination anglo-saxonne) est un des paramètres critiques influençant fortement la QoS d’un service de voix sur IP. C’est le temps que va mettre en moyenne un paquet IP contenant un échantillon de voix pour traverser l’infrastructure entre deux interlocuteurs. Ce temps de transit comporte quatre composantes :

Le délai d’échantillonnage.

Le délai de propagation.

Le délai de transport.

Le délai des buffers de gigue.

Le délai d’échantillonnage est la durée de numérisation de la voix à l’émission puis de conversion en signal voix à la réception. Ce temps dépend 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 délai de propagation est la durée de transmission en ligne des données numérisées. Cette durée est normalement très faible par rapport aux autres composantes du délai de transit, de l’ordre de quelques millisecondes.

Le délai de transport est la durée passée à traverser les routeurs, les commutateurs et les autres composants du réseau et de l’infrastructure de téléphonie IP. L’ordre de grandeur est de plusieurs dizaines de millisecondes.

Chapitre I : Réseau de nouvelle génération (NGN) et voix sur IP (VoIP)

Le délai des buffers de gigue est le retard introduit à la réception en vue de lisser la variation de temps de transit, et donc de réduire la gigue de phase. L’ordre de grandeur est de 50 ms. Les éléments d’infrastructure, 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 conséquence du fait que tous les paquets contenant des échantillons de voix ne vont pas traverser le réseau à la même vitesse. Cela crée une déformation de la voix ou un hachage. La gigue de phase est indépendante du délai de transit. Le délai peut être court et la gigue importante ou inversement. La gigue est une conséquence de congestions passagères sur le réseau, ce dernier ne pouvant plus transporter les données de manière constante dans le temps. La valeur de la gigue va de quelques ms à quelques dizaines de ms.

I.4.5.4. La perte de données

La transmission de la voix par paquets s’appuie sur le protocole RTP (Real-Time Transport Protocol). Ce dernier permet de transmettre sur IP les paquets de voix en reconstituant les informations même si la couche de transport change l'ordre des paquets. Il utilise pour cela des numéros de séquence et s’appuie sur UDP.

Les contraintes temps réel de délai de transit évoquées plus haut rendent inutile la retransmission des paquets perdus : même retransmis un datagramme RTP arriverait bien trop tard pour être d’une quelconque utilité dans le processus de reconstitution de la voix. En voix sur IP on ne retransmet donc pas les données perdues. Ces pertes de données VoIP sont dues aux congestions sur le réseau, qui entraînent des rejets de paquets tout au long du réseau, ou à une gigue excessive qui va provoquer des rejets de paquet dans les buffers de gigue du récepteur, ceux-ci ne pouvant pas accueillir tous les paquets arrivés en retard.

Une perte de données régulière mais faible est moins gênante en voix sur IP que des pics de perte de paquets espacés mais élevés. En effet l’écoute humaine s’habituera à une qualité moyenne mais constante et en revanche supportera peu de soudaines dégradations de la QoS.

Le taux de perte en VoIP est typiquement de quelques pourcents ou dixièmes de pourcent.

I.4.6. Les défauts de la communication IP

Il n’est pas facile de transformer un réseau d’échange de données en une architecture de transmission synchrone, à débit constant, pour les applications critiques telle que la téléphonie. La qualité de service reste donc la question centrale de la voix sur IP. Les principaux défauts de la transmission IP sont :

Le délai : le délai doit rester inférieur à 400 ms aller-retour pour satisfaire les critères d’interactivité d’une communication téléphonique.

La gigue : c’est la variation de délai, ce dernier pourrait être constant ce qui préserve la synchronisation du signal entre l’émetteur et le récepteur ou variable ce qui détruit la base de temps du signal et oblige le destinateur de maintenir une mémoire tampon de resynchronisation.

Chapitre I : Réseau de nouvelle génération (NGN) et voix sur IP (VoIP)

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 phénomène d’écho devient gênant lorsque le temps d’aller retour du signal dépasse 40 ou 50 ms.

La fiabilité des équipements : l’industrie des télécommunications est habituée à une fiabilité de cinq chiffres 99,999% tandis que celle du réseau des données est 80%.

I.5. Conclusion

Il ressort de notre première étude qu’au niveau de la couche Contrôle, les principales incertitudes concernent le choix des protocoles. En effet, pour chaque domaine concerné, deux ou plusieurs protocoles sont en général en lice, l’un plus ancien et plus proche de l’héritage «téléphonie», et l’autre plus récent et plutôt hérité du monde Internet. Cette situation soulève immanquablement la question de l’interopérabilité à court/moyen terme entre solutions implémentant des protocoles différents.

Quant à la VoIP le principal challenge pour un tel service est de satisfaire les besoins des utilisateurs. Ces derniers sont en effet habitués à la qualité de service délivrée par les systèmes téléphoniques traditionnels et accepteraient difficilement une solution, même économique, présentant une dégradation sensible de cette qualité de service.

Dans ce premier chapitre, nous avons présenté les protocoles de signalisation ainsi que la notion de la VoIP d’une façon général, le chapitre suivant fera l’objet d’une description détaillé des différents protocoles de contrôle d’appel, de leurs architectures et de leurs spécificités, ainsi que la représentation de notion d’application vocale et de principe de langage VoiceXML.

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

Chapitre II

de signalisat ion de VoIP et le langage VoiceXML Chapitre II Les protocoles de signalisation de

Les protocoles de signalisation de VoIP et le langage VoiceXML

le langage VoiceXML Chapitre II Les protocoles de signalisation de VoIP et le langage VoiceXML Sup’Com
le langage VoiceXML Chapitre II Les protocoles de signalisation de VoIP et le langage VoiceXML Sup’Com

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

Chapitre II

Les protocoles de signalisation de VoIP et le langage VoiceXML

II.1. Introduction

La signalisation est une des plus importantes fonctions dans l’infrastructure des télécommunications puisqu’elle permet aux composants du réseau de communiquer entre eux pour établir et terminer des appels. La voix sur IP, par exemple, dont le but est d’établir des canaux de communication vocaux entre utilisateurs, requiert alors l’utilisation des protocoles de signalisation pour initier et terminer les appels.

Nous nous intéressons dans une première section de ce chapitre à l’étude de différents protocoles spécifiant par une architecture centralisée et distribuées, ainsi qu’une étude comparative entre ces différents protocoles. La deuxième section fera l’objet de l’étude de langage Voice XML et de la notion d’application vocale.

II.2. Les protocoles de contrôle d’appel

Le VoIP utilise plusieurs protocoles de contrôle d’appel pour l’établissement des communications IP ainsi pour la transmission de flux de données. Il existe : l’architecture centralisée et l’architecture distribuée

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

II.2.1. Architecture centralisée

Ce modèle est fort proche de la philosophie des opérateurs de télécoms traditionnels. Il considère que l'intelligence et les fonctionnalités sont uniquement localisées au sein du réseau! Ainsi, les terminaux utilisateurs (téléphones analogiques, GSM, etc.) sont "ignorants" et offrent peu ou pas de fonctionnalités propres. Par exemple, si un abonné désire faire un transfert inconditionnel d'appels vers un autre poste, c'est au central téléphonique de l'opérateur (ou le PABX privé) qu'incombe cette tâche. 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 opérateur

Les caractéristiques d'une telle architecture sont les suivantes:

L'intelligence est au sein du réseau. Les terminaux des utilisateurs sont relativement "ignorants". La gestion est centralisée. La réservation des ressources et la signalisation des communications sont similaires à celle du PSTN. Peu de possibilités de fonctionnalités sur les terminaux utilisateurs.

Les relations au sein d'une architecture centralisée sont souvent qualifiées de "maître/esclave".

sont souvent qualifiées de " maître/esclave ". Figure II.1 : Intelligence uniquement auprès des

Figure II.1 : Intelligence uniquement auprès des "maîtres"

Parmi les protocoles existants pour ce type d'architecture, on retiendra :

II.2.1.1. MGCP- Media Gateway Control Protocol

Définit des protocoles de commande de passerelles de conversion de flux multimédia, le protocole MGCP sert à l’échange de messages de signalisation entre un contrôleur de passerelles de médias et des passerelles réparties dans un réseau IP. Pour l'établissement et la terminaison

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

des sessions, MGCP se sert de signaux et événements. MGCP met en ouvre un organe central de gestion des appels et s'appuie sur des terminaux simplifiés à l'extrême. La standardisation de MGCP a été stoppée pour faire place à MEGACO/H.248 ((Media Gateway Control Protocol).

Exemple :

Media Gateway Controller
Media Gateway
Controller

RTC

Media Gateway
Media Gateway

IP

Exemple : Media Gateway Controller RTC Media Gateway IP Flux PCM 64 Kb/s Flux RTP Transformation

Flux PCM

64 Kb/s

Flux RTP

Transformation d’une voie téléphonique (RTC) en une voie téléphonique IP. C’est une approche reposant sur la séparation de la logique de contrôle des supports multimédia.

II.2.1.2. MEGACO/H.248

Media Gateway Control (Megaco H.248): c'est le fruit d'une collaboration conjointe entre l'ITU- T Study Group16 et l'organisme IETF. L'IETF identifie ce protocole comme "MEGACO" alors que l'ITU le référence comme l'H.248. Ce protocole est considéré comme la nouvelle génération de MGCP. Cette technologie de signalisation est destinée à initier les communications entre un Media Gateway (MG: le terminal sans intelligence) et un Media Gateway Controller (MGC: le centre névralgique de l'intelligence) au travers d'un réseau de données IP.

II.2.1.3. Net2Phone

Net2Phone: c'est un vétéran (1995) et un leader des outils de téléphonie pour PC. Il utilise une technologie propriétaire qui permet de réaliser 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 téléphonique 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 propriétaire développé par CISCO. Ce protocole est utilisé pour le CISCO Call Manager et les téléphones IP.

II.2.2. Architecture distribuée

Le modèle est proche de la philosophie utilisée au sein de l'Internet. Dans ce modèle, les architectures informatiques sont scindées en de multiples entités afin de déléguer les tâches à accomplir aux systèmes les plus adaptés à leur réalisation: par exemple le DNS pour la localisation de services. Dans un mode distribué, les terminaux utilisateurs offrent en outre de nombreuses fonctionnalités et services. Ainsi, si un abonné désire utiliser un service de rejet d'appels sélectif, il peut le faire directement via un terminal qui lui est associé, sans intervention d'une tierce partie.

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

Les caractéristiques d'une telle architecture sont:

Intelligence distribuée entre les terminaux utilisateurs et les équipements de

signalisation disponibles au sein du réseau. Les terminaux sont les téléphones IP, les PC ou les passerelles VoIP.

Les systèmes sont flexibles et il est aisé d'ajouter un nouveau service.

Les systèmes sont plus complexes.

Les relations au sein d'une architecture distribuée sont souvent qualifiées de "client/serveur".

sont souvent qualifiées de "client/serveur". Figure II.2 : Intelligence partagée entre les serveurs et

Figure II.2 : Intelligence partagée 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 développement du multimédia sur les réseaux, il est devenu nécessaire de créer des protocoles qui supportent ces nouvelles fonctionnalités, telles que la visioconférence : l’envoi de son et de vidéo avec un souci de données temps réel. Le protocole H.323 est l’un d’eux. Il permet de faire de la visioconférence sur des réseaux IP.

Le standard H.323 a été conçu par l’ITU-T. Il fait partie d’une série de recommandations qui décrivent des transmissions multimédia mais sur des réseaux différents. Il spécifie les composants, protocoles et procédures permettant la mise en place d’un service multimédia sur des réseaux à paquets commutés sans garantie de bande passante. Ce standard est valable pour

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

VoIP car il permet de transmettre uniquement la voix ou un mélange de voix et de données. Il est constitué par un ensemble de protocoles permettant des communications entre plusieurs entités du réseau. Ces entités sont les Gateways, Gatekeeper, les terminaux et les unités de contrôle multipoint MCU. La figure suivante montre un réseau doté d’équipements basés sur le modèle H.323. Nous allons décrire par la suite le rôle de chacun de ces équipements [6], [7].

la suite le rôle de chacun de ces équipements [6], [7]. Figure II.3 : Topologie d'un

Figure II.3 : Topologie d'un réseau VoIP – H.323

II.2.2.1.1. Les différents composants de H.323

H.323 est un protocole de communication englobant un ensemble de normes et composants utilisés pour l’envoi de données audio et vidéo sur Internet et parmi ces composants on retiendra :

Les terminaux H.323

Les terminaux sont des clients dans un réseau H.323. Ce sont des systèmes d’audio (Téléphone IP, PC) ou de vidéo conférence utilisés pour communiquer en temps réel. Le standard H.323 requiert que chaque terminal supporte un certain nombre de fonctions (voir Figure II.4) et de codeurs qui ont été définis par l’ITU, 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 fonctionnalités supplémentaires, tels que des codeurs audio/vidéo, le protocole T.120 pour la data-conférence et des fonctionnalités de qualité de service. Cependant, la multiplicité des options rend difficile l’interopérabilité des différents terminaux H.323.

Les passerelles (GW : Gateway)

La passerelle ou « Gateway » gère l’interconnexion entre le réseau IP et le réseau téléphonique classique ; elle fournit une traduction entre des formats de transmission aussi bien de signalisation que de flux multimédia. Le Gateway établit et termine les appels aussi bien du côté du réseau IP que du côté du réseau téléphonique. Elle peut aussi effectuer le transcodage entre

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

les formats audio, vidéo ou data. Une passerelle possède les mêmes fonctionnalités qu’un terminal H.323 sur le réseau IP, et aussi celles d’un terminal téléphonique sur le réseau de téléphonie.

terminal téléphonique sur le réseau de téléphonie. Figure II.4 : Diagramme fonctionnel d’une passerelle Les

Figure II.4 : Diagramme fonctionnel d’une passerelle

Les portiers (GK : Gatekeeper)

Le Gatekeeper, qui est un équipement optionnel dans un système H.323, fournit un service de contrôle d’appel pour les terminaux H.323. Plusieurs Gatekeepers peuvent être présents sur un réseau et communiquer les uns avec les autres. Le Gatekeeper est séparé des autres terminaux, cependant il peut être physiquement implémenté avec un terminal, un Gateway ou un autre élément du réseau non-H323.

un Gateway ou un autre élément du réseau non-H323. Figure II.5 : Diagramme fonctionnel d’un Gatekeeper

Figure II.5 : Diagramme fonctionnel d’un Gatekeeper

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

Le Gatekeeper fournit les services suivants :

Traduction d’adresse : Le Gatekeeper fait la traduction de l’alias H.323 en une adresse de transport (adresse IP + port) Cela est effectué grâce à une table qui est rafraîchie par les messages d’enregistrement (Registration message).

Contrôle d’admission : Le Gatekeeper autorise l’accès au réseau par les messages H.225 (ARQ/ACF/ARJ). Ce contrôle peut être basé sur l’autorisation d’appel, la bande passante disponible ou d’autres critères fixés par l’administrateur.

Gestion de zone : Le Gatekeeper doit garantir tous les services décrits précédemment pour les terminaux enregistrés.

Contrôle de bande passante: Le Gatekeeper peut refuser l’établissement d’un appel pour cause de limitation de bande passante.

Signalisation de contrôle d’appel: Le Gatekeeper peut choisir de faire la signalisation d’appel avec le terminal par lui-même ou de rediriger le terminal pour qu’il établisse un «canal» de signalisation directement avec l’autre terminal. De cette façon, cela permet d’éviter au Gatekeeper de gérer les appels H.225.

Autorisation d’appel: Par l’intermédiaire de la signalisation H.225, le Gatekeeper peut accepter ou refuser une demande d’appel émise par un terminal.

Gestion des appels: Le Gatekeeper peut recenser les appels en cours dans la zone qu’il gère et connaître l’état dans lequel les différents appels se trouvent.

Les unités de contrôle multipoints (MCU)

Le « Multipoint Controller Unit » gère les connexions multipoint (ex : appels de conférence). Il se décompose en un Multipoint Controller (MC), affecté à la signalisation, et un Multipoint Processor (MP), dédié à la transmission proprement dite.

Processor (MP), dédié à la transmission proprement dite. Figure II.6 : Diagramme fonctionnel d’une MCU Sup’Com

Figure II.6 : Diagramme fonctionnel d’une MCU

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

II.2.2.2. Le protocole SIP (Session Initial Protocol)

Le protocole SIP (session initial Protocol) est développé par le groupe MMUSIC (Multiparty Multimedia Session Control) : Ensemble de standards développés pour le support de conférences Internet multimédia « faiblement contrôlées » pour l’établissement et la supervision de conférences multimédia, peut être comparé à un protocole d’établissement d’appel, il permet d’associer des supports audio, vidéo et de données à une session multimédia.

Le protocole SIP (normalisé par l’IETF, R.F.C 2543) est un protocole de signalisation appartenant à la couche application du modèle OSI et il est apparenté au protocole HTTP. Son rôle est d’ouvrir, modifier et libérer les sessions. L’ouverture de ces sessions permet de réaliser de l’audio ou vidéoconférence, de l’enseignement à distance, de la voix (téléphonie) et de la diffusion multimédia sur IP essentiellement.

SIP est rapidement apparu comme une alternative à H.323. SIP est indépendant du protocole de transport utilisé. Il utilise le protocole SDP (Session Description Protocol) pour la description des communications média.

II.2.2.2.1. Topologie de protocole SIP

L'architecture de SIP est basée sur des relations client/serveur. Il spécifie plusieurs entités du réseau sur lequel il opère. Ces principales entités sont : les terminaux (User Agent), les serveurs Proxy SIP, les serveurs de redirection, les serveurs d’enregistrement, les passerelles. Les serveurs SIP intermédiaires peuvent se comporter comme Proxy serveur ou serveur de redirection.

Serveur de re-direction Serveur Proxy SIP d’enregistrement SIP PSTN/ou Mobile Clients Passerelle SIP SIP
Serveur de
re-direction
Serveur
Proxy SIP
d’enregistrement
SIP
PSTN/ou
Mobile
Clients
Passerelle
SIP
SIP

Serveur de

localisation

Figure II.7 : Topologie d'un réseau VoIP – SIP

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

Les terminaux

Les terminaux sont donc des appareils pouvant émettre et recevoir de la signalisation SIP. On distingue essentiellement deux types de terminaux : les téléphones ou les PC équipés d’un logiciel adéquat, d’une carte son, d’un microphone, etc. Un terminal SIP doit disposer d’un agent qui devient client lorsqu’il émet des requêtes et reçoit des réponses (UAC User Agent Client) et par conséquent son partenaire devient serveur (UAS User Agent Serveur) puisqu’il répond à ces requêtes. Les terminaux peuvent communiquer directement entre eux ou par l'intermédiaire d'autres serveurs.

Les serveurs Proxy SIP

Le serveur Proxy joue le rôle de serveur d’un côté (réception de requête) et de client de l’autre (envoi de requête). Un serveur Proxy peut transmettre une requête, sans changement, à la destination finale ou éventuellement modifier certains paramètres. Il renseigne le champ «via» à chaque fois qu’une requête passe par lui afin que la réponse puisse prendre le même chemin au retour ; ce qui ne serait pas possible avec le protocole UDP.

Le Proxy peut aussi dans certains cas être chargé d’effectuer d’autres tâches telles que l’authentification, l’autorisation, la gestion des taxes, etc.

l’autorisation, la gestion des taxes, etc. Figure II.8 : Proxy SIP Alors le Proxy SIP reçoit

Figure II.8 : Proxy SIP

Alors le Proxy SIP reçoit une requête SIP, modifie son entête, la transmet au Proxy suivant ou à l’agent final. Il permet l’acheminement des messages SIP. Existe en version stateful et stateless suivant qu’il garde ou non des informations au cours des sessions.

Les serveurs de redirection

Un serveur de redirection répond à une requête SIP « Invite ». Il établit la correspondance entre l’adresse SIP du terminal appelé et la ou les adresses où il pourra effectivement être joignable. Le serveur redirection n’est pas chargé d’accepter les appels ni d’émettre des requêtes. Il ne fait que répondre aux requêtes émises par des terminaux SIP appelants.

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

C’est un serveur réalisant une association d’adresses vers une ou plusieurs nouvelles adresses. Un Redirect Server est consulté par l’UAC comme un simple serveur et ne peut émettre de requêtes contrairement au Proxy Server.

Les serveurs d’enregistrement

Un serveur d’enregistrement ou registrar est un serveur qui traite les requêtes « Register » et peut aussi avoir la fonction de Proxy. Sa fonction est de connaître l’endroit 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 d’une adresse SIP, il faut faire une correspondance avec une adresse IP qui peut être variable (mobilité IP) : c’est le rôle 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 assurée par le service de localisation.

II.2.2.2.2. Les messages SIP

II.2.2.2.2.1. Les requêtes de base SIP

Les requêtes de base SIP appelés encore « méthodes », sont au nombre de six. Ces requêtes de base permettent de localiser, d’adresser un élément du réseau et lui transmettre les informations de signalisation :

Invite : Ce message est une demande d’établissement de liaison. Le type de session, l’adresse IP, le port, et le type du codec sont inscrits dans le corps du message. L’envoi d’un message « invite » durant une session existante donne lieu à une réinvitation et est utilisé pour la modification des paramètres 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 médias, alors le ACK devra les contenir. Options : Demande à un autre agent ces comptabilités, la réponse contiendra la liste des méthodes qu’il supporte, ces codecs etc. L’agent questionné répondra à ce message comme s’il s’agissait d’une invite. Bye : Termine une communication, l’agent stop l’envoi de paquets de type media (RTP). Cancel : Termine une communication en cour d’établissement. Register : Permet à un agent de s’enregistrer ou de mettre à jour sa localisation et sont URL auprès d’un serveur d’enregistrement, celui-ci pourra à son tour mettre à jour le serveur de localisation, ces données seront utilisées pour la redirection des communications.

II.2.2.2.2.2. Les autres requêtes SIP

Afin d’étendre les possibilités de SIP des nouvelles méthodes ont été ajoutée, actuellement on peut en compter 8 mais il est vraisemblable que cette liste va s’agrandir au fil du temps :

Info : Est utilisé pour transmettre de la signalisation, exemple signaux en provenance du Gateway PSTN.

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

Refer : Permet à un agent de demander à un autre agent d’exécuter une requête particulière. Prack : Ce message et une confirmation à un message de réponse temporaire.

Comet : Est utilisé pour annoncer à un agent qu’il doit avertir l’utilisateur que certaines conditions (ex. QoS etc.) ont été réunies. Subscribe : Permet de s’inscrire de façons à être informé lors de l’exécution d’un événement donné. Unsubscribe : Annule une inscription préalable. Notify : Est utilisé pour informer les utilisateurs inscrits que un événement a eu lieu. Message : Permet l’envoi d’un 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 Inconvénients H323, SIP et MGCP

   

Avantages

 

Inconvénients

 

Simple à mettre en œuvre, messages écrits en clair Interopérabilité très bonne Grâce à CPL (Call Processing Language) qui utilise XML, il est très facile d’ajouter des services intelligents de redirection Très bonne possibilité de gestion de la mobilité Utilisé pour la téléphonie 3G (UMTS)

Pas encore de grande référence Service supplémentaire de téléphonie inexistant En pleine maturation

SIP

 

 

 

Maturité du protocole: Actuellement version 4 pour la définition. Les premières mises en œuvre de V3 commencent juste à apparaître Beaucoup de constructeurs utilisent

H.323

Protocole très complexe, manque d’inter-opérabilité Difficultés avec les Firewall Support des fonctions avancées de la téléphonie. Pas dans l’esprit « Internet »

H323

Peut supporter autre chose que IP, existe aussi sur ATM

 

Permet d’utiliser des téléphones « idiots » Indépendant des protocoles de signalisation supérieurs (H.323, SIP) Bien pour les opérateurs voulant faire du RTC-IP-RTC

Pas encore de grande référence Service supplémentaire de téléphonie inexistant En pleine maturation

MGCP

Tableau II.1 : Avantages et inconvénients des protocoles de signalisations de VoIP [8].

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 définissons une application vocale comme une application informatique utilisant la parole pour réaliser/accomplir certaines tâches. Dans ce type d'applications, l'utilisateur peut dialoguer avec l'application en utilisant seulement les mots clés, une phrase courte et simple, … ou toute la complexité de la langue

Nous présentons dans cette section, tout d’abord, la notion de VoiceXML, ses avantages, ainsi que ses inconvénients. Nous donnons, en conclusion, des remarques importantes qui nous motivent pour faire plus de recherches portant sur le système de dialogue.

II.4.1. Introduction

VoiceXML est le nom d'une norme de technologie proposée initialement par le forum de VoiceXML [9]. Elle est basée sur des veilles technologies telles que VoXML de Motorola et de SpeechML d'IBM, pour créer une nouvelle façon d’interagir avec des applications via une interface vocale, en apportant les avantages de développement du WEB aux applications interactives par la parole.

La première version de VoiceXML a été élaborée par AT&T, Lucent Technologies, Motorola, et IBM et approuvée par le W3C en mars 2000. La deuxième version est également apparue avec l’aide des membres du groupe « Voice Browser » du W3C [10].

Au point de vue technique, VoiceXML est considéré comme un langage qui permet d’intégrer aisément la téléphonie et l’Internet. Il s'agit d'un interpréteur (browser) vocal de pages dans une forme dérivée du XML. Un interpréteur de ce type possède une connexion au réseau téléphonique d'un côté, une connexion au réseau Internet de l’autre, 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 synthèse de la parole, la reconnaissance de la parole et l'annulation d'écho.

L’objectif principal de VoiceXML est premièrement d’apporter tous les avantages de développement de services Web à des systèmes d’application utilisant la parole pour interagir, et deuxièmement de permettre au développeur de programmer et de gérer des ressources au haut niveau. De plus, VoiceXML vise à satisfaire les besoins suivants :

Minimiser les interactions client/serveur en précisant plusieurs interactions par document.

Séparer le code d’interaction d’utilisateur (VoiceXML) de la logique (scripts CGI Common Gateway Interface).

Favoriser la portabilité de service à travers des plates-formes d’implémentation. 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 possibilités pour supporter des dialogues complexes.

Les documents VoiceXML couvrent donc les éléments suivants : sortie pour la synthèse de la parole TTS (Text To Speech), sortie des fichiers sonores, reconnaissance d'entrée parlée, reconnaissance d'entrée DTMF, enregistrement d'entrée parlée, contrôle de dialogue et caractéristiques de téléphonie tels que le transfert et la déconnexion d'appel.

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

II.4.2. Présentation de VoiceXML

VoiceXML et HTML sont des langages à balise (‘Markup Language’). Mais quand un document Html est interprété par un "Web Browser" (Internet Explorer, Firefox, …) pour formater le contenu présenté sur votre ordinateur, VoiceXML est lui interprété par un "Voice Brower" pour formater le contenu présenté sur votre téléphone.

pour formater le contenu présenté sur votre téléphone. L’objectif initial du langage VoiceXML est de permettre

L’objectif initial du langage VoiceXML est de permettre aux personnes disposant d’un simple téléphone d’accéder sous forme vocale aux contenus et services du Web ainsi qu’aux systèmes d’informations des entreprises.

ainsi qu’aux systèmes d’informations des entreprises. VoiceXML est un langage de programmation des interactions

VoiceXML est un langage de programmation des interactions vocales homme-machine s'appuyant sur l'architecture et les applications du Web. Les principales fonctionnalités de ce langage sont :

La diffusion de fichiers audio.

La diffusion de parole synthétisée (synthèse vocale).

La détection de codes DTMF générés par les touches du clavier du téléphone.

La détection de mots ou expressions prononcés par l'utilisateur (reconnaissance

vocale). L’enregistrement de la parole de l’utilisateur.

Le contrôle de l’appel téléphonique (transfert de l’appel, déconnexion de l’appel).

II.4.3. Définition

VoiceXML est un langage de programmation pérenne et portable, normalisé par le World Wide Web Consortium (W3C). Il sert à développer des services de communication interactifs, convergents avec Internet. Il permet d'élaborer un scénario d'accueil de l'appelant en intégrant de multiples possibilités : jeu d'un message préenregistré, reconnaissance des touches tapées sur le clavier téléphonique (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 synthèse vocales, gestion de plusieurs canaux (e-mail, SMS, fax et Web), traitement des appels entrants ou sortants, transfert d'appel, etc.

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

II.4.4. Concept de base

La technologie VoiceXML apporte les fonctionnalités suivantes : création et gestion de dialogues vocaux utilisant des voix synthétisées, des sons numérisés, de la reconnaissance de la parole et des sons DTMF.

La réalisation de cet exploit passe par une plate-forme «interface vocale» du W3C. Cette plate- forme VoiceXML est composée de plusieurs éléments qui sont :

Le langage de synthèse vocale (SSML) utilisé pour générer des annonces vocales synthétiques. La grammaire de reconnaissance de la parole (SRGS) qui guide la reconnaissance en utilisant la description des réponses possibles de l'utilisateur. Le contrôle d'appel du navigateur vocal (Voice Browser CCXML) qui gère les appels téléphoniques. L'interprétation sémantique pour la reconnaissance de la parole (SISR) qui définit la

VoiceXML pour les interactions entre une application et un utilisateur.

syntaxe et la sémantique des balises.

II.4.5. Caractéristiques II.4.5.1. Modèle d’architecture

Le modèle d’architecture d’une application vocale, développée en se fondant sur la norme VoiceXML, est illustré par la figure II.9 :

Utilisateur

Réseaux téléphoniques
Réseaux téléphoniques

Infrastructure de téléphone

Reconnaissance de la parole

Plate-forme d’implémentation

Synthèse de la parole

Plate-forme d’implémentation Synthèse de la parole Interprète de VoiceXML Application Figure II.9 : Modèle

Interprète de VoiceXML

Synthèse de la parole Interprète de VoiceXML Application Figure II.9 : Modèle d’architecture de

Application

Figure II.9 : Modèle d’architecture de VoiceXML

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

Dans ce modèle, la plate-forme d’implémentation a pour but de fournir les primitives dédiées aux événements concernant les actions à la fois d’utilisateur et de système. Elle se compose une infrastructure de téléphonie pour capturer et diffuser les appels téléphoniques, un module de reconnaissance automatique de la parole (ASR – Automatic Speech Recognizer), et un module de synthèse de la parole (TTS – Text To Speech). L'interprète de VoiceXML doit traduire les événements spécifiant dans les documents VoiceXML produits par une application en des actions concrètes sur le monde. L’interprète de VoiceXML doit également assurer la coordination de ces actions.

II.4.5.2. Avantages

La norme VoiceXML présente les avantages suivants :

Réutilisation de qualifications : les développeurs à base des technologies de Web s’accordent pour dire que VoiceXML est facile à apprendre, en raison de sa similitude avec d'autres langages de Markup tels que HTML. Leurs compétences, par exemple pour la génération dynamique du contenu, pourront être réutilisées afin de développer des applications vocales.

Facilité de construction : pour une application vocale simple, sa conception ainsi que son développement peuvent être facilement effectués en se fondant sur des environnements développés de VoiceXML. La raison de cette facilité réside aux objectifs posés de cette norme.

Portabilité : les applications développées en VoiceXML peuvent fonctionner sur une grande variété de plates-formes et peuvent migrer facilement.

II.4.5.3. Inconvénients

Les applications à base de la norme VoiceXML ne sont appropriées 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 constituée de mots clés ou de phrases simples. Cela est donc un grand inconvénient pour l’utilisateur quand il veut exprimer ses demandes par des longues phrases à telle application.

De plus, le dialogue, entre l’utilisateur et l’application, n’est constitué que par des questions/réponses, dans lesquelles l’application garde toujours sa propre initiative.

VoiceXML est conçu principalement pour fonctionner avec le téléphone, qui est le dispositif de transmission le plus omniprésent. Néanmoins, les limitations, imposées par le téléphone comme un niveau sonore faible, un taux de bruit élevé, etc., amènent de la faiblesse au module de reconnaissance automatique de la parole, qui peut être prédéfini et fixé dans l’environnement d’exploitation de cette norme.

II.4.6. Systèmes de dialogue oral homme-machine II.4.6.1. Principes généraux

Un système de dialogue oral homme-machine (désormais SDHM, ou par simplicité, système de dialogue) est un système informatique qui est capable d’interagir naturellement (c’est-à-dire d’une façon qui semble naturelle à l’homme, principalement en langue naturelle) avec l’utilisateur principal via des modalités d’interaction vocale pour accomplir une tâche concrète. Evidemment, un système de dialogue est une application vocale mais elle doit être capable de comprendre non seulement les mots clés, mais également des phrases complètes, c'est-à-dire que l'utilisateur peut vraiment dialoguer avec elle.

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

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 compréhension des énoncés de l’utilisateur. Tout ce que le système peut comprendre par sa propre manière formelle conduit directement l’action du système dans son propre monde. Evidemment, l’action du système peut satisfaire ou non les souhaits de l’utilisateur et donc le processus de cognition est exigé afin d’assurer une satisfaction maximale si possible.

Les composants minimaux d’un SDHM doivent se charger des tâches comme la reconnaissance, la synthèse de la parole, la compréhension, la coordination des tours de parole ou bien le contrôle de dialogue et la manipulation de tâches élémentaires ou bien le contrôle de tâche. Nous détaillons maintenant ces composants dans la section suivante décrite l’architecture générale d’un SDHM.

II.4.6.2. Architecture générale

En utilisant les principes abordés à la section précédente, nous proposons une architecture générique dédiée au système de dialogue, illustrée par la figure II.10 :

au système de dialogue, illustrée par la figure II.10 : Énoncé oral Énoncé oral Reconnaissance de
au système de dialogue, illustrée par la figure II.10 : Énoncé oral Énoncé oral Reconnaissance de
au système de dialogue, illustrée par la figure II.10 : Énoncé oral Énoncé oral Reconnaissance de

Énoncé oral

Énoncé oral

Reconnaissance de la parole

Synthétiseur de la parole

Chaîne orthographique

Compréhension

sémantique

Schéma sémantique

Interpréteur

pragmatique

Générateur

Action sur

sémantique Schéma sémantique Interpréteur pragmatique Générateur Action sur le monde Contrôleur de la tache

le monde

Contrôleur de

la tache

Actes
Actes

Contrôleur de dialogue

Figure II.10 : Architecture générale d’un système de DHM

L'objectif principal de notre architecture est de séparer le plus nettement possible les composants d’un SDHM, afin que nous puissions les manipuler aisément. En général, nous visons

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

effectivement deux caractéristiques principales : distribué et modulaire. Chaque composant doit être modulaire pour que des changements d’un des autres ne l’affectent pas. Pour la même raison, ils sont distribués en tirant profit de la puissance de plusieurs machines différentes. Les défis du système de dialogue oral homme-machine présenté dans la section suivante sont considérés en donnant à cette architecture des facilités de mise en oeuvre.

Notre architecture se compose de sept modules différents. Nous abordons maintenant ces modules en détail :

II.4.6.2.1. Reconnaissance automatique de la parole Les signaux sonores que l’utilisateur prononce arrivent au système et sont capturés par des interfaces spéciales (une carte téléphonique, une carte de son…). Ces signaux sont transmis au module de reconnaissance automatique de la parole afin de les convertir en une chaîne de caractères de confiance. Cette chaîne orthographique est transmise immédiatement au module de compréhension sémantique.

Normalement, le module de reconnaissance de la parole peut retourner une liste de n meilleures chaînes orthographiques qui représentent 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 chaîne de résultat et caractérise donc cette chaîne.

Au niveau le plus bas, le score acoustique d’un mot est effectivement mesuré à partir du score de phonème.

Modélisation de langage
Modélisation de
langage
Acquisition et Reconnaissance modélisation acoustique Parole du signal
Acquisition
et
Reconnaissance
modélisation
acoustique
Parole
du signal
Reconnaissance modélisation acoustique Parole du signal n-candidats Figure II.11 : Description d’un module de

n-candidats

Figure II.11 : Description d’un module de reconnaissance de la parole

Un module de reconnaissance se compose normalement de trois composants principaux illustrés ci-dessus Le premier est pour acquérir le signal sonore de l’énoncé de l’utilisateur et le modéliser sous une forme généralement fréquentielle en gardant des paramètres pertinents. Ces paramètres sont utilisés dans le composant de reconnaissance acoustique qui identifie les sons présents dans le signal. La reconnaissance acoustique est effectuée en utilisant normalement la modélisation par modèles de Markov cachés [11] concernant des phonèmes, diphones, syllabes, etc. Il est ensuite nécessaire de mettre en correspondance une suite d’éléments acoustiques avec une forme lexicale en utilisant le composant de modélisation de langage. Il permet donc de spécifier le positionnement d'un mot dans l’énoncé de l’utilisateur par différentes techniques de modélisation à base soit de grammaire, soit de statistique, soit la combinaison des deux [12]. Selon la demande de chaque application, le résultat obtenu peut être soit une chaîne textuelle, soit une liste des n meilleures chaînes textuelles.

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

En ce qui concerne la dépendance à l’utilisateur, actuellement, il existe plusieurs moteurs de

reconnaissance ayant un modèle acoustique déjà adapté aux utilisateurs, à l’environnement, au canal de communication. Cela apporte donc l’indépendance du locuteur à l’application vocale.

II.4.6.2.2 Compréhension sémantique

Le module de compréhension sémantique a la charge de caractériser la chaîne de caractères

envoyés par le module de reconnaissance de la parole. Il doit l’analyser pour produire un schéma sémantique qui symbolise ce que l’utilisateur vient de prononcer au système. Comme pour un humain, il est certain qu’il y aura des erreurs à ce niveau là : le système (ce module) ne peut tout comprendre ou peut les comprendre de manière différente…

La compréhension doit être effectivement effectuée par l’analyse syntaxique et sémantique. L’analyse syntaxique est à base de grammaire formelle, de grammaire transformationnelle, ou de grammaire en chaîne… Plusieurs approches différentes sont également utilisées au cours des analyses sémantiques comme grammaire sémantique [13], grammaire de cas [14], grammaire fonctionnelle [15]…

II.4.6.2.3 Interpréteur pragmatique

Le schéma sémantique sorti du module de compréhension arrive ensuite dans un central qui

coordonne les modules principaux du système : interprétation, contrôleur du dialogue et contrôleur de la tâche. Ces trois modules peuvent mutuellement interagir afin d’obtenir des données nécessaires pour l’action.

Le central transfère tout d’abord le schéma sémantique au module d’Interpréteur pragmatique et

attend des actes de dialogue en réponse. Ce module doit résoudre des problèmes concernant la référence (noms propres, expressions de désignation, anaphores, déictiques, etc.), les présuppositions et les implicatives conventionnelles…en se fondant sur des connaissances de l’historique (acquises par les tours précédents de parole), des référents de contexte obtenus en interagissant avec le contrôleur de la tâche. Le central retrouve à la sortie de ce module des actes de dialogue qui sont ensuite pris et traités par le module de contrôleur du dialogue.

II.4.6.2.4 Contrôleur du dialogue Le contrôleur du dialogue assure effectivement un rôle important dans un système de DHM :

Coordonner toutes les interactions entre l’utilisateur et le système.

Assurer l’avancement, la cohérence de dialogue.

Etre le pont qui relie la parole et l’action réelle dans le monde.

En effet, l’acte de dialogue sorti du module d’interpréteur pragmatique est analysé et traité par le

contrôleur du dialogue. En s’appuyant sur les tours précédents de la parole, il doit déterminer le but souhaité par l’utilisateur. Afin de bien conduire le dialogue au but posé, il doit également calculer la stratégie appliquée pour générer l’acte (l’action et de même, la réponse) du système.

A la sortie de ce module, on trouvera l’acte de dialogue du système et des données

supplémentaires qui sont tous transférés au module de génération. Bien évidemment, des interactions nécessaires au contrôleur de la tâche peuvent être invoquées au cours de ces calculs pour qu’il puisse avoir suffisamment de connaissances ciblées sur l’action du système.

II.4.6.2.5 Contrôleur de la tâche

Le contrôleur de la tâche est un module concernant purement l’application réelle. Il doit représenter des tâches, des services visés par le système. Au point de vue de la conception logicielle, nous considérons ce module comme une application réelle enrichie par les interfaces