réseaux multiservices données , voix et vidéo sur...

50
1 1 ©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages Réseaux multiservices Données , voix et vidéo sur réseau de données 2 ©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages Références M. Alp Arslan : Cegetel Construire son réseau d’entreprise par Jean luc montagnier aux éditions Eyrolles Philippe Teyssier : Nextiraone

Upload: letuyen

Post on 12-Sep-2018

218 views

Category:

Documents


0 download

TRANSCRIPT

1

1

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Réseaux multiservices Données , voix et vidéo sur

réseau de données

2

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Références

�M. Alp Arslan : Cegetel

� Construire son réseau d’entreprise par Jean luc montagnier aux éditions Eyrolles

� Philippe Teyssier : Nextiraone

2

3

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

AGENDA

Problématique du transport des flux multimédia sur

un réseau de données

Théorie et pratique de VoIP

Voix et téléphonie sur IP : Étude des standards act uels

H323, SIP, MGCP

4

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Quel est le problème ?

3

5

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

La Problématique

Economique Technique

Psychologique

Réduire les coûts defonctionnement

Intégration Voix , Vidéo, Données

Transporter des fluxIsochrones

Garantie de QoS(Perte, Délai et Gigue)

Technologie end user

6

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Avantages de la TOIPCONVERGENCE•Réseau unique•Communications unifiées

OPTIMISATION DES RESSOURCES•Pas de circuit dédié

COUT DE TRANSPORT QUASIMENT NUL

SERVICES EXCLUSIFS•Service de présence•nomadisme

DISPARITION PABX•Centrex•PBX IP

4

7

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Transport : Les Approches

Deux Philosophies

Commutation deCircuit

Commutation dePaquet

ModeConnecté

ModeDatagramme

RTCRNIS-BE

Frame RelayATM

IP

8

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Principes du Transport de la Voix

Réseau de Transportde type Paquet

Numérisation Numérisation

Signalisation

Frame RelayATM

IP

Q.931H.323SIP

MGCP

CodecG.xxx

CodecG.xxx

5

9

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Flux multimédia

Nouvelles contraintes pour le réseau de données

• Numérisation des signaux audio et vidéo•Pour la voix synchronisation Émetteur /récepteur•Pour la Vidéo , augmentation du volume de données t ransférées• Point à Multipoint (Gestion du Multicast)

• garantie de Qualité de service (Délai, Gigue, Ban de passante , taux de perte)

10

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Numérisation : Le Principe

Transformation d ’un signal analogique en un signal numérique

Échantillonnage + Quantification et codage + Compression

0110010100101011001010110100101010010100010110100100101011101010100111101001011111001010010101001010010101011010100101010101010010010101101101101011101010001011

6

11

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Codec Audio

Codec et algorithme de codage

Débit Trame (Durée de remplissage de la zone de données)

Qualité d’écoute (MOS) Application

G711 (PCM) 64 kb/s 0,125 ms 82% (4.1) RTC,RNIS

G726 (ADPCM) 32 kb/s 0,125 ms 77% (3,85)

G728 (LD-CELP) 16 kb/s 0,625 ms 72% (3,61)

G729 (CS-ACELP) 8kb/s 10 ms 78% (3,92) Frame -relay

G723.1 (MPLQ) 6,3 kb/s 30 ms 78% (3,9) IP

G723.1 (ACELP) 5,3 kb/s 30 ms 73% (3,65)

GSM 13 kb/s 20 ms 82% (4.1) GSM

12

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Codec

Algorith

me

Codage

Débit de la

parole

téléphonique en

kb/s

Trame Codec

durée en ms

Trame

Codec

taille en

bits

Taille

paquet IP

en bits

Débit réel

au niveau IP

en kb/s

G711 PCM 64 20 8 328 80

G723 ACELP 5,6 30 168 488 16

G723 ACELP 6,4 30 192 512 17

G726 ADPCM 32 20 4 324 48

G728 LD-CELP 16 20 10 330 32

G729 CS-CELP 8 10 80 400 40

Attention aux encapsulations

Niveau Physique => Délais de sérialisation

7

13

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Le Parfait Codec

Econome en Bande Passante … mais avec un bon MOS (Mean Opinion Score):4 < MOS < 5 : Haute Qualité 3 < MOS < 3,5 : Qualité Moyenne avec dégradation audible3,5 < MOS < 4 : Qualité Standard 2,5 < MOS < 3 : Communication possible (qualité militaire)

Compression des Silences … mais avec un bon confort d ’écoute65% du temps d ’une conversation à deux interlocuteurs est composée de silence !

Non Delaivore … mais économe en bande passanteDélai Codec = (Taille de la trame + délai traitement codec) x pondération DSP => trame courte

Echelle du MOS Subjective => calcul mathématique du MOS

14

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Codec Vidéo

Codec et algorithme de codage

Bande passante requise

MPEG1 1,8 a 80 Mb/s

MPEG 2 1,8 a 80 Mb/s

MPEG 4 64 kb/s à 2 Mb/s

M-JPEG 8 a 10 Mb/s

H261, H263 p x 64 kb/s ( 1 < p < 30)

Taux de compression : 1 pour 300 !

8

15

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Problèmes posés par les transmissions audio et vidé o

Echo

Délai de transit

Variation du délai : Gigue

Taux de perte

16

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Echo

Délai > 25 ms => Effet Cathédrale, puis Echo

Echo Electrique (hybride)

Généré lors du passage2 fils / 4 fils

Echo Acoustique

Echo pour l ’émetteurEcho pour le récepteur

Généré par réémission partielledu message acoustique reçu

Annulateur d’écho

9

17

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Gigue (1)

Variation du délai de transit, en ms

Flux en Emission Bon jour Com ment allez vous cher ami?

Flux Réel Réception Bon jourCommentallez vousch er ami?

