1

Voix sur IP etQoS dans l’Internet

André-Luc BeylotDépartement Télécoms et Réseaux

ENSEEIHT

2

Plann Introductionn RTP/RTCPn QoS dans l’Internetn Session Description Protocol : SDPn Les protocoles de signalisation :

u SIPu H.323u MGCP

n Conclusion

2

3

Introduction : Que pourrait-être la voix sur IP ?

n Exemple :u John, devant son ordinateur, appelle Mary

(mary@enseeiht.fr), en demandant les options audio et video.u L’appel prévient l’agent d’appel de Mary

F L’agent d’appel “sonne” sur l’ordinateur de Mary, son téléphonecellulaire et son téléphone fixe

u Marie répond depuis l’ordinateur de son bureauu Durant l’appel, John décide d’ajouter Bob à la conversation

qui répond avec son téléphone cellulaireF L’agent d’appel de Bob doit trouver une passerelle entre le

réseau IP et le réseau Téléphonique commuté (RTC)u Par la suite, Bob décide d’envoyer un document video

F Il utilise le serveur Web pour diffuser (multicast) la séquencevideo

4

Introduction : Que pourrait-être la voix sur IP ?

n Services et Protocoles mis en jeu dans le scénarioprécédent :u Protocoles de Transport supports de communications

F pour la voixF pour la video en temps réelF pour la video stockée

• Solution : RTP diffusion en direct - RTSP données stockéesu Protocoles de signalisation

F mise en place de connexionF trouver les correspondants (pages blanches)F multicastF negotiations des formats des médias (audio ; audio et video)F contrôle des passerelles entre Internet et RTC

• Nombreuses solutions : H323, SIP, MGCP

3

5

Introduction : RTCn Le RTC a de nombreux avantages :

u Une bonne qualité de voixu Grande robustesse (système de signalisation : SS7)u Très sûru Services efficaces (réseau intelligent, fax)

n Mais le RTC a atteint ses limites : introduction denouveaux services (de données) trop cher :u le dernier km constitue un goulot d’étranglementu les connexions Web ne sont pas bien adaptées pour un circuit

de voix (le SS7 a été prévu pour le trafic de voix)u ATM, qui était “la solution”, est arrivé trop tard pas

d’applications ATM natives)

6

Introduction : Internetn Internet offre une base réelle pour une intégration de

service efficace (orienté paquet)n Mais le transport de la voix ne s’accomode pas bien :

F d’1 délai trop importantF d’1 gigue trop importante (service isochrone)

u Solutions possibles : DiffServ, MPLS, IntServ

n Conclusion : dans un premier temps, la voix sur IP devracoexister avec le RTC

4

7

Problèmes liés à la transmissionde la voix

n Délai et gigue dans le RTC :u Gigue négligeable (Commutation de Circuits)u Délai ~ Propagation. Faible sauf satellite (acoustic echo

problem)n Dans VoIP : 2 problèmes : partie fixe et variable.

u Partie Fixe :F Système d’Exploitation :

• la carte son– échantillonne le signal provenant du micro– accumule les échantillons dans un buffer– demande à l’OS de les récupérer par des interruptions

• Pb : pour la plupart des OS, période des interruptions >= 60 ms• Conséquence : arrivées groupées.• Solution : OS temps réel ou hardware dédié

8

Transmission de la voixn Délai Partie Fixe :

u Codeur :F beaucoup de codeurs sont orientés trames (plutôt

qu’échantillon)F Accumulation d’échantillons prend un certain tempsF de +, certains codeurs utilisent la technique “plus on en sait,

mieux on compresse”

u Politique de redondance :F limiter l’impact des pertes de paquetsF méthode proactive. E.g. : à chaque paquet, on ajoute une copie

(codée avec une qualité moindre) du paquet précédentF Nécessaire parce que les retransmissions ne sont pas possibles

(les paquets arriveraient trop tard !)F Problème : en cas de congestion, participe à la congestion !

