ToIP ( Telephony over IP ) - UV UTBM J. Millet

ToIP
( Telephony over IP )
On sait que pour faire un réseau téléphonique on a besoin des fonctions
- de transmission
- de commutation
- de signalisation ( gestion des communications : établissement, rupture, services associés )
Transmission et commutation sont celles du réseau IP. Il reste à définir le contrôle de la communication:
La signalisation est l’élément important, c’est ce qui donne une installation de téléphonie sur IP ToIP.
Elle est mise en œuvre au moins par 2 éléments :
Passerelle
ou
Gateway
Gatekeeper
ou
Serveur de
traitement d'appel
( Call Processing Server )
On y trouve:
- des interfaces avec le réseau IP ( support des protocoles de routage )
- des interfaces avec les réseaux téléphoniques
( RNIS BRI et PRI, LR analogiques, signalisation SS7 …)
- des moyens de conversion du trafic voix isochrone en paquets :
* G.711 : non compressé - utilisation de 64 kbit/s
* G.723 : compression à 5,3 et 6,3 kbit/s
* G.729 : compression à 8 et 13 kbps
* G.728 : compression à 16 kbps
...
- des éléments de détection et génération des signaux multi-fréquences
- des moyens de suppression d’écho : ITU G.165
C’est un serveur centralisé qui assure:
- Conversion d’adressage : E.164 @IP (plan d’adressage privé)
- Gestion des profils utilisateurs
- Gestion des appels:
autorisation, connexion, maintien, transfert, déconnexion, retour,...
identification de l’appelant ...
- Gestion des configurations, du plan de numérotation ( portabilité du n°
interne, LDAP… )
- Fonctionnement d’éléments de sécurisation (tolérance de panne … )
- Génération des informations d’administration
Ces fonctions sont organisées de manières différentes selon les protocoles de signalisation utilisée:
- H.323 : le principal standard
vidéo, voix, données, signalisation, 30 secondes pour établir un appel ... Complexe
- H.323 v2 : actuellement prédominant
moins de paquets, démarrage plus rapide, mais :
ajout de H.450 ( Téléservices ) H.235 (Sécurité et chiffrement)
- MGCP ( Media Control Gateway Protocol ) :
RFC 2705, support de la voix
- SIP ( Session Initiation Protocol ) :
RFC 2543, support de la voix;
- H.248 / Megaco :
RFC 2885, nouveau, peu testé, mais compétitif
- XMPP ( Extensible Messaging and Presence Protocol ):
Google Talk
- Protocoles propriétaires:
Skype
==> Problèmes d’interopérabilité
On va s’intéresser aux 2 principaux protocoles : H323 et SIP.
1
ToIP

I) H323
Origine de H323
H323 est un standard défini par l’UIT qui spécifie les composants, protocoles et procédures pour des
communications multimédia ( audio, vidéo et échange de données en temps réel ) sur des réseaux à commutation
de paquets. Il est soutenu par Microsoft.
En fait H323 regroupe différents protocoles qui doivent agir ensemble. On a tendance à appeler H323
des communications où seule une partie de H323 intervient ( Netmeeting en liaison directe ).
Composants de H323
Terminal H323 : PC ou système intégrant la pile protocolaire H323.
Gateway : Relie 2 réseaux différents, l’un H323, l’autre non ( exemple : réseau IP et RTC ).
=> Traduction des protocoles d’établissement et rupture d’appel, conversions de formats…
Gatekeeper ( Portier ) : Elément le plus important de H323 :
Il assure traduction d’adresse, gestion des profils utilisateurs, gestion des appels ( autorisation,
connexion,…), gestion du plan de numérotation ( annuaire LDAP )
Traduction d’adresse:
Utilisation d’alias en H323 ou d’un numéro de téléphone E.164 du RTC ou RNIS : Le gatekeeper
doit traduire l’alias ou le numéro de téléphone E.164 en adresse réseau du terminal destination
( ex: adr IP et numéro de port TCP ) .
MCU (Multipoint Control Unit ) : Tous les terminaux d’une conférence se connectent au MCU.
Il comprend le MC ( Multipoint Controller ) et des MP ( Multipoint
Processor ). Le MC négocie les codecs à utiliser, le MP mixe les flux
Un MC peut être dans un terminal, Gatekeeper ou Gateway.
Remarque: Souvent, une machine regroupe ces différentes fonctions.
2
ToIP

