Voix sur IP et QoS dans l Internet

Transcription

1 Voix sur IP et QoS dans l Internet André-Luc Beylot Département Télécoms et Réseaux ENSEEIHT Plan Introduction RTP/RTCP QoS dans l Internet Session Description Protocol : SDP Les protocoles de signalisation : SIP H.323 MGCP Conclusion 2 1

2 Introduction : Que pourraitêtre la voix sur IP? Exemple : John, devant son ordinateur, appelle Mary (mary@enseeiht.fr), en demandant les options audio et video. L appel prévient l agent d appel de Mary L agent d appel sonne sur l ordinateur de Mary, son téléphone cellulaire et son téléphone fixe Marie répond depuis l ordinateur de son bureau Durant l appel, John décide d ajouter Bob à la conversation qui répond avec son téléphone cellulaire L agent d appel de Bob doit trouver une passerelle entre le réseau IP et le réseau Téléphonique commuté (RTC) Par la suite, Bob décide d envoyer un document video Il utilise le serveur Web pour diffuser (multicast) la séquence video 3 Introduction : Que pourraitêtre la voix sur IP? Services et Protocoles mis en jeu dans le scénario précédent : Protocoles de Transport supports de communications pour la voix pour la video en temps réel pour la video stockée Solution : RTP diffusion en direct - RTSP données stockées Protocoles de signalisation mise en place de connexion trouver les correspondants (pages blanches) multicast negotiations des formats des médias (audio ; audio et video) contrôle des passerelles entre Internet et RTC Nombreuses solutions : H323, SIP, MGCP 4 2

3 Introduction : RTC Le RTC a de nombreux avantages : Une bonne qualité de voix Grande robustesse (système de signalisation : SS7) Très sûr Services efficaces (réseau intelligent, fax) Mais le RTC a atteint ses limites : introduction de nouveaux services (de données) trop cher : le dernier km constitue un goulot d étranglement 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) ATM, qui était la solution, est arrivé trop tard pas d applications ATM natives) 5 Introduction : Internet Internet offre une base réelle pour une intégration de service efficace (orienté paquet) Mais le transport de la voix ne s accomode pas bien : d 1 délai trop important d 1 gigue trop importante (service isochrone) Solutions possibles : DiffServ, MPLS, IntServ Conclusion : dans un premier temps, la voix sur IP devra coexister avec le RTC 6 3

4 Problèmes liés à la transmission de la voix Délai et gigue dans le RTC : Gigue négligeable (Commutation de Circuits) Délai ~ Propagation. Faible sauf satellite (acoustic echo problem) Dans VoIP : 2 problèmes : partie fixe et variable. Partie Fixe : 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é 7 Transmission de la voix Délai Partie Fixe : Codeur : beaucoup de codeurs sont orientés trames (plutôt qu échantillon) Accumulation d échantillons prend un certain temps de +, certains codeurs utilisent la technique plus on en sait, mieux on compresse Politique de redondance : limiter l impact des pertes de paquets méthode proactive. E.g. : à chaque paquet, on ajoute une copie (codée avec une qualité moindre) du paquet précédent Nécessaire parce que les retransmissions ne sont pas possibles (les paquets arriveraient trop tard!) Problème : en cas de congestion, participe à la congestion! 8 4

5 Problèmes liés à la transmission de la voix Partie Fixe (suite) : Protocoles de Transport (RTP, UDP, IP) : ils ajoutent des délais en accolant les en-têtes pour réduire l overhead, on pourrait envisager de regrouper les trames. Le multiplexage RTP n est pas encore standardisé Partie Variable (gigue) : due aux variations de délai dans le réseau Solution : utiliser un buffer de réception Principle : à la réception du premier paquet, le bufferiser pendant une période fixe L puis lire de façon continue. Difficulté : dimensionner L trop petit => trop de paquets perdus (arrivent trop tard) trop grand => delai inacceptable (la voix = signal temps réel!) 9 RTP/RTCP RTP solution communément acceptée pour transférer de la voix sur un réseau de type paquet (Internet). RTP envoie des données au-dessus de TCP ou de UDP RTP permet de numéroter pour reséquencer et de compenser la gigue due au multiplexage statistique (< routers) : estampille : synchronisation numérotation (pas fait par UDP) type de données (e.g : PCM, H.263) RTP permet des sessions unicast ou multicast Une session RTP par flux (port UDP / adresse Multicast). Flux synchronisés par RTCP 10 5