5

9

Problèmes liés à la transmissionde la voix

n Partie Fixe (suite) :u Protocoles de Transport (RTP, UDP, IP) :

F ils ajoutent des délais en accolant les en-têtesF pour réduire l’overhead, on pourrait envisager de regrouper les

“trames”. Le multiplexage RTP n’est pas encore standardisé

n Partie Variable (gigue) :u due aux variations de délai dans le réseauu Solution : utiliser un buffer de réceptionu Principle : à la réception du premier paquet, le bufferiser

pendant une période fixe L puis lire de façon continue.F Difficulté : dimensionner L

• trop petit => trop de paquets perdus (arrivent trop tard)• trop grand => delai inacceptable (la voix = signal temps réel !)

10

RTP/RTCPu RTP solution communément acceptée pour transférer de la

voix sur un réseau de type paquet (Internet).u RTP envoie des données au-dessus de TCP ou de UDPu RTP permet de numéroter pour reséquencer et de compenser

la gigue due au multiplexage statistique (< routers) :F estampille : synchronisationF numérotation (pas fait par UDP)F type de données (e.g : PCM, H.263)

u RTP permet des sessions unicast ou multicastu Une session RTP par flux (port UDP / adresse Multicast).

F Flux synchronisés par RTCP

6

11

RTCP - RTP Control Protocoln RTCP port # = RTP port # +1n RTCP a pour but :

u distribuer des statistiques (Evaluation de la QoS) entre lesparticipants (émetteurs et récepteurs)

u Synchronisation entre les médias en comparant lesestampilles RTP (media relative time)

n RTP et RTCP permettent un contrôle de niveau applicatifde le connexion téléphonique

n RTP/RTCP n’ont pas d’influence sur le réseau lui-mêmen l’Internet n’est pas capable de garantir des délais/gigue/

pertes faibles : problème pour la voixu RTP permet de compenser une gigue modérée et RTCP

permet d’effectuer des adaptations au niveau des terminaux

12

1ère Solution: IntServIntegrated Services

n Problème : Durant une congestion tous les paquets sonttraités de la même façon => sensiblement le même délai

n Seuls contrôles possibles aux extrémités : trop lent (temps réel)

n Améliorer le modèle de base de l’Internetu 1 seule classe de trafic le best effort => plusieurs classes

n Créer des protocoles et des algorithmes pour mettre enœuvre ces nouveaux modèles de serviceu ancien modèle : pas de gestion des ressources au niveau IPu nouveau modèle : gestion explicite des ressources au niveau IP

n Principale différenceu ancien modèle : protocole sans étatu nouveau modèle : état de chaque flux géré dans chaque routeur

F utilisé pour l’admission d’appel et l’ordonnancementF mis à jour par un protocole de signalisation

7

13

IntServ : Integrated Servicesn Chaque source (flux) décrit ses caractéristiques de

trafic et ses besoins en Qualité de Service (parexemple, délai de bout en bout) en utilisant RSVP -Reservation Protocol

n Chaque routeur à la réception de ce message ajoute lescaractéristiques du flux dans une table (pas deréservation)

n Quand le message arrive à destination, le destinataireindique ses contraintes et envoie un message deréservation de ressources

n On essaye alors de réserver dans chaque routeur ledébit et la taille mémoire nécessaires pour garantir lescontraintes.

14

EmetteurRécepteur

Exemple - IntServn Délai et Bande Passante garantie par fluxn Allocation de ressources - contrôle d’admission par fluxn Etat de chaque flux - Chemin Stable

8

15

Exemple d’IntServ

EmetteurRécepteur

• Scheduling et Gestion de buffer par flux

16

Schéma général

ContrôleAdmission

Paquet dedonnées

Paquet dedonnées

Pla

n d

e C

on

trô

leP

lan

de

donn

ées

Scheduler

Routage Messagesroutage

messagesRSVP

Classifieur

RSVP

