ToIP ( Telephony over IP ) - UV TL53 UTBM

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
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
Gatekeeper
ou
Serveur de
traitement d'appel
( Call Processing Server )
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 : vidéo, voix, données, signalisation, 30 secondes pour établir un appel ... Complexe
- H.323 v2 :
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é
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 était soutenu par
Microsoft ( Netmeeting ).
En fait H323 regroupe différents protocoles qui doivent agir ensemble.
J. Millet
1
ToIP
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.
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 ).
J. Millet
2
ToIP
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)
découverte de GK: G
enregistrement sur le GK: E
autorisation d'appel: A
modification de bande passante: B
Fin de communication: D
résiliation d'enregistrement: U
Requête du client
( xRQ )
Réponse: Accord
du GK ( xCF )
Réponse: Refus
du GK ( xRJ )
GRQ = code fait de 0 et 1
dans champ de trame
RRQ
ARQ
BRQ
DRQ
URQ
GCF
GRJ
RCF
ACF
BCF
DCF
UCF
RRJ
ARJ
BRJ
DRJ
URJ
Les messages Q931: Voir RNIS ( Setup, Call Proceeding, Alerting, Connect, ... )
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
APPEL
SANS GK:
End Session Command
Fin de session H245 ( plus de messages H245 )
De terminal à terminal ( 4 phases )
...
Modes de fonctionnement avec GK
J. Millet
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.
3
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:
J. Millet
4
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: [email protected]. 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 :
Requête
INVITE
= codes ASCII "INVITE" dans
message sur port SIP 5060
ACK
BYE
CANCEL
OPTIONS
REGISTER
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
Différents messages de réponse échangés :
Réponse
1xx
2xx
3xx
4xx
5xx
6xx
J. Millet
Description
Messages informatifs ( 100 - Trying, 180 - Ringing, … )
Réponse en cas de succès ( 200 - OK, … )
Réponse de redirection
Messages d’échec de requête
Messages d’échecs de serveur
Messages d’échecs généraux
5
ToIP
Fonctionnement de SIP
* Appel d'un usager par son adresse ( pas de numéro de téléphone E164 ) :
L’intérêt de SIP est l’utilisation du DNS du fait du format e-mail d’une adresse.
L'appelant [email protected] appelle dans son logiciel SIP l'adresse [email protected]
( pas de numéro de téléphone appelé donc pas de passage par un serveur SIP côté appelant )
NB: Pour alléger le schéma, il n'y a pas:
- les requêtes au serveur DNS
- certains messages informatifs
(100-Trying après INVITE,
180-Ringing après réception du INVITE)
* Appel avec utilisation de redirection
J. Millet
6
ToIP
Contenu du message d'établissement d'appel INVITE
Ce message est envoyé par le client appelant pour lancer un appel.
( La trame qui illustre les messages est un appel du téléphone Xlite 100 d'@IP 192.168.1.24 vers le 101 en utilisant un serveur en
192.168.1.23 )
Request Line: Identifie la méthode = Contenu du message SIP
INVITE sip:[email protected] SIP/2.0
Méthode INVITE,
request-URI User Part: 101,
request-URI Host Part: 192.168.1.23
version SIP: SIP/2.0
Message Header:
Via: SIP/2.0/UDP 192.168.1.24:11792;branch=z9hG4bK-d87543-796fa72b2541a62b-1--d87543-;rport
VIA sert à enregistrer la route suivie par le message. Chaque proxy SIP y ajoute son adresse.
La réponse à la requête utilisera ces informations.
Il est aussi utilisé pour éviter les boucles.
Dans notre exemple on a l'adresse IP du PC appelant.
Max-Forwards: 70
Valeur décrémentée à chaque serveur traitant la demande ( comme un TTL )
Valeur initiale à 70.
To: "101"<sip:[email protected]>
Identité de l'appelé ( URL = User Registration Location = user@domain )
From: "100"<sip:[email protected]>;tag=b705a06f
Identité de l'appelant
Call-ID: MjIwNjQyYTkzYjljODM4NTY4NjcwZTM1Nzk4OTcyZTE.
Identifiant d'appel
CSeq: 2 INVITE
Numéro de séquence et méthode de la demande. Il permet d'identifier les transactions.
On peut aussi avoir d'autres entêtes ( Header ): Allow, User-agent, Authorization, … ( voir RFC 3261 )
Message Header: Il contient la description de l'appel pour la partie multimédia ( RTP, codec ): SDP
Source: https://supportforums.cisco.com/document/113271/understanding-sip-traces
RFC 3261 http://abcdrfc.free.fr/rfc-vf/pdf/rfc3261.pdf
Description de session SDP ( Session Description Protocol ): RFC 4796
On retrouve le protocole SDP dans les messages SIP comme RTSP ( Real Time Streaming Protocol ).
Dans le message SDP on trouve les informations:
Paramètres SDP
v=0
o=- 1 2 IN IP4 192.168.1.24
Nom et Fonction
v Version: Version de SDP
o Origin: ( Nom du créateur, xlite met "-",
Identifiant de session
Version de session
Type de réseau du créateur: IN Ip Network
Type d'adresse réseau IP4
Adresse réseau du créateur du flux )
s=CounterPath X-Lite 3.0
c=IN IP4 192.168.1.24
t=00
m=audio 22784 RTP/AVP 0 98 8 3 101
( 98 = Dynamic RTP Type 98 = codec iLBC de Xlite )
a=alt:1 1 : VvFAFtE+ Nfg5ys w+ 192.168.1.24 22784
a=fmtp:101 0-15
a=rtpmap:98 iLBC/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
( xlite ne définit pas d'attribut pour les codecs G711 et GSM )
s Session Name: Type d'échange multimédia
c Connexion avec @IP pour flux RTP
t Time
m Media avec port RTP à utiliser et codec ( PT payload
Type de RTP )
a Attribute Media
rtpmap: type de codec ( valeur PT payload type )
Remarque: 101signifie rtp-nte payload ( pour les codes DTMF )
ptime: durée d'un paquet RTP
fmtp: manière d'échanger les tonalités DTMF
( Valeur pour un appel avec Xlite vers Trixbox pour l'écho *43; codec G711 µ utilisé pour la communication )
J. Millet
7
ToIP
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: PT payload type: 0 = voix G711 loi µ à 64 kbit/s 8 kHz, trame de 20 ms
3 = voix GSM à 13 kbit/s
8 = voix G711 loi A à 64 kbit/s 8 kHz, trame de 20 ms
18 = G729 Fe=8kHz, trame de 20 ms
Voir http://en.wikipedia.org/wiki/RTP_audio_video_profile
)
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
J. Millet
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
8
Paquet RTCP BYE:
Une source inactive envoie un paquet
RTCP BYE avec la raison de la fin de
session.
ToIP
Exemple d’établissement d’appel mêlant RNIS et SIP utilisant un serveur de redirection
Source: http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/sip/proxies/1-0/administration/guide/ver1_0/appbcf.pdf
J. Millet
9
ToIP
Performances d'un ordinateur hébergeant un serveur ASTERISK *
selon le protocole de signalisation utilisé ( codec loi en µ )
selon le codec utilisé
J. Millet
10
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 ).
J. Millet
11
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 ).
J. Millet
12
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.
J. Millet
13
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
J. Millet
14
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
J. Millet
15
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.
J. Millet
16
ToIP