2
- Le Réseau Téléphonique Commuté
Mais qu’est-ce que le RTC?
Le RTC est tout simplement le réseau téléphonique que nous utilisons
dans notre vie de tous les jours et qui nous donne accès à de
multiple fonction. En effet outre le fait de pouvoir téléphoner,
le RTC nous permet d’utiliser de multiples services tel que la
transmission et réception de fax, l’utilisation d’un minitel,
accéder à Internet etc… Il représente donc l'un des protocole
de discussion utilisé sur la paire de cuivre boucle locale.
2.1 - Histoire de la téléphonie
Du premier télégraphe de Chappe
en 1790 au RTC actuelle, l’histoire des communications à connu
de grands moments et de grandes avancés dû à l’ingéniosité de
certains et aux progrès technologique et électronique. Nous retiendrons
quelques grandes dates tel que :
1837 Premier télégraphe électrique
inventé par Samuel Morse
1889 Almon B. Strowger (USA)
invente le premier « sélecteur » automatique et donne ainsi naissance
à la commutation téléphonique automatique
1938 Alec Reeves (Français)
dépose le brevet des futurs systèmes à modulation par impulsion
et codage (MIC) : quantification et échantillonnage du signal
à intervalles réguliers, puis codage sous forme binaire.
1962 Les premiers systèmes
de transmission multiplex de type MIC apparaissent aux Etats-Unis
ils permettent une liaison à 24 voies entre centraux téléphonique,
à la même époque en France on installe des MIC à 32 voies.
1970 Un nouveau pas est franchi
dans le domaine de la commutation électronique avec la mise en
service en France, par le CNET, des premiers centraux téléphoniques
publics en commutation électronique temporelle.
1979 Lancement du minitel en
France
1987 Le RNIS est mis en service
en France.
1990 De nouveaux concepts apparaissent
tel que la commutation temporelle asynchrone (ATM) et la hiérarchie
numérique synchrone.
2.2 - Principe du Rtc
Le réseau téléphonique public
(RTPC, Réseau Téléphonique Public Commuté ou simplement RTC) a
essentiellement pour objet le transfert de la voix. Le transport
des données n'y est autorisé, en France, que depuis 1964. Utilisant
le principe de la commutation de circuits, il met en relation
deux abonnés à travers une liaison dédiée pendant tout l’échange.

On distingue deux grandes parties dans ce réseau :
Le réseau capillaire ou de
distribution, c’est le raccordement depuis chez l’abonné à un
point d'entrée du réseau. Cette partie du réseau est analogique.
Le réseau de transit, effectue
pour sa part le transport des communications entre les nœuds de
transit concentrateurs / commutateurs). Cette portion du réseau
est actuellement numérique.
La numérisation offre plusieurs
avantages. Puisqu'il ne s'agit que de 0 et de 1, la qualité du
signal est préservée, quelle que soit la distance entre les convertisseurs
(analogique numérique et numérique analogique). Ce n'est pas le
cas des communications analogiques où le signal est pollué à chaque
manipulation.
La gestion générale du réseau discerne trois fonctions :
La distribution, celle-ci comprend
essentiellement la liaison d'abonné ou boucle locale (paire métallique
torsadée) qui relie l'installation de l'abonné au centre de transmission
de rattachement. Cette ligne assure la transmission de la voix
(fréquence vocale de 300 à 3 400 Hz), de la numérotation (10 Hz
pouf la numérotation décimale -au cadran- et 697 à 1633 Hz pour
la numérotation fréquentielle) et de la signalisation générale
(boucle de courant, fréquences supra vocales)
La commutation, c'est la fonction
essentielle du réseau, elle consiste à mettre en relation deux
abonnés, maintenir la liaison pendant tout l'échange et libérer
les ressources à la fin de celui-ci. C'est le réseau qui détermine
les paramètres de taxation et impute le coût de la communication
à l'appelant
La transmission, c'est la partie
support de télécommunication du réseau, cette fonction est remplie
soit par un système filaire cuivre (en voie de disparition), de
la fibre optique ou des faisceaux hertziens. Aujourd'hui, le réseau
est pratiquement intégralement numérisé, seule la liaison d'abonné
reste analogique.
2.3 - Architecture du réseau
Le réseau téléphonique commuté
a une organisation hiérarchique à trois niveaux. Il est structuré
en zones correspondant à un niveau de concentration.