Choix chemin

Table - Forwarding Table QoS par flux

9

17

Classes de Servicen Le service peut être vu comme un contrat entre le réseau et le client :

service de bout en bout

3 classes de Servicen Service Garanti (Applications temps réel)

u réseau => client : borne sup sur le délai pour chaque paquetu client => réseau : pas plus de données envoyées que spécifiéu contrôle d’admission repose sur une analyse pire casu classification/scheduling par flux

n Charge contrôlée (Contraintes de Délai)u réseau => client: perf. ~ à 1 réseau best-effort peu chargéu client => réseau : pas plus de données envoyées que spécifiéu contrôle d’admission : mesures de trafic agrégéu ordonnancement sur une agrégation de flux possible

n best-effort (Applications “elastiques”)

18

Message PATH et RESVn Message PATH

u Flowspec: Spécification du Trafic (token bucket)u Routeurs stocke:

F l’adresse du nœud précédentF Emetteur et son Flowspec

n Message RESVu Suit le chemin inverse au message PATHu Flowspec + QoS désirée (e.g., queueing delay)u Routeur déroule :

F Contrôle d’admissionF Met à jour la réservation (qté de ressources)

10

19

Spécification: Token Bucketn 2 paramètres (r, b)

u r – débit d’arrivée des jetonsu b – taille de la file des jetons

n Débit d’arrivée <= R bit/s (e.g., R capacité du lien)n 1 bit est transmis s’il y a un jetonn Courbe d’arrivée – quantité maximale de bits transmis en une durée t

r bit/s

b bits

<= R bit/s

regulateurtime

bits

b

enveloppe R

enveloppe r

Courbe d’arrivées

20

Réservation de bout en boutn Quand R reçoit le message PATH il connaît

u Caracteristique de Trafic (tspec): (r,b,R)u Nombre de sauts

n R il renvoie cette info + le délai pire cas D qu’elle peut supporterdans le message RESV

n Chaque routeur le long du chemin fournit un délai garanti (parsaut) et forwarde le message RESV données mises à jour

S1S1

S2S2

S3S3

SSRR(b,r,R) (b,r,R,3)

Nombre de saut

(b,r,R,2,D-d1)(b,r,R,1,D-d1-d2)(b,r,R,0,0)

(b,r,R,3,D)

worst-case delayPATHRESV

11

21

Réservation pour 1 noeud

n Etant donné (b,r,R) et le délai dn Allouer le débit ra et la taille mémoire Ba qui

garantisse d

bits

b

enveloppe r Courbe d’arrivée

d

Ba

enveloppe ra

22

“Soft State”n Un état est associé à une session + durée de vie

n Etat perdu quand la temporisation expire

n Emetteur et Récepteur rafraichissent périodiquementl’état en s’envoyant des messages PATH/RESV et enréarmant les temporisations

n Avantageu les paquets de signalisation peuvent éventuellement être

perdus (pas besoin de transmission fiable)

u peuvent s’adapter aux changements de routes

12

23

RSVP et le routage

n RSVP est prévu pour fonctionner avec de nombreuxprotocoles de routage

n Service de routage minimalu RSVP demande à l’algorithme de routage dans chaque

nœud comment router le message PATH

n Routage QoSu Sélection de route RSVP repose sur les paramètres de

QoS

n Routage Explicite

24

Récapitulatif de IntServn Avantages :

u définition claire de la QoS et de la définition du servicen Inconvénient :

u une source peut avoir du mal à déterminer ses paramètres detoken bucket

u passage à l’échelle (trop nombreux flux à gérer)u fournir un “débit” r impose une politique d’ordonnancement

compliquéen Conclusion : difficultés de déploiement à grande échelle

a

13

25

La différentiation de Services :DiffServ

n Objectif : fournir de la QoS de façon “scalable”n Principe :

u Agrégation de flots en classes.u Per Hop Behavior :