6 RTCP - RTP Control Protocol RTCP port # = RTP port # +1 RTCP a pour but : distribuer des statistiques (Evaluation de la QoS) entre les participants (émetteurs et récepteurs) Synchronisation entre les médias en comparant les estampilles RTP (media relative time) RTP et RTCP permettent un contrôle de niveau applicatif de le connexion téléphonique RTP/RTCP n ont pas d influence sur le réseau lui-même l Internet n est pas capable de garantir des délais/gigue/ pertes faibles : problème pour la voix RTP permet de compenser une gigue modérée et RTCP permet d effectuer des adaptations au niveau des terminaux 11 1ère Solution: IntServ Integrated Services Problème : Durant une congestion tous les paquets sont traités de la même façon => sensiblement le même délai Seuls contrôles possibles aux extrémités : trop lent (temps réel) Améliorer le modèle de base de l Internet 1 seule classe de trafic le best effort => plusieurs classes Créer des protocoles et des algorithmes pour mettre en œuvre ces nouveaux modèles de service ancien modèle : pas de gestion des ressources au niveau IP nouveau modèle : gestion explicite des ressources au niveau IP Principale différence ancien modèle : protocole sans état nouveau modèle : état de chaque flux géré dans chaque routeur utilisé pour l admission d appel et l ordonnancement mis à jour par un protocole de signalisation 12 6

7 IntServ : Integrated Services Chaque source (flux) décrit ses caractéristiques de trafic et ses besoins en Qualité de Service (par exemple, délai de bout en bout) en utilisant RSVP - Reservation Protocol Chaque routeur à la réception de ce message ajoute les caractéristiques du flux dans une table (pas de réservation) Quand le message arrive à destination, le destinataire indique ses contraintes et envoie un message de réservation de ressources On essaye alors de réserver dans chaque routeur le débit et la taille mémoire nécessaires pour garantir les contraintes. 13 Exemple - IntServ Délai et Bande Passante garantie par flux Allocation de ressources - contrôle d admission par flux Etat de chaque flux - Chemin Stable Récepteur Emetteur 14 7

8 Exemple d IntServ Scheduling et Gestion de buffer par flux Emetteur Récepteur 15 Schéma général Messages routage Routage RSVP Contrôle Admission Plan de Contrôle messages RSVP Paquet de données Table - Forwarding Choix chemin Classifieur Table QoS par flux Scheduler Plan de données Paquet de données 16 8

9 Classes de Service Le service peut être vu comme un contrat entre le réseau et le client : service de bout en bout 3 classes de Service Service Garanti (Applications temps réel) réseau => client : borne sup sur le délai pour chaque paquet client => réseau : pas plus de données envoyées que spécifié contrôle d admission repose sur une analyse pire cas classification/scheduling par flux Charge contrôlée (Contraintes de Délai) réseau => client: perf. ~ à 1 réseau best-effort peu chargé client => réseau : pas plus de données envoyées que spécifié contrôle d admission : mesures de trafic agrégé ordonnancement sur une agrégation de flux possible best-effort (Applications elastiques ) 17 Message PATH et RESV Message PATH Flowspec: Spécification du Trafic (token bucket) Routeurs stocke: l adresse du nœud précédent Emetteur et son Flowspec Message RESV Suit le chemin inverse au message PATH Flowspec + QoS désirée (e.g., queueing delay) Routeur déroule : Contrôle d admission Met à jour la réservation (qté de ressources) 18 9

