Voix sur IP

André-Luc Beylot
Département Télécoms et Réseaux
ENSEEIHT
 Plan
n Introduction
n RTP/RTCP
n Les protocoles de signalisation :
u SIP
u H.323
u MGCP/Megaco
n Conclusion

2
 Introduction : Que pourrait-
être la voix sur IP ?
n Exemple :
u John, devant son ordinateur, appelle Mary
([email protected]), 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éphone
cellulaire et son téléphone fixe
u Marie répond depuis l’ordinateur de son bureau
u Durant l’appel, John décide d’ajouter Bob à la conversation
qui répond avec son téléphone cellulaire
F 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équence
video
3
 Introduction : Que pourrait-
être la voix sur IP ?
n Services et Protocoles mis en jeu dans le scénario
précédent :
u Protocoles de Transport supports de communications
F pour la voix
F pour la video en temps réel
F pour la video stockée
• Solution : RTP diffusion en direct - RTSP données stockées
u Protocoles de signalisation
F mise en place de connexion
F trouver les correspondants (pages blanches)
F multicast
F negotiations des formats des médias (audio ; audio et video)
F contrôle des passerelles entre Internet et RTC
• Nombreuses solutions : H323, SIP, MGCP
4
 Introduction : RTC
n Le RTC a de nombreux avantages :
u Une bonne qualité de voix
u Grande robustesse (système de signalisation : SS7)
u Très sûr
u Services efficaces (réseau intelligent, fax)

n Mais le RTC a atteint ses limites : introduction de

nouveaux services (de données) trop cher :
u le dernier km constitue un goulot d’étranglement
u 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)
5
 Introduction : Internet
n 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 important
F d’1 gigue trop importante (service isochrone)
u Solutions possibles : DiffServ, MPLS, IntServ

n Conclusion : dans un premier temps, la voix sur IP devra

coexister avec le RTC

6
Problèmes liés à la transmission
de 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é
7
 Transmission de la voix
n 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 temps
F de +, certains codeurs utilisent la technique “plus on en sait,
mieux on compresse”

u Politique de redondance :
F limiter l’impact des pertes de paquets
F méthode proactive. E.g. : à chaque paquet, on ajoute une copie
(codée avec une qualité moindre) du paquet précédent
F 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 !8
Problèmes liés à la transmission
de la voix
n Partie Fixe (suite) :
u Protocoles de Transport (RTP, UDP, IP) :
F ils ajoutent des délais en accolant les en-têtes
F 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éseau
u Solution : utiliser un buffer de réception
u 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 !)9
 RTP/RTCP
u 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 UDP
u RTP permet de numéroter pour reséquencer et de compenser
la gigue due au multiplexage statistique (< routers) :
F estampille : synchronisation
F numérotation (pas fait par UDP)
F type de données (e.g : PCM, H.263)
u RTP permet des sessions unicast ou multicast
u Une session RTP par flux (port UDP / adresse Multicast).
F Flux synchronisés par RTCP

10
 RTCP - RTP Control Protocol
n RTCP port # = RTP port # +1
n RTCP a pour but :
u distribuer des statistiques (Evaluation de la QoS) entre les
participants (émetteurs et récepteurs)
u Synchronisation entre les médias en comparant les
estampilles RTP (media relative time)
n RTP et RTCP permettent un contrôle de niveau applicatif
de le connexion téléphonique
n RTP/RTCP n’ont pas d’influence sur le réseau lui-même
n l’Internet n’est pas capable de garantir des délais/gigue/
pertes faibles : problème pour la voix
u RTP permet de compenser une gigue modérée et RTCP
permet d’effectuer des adaptations au niveau des terminaux
11
 SDP : Session
Description Protocol
 SDP : Session Description
Protocol
n RFC 2237

n Pas vraiment un protocole - les données sont véhiculées par

d’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)

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

16
 SIP Requêtes et Réponses
n Requêtes
u INVITE : mises en place de connexion
u ACK
u BYE
u CANCEL : arrêter la recherche d’un utilisateur
u REGISTER : pour s’enregistrer auprès d’un serveur
n Réponses
u Traitement en cours
u Succès
u Redirection
u Echec (du client, du serveur)

17
 Appel Téléphonique entre
utilisateurs Internet
Mary John
INVITE
[email protected]
c=IN IP4 192.190.132.20 RTP/AVP 0
m=audio 49170 RTP/AVP 0 Audio = Loi µ 192.190.132.31
192.190.132.20

port UDP où le flux

RTP est attendu

µ law
Port # 49170
200 OK
c=IN IP4 192.190.132.31
m=audio 12345 RTP/AVP 3

John peut recevoir

des données GSM
GSM
sur le port 12345

Port # 12345

ACK 18
 Entités SIP
n 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
localisation
u Enregistrement non permanent (timeout)
n Serveur de redirection:
u répond à des demandes de connexions par des réponses 3xx
u en donnant d’autres adresses ...

