La voix sur IP

1. Université Montpellier II – 2007 & 2008 La voix sur IP Cisco - modèle 7912G De la communication audioau protocole H323 Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

2. Sommaire Cisco - modèle 7920 Communication audio et video en mode paquet Codage des flux Le protocole H323 : généralités, présentation pas à pas Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

3. De la technique analogique à la digitalisation La téléphonie analogique classique utilise la modulation de signaux électriques le long d’un câble : solution très ancienne mais simple avec des délais de transmission courts, utilisant le multiplexage en fréquence. Communication audio et video en mode paquet La transformation d'un signal analogique en signal numérique est appelée numérisation. La numérisation comporte deux activités parallèles : l'échantillonnage et la quantification. L'échantillonnage consiste à prélever périodiquement des échantillons d'un signal analogique. La quantification consiste à affecter une valeur numérique à chaque échantillon prélevé. Application du théorème de Shannon aux signaux transportant la voix : numérisation sur RNIS (300 à 4000 Hz) : 8 x 8000 = 64 Kbits/s Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

4. Multiplexage temporel de canaux de communication Le multiplexage temporel (TDM : Time Division Multiplexing) permet de juxtaposer des canaux pour la voix sur une seule ligne de transmission. Communication audio et video en mode paquet Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

5. Multiplexeurstatistique Optimisation de la bande passante Introduction de gigue et de délai Multiplexage statistique Le multiplexage statistique libère les canaux non utilisés (VAD : Voice Activity Detection) et tranfère les données en mode asynchrone. Communication audio et video en mode paquet Parfait exemple de multiplexeur statistique : un routeur IP … La gigue Le multiplexage statistique introduit un délai variable dans la communication, et les terminaux récepteurs doivent corriger cet effet. Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

6. Transport de la voix et de la video sur IP avec RTP • RTP (Real-Time Transport Protocol) permet aux logiciels de réception de compenser la gigue et de remettre en séquence les paquets IP, et utilise le plus fréquemment UDP. Il permet le transport des données utiles (niveau applicatif). • RTP transporte : • une information sur le type de données transportées • des marqueurs temporels • des numéros de séquence Communication audio et video en mode paquet Payload type : information sur les données temps réel transportées (type de Codec audio ou video) Timestamp : l’unité de temps dépend du type de contenu et s’appuie sur une synchronisation via RTCP. Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

7. V=2 P RC PT = SR = 200 Longueur SSRC de l’émetteur (source de synchronisation) Marqueur temporel (mot de poids fort) Marqueur temporel (mot de poids faible) Marqueur temporel RTP Nombre de paquets envoyés Nombre d’octets envoyés SSRC x (SSRC de la première source) Taux de perte Nombre cumulé de paquets perdus Plus grand numéro de séquence reçu dans un message SR Valeur de gigue Dernier marqueur temporel reçu, format NTP compact Délai depuis l’arrivée du dernier marqueur temporel reçu 0 31 Transport de la voix et de la video sur IP avec RTCP RTCP (Real-Time Transport Control Protocol) permet de transmettre épisodiquement des paquets de contrôle (coordonnées des participants, statistiques, paramètres de qualité…) Rapport d’émetteur (Sender Report) 1e section : nbr de rapports inclus dans le message, type de paquet, longueur en mots de 32 bits, SSRC de l’émetteur 2e section : instant d’envoi du SR au format NTP, marqueur temporel RTP, nbr de paquets envoyés depuis le début de la session, nbr d’octets envoyés pour l’ensemble des flux 3e section : SSRC de la source, évaluation du taux de pertes, valeur estimée de gigue, délai depuis le dernier SR (multiples de 1/65536e de seconde) Rapport récepteur (Receiver Report) : PT = 201, pas de 2e section Communication audio et video en mode paquet Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

8. Codage des flux média (voix) : les CODEC Tous les flux média peuvent être véhiculés par RTP, mais après conversion de données analogiques en données digitalisées. Le rôle des CODEC est d’opérer cette transformation. Communication audio et video en mode paquet Caractéristiques des CODEC Utilisation de la bande passante Les codeurs bande étroite (300 à 3400 Hz) sont disponibles de 1,2 Kbit/s jusqu’à 64 Kbit/s. La qualité est mesurée en échelle MOS (Mean Opinion Score) Voice Activity Detection(VAD) : capacité à détecter les silences Discontinuous Transmission (DTX) : arrêt de la transmission quand le VAD détecte un silence Comfort Noise Generation (CNG) : maintient ambiance sonore Score MOS Définition Exemple 4 à 5 Haute qualité Téléphone RNIS 3,5 à 4 Qualité commerciale Téléphone fixes classiques(G726 – 32 kbit/s ADPCM) 3 à 3,5 Qualité acceptable avec dégradation perceptible 2,5 à 3 Qualité militaire Moins de 2,5 Qualité synthétique Voix robotisée Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

