réseaux multiservices données , voix et vidéo sur...
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