19
 Entités et adresses SIP
n 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 temporaire
u Tâches :
F doit trouver l’utilisateur en lui redirigeant les messages
F implante les règles de redirection (call forward on busy …)
F filtrage d’appel
n SIP addresses = URL
u pas une adresse de transport, le plus souvent @mail
u 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 20
 Conférence
n 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 adresse

multicast.

n Le passage d’une communication entre 2 utilisateurs à une

conférence entre n utilisateurs se fait en envoyant un
“INVITE” à une @ à tous les participants en utilisants le
même CallID
21
Protocole de
signalisation
H.323
 H.323
u 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
23
 Différentes phases de H.323
n Gatekeeper (contrôleur) : contrôle la session : traduction
d’adresse, contrôle d’admission/BP, gère une zone
n Gateway: passerelle H.323/RTC
n Initialisation: enregistrement auprès du GK
n 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 traiter
n Echange de données:
F configuration et ouverture de canaux logiques
F envoyer et recevoir des flux de données

n Re-négotiation: changer participants/ médias/ paramètres

n Fin:terminer l’appel/conférence ; supprimer un utilisateur référencé
24
 Composants et Canaux H.323
n Utilisateur – contrôleur GK (H.225.0)
u UDP
n Signalisation : H.225 (Q.931)
u Contrôle d’appel
u service supplémentaires
u 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 échanges
u Utilise TCP
n Canaux logiques : transporte flux audio, video (UDP)
25
1ère Phase : Initialisation de l’appel (H.225)

H.225: SETUP
Call Identifier : 45442345 IP address : 10.2.3.4
Email-ID of A : [email protected]
Source type : PC
Terminal A : John
Call Type : Point to Point Terminal B : Mark
Destination @ : [email protected]

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

H.225: CONNECT
Call Identifier : 45442345

Dedicated port # H.245 address : 10.2.3.4:8741

26
 1ère Phase : Initialisation (H.225)

n @ H.323v2
F E.164
F H.323-ID (chaîne de catactères)
F url-ID
F transport-ID (ex:10.2.3.4:1720)
F E-mail ID : [email protected]

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

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

H.245: TerminalCapabilitySet
Multiplex Capability
Capability Table : IP address : 10.2.3.4
H.261 Video
Terminal A : John G711 A law 64k Terminal B : Mark
G729

Term. Cap. Set

H.245 Control Channel H.245 Control Channel
TCP port # Term. Cap. Set Ack
TCP port # 8741
Term. Cap. Set

Term. Cap. Set Ack

H.245: TerminalCapabilitySet
Multiplex Capability
Capability Table :
H.261 Video
G711 A law 64k 28
3ème phase : Mise en place du Dialogue
H.245: OpenLogicalChannel
Logical Channel 1,
RTCP RR port 7771 IP address : 10.2.3.4
G711, A law 64k
Terminal A : John Session #, RTP payload type Terminal B : Mark
silence suppression

Open logical channel

H.245 Control Channel H.245 Control Channel
TCP port # TCP port # 8741
Open logical channel Ack

Open logical channel

Open logical channel Ack

H.245: OpenLogicalChannelAck
Logical Channel 1,
Mise en place de 2 canaux RTCP SR port 9345
RTP port 9344
unidirectionnels
29
 4ème phase : Dialogue
IP address : 10.2.3.4

Terminal A : John Terminal B : Mark

Audio Channel = Audio Channel =

logical channel 1 logical channel 1
RTP Flow from A to B
RTP : UDP RTP : UDP 9344
RTCP :UDP 7771 RTCP RR RTCP :UDP
RTCP :UDP RTCP :UDP 9345
RTCP SR

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

...
H.245 Control Channel
H.245 Control Channel
TCP port # 8741
TCP port #
Logical Channel 0

30
 Dernière Phase : Fin
n Sur le canal H.245, fermeture de tous les canaux de
données
u Initié par le premier qui raccroche
u CloseLogicalChannel et CloseLogicalChannel Ack

n Si le canal H.225 n’a pas été fermé, Release Complete

message est envoyé

31
 Appel RTC/Internet
n Gatekeepers (GK):
u gère une zone locale (contrôle des appels entrants/sortants)
u enregistre les utilisateurs locaux
u 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 GK
u 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
32
1ère étape : Localisation du GK et
Enregistrement
n Localisation GK :
u Configuration Manuelle
u Configuration Dynamique (roaming users)
n Enregistement :
u Utilisateur vers GK : RRQ (Registration ReQuest)
F contient les ports à utiliser pour le canal de signalisation de
l’appel (H.245)
u GK vers Utilisateur : RCF (Registration Confirm)
F GK renvoie:
• un identifiant unique d’utilisateur (à utiliser dans les msg RAS)
• alias

33
 2ème phase : Requête
d’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 123456789
u CallId
u 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

34
 3ème phase : Sig. d’appel

2ème
phase