Fonctionnement de H323
H323 repose sur un ensemble de protocoles :
- H.225 : Canal de signalisation pour envoyer des demandes de mise en relation
• H.225-RAS (Registration Admission Status) pour la signalisation d’enregistrement avec
le GK ( Téléphone connecté et peut être joint ), d'admission ( demande d'appel ) et d'état.
• H.225-Q.931 ( ou H225-CS Call Signaling )pour la signalisation d’appel: Idem RNIS
- H.245: Canal de contrôle d’appel pour envoyer des messages de négociation
sur la façon de communiquer et de coder les informations à échanger.
- RTP ( audio, vidéo ) et T120 ( Tableau blanc ): Canaux de transport des données pour l’audio,
la vidéo et le partage d’application.
RTP = numéro de port UDP pair, RTCP associé = numéro du port UDP de RTP + 1
RTCP contient des informations sur les échanges ( temps de transfert, gigue, perte paquets ).
- RTCP (Real Time Transport Control Protocol): canaux de contrôle du transport des données
audio et vidéo gérant des messages pour s’assurer que les données audio et vidéo sont bien
échangées ( contrôler l’arrivée des paquets car RTP fonctionne sur UDP ).
Pile protocolaire H323:
Les principaux messages RAS ( enregistrement, authentification, état )
messages de requête (xRQ = xReQuest) envoyé au GK qui accepte (xCF = xConFirm) ou rejette (xRJ=xReJect)
Requête du client
( xRQ )
Réponse: Accord
du GK ( xCF )
Réponse: Refus
du GK ( xRJ )
découverte de GK: G GRQ GCF GRJ
enregistrement sur le GK: E ERQ ECF ERJ
autorisation d'appel: A ARQ ACF ARJ
modification de bande passante: B BRQ BCF BRJ
Fin de communication: D DRQ DCF DRJ
résiliation d'enregistrement: U URQ UCF URJ
Les messages Q931: Voir RNIS ( Setup, Call Proceeding, Alerting, Connect, ... )
3
ToIP

