Voix sur IP

Voix sur IP
André-Luc Beylot
Département Télécoms et Réseaux
ENSEEIHT
Plan
n
n
n
Introduction
RTP/RTCP
Les protocoles de signalisation :
u
u
u
n
SIP
H.323
MGCP/Megaco
Conclusion
2
Introduction : Que pourraitêtre la voix sur IP ?
n
Exemple :
u
u
John, devant son ordinateur, appelle Mary
([email protected]), en demandant les options audio et video.
L’appel atteint l’agent d’appel de Mary
F
u
u
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
F
u
L’agent d’appel “sonne” sur l’ordinateur de Mary, son téléphone
cellulaire et son téléphone fixe
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
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
F
F
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
u
Protocoles de signalisation
F
F
F
F
F
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
Introduction : RTC
n
Le RTC a de nombreux avantages :
u
u
u
u
n
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 :
u
u
u
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
n
n
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 :
F
F
u
n
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
Problèmes liés à la transmission
de la voix
n
Délai et gigue dans le RTC :
u
u
n
Gigue négligeable (Commutation de Circuits)
Délai ~ Propagation. Faible sauf satellite (acoustic echo
problem)
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
F
F
u
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 :
F
F
F
F
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
Problèmes liés à la transmission
de la voix
n
Partie Fixe (suite) :
u
Protocoles de Transport (RTP, UDP, IP) :
F
F
n
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) :
u
u
u
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.
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
u
u
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) :
F
F
F
u
u
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).
F
Flux synchronisés par RTCP
10
RTCP - RTP Control Protocol
n
n
RTCP port # = RTP port # +1
RTCP a pour but :
u
u
n
n
n
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
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
n
RFC 2237
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
u
u
codeurs audio et vidéo utilisés (payload type)
information sur la session (nom, description courte)
adresse multicast à utiliser (en cas de conférence multiparties)
13
Protocoles de
signalisation:
SIP
Introduction
n
n
SIP (RFC 2543) issu du groupe de travail MMUSIC
(Multiparty Multimedia Session Control) de l’IETF
MMUSIC :
u
u
SIP : Session Initiation Protocol
SDP : Session Description Protocol
F
u
n
(type de format échangé, adresses, nom de la session …)
RTSP : Real-time Streaming Protocol
Objectifs de SIP
u
u
u
u
u
Localisation
Etablissement d’appel
(Re)-Négotiation des paramètres de session
Gestion des participants de l’appel
Fin et transferts d’appels
15
Transactions et messages SIP
n
Entités SIP communiquent via des ‘transactions’ :
u
u
n
SIP fonctionne sur TCP ou UDP
u
n
1 transaction = 1 requête + 1 ou plusieurs réponses
Transactions numérotées, mode client/serveur
Rem : les flux sont eux véhiculés par RTP/RTCP sur UDP
2 types de messages : Requêtes et Réponses
u
En-tête :
F
F
F
F
F
Call-ID. E.g. [email protected]
Cseq : numéro de séquence
From : e.g. From: ‘Mydisplayname’ <sip:[email protected]>
To : e.g. To: ‘Helpdesk’ <sip:[email protected]>;
Via : e.g. Via : [email protected];
16
SIP Requêtes et Réponses
n
Requêtes
u
u
u
u
u
n
INVITE : mises en place de connexion
ACK
BYE
CANCEL : arrêter la recherche d’un utilisateur
REGISTER : pour s’enregistrer auprès d’un serveur
Réponses
u
u
u
u
Traitement en cours
Succès
Redirection
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
m=audio 49170 RTP/AVP 0
192.190.132.20
RTP/AVP 0
Audio = Loi µ
192.190.132.31
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
GSM
John peut recevoir
des données GSM
sur le port 12345
Port # 12345
ACK
18
Entités SIP
n
Annuaire :
u
u
u
u
u
n
garde la trace de la correspondance = SIP @ / IP @
utilise la requête ‘Register’
Découverte de l’annuaire : Groupe multicast dédié :
sip.mcast.net:224.0.1.75 (TTL=1)
Communication possible en unicast si on connaît sa
localisation
Enregistrement non permanent (timeout)
Serveur de redirection:
u
u
répond à des demandes de connexions par des réponses 3xx
en donnant d’autres adresses ...
19
Entités et adresses SIP
n
Agent d’appel (Call Agent) :
u
u
proxy (doit se trouver sur le chemin de chaque appel)
pas situé sur la machine de l’usager
• qui peut être éteinte /utiliser une adresse IP temporaire
u
Tâches :
F
F
F
n
doit trouver l’utilisateur en lui redirigeant les messages
implante les règles de redirection (call forward on busy …)
filtrage d’appel
SIP addresses = URL
u
u
pas une adresse de transport, le plus souvent @mail
Localisation en 2 temps :
F
F
Trouver le serveur SIP à partir de SIP URL, en utilisant le DNS
(en retrouvant des enregistrements ‘sip.udp’ or ‘sip.tcp’)
20
Envoyer un INVITE au Serveur qui redirige l’appel
Conférence
n
n
n
n
SIP fait pour utiliser IP multicast : flux de données et de
sig peuvent être envoyés en utilisant le multicast
URL Destination = nom de la conférence
Réponses aux requêtes SIP envoyées à la même adresse
multicast.
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
u
H.323 : vidéo-conférence sur des réseaux de paquets (IP,
ATM, IPX)
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 :
•
•
•
•
u
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”
H.323 a pour objectif de résoudre ces problèmes
23
Différentes phases de H.323
n
n
n
n
n
n
n
Gatekeeper (contrôleur) : contrôle la session : traduction
d’adresse, contrôle d’admission/BP, gère une zone
Gateway: passerelle H.323/RTC
Initialisation: enregistrement auprès du GK
GK admission: obtenir l’autorisation - GK résout les @
Signalisation d’appel:
F
initialisation et mise en place/rejet de la demande (cnx sig)
F
échange du type de données que les entités peuvent traiter
Négotiation/configuration:
Echange de données:
configuration et ouverture de canaux logiques
F envoyer et recevoir des flux de données
Re-négotiation: changer participants/ médias/ paramètres
Fin:terminer l’appel/conférence ; supprimer un utilisateur référencé
F
n
n
24
Composants et Canaux H.323
n
Utilisateur – contrôleur GK (H.225.0)
u
n
Signalisation : H.225 (Q.931)
u
u
u
n
Contrôle d’appel
service supplémentaires
TCP; depuis la v3: éventuellement UDP
contrôle (H.245):
u
u
u
u
n
UDP
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)
25
1ère Phase : Initialisation de l’appel (H.225)
Terminal A : John
Call Signal Channel
(Q.931 Channel)
TCP port # 1720
H.225: SETUP
Call Identifier : 45442345
Email-ID of A : [email protected]
Source type : PC
Call Type : Point to Point
Destination @ : [email protected]
IP address : 10.2.3.4
Terminal B : Mark
Setup
Alerting
Connect
Call Signal Channel
(Q.931 Channel)
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
F
F
F
F
n
E.164
H.323-ID (chaîne de catactères)
url-ID
transport-ID (ex:10.2.3.4:1720)
E-mail ID : [email protected]
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)
Terminal A : John
H.245: TerminalCapabilitySet
Multiplex Capability
Capability Table :
H.261 Video
G711 A law 64k
G729
IP address : 10.2.3.4
Terminal B : Mark
Term. Cap. Set
H.245 Control Channel
TCP port #
Term. Cap. Set Ack
H.245 Control Channel
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
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 : 10.2.3.4
Terminal B : Mark
Open logical channel
H.245 Control Channel
TCP port #
Open logical channel Ack
H.245 Control Channel
TCP port # 8741
Open logical channel
Open logical channel Ack
Mise en place de 2 canaux
unidirectionnels
H.245: OpenLogicalChannelAck
Logical Channel 1,
RTCP SR port 9345
RTP port 9344
29
4ème phase : Dialogue
IP address : 10.2.3.4
Terminal A : John
Terminal B : Mark
Audio Channel =
logical channel 1
Audio Channel =
logical channel 1
RTP Flow from A to B
RTP : UDP
RTCP :UDP 7771
RTCP :UDP
RTCP RR
RTP : UDP 9344
RTCP :UDP
RTCP :UDP 9345
RTCP SR
...
H.245 Control Channel
TCP port #
RTP Flow from B to A
...
...
H.245 Control Channel
TCP port # 8741
Logical Channel 0
30
Dernière Phase : Fin
n
Sur le canal H.245, fermeture de tous les canaux de
données
u
u
n
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é
31
Appel RTC/Internet
n
Gatekeepers (GK):
u
u
u
gère une zone locale (contrôle des appels entrants/sortants)
enregistre les utilisateurs locaux
joue le rôle d’agent d’appel (redirection si appelé occupé ...)
F
n
Communication entre utilisateur et GK défini dans RAS
(Registration, administration and status) inclus dans H.225.0 ⇒
Canal RAS
Gateways (GW):
u
u
gérés par les GK
interface entre Internet et RTC
F
accès RNIS :
F
liaisons analogiques :
• GW envoie directement les messages Q.931 (SETUP, ALERTING)
• 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
u
n
Configuration Manuelle
Configuration Dynamique (roaming users)
Enregistement :
u
Utilisateur vers GK : RRQ (Registration ReQuest)
F
u
contient les ports à utiliser pour le canal de signalisation de
l’appel (H.245)
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
u
u
u
u
n
type d’appel (e.g. point to point)
modèle d’appel (direct ou routé = de zone en zone - GK to GK)
destination E.g. numéro E.164 +33 123456789
CallId
Estimation de la bande passante requise
GK vers utilisateur : ACF (Admission Confirm)
u
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é”)
Bande Passante autorisée
34
3ème phase : Sig. d’appel
2ème
phase
GK
ARQ
(number=+33 123456789)
GW
GW peut changer le numéro
(e.g. enlever +33 s’il est localisé
en France)
RAS Channel
ACF
(Q.931=10.1.2.3:1720)
SETUP (number=+33 1 93 26 00 00)
ARQ
Q.931 Channel
GW demande la
permission au GK
ACF
↓
ALERTING
CONNECT
35
Fin d’appel
GK
GW
EndSessionCommand (H.245 level)
EndSessionComplete (H.245 level)
ReleaseComplete (Q.931 level)
DRQ (disengage request)
DRQ
DCF (disengage confirm)
Confirmation envoyée
à DCF
la GW et à l’utilisateur
36
Numérotation H.323
n
Problème : comment atteindre un téléphone IP à partir
d’un téléphone du RTC ?
u
n
Besoin d’une procédure automatique. Plusieurs solutions :
u
u
u
n
n
1 préfixe spécial par pays
1 code spécial (comme les numéros 800)
1 code de pays pour les téléphones IP
1ère solution pose un vrai pb :
u
n
Appeler une passerelle interactive qui demande une adresse
IP ou un e-mail => Problème de passage à l’échelle
atteindre un téléphone IP dans un autre pays conduira à
router l’appel via le RTC jusqu’au pays considéré !
Objectif rentrer le plus tôt possible dans l’Internet.
Pas de solution largement acceptée pour l’instant ...
37
H.323 versus SIP
n
Avantages de SIP :
u
u
n
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 :
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
Call
n
n
RTP - audio data
S’occupe uniquement de la mise en place des connexions
Autres fonctionnalités implantées dans les GW
u
u
n
GW
autorisations, paiements
collecte de la sig
Le GK ne pilote pas vraiment la GW
40
D’H.323 à MGCP/Megaco
n
Inefficace pour les grandes passerelles d’opérateurs
u
u
n
Trop complexe pour des petites passerelles d’accès
u
u
n
n
Nombreuses Connexions (H.225, H.245, RTP)
Traitements Longs (message en ASN.1)
Passerelle très impliquée dans la mise en place des cnx
Implantation de services cher
Idée de base MGCP/MEGACO: Séparer physiquement le
contrôle d’appel du contrôle des média et des “tuyaux”
La GW a suffisamment à faire avec les conversions
MIC/RTP
41
Media gateway control et sig.
d’appel
ISUP over SIGTRAN
SG
SIP-T, ISUP in H.323
MGC
SG
MGC
SIP
SIP
User Agent
H.323 call
signaling
PSTN
Gateway
control
protocol
PSTN
Gateway
control
protocol
Internet
H.323
Endpoint
MG
MG
SS7
Network
Call signaling
Media gateway control signaling
Media flows
SG: Signaling Gateway, MG: Media Gateway, MGC: Media Gateway Controller
SS7
Network
42
MGCP
Media Gateway Control Protocol
(MGCP)
n
n
RFC 2705 (Avril 2000)
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
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
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
SS7/ISUP
STP
Call
agent
SS7/ISUP
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)
SS7/ISUP
STP
Call
agent
MGCP/UDP
IP Network
CO
RGW
TGW
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
SS7/ISUP
Call
agent
H.323
MGCP/UDP or SIP
STP
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
n
Ou SIP ?
F
n
Etablissement des appels très long.
SIP protocole “peer to peer” qui ne convient pas à un contrôle
des gateways
MGCP doit-il remplacer H.323 ou SIP?
F
F
Apparemment non. SIP et H.323 offrent un grand nombre de
services non couverts par MGCP (conférences multimedia,
règles de redirection)
SIP et H.323 permet la mise en œuvre de services ‘intraInternet’ 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
u
Cela prend beaucoup de temps ⇒ la coexistence RTC/VoIP va
durer encore longtemps
Besoin d’une proposition globale
F
F
n
A l’heure actuelle, bataille entre SIP et H.323
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.
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