F EF (Expedited Forwarding) : délai faible. Cette classe est laplus prioritaire

F AF (Assured Forwarding) : divisée en sous-classes, correspondsensiblement à des niveaux de priorités

F Best Effortu Routeurs servent des classes et plus des flux ⇒ scalableu Pour émettre du trafic, une source établit un SLA (Service

Level Agreement) avec un routeur de bordureu Routeurs de bordure et fournisseur de Bande Passante (BB)

gère la bande passante, assurant par exemple que le traficEF ne constitue pas plus de 10 % du débit total.

26

Differentiated Services(Diffserv)

n Découpages en Domainesn “Edge routers”

u Lissage et contrôle par agrégatu Marque les paquets (champ TOS d’IPv4) => classes

n “Core routers”u Traite les paquets en utilisant le marquage (PHB)

IngressEgressEgress

IngressEgressEgress

DS-1 DS-2

Edge router Core router

14

27

DiffServn Plusieurs types de service (reposant sur les PHB)

u Service Assuré (Olympic - décliné en 3 niveaux) utilise AFu Service Premium utilise EFu best-effort

n 2 informations binairesu bit Pu bit A

28

Services Assuré et PrémiumService Assurén Defini 1 profil utilisateur i.e. combien de trafic assuré il

peut envoyer dans le réseau (toutes destinatio. confondues)n Réseau : fournit un taux de perte inférieur au best-effort

u En cas de congestion, on perd d’abord les paquets Best-Effortn Usager : Pas plus de paquets ‘service assuré’ que son profil

u sinon le trafic en excès est déclassé en Best Effort

Service Prémiumn “Tuyau virtuel” entre 1 “ingress” et 1 “egress” routern Réseau : garantit pas de perte ET faible délain Utilisateur : n’envoie pas + que la taille du “tuyau”

u Trafic en excès retardé et supprimé quand la file déborde

15

29

Routeur de bordure

Classifieur

Conditionneur

Conditionneur

Scheduler

Classe 1

Classe 2

Best-effort

Trafic Marqué

Ingress

Classification par agrégat (par exempletrafic d’un utilisateur)

Traficdonnées

30

Mesure/Marquagen Service assurén Trafic conforme marqué:

u bit A positionnén Trafic non conforme (en excès) n’est pas marqué

u bit A effacé (s’il était positionné) dans chaquepaquet ; trafic traité comme du best effort

r bit/s

b bits

Mesure Trafic conforme

Trafic non conforme

Trafic Assuré

Profil Utilisateur (token bucket)

Mettre A

Effacer A

16

31

Mesure-Marquage-Lissagen Service Premiumn Trafic conforme marqué (Bit P positionné)n Trafic non-conforme retardé/ supprimé (buffer plein)

r bit/s

b bits

Mesure/Lissage/Positionner P

Trafic conforme

Trafic non-conforme(retardé et le cas échéant supprimé)

Trafic prémium

Profil Utilisateur(token bucket)

32

Schedulern Utilisé par tous les routeursn Pour le service Premium – priorité stricten Pour le service Assuré – RIO (RED with In and Out)

u Suppression en priorité des paquets non-conformesF Pour le trafic non-conforme tenir compte de tous les paquetsF Pour le trafic conforme ne tenir compte que des paquets conformes

OUT IN

Taille (moyenne) de la file

1

Probabilitéde perte

17

33

Scheduler

n Trafic envoyé avec une priorité hauten Trafic assuré passe à travers RIO et est

envoyé avec une priorité faible

Bit P=1?

Bit A=1 ? RIO

oui

nonouinon

Haute priorité

Faible priorité

34

Contrôle du cheminn Chaque domaine possède un Bandwidth Broker (BB)

u Allocation de bande passante entre entrée/sortien Réalise le contrôle d’admission pour le domainen BB pas facile à implanter

u Connaissance complète du domaineu “Single point of failure”, goulot d’étranglement

BBBB BBBB BBBB1

2 3