Les principaux messages H245: Gestion des canaux logiques pour communication multimédia
Au message de commande peut répondre un message Ack, Reject, Confirm (Release aussi en cas
particulier de time out ).
Master-Slave Determination Détermination du rôle de maître et esclave.
Terminal Capability Set Echanges sur les capacités multimédia des terminaux
=> Choix des codecs utilisés
Open Logical Channel
Ouvre un canal logique pour transport multimédia: RTP + RTCP
Close Logical Channel
Fermeture de canal logique multimédia
End Session Command Fin de session H245 ( plus de messages H245 )
...
Le protocole RTP
Une session RTP est un échange point à point pour un seul flux de données. Un ensemble de sessions ( différents
flux et liaisons ) formera la communication multimédia.
RTP fonctionne avec ses contrôles: RTCP: Une session est définie par un couple de port: RTP ( pair ) et RTCP
( impair = celui de RTP + 1 ). RTP/RTCP est au dessus de UDP ( en général ). Les paquets RTP/RTCP ne sont
pas interprétés par le réseau. Il fonctionne en unicast ou multicast.
RTP permet de déterminer la base de temps des différents flux ( estampilles )
de détecter les pertes ou inversion de paquets ( numéros de paquets )
d'identifier le contenu ( payload type:
0 = voix MIC G711 µ à 64 kbit/s
3 = voix GSM à 4,8 kbit/s
33 = vidéo MPEG2 )
Le flux d'un média est fait de paquets ( UDP/entête RTP/charge RTP=codec ). Les entêtes RTP des paquets sont:
V ( 2 bits ): version du protocole RTP
P ( 1 bit ): Padding ( 1 => octets de remplissage à la fin de la charge, le dernier
octet de la charge indique le nombre de ces octets )
X ( 1 bit ): Extension ( 1=> l'entête est étendue )
CC: CSRC Count ( 4 bits ): Nombre de sources ( 0: la source est aussi la soucre de
synchro ).
M: Marker ( 1 bit ): Signification lié au type de média
PT: Payload Type ( 7 bits ): Type de flux média (RFC 1890 )
Sequence number ( 16 bits ): N° du paquet RTP
Timestamp ( 32 bits ): Référence liée à l'instant de codage du premier octet de la
charge ( RTCP fera le lien entre cette valeur locale et le temps absolu ).
SSRC: Synchronization Source: Identifie la source de synchro.
CSRC: Content Source ( 32 bits ): Identifie la ou les source(s) voir CC.
Le protocole RTCP ( RFC 3550 )
Un appareil en session RTP envoie périodiquement des paquets RTCP ( infos sur la QoS, sur la source et
statistiques de transmission ). Il y a différents types de paquets RTCP:
Sender Report ( SR ), Receiver Report ( RR ), Source Description ( SDES ), Goodbye (Bye ).
Un paquet UDP peut concaténer plusieurs paquets RTCP. Un participant à la session RTP qui a émis un paquet
RTP devra envoyer un paquet Sender Report ( SR ), un récepteur un paquet RR:
Paquet RTCP SR ( émission ): Il contient
- le SSRC du flux RTP émis
- L'heure ( NTP TimeStamp: RFC 1305 )
quand le rapport a été émis.
- Le TimeStamp RTP correspondant à
l'heure
- Le nombre de paquets envoyés
- Le nombre d'octets envoyés
- Un rapport RR pour chaque source reçue
Paquet RTCP RR ( réception ): Il contient Paquet RTCP SDES
( Description de la source )
- le SSRC du flux RTP
- information obligatoire:
- la proportion de paquets perdus CNAME ( Canonical Name =
( = nb de paquets perdus / nb paquets chaine ascii user@host )
envoyés donné par SR )
- le dernier numéro de séquence - informations optionnelles
- la gigue ( variation de la latence )
- le dernier SR reçu
- délai passé depuis le dernier SR reçu
Paquet RTCP BYE:
Une source inactive envoie un paquet
RTCP BYE avec la raison de la fin de
session.
4
ToIP

APPEL SANS GK:
De terminal à terminal ( 4 phases )
5
ToIP

APPEL AVEC GK
On ajoute une première phase RAS ( enregistrement, authentification, état )
- Registration RRQ: * Le terminal donne au GK sur le port 1719 son Alias et son n° E164, son IP et port H225-Q931 ( 1720 par défaut ), son IP et port H225-RAS ( dynamique, utilisé pour ce message ).
Le GK enregistre le terminal ( adr IP, Alias, n° E164, prêt à communiquer ).
RCF: * Le GK indique - le port d'appel H225-Q931 du GK à utiliser par le terminal pour envoyer au GK les messages H225-Q931 ( normalement 1720, 1721 pour GnuGK par défaut ).
- une durée de vie de l'enregistrement
- une référence du terminal dans le GK, ...
- Authentification ARQ: * Envoi sur le port 1719 avec type d'appel ( pt à pt ou multipoint ), identifiant de l'appelant, n°E164 ou Alias de l'appelé, n°E164 ou Alias de l'appelant,
une référence d'appel, la bande passante souhaitée
ACF: * Envoi de la bande passante allouée, le mode d'appel via GK ( direct ou routé ), l'adresse IP et le port H225-Q931 du GK ( 1720 par défaut en H323, 1721 par défaut sur GnuGK )
- Status
Au lieu de numéroter avec l'adresse IP ( appel sans GK ), l'appelant doit mettre le numéro E164 ou l'alias H323 appelé dans son logiciel ( l'adresse IP du GK a été définie ou découverte par
recherche multicast ). Le GK va traduire le numéro demandé en IP et port destination.
Si on met l'adresse IP pour un appel avec GK, le logiciel risque de créer des incohérences, à fortiori si on mélange E164 et IP => échec d'appel.
Exemple: GnuGK est un GK qui utilise le port 1721 par défaut. Le terminal Ekiga réalise bien les étapes RRQ et ARQ.
Mais quand il envoie le SETUP H225-Q931 sur le port 1721 négocié en RAS, il met un port destination dans le message = 1720 !! ( tout en utilisant 1721 donné en RAS )
n°E164 dans le terminal => Cohérence des ports. n°E164@adr IP => Incohérence des ports d'où échec ( Ekiga met port dest = 1720 dans le message SETUP car il voit une IP
dans le numéro d'appel alors qu'il utilise 1721 que RAS lui a dit d'utiliser ).
Il existe 3 modes selon le niveau d'implication du GK:
6
ToIP

APPEL AVEC GK : Mode direct ( 5 phases )
7
ToIP

8
ToIP

