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 On y trouve:
ou - des interfaces avec le réseau IP ( support des protocoles de routage )
Gateway - 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 C’est un serveur centralisé qui assure:

ou - Conversion d’adressage : E.164 <------> @IP (plan d’adressage privé)
Serveur de - Gestion des profils utilisateurs
traitement d'appel - Gestion des appels:
( Call Processing Server ) 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.

ELANG Antoine 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 Réponse: Accord Réponse: Refus

( xRQ ) du GK ( xCF ) 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, ... )

ELANG Antoine 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: 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
Paquet RTCP RR ( réception ): Il contient Paquet RTCP SDES Paquet RTCP BYE:
( Description de la source )
- le SSRC du flux RTP - information obligatoire: Une source inactive envoie un paquet
- la proportion de paquets perdus CNAME ( Canonical Name = RTCP BYE avec la raison de la fin de
( = nb de paquets perdus / nb paquets chaine ascii user@host ) session.
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

ELANG Antoine 4 ToIP

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

ELANG Antoine 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:

J. Millet 6 ToIP
 APPEL AVEC GK : Mode direct ( 5 phases )

ELANG Antoine 7 ToIP

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

Améliorations et nouvelles fonctionnalités

I) Démarrage plus rapide ( Fast Start ):

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

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

ELANG Antoine 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 :

Requête Description
INVITE Pour initier une session = établissement d’appel
ACK Conclut la fin d’une procédure.
BYE Pour terminer une session
CANCEL Pour annuler des recherches et sonnerie
OPTIONS Pour indiquer les caractéristiques supportées par le terminal
REGISTER Enregistre un usager dans un service de localisation

Différents messages de réponse échangés :

Réponse Description
1xx Messages informatifs ( 100 - Trying, 180 - Ringing, … )
2xx Réponse en cas de succès ( 200 - OK, … )
3xx Réponse de redirection
4xx Messages d’échec de requête
5xx Messages d’échecs de serveur
6xx Messages d’échecs généraux

ELANG Antoine 11 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 cz@cs.tu-berlin.de appelle dans son logiciel SIP l'adresse henning@columbia.edu
( 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

ELANG Antoine 12 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:101@192.168.1.23 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:101@192.168.1.23>
Identité de l'appelé ( URL = User Registration Location = user@domain )

From: "100"<sip:100@192.168.1.23>;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 Nom et Fonction

v=0 v Version: Version de SDP
o=- 1 2 IN IP4 192.168.1.24 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 s Session Name: Type d'échange multimédia
c=IN IP4 192.168.1.24 c Connexion avec @IP pour flux RTP
t=00 t Time
m=audio 22784 RTP/AVP 0 98 8 3 101 m Media avec port RTP à utiliser et codec ( PT payload
( 98 = Dynamic RTP Type 98 = codec iLBC de Xlite ) Type de RTP )
a=alt:1 1 : VvFAFtE+ Nfg5ys w+ 192.168.1.24 22784 a Attribute Media
a=fmtp:101 0-15 rtpmap: type de codec ( valeur PT payload type )
a=rtpmap:98 iLBC/8000 Remarque: 101signifie rtp-nte payload ( pour les codes DTMF )
a=rtpmap:101 telephone-event/8000 ptime: durée d'un paquet RTP
a=sendrecv fmtp: manière d'échanger les tonalités DTMF
( xlite ne définit pas d'attribut pour les codecs G711 et GSM )
( Valeur pour un appel avec Xlite vers Trixbox pour l'écho *43; codec G711 µ utilisé pour la communication )

ELANG Antoine 13 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

ELANG Antoine 14 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

ELANG Antoine 15 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 ).

ELANG Antoine 18 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 ).

ELANG Antoine 19 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 P-CSCF: Proxy CSCF

éléments de routage Premier contact de l'usager avec un réseau IMS. Tout trafic SIP passe par lui.
CSCF
( Call Session I-CSCF: Interrogating CSCF
Control Function ) 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 BGCF: Breakout Gateway Control Function

de réseaux Serveur SIP incluant des fonctions de routage basée sur le numéro de téléphone
( réseau IP de IMS et ( utilisé seulement pour un appel vers un réseau téléphonique RTC, RNIS ou PLMN )
réseau téléphonique )
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 PDF: Policy Decision Function

( support functions ) 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.

ELANG Antoine 20 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

ELANG Antoine 21 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".

* LeP-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

ELANG Antoine 22 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.

ELANG Antoine 23 ToIP