Voix sur IP

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

ENSEEIHT

2

Plann Introductionn RTP/RTCPn Les protocoles de signalisation :

u SIPu H.323u MGCP/Megaco

n Conclusion

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 atteint 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

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

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 !

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

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

SDP : SessionDescription Protocol

13

SDP : Session DescriptionProtocol

n RFC 2237

n Pas vraiment un protocole - les données sont véhiculées pard’autres protocoles

n Utilisé SIP, RTSP, H.332, MGCP

n Décrit les sessions multimédia :u codeurs audio et vidéo utilisés (payload type)u information sur la session (nom, description courte)u adresse multicast à utiliser (en cas de conférence multi-

parties)

Protocoles designalisation:

SIP

15

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

16

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;

17

SIP Requêtes et Réponsesn Requêtes

u INVITE : mises en place de connexionu ACKu BYEu CANCEL : arrêter la recherche d’un utilisateuru REGISTER : pour s’enregistrer auprès d’un serveur

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

18

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

19

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 ...

20

Entités et adresses SIPn Agent d’appel (Call Agent) :

u proxy (doit se trouver sur le chemin de chaque appel)u pas situé sur la machine de l’usager

• qui peut être éteinte /utiliser une adresse IP temporaireu Tâches :

F doit trouver l’utilisateur en lui redirigeant les messagesF implante les règles de redirection (call forward on busy …)F filtrage d’appel

n SIP addresses = URLu pas une adresse de transport, le plus souvent @mailu Localisation en 2 temps :

F Trouver le serveur SIP à partir de SIP URL, en utilisant le DNS(en retrouvant des enregistrements ‘sip.udp’ or ‘sip.tcp’)

F Envoyer un INVITE au Serveur qui redirige l’appel

21

Conférencen SIP fait pour utiliser IP multicast : flux de données et de

sig peuvent être envoyés en utilisant le multicast

n URL Destination = nom de la conférence

n Réponses aux requêtes SIP envoyées à la même adressemulticast.

n Le passage d’une communication entre 2 utilisateurs à uneconférence entre n utilisateurs se fait en envoyant un“INVITE” à une @ à tous les participants en utilisants lemême CallID

Protocole designalisation

H.323

23

H.323u H.323 : standard ITU-T.

• Début des travaux sur H.323v1 Mai 1995• Version 2 - Février 1998• Version 3 - utilisation possible d’UDP

u H.323 : vidéo-conférence sur des réseaux de paquets (IP,ATM, IPX)

u Video-conférence existe déjà sur l’Internet avec le Mbone :• Media transportés par RTP/RTCP• arbre MC construit avec DVMRP

u Solution fruste :• DVMRP ne permet pas le passage à l’échelle• on ne peut pas négocier le codec• pas de possibilité de contacter un utilisateur du RTC• Pas de service de “pages blanches”

u H.323 a pour objectif de résoudre ces problèmes

24

Différentes phases de H.323n Gatekeeper (contrôleur) : contrôle la session : traduction

d’adresse, contrôle d’admission/BP, gère une zonen Gateway: passerelle H.323/RTCn Initialisation: enregistrement auprès du GKn GK admission: obtenir l’autorisation - GK résout les @n Signalisation d’appel:

F initialisation et mise en place/rejet de la demande (cnx sig)n Négotiation/configuration:

F échange du type de données que les entités peuvent traitern Echange de données:

F configuration et ouverture de canaux logiquesF envoyer et recevoir des flux de données

n Re-négotiation: changer participants/ médias/ paramètresn Fin:terminer l’appel/conférence ; supprimer un utilisateur référencé

25

Composants et Canaux H.323n Utilisateur – contrôleur GK (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)

26

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 : JohnTerminal 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 #

27

1ère Phase : Initialisation (H.225)

n @ H.323v2F E.164F H.323-ID (chaîne de catactères)F url-IDF transport-ID (ex:10.2.3.4:1720)F E-mail ID : Mark@domain2.com

n Identifiants :F H.225.0 :

• Référence de l’appel (unique entre A et B)F H.323 :

• Identifiant d’appel• Identifiant de conférence (CID) : unique pour tous les participants