Avantages, inconvénients des modes avec GK:
Mode direct:
+ Peu de trafic sur le GK,
- Difficultés avec la NAT ou les firewall ( ports dynamiques, plage à autoriser ).
Mode routé: + Le GK garde la supervision ( modification des paramètres d'un flux, facturation ).
- Machine fortement sollicitée.
Mode Proxy: + Le GK garde la supervision ( modification des paramètres d'un flux, facturation ).
+ Gestion de la NAT.
+ Gestion plus facile de firewall.
- Machine très fortement sollicitée.
- Mode non défini dans la norme, tout GK ne fait pas proxy.
I) Démarrage plus rapide ( Fast Start ):
Améliorations et nouvelles fonctionnalités
On utilise souvent les 3 fonctionnalités suivantes en parallèle:
– H.245 Tunneling:
H.225-Q.931 et H.245 utilisent un seul canal ( messages H.245 via la même connexion TCP initiée sur
le port de H225-Q931: 1720 souvent ) => 1 port TCP en moins.
– H245 précoce ( Early H.245 )
Ouverture du canal de contrôle H.245 dès que possible et parallèlement à la signalisation d’appel Q931.
( l’adresse H.245 est fournie par l’appelant dans le message SETUP et/ou par l’appelé dans le message
CallProceeding et/ou Alerting )
* la négociation des paramètres anticipée
* ouverture des canaux RTP avant le message Connect
=> Etablissement d'appel plus rapide.
– Démarrage rapide ( FastConnect )
Les informations du canal de contrôle H245 sont incluses dans l’invitation d’appel H225-Q931 SETUP.
=> ouverture du canal H.245 simplifiée ou même rendue optionnelle.
L’appel est plus rapidement établi ( quelques sec. contre 15-30 sec. en H.323 v.1 )
II) Services supplémentaires
H450: Série de recommandations proposant d'autres services ( H450.2: Transfert d'appel, H450.4: Mise en
garde,... )
9
ToIP

Appel d’un poste H323 vers un téléphone classique : GK et passerelle Gateway
Etape préliminaire : Etablissement d’une liaison physique. ( acquérir les paramètres réseaux puis connexion )
Etape 1 : Localisation du Gatekeeper ( enregistre les terminaux, les autorise ou non à utiliser les ressources, les facture )
- Un gatekeeper écoute l’adresse multicast 220.0.1.41 sur le port UDP 1718.
Le terminal envoie un message UDP H225 « GRQ = gatekeeper request » vers cette adresse et ce port.
( contient l’adresse et port RAS utilisés, le type de terminal ).
- Le gatekeeper répond par « GCF = Gatekeeper confirm » vers le port RAS défini ( contient le nom du gatekeeper, l’adresse et port RAS utilisés ).
- Le terminal s’enregistre auprès du gatekeeper sur le port UDP 1719 par le message « RRQ Registration request ».
Il contient les mêmes informations que GRQ.
- Le gatekeeper répond par « RCF Registration confirm » vers le port RAS spécifié par le terminal. Il contient une adresse et port H225 pour
les messages de contrôle d’appel à envoyer au gatekeeper, un alias ( N° E164, chaîne de caractères ) permettant de connaître ce terminal hors
du réseau, un identificateur unique que le terminal devra rappeler lors des messages suivants.
Etape 2 : Trouver le destinataire
- Le terminal envoie « LRQ Location request » sur le port UDP 1719 du gatekeeper indiquant l’alias de l’appelé et l’adresse où il souhaite la réponse.
- Le gatekeeper répond sur le port indiqué en donnant l’adresse IP et le port où contacter le correspondant ( passerelle de sortie ) pour envoyer les
messages de signalisation d’appel Q931. Il donne aussi le couple IP/Port pour les messages RAS.
Etape 3 : Demande d’admission
- Le terminal envoie un message RAS « ARQ Admission request » à son gatekeeper comprenant numéro de demande, type d’appel,
modèle d’appel, identificateur de l’appelant, adresse de l’appelé ( E164 ou ID H323), l’adresse de l’appelant, la bande passante
- Le gatekeeper répond par « ACF Admission confirm » où il alloue une bande passante, indique l’adresse « signal d’appel » à utiliser pour
la signalisation Q931,.…
Etape 4 : Message de connexion
- L’appelant envoie un message « Initialisation » vers adresse et port 1720 du correspondant que le gatekeeper a indiqué précédemment
( ici passerelle IP vers réseau téléphonique ). Le message contient :
Capacité de transport, numéro E164 de l’appelant, de l’appelé, adresse de transport H245, identité H323,…
- La passerelle demande l’autorisation au gatekeeper avant de traiter l’appel ( messages ARQ/ACF ).
- La passerelle traite l’appel.
- La passerelle envoie à l’appelant le message « Sonnerie et traitement d’appel en cours » sur le port 1720 régulièrement jusqu’à ce que l’appelé
décroche.
- Au décrochage de l’appelé, la passerelle envoie à l’appelant le message « Connexion » comme l’indique la norme Q931. Il donne son adresse et
port H245 où devra s’établir le canal de contrôle d’appel.
Etape 5 : Début de communication et conversation
On reprend les étapes décrites pour l’échange entre 2 postes H323 sasn GK.
10
ToIP