579

émetteur

récepteur8 profil 6

profil4 profil

18

35

Comparaison

Setup par fluxSetup à long termePas de setupComplexité

Bout en boutDomaineBout en boutportée

-- (chaque routeurmaintient l’état dechaque flux)

+ (routeurs de bordurepar agrégat, routeursinternes par PHB)

++ (les routeursne maintiennentque les tables deroutage)

Passage àl’échelle

Isolation etgaranties par flux

Isolation et garantiespar agrégat

Pas d’isolationPas de guaranties

Service

IntservDiffservBest-Effort

Protocole designalisation:

SIP

19

37

Introductionn SIP (RFC 2543) issu du groupe de travail MMUSIC

(Multiparty Multimedia Session Control) de l’IETFn MMUSIC :

u SIP : Session Initiation Protocolu SDP : Session Description Protocol

F (type de format échangé, adresses, nom de la session …)u RTSP : Real-time Streaming Protocol

n Objectifs de SIPu Localisationu Etablissement d’appelu (Re)-Négotiation des paramètres de sessionu Gestion des participants de l’appelu Fin et transferts d’appels

38

Transactions et messages SIPn Entités SIP communiquent via des ‘transactions’ :

u 1 transaction = 1 requête + 1 ou plusieurs réponsesu Transactions numérotées, mode client/serveur

n SIP fonctionne sur TCP ou UDPu Rem : les flux sont eux véhiculés par RTP/RTCP sur UDP

n 2 types de messages : Requêtes et Réponsesu En-tête :

F Call-ID. E.g. maconference23sept9h30@conf.comF Cseq : numéro de séquenceF From : e.g. From: ‘Mydisplayname’ <sip:me@company.com>F To : e.g. To: ‘Helpdesk’ <sip:helpdesk@company.com>;F Via : e.g. Via : router1@provider.com;

20

39

SIP Requêtes et Réponsesn Requêtes

u INVITE : mises en place de connexionu ACK, BYE, CANCEL, REGISTER

n Réponsesu Traitement en coursu Succèsu Redirectionu Echec (du client, du serveur)

40

Appel Téléphonique entreutilisateurs Internet

INVITEjohn@192.190.132.31c=IN IP4 192.190.132.20m=audio 49170 RTP/AVP 0 192.190.132.31192.190.132.20

Port # 49170 µ law

RTP/AVP 0Audio = Loi µ

200 OKc=IN IP4 192.190.132.31m=audio 12345 RTP/AVP 3

John peut recevoirdes données GSMsur le port 12345GSM

Port # 12345

ACK

JohnMary

port UDP où le flux RTP est attendu

21

41

Entités SIPn Annuaire :

u garde la trace de la correspondance = SIP @ / IP @u utilise la requête ‘Register’u Découverte de l’annuaire : Groupe multicast dédié :

sip.mcast.net:224.0.1.75 (TTL=1)u Communication possible en unicast si on connaît sa

localisationu Enregistrement non permanent (timeout)

n Serveur de redirection:u répond à des demandes de connexions par des réponses 3xxu en donnant d’autres adresses ...

Protocole designalisation

H.323

22

43

Composants et Canaux H.323n Utilisateur – contrôleur (H.225.0)

u UDPn Signalisation : H.225 (Q.931)

u Contrôle d’appelu service supplémentairesu TCP; depuis la v3: éventuellement UDP

n contrôle (H.245):u Négociation type de données et capacités des intervenants ;u ouverture des “canaux logiques”u Reste ouverte pendant toute la durée des échangesu Utilise TCP

n Canaux logiques : transporte flux audio, video (UDP)

44

1ère Phase : Initialisation de l’appel (H.225)

H.225: SETUPCall Identifier : 45442345Email-ID of A : John@domain1.comSource type : PCCall Type : Point to PointDestination @ : Mark@domain2.com

Terminal A : John Terminal B : Mark

Call Signal Channel(Q.931 Channel)TCP port # 1720