10 Spécification: Token Bucket 2 paramètres (r, b) r débit d arrivée des jetons b taille de la file des jetons Débit d arrivée <= R bit/s (e.g., R capacité du lien) 1 bit est transmis s il y a un jeton Courbe d arrivée quantité maximale de bits transmis en une durée t Courbe d arrivées r bit/s bits b bits b enveloppe R enveloppe r <= R bit/s regulateur time 19 Réservation de bout en bout Quand R reçoit le message PATH il connaît Caracteristique de Trafic (tspec): (r,b,r) Nombre de sauts R il renvoie cette info + le délai pire cas D qu elle peut supporter dans le message RESV Chaque routeur le long du chemin fournit un délai garanti (par saut) et forwarde le message RESV données mises à jour Nombre de saut S (b,r,r,0,0) PATH RESV (b,r,r) S1 S2 (b,r,r,2,d-d 1 ) (b,r,r,1,d-d 1 -d 2 ) (b,r,r,3) S3 R (b,r,r,3,d) worst-case delay 20 10

11 Réservation pour 1 noeud Etant donné (b,r,r) et le délai d Allouer le débit r a et la taille mémoire B a qui garantisse d enveloppe r a bits enveloppe r Courbe d arrivée b d B a 21 Soft State Un état est associé à une session + durée de vie Etat perdu quand la temporisation expire Emetteur et Récepteur rafraichissent périodiquement l état en s envoyant des messages PATH/RESV et en réarmant les temporisations Avantage les paquets de signalisation peuvent éventuellement être perdus (pas besoin de transmission fiable) peuvent s adapter aux changements de routes 22 11

12 RSVP et le routage RSVP est prévu pour fonctionner avec de nombreux protocoles de routage Service de routage minimal RSVP demande à l algorithme de routage dans chaque nœud comment router le message PATH Routage QoS Sélection de route RSVP repose sur les paramètres de QoS Routage Explicite 23 Récapitulatif de IntServ Avantages : définition claire de la QoS et de la définition du service Inconvénient : une source peut avoir du mal à déterminer ses paramètres de token bucket passage à l échelle (trop nombreux flux à gérer) fournir un débit r a impose une politique d ordonnancement compliquée Conclusion : difficultés de déploiement à grande échelle 24 12

13 La différentiation de Services : DiffServ Objectif : fournir de la QoS de façon scalable Principe : Agrégation de flots en classes. Per Hop Behavior : EF (Expedited Forwarding) : délai faible. Cette classe est la plus prioritaire AF (Assured Forwarding) : divisée en sous-classes, correspond sensiblement à des niveaux de priorités Best Effort Routeurs servent des classes et plus des flux scalable Pour émettre du trafic, une source établit un SLA (Service Level Agreement) avec un routeur de bordure Routeurs de bordure et fournisseur de Bande Passante (BB) gère la bande passante, assurant par exemple que le trafic 25 EF ne constitue pas plus de 10 % du débit total. Differentiated Services (Diffserv) Découpages en Domaines Edge routers Lissage et contrôle par agrégat Marque les paquets (champ TOS d IPv4) => classes Core routers Traite les paquets en utilisant le marquage (PHB) DS-1 DS-2 Ingress Egress Ingress Egress Edge router Core router 26 13

14 DiffServ Plusieurs types de service (reposant sur les PHB) Service Assuré (Olympic - décliné en 3 niveaux) utilise AF Service Premium utilise EF best-effort 2 informations binaires bit P bit A 27 Services Assuré et Prémium Service Assuré Defini 1 profil utilisateur i.e. combien de trafic assuré il peut envoyer dans le réseau (toutes destinatio. confondues) Réseau : fournit un taux de perte inférieur au best-effort En cas de congestion, on perd d abord les paquets Best-Effort Usager : Pas plus de paquets service assuré que son profil sinon le trafic en excès est déclassé en Best Effort Service Prémium Tuyau virtuel entre 1 ingress et 1 egress router Réseau : garantit pas de perte ET faible délai Utilisateur : n envoie pas + que la taille du tuyau Trafic en excès retardé et supprimé quand la file déborde 28 14

15 Routeur de bordure Ingress Trafic données Conditionneur Classe 1 Conditionneur Classe 2 Classifieur Best-effort Trafic Marqué Scheduler Classification par agrégat (par exemple trafic d un utilisateur) 29 Mesure/Marquage Service assuré Trafic conforme marqué: bit A positionné Trafic non conforme (en excès) n est pas marqué bit A effacé (s il était positionné) dans chaque paquet ; trafic traité comme du best effort r bit/s b bits Profil Utilisateur (token bucket) Trafic Assuré Mesure Mettre A Trafic conforme Effacer A Trafic non conforme 30 15