Flux Idéal Réception Bon jour Com ment allez vous che r ami?

Délai deTransit

Réseau en mode non connecté

18

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Gigue (2)

Suppression de la gigue

Trouver le meilleur Compromis Réduction Gigue / Augmentation Délai

Buffer tampon

Augmentation du délai de transit

10

19

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Réseau IP ouFrame Relay

DélaisFixes

DélaisVariables

Numérisation Voix + Mise en paquet

Traitement10 ms

Queuing10 à 20 ms

Transmission1 à 30 ms

Réseau20 à 40 ms

Transmission1 à 30 ms

Traitement10 ms

Buffervariable

Variation du Délai de Transitjusqu ’à 500 ms sur @

Délai de transitDélai MAX 300 ms !

20

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Taille de la trame

Débit du lien d’accès

56kbps

64kbps

128kbps

256kbps

512kbps

768kbps

1536kbs

1Byte

143us

125us

62.5us

31us

15.5us

10us

5us

64Bytes

9ms

8ms

4ms

2ms

1ms

640us

320us

18ms

128Bytes

16ms

8ms

4ms

2ms

1.28ms

640us

36ms

256Bytes

32ms

16ms

8ms

4ms

2.56ms

1.28ms

72ms

512Bytes

64ms

32ms

16ms

8ms

5.12ms

2.56ms

144ms

1024Bytes

128ms

64ms

32ms

16ms

10.24ms

5.12ms

1500Bytes

46ms

214ms

93ms

23ms

15mss

7.5ms

Taille maximumd ’une trame

Ethernet

Débit « commun

» d ’un accès

permanent

Temps de sérialisation

Fragmenter pour réduire le temps de

transit

187ms

Attention aux délais de sérialisation

11

21

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Délai de Transit : Exemple de Bilan pour une trame de 30ms générée par codec G723 (20 octets)

Opération Délai

Traitement codec émission 7,5ms (G723)

Remplissage trame 30 ms de voix (20 octets)

Encapsulation trame dans RTP/UDP/IP 5ms (dépend de l’OS de la pile IP)

Encapsulation IP/frame relay 2ms (Routeur)

Sérialisation de 60 octets (20+12+8+20)

Sur une ligne à 128 kb/s

4ms sans compression

Décapsulation IP/Fr 2ms (Routeur)

Décapsulation RTP/UDP/IP 5ms (dépend de l’OS de la pile IP)

Tampon de gigue en réception 15 ms (deux fois le délai du codec)

Traitement codec réception 7,5 ms(G723)

Temps de transit réseau 30 à 150 ms

TOTAL 110 a 220 ms

22

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Perte de Paquets

Evolution des codecs pour prendre en compte ce phénomène (interpolation, redondance d ’information, double codage …).

Pourcentage de paquets non remis au destinataire

Niveau de Qualité perçu en fonction du Taux de Perte

0 5 % 10 % 15 %

Excellent Bon Pauvre Inaccept able

12

23

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Le transport des données multimédia : synthèse

Qualité Voix Vidéo

Bonne (dégradations non perceptibles)

Délai < 200 ms

Gigue < 15 ms

Perte < 5%

Délai < 200 ms

Gigue < 15 ms

Perte < 5%

Limite de l’acceptable Délai = 400 ms

Gigue = 30 ms

Perte = 10%

Délai =400 ms

Gigue = 20 ms

Perte = 10%

24

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Théorie et pratique de VoIP

13

25

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

La Réalité IP

1234

12 4

DéséquencementPerteGigue

Asynchronisme

Best Effort en Temps Différé

26

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Pourquoi TCP et UDP ne conviennent pasDans les communications temps réel ?