ARQ GK GW
(number=+33 123456789)
GW peut changer le numéro
RAS Channel (e.g. enlever +33 s’il est localisé
ACF en France)
(Q.931=10.1.2.3:1720)

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

GW demande la
ARQ permission au GK
Q.931 Channel
ACF

↓
ALERTING

CONNECT 35
 Fin d’appel

GK GW

EndSessionCommand (H.245 level)

EndSessionComplete (H.245 level)

ReleaseComplete (Q.931 level)

DRQ (disengage request)

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

DCF (disengage confirm) 36

 Numérotation H.323
n 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’échelle
n Besoin d’une procédure automatique. Plusieurs solutions :
u 1 préfixe spécial par pays
u 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 ... 37
 H.323 versus SIP
n 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’un
backbone IP multicast pour le transport des données et de la
signalisation (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 le
terminal doit être prêt à recevoir des données d’annonce de
capacités

38
MGCP/Megaco
 Analyse de H.323
Gatekeeper Gatekeeper
H.225 - multiplexing

RAS - registration, admissions, status

Call Signaling

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

GW GW
RTP - audio data
Call

n S’occupe uniquement de la mise en place des connexions

n Autres fonctionnalités implantées dans les GW
u autorisations, paiements
u collecte de la sig
n Le GK ne pilote pas vraiment la GW
40
 D’H.323 à MGCP/Megaco
n 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ès

u Passerelle très impliquée dans la mise en place des cnx
u Implantation de services cher

n Idée de base MGCP/MEGACO: Séparer physiquement le

contrôle d’appel du contrôle des média et des “tuyaux”

n La GW a suffisamment à faire avec les conversions

MIC/RTP 41
 Media gateway control et sig.
d’appel
ISUP over SIGTRAN

SIP-T, ISUP in H.323

SG MGC MGC SG

SIP
SIP
User Agent

PSTN H.323 call PSTN

signaling Gateway
Gateway
control
Internet control
protocol
protocol

H.323
Endpoint
MG
MG

SS7 Call signaling

Media gateway control signaling
SS7
Network
Media flows Network
42
SG: Signaling Gateway, MG: Media Gateway, MGC: Media Gateway Controller
MGCP
Media Gateway Control Protocol
(MGCP)
n RFC 2705 (Avril 2000)

n MGCP utilisé pour contrôler des passerelles téléphoniques (de cœur ou

résidentielles) par des éléments de contrôle d’appel externes appelés
media 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=0
F c=IN IP4 128.16.59.1
F m=audio 3456 RTP/AVP 0 96
F a=rtpmap:96 G726/4 44
 Architecture MGCP
n 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 liaisons

ATM (…)

45
 Architecture MGCP
n Trunk Gateway (TGW):

u Interconnexion Internet-RTC : convertit les formats

TDM/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)

46
 MGCP Architecture
n Call Agent (CA) ou Media Gateway Controller:
u Contrôle RGW et TGW
u 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 SS7
u Ils peuvent utiliser SIP qui peut encapsuler des données SS7
u A terme utiliser les solutions SS7 over IP (STCP) issues du groupe
de travail IETF Sigtran.

47
 Configurations MGCP (1/3)

PSTN signaling
protocols Call
agent
SS7/ISUP SS7/ISUP

STP STP
MGCP/UDP
IP Network
CO TGW TGW CO

RTP
TGW : Trunk Gateway
CO : Central Office
STP : Switching Transfer Point 48
Configurations MGCP (2/3)

Call
SS7/ISUP agent

STP MGCP/UDP
IP Network
CO TGW RGW

RTP

49
Configurations MGCP (3/3)
Le CA met en œuvre de nombreux
protocoles (SS7,H.323 ou SIP), utilise
MGCP pour contrôler les GWs
Call
SS7/ISUP agent

H.323
STP MGCP/UDP or SIP RTP
IP Network
CO TGW RGW

RGW : Residential Gateway

50
Communication MGCP/RTC

L’agent d’appel
peut maintenant
chercher 1 TGW
pour cet appel

(Initial Address Message)

(Address Complete Message)

(Answer Message)

51
Communication MGCP/SIP

52
 MGCP vs. SIP
n 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 liaisons
Internet/RTC
53
 Conclusion
n Pour remplacer le RTC, VoIP a besoin d’un vrai protocole de
signalisation efficace
u Cela prend beaucoup de temps ⇒ la coexistence RTC/VoIP va
durer encore longtemps
u Besoin d’une proposition globale
F A l’heure actuelle, bataille entre SIP et H.323
F Groupe de travail MEGACO IETF (commun ITU-T/IETF/ETSI)
essaye de proposer un rapprochement MGCP - H.323 ; inclus
dans H.323 (H.248) modélisation des communications
multimédia.
n Les protocoles de signalisation ont besoin d’une bonne
disponibilité (pour le RTC 99.999 %), délai raisonnable +
transfert de la voix contraignant
F solutions DiffServ/MPLS
54