16 Mesure-Marquage-Lissage Service Premium Trafic conforme marqué (Bit P positionné) Trafic non-conforme retardé/ supprimé (buffer plein) r bit/s b bits Profil Utilisateur (token bucket) Trafic prémium Mesure/ Lissage/ Positionner P Trafic conforme Trafic non-conforme (retardé et le cas échéant supprimé) 31 Scheduler Utilisé par tous les routeurs Pour le service Premium priorité stricte Pour le service Assuré RIO (RED with In and Out) Suppression en priorité des paquets non-conformes Pour le trafic non-conforme tenir compte de tous les paquets Pour le trafic conforme ne tenir compte que des paquets conformes Probabilité de perte 1 OUT IN Taille (moyenne) de la file 32 16

17 Scheduler Trafic envoyé avec une priorité haute Trafic assuré passe à travers RIO et est envoyé avec une priorité faible Bit P=1? oui Haute priorité non Bit A=1? oui non RIO Faible priorité 33 Contrôle du chemin Chaque domaine possède un Bandwidth Broker (BB) Allocation de bande passante entre entrée/sortie Réalise le contrôle d admission pour le domaine BB pas facile à implanter Connaissance complète du domaine Single point of failure, goulot d étranglement émetteur 9 BB 7 BB 5 BB 8 profil 6 profil 4 profil récepteur 34 17

18 Comparaison Best-Effort Diffserv Intserv Service Pas d isolation Pas de guaranties Isolation et garanties par agrégat Isolation et garanties par flux portée Bout en bout Domaine Bout en bout Complexité Pas de setup Setup à long terme Setup par flux Passage à l échelle ++ (les routeurs ne maintiennent que les tables de routage) + (routeurs de bordure par agrégat, routeurs internes par PHB) -- (chaque routeur maintient l état de chaque flux) 35 Protocole de signalisation: SIP 18

19 Introduction SIP (RFC 2543) issu du groupe de travail MMUSIC (Multiparty Multimedia Session Control) de l IETF MMUSIC : SIP : Session Initiation Protocol SDP : Session Description Protocol (type de format échangé, adresses, nom de la session ) RTSP : Real-time Streaming Protocol Objectifs de SIP Localisation Etablissement d appel (Re)-Négotiation des paramètres de session Gestion des participants de l appel Fin et transferts d appels 37 Transactions et messages SIP Entités SIP communiquent via des transactions : 1 transaction = 1 requête + 1 ou plusieurs réponses Transactions numérotées, mode client/serveur SIP fonctionne sur TCP ou UDP Rem : les flux sont eux véhiculés par RTP/RTCP sur UDP 2 types de messages : Requêtes et Réponses En-tête : Call-ID. E.g. maconference23sept9h30@conf.com Cseq : numéro de séquence From : e.g. From: Mydisplayname <sip:me@company.com> To : e.g. To: Helpdesk <sip:helpdesk@company.com>; Via : e.g. Via : router1@provider.com; 38 19

20 SIP Requêtes et Réponses Requêtes INVITE : mises en place de connexion ACK, BYE, CANCEL, REGISTER Réponses Traitement en cours Succès Redirection Echec (du client, du serveur) 39 Appel Téléphonique entre utilisateurs Internet Mary John INVITE john@ c=in IP m=audio RTP/AVP 0 RTP/AVP 0 Audio = Loi m port UDP où le flux RTP est attendu Port # m law 200 OK c=in IP m=audio RTP/AVP 3 GSM John peut recevoir des données GSM sur le port Port # ACK 40 20

21 Entités SIP Annuaire : garde la trace de la correspondance = / utilise la requête Register Découverte de l annuaire : Groupe multicast dédié : sip.mcast.net: (TTL=1) Communication possible en unicast si on connaît sa localisation Enregistrement non permanent (timeout) Serveur de redirection: répond à des demandes de connexions par des réponses 3xx en donnant d autres adresses Protocole de signalisation H