II) SIP ( Session Initiation Protocol )
Origine de SIP ( Henning Schulzrinne à www.cs.columbia.edu )
SIP est un protocole simple de l’IETF ( RFC2543 ), utilisant des requêtes et des réponses textes. Un
usager dans un réseau SIP est identifié par une adresse e-mail sip: userID@gateway.com. Son identité peut aussi
être un numéro de téléphone ( adresse E164 ).
Composants de SIP
Clients SIP :
- Téléphones ( PC = Softphones ou téléphones SIP )
- Gateway : Contrôle d’appel, changement de format de transmission
Gestion de l’établissement et rupture d’appel côté IP et réseau à commutation de circuit.
Serveurs SIP :
- Serveur Proxy : Elément intermédiaire qui reçoit et redirige les requêtes SIP. Il est capable
d’authentification, d’autorisation, de routage, de retransmission de requête.
- Serveur de redirection ( RS = Redirect Server ) : Fournit au client le ou les sauts qu’un message
doit suivre, le client contactera le serveur du saut suivant.
- Serveur d’enregistrement ( Registrar Server ) : Enregistre la localisation d’un client.
Les usagers s’enregistrent avec un serveur d’enregistrement. Ce serveur fournira la localisation de
l’usager quand on lui demandera cet usager.
Quand un usager lance un appel, une requête SIP est envoyée au serveur SIP ( soit proxy, soit serveur
de redirection ). Elle inclut l’adresse de l’appelant ( champ From de l’entête ) et l’adresse de l’appelé ( Champ
To de l’entête ).
Différents messages de requête échangés :
INVITE
ACK
BYE
CANCEL
OPTIONS
REGISTER
Requête
Description
Pour initier une session = établissement d’appel
Conclut la fin d’une procédure.
Pour terminer une session
Pour annuler des recherches et sonnerie
Pour indiquer les caractéristiques supportées par le terminal
Enregistre un usager dans un service de localisation
Contenu du message INVITE :
Ce message est envoyé par le client appelant pour lancer un appel.
Paramètre
Description
Identifiant d’appel ( Call-ID )
CSeq
From
To
Via
Différents messages de réponse échangés :
Identifie la session
Nombre qui est incrémenté pour se repérer dans une séquence de requêtes pour un appel
donné.
URL ( User registration Location ) indiquant l’appelant.
URL ( User registration Location ) indiquant l’appelé.
Indique le chemin pris par la requête jusqu’ici.
Il est utiliser pour prévenir les boucles.
Il permet à la réponse de suivre la même route.
Réponse
1xx
2xx
3xx
4xx
5xx
6xx
Messages informatifs
Réponse en cas de succès
Réponse de redirection
Messages d’échec de requête
Messages d’échecs de serveur
Messages d’échecs généraux
Description
11
ToIP

Fonctionnement de SIP
* Recherche d’un usager :
L’intérêt de SIP est l’utilisation du DNS du fait du format e-mail d’une adresse.
Dans le cas d’une redirection, on arrive aux échanges suivants :
12
ToIP