TCP… Transport fiable (Contrôle séquence, Contrôle erreur, Contrôle congestion …mais Pose deux problèmes :• Les contrôles engendrent un surplus de données important !• Ce n’est pas la fiabilité qui importe …mais le TEMPS !

UDP… Aucun mécanisme de contrôle …et aucun mécanisme pour reconstituerl’ordre des flux auprès du récepteur !

14

27

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Ou se trouve RTP ? Exemple du cas Stack H323

VoixG711G723G729

VoixG711G723G729

Contrôle et Signalisation

RTCPH225H450

Contrôle et Signalisation

RTCPH225H450

EthernetEthernet Token-RingToken-Ring FDDIFDDI F-RelayF-RelayATMATM PPPPPP

VidéoVidéo DataData

28

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

RTP : Pourquoi Faire ?

RTP : Real-Time Transport Protocol (RFC 3550)S ’appuie sur UDP ou TCP

Ce que RTP Fait Ce que RTP Ne Fait Pas

Ajoute des informations aux paquets IP permettant de :

- Horodatage

- Numéro de Séquence

- Influence sur le comportementdu réseau IP

- Contrôle de la QoS renduepar le réseau IP

15

29

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

RTP: Protocole

Header UDP

Header IP

Données issues d’un codec

Bits de Contrôle Num. Séquence

Horodatage (32 bits)

Source du Stream RTP

Une session RTP s ’appuie sur UDP ou TCP

20 octets

8 octets

12 octets

+

+

Intérêt de laCompression des

headers RTP/UDP/IP

30

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

RTP et RTCP

RTCP : Real-Time Transport Control Protocol

Une Session RTP => Une session RTCP Associée (pour informer l’émetteur de la qualité du service perçu par le récepteur )

L ’émetteur du stream RTP envoie des Sender ReportsLe(s) récepteur(s) du stream RTP envoie des Receiver Reports

Gestion intelligente des flux : Pour consommer le moins de bande passante Possible

- Flux RTCP < 5% flux RTP- Sender Reports = 25% flux RTCP (pour une source)- Receiver Reports = 1/n flux RTCP restants (n : nb de participants)- Fréquence d ’émission : 1 rapport au maximum toutes les 5s

16

31

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

QoS et IP

QoS Réseau IP

Délai de TransitGigueBande PassanteTaux de PerteDéséquencement

Pas Conçu pour çaPas Conçu pour çaSurdimensionnementSurdimensionnementStabilité des routes

Solutions

WeightedFair

QueuingAlgorithms

IntServDiffServMPLS

32

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

QoS : définitions

�Caractéristiques de la QoS�délai d’acheminement de bout en bout

�variation de ce délai (gigue)

�pourcentage de paquets perdus

�bande passante nécessaire

�Mécanismes et algorithmes sous-jacents�Taille des buffers�Identification et contrôle des différents flux

�classifier, policy, shaping,�Traiter les congestions (scheduler)

�exemple : WFQ�Prévenir les congestions

�exemple : RED, WRED

POLITIQUE QOS = Maîtrise des caractéristiques de QOS

17

33

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Critères de la QOS

�délai d’acheminement de bout en bout

�variation de ce délai (gigue ou jitter)

�pourcentage de paquets perdus

�bande passante nécessaire

delaydelaydelaydelayjitterjitterjitterjitter

loss ratioloss ratioloss ratioloss ratiobandwidthbandwidthbandwidthbandwidth

Délai de bout en bout (+gigue)

Bande passantePerte de paquets

Application : Optimisation pour le délai, la bande passante, ou les pertes, mais pas tout !

Paramètres réseau correspondants ?

34

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Besoin QOS des applications

Besoin en débit

Sensibilité aux pertes

Sensibilité aux délais

Sensibilité à la gigue

Applications Interactives (Telnet, Accès BD, Courtes transactions Web,

Xwindow …)

Faible Moyenne Haute Faible

Applications Multimédia Interactives (Voix ou vidéo sur IP)

Moyen Moyenne Haute Haute

Applications Multimédia non Interactives

(enseignement a distance, diffusion …)

Haut Moyenne Faible Faible

Applications à requêtes (client/serveur, NFS, …)

Moyen Faible Haute Faible

Applications de transfert (ftp,sauvegardes, télédistribution, longues transactions

Web…)

Haut Faible Faible Faible

Contrôle du réseau (SNMP,RIP,OSPF,BGP, …)

Faible Haute Haute Faible

Flux différents dans files d’attentes différentes

18

35

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Quel niveau de QOS pour les applications ?

�“Services Garantis” �Approche circuit commuté

�Réservation et garantie de certains paramètres ( bande passante, latence, … )

�“Services Différenciés”�Permet la prioritisation de trafic en les séparant par niveau de criticité

�Traitement privilégié pour le trafic important; traitement dégradé pour le trafic non important

�Le trafic important passe, mais sans “garantie”

�Best Effort�“What you see is what you get”

�Seul demande : de la bande passante ...

36

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Quelles solutions techniques ? � Ne rien faire => Best effort

�Situation assez courante ! Mais Pb pour les appli critiques (Voix sur IP)

�Pari sur évolution des débits (DWDM, LAN Gigabi …)

� Mauvaise approche ! Mais réseau simple !

� Gestion du trafic aux extrémités du réseau �liée au monde IP !

�Gestionnaire de bande passante

�Transitoire ?

� Gestion du trafic dans le réseau �favoriser les flux prioritaires (rôle actif des nœuds => classifier, mise en file d ’attente, ordonnancer)

�s ’imposera a terme !

� Ingénierie des trafics (MPLS-Politique de Routage)

19

37

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Gestionnaire de bande passante : Fonctionnalités

Découverte et classification du trafic

Analyse du trafic

Gestion de la politique de Qos

Moteur de Qos

Gestion de la politique de Qos

Reporting

•Niveaux 2-7

•Classification très fine

•Jeu d’indicateurs

•Exp : Temps de réponse pour application

•Paramétrage QOS

•Délicat

•Simple

•Méthodes et algorithmes QOS

•MEO en situation de congestion

•Temps réel pour vérifier les paramétrages

38

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Exemple de gestion de BP

Source : 01 informatique

•Simple a mettre en œuvre

•Ne remet pas en cause l’existant

•Efficace

•Économique

2 axes d’améliorations :

•Prioriser les flux

•Contrôler les flux utilisateurs

20

39

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Les composants de la QOS au sein du réseau

1- QoS associée à un équipement

2- Signalisation Qos(IN BAND – OUT BAND) 3- Gestion et

contrôle de la Qos

40

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

�3 solutions pour la QOS IP aujourd'hui :

�Integrated Services ( IntServ : RFC : 2205,2208,2209 )

�Utilisation de la signalisation RSVP pour réserver pour chaque flux des

ressources dans le réseau

�Differentiated Services ( DiffServ : RFC 2475)

�Utilisation du champ TOS de l ’entête IP ( renommé DS )

�Plus adapté aux réseaux de grande taille qu ’ IntServ

�MPLS (MultiProtocol Label Switching)

�Technique d ’ingénierie de trafic

�Ip en mode connecté !(identique à création de CV (LSP = Label Switch path)

Qos au sein du réseau : Modèles de QOS pour IP

21

41

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Modèle Intserv : RSVP (Fonctionnement)�Principe

�Utilisation de la signalisation RSVP pour réserver pour chaque flux des ressources dans le réseau pour une qualité de service particulière

RSVP-PATH

TSPEC,ADSPEC

RSVP-PATH

TSPEC,ADSPEC

RSVP-PATH

TSPEC,ADSPEC

RSVP-RESV

RSPEC

RSVP-RESV

RSPEC

RSVP-RESV

RSPEC

•Rafraîchissement de la réservation des ressources toutes les 30 secondes !

•Si flux bidirectionnel => 2 sessions RSVP !

42

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Modèle Intserv : Utilisation

�Principe Utopique dans les grands et très grands réseaux

�Complexité liée à la signalisation

�Supporte IPv4 et IPv6

�Pratiquement on garde RSVP pour les réseaux d’accès

22

43

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Modèle Diffserv : Origine et principes

�Modèle né des limitations du modèle Intserv

�Principes

�Cœur de réseau dédié commutation => Marquage des paquets aux Pt

d ’entrée du réseau (Ingress node)

�COS indiquée dans champ DS du paquet IP => service à fournir par le

noeud au paquet (PHB : Per Hop Behavior)

�Chaque élément du réseau doit supporter Diffserv

44

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Modèle DiffServ : Champ DS

Adresse destination

Type Of Service Longueur totale

Adresse source

Checksum en-têteProtocoleDurée vie(TTL)

Identification

VersionLong.en-tête

Flags Fragment offset

Options(facultatif)

Bourrage

Octet 1 Octet 2 Octet 3 Octet 4

D.S.C.P C.U1 2 3 4 5 6 7 8

DS

23

45

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Modèle Diffserv : Architecture et Terminologie

CommutateursL2

CommutateursL3

BordureBackbone WAN

(Cœur du réseau)Backbone WAN

(Cœur du réseau)

DS Ingress Node

DS Egress Node

Domaine Diffserv

DS Interior Node

Point d ’entrée et sortie(Bordure du réseau)

Pour un Flux IP donné TouT les nœuds du domaine Diffserv appliquent le même PHB

Nouvelle politique de QOS ?

46

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Policing

MarquageDSCP

Shaping

Ordonnancement

•Gestion de la congestion :• RED ou WRED

•Shaping :• Améliorer l efficacité et la conformité aux règles

•Ordonnancement (WFQ):• Remplissage des files de sortie en fonction des priorités

•Classification (BA,MF):• Filtres basés sur les adresses IP S/D, ports TCP/UDP, champ DS

•Meter-Policing :• Le flux est il conforme aux règles définies ? Sinon Drop ou Shaping ou re-marquage DS

•Marker :• Marquage du champ DS en fonction des règles définies

Gestion des flux : en entrée

24

47

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Shaping

Gestion des flux : le cœur

Policing

MarquageDSCP

Shaping

priorités

Ordonnancement

•Gestion de la congestion :• RED ou WRED

•Shaping :• Améliorer l efficacité et la conformité aux règles

•Ordonnancement (WFQ) :• Remplissage des files de sortie en fonction des priorités

48

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Per-Hop Behaviors (PHB)

�PHB : Mode de traitement des paquets au niveau des équipements

DiffServ du réseau.

�« Policing » (régulation)

�Re-marquage possible du champ DS

�Traitement en entrée (ex : priorité des drops)

�Shaping

�Priorités en sortie

�L’IETF a défini 3 différents PHB / 6 classes pour DiffServ:

�Expedited Forwarding (EF) - RFC 2598 (1 classe)

�Assured Forwarding (AF) - RFC 2597 (4 classes)

�DEfault Forwarding (DE) - RFC 2474 (1 classe)

25

49

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Expedited Forwarding (EF) PHB

�Service virtuellement équivalent à un lien dédié

�Qos maximal (Bp max, Peu de perte paquets, délai et gigue faible)

�Adapté aux flux sensibles (Voix sur IP, SNA …)

�Trafic shaping en sortie pour maintenir le contrat vers le domaine suivant

�Design du réseau

�La vitesse du lien en sortie doit être égale ou supérieure aux flux en entrée

�Organisation des flux

�Pour un réseau multiservice, le trafic « EF » ne doit représenter qu’une faible partie

des flux (typiquement < 10%)

DSCP = 101110

RFC 2598

50

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Assured Forwarding (AF) PHBFaiblelatence

Fortelatence

Haut Niveaude suppression

Faible niveaude suppression

4 classes AF (niveaux de priorité)3 niveaux de drop par classe AF

RFC 2597

Afxy

ClasseDrop precedence

X = [1..4]

Y = [1..3]

ClassesDrop

Classe 1 Classe 2 Classe 3 Classe 4

Bas 001010(AF11)

010010(AF21)

011010(AF31)

100010(AF41)

Médium 001100 (AF12)

010100 (AF22)

011100 (AF32)

100100 (AF42)

Élevé 001110 (AF13)

010110 (AF23)

011110 (AF33)

100110 (AF43)

26

51

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

DEfault Forwarding (DE) PHB

DSCP = 000000

Service IP classique Best effort

Organisation des fluxapplications les moins stratégiquesex : « surf » sur le net

52

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

classification commerciale

Catégories De l’application

Nom de la classe de

service Temps réel,

Faible latence Premium

Platinum Temps réel, Latence moyenne

Gold

Silver Pas de temps réel, Applications critiques

Bronze

Pas de temps réel, Applications non

critiques

Standard

PHB DiffServ

EF

DE

AF

L'utilisation de noms pour les classes simplifie la configuration

27

53

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

�Nécessaire au fonctionnement de l ’architecture DiffServ

�priorité des « Drop »

�PHB DE : tous les flux peuvent potentiellement être supprimés

�PHB AF : 3 niveaux de « Discard » pour chaque classe

�PHB EF : aucune trame ne peut être supprimée « No Discard »

�RED : Random Early Detection

�Suppression aléatoire et dynamique des trames

�WRED, MRED : suppression en tenant compte des priorités

Mécanismes de gestion de la congestion

54

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

�Ordonnancement stricte

�Affectation d ’un % fixe à une file de priorité

�Une file de priorité haute doit être complètement vidée avant le traitement des autres

�Ordonnancement par répartition de la bande passante

�Chaque file aura la main tous les n paquets (Fair queueing)

�Amélioration …pour tenir compte des besoins en bande passante => WFQ

Gestion des files de priorités

28

55

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Gestion des Files : Exemple WFQ (Weighted Fair Queuing)

Classification et Création dynamique d’une file par session

Files d ’attente (Buffers) par Session

Allocation équitable de la bande passante

Weighted Fair Queuing

La pondération est fonction

de la Qos désirée;

du débit du flux .

File d ’attente de sortie

500 - Telnet SAP

10 - FTP

100 - Lotus Notes

Seuil de BP < Seuil paramétré

Seuil de BP = Seuil

paramétré mais < seuil

maximal

Ou

Seuil de BP ≥ Seuil

maximal

56

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Mapping IP / Couche 2

Ethernet ATM FrameRelay

LS EthernetTokenMPLS

802.1PCOSATM

mécanismesFR

Mécanismesde

Prioritisation802.1P

COSMPLS

IP - DiffServ La QOS de bout en bout

29

57

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Mapping DSCP / 802.1p : Exemple

Classe deservice

DiffServDSCP

Champ802.1p

Premium EF 7

Platinum AF11, AF12 or AF13 6

Gold AF21, AF22 or AF23 5 (or 4)

Silver AF31, AF32 or AF33 3 (or 2)

Bronze AF41, AF42 or AF43 0 (Defaut)

Standard DE 1

•PC vers Commutateur niveau 2 : Codage DSCP par appli PC•Certains commutateurs de niveau 2 interprètent le champ DS (Vérifier !)

DSCP 802.1p DSCP

•Commutateurs niveau 2 vers les commutateurs niveau 3 ou routeurs : Les équipements de niveau 3 suppriment le champ 802.1p

58

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

�Constat pour Diffserv , Intserv …

�Envisageables dans les environnements ou l’on connait les

clients (réseaux d’entreprise)

�Non acceptables pour les opérateurs ..a cause de la

méconnaissance des flux

Ingénierie de trafic

�Pour Contrôler les flux..il faut savoir ou passent les flux =>

MPLS (Equivalent du circuit Commuté dans le RTC !)

30

59

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

MPLS : Principes

10.1.1.1

10.2.1.1LSR

LSR

Ingress Routing table

Destination Next Hop

10.1.1.1

10.1/16 (2,84)

10.2/16 (3,99)

LSR

LSR LSR

LSR

LSR

10.1.1.1 8410.1.1.1 3

In Out

(2,84) (6,3)

MPLS table

Egress Routing table

Destination Next Hop

10.1/16 10.1.1.100

10.2/16 10.2.1.100

10.1.1.100

10.2.1.100In Out

(1,99) (2,56)

MPLS table

In Out

(3,56) (5,3)

MPLS table

60

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

MPLS : Trafic engineering

LSR

LSR1

LSR

LSR LSR

LSR3

LSR5LSR4

Choix du protocole de routage

LSP Établi entre R1 et R4

LSR2

31

61

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Relation Diffserv - MPLS

CommutateursL2

CommutateursL3

BordureWAN MPLS

(Cœur du réseau)Backbone WAN

(Cœur du réseau)

DS Ingress Node

DS Egress Node

Domaine Diffserv

Point d ’entrée et sortie(Bordure du réseau)

Pour un Flux IP donné TouT les nœuds du domaine Diffserv appliquent le même PHB

Mode E-LSP : Copie champ DSCP (3 premiers bits) dans champ EXP du label

62

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

RSVP + DiffServ +MPLS

CoreMPLS

Réseau d ’Accès

LANClient

- Core sans congestion : 1 classe- MPLS : n classes=> n LSP

avec WFQ par classe.

Réseau d ’Accès avec congestion- RSVP pour les flux sensibles- Best Effort pour les autres

Mise en Oeuvre de Tunnels RSVP à travers le backbon e

Edge Routeur regroupant les flux similaires ( ρi,σi)

dans des classes de service adaptées et homogènes

Routeurs d’accèsavec RSVP

Routeurs de backbonegérant n classes de

service DiffServ

Agrège les flux RSVP en classes Diffserv

32

63

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Architectures de TOIP

64

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Les standards existants

H.323 SIP

MGCP

Concurrents

Concurrents/Partenaires

Concurrents/Partenaires

33

65

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

H.323 : PositionnementRecommandation ITU-T (Study Group 16 - Contribution 54)

H.323 permet de rendre des Services de Communications Multimédiaentre des Entités interconnectées par un Réseau à Commutation de Paquets

sans Garantie de Qualité de Service.

- Point à Point- Multipoint- Broadcast

- Audio (Mandatory)- Données (Option)- Vidéo (Option)

- Terminal- Gateway- Gatekeeper- MC / MP / MCU

- LAN (Version 1)- MAN et WAN(Version 2)

- Internet (Version 2)

IP

66

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Architecture H.323

Internet RTC/RNIS

GatekeeperH.323H.323/netmeeting

Routeur Gateway

H.320(Over ISDN)

H.324(Over POTs)H.323

LAN

MCU

34

67

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

H.323 : Les Protocoles

H.225.0Réseau

Control System

H.245 (gestion signalisation)

H225.0 Adaptation QSIG

RTP /RTCP

Codec VidéoH.261, H.263

Codec AudioG.711, G.722, G.723,

G.728, G.729

Data Interface T.120

Sécurité H.235

Services Supplémentaires H.450

EquipementVidéo

EquipementAudio

ApplicationsData

Systèmede

Supervision

Authentification, Intégrité,

Chiffrement

Transfert d’appel ,rappel sur occupation

68

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

H.323 : Le Fonctionnement (1)

Cas n°1 : Appel de poste à poste en connaissant l ’a dresse de l ’appeléPhase 1 : Initialisation de l ’Appel

AppelantOGA

AppeléAAR

Port TCP1720

SYN

SYN ACK

Ouverture d ’une session TCPet Création du Call Signaling Channel

Port TCP1720

Envoi de la Requête de l ’Appelant

SETUPPort TCP

1720

Call Reference : 10 (L)Call Id : 45442345 (G)Id-Sender : OGASource : PCCall type : Pt to PtId-Rec. : oga@insa

Réponse de l ’Appelé

ALERTING

CONNECT

Port TCP1720

Call Reference : 10 (L)Call Id : 45442345 (G)Source : PCH.245 Address :10.2.3.4:8741

35

69

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

H.323 : Le Fonctionnement (2)

Cas n°1 : Appel de poste à poste en connaissant l ’a dresse de l ’appeléPhase 2 : Etablissement du Control Channel

AppeléAAR

Port TCP8741

SYN

SYN ACK

Ouverture d ’une session TCPet Création du Control Channel

Port TCP4852

Négociation des Capacités de Communication

Terminal Capability Set Port TCP8741

Liste des capacités :- T120 et G.729ou- T120 et H.261 et G.711 Alaw

Terminal Capability Set Ack

Réponse de l ’Appelé

Terminal Capability Set

Terminal Capability Set Ack

Port TCP4852

Liste des capacités :- T120 et G.729

AppelantOGA

70

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

H.323 : Le Fonctionnement (3)

Cas n°1 : Appel de poste à poste en connaissant l ’a dresse de l ’appeléPhase 3 : Ouverture des Canaux Logiques Unidirectio nnels

AppeléAAR

Ouverture d ’autres canaux logiques

Ouverture d’un canal logique Voix

Open Logical ChannelPort TCP

8741

Port TCP4852

Description du canal :- Logical Channel 1- RTP Port x- RTCP RR port 7771- G711 Alaw64K- Silence Suppression

Open Logical Channel

Open Logical Channel Ack

Open Logical Channel AckPort TCP

8741

Acceptation du canal :- Logical Channel 1- RTCP SR port 9345- RTP port 9344

AppelantOGA

36

71

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

H.323 : Le Fonctionnement (4)

Cas n°1 : Appel de poste à poste en connaissant l ’a dresse de l ’appeléPhase 4 : Communication

AppeléAARTransmission d ’un flux monodirectionnel

Flux RTPRTP : UDP

RTCP : TCP 7771

RTCP TCP

RTCP Receiver Report

RTP : UDP 9344

RTCP : TCP

RTCP : TCP 9345RTCP Sender Report

Contrôle du canal logique

Port TCP8741

Port TCP4852

Messages de contrôle pourl ’ensemble des canaux

logiques entre OGA et AAR

AppelantOGA

72

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

H.323 : Le Fonctionnement (5)

Cas n°1 : Appel de poste à poste en connaissant l ’a dresse de l ’appeléPhase 5 : Fin de la Communication

AppeléAARFermeture du canal logique (x n)

Close Logical Channel Port TCP8741

Port TCP4852 Close Logical Channel Ack

Fermeture du Control Channel

H.245 End Session Port TCP8741

Port TCP4852 H.245 End Session

Port TCP1720

Port TCP1720

Fermeture du Call Signaling Channel

H.225 Release Complete

H.225 Release Complete

AppelantOGA

37

73

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

H.323 : Le Fonctionnement (6)

Cas n°2 : Appel de ma grand-mère depuis un terminal sur Internet=> Problèmatique

Un poste téléphonique n’est pas un équipement IP GATEWAY

GATEKEEPER

Une adresse IP peut-être allouée dynamiquementLe destinataire peut avoir éteint son posteLe destinataire peut se déplacerLa communication RTC doit être refacturéeLes ressources de la Gateway ne sont pas infiniesLe destinataire peut être connu par un AliasTout le monde n’a pas accès à l’International ...

=> Services Réseau à Valeur Ajoutée

74

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

H.323 : Conférence (1)

Une Conférence = Deux Fonctions

Contrôle- Qui peut participer ?- Comment sont intégrés les

nouveaux participants ?- Comment est réalisée la

synchronisation ?- Qui peut broadcaster un flux … ?

Multipoint Controller (MC)

TraitementFlux Audio :

- Somme de toutes les sources- Flux de l ’intervenant …

Flux Video :- Mosaïque des participants- Image de l ’intervenant ...

Multipoint Processor (MP)

Multipoint Controller Unit (MCU) = MC + MPs(optionn el)

Conférence Centralisée : Un MP central est utilisé par tous les participantsConférence Décentralisée : Chaque terminal envoie ses flux vers tous les participants

38

75

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

H.323 : Conférence (2)

OGA MCU ITC1

Création de la Conférence : [email protected]

Invitation d ’un participant Invitation d ’un participant

Acceptation de l’Invitéet Négociation des paramètresAcceptation de l’Invité

Demande de participation

Demande de la liste desconférences actives

Ouverture des canaux logiques

76

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

SIP : Positionnement

SIP : Session Initiation Protocol (RFC 2543 produit par le Working Group MMUSIC (Multiparty MUltimédia SessIon Control) dont les travaux sont orientés sur les conférences à faible interaction)s ’appuie sur un ensemble de protocoles définis (ou en cours de définition) par l ’IETF :

SDP : Session Description ProtocolSAP : Session Announcement ProtocolRTSP : Real Time Stream ProtocolSCCP : Simple Conference Control ProtocolRTP/RTCP : Real Time Transport Protocol / Real Time Transport Control ProtocolRSVP : Resource Reservation Protocol

Objectif : Concurrencer H.323

Moyens : Faire simple en profitant de tous les outils et moyens associés à l ’environnement IP (Multicast et DNS notamment)

39

77

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

SIP : Principes

Modèle Client / Serveur : Appelant = Client, Appelé = Serveur

Modèle Transactionnel : Une requête entraîne au moins une réponse- Status d ’information (1xx) : En cours, Sonnerie …- Status de résultat (2xx à 6xx)- Acquittement (dans certains cas)

SIP s ’appuie indifféremment sur TCP ou UDP

Requêtes transmises en mode texte (vs ASN1 pour H.323)

Pas de Codec par défaut ou obligatoire (vsG.723.1 pour H.323)

Adapté à l ’environnement Internet (Proxy, Firewall)

78

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

SIP : Messages

INVITE sip:[email protected] SIP/2.0

Via : SIP/2.0/UDP 192.130.2.5Call-ID : [email protected] : <sip:[email protected]>To : <sip:[email protected]>Cseq : 1 INVITE

Subject : xxxxxxxxxxxxxxx

Content-Type : application/sdpContent-Length : 885

v=0o=bell 457889564 …….

Requête

HeaderGénéral

HeaderRequête

HeaderEntité

DonnéesSDP

Exemple demessage derequête SIP

-Mode Texte

40

79

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

SIP : Fonctionnement de Base

Cas n°1 : Appel de poste à poste en connaissant l ’a dresse de l ’appelé

AppelantOGA

AppeléAAR

Transmission des informations

Données

UDP : 49190UDP : 9876

Données

Fin de l ’Appel

BYE

200 OK

TCP/UDP : 5060

TCP/UDP : 5060

NumSeq : 23 invitefrom : IN IP4 192.1.2.1 to : [email protected] : audio codec

port 9876

TCP/UDP : 5060INVITE

200 OK

Ouverture de la Session SIP

TCP/UDP : 5060

NumSeq : 23 invitefrom : IN IP4 192.1.2.1 to : [email protected] : audio codec

port 49190

ACK

80

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

SIP : Services Avancés

Registrar ServerCorrespondance Adresse SIP <-> Adresse IP.Inscription des utilisateurs de type Soft State.Découverte des Registrar : statique ou dynamique (224.0.1.75, TTL=1)

Proxy ServerSe comporte comme un serveur SIP pour les requêtes entrantes.Se comporte comme un client SIP pour les requêtes sortantes.Peut modifier des paramètres de requêtes.

Forking Proxy ServerDuplication d ’une requête vers plusieurs destinations.

Redirect ServerFournit des informations permettant de redéfinir l ’adresse SIP d ’appel

. Liste d ’adresse SIP correspondant à une personne

. Nouvelle adresse SIP définitive

. Nouvelle adresse SIP temporaire

41

81

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

SIP : Adressage

Adresse SIP = user@host (URL : Uniform Resource Locator)Souvent, adresse SIP = adresse e-mail

Résolution d ’adresse en deux temps

Temps 1 : Localisation du Serveur SIP- Mise en oeuvre classique du DNS (Domain Name Server)- Serveur SIP identifié par un enregistrement SRV, MX, CNAME ou A

Temps 2 : Interrogation du Serveur SIP- Association adresse SIP <-> adresse transport de l ’appelé

Gestion de l ’aspect dynamique de l ’adressage IP- Adresse Serveur SIP « statique »- Contenu des serveurs géré dynamiquement (mobilité)

82

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

H.323 vs SIP

Ce que SIP fait etque H.323 ne fait pas

Simplicité

Vitesse

Signalisation UDP et Multicast

Adressage Internet-like

Message en mode texte

Ce que H.323 fait etque SIP ne fait pas

Complet … mais complexe

Canaux logiques

Gestion des conférences

Codage binaire (ASN1)

Clairement Normalisé

… et pourquoi pas H.323 et SIP ?

42

83

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

MGCP : PositionnementMGCP : Media Gateway to media Controller Protocols

Constat :- H.323 est trop compliqué- Tout le monde ne dispose pas d ’un terminal haut-de-gamme- Le RTC ne disparaîtra pas du jour au lendemain- La signalisation NNI SS7 est particulièrement efficace

Acteurs : Bellcore (devenu Telcordia), Cisco puis Level3

Le réseau IP doit se comporter, et être vu du résea u téléphonique,comme un Switch Standard.

84

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

MGCP : Architecture

Signaling Agent /Media Gateway Controller

Media Gateway

Signaling Gateway

Réseau IPRTC

H.323SIPATM

MGCP

43

85

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

MGCP : Protocole

Définit l ’interface entre un Media Gateway Controller et des Media Controller

Protocole de type Maître / Esclave avec une intelligence centralisée

Messages sont en mode texte

Conçu pour des gateways de 1 à plus de 100 000 ports

Possibilité d ’associer des actions à des évènements (Notification Request)

En cours de spécifications :- Ne gère pas les appels multimédia (limité à la voix)- Limité à huit commandes

86

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Quelle Signalisation ?

H.323 est complet et normalisé

SIP est simple et en plein développement

MGCP/H.248 est économique

Cohabitation Incontournable+

Saine Emulation

Développement de Nouveaux Services

44

87

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Voip/Toip En pratique

88

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Infrastructure réseaux (1/2)

Flux de signalisation

Flux de communication

� Flux standardisé TCP (SIP, H323 et MGCP)

� Nécessaire au fonctionnementde tous les postes (actifs et repos)

� Environ 0,4 kbit/s par client

� Flux RTP

� Entre les DSP (Digital Sound Processor)des clients actifs

� 1 Erlang : 1 canal occupépendant 1 heure

� Trafic moyen : 0,16 E par poste(dont 50% en interne)

� Trafic agent : Entre 0,7 et 1 E

� Algorithmes de compression� G711 : 80 kbit/s

� G729 : 30 kbit/s

� G723 : 25 kbit/s

45

89

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Infrastructure réseaux (2/2)

� Signalisation intra cluster� Synchronisation permanente des bases de données

� Bande passante intra cluster de 2 Mbit/s

� Films sonores et musicaux� G711 pour qualité correcte

� Accès messagerie vocale� Généralement G711

� Nécessité de transcodage sur le WAN

Flux applicatifs

Qualité de service� Sur le LAN

� Création d’un VLAN de ToIP

� Large bande passante : Pas de compression(G711)

� Sur le WAN� Délai de transit < 150 ms

� Variation de délai de transit < 20 ms

� Taux de perte de paquets < 1%

� Bande passante limitée : Compression (G729)

90

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Exemple D’architecture TOIP/VOIP

Traficintra cluster

QoSsur le WAN

Diffusionfilms vocaux

Accès G711transcodage

TraficPostes et MG

VLAN ToIPsur le LAN

TraficPostes Agent

46

91

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Services téléphoniques

Services et exploitations existantes

Organes périphériques� Circuits de conférence

� Guides vocaux

� Attentes musicales

� Impacts sur le WAN� Sorties de proximité, Least Cost Routing (LCR)

� Portabilité des SDA

� Appels d’urgence

� Réglementation ARCEP

� Technologies� Analogiques

et numériques (RTC)

� SIP

Accès opérateurs

Plan de numérotation

92

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Services téléphoniques (Exemple)

Portabilité SDAUrgences

Diffusionfilms vocaux

Types deraccordement

Niveau deservices tél.

Plan denumérotation

47

93

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Sécurité et disponibilité

Sécurité informatique

Disponibilité� Historiquement l’application téléphonique offre une disponibilité record

� Criticité de l’application en interne

� Valeur d’image

� Source de « revenus »

� Aujourd’hui, toute l’infrastructure de ToIP repose sur l’architecture IP

� Nécessité de redondé les équipements sensibles

� Flux généralement connus et conformes à la politique de sécurité informatique

� Nécessité de prendre en compte car impact important

� Design réseau

� Matériels ou licences additionnels (chiffrement de la signalisation et des communications)

� Difficultés lors du déploiement

94

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Sécurité et disponibilité (Exemple)

Disponibilitédu LAN

Disponibilitédes serveurs

Politique desécurité info.

Mécanismesde secours

Disponibilité etstabilité WAN

Duplicationactif / passif

Cluster avecpartage charge

Raccordementstations sur LAN

ChiffrementSig + Flux

48

95

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Intérêt économique

De quel budget parle-t-on ?

Danger = « Caricaturer » l’intérêt économique

� Investissement� Delta financier entre les différentes solutions / architectures du marché

� TCO (Total Cost ofOwnership)� Investissements +

tous les coûts induitspar la solution

� ROI (Return OnInvest)� TCO – tous les gains

attendus de la solution

96

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Des économies concrètessur les coûts

Des accroissements de

la productivité peuvent être quantifiés de

manière certaine

Des avantages biens réels, mais plus difficiles à quantifier

Domaines non financiers

• Satisfaction du client• Conservation des employés• Souplesse géographique• Positionnement concurrentiel• Déploiement plus rapide des

applications• Continuité de l’activité voix• Productivité obtenue via les

applications convergentesdifficile à quantifier

Réseau unique• Maintenance, câblage, administration, support,

déplacements / ajouts / modifications (“MAC”), personnel

•Continuité de l’activité voix

•Surface occupée• Utilisation de l’espace, réduction des coûts

opérationnels, souplesse

•Réduction du coût des appels• Réduction de l’utilisation des téléphones mobiles

• Extension, portabilité, roaming sur le parc de bâtiments, siège social, autre emplacement

• Gestion des appels sortants

• Messagerie unifiée• Audio conférence

•Petite succursale d’entreprise

•Création de rapports, facturation, gestion des coûts

•Réduction des coûts relatifs aux PC

Efficacité des employés

• Applications liées à l ’utilisateur final

• Audio conférence• Messagerie unifiée

• Assistant personnel• Accès au Web

• Intégration de l’informatique et de la téléphonie (“CTI”)

• Intégration système d’information

• Expl. globale de la gestion des installations

Intérêt économique

49

97

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

� Travail en mode projetmode projet�Mise en place d ’une équipe projet très en amont

�Fédérée par ll ’IC’IC et ConsultantConsultant en avant vente

�Managée ensuite par le chef de projet

Rôle équipe p rojetrojetAnticipation et prise en compte de toutes les composantes liées au projet

Identification et prise en compte immédiate des risques et des contraintes

Convergence des compétences internes

Offre de service adaptée

Respect des engagements fonctionnels, de déploiement et de recette

Démarche Projet

98

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Installation Monteurs Câblage

Responsable déploiement

Formateurs

Téléphonie sur VOIP

Infrastructure DATA

Messagerie Vocale, unifiée

Intégration ( Appli Métier )

Outil d’administration

Responsable Technique

Directeur de projet

(PM : Project Manager)

Equipe Projet : Organisation

50

99

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

� Le Plan Projet comprend :� L’organisation de l’équipe Projet

� La méthodologie Projet

� Les phases du Projet

� Le planning du Projet

� La liste détaillée des prestations fournies par NextiraOne

� La liste des actions incombant au client

Les différents documents:Le dossier de spécifications et d’architectureLe dossier d’installationLe dossier d’exploitationLe dossier de recetteLa liste détaillée des prestations fournies par NextiraOneLa liste des actions incombant au client

Démarche Projet

100

©Omar Gaouar– INSA DE LYON – Département télécommunications Services & Usages

Logistique

Phases du projetLa découpe générique en phases du projet est faite de la façon suivante :

LancementCollecte des donnéesConceptionInstallation des serveurs de téléphonieIntégration dans le poste informatiqueRecette provisoireDéploiement et assistance à la mise en serviceRecette définitive

FormationDes utilisateursTransfert de compétence

Plan Projet