28

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

29

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

30

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... ......

31

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é

32

Appel RTC/Internetn Gatekeepers (GK):

u gère une zone locale (contrôle des appels entrants/sortants)u enregistre les utilisateurs locauxu joue le rôle d’agent d’appel (redirection si appelé occupé ...)

F Communication entre utilisateur et GK défini dans RAS(Registration, administration and status) inclus dans H.225.0 ⇒Canal RAS

n Gateways (GW):u gérés par les GKu interface entre Internet et RTC

F accès RNIS :• GW envoie directement les messages Q.931 (SETUP, ALERTING)

F liaisons analogiques :• numérotation DTMF• envoie un message “ALERTING” quand il détecte une sonnerie

33

1ère étape : Localisation du GK etEnregistrement

n Localisation GK :u Configuration Manuelleu Configuration Dynamique (roaming users)

n Enregistement :u Utilisateur vers GK : RRQ (Registration ReQuest)

F contient les ports à utiliser pour le canal de signalisation del’appel (H.245)

u GK vers Utilisateur : RCF (Registration Confirm)F GK renvoie:

• un identifiant unique d’utilisateur (à utiliser dans les msg RAS)• alias

34

2ème phase : Requêted’autorisation d’appel

n Utilisateur vers GK : ARQ (Admission ReQuest - msg RAS)u type d’appel (e.g. point to point)u modèle d’appel (direct ou routé = de zone en zone - GK to GK)u destination E.g. numéro E.164 +33 123456789u CallIdu Estimation de la bande passante requise

n GK vers utilisateur : ACF (Admission Confirm)u Adresse IP + # port pour le canal Q.931. Pour les num. E.164,

adresse d’une GW (ou d’un GK pour le modèle “routé”)u Bande Passante autorisée

35

GW demande la permission au GK

3ème phase : Sig. d’appel

GK GWARQ (number=+33 123456789)

ACF (Q.931=10.1.2.3:1720)

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

ARQ

ACF

ALERTING

CONNECT

RAS Channel

Q.931 Channel

↓

2ème phase

GW peut changer le numéro(e.g. enlever +33 s’il est localisé

en France)

36

Fin d’appel

GK GW

EndSessionCommand (H.245 level)

EndSessionComplete (H.245 level)

ReleaseComplete (Q.931 level)

DRQ (disengage request)

DRQDCF

DCF (disengage confirm)

Confirmation envoyéeà la GW et à l’utilisateur

37

Numérotation H.323n Problème : comment atteindre un téléphone IP à partir

d’un téléphone du RTC ?u Appeler une passerelle interactive qui demande une adresse

IP ou un e-mail => Problème de passage à l’échellen Besoin d’une procédure automatique. Plusieurs solutions :

u 1 préfixe spécial par paysu 1 code spécial (comme les numéros 800)u 1 code de pays pour les téléphones IP

n 1ère solution pose un vrai pb :u atteindre un téléphone IP dans un autre pays conduira à

router l’appel via le RTC jusqu’au pays considéré !n Objectif rentrer le plus tôt possible dans l’Internet.n Pas de solution largement acceptée pour l’instant ...

38

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

MGCP/Megaco

40

H.225 - multiplexing

Analyse de H.323

RAS - registration, admissions, status

Call Signaling

H.245 - channels, capabilities/preferences, flow control

RTP - audio data

Gatekeeper Gatekeeper

GW GW

Call

n S’occupe uniquement de la mise en place des connexionsn Autres fonctionnalités implantées dans les GW

u autorisations, paiementsu collecte de la sig

n Le GK ne pilote pas vraiment la GW

41

D’H.323 à MGCP/Megacon Inefficace pour les grandes passerelles d’opérateurs

u Nombreuses Connexions (H.225, H.245, RTP)u Traitements Longs (message en ASN.1)

n Trop complexe pour des petites passerelles d’accèsu Passerelle très impliquée dans la mise en place des cnxu Implantation de services cher

n Idée de base MGCP/MEGACO: Séparer physiquement lecontrôle d’appel du contrôle des média et des “tuyaux”

n La GW a suffisamment à faire avec les conversionsMIC/RTP