* Exemple d’établissement d’appel mêlant RNIS et SIP utilisant un serveur de redirection
Détail du déroulement d’appel
1 Etablissement d’appel RNIS entre PABX et Gateway1 selon le numéro appelé.
Le PABX est programmé pour utiliser ce faisceau pour le numéro appelé.
2 Le Gateway 1 appelle le serveur RS. Dans l’invitation à participer
- on trouve l’adresse de l’appelé :
“sip:0381994700@host.com; user=phone.”
User=phone indique que c’est un numéro de téléphone, pas une adresse IP.
- Le PABX A est défini comme initiateur de la session dans le champ From.
- Un numéro est affecté à la session, il est placé dans le champ Call-ID.
- Le port de la Gateway1 pour recevoir les données RTP est spécifié.
3 Le serveur de redirection répond. Il indique avoir accepté l’invitation, contacté un serveur
de location couvrant host.com qui lui a indiqué où trouver l’appelé. Il renvoie au
Gateway1 les différentes adresses possibles de l’appelé ( Multiple Choice ).
4 Acquittement par le Gateway1 qui conclut cette phase.
5 Gateway1 appelle Gateway2 qui correspond à la première possibilité. Cseq est incrémenté
6 Le Gateway2 reçoit le message INVITE et appelle le PABX de l’usager appelé.
7 Pendant ce temps, le Gateway1 indique à l’usager appelant que la procédure suit son cours
en acquittant la demande d’établissement d’appel..
8 Le Gateway2 répond à l’INVITE envoyée par le Gateway1 en indiquant qu’il tente de
contacter l’usager
9 Le PABX B indique au Gateway2 qu’il recherche l’usager appelé.
10 Le PABX B l’a trouvé et l’informe par sonnerie qu’on l’appelle. Il rapporte cela au
Gateway 2.
11 Le Gateway2 informe le Gateway1 que l’usager appelé est trouvé et informé.
12 Le Gateway1 informe le PABX A que le terminal de l’usager appelé sonne.
Le PABX A envoie la tonalité de sonnerie à l’appelant.
Un lien unidirectionnel est établi entre PABX A et Gateway1, entre PABX B et Gateway2.
Un lien bidirectionnel est établi entre Gateway1 et Gateway2 ( canal RTP ).
13 L’appelé répond, le PABX B informe le Gateway 2, la connexion est faite dans les 2 sens.
14 Le Gateway 2 indique au Gateway 1 qu’il communique avec l’appelé.
15 Le Gateway informe le PABX A.
16 Le PABX A acquitte cette information de connexion avec l’appelé.
17 Le Gateway 1 informe le Gateway 2 que de son côté la liaison est prête aussi.
18 Le Gateway 2 informe le PABX B que tout le monde est prêt.
Un lien bidirectionnel est établi entre PABX A et Gateway1, entre PABX B et Gateway2.
Un lien bidirectionnel est établi entre Gateway1 et Gateway2 ( canal RTP ).
19 L’usager B raccroche, le PABX B envoie le message RNIS Disconnect au Gateway.
13
ToIP

III) Comparaison SIP/H323
H323 est une suite de protocoles clairement définis par l’UIT. Cette norme a été beaucoup utilisée
( Microsoft avec netmeeting ) et a donc l’avantage d’être répandue. Elle a été améliorée avec la version 2 puis 3.
Toutefois H323 est un ensemble d’éléments compliqués et lourd à mettre en œuvre ( on doit définir les
interactions entre protocoles ). Le fonctionnement demande l’utilisation de serveurs spécifiques.
La complexité de H323 et ce principe de serveurs spécifiques entraînent un temps d’établissement
d’appel trop long.
Le protocole SIP a été développé pour éliminer ces problèmes tout en remplissant les mêmes fonctions
de signalisation. Il est simple à développer car basé sur des échanges de texte pour la signalisation. Ainsi on
peut développer des applications CTI extrêmement simplement.
SIP utilise le système de DNS.
Cette signalisation tire partie du développement d’internet car elle utilise le système de DNS comme
système d’annuaire intermédiaire ( il faut tout de même un serveur local de localisation ).
SIP utilise plutôt UDP alors que H323 utilise TCP. Comme TCP est un mode connecté, les gateways
H323 doivent connaître en permanence l’état de la connexion. Cela devient problématique si le nombre
augmente ( la version 3 de H323 autorise l’utilisation de UDP pour diminuer le temps d’établissement de
connexion ).
SIP
H323
Norme IETF UIT
Mode connecté ( TCP ) ou non UDP et TCP TCP
( UDP option version 3 )
Intelligence dans le réseau
Serveurs ( Proxy, Gatekeepers
redirect, registrar )
Modèle
Web www Téléphonie: QSIG
Client / Serveur
Protocole temps réel RTP RTP
Base du code Texte ASCII Binaire
Protocoles associés IP, SDP, HTTP,… Protocoles RNIS
14
ToIP

15
ToIP

Performances d'un ordinateur hébergeant un serveur ASTERISK *
selon le protocole de signalisation utilisé ( codec loi en µ )
selon le codec utilisé
16
ToIP