Call Signal Channel(Q.931 Channel)TCP port # 1720

Setup

Alerting

Connect

H.225: CONNECT

Call Identifier : 45442345

H.245 address : 10.2.3.4:8741

IP address : 10.2.3.4

Dedicated port #

23

45

2ème Phase : Canal de contrôle (H.245)

Terminal A : John Terminal B : Mark

H.245 Control ChannelTCP port #

Term. Cap. Set

Term. Cap. Set Ack

H.245: TerminalCapabilitySetMultiplex CapabilityCapability Table :

H.261 VideoG711 A law 64kG729

H.245: TerminalCapabilitySetMultiplex CapabilityCapability Table :

H.261 VideoG711 A law 64k

IP address : 10.2.3.4

H.245 Control ChannelTCP port # 8741

Term. Cap. Set

Term. Cap. Set Ack

46

Terminal A : John

H.245 Control ChannelTCP port #

H.245: OpenLogicalChannelLogical Channel 1, RTCP RR port 7771G711, A law 64kSession #, RTP payload typesilence suppression

H.245: OpenLogicalChannelAckLogical Channel 1,RTCP SR port 9345RTP port 9344

IP address : 10.2.3.4

Open logical channel

Open logical channel Ack

Open logical channel

Open logical channel Ack

Mise en place de 2 canaux

unidirectionnels

3ème phase : Mise en place du Dialogue

Terminal B : Mark

H.245 Control ChannelTCP port # 8741

24

47

4ème phase : Dialogue

Terminal A : John

Audio Channel =logical channel 1

RTP : UDPRTCP :UDP 7771RTCP :UDP

H.245 Control ChannelTCP port #

IP address : 10.2.3.4

H.245 Control ChannelTCP port # 8741

Logical Channel 0

Terminal B : Mark

Audio Channel =logical channel 1

RTP : UDP 9344RTCP :UDPRTCP :UDP 9345

RTP Flow from A to B

RTCP RR

RTCP SR

RTP Flow from B to A... ......

48

Dernière Phase : Finn Sur le canal H.245, fermeture de tous les canaux de

donnéesu Initié par le premier qui raccrocheu CloseLogicalChannel et CloseLogicalChannel Ack

n Si le canal H.225 n’a pas été fermé, Release Completemessage est envoyé

25

49

Gateway demandes’il peut router l’appel

Destinataire dans le RTC

Contrôleur PasserelleARQ (number=+33 123456789)

ACF (Q.931=10.1.2.3:1720)

SETUP (number=+33 1 93 26 00 00)

ARQ

ACF

ALERTING

CONNECT

Canal Q.931

¯

Gateway peut éventuellementchanger le numéro

(e.g. suppression du +33)

50

H.323 versus SIPn Avantages de SIP :

u Rapidité : établissement de connexion beaucoup plus simple(H.323 impose de nombreux échanges)

u Multicast : SIP est prévu pour fonctionner au-dessus d’unbackbone IP multicast pour le transport des données et de lasignalisation (H.323 fait du multi-unicast)

n Avantages de H.323 :u Canaux logiques : distinction claire entre les canaux de

données et les canaux de contrôle alors qu’avec SIP leterminal doit être prêt à recevoir des données d’annonce decapacités

26

51

Conclusionn Pour remplacer le RTC, VoIP a besoin d’un vrai protocole de

signalisation efficaceu Cela prend beaucoup de temps ⇒ la coexistence RTC/VoIP va

durer encore longtempsu Besoin d’une proposition globale

F A l’heure actuelle, bataille entre SIP et H.323F Groupe de travail MEGACO IETF (en commun avec l’ITU-T)

essaye de proposer un rapprochement MGCP - H.323

n Les protocoles de signalisation ont besoin d’une bonnedisponibilité (pour le RTC 99.999 %), délai raisonnable +transfert de la voix contraignant

F solutions DiffServ/MPLS