On distingue :
Zone à Autonomie d'Acheminement
(ZAA), cette zone, la plus basse de la hiérarchie, comporte un
ou plusieurs Commutateurs à Autonomie d'Acheminement (CAA) qui
eux-mêmes desservent des Commutateurs Locaux (CL). Les commutateurs
locaux ne sont que de simples concentrateurs de lignes auxquels
sont raccordés les abonnés finals. La ZAA (Zone à Autonomie d'Acheminement)
est un réseau étoilé, elle constitue le réseau de desserte;
Zone de Transit Secondaire
(ZTS), cette zone comporte des Commutateurs de Transit Secondaires
(CTS). Il n'y a pas d'abonnés reliés aux CTS (Commutateurs de
Transit Secondaires). Ils assurent le brassage des circuits lorsqu'un
CAA (Commutateur à Autonomie d'Acheminement) ne peut atteindre
le CAA destinataire directement (réseau imparfaitement maillé);
Zone de Transit Principal (ZTP),
cette zone assure la commutation des liaisons longues distances.
Chaque ZTP (Zone de Transit Principal) comprend un Commutateur
de Transit Principal (CTP), L'un des commutateurs de transit principal
(CTP) est relié au commutateur international de transit.
6 - Standards
VoIP
6.1 - Protocole H323
6.1.1 - Introduction
Avec le développement
du multimédia sur les réseaux, il est devenu nécessaire
de créer des protocoles qui supportent ces nouvelles
fonctionnalités, telles que la visioconférence : l’envoi
de son et de vidéo avec un soucis de données temps réel.
Le protocole H.323 est l’un d’eux. Il permet de faire
de la visioconférence sur des réseaux IP.
H.323 est un protocole de communication englobant
un ensemble de normes utilisés pour l’envoi de données
audio et vidéo sur Internet. Il existe depuis 1996 et
a été initié par l’ITU (International Communication
Union), un groupe international de téléphonie qui développe
des standards de communication. Concrètement, il est
utilisé dans des programmes tels que Microsoft Netmeeting,
ou encore dans des équipements tels que les routeurs
Cisco. Il existe un projet OpenH.323 qui développe un
client H.323 en logiciel libre afin que les utilisateurs
et les petites entreprises puissent avoir accès à ce
protocole sans avoir à débourser beaucoup d’argent.
6.1.2 - Fonctionnement
Le protocole H.323 est utilisé
pour l’interactivité en temps réel, notamment la visioconférence
(signalisation, enregistrement, contrôle d’admission, transport
et encodage). C’est le leader du marché pour la téléphonie Ip. Il s’inspire
du protocole H.320 qui proposait une solution pour la visioconférence
sur un réseau numérique à intégration de service (Rnis ou Isdn en
anglais), comme par exemple le service numéris proposé par France
Telecom. Le protocole H.323 est une adaptation de H.320 pour les
réseaux Ip. A l’heure actuelle, la visioconférence sur liaison Rnis
est toujours la technique la plus déployée. Elle existe depuis 1990.
Les réseaux utilisés sont à commutation de circuits. Ils permettent
ainsi de garantir une Qualité de Service (QoS) aux utilisateurs
(pas de risque de coupure du son ou de l'image). Aujourd'hui, c'est
encore un avantage indiscutable. Par contre, comme pour le téléphone,
la facturation est fonction du débit utilisé, du temps de communication
et de la distance entre les appels.
H.323 définit plusieurs éléments de réseaux :
Les terminaux - Dans
un contexte de téléphonie sur IP, deux types de terminaux
H.323 sont Aujourd’hui disponibles. Un poste téléphonique
IP raccordés directement au réseau Ethernet de l’entreprise.
Un PC multimédia sur lequel est installé une application
compatible H.323.
Les passerelles (GW:
Gateway) - Elles assurent l'interconnexion entre un
réseau Ip et le réseau téléphonique, ce dernier pouvant
être soit le réseau téléphonique public, soit un Pabx
d’entreprise. Elles assurent la correspondance de la
signalisation et des signaux de contrôle et la cohésion
entre les médias. Pour ce faire, elles implémentent
les fonctions suivantes de transcodage audio (compression,
décompression), de modulation, démodulation (pour les
fax), de suppression d’échos, de suppression des silences
et de contrôle d’appels. Les passerelles sont le plus
souvent basées sur des serveurs informatiques standards
(Windows NT, Linux) équipés d’interfaces particuliers
pour la téléphonie (interfaces analogiques, accès de
base ou accès primaire RNIS, interface E1, etc.) et
d’interfaces réseau, par exemple de type Ethernet. La
fonctionnalité de passerelle peut toutefois être intégrée
directement dans le routeur ainsi que dans les Pbx eux-mêmes.
Les portiers (GK:
Gatekeeper) - Ils sont des éléments optionnels dans
une solution H.323. Ils ont pour rôle de réaliser la
traduction d'adresse (numéro de téléphone - adresse
Ip) et la gestion des autorisations. Cette dernière
permet de donner ou non la permission d'effectuer un
appel, de limiter la bande passante si besoin et de
gérer le trafic sur le Lan. Les "gardes-barrière" permettent
également de gérer les téléphones classiques et la signalisation
permettant de router les appels afin d'offrir des services
supplémentaires. Il peuvent enfin offrir des services
d’annuaires.
Les unités de contrôle
multipoint (MCU, Multipoint Control Unit) - Référence
au protocole T.120 qui permet aux clients de se connecter
aux sessions de conférence de données. Les unités de
contrôle multipoint peuvent communiquer entre elles
pour échanger des informations de conférence.
Dans un contexte
de téléphonie sur IP, la signalisation a pour objectif
de réaliser les fonctions suivantes :
Recherche et traduction
d’adresses - Sur la base du numéro de téléphone du destinataire,
il s’agit de trouver son adresse IP (appel téléphone
. PC) ou l’adresse IP de la passerelle desservant le
destinataire. Cette fonction est prise en charge par
le Gatekeeper. Elle est effectuée soit localement soit
par requête vers un annuaire centralisé.
Contrôle d’appel
- L’équipement terminal (« endpoint » = terminal H.323
ou passerelle) situé à l’origine de l’appel établit
une connexion avec l’équipement de destination et échange
avec lui les informations nécessaires à l’établissement
de l’appel. Dans le cas d’une passerelle, cette fonction
implique également de supporter la signalisation propre
à l’équipement téléphonique à laquelle elle est raccordée
(signalisation analogique, Q.931, etc.) et de traduire
cette signalisation dans le format défini dans H.323.
Le contrôle d’appel est pris en charge soit par les
équipements terminaux soit par le Gatekeeper. Dans ce
cas, tous les messages de signalisation sont routés
via le Gatekeeper, ce dernier jouant alors un rôle similaire
à celui d’un PBX.
Services supplémentaires : déviation, transfert d’appel,
conférence, etc.
Trois protocoles
de signalisation sont spécifiés dans le cadre de H.323
à savoir :
RAS (Registration,
Admission and Status) - Ce protocole est utilisé pour
communiquer avec un Gatekeeper. Il sert notamment aux
équipements terminaux pour découvrir l’existence d’un
Gatekeeper et s’enregistrer auprès de ce dernier ainsi
que pour les demandes de traduction d’adresses. La signalisation
RAS utilise des messages H.225.0 6 transmis sur un protocole
de transport non fiable (Udp, par exemple).
Q.931 - H.323 utilise
une version simplifiée de la signalisation RNIS Q.931
pour l’établissement et le contrôle d’appels téléphoniques
sur Ip. Cette version simplifiée est également spécifiée
dans la norme H.225.0.
H.245 : ce protocole
est utilisé pour l’échange de capacités entre deux équipements
terminaux. Par exemple, il est utilisé par ces derniers
pour s’accorder sur le type de codec à activer. Il peut
également servir à mesurer le retard aller-retour (Round
Trip Delay) d’une communication.
Une communication
H.323 se déroule en cinq phases :
Établissement d’appel
Échange de capacité
et réservation éventuelle de la bande passante à travers
le protocole RSVP (Ressource reSerVation Protocol)
Établissement de
la communication audio-visuelle
Invocation éventuelle
de services en phase d’appel (par exemple, transfert
d’appel, changement de bande passante, etc.)
Libération de l’appel.
6.1.3 - H323 dans le modèle Osi
Les différents protocoles
sont représentés ci-dessous dans le modèle OSI :

6.1.4 - La visioconférence
sur Ip
Tout d’abord, au
niveau économique, la visioconférence sur Ip s’avère
moins coûteuse que celle sur liaison RNIS car d’un côté,
l’équipement d’un PC est relativement peu cher : ce
système ne nécessite pas l’installation de prises RNIS
spéciales. D’autre part, une liaison Rnis a un coût
calculé selon la longueur de l’appel, le débit, et la
distance. Alors que dans une liaison IP, le prix est
forfaitaire selon le débit. En fin de compte, la visioconférence
par Ip s’avère souvent moins onéreuse que par liaison
Rnis.
Ensuite, qualitativement parlant, la visioconférence
sur Ip peut utiliser des débits supérieurs et ainsi
avoir une image et un son meilleurs qu’avec une liaison
Rnis. En effet, la visioconférence sur Numeris utilise
des débits allant de 128Kb/s à 384Kb/s, alors qu’en
mutualisant certaines liaisons Ip, on peut obtenir des
lignes haut débit allant jusqu’à plusieurs Mb/s. Malheureusement,
le problème majeur de la visioconférence sur Ip est
l’absence d’une Qualité de Service (QoS) sur les réseaux
Ip. C’est également ce qui fait l’avantage des réseaux
Rnis. Cependant, avec l’évolution des réseaux Ip, on
sait désormais qu’il est possible qu'on puisse disposer
d’une QoS sur ceux-ci tel que Rsvp, Diffserv, gestion
de file d'attente. On pourrait donc avoir des flux avec
priorité sur ces réseaux.
En dehors du protocole H.323, il existe des normes de
visioconférence sur Ip ayant des possibilités analogues
à H.323 telles que Ip multicast, qui est particulièrement
adaptés au téléenseignement et à la diffusion de séminaires
et conférences car il permet la connexion de plusieurs
dizaines de sites voire plus. Il existe également le
système Vrvs qui est utilisé dans certaines communautés
scientifiques, notamment la physique, en raison de sa
convivialité. Il intègre Ip multicast et H.323.
Pour pouvoir suivre une visioconférence, il faut bien
entendu le matériel adéquat. Ce peut être un matériel
dédié contenant tout ce qu’il faut : moniteur, micro,
et caméra vidéo. Ou alors, un ensemble matériel et logiciel
sur un poste de travail normal (PC, etc.). Si la visioconférence
ne compte que deux interlocuteurs, alors la liaison
est point à point comme illustré sur le schéma ci-dessous
:

Dans le cas où il y a plus de deux interlocuteurs, la
visioconférence nécessite l’utilisation d’un pont multipoint
comme illustré sur le schéma ci-dessous :

Pour se connecter entre eux, les interlocuteurs sont
identifiés par un numéro ou une adresse E.164. Elle
est composée de numéros et est structurée comme un numéro
de téléphone. En particulier, un numéro de téléphone
est une adresse E.164. « E.164 » est le nom de la norme
qui définit ces adresses.
Pour router un appel H.323 dans le réseau, il est nécessaire
d’avoir un « GateKeeper ». C’est un élément logiciel
qui fonctionne dans un PC, ou encore dans un pont multipoint
ou dans un routeur IP (Exemple dans les routeurs Cisco).
En fonction de l’adresse destinataire contenue dans
l’appel H.323, les différents GateKeeper vont établir
la communication entre émetteur et destinateur et mettre
en place le routage.
Par ailleurs, le protocole H.323 intègre la norme T.120
qui permet le partage d’applications. On peut, par exemple,
afficher des documents sur les postes de travail des
autres interlocuteurs.
6.1.5 - Avantages et inconvénients
Les réseaux IP sont
à commutation de paquets, les flux de données transitent
en commun sur une même liaison. La visioconférence IP
mise sur une disponibilité de ces liaisons. Les débits
des réseaux IP doivent donc être adaptés en fonction
du trafic afin d'éviter tout risque de coupure du son
et de la vidéo. Tous les sites n’ont pas le même débit.
Plus le débit sera élevé et plus le risque de coupure
sera faible. Par ailleurs, tant que la Qualité de Service
n’existera pas dans les réseaux IP, la fiabilité des
visioconférences sur les lignes à faible débit sera
basse.
A l’heure actuelle, la compatibilité entre les différentes
normes de visioconférence est assez faible. La visioconférence
H.323 et H.320 sont compatibles mais elles nécessitent
l’emploi de passerelles H.320/H.323.
En ce qui concerne les différentes normes pour la visioconférence
sur Ip, H.323 et Ip Multicast ne sont, en règle générale,
pas compatibles, sauf dans le cadre de VRVS qui permet
un certain degré d’interopérabilité, mais ne gère pas
la norme T.120.
Voici les principaux bénéfices qu’apporte la norme H.323
sont les suivants :
Codec standards :
H.323 établit des standards pour la compression et la
décompression des flux audio et vidéo. Ceci assure que
des équipements provenant de fabricants différents ont
une base commune de dialogue.
Interopérabilité
: Les utilisateurs veulent pouvoir dialoguer sans avoir
à se soucier de la compatibilité du terminal destinataire.
En plus d’assurer que le destinataire est en mesure
de décompresser l’information, H.323 établit des méthodes
communes d’établissement et de contrôle d’appel.
Indépendance vis
à vis du réseau : H.323 est conçu pour fonctionner sur
tout type d’architecture réseau. Comme les technologies
évoluent et les techniques de gestion de la bande passante
s’améliorent, les solutions basées sur H.323 seront
capables de bénéficier de ces améliorations futures.
Indépendance vis
à vis des plates-formes et des applications : H.323
n’est lié à aucun équipement ou système d’exploitation.
Support multipoint
: H.323 supporte des conférences entre trois points
terminaux ou plus sans nécessiter la présence d’une
unité de contrôle spécialisée.
Gestion de la bande
passante : Le trafic audio et vidéo est un grand consommateur
de ressources réseau. Afin d’éviter que ces flux ne
congestionnent le réseau, H.323 permet une gestion de
la bande passante à disposition. En particulier, le
gestionnaire du réseau peut limiter le nombre simultané
de connexions H.323 sur son réseau ou limiter la largeur
de bande à disposition de chaque connexion. De telles
limites permettent de garantir que le trafic important
ne soit pas interrompu.
Support multicast
: H.323 supporte le multicast dans les conférences multipoint.
Multicast envoie chaque paquet vers un sous-ensemble
des destinataires sans réplication, permettant une utilisation
optimale du réseau.
A l’heure actuelle,
le standard de fait pour les systèmes de téléphonie
sur IP est la norme H.323 de l’UIT. Indispensable pour
permettre un minimum d’interopérabilité entre équipements
de fournisseurs différents, ce standard présente toutefois
les inconvénients suivants :
Protocole complexe,
créé initialement pour les conférences multimédia et
qui incorpore des mécanismes superflus dans un contexte
purement téléphonique. Ceci a notamment des incidences
au niveau des terminaux H.323 (téléphones IP, par exemple)
qui nécessitent de ce fait une capacité mémoire et de
traitement non sans incidence au niveau de leur coût.
Comprend de nombreuses
options susceptibles d’être implémentées de façon différentes
par les constructeurs et donc de poser des problèmes
d’interopérabilité ou de plus petit dénominateur commun
(dans le choix du codec, par exemple) ; D’autre part,
comme le seul codec obligatoire est le codec G.711 (64
Kps) et que le support des autres codecs plus efficaces
est optionnel, l’interopérabilité entre produits provenant
de constructeurs différents ne signifie pas qu’ils feront
un usage optimal de la bande passante. En effet, dans
le cas où les codecs à bas débits sont différents, le
transport de la voix se fera à 64 Kbps, ce qui, en terme
de bande passante, ne présente guère d’avantages par
rapport à un système téléphonique classique.
6.1.6 - Comparaison avec Sip
Sip est un autre
protocole pour l’interactivité en temps réel. Il a été
développé par l’IETF et s’inspire du protocole Http
alors que H.323 s’inspire de la téléphonie. Sip est
plus modulaire et peut fonctionner avec d’autres protocoles.
Il est donc plus souple que H.323.
6.1.7 - Conclusion
Le protocole H.323
est une des normes envisageables pour la visioconférence
sur Ip. Cependant, elle est pour l’instant surtout employé
par des programmes propriétaires (Microsoft, etc.).
La documentation est difficile d’accès car l’ITU fait
payer les droits d’accès aux derniers développements
de cette technologie, en dehors des efforts faits par
le projet OpenH.323 pour rendre cette technologie accessible
à tous. Cet ensemble de normes ne s’avèrent pas toujours
compatibles avec d’autres protocoles à cause de son
développement inspiré de la téléphonie, ce qui peut
rendre son utilisation un peu "rigide".
6.2 - Protocole SIP
6.2.1 - Introduction
Le protocole Sip
(Session Initiation Protocole) a été initié par le groupe
MMUSIC (Multiparty Multimedia Session Control) et désormais
repris et maintenu par le groupe SIP de l'IETF donnant
la Rfc 3261 rendant
obsolète la Rfc
2543. Sip est un protocole de signalisation appartenant
à la couche application du modèle Osi.
Son rôle est d’ouvrir, modifier et libérer les sessions.
L’ouverture de ces sessions permet de réaliser de l’audio
ou vidéoconférence, de l’enseignement à distance, de
la voix (téléphonie) et de la diffusion multimédia sur
Ip essentiellement. Un utilisateur peut se connecter
avec les utilisateurs d’une session déjà ouverte. Pour
ouvrir une session, un utilisateur émet une invitation
transportant un descripteur de session permettant aux
utilisateurs souhaitant communiquer de s’accorder sur
la compatibilité de leur média, Sip permet donc de relier
des stations mobiles en transmettant ou redirigeant
les requêtes vers la position courante de la station
appelée. Enfin, SIP possède l’avantage de ne pas être
attaché à un médium particulier et est sensé être indépendant
du protocole de transport des couches basses.
6.2.2 - Fonctionnement
Sip intervient aux
différentes phases de l'appel :
Localisation du terminal
correspondant,
Analyse du profil
et des ressources du destinataire,
Négociation du type
de média (voix, vidéo, données…) et des paramètres de
communication,
Disponibilité du
correspondant, détermine si le poste appelé souhaite
communiquer, et autorise l’appelant à le contacter.
Etablissement et
suivi de l'appel, avertit les parties appelant et appelé
de la demande d’ouverture de session, gestion du transfert
et de la fermeture des appels.
Gestion de fonctions
évoluées : cryptage, retour d'erreurs, …
Avec Sip, les utilisateurs
qui ouvrent une session peuvent communiquer en mode
point à point, en mode diffusif ou dans un mode combinant
ceux-ci. Sip permet donc l’ouverture de sessions en
mode :
Point-à-point - Communication
entre 2 machines, on parle d’unicast.
Diffusif - Plusieurs
utilisateurs en multicast, via une unité de contrôle
M.C.U (Multipoint Control Unit)
Combinatoire - Plusieurs
utilisateurs pleinement interconnectés en multicast
via un réseau à maillage complet de connexions.
Voici les différents
éléments intervenant dans l'ouverture de session :
Suivant nature des
échanges, choix des protocoles les mieux adaptés (Rsvp,
Rtp, Rtcp, Sap, Sdp).
Détermination du
nombre de sessions, comme par exemple, pour véhiculer
de la vidéo, 2 sessions doivent être ouvertes (l’une
pour l’image et l’autre pour la vidéo).
Chaque utilisateur
et sa machine est identifié par une adresse que l’on
nomme Url Sip et qui se présente comme une Url Mailto.
Requête Uri permettant
de localiser le proxy server auquel est rattaché la
machine de l’appelé.
Requête Sip, une
fois le client (machine appelante) connecté à un serveur
Sip distant, il peut lui adresser une ou plusieurs requêtes
Sip et recevoir une ou plusieurs réponses de ce serveur.
Les réponses contiennent certains champs identiques
à ceux des requêtes, tels que : Call-ID, Cseq, To et
From.
Les échanges entre
un terminal appelant et un terminal appelé se font par
l’intermédiaire de requêtes :
Invite - Cette requête
indique que l’application (ou utilisateur) correspondante
à l’Url Sip spécifié est invité à participer à une session.
Le corps du message décrit cette session (par ex : média
supportés par l’appelant ). En cas de réponse favorable,
l’invité doit spécifier les médias qu’il supporte.
Ack - Cette
requête permet de confirmer que le terminal appelant
a bien reçu une réponse définitive à une requête Invite.
Options - Un proxy
server en mesure de contacter l'UAS (terminal) appelé,
doit répondre à une requête Options en précisant ses
capacités à contacter le même terminal.
Bye - Cette requête
est utilisée par le terminal de l’appelé à fin de signaler
qu’il souhaite mettre un terme à la session.
Cancel - Cette requête
est envoyée par un terminal ou un proxy server à fin
d’annuler une requête non validée par une réponse finale
comme, par exemple, si une machine ayant été invitée
à participer à une session, et ayant accepté l’invitation
ne reçoit pas de requête Ack, alors elle émet une requête
Cancel.
Register - cette
méthode est utilisée par le client pour enregistrer
l’adresse listée dans l’URL TO par le serveur auquel
il est relié.
Une réponse à une
requête est caractérisée, par un code et un motif, appelés
code d’état et raison phrase respectivement. Un code
d’état est un entier codé sur 3 bits indiquant un résultat
à l’issue de la réception d’une requête. Ce résultat
est précisé par une phrase, textbased (UTF-8), expliquant
le motif du refus ou de l’acceptation de la requête.
Le code d’état est donc destiné à l’automate gérant
l’établissement des sessions Sip et les motifs aux programmeurs.
Il existe 6 classes de réponses et donc de codes d’état,
représentées par le premier bit :
1xx = Information
- La requête a été reçue et continue à être traitée
2xx = Succès - L’action
a été reçue avec succès, comprise et acceptée
3xx = Redirection
- Une autre action doit être menée afin de valider la
requête
4xx = Erreur du client
- La requête contient une syntaxe éronnée ou ne peut
pas être traitée par ce serveur
5xx = Erreur du serveur
- Le serveur n’a pas réussi à traiter une requête apparemment
correcte
6xx = Echec général
- La requête ne peut être traitée par aucun serveur
Dans un système
Sip on trouve deux types de composantes, les users agents
(UAS, UAC) et un réseau de serveurs :
L’UAS (User Agent
Server) - Il représente l’agent de la partie appelée.
C’est une application de type serveur qui contacte l’utilisateur
lorsqu’une requête Sip est reçue. Et elle renvoie une
réponse au nom de l’utilisateur.
L’U.A.C (User Agent
Client) - Il représente l’agent de la partie appelante.
C’est une application de type client qui initie les
requêtes.
Le relais mandataire
ou PS (Proxy Server), auquel est relié un terminal fixe
ou mobile, agit à la fois comme un client et comme un
comme serveur. Un tel serveur peut interpréter et modifier
les messages qu’il reçoit avant de les retransmettre
:
Le RS (Redirect Server)
- Il réalise simplement une association (mapping) d’adresses
vers une ou plusieurs nouvelles adresses. (lorsqu’un
client appelle un terminal mobile - redirection vers
le PS le plus proche - ou en mode multicast - le message
émis est redirigé vers toutes les sorties auxquelles
sont reliés les destinataires). Notons qu’un Redirect
Server est consulté par l'Uac comme un simple serveur
et ne peut émettre de requêtes contrairement au Ps.
Le LS (Location Server)
- Il fournit la position courante des utilisateurs dont
la communication traverse les Rs et PS auxquels il est
rattaché. Cette fonction est assurée par le service
de localisation.
Le RG (Registrar)
- C'est un serveur qui accepte les requêtes Register
et offre également un service de localisation comme
le LS. Chaque PS ou RS est généralement relié à un Registrar.
6.2.3 - Sécurité et Authentification
Les messages Sip
peuvent contenir des données confidentielles, en effet
le protocole Sip possède 3 mécanismes de cryptage :
Cryptage de bout
en bout du Corps du message Sip et de certains champs
d’en-tête sensibles aux attaques.
Cryptage au saut
par saut (hop by hop) à fin d’empêcher des pirates de
savoir qui appelle qui.
Cryptage au saut
par saut du champ d’en-tête Via pour dissimuler la route
qu’a emprunté la requête.
De plus, à fin d’empêcher
à tout intrus de modifier et retransmettre des requêtes
ou réponses Sip, des mécanismes d’intégrité et d’authentification
des messages sont mis en place. Et pour des messages
Sip transmis de bout en bout, des clés publiques et
signatures sont utilisées par Sip et stockées dans les
champs d’en-tête Autorisation.
Une autre attaque connue avec Tcp ou Udp est le « deny
of service », lorsqu’un Proxy Server intrus renvoie
une réponse de code 6xx au client (signifiant un échec
général, la requête ne peut être traitée). Le client
peut ignorer cette réponse. Si il ne l’ignore pas et
émet une requête vers le serveur "régulier" auquel il
était relié avant la réponse du serveur "intrus", la
requête aura de fortes chances d’atteindre le serveur
intrus et non son vrai destinataire.
6.2.4 - Comparaison avec H323
Voici les avantages
du protocole H.323 :
Il existe de nombreux
produits (plus de 30) utilisant ce standard adopté par
de grandes entreprises telles Cisco, IBM, Intel, Microsoft,
Netscape, etc.
Les cinq principaux
logiciels de visioconférence Picturel 550, Proshare
500, Trinicon 500, Smartstation et Cruiser 150 utilisent
sur Ip la norme H.323.
Un niveau d’interopérabilité
très élevé, ce qui permet à plusieurs utilisateurs d'échanger
des données audio et vidéo sans faire attention aux
types de média qu'ils utilisent.
Voici les avantages
du protocole Sip :
Sip est un protocole
plus rapide. La séparation entre ses champs d’en-tête
et son corps du message facilite le traitement des messages
et diminue leur temps de transition dans le réseau.
Nombre des en-têtes
est limité (36 au maximum et en pratique, moins d'une
dizaine d'en-têtes sont utilisées simultanément), ce
qui allège l'écriture et la lecture des requêtes et
réponses.
Sip est un protocole
indépendant de la couche transport. Il peut aussi bien
s’utiliser avec Tcp
que Udp.
De plus, il sépare
les flux de données de ceux la signalisation, ce qui
rend plus souple l'évolution "en direct" d'une communication
(arrivée d'un nouveau participant, changement de paramètres…).
| |
SIP |
H323 |
| |
|
|
| Nombre
échanges pour établir la connexion |
1,5
aller-retour |
6
à 7 aller-retour |
| Maintenance
du code protocolaire |
Simple
par sa nature textuelle à l'exemple de Http |
Complexe
et nécessitant un compilateur |
| Evolution
du protocole |
Protocole
ouvert à de nouvelles fonctions |
Ajout
d'extensions propriétaires sans concertation
entre vendeurs |
| Fonction
de conférence |
Distribuée |
Centralisée
par l'unité MC |
| Fonction
de téléservices |
Oui,
par défaut |
H.323
v2 + H.450 |
| Détection
d'un appel en boucle |
Oui |
Inexistante
sur la version 1
un appel routé sur l'appelant provoque une infinité
de requêtes |
| Signalisation
multicast |
Oui,
par défaut |
Non |
6.2.5 - Conclusion
La simplicité, la
rapidité et la légèreté d’utilisation, tout en étant
très complet, du protocole Sip sont autant d’arguments
qui pourraient permettre à Sip de convaincre les investisseurs.
De plus, ses avancées en matière de sécurité des messages
sont un atout important par rapport à ses concurrents.
6.3 - Transport Rtp & Rtcp
6.3.1 - Introduction
Rtp est un protocole
qui a été développé par l’IETF afin de facilité le transport
temps réel de bout en bout des flots données audio et
vidéo sur les réseaux Ip, c’est à dire sur les réseaux
de paquets. Rtp est un protocole qui se situe au niveau
de l'application et qui utilise les protocoles sous-jacents
de transport Tcp ou Udp. Mais l'utilisation de Rtp se
fait généralement au-dessus de Udp ce qui permet d’atteindre
plus facilement le temps réel. Les applications temps
réels comme la parole numérique ou la visio-conférence
constitue un véritable problème pour Internet. Qui dit
application temps réel, dit présence d’une certaine
qualité de service (QoS) que Rtp ne garantie pas du
fait qu'il fonctionne au niveau Applicatif. De plus
Rtp est un protocole qui se trouve dans un environnement
multipoint, donc on peut dire que Rtp possède à sa charge,
la gestion du temps réel, mais aussi l’administration
de la session multipoint.
Rtp et Rtcp sont définis, depuis juillet 2003, par la
Rfc 3550 rendant
obsolète la version précédente Rfc 1889.
6.3.2 - Les fonctions de Rtp
Le protocole Rtp,
Real Time Transport Protocol, standardisé en 1996, a
pour but d’organiser les paquets à l’entrée du réseau
et de les contrôler à la sortie. Ceci de façon à reformer
les flux avec ses caractéristiques de départ. Rtp est
géré au niveau de l'application donc ne nécessite pas
l'implémentation d’un Kernel ou de librairies. Comme
nous l’avons dit dans l’introduction, Rtp est un protocole
de bout en bout. Rtp est volontairement incomplet et
malléable pour s'adapter aux besoins des applications.
Il sera intégré dans le noyau de l'application. Rtp
laisse la responsabilité du contrôle aux équipements
d'extrémité.
Rtp, est un protocole adapté aux applications présentant
des propriétés temps réel. Il permet ainsi de :
Reconstituer la base
de temps des flux (horodatage des paquets : possibilité
de resynchronisation des flux par le récepteur)
Mettre en place un
séquencement des paquets par une numérotation et ce
afin de permettre ainsi la détection des paquets perdus.
Ceci est un point primordial dans la reconstitution
des données. Mais il faut savoir quand même que la perte
d’un paquet n’est pas un gros problème si les paquets
ne sont pas perdus en trop grands nombre. Cependant
il est très important de savoir quel est le paquet qui
a été perdu afin de pouvoir pallier à cette perte. Et
ce par le remplacement par un paquet qui se compose
d’une synthèse des paquets précédent et suivant.
Identifier le contenu
des données pour leurs associer un transport sécurisé.
L’identification
de la source c’est à dire l’identification de l’expéditeur
du paquet. Dans un multicast l’identité de la source
doit être connue et déterminée.
Transporter les applications
audio et vidéo dans des trames (avec des dimensions
qui sont dépendantes des codecs qui effectuent la numérisation).
Ces trames sont incluses dans des paquets afin d’être
transportées et doivent de ce fait être récupérées facilement
au moment de la phase de dépaquétisation afin que l’application
soit décodée correctement.
En revanche, ce
n'est pas "la solution" qui permettrait d'obtenir des
transmissions temps réel sur IP. En effet, il ne procure
pas de :
Réservation de ressources
sur le réseau (pas d'action sur le réseau, cf. RSVP);
Fiabilité des échanges
(pas de retransmission automatique, pas de régulation
automatique du débit);
Garantie dans le
délai de livraison (seules les couches de niveau inférieur
le peuvent) et dans la continuité du flux temps réel.
6.3.3 - Entête Rtp
L'entête d'un paquet
Rtp est obligatoirement constitué de 16 octets. Cette
entête précède le "payload" qui représente les données
utiles.

6.3.3.1 - V
Ce champ, codé sur
2 bits, permet d'indiquer la version de Rtp. Actuellement,
V=2.
6.3.3.2 - P
Ce bit indique,
si il est à 1, que les données possèdent une partie
de bourrage.
6.3.3.3 - X
Ce bit spécifie,
si il est à 1, que l'entête est suivie d'une entête
supplémentaire.
6.3.3.4 - CC
Ce champ, codé sur
4 bits, représente le nombre de CSRC qui suit l'entête.
6.3.3.5 - M
Ce bit, lorsqu'il
est à 1, définie