Evolution du coeur de réseau
( NGN Next Generation Network )
Le réseau doit gérer des flux multimédia: Voix, données, images.
Il est fait de couches successives ajoutées:
- Réseau téléphonique à commutation de circuit ( RTC, RNIS ) pour la voix.
- puis DSLAM pour la data.
- puis appareils pour la Triple play.
On cherche maintenant à regrouper la gestion de ces flux: NGN, Next Generation Network ou Réseau
Convergent Multiservices.
( NGN est un terme générique qui peut être réalisé par plusieurs technologies ).
Ce réseau repose sur 2 éléments:
- Softswitch: Il n'est plus associé à un point physique du réseau et ne gère plus les liens
physiques = Serveur informatique qui fait le traitement des appels vocaux:
Il identifie la demande d'appel que le réseau lui achemine et gère l'intelligence du
service de commutation ( analyse des paquets de signalisation, acheminement selon
table d'appels, plan de numérotation ). Il indique la route à suivre.
Les paquets voix ne transitent pas par lui mais par la route qu'il indique.
=> Découplage matériels de signalisation/trafic voix => Moins de sites, de liens par rapport au TDM.
- Media Gateway: Assure la gestion de la couche physique ( disponibilité, gestion de fautes ).
Couche physique = réseau de transmission ( coeur de réseau )
et réseau d'accès ( liaison avec abonnés ).
Il met en paquets le trafic voix.
Le softswitch gère les Media Gateways par protocole SIP, SIGTRAN, MEGACO ou MGCP.
Il devra utiliser la signalisation SS7 pour dialoguer avec le RTC,
SIP ou autre pour dialoguer avec un serveur dans le doamine paquet.
Pour le partie réseau d'accès, on utilise un appareil qui intégre tous les types de liaisons ( RTC, RNIS, DSL,
FTTx, X25, ... ): Solution de raccordement tout en un = MSAN ( Multi Service Access Node ).
17
ToIP

Un réseau NGN est organisé selon une architecture en couches:
Couche d'accès: fonctions et équipements pour gérer les équipements de l'usager
( téléphone commuté, DSL, HFC = hybrid fibre coaxial, sans fil, ... )
Couche de transport: Acheminement du trafic dans le coeur de réseau.
Le Media Gateway = MGW fait la passerelle entre le protocole de
transport et les types de réseaux physiques d'accès.
Importance de la QoS.
Couche de contrôle: Contrôle des services ( en particulier contrôle d'appel pour la voix ).
Le Softswitch est le serveur d'appel qui réalise la commutation.
Le protocle le plus utilisé est IMS ( IP Multimedia Subsystem ).
Dans ce cas le softswitch est un CSCF ( Call Session Control
Function ).
Couche d'exécution des services: Serveurs d'applications et "enablers" ( gestion d'infos utilisées par les
serveurs d'applications comme gestion de présence de l'usager ).
Cette couche utilise souvent SIP.
Couche d'applications: Applications.
Ces couches sont indépendantes => Plus de flexibilité et ajout de nouveaux services sans tout changer.
Cela facilite aussi l'interconnexion de réseaux ( NGN ou traditionnels ).
18
ToIP

IMS ( IP Multimedia Subsystem )
La partie contrôle du réseau NGN est IMS ( IP Multimedia Subsystem: protocole du 3GPP venant d'UMTS ).
« IMS, c'est un SIP intelligent:
SIP était un protocole conçu, à l'origine, de façon verticale, où un client SIP sur le terminal discute
directement avec un autre client ou par l'intermédiaire d'un proxy dans le réseau.
L'IMS enrichit cette notion de proxy en y ajoutant des règles de routage intelligentes, afin de terminer
l'appel au bon endroit, en fonction d'un certain nombre d'informations telles que la localisation,
la présence, le type de terminal... »
I) Eléments d'IMS
Gestion de session et
éléments de routage
CSCF
( Call Session
Control Function )
P-CSCF: Proxy CSCF
Premier contact de l'usager avec un réseau IMS. Tout trafic SIP passe par lui.
I-CSCF: Interrogating CSCF
Doit faire le lien entre un usager et son serveur SIP.
Va interroger pour cela une base de donnée = HSS.
S-CSCF: Serving CSCF
Gestion de l'enregistrement, du routage, des profils d'usager
Bases de données
HSS: Home Subscriber Server
Base principale pour tous les usagers d'un réseau ( HLR/AUC du GSM plus
infos liées au multimédia IP ).
Un usager a une identité privée ( sur son réseau pour enregistrement, autorisation ) et
une publique ( pour que d'autres usagers le contacte )
SLF: Subscription Locator Function
Mécanisme de résolution pour que I-CSCF, S-CSCF et serveurs trouvent la base HSS
d'un usager dans le cas de multiples HSS pour un rseau.
Services
AS: Application server
Héberge et exécute des services
services SIP = SIP AS,
services OSA = OSA-SCS ( Open Service Access - Service Capability Server )
services liés au GSM ( CAMEL ) = IMS-SSF ( Service Switching Function )
MRFC et MRFP: Media Ressource Function Controller et Processor
Gestion media, ensemble de media utilisés par le réseau: Annonces, trancodage,...
Interconnexion
de réseaux
( réseau IP de IMS et
réseau téléphonique )
BGCF: Breakout Gateway Control Function
Serveur SIP incluant des fonctions de routage basée sur le numéro de téléphone
( utilisé seulement pour un appel vers un réseau téléphonique RTC, RNIS ou PLMN )
MGCF: Media Gateway Control Function
Passerelle entre contrôles d'appel côté IMS ( SIP ) et côté réseau téléphonique ( SS7 ).
IMS-MGW ( Media Gateway ) et SGW ( Signalling Gateway ):
MGW: Passerelle entre média côté SIP ( RTP ) et côté réseau téléphonique ( MIC,...)
SGW: Passerelle pour la signalisation ( bas niveau par rapport à BGCF )
Fonctions d'assistance
( support functions )
PDF: Policy Decision Function
Serveur de règles qui gère la qualité de service selon les capacités des terminaux et
leur raccordement.
Ces éléments sont fonctionnels ( logiques ).
Au niveau physique une machine peut regrouper plusieurs de ces fonctions.
19
ToIP

Eléments
de l'architecture IMS
et
Interfaces entre eux
II) Principe d'IMS
Réseaux actuels =
en silos
( infrastructures
parallèles )
Réseau IMS
=
Multimedia
20
ToIP