9. Quelques codeurs audio G711 (approuvé en 1965) : codage jusqu’à 4 kHz loi A en Europe -> flux de données de 64 Kbit/s loi µ aux Etats-Unis et au Japon de 56 Kbit/s score MOS de 4,2 G722 (approuvé en 1998) : codage jusqu’à 7kHz débit de 48, 56 ou 64 Kbit/s adapté aux téléconférences G722.1 24 ou 32 Kbit/s, version propriétaire Ste Picturetel à 16 Kbit/s (Siren™ utilisée par Windows™ Messenger) G723.1 (approuvé en 1995) : 6,4 (score MOS de 3,9) ou 5,3 Kbit/s (score MOS de 3,7) intègre le VAD, le DTX et le CNG sélectionné par le Forum VoIP comme codeur par défaut en bas débit sous H323 G729 (approuvé en 1996) : très utilisée en VoIP sur Frame Relay intègre le VAD, le DTX et le CNG, débit de 8 Kbit/s score MOS de 4,0 Quelques codeurs vidéo(pour mémoire) H.261 (40 K à 2 Mbit/s) – H.263 (bas débit) – H.264 (visioconférence professionnelle à 192 ou 386 Kbit/s) Communication audio et video en mode paquet Tonalités DTMF (Dual-Tone Multi-Frequency) Données DMTF (clavier téléphonique) font partie du flux audio, échappent aux techniques de compression de la voix : H.323 utilise le canal de signalisation (message H.245), ou sur le canal média en RTP en H.323.4 (RFC 2833). Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

10. Contrôle Données Audio Video Contrôle Contrôle UDP TCP Internet Protocol (IP) • Protocoles utilisés dans H323 (« specification chapeau ») • H.323 : System Document • H.225 : Signalisation d'appel, empaquetage, enregistrement au garde-barrière, admission et état • H.245 : Contrôle (également utilisé dans H.324 et H.310) • T.120 : Contrôle des données et des conférences, • RTP : Real-time Transport Protocol (IETF) • RTCP : Real-time Transport Control Protocol (IETF) Protocole H323, généralités Mai 1995 : début des travaux sur H.323 Juin 1996 : décidé par l'ITU-T Janvier 1998 : approbation de la version 2(H.450, extension QSIG) Septembre 1999 : approbation de la version 3(CLIR, ou confidentialité) Novembre 2000 : approbation de la version 4(accélération des connexions, rappel automatique, transfert…) H.7xx H.26x H.225 H.245 T.120 RTCP GB RTP Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

11. Eléments d’un système H323 • H.323 inclut la spécification des : • terminaux de visioconférence • passerelles entre réseaux H.323 et d’autres réseaux audio et video (dont les réseaux de visioconférence H.320) • gatekeeper : serveurs de contrôle du réseau H.323 (enregistrements des terminaux, administration des appels …) • ponts de conférence : MCU (Multipoint Control Unit, traitant différents flux média) Protocole H323, structure • Protocoles utilisés • H.323 inclut les protocoles suivants : • RTP/RTCP décrits dans la norme RFC 1889 spécifiant les conditions d’un transport de données temps réel sur des réseaux IP; RTP rattrape les effets de la gigue et détecte les pertes de paquets; RFC1889 nécessite un travail de profilage avant utilisation. • recommandation UIT H.225.0 pour le profilage en application visioconférence (identificateurs des codeurs, traitement des redondance entre RTCP et H.245 et du RAS (Registration, Admission, Status) entre un terminal et un gatekeeper…) • recommandation UIT H.245 pour la négociation des codes Codec, la gestion des données DTMF et des flux média. Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

12. Cas simple d’un appel d’un terminal A vers un terminal B (H.323 version 1) • Etape 1 : initialisation de l’appel Adresses IP fixes et connues Appel par deux connexions TCP : • une pour les messages de contrôle d’appel, établie par l’appelant vers habituellement le port 1720 du terminal appelé (« canal de signalisation d’appel » ou « connexion Q.931 » permettant l’échange des messages définis en H.225.0, proches de Q.931) • une pour les messages de contrôle des flux média, sur un port spécifique alloué par l’appelé, servant au transport des messages H.245 (capacité audio et video respectives, définitions maître-esclave, ouverture des canaux logiques audio et vidéo (autant de sessions RTP), pour toute la durée de la communication) H323 pas à pas Message SETUP vers port 1720 Message ALERTING (sonnerie) Message CONNECT (décroché) La première connexion TCP sur port 1720 peut ensuite être fermée et ré-ouverte à nouveau à la fin de la session pour le traitement du « raccroché » (message RELEASE COMPLETE). Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