42

Media gateway control et sig.d’appel

SG

MG

MGC SG

MG

MGC

SIPUser Agent

H.323Endpoint

PSTN PSTN

Call signaling

Media gateway control signaling

Media flows

SIP-T, ISUP in H.323

SIP

H.323 callsignalingGateway

controlprotocol

Gatewaycontrolprotocol

ISUP over SIGTRAN

SS7Network

SS7Network

Internet

SG: Signaling Gateway, MG: Media Gateway, MGC: Media Gateway Controller

MGCP

44

Media Gateway Control Protocol(MGCP)

n RFC 2705 (Avril 2000)

n MGCP utilisé pour contrôler des passerelles téléphoniques (de cœur ourésidentielles) par des éléments de contrôle d’appel externes appelésmedia gateway controllers ou call agents.

n MGCP au-dessus d’UDP : passage à l’échelle, delai

n MGCP utilise SDP pour décrire les connexions:F v=0F c=IN IP4 128.16.59.1F m=audio 3456 RTP/AVP 0 96F a=rtpmap:96 G726/4

45

Architecture MGCPn Residential Gateways (RGW):

u Connexions des usagers téléphoniques IP

u Pas de modification du téléphone

u RGW détecte les événements et les notifie à l’agent d’appel(MGCP)

u RGW supporte RTP

u RGW connecté à l’Internet via le RTC, l’ADSL ou des liaisonsATM (…)

46

Architecture MGCPn Trunk Gateway (TGW):

u Interconnexion Internet-RTC : convertit les formatsTDM/RTP - RTP/TDM

u Supporte MGCP (contrôlé par un Call Agent)

u Doit aussi supporter (côté RTC):F Signalisation dans la bande (liaisons analogiques)

47

MGCP Architecturen Call Agent (CA) ou Media Gateway Controller:

u Contrôle RGW et TGWu Supporte la signalisation SS7 (TGW est simple: s’occupe de la

conversion TDM/RTP)u 1 CA contrôle plusieurs GWs

n Pas de protocole normalisé pour les échanges entre CA :u Pas critique dans un premier temps, les CA peuvent interopérer via

le SS7u Ils peuvent utiliser SIP qui peut encapsuler des données SS7u A terme utiliser les solutions SS7 over IP (STCP) issues du groupe

de travail IETF Sigtran.

48

Configurations MGCP (1/3)

CO

IP Network

STP

TGW TGW

SS7/ISUP

MGCP/UDP

RTP

CO

STP

SS7/ISUP

Call agent

PSTN signalingprotocols

TGW : Trunk GatewayCO : Central Office STP : Switching Transfer Point

49

Configurations MGCP (2/3)

CO

IP Network

STP

Call agent

TGW RGW

SS7/ISUP

MGCP/UDP

RTP

50

Configurations MGCP (3/3)

CO

IP Network

STP

Call agent

TGW RGW

SS7/ISUP

MGCP/UDP

Le CA met en œuvre de nombreuxprotocoles (SS7,H.323 ou SIP), utiliseMGCP pour contrôler les GWs

H.323 or SIP RTP

RGW : Residential Gateway

51

Communication MGCP/RTC

(Initial Address Message)

(Address Complete Message)

(Answer Message)

L’agent d’appelpeut maintenantchercher 1 TGW

pour cet appel

52

Communication MGCP/SIP

53

MGCP vs. SIPn Ne pourrait-on pas utiliser uniquement H.323?

F Etablissement des appels très long.

n Ou SIP ?F SIP protocole “peer to peer” qui ne convient pas à un contrôle

des gateways

n MGCP doit-il remplacer H.323 ou SIP?F Apparemment non. SIP et H.323 offrent un grand nombre de

services non couverts par MGCP (conférences multimedia,règles de redirection)

F SIP et H.323 permet la mise en œuvre de services ‘intra-Internet’ alors que MGCP se concentre sur les liaisonsInternet/RTC

54

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 (commun ITU-T/IETF/ETSI)

essaye de proposer un rapprochement MGCP - H.323 ; inclusdans H.323 (H.248) modélisation des communicationsmultimédia.

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