II) Fonctionnement
1) Avoir une connectivité IP ( ex: En GPRS, Procédure d'attachement, activation du contexte PDP Packet Data Protocol )
2) Découvrir un point d'entrée IMS: P-CSCF (‘‘P-CSCF discovery’’).
( Statique: IP fixée et programmée dans le terminal
Dynamique: recherche par DHCP/DNS ou en GPRS: Requête demandant l'adresse lors de l'activation du contexte
PDP, réponse lors de l'activation PDP par le réseau ).
3) Enregistrement IMS
phase 1: * Le terminal initie l'enregistrement par envoi au P-CSCF découvert de REGISTER
avec - son identité à enregistrer ( publique et privée )
- son domaine "home".
* Le P-CSCF transmet au domaine = I-CSCF trouvé par requête DNS ( rfc3263 ).
En ajoutant "path" avec son URI à l'entête SIP, le P-CSCF indique la route de retour.
* Le I-CSCF interroge le HSS en donnant l'identifiant de l'usager
( "To": identifiant public, "Authorization": identifiant privé )
* Le HSS répond avec la définition du S-CSCF ou des éléments pour que l'I-CSCF en
choisisse un.
* Le I-CSCF prolonge la requête REGISTER au S-CSCF.
* Le S-CSCF interroge le HSS qui lui donne les informations de sécurité à utiliser.
( données de challenge et réponse attendue )
Le HSS mémorise aussi l'identité du S-CSCF pour l'URI piblique de l'usager.
* Le S-CSCF envoie le challenge dans un message:
401 Unauthorized Response avec demande d'authentification ( challenge ).
phase 2: * Le terminal calcule la réponse au challenge du message 401, puis l'envoie dans sa
nouvelle requête REGISTER ( incluant un champ Response après "Authorization" )
* Le S-CSCF vérifie. Si c'est bon, il crée un lien associant identité publique de
l'usager, son champ "contact" et les entêtes "path" du message REGISTER.
Le S-CSCF charge le profil de l'usager depuis le HSS ( liste des serveurs applicatifs
de l'usager ) puis il accepte l'enregistrement: message 200 OK.
Phase 1
Phase 2
21
ToIP

4) Appel ( Session Initiation )
L'appel est activé par message INVITE.
L'appelé envoie 183 Session Progress = 1ère réponse SDP ( Session Description Protocol )
Ensuite il y aura échange d'informations supplémentaires nécessaires à la communication
( message PRACK = Provisional Response ACK, réponse 200 OK,
message UPDATE, réponse 200 OK, réponse 180 Ringing, message PRACK, réponse OK )
Enfin, lorsque l'appelé répond ( fin de l'établissement ), le terminal de l'appelé enverra 200
OK, l'appelant lui répondra par ACK. Ils seront alors en communication.
22
ToIP