22 Composants et Canaux H.323 Utilisateur contrôleur (H.225.0) UDP Signalisation : H.225 (Q.931) Contrôle d appel service supplémentaires TCP; depuis la v3: éventuellement UDP contrôle (H.245): Négociation type de données et capacités des intervenants ; ouverture des canaux logiques Reste ouverte pendant toute la durée des échanges Utilise TCP Canaux logiques : transporte flux audio, video (UDP) 43 1ère Phase : Initialisation de l appel (H.225) Terminal A : John H.225: SETUP Call Identifier : ID of A : John@domain1.com Source type : PC Call Type : Point to Point : Mark@domain2.com IP address : Terminal B : Mark Call Signal Channel (Q.931 Channel) TCP port # 1720 Setup Alerting Connect Call Signal Channel (Q.931 Channel) TCP port # 1720 Dedicated port # H.225: CONNECT Call Identifier : H.245 address : :

23 2ème Phase : Canal de contrôle (H.245) Terminal A : John H.245: TerminalCapabilitySet Multiplex Capability Capability Table : H.261 Video G711 A law 64k G729 IP address : Terminal B : Mark H.245 Control Channel TCP port # Term. Cap. Set Term. Cap. Set Ack Term. Cap. Set H.245 Control Channel TCP port # 8741 Term. Cap. Set Ack H.245: TerminalCapabilitySet Multiplex Capability Capability Table : H.261 Video G711 A law 64k 45 3ème phase : Mise en place du Dialogue Terminal A : John H.245: OpenLogicalChannel Logical Channel 1, RTCP RR port 7771 G711, A law 64k Session #, RTP payload type silence suppression IP address : Terminal B : Mark H.245 Control Channel TCP port # Open logical channel Open logical channel Open logical channel Ack H.245 Control Channel TCP port # 8741 Open logical channel Ack Mise en place de 2 canaux unidirectionnels H.245: OpenLogicalChannelAck Logical Channel 1, RTCP SR port 9345 RTP port

24 4ème phase : Dialogue IP address : Terminal A : John Terminal B : Mark Audio Channel = logical channel 1 RTP : UDP RTCP :UDP 7771 RTCP :UDP RTP Flow from A to B RTCP RR RTCP SR Audio Channel = logical channel 1 RTP : UDP 9344 RTCP :UDP RTCP :UDP 9345 H.245 Control Channel TCP port #... RTP Flow from B to A Logical Channel 0 H.245 Control Channel TCP port # Dernière Phase : Fin Sur le canal H.245, fermeture de tous les canaux de données Initié par le premier qui raccroche CloseLogicalChannel et CloseLogicalChannel Ack Si le canal H.225 n a pas été fermé, Release Complete message est envoyé 48 24

25 Destinataire dans le RTC ARQ Contrôleur (number= ) ACF (Q.931= :1720) Passerelle Gateway peut éventuellement changer le numéro (e.g. suppression du +33) Canal Q.931 ALERTING SETUP (number= ) ARQ ACF CONNECT Gateway demande s il peut router l appel 49 Avantages de SIP : H.323 versus SIP Rapidité : établissement de connexion beaucoup plus simple (H.323 impose de nombreux échanges) Multicast : SIP est prévu pour fonctionner au-dessus d un backbone IP multicast pour le transport des données et de la signalisation (H.323 fait du multi-unicast) Avantages de H.323 : Canaux logiques : distinction claire entre les canaux de données et les canaux de contrôle alors qu avec SIP le terminal doit être prêt à recevoir des données d annonce de capacités 50 25

26 Conclusion Pour remplacer le RTC, VoIP a besoin d un vrai protocole de signalisation efficace Cela prend beaucoup de temps la coexistence RTC/VoIP va durer encore longtemps Besoin d une proposition globale A l heure actuelle, bataille entre SIP et H.323 Groupe de travail MEGACO IETF (en commun avec l ITU-T) essaye de proposer un rapprochement MGCP - H.323 Les protocoles de signalisation ont besoin d une bonne disponibilité (pour le RTC %), délai raisonnable + transfert de la voix contraignant solutions DiffServ/MPLS 51 26