13. Etape 2 : négociation des capacités Utilisation de la seconde connexion TCP pour le contrôle des flux média et l’échange des capacités (norme H.245) L’appelant établit le canal de contrôle H.245 (canal logique 0) dès réception du message ALERTING, ou CALL PROCEEDING ou CONNECT qui fournit le N° de port à appeler sur le poste distant. • Après établissement du canal, le premier message envoyé/reçu est TerminalCapability avec : • Numéro de séquence, • Table des capacités en Codec, • Combinaison de Codec audio et vidéo supportés • Négociation maître/esclave (MCU, ou pont de conférence multipoint, dominant) H323 pas à pas Connexion de contrôle H.245 Terminal Capability set Terminal Capability set ack Terminal Capability set Terminal Capability set ack Les communications RTP et RTCP sont maintenant disponibles… Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

14. OpenLogicalChannel OpenLogicalChannel OpenLogicalChannel ack OpenLogicalChannel ack • Etape 3 : ouverture des canaux média • Ouverture des canaux voix et vidéo dans des canaux logiques unidirectionnels. • Message H.245 OpenLogicalChannel transporte le numéro identifiant le canal logique, paramètres d’identification des données (exemple : G.711), adresses et ports UDP où devront être envoyés les rapports de réception RTCP. • Si plusieurs canaux, vérification des combinaisons de Codec, qui peuvent être asymétriques. • Après acquittement, B est prêt à recevoir des données RTP de A, et inversement. • OpenLogicalChannel ack envoyé par B fournit l’adresse IP et le port UDP où A devra envoyer les données RTP, et le port UDP où A devra envoyer les rapports d’émission RTCP. H323 pas à pas Traitement des données DTMF Le plus souvent un message H.245 spécifique userInputIndication (UII) utilisant la qualité d’une connexion TCP, transportant tous les caractères numériques et les lettres « A », « B », « C », « D », « * » et « # ». Données étendues en H.323.2 avec informations sur le niveau en DB et la durée du signal. Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

15. Etape 4 : dialogue • Le flux média est envoyé dans des paquets RTP • Les rapports de réception RTCP permettent à chaque terminal de mesurer la qualité de service du réseau en indiquant la fraction de paquets perdus depuis le dernier rapport, le total des paquets perdus, une mesure de la gigue, le plus haut numéro de séquence RTP reçue. Les terminaux sont censés réagir à une diminution de la qualité en diminuant les débits ou en changeant de Codeur audio ou vidéo • La norme H.323 n’autorise qu’une paire RTP/RTCP par session; il peut y avoir 3 types principaux de sessions entre terminaux H.323 : audio, vidéo et données. H323 pas à pas Flux RTP A vers B audio RTCP Receiver Report audio RTCP Sender Report audio Flux RTP A vers B video RTCP Receiver Report video RTCP Sender Report video … Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

16. A B closeLogicalChannel LogicalChannelAck endSessionCommand releaseComplete releaseComplete • Etape 5 : fin de la communication • Le premier poste (exemple : B) qui raccroche envoi un message closeLogicalChannel pour chaque canal logique ouvert. Le poste A en vis-à-vis en accuse réception par un message LogicalChannelAck. • Après fermeture de ses canaux logiques, A envoie un message H.245 endSessionCommand, puis va attendre le même message de B, et enfin ferme le message de contrôle H.245 • Enfin A et B doivent envoyer un message H.225 releaseComplete si le canal de signalisation est encore ouvert, puis le fermer. L’appel est alors terminé. H323 pas à pas Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr

17. Appel vers un téléphone public à partir d’Internet via Gatekeeper et Gateway • Rôle d’un Gatekeeper : « registration » des utilisateurs pouvant être joints sur le réseau, admission des appels avec vérification des droits d’accès aux ressources, comptabilité des appels, détermination de l’adresse à utiliser pour atteindre un alias particulier • Responsabilité d’un Gatekeeper : routage des appels dans un réseau H.323 et implémentation de services comme le transfert d’appels, le service « ne pas déranger », le déport d’appel sur un répondeur… • L’ensemble des terminaux , serveurs de conférences, passerelles, contrôlés par un Gatekeeper sont considérés comme faisant partie d’une zone • L’appel est redirigé vers la passerelle, laquelle enverra ensuite directement les messages ALERTING et CONNECT au terminal, puis procédure standard H.323 entre terminal et passerelle. H323 pas à pas A B Téléphone IP Internet Gatekeeper Téléphone réseau public Gateway Protocole Terminal <-> Gatekeeper Enregistrement (Registration), admission (Admission) et contrôle de status (Status) ou « RAS » défini dans la norme H.225.0. Claude Zurbach – CNRS – Claude.Zurbach@lpta.in2p3.fr