Vous êtes sur la page 1sur 52

Un PABX (Private Automatic Branch eXchange) ou PBX en Anglais, est un autocommutateur privé, utilisé dans les entreprises pour

assurer les
communications internes et le lien avec le réseau téléphonique commuté global (Public Switched Telephone Network). Un PBX est capable de redirigé les
appels entrant vers un téléphone en particulier, ou de permettre aux téléphones de choisir une ligne en particulier pour passer un appel. Comme un routeur
sur internet est responsable de rediriger les paquets de données d'une source vers une ou plusieurs destinations, un PBX redirige les appels téléphoniques.

1.8. L'IPBX ou PABX - IP 

C'est un autocommutateur compatible avec la téléphonie sur IP. Il permet comme un commutateur téléphonique standard, d'établir une communication
téléphonique entre deux abonnés distants. A l'intérieur d'une entreprise, l'IPBX définit le routage des paquets pour que la communication parvienne au bon
poste de l'entreprise. Un PABX-IP peut être soit un autocommutateur auquel l'entreprise ajoute une carte d'extension IP, soit une machine nativement IP.
Un autocommutateur IP qui sert de serveur de messagerie, capable de stocker l'historique des communications ou éventuellement des messages. IPBX c'est
la dernière génération de PABX, il s'intègre à la téléphonie sur IP.

Figure 1 : Architecture avec un IPBX Asterisk d'un centre appel

1.9. Passerelles IP 


Les passerelles IP servent de liens entre les réseaux téléphoniques commutés (RTC) et les réseaux IP. Passerelle de voix sur IP est spécifiquement conçue
pour permettre aux messages vocaux provenant d'un réseau téléphonique traditionnel d'être transmis sur un réseau utilisant le protocole IP, tout en leur
offrant la possibilité d'effectuer le chemin inverse.

Figure 2 : Architecture d'un Passerelle IP

SECTION 2 : FONCTIONNEMENT

2.1. Principe

Le principe de la téléphonie sur IP est la numérisation de la voix, c'est-à-dire le passage d'un signal analogique à un signal numérique. Celui-ci est compressé
en fonction des codecs choisis, cette compression a comme but de réduire la quantité d'information qui est transmise sur le réseau. Le signal obtenu est
découpé en paquets, à chaque paquet on ajoute les entêtes propres au réseau (IP, UDP, RTP....) et pour finir il est envoyé sur le réseau.

A l'arrivée, les paquets transmis sont réassemblés en supprimant d'abord les entêtes. Le signal de données ainsi obtenu est décompressé puis converti en
signal analogique afin que l'utilisateur puisse écouter le message d'origine.

2.2. Architecture de transmission VoIP


La technologie de la voix sur IP (VoIP pour Voice over IP) nous présente une architecture découpée en 8 grandes étapes :

Figure 3 : 8 étapes de la voix à IP

2.2.1 Acquisition du signal


La VoIP suppose la transformation d'un signal continu analogique (la voix) en un signal discret numérique (composé d'une série de chiffres). La première
étape consiste naturellement à capter la voix à l'aide d'un micro, qu'il s'agisse de celui d'un téléphone ou d'un micro casque.

2.2.2 Numérisation

La voix passe alors dans un convertisseur analogique numérique qui réalise deux tâches distinctes :

· l'échantillonnage du signal sonore, c'est-à-dire un prélèvement périodique de ce signal ;

· la quantification, qui consiste à affecter une valeur numérique (en binaire) à chaque échantillon. Plus les échantillons sont codés sur un nombre de bits
important, meilleure sera la qualité (on parle de «résolution») de la conversion. Généralement, la voix est échantillonnée à 8 kHz et chaque échantillon est
codé sur 8 bits, ce qui donne un débit de 64 kbit/s (norme G711).

2.2.3 Compression

Le signal une fois numérisé peut être traité par un DSP (Digital Signal Processor) qui va le compresser, c'est-à-dire réduire la quantité d'informations (bits)
nécessaire pour l'exprimer. Plusieurs normes de compression et décompression (Codecs) sont utilisées pour la voix. L'avantage de la compression est de
réduire la bande passante nécessaire pour transmettre le signal.

2.2.4 Habillage des en-têtes

Les données «brutes» qui sortent du DSP doivent encore être enrichies en informations avant d'être converties en paquets de données à expédier sur le
réseau. Trois «couches» superposées sont utilisées pour cet habillage :

La couche IP

La couche IP correspond à l'assemblage des données en paquets. Chaque paquet commence par un en-tête indiquant le type de trafic concerné, ici du trafic
UDP.

La couche UDP
La deuxième couche, UDP, consiste à formater très simplement les paquets. Si l'on restait à ce stade, leur transmission serait non fiable : UDP ne garantit ni
le bon acheminement des paquets, ni leur ordre d'arrivée.

La couche RTP (Real Time Protocol) / RTCP (Real Time Control Protocol)

Pour palier l'absence de fiabilité d'UDP, un formatage RTP est appliqué de surcroît aux paquets. Il consiste à ajouter des entêtes d'horodatage et de
synchronisation pour s'assurer du réassemblage des paquets dans le bon ordre à la réception. RTP est souvent renforcé par RTCP qui comporte, en plus, des
informations sur la qualité de la transmission et l'identité des participants à la conversation.

2.2.5 Emission et transport

Les paquets sont acheminés depuis le point d'émission pour atteindre le point de réception sans qu'un chemin précis soit réservé pour leur transport. Ils
vont transiter sur le réseau (réseau local, réseau étendu voire Internet) en fonction des ressources disponibles et arriver à destination dans un ordre
indéterminé.

2.2.6 Réception

Lorsque les paquets arrivent à destination, il est essentiel de les replacer dans le bon ordre et assez rapidement. Faute de quoi une dégradation de la voix se
fera sentir. Ce point sera détaillé plus loin.

2.2.7 Conversion numérique analogique

La conversion numérique analogique est l'étape réciproque de l'étape 2, qui permet de transformer les données reçues sous forme de série discrète en un
signal électrique «continu».

2.2.8 Restitution

Dès lors, la voix peut être retranscrite par le haut-parleur du casque, du combiné téléphonique ou de l'ordinateur.

Section 3. MODES D'ACCES ET ARCHITECTURE

3.1. Les modes d'accès


Selon le type de terminal utilisé (un ordinateur ou un téléphone classique), on distingue trois modes d'accès possibles de voix sur IP :

· La voix sur IP entre deux ordinateurs

· La voix sur IP entre un ordinateur et un téléphone

· La voix sur IP entre deux téléphones

Il est nécessaire de rappeler aux utilisateurs qu'ils doivent être dans le même réseau IP (Internet ou Intranet de l'entreprise).

3.1.1. La voix sur IP entre deux ordinateurs

Figure 5 : Voix sur IP entre deux ordinateurs

C'est le cas le plus simple. Il suffit de disposer d'une carte son, de haut-parleurs et de microphones pour chacun des interlocuteurs. Il faut également
connaître l'adresse IP de chacun des terminaux pour établir la communication.

Dans ce premier type de voix sur IP, les utilisateurs communiquent à partir d'un logiciel de voix sur IP qu'on appel soft phone.

3.1.2 La voix sur IP entre un PC et un téléphone


Figure 6 : Voix sur IP entre PC et un téléphone

Ce cas nécessite une conversion des signaux entre le RTC et le réseau IP. En effet, ces deux terminaux utilisant des technologies différentes (la commutation
de circuits et la commutation de paquets), l'échange des informations nécessite une passerelle. L'utilisateur possédant un ordinateur et désirant appeler
l'autre sur son téléphone doit se connecter à un service spécial sur Internet, offert par un fournisseur de service (un ISP) ou par son fournisseur d'accès à
Internet (son IAP).

3.1.3 La voix sur IP entre deux téléphones


Figure 7 : Voix sur IP entre deux téléphones

C'est le cas le plus complexe car il nécessite deux conversions de signaux. On utilise des passerelles analogues entre le réseau téléphonique et le réseau. Un
utilisateur appelle le numéro d'une passerelle et lui communique le numéro du correspondant qu'il cherche à joindre.

SECTION 4 : LES PROTOCOLES DE SIGNALISATION

Un protocole est un langage commun utilisé par l'ensemble des acteurs de la communication pour échanger des données. Toutefois son rôle ne s'arrête pas
là. Un protocole permet aussi d'initialiser la communication, d'échanger de données. Il faut distinguer plusieurs types de protocoles :

· Les protocoles de signalisation,

· Les protocoles de transport de la voix.

Les protocoles signalétiques, ont la charge de régir les communications, de déterminer les appelés, de signaler les appelants, de gérer les absences, les
sonneries etc... Mais aussi de négocier quel codec pourra être utilisé.
Les protocoles de transport quand à eux, transportent l'information sur un réseau IP. Ce type de protocoles est spécifique à la voix sur IP et aux applications
nécessitant le transit de l'information en temps réel comme par exemple, la vidéo conférence.

La Norme H323, SIP et MGCP, sont des normes dont les spécifications doivent être respectées par les appareils de téléphonie sur IP pour assurer
l'interopérabilité.

Notre étude sera basée sur les protocoles les plus utilisés : H323, SIP et IAX2

4.1. Le protocole H 323

H323 est en ensemble de protocole utilisé en voix sur IP. Il a été développé par l'Union International des Télécoms (ITU). H323 est une dénomination pour
désigner un ensemble de protocoles, qui peuvent être regroupé en trois catégories : signalisation, négociation et transport.

Lors d'un appel, il est utilisé en premier lieu le protocole H225 pour la signalisation de l'appel. Puis vient le H245 pour la négociation, et enfin le RTP pour le
transport de la voix. Ces trois protocoles sont de couches 5 et reposent sur le protocole TCP pour les deux premiers et UDP pour le dernier.
Figure 6 : Pile de protocole H323

4.2. Le protocole SIP

Session Initiation Protocol (SIP) est un protocole développé par l'Internet Engineering Task Force (IETF) permettant la négociation et l'établissement de
sessions VoIP. SIP est un protocole de couche 5 du modèle OSI, dite de session. Il s'appuie généralement sur une couche de transport UDP, bien qu'il soit
possible d'augmenter sa fiabilité en l'appliquant sur du TCP. Le port par défaut de SIP est le 5060. SIP ne traite que l'établissement de session. Il ne
transporte pas les données échangées pendant la communication, ce rôle étant joué par RTP (Real-time Transport Protocol). On distingue différents acteurs
dans le protocole SIP. Le plus évident est le User Agent. Il peut s'agir d'un téléphone IP, d'un téléphone analogique relié à un boîtier ATA (Analog Telephony
Adapter) ou encore d'un softphone. C'est l'équipement manipulé par l'usager. Un élément fondamental est le Registrar Server. Il établit la correspondance
entre une adresse à long terme (une URI ou un numéro de téléphone) et une adresse à court terme, typiquement une adresse IP.

Le dernier élément très important d'une architecture SIP est le serveur proxy. Il relaye les messages des User Agents à leur destination. Sa raison d'être est
que les User Agent ne peuvent pas toujours joindre directement les autres périphériques, notamment les User Agent hors de leur réseau.

Les messages utilisés par SIP sont volontairement similaires à ceux utilisés par le HTTP. Ils sont codés en ASCII et utilisent des codes proches de ceux du
HTTP. Différents messages sont utilisés par SIP, les plus importants étant les suivants :

· REGISTER : Le client envoie ce message à son registrar pour s'enregistrer, c'est-à-dire pour donner son URI et son adresse IP au registrar.

· INVITE : Ce message permet à un client de demander l'établissement d'une nouvelle session. Il peut être utilisé également en cours de communication
pour modifier la session.

· ACK : Le message ACK confirme l'établissement d'une session SIP, suite à un message INVITE.

· CANCEL : Ce message annule une demande de session précédemment effectuée avec un INVITE.

· BYE : termine une session en cours. Contrairement au message CANCEL, la session SIP doit être active pour pouvoir envoyer un message BYE. Même si son
comportement peut sembler similaire à CANCEL, une différence fondamentale existe : le message BYE représente un succès (la communication a eu lieu et
est désormais terminée) alors que CANCEL est, du point de vue de l'usager, un échec : l'appelé n'a pas répondu à temps, l'appelant a donc raccroché, la
session n'a donc pas abouti.

· Des codes de réponse : Des codes à trois chiffres, similaires à ceux du HTTP, sont envoyés en réponse à un précédent message. Le premier chiffre
détermine le type de réponse, les deux suivants donnent une indication plus précise.

1xx - Réponse temporaire : la requête est en cours de traitement.

2xx - Succès : l'action demandée a été reçue, comprise et acceptée.

3xx - Redirection : une autre action auprès d'un autre équipement est nécessaire.
4xx - Erreur du client : la requête est mal formée

5xx - Erreur du serveur : le serveur n'a pas réussi à répondre correctement à la requête.

6xx - Autre erreur, problème global.

4.2.1 Les avantages et inconvénients du protocole SIP

Les avantages

L'implémentation de la VoIP avec le protocole de signalisation SIP (Session Initiation Protocol) fournit un service efficace, rapide et simple d'utilisation. SIP
est un protocole rapide et léger.

Les utilisateurs s'adressent à ces serveurs Proxy pour s'enregistrer ou demander l'établissement de communications. On peut s'enregistrer sur le Proxy de
son choix indépendamment de sa situation géographique. L'utilisateur n'est plus "attaché" à son autocommutateur. Une entreprise avec plusieurs centaines
d'implantations physiques différentes n'a besoin que d'un serveur Proxy quelque part sur l'Internet pour établir "son" réseau de téléphonique "gratuit" sur
l'Internet un peu à la manière de l'émail.

Les inconvénients

L'une des conséquences de cette convergence est que le trafic de voix et ses systèmes associés sont devenus aussi vulnérables aux menaces de sécurité que
n'importe quelle autre donnée véhiculée par le réseau.

En effet SIP est un protocole d'échange de messages basé sur HTTP. C'est pourquoi SIP est très vulnérable face à des attaques de types DoS (dénis de
service), détournement d'appel, trafic de taxation, etc.

4.2.2 Etude comparative entre SIP et H3233

Les deux protocoles SIP et H323 représentent les standards définis jusqu'à présent pour la signalisation à propos de la téléphonie sur Internet. Ils présentent
tous les deux des approches différentes pour résoudre un même problème.

H323 est basé sur une approche traditionnelle du réseau à commutation de circuits. Quant à SIP, il est plus léger car basé sur une approche similaire au
protocole http. Tous les deux utilisent le protocole RTP comme protocole de transfert des données multimédia.
Au départ H323 fut conçu pour la téléphonie sur les réseaux sans QoS, mais on l'adopta pour qu'il prenne en considération l'évolution complexe de la
téléphonie sur internet.

La complexité de H323 provient encore du fait de la nécessité de faire appel à plusieurs protocoles simultanément pour établir un service, par contre SIP n'a
pas ce problème.

Les nouvelles versions de H323 doivent tenir compte des anciennes versions pour continuer à fonctionner. Ceci entraîne pour H323 de garder un peu plus
de codecs pour chaque version. H323 ne reconnaît que les Codecs standardisés pour la transmission des données multimédias proprement dit alors que SIP,
au contraire, peu très bien en reconnaître d'autres. Ainsi, on peut dire que SIP est plus évolutif que H323.

4.2.3. Déroulement d'un appel téléphonique sous SIP

Pour initier une session SIP, la procédure est la suivante. les messages ne transitent pas par un proxy mais sont envoyés directement au User Agent
concerné. L'appelant envoie un INVITE à l'appelé. Au moyen du protocole SDP, il indique dans sa requête quels médias il souhaite échanger audio/vidéo) et
les codecs qu'il prend en charge.

L'appelé lui indique qu'il traite la requête par un code de réponse "100 rying". Une fois la requête traitée, il envoie un code "180 Ringing" pour indiquer que
le téléphone appelé est en train de sonner. Les réponses 100 et 180 sont généralement envoyées à quelques millisecondes d'intervalle seulement. Pour
comprendre la réelle utilité du message "100 Trying", il faut considérer le cas ou l'appelé à besoin de plus de temps pour traiter la requête, par exemple s'il
doit demander une autorisation avant d'accepter l'appel.

Lorsque l'usager appelé répond, une réponse définitive est envoyée à l'appelant dans une message "200 OK". Ce message contient des informations de
sessions grâce à SDP. Contrairement au SDP du message INVITE, celui-ci ne contient qu'un seul codec car l'appelé a choisi le plus approprié dans la liste
proposée par l'appelant.

L'appelant termine par un message ACK, indiquant que la session est établie et que les deux parties sont maintenant en communication.

4.3. Le protocole IAX

Le protocole d'Echange Inter-Asterisk (Inter-Asterisk eXchange, IAX) version 2 (IAX2) propose une alternative aux protocoles de signalisation tels que SIP.
IAX2 a été crée dans le cadre du projet de PBX Open source Asterisk. Contrairement à SIP qui utilise 2 paires de flux (l'une pour la signalisation, l'autre pour
la voix), IAX utilise une seule paire de flux pour communiquer entre les extrémités de la ligne (téléphone ou central téléphonique). La signalisation comme
les données (la conversation vocale) sont transmises sur le même canal, par opposition à SIP qui utilise un second canal («  out-of-band ») pour les flux de
données (RTP) transportant la voix.

De  plus, IAX2  permet  à plusieurs   appels  d'être   rassemblés  dans  un  seul   ensemble  de paquets   IP, puisque qu'un seul paquet peut transporter des
informations concernant plusieurs appels en cours.

Ce mécanisme se nomme « trunking ». Avec IAX2, le « trunking » permet des économies de bande passante. Le concept de « trunking » nous l'expliquons
comme ceci : imaginez que vous ayez à envoyer cinq lettres à des destinataires vivant dans un autre pays. Vous pouvez utiliser une enveloppe par lettre, ou
inclure les cinq lettres dans une seule enveloppe et inclure le nom du destinataire final en première ligne de chacune des lettres. Le «  trunking » opère de
façon similaire et permet d'envoyer plusieurs lettres (appels) dans une seule enveloppe (paquet IP). En résumé, IAX2 présente les caractéristiques
suivantes :

Minimise la bande passante par appel

Réduit la consommation de bande passante pour un ensemble d'appels (par l'utilisation du « trunking »).

En bref, 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 nous
permettre d'opter pour son choix. De plus, ses avancées en matière de sécurité des messages sont un atout important par rapport à ses concurrents.

SECTION 5 : LES CODECS

Codec est une abréviation pour Codeur/Décodeur. Un codec est basé sur un algorithme qui permet la compression des données qu'on lui donne. Il s'agit
d'un procédé permettant de compresser et de décompresser un signal, de l'audio ou de la vidéo, le plus souvent en temps réel, permet une réduction de la
taille du fichier original. Le codec numérise et compresse la voix de l'émetteur, ainsi les données numériques sont encapsulées dans des paquets IP et
acheminées vers le destinataire. A l'arrivés au destinataire, ce dernier grâce au même codec décompresse et restitue le son. Il On distingue des codecs à
pertes et codecs sans pertes. Un codec à pertes distingue les parties moins importantes des informations et les supprime pour gagner en taille.

Une fois le signal numérisé et encodé, il est prêt à être transmis. Le transport des données peut se faire par l'intermédiaire de plusieurs protocoles dont
notamment RTP et RTCP, le contrôle du flux se faisant via les autres protocoles nommés plus haut. Arrivé du coté du récepteur, le signal est décodé en
utilisant le même codec et ensuite restitué.
L'objectif d'un codec est la transformation d'un signal analogique vers un signal numérique et vice-versa. Ici, le codec transforme donc le signal de la voix en
données numériques facilement transportables sur un réseau. Après de transport, le même codec se charge de reconvertir le signal numérique vers un
signal analogique.

Il existe une différence majeure permettant de classer les codecs existants dans deux catégories : les codecs sans pertes (lossless) et les codecs avec pertes
(lossy).

Dans un codec lossless, tout le signal est transformé en binaire et le décodage restitue des données parfaitement identiques à celles données en entrée. Ce
type de codecs est utilisé quand la qualité de la restitution est importante.

Dans un codec lossy, certaines parties du signal sont écartées et supprimées. Dans l'exemple de la voix, l'oreille humaine rencontre ses limites lorsqu'il s'agit
d'écouter des fréquences trop basses ou trop hautes. Les codecs avec pertes (aussi appelés destructeurs) tirent parti de ce phénomène. Les sons dans les
fréquences hautes ou basses sont tronqués pour diminuer la quantité d'information à transmettre. L'exploitation des particularités de l'oreille humaine
s'appelle la psycho acoustique.

- Qualité de la voix :

Dans la téléphonie sur IP, les différents codecs retransmettent plus ou moins bien le signal original. Pour mesurer la qualité de la voix restituée, on parle de
score MOS (Mean Opinion Score). C'est une note comprise entre 1 et 5 et attribuée par des auditeurs jugeant de la qualité de ce qu'ils entendent. Pour la
VoIP, plusieurs codecs peuvent servir. Voici leurs détails :

G.711 : Ce codec est le premier à avoir été utilisé dans la VoIP. Même si il existe maintenant des codecs nettement plus intéressants, celui ci continue d'être
implémenté dans les équipements à des fins de compatibilité entre marques d'équipements différentes.

G.722 : A la différence du G.711, ce codec transforme le spectre jusqu'à 7kHz ce qui restitue encore mieux la voix. Les débits que ce codec fournit sont 48,56
ou 64kbit/s. Une des particularités est de pouvoir immédiatement changer de débit. Ceci est fortement appréciable lorsque la qualité du support de
transmission se dégrade.

G.722.1 : Dérivé du codec précédent, celui ci propose des débits encore plus faibles (32 ou 24kbit/s). Il existe même des versions propriétaires de ce codec
fournissant un débit de 16kbit/s.
G.723.1 : C'est le codec par défaut lors des communications à faible débit. Deux modes sont disponibles. Le premier propose un débit de 6,4kbit/s et le
deuxième un débit de 5,3kbit/s.

- Compression du silence :

Une des méthodes utilisées par les codecs pour réduire la quantité de données à transmettre et de détecter les silences. Dans une conversation
téléphonique, chaque locuteur ne parle que 1/3 du temps en moyenne. Ce qui fait que 1/3 du temps d'une conversation est constitué de silence facilement
reproductible et donc non codé par le codec. Ce mécanisme s'appelle VAD (Voice Activity Détection - DAV : Détection d'activité de la voix).

- Génération de bruits de confort :

Pendant une conversation où les silences sont effacés, l'absence de bruit chez le récepteur peut vite se révéler inconfortable. Dans cette optique, les codecs
disposent d'un générateur de bruits de confort visant à simuler des bruits de fond pour améliorer le confort des utilisateurs.

- Robustesse sur la perte de paquets :

Si les conditions de circulations sur le réseau se dégradent, certains paquets contenant de l'information peuvent se perdrent ou arriver trop tard. Ce
problème est en partie compensé par l'utilisation des buffers, mais la gigue peut être telle que le codec soit obligé de retransmettre au récepteur un paquet,
alors qu'il n'est pas arrivé. Il existe plusieurs méthodes pour palier à ce problème : Il est possible par exemple de simplement répéter le contenu du dernier
paquet pour combler le vide. On peut aussi répartir l'information sur plusieurs paquets de façon à introduire une redondance des données. En cas de pertes
de paquets, le codec dispose ainsi d'une copie du paquet à retransmettre.

SECTION 6 : LES CONTRAINTES DE LA TELEPHONIE SUR IP

La téléphonie est un service vital pour l'entreprise, les questions de qualité de service QoS « quality of service » sont donc particulièrement importantes.

La QoS a pour vocation d'assurer la disponibilité de la téléphonie en tout temps et d'assurer une transmission des conversations dans de bonnes conditions.
La qualité du transport de la voix est affectée par les paramètres suivants :

Ø La qualité du codage

Ø Le délai d'acheminement (delay)


Ø La gigue (jitter)

Ø La perte de paquets (packet loss)

Ø L'écho

Toutes ces contraintes déterminent la QoS (Quality of Service ou Qualité de service en français). Le transport de la voix sur IP implique l'utilisation de
nombreux protocoles : RTP, RTCP, H245, H225,...

Des normes ont vu le jour afin que les équipements de différentes entreprises puissent communiquer entre eux. Le premier fut H.323, puis arriva la norme
SIP.

Qualité du codage

Généralement, plus le taux de compression est élevé par rapport à la référence de 64 Kb/s (G711), moins la qualité de la voix est bonne. Toutefois, les
algorithmes de compression récents permettent d'obtenir des taux de compression élevés, tout en maintenant une qualité de la voix acceptable.

L'acceptabilité par l'oreille humaine des différents algorithmes est définie selon le critère MOS (Mean Operationnal Score), défini par l'organisme de
normalisation internationale ITU (International Télécommunication Union / Union internationale des Télécommunications). Dans la pratique, les deux
algorithmes les plus utilisés sont le G.729 et le G.723.1.

Le tableau ci-après montre une liste de codecs avec leur débit correspondant :

Nom du codec Débit

G.711 64kbps

G.726 32kbps

G.726 24kbps

G.728 16kbps
G.729 8kbps

G.723.1 MPMLQ 6.3 kbps

G.723.1 ACELP 5.3k kbps

Tableau n°1: Correspondance entre les débits et les codecs

Délai d'acheminement : latence (Delay)

Selon la norme ITU G114, le délai d'acheminement permet :

- Entre 0 et 150 ms, une conversation normale

- Entre 150 et 300 ms, une conversation de qualité acceptable

- Entre 300 et 700 ms, uniquement une diffusion de voix en half duplex (mode talkie-walkie)

- Au-delà, la communication n'est plus possible

Précisons que le budget temps (latence) est une combinaison du délai dû au réseau et du délai lié au traitement de la voix par le codec (algorithmes de
compression/décompression de la voix). Dans la pratique, si l'on enlève le temps dû aux algorithmes de compression, il est impératif que le réseau achemine
la voix dans un délai de 100 à 200 ms. Or, la durée de traversée d'un réseau IP est dépendante du nombre de routeurs traversés ; le temps de traversée d'un
routeur étant lui-même fonction de la charge de ce dernier qui fonctionne par file d'attente.

Gigue (Jitter)

La gigue (variation des délais d'acheminement des paquets voix) est générée par la variation de charge du réseau (variation de l'encombrement des lignes
ou des équipements réseau) et donc à la variation de routes dans le réseau. Chaque paquet est en effet susceptible de transiter par des combinaisons
différentes de routeurs entre la source et la destination. Pour compenser la gigue, on peut utiliser des buffers (mémoire tampon) côté récepteur, afin de
reconstituer un train continu et régulier de paquets voix.

Toutefois, cette technique a l'inconvénient de rallonger le délai d'acheminement des paquets. Il est donc préférable de disposer d'un réseau à gigue limitée.

Perte de paquets (packet loss)

Lorsque les routeurs IP sont congestionnés, ils libèrent automatiquement de la bande passante en se débarrassant d'une certaine proportion des paquets
entrants en fonction de seuils prédéfinis.

La perte de paquets est préjudiciable, car il est impossible de réémettre un paquet voix perdu, compte tenu du temps dont on dispose. Le moyen le plus
efficace de lutter contre la perte d'informations consiste à transmettre des informations redondantes (code correcteur d'erreurs), qui vont permettre de
reconstituer l'information perdue. Des codes correcteurs d'erreurs, comme le Reed Solomon, permettent de fonctionner sur des lignes présentant un taux
d'erreur de l'ordre de 15 ou 20 %. Une fois de plus, ces codes correcteurs d'erreurs présentent l'inconvénient d'introduire une latence supplémentaire.

Certains, très sophistiqués, ont une latence très faible.

Echo

L'écho est un phénomène lié principalement à des ruptures d'impédance lors du passage de 2 fils à 4 fils. Le phénomène d'écho est particulièrement
sensible à un délai d'acheminement supérieur à 50 ms. Il est donc nécessaire d'incorporer un équipement ou logiciel qui permet d'annuler l'écho.

CHAPITRE II : LES SOLUTIONS LOGICIELS LIBRES

II.1. DEFINITION

II.1.1. Logiciels libres

Un logiciel libre est un logiciel dont l'utilisation, l'étude, la modification, la duplication et la diffusion sont universellement autorisées sans contrepartie.

Le logiciel libre a fait une incursion remarquée dans le monde de la téléphonie, par le biais de solutions PC-PBX (un ordinateur de type PC muni de cartes
d'interface spécifiques) tournant sous Linux (ou un autre système libre) et équipées de logiciels Open source comme Asterisk, Yate, VOCAL, etc. Nous
décrivons ici les forces et faiblesses de ces différentes plateformes afin de choisir en fonction des besoins exprimés, la solution qui sera implémentée.
II.1.2. Asterisk

Asterisk est un PABX logiciel libre, multiplateforme, publié sous licence GPL par Mark Spencer de la société Digium. Asterisk permet, entre autres, la
messagerie vocale, la conférence, les serveurs vocaux, la distribution des appels. Asterisk implémente les protocoles H323 et SIP, ainsi qu'un protocole
spécifique nommé IAX (Inter-Asterisk eXchange). Ce protocol IAX permet la communication entre client et serveur Asterisk ainsi qu'entre deux serveurs
Asterisk. Asterisk peut également jouer le rôle de registrar et passerelle avec les
réseaux publics (RTC, GSM, etc.).(12(*))

Architecture interne

Figure 6 : architecture interne d'Asterisk


Asterisk est un système flexible grâce à sa structure interne constitué de quatre APIs (Application Programming Interface) spécifiques autour du « central
core system ». Celui-ci manie les connexions internes du PBX en faisant abstraction des protocoles, des codecs, des interfaces téléphoniques et des
applications (d'où la possibilité d'utiliser n'importe quel hardware et n'importe quelle technologie).

Asterisk joue le rôle de middleware (intergiciel) entre les technologies de téléphonie et les applications (conférence, messagerie vocale, IVR).

Le coeur contient 5 moteurs ayant chacun un rôle essentiel et critique dans les opérations :

- La commutation de PBX (PBX Switching Core) : fonction primaire, commute de manière transparente les appels.

- Lanceur d'applications (Application Launcher) : lance les applications qui exécutent des services pour les utilisateurs.

- Traducteur de codec (Codec Translator) : code et décode la voix, plusieurs codecs sont utilisés pour trouver l'équilibre entre la qualité audio et l'usage de la
bande passante.

- Planificateur Manager d'I/O (Scheduler and I/O Manager) : planifie en bas niveau et gère les entrées/sorties pour des performances optimales.

- Dynamic Module Loader : charge les pilotes (lors de la 1ère exécution d'Asterisk, il initialise les pilotes et fait le lien avec les APIs appropriés). Après que les
pilotes soient chargés (DML), les appels commencent à être acceptés (PBXSC) et redirigés en faisant sonner les téléphones (AL).

L'abstraction matérielle et protocolaire passe par l'utilisation de 4 APIs :

1. L' API Canal (Asterisk Channel API)

Cette API gère le type de raccordement sur lequel arrive un appelant, que ce soit une connexion VoIP, un RNIS, ou une autre technologie.

2. L' API application (Asterisk Application API)

Elle autorise différents modules de tâches à être lancé pour exécuter diverses fonctions. Communication, audio-conférence, messagerie vocale et n'importe
quelle autre tâche qu'un système PBX standard exécute actuellement, sont mises en oeuvre par ce module.

3. L'API traducteur de Codec (Codec Translator API)

Charge les modules de codec pour supporter divers formats de codage et de décodage audio tels que le GSM, la Mu-Law, l'A-Law, et même le MP3.
4. L'API de format de fichier (Asterisk File Format API)

Elle permet la lecture et l'écriture de divers formats de fichiers pour le stockage de données dans le file system.

En utilisant ces APIs Asterisk réalise une abstraction complète entre ces fonctions noyau de serveur PBX et les diverses technologies existantes (ou en
développement) dans le domaine de la téléphonie.

II.1.3. Les terminaisons d'Asterisk

AsteriskGUI et Free PBX

AsteriskGUI, GUI pour Graphique User Inter face (Inter face utilisateur graphique) se trouve être une inter face graphique et l'outil d'administration
d'AsteriskNOW. Free PBX est aussi une interface d'administration créée pour la gestion des serveurs Asterisk. Ces interfaces permettent à chacun de
simplifier l'utilisation et l'administration de votre IPBX en le rendant plus accessible.

Asterisk at Home

Cette déclinaison d'Asterisk est destinée à être intégré au sein de très petites structures comme les réseaux domestiques. L'objectif de cette distribution est
de simplifier l'intégration d'un serveur de téléphonie sur IP et de proposer une version light d'Asterisk sous forme de package.

Asterisk for Windows

Cette plate-forme d'Asterisk est une déclinaison destinée à permettre la mise en oeuvre de la solution Asterisk sous Windows pour les allergiques à Linux.
Cette déclinaison dispose des mêmes fonctionnalisées que ses homologues sous linux.

SipXecs

SipXecs est une solution IPBX gratuite pouvant être mise en oeuvre au sein d'infrastructure de différentes tailles. Elle peut être intégrée dans des
infrastructures de très petites tailles à des infrastructures allant jusqu'à 6000 d'après les développeurs de la communauté. Ce produit a pour particularité de
supporter uniquement le protocole SIP.
SipXecs doit sa création à la société Pingtel Corp qui réalisa le développement du produit en 1999. Ce produit a été développé à par tir des langages C/C++ et
basé sur une interface d'administration WEB afin de réaliser la gestion des différents services offerts par le produit tel que le plan de numérotation, les
utilisateurs ou bien les téléphones. Il permet une intégration complète d'un système de messagerie unifié pour Microsoft Outlook.

CallWeaver

CallWeaver est un IPBX qui a été développé autour du projet Asterisk. Ce produit est basé sur une licence de type GPL. Callweaver est capable de s'interfacer
sur plusieurs types de réseaux, tel que le raccordement à un réseau téléphonique traditionnel ou IP. Ce produit a été conçu de sorte à ce qu'il puisse gérer
un ensemble de protocoles de signalisation de Voix sur IP (H323, IAX2, MGCP, SIP...). Call weaver permet d'administrer le serveur, comme une inter face
WEB plus simple pour les adeptes de l'interface graphique.

La version stable actuellement en ligne de Callweaver est la version 1.2.0.1. Ci-dessous une présentation des principales caractéristiques de l'outil :

· Interconnexion au réseau RTC (FXS/FXO, ISDN, PRI , E1, T1),

· Gère plusieurs protocoles de Voix sur IP (H.323, IAX2, MGCP and SIP and SCCP),

· Supporte le protocole STUN pour les communications SIP,

· Support du FAX via T.38. (Fax over IP),

· Serveur vocal interactif,

· Gestion des conférences,

· Gestion des fils d'attentes.


FreeSwitch

Freeswitch est une solution Open source de téléphonie sur IP, sous une licence MPL (Mozilla Public License), développé en C. Elle permet la mise en place de
communications vers un téléphone virtuel via un commutateur virtuel. Freeswitch peut être utilisé comme un simple commutateur, un PBX, une passerelle
ou un serveur d'applications IVR (Interactive Voice Response) en utilisant des scripts ou des fichiers XML permettant d'automatiser certaines taches et de
développer de nouveaux services.

Freeswitch fonctionne sur plusieurs systèmes d'exploitation, notamment Windows, Mac OS X, Linux, BSD et sur les deux plates-formes Solaris (32 bits et 64
bits). Une Inter face Web pour Freeswitch est disponible sous le nom Wiki PBX.

La configuration de Freeswitch peut s'effectuer de deux manières :

· En ligne de commande (CLI),

· En Inter face graphique (Web).

GNU Bayonne

GNU Bayonne est le serveur d'applications téléphoniques du projet GNU, c'est-à-dire orienté Open source basé sur une licence libre. Cette solution offre un
environnement gratuit permet tant aux petites et grandes infrastructures de développer, de déployer et de gérer des solutions de téléphonie intégrées à
leur réseau informatique afin d'exploiter une ou plusieurs lignes téléphoniques.

GNU Bayonne2 permet de développer des applications IVR (Interactive Voice Response) grâce à un simple langage de script. La version 1.x gère la VoIP grâce
au couplage avec le logiciel GNU oSIP Stack. GNU Bayonne se décline sous deux versions :

· Bayonne 1 : version développée en 1998 pour succéder au système ACS,

· Bayonne 2 : version développée en 2005 avec un accent particulier sur l'utilisation du protocole SIP.
Bayonne est basé sur le projet ACS (Adjunct Communication Server). Le projet ACS a été repris par le projet GNU qui oeuvre pour développer un système
d'exploitation et des logiciels complètements gratuits basés sur Unix. Le nom Bayonne vient du nom du célèbre pont qui relie la ville de Bayonne dans le
New Jersey avec l'île de Staten Island dans l'état de New York. L'auteur a ainsi voulu montrer que son logiciel était un pont entre le monde de l'informatique
et le monde de la téléphonie. Bayonne ne possède pas de fonction IP-PBX dans sa version 1. La version 2, prend en compte cet te fonctionnalité. Ce projet
étant peu suivi par la communauté Internet, il est très difficile donc de trouver de la documentation. Actuellement GNU Bayonne est un projet de petite
envergure mais il a le mérite d'avoir fait partie des précurseurs dès 1998.

Le fonctionnement de GNU Bayonne repose sur plusieurs composants que l'on doit lui associer pour pouvoir l'exploiter et le mettre en place.

· GNU Common C++,

· GNU ccScript (Machine virtuelle),

· GNU ccAudio (Gestion des flux audio),

· GNU oSIP Stack (Pile SIP),

· Libhoard (librairie additionnelle),

· Voicetronix PCI (pilote).

Bayonne dispose d'un interpréteur de scripts qui peut être étendu grâce à des applications TGI (Telephony Gateway Inter face), c'est-à-dire une Passerelle
d'Interfaçage Téléphonique permet tant de simplifier l'intégration de GNU Bayonne.

La solution peut être utilisée aujourd'hui complètement sous GNU/Linux avec une variété grandissante de matériels téléphoniques compatibles. Bayonne
est portable et peut être compilé sur la plupart des systèmes d'exploitation.
GNU Bayonne se caractérise par la multitude de services qu'il offre, notamment GNU Bayonne2 qui utilise le protocole SIP et H323 offrant des services
avancés IP, bien connu des solutions PBX Open source. Certains utilisateurs de Bayonne avouent que sa configuration est difficile à mettre en place.

La première étape consiste à disposer d'un système d'exploitation Open source, par exemple Debian.

La seconde étape consiste à compiler et installer GNU Bayonne2 puis, les modules et enfin les fichiers de configuration pour les différents services que vous
souhaitez mettre en place pour configurer vos services.

YATE

YATE est un logiciel créé par une communauté originaire de Roumanie, le nom donné à la solution est un acronyme signifiant Yet Another Telephony Engine.
Il a été développé en C++ par la société Null Team qui a été fondée en 2004, après quelques années d'expérience dans le domaine de la téléphonie et de la
création de logiciel. Yate se distingue sous deux versions : YATE 1 et YATE 2.

Il peut réaliser la fonction de passerelle entre le réseau public et le réseau IP ou entre un PC et un téléphone, afin de réaliser l'acheminement des
communications ver le réseau de l'opérateur.
Figure 7 : Tableau synthèse des logiciels libres

DEUXIEME PARTIE :

MISE EN PLACE D'UN PABX-IP

AVEC ASTERISK
I. INTRODUCTION

Après avoir rédigé toutes ces théories, il nous sera facile de déployer un PABX-IP.

II. CHOIX DES EQUIPEMENTS ET LOGICIELS

Asterisk peut supporter plusieurs types de téléphones :

· Les téléphones IP : Nous avons plusieurs types de téléphones IP parmi lesquels nous avons les téléphones CISCO, qui utilisent le protocole SCCP (Skinny
Client Control Protocole). Il existe également des téléphones GSM/WIFI, qui fonctionnent avec le protocole SIP, son interconnexion avec le réseau IP se fait
via à un ACCES POINT. Dans notre implémentation nous avons fait usage d'un téléphone IP de marque Grandstream.

· Les téléphones analogiques ou traditionnels qui utilisent le protocole SIP, sa connexion dans le réseau IP se fait via à une passerelle utilisant ce même
protocole. Il existe des solutions propriétaires telle que Linksys adapter qui est une passerelle SIP contenant deux modules FXS pour deux téléphones
analogiques et un port RJ45 pour la relier au réseau IP. Nous avons choisi un Linksys.

· Les stimulateurs téléphoniques appelés softphones, qui sont des logiciels qui jouent un rôle de téléphone. Ces logiciels (Xten, Xlite, gromemeeting,
NetMeeting etc.) peuvent être installés sur des systèmes différents (windows, linux, mac, etc.). Nous avons choisi à l'occasion Xlite.

Notre infrastructure de test comprend :

Ø Un PC tournant sous Linux et équipé d'une carte réseau faisant office d'un serveur.

Ø Un pc tournant sous Windows équipés d'une carte son, d'une carte réseau, d'un casque, d'un microphone et d'un soft phone.

Ø Deux Téléphones IP et un téléphone analogique

Il est aussi a noté que le champ d'expérimentation se fera sur un LAN constitué de câble UTP RJ45, un câble RJ11 et un Switch.

Les fonctionnalités que nous avons eues à implémenter :


Ø Appels entre terminaux : ils fonctionnent comme les appels classiques. Pour appeler, il suffit de composer son numéro. Les terminaux peuvent être un PC,
un téléphone IP.

Ø Interconnexion du réseau IP avec le réseau RTC

III. PROJET DE CONCEPTION DU RESEAU DE L'AGENCE TABI et Fils

Nous présentons sur la figure 8, notre solution de VoIP appliquée au réseau LAN de TABI et Fils. Cependant, le schéma ci-dessous est l'architecture d'une
implémentation d'Asterisk :
Figure 8 : Design-asterisk-GETRAK

IV. INSTALLATION D'ASTERISK SUR FEDORA

Nous avons choisi cette distribution compte tenu des ces fonctionnalités suivantes :
- Distribution récente utilise un noyau récent (2.6)

- Utilisation de l'outil YUM qui est un gestionnaire des paquets très puissant dans la mesure où il vous permet entre autre de retrouver automatiquement un
paquetage sur internet de le télécharger, de le décompresser et de l'installer pour vous.

QUELQUES COMMANDES DE BASE DU SERVEUR ASTERISK

Une fois Asterisk installé correctement, l'étape suivante est de nous familiariser avec quelques-unes des commandes de base :

· Exécuter Asterisk (qui se placera en arrière plan) :

# /etc/init.d/Asterisk (start|stop)

· Exécuter le serveur Asterisk en mode « bavard » 

( vvv), et ouvrir une « console » cliente ( c)

(la console cliente, ou CLI, permet de contrôler ce qui se passe dans le serveur Asterisk)

# Asterisk -vvvc

Si le serveur est déjà lancé, ouvrir un terminal client et se connecter au serveur pour contrôler son statut ( r) :

# Asterisk -r

· Recharger tous les fichiers de configuration ;

#CLI> reload

· Activer les informations de diagnostique pour SIP 

#CLI> SIP debug

· Désactiver les informations de diagnostique pour SIP 
#CLI> SIP nodebug

· Afficher le statut des utilisateurs, pairs et canaux pour SIP 

#CLI> sip show users

#CLI> sip show peers

#CLI> sip show channels

V. CONFIGURATION DU SERVEUR

En guise de configuration de notre serveur nous avons eu a édité deux fichiers de base :

- sip.conf

- extensions.conf

Cependant sip.conf : contient les paramètres relatifs au protocole SIP pour l'accès au serveur Asterisk, les clients doivent y figurer afin de pouvoir recevoir
ou effectuer un appel via le serveur.

Le fichier extensions.conf est la loge ou le lieu de stockage du Dialplan (plan de numérotation qui est composé d'un ou plusieurs contexte d'extensions.

VI. LES CAPTURES DU SERVEUR ASTERISK


A. Fichier extensions.conf

B. Fichier sip.conf
DIFFICULTES RENCONTREES

Au cours de notre recherche qui a consisté dans un premier temps à récolter les informations relatives à la nouvelle technologie de communication, nous
avons noté des difficultés suivantes :

· Rareté quant à la disponibilité des certains équipements tels que la carte TDM PCI, en local.
· Absence d'ouvrages explicitement dédié au serveur Asterisk dans les bibliothèques de la place.

· Difficultés de recueillir des informations sur le protocole d'inter-connectivité entre Asterisk et un réseau GSM auprès des IT concernés (Zain, Tigo).

SUGGESTIONS

Après étude, nous avons découvert que le réseau GETRAK, regorgeait de l'équipement minimal d'un réseau IP susceptible de permettre l'implémentation de
la VoIP. A savoir : switch D-link, Pcs, Lan opérationnel.

C'est ainsi que pour notre travail nous suggérons aux responsables administratifs de l'entreprise GETRAK, de bien vouloir investir dans ce projet qui s'avère
par ailleurs très rentable pour pouvoir mettre à profit les atouts qu'offre un réseau IP.

CONCLUSION

Au terme de ce travail, nous n'avons pas prétendu exploiter la panoplie des enjeux rencontrés dans l'implémentation d'une infrastructure de système
téléphonique de type VoIP.

Néanmoins nous avons tentés, par des multiples efforts, d'étayer cette étude de mise au point de manière à proposer des réponses à notre problématique.

En effet, il a été possible de matérialisé la fusion d'un réseau informatique et téléphonique en un, favorisant ainsi la réduction de cout de communication et
de maintenance.

En ce qui concerne notre champ d'investigation en l'occurrence l'agence GETRAK ; celle-ci pourra se doté d'une infrastructure de communication VoIP en
toute aise tant à son siège sociale qu'à ce succursale existante ou futur. Cependant la gestion de ce système pourra favoriser son évolution sociaux
économique toute au long de son existence.

Synoptique d'une architecture TOIP avec un PABX traditionnel

Ci-dessous, un synoptique d'une solution "TOIP" avec interconnexion avec un PBX existant (la liaison peut-être un RNIS, QSIG ou E&M) et une liaison vers le
réseau public à partir de la passerelle (gateway) qui peut servir soit en permanence, soit dans certains cas (routage international ou opérateur différent du
PBX).
Dans notre cas ci-dessous qui est une architecture mixte, les composants sont : - Un switch,

- Deux postes IP (Cisco 7960),

- Une application SoftPhone sur PC,

- Un routeur servant de passerelle (gateway) vers le PBX (pour les appels internes) et vers le PSTN (pour les appels externes),

- Un serveur de communications IP : Call Manager ( le serveur peut être intégrédans un seul et même élément ).

Synoptique d'une architecture TOIP avec un PABX traditionnel Figure 16 : Architecture TOIP avec un PABX traditionnel

Problème et qualité de service


Latence

La maîtrise du délai de transmission est un élément essentiel pour bénéficier d'un véritable mode conversationnel et minimiser la perception d'écho
(similaire aux désagréments causés par les conversations par satellites, désormais largement remplacés par les câbles pour ce type d'usage). Or la durée de
traversée d'un réseau IP dépend de nombreux facteurs: Le débit de transmission sur chaque lien, le nombre d'éléments réseaux traversés, le temps de
traversée de chaque élément, qui est lui même fonction de la puissance et la charge de ce dernier, du temps de mise en file d'attente des paquets, et du
temps d'accès en sortie de l'élément. Le délai de propagation de l'information, qui est non négligeable si on communique à l'opposé de la terre. Une
transmission par fibre optique, à l'opposé de la terre, dure environ 70 ms. Noter que le temps de transport de l'information n'est pas le seul facteur
responsable de la durée totale de traitement de la parole. Le temps de codage et la mise en paquet de la voix contribuent aussi de manière importante à ce
délai. Il est important de rappeler que sur les réseaux IP actuels (sans mécanisme de garantie de qualité de service), chaque paquet IP « fait son chemin »
indépendamment des paquets qui le précèdent ou le suivent: c'est ce qu'on appelle grossièrement le « Best effort » pour signifier que le réseau ne contrôle
rien. Ce fonctionnement est fondamentalement différent de celui du réseau téléphonique où un circuit est établi pendant toute la durée de la
communication. Les chiffres suivants (tirés de la recommandation UIT-T G114) sont donnés à titre indicatif pour préciser les classes de qualité et
d'interactivité en fonction du retard de transmission dans une conversation téléphonique. Ces chiffres concernent le délai total de traitement, et pas
uniquement le temps de transmission de l'information sur le réseau.

TROISIEME PARTIE: Mise en place d’une maquette de test et de couplage d’un PABX IP avec une architecture SMS

I. LA MISE EN PLACE D’UNE MAQUETTE DE TEST

Notre infrastructure de test comprend:

• Un PC tournant sous Linux FC3 et équipé d’une carte réseau et d’une carte TDM04B (pour accéder aux téléphones fixes de la SONATEL) faisant office de
serveur (voir Figure 10).

• Des PCs tournant sous Windows(2000Pro,XP) et équipés d’une carte son, d’une carte réseau, d’un casque et d’un microphone sur lesquels sont installés
un softphone (voir annexe 4).
Figure 10: Les types de softphones

• Un LAN 100Mbits
• 1 téléphones analogique (avec un Linksys adapter ), 4 Téléphones IP, 2Téléphone GSM/WIFI (voir annexe 5).

Figure 11: Les types de téléphones


Figure 12: Maquette de test

Les fonctionnalités que nous avons eues à implémenter:

• Appels entre terminaux: ils fonctionnent comme les appels classiques.

Pour appeler, il suffit de composer son numéro. Les terminaux peuvent être un PC, un téléphone IP, un téléphone analogique ou un téléphone GSM/WIFI.
• La messagerie Vocale: cela donne la possibilité à celui qui cherche à nous contacter de nous laisser un message si nous sommes déjà en communication ou
si nous sommes absents.
• Transfert un appel: nous pouvons transférer un appel vers un autre poste si on ne décroche pas après un certain temps ou même en pleine
communication. Pour cela, il nous suffit de choisir le numéro sur lequel nous voulons transférer cet appel ;ce numéro est prédéfini au niveau du serveur.

• Filtrage d’appels: nous pouvons filtrer des appels en fonction de l’identité ou du numéro de l’appelant ou de l’appelé. Par exemple, nous interdisons tous
les numéro commencant par 101X d’accéder au réseau publique.

• Parking: il consiste à garder quelque part pendant une durée limitée un appel de façon à pouvoir se déplacer et aller répondre dans un autre endroit.

• Facturation: il s’agit d’établir la facturation à partir des informations, stockées la base de données CDR (Call Detail Recorder), concernant tous appels:
noms et numéros de l’appelant et de l’appelé, heures et durées des communications, etc.

• Conférence audio: cela permet la communication entre plusieurs correspondants qui se trouvent dans divers endroits sans pour autant se déplacer.
• SVI (Serveur Vocal Interactif): le SVI sert de répondeur, contrôlé par l’ensemble des touches du téléphone (DTMF, Dual Tonique Multi Frequences) ou des
technologies de reconnaissance vocale, permet d’échanger de manière automatique des informations diverses.

Au sein de la section informatique, nous avons mis en place un SVI pour les réceptions d’appels venant de l’extérieur (réseau publique). Dans la section
informatique, tous les appels venant de l’extérieur doivent être réceptionnés par la secrétaire il existe des moments ou la secrétaire est absente (les heures
de pause, les heures de descente). Et dans ce cas, nous avons mis en place un SVI pour permettre à l’appelant un accès direct à un Bureau selon l’option
choisie dans le menu proposé. Voici l’algorithme:
Figure 13: Algorithme du SVI

• Interconnexion de deux serveurs asterisk: nous avons effectué une interconnexion de deux serveurs Asterisk en local.

• Interconnexion du réseau IP avec le réseau RTC: Asterisk autorise le dialogue entre différents serveurs VoIP ( décentralisé ), il est possible aussi d’attendre
simplement le réseau PSTN par une carte TDM insérée dans le serveur Asterisk. Une personne sur le réseau PSTN peut elle aussi atteindre le serveur afin de
joindre un correspondant interne et/ou le central téléphone.
• ACD (Agents et Centre d’appel): il s’agit de servir des appels en entrée, présentés sur un ou plusieurs numéros et acheminés dans une ou plusieurs files
d’attente. Afin de prendre en charge ces appels, il est nécessaire d’avoir des agents et des téléphones. Le centre d’appel doit offrir des fonctions simples
permettant à un agent d’entrer dans le système et d’en sortir, de façon authentifiée et ce à partir de n’importe quel poste banalisé par exemple un service
de renseignement, une agence de voyage.

Apres avoir mis en place une solution PABX IP Open source à la section informatique, nous avons couplé à cette solution une architecture SMS, pour
permettre aux étudiants d’accéder à l’information avec un simple sms.

II. COUPLAGE D’UN PABX IP AVEC UNE ARCHITECTURE SMS

II.1 L’état de l’art sur les architectures SMS

L’utilisation du téléphone mobile a connu une augmentation brutale dans les années 1990, jusqu’à saturation du marché peu après 2000. D’abord réservé à
une élite sociale pour une utilisation professionnelle, il s’est répandu jusqu’à devenir le moyen de communication privilégier d’un grand nombre de
personnes.

La communication entre téléphones mobiles est chère, beaucoup plus chère entre deux téléphones mobiles appartenants à deux opérateurs téléphoniques
différents. C’est ainsi, il existe des moyens de faire la communication très populaire chez les jeunes avec un faible coût: les SMS.

II.1.1 Les SMS

Le terme anglais Short Message Service, plus connu sous l’acronyme SMS, est un service proposé conjointement à la téléphonie mobile permettant de
transmette des massages écrits de petite taille.

Le SMS, permet de transmettre des messages de taille comprise entre 70 et 160 caractères suivant la langue utilisée. La taille du SMS est limitée par le mode
de transport. Une version améliorée, les MMS (Multimédia Message Service), qui permet d’envoyer des messages plus grands et contenant des
informations de type données informatiques (image, son,vidéo …), est en cours de diffusion.

Contrairement aux SMS, les MMS utilisent des canaux utilisateurs qui doivent donc être prévus par l’opérateur.

Transportés dans les canaux de signalisation, les SMS n’occupent pas la bande passante réservée au transport de la voix ; leur utilisation est donc peu
coûteuse pour l’opérateur.
Chaque message est envoyé via un mécanisme (Stone and Forward) à un SMSC (SMS Center), qui essaie de le transmettre au destinataire. Si ce dernier n’est
pas joignable, le SMSC stocke le message pour le retransmettre, en plusieurs tentatives si nécessaire. Deux opérations sont disponibles: le Mobile
Terminated (MT), pour les messages envoyés à un terminal mobile, et le Mobile Originating (MO), pour ceux qui sont envoyés depuis un terminal mobile. Il
existe deux types de protocole de transmission de SMS:

• Le protocole Short Message Service – Point to Point (SMS-PP), qui permet une transmission de point à point (entre SMSC et un téléphone mobile GSM).
• Le protocole Short Message Service – Cell Broadcast (SMS-CB), qui permet une transmission par diffuser des messages (publicitaires, informations
publiques, etc.) à tous les utilisateurs mobiles d’une zone géographique donnée (entre SMSC et plusieurs téléphones mobiles BSM).

Pour la transmission des SMS, entre le SMSC et un appareil mobile, la longueur de charge utile est limitée par les contraintes du protocoles de signalisation à
savoir 140 octets (140 octets équivalent à 140 * 8 bits = 1120 bits). En pratique, cela se traduit soit par 160 caractères en encodage sur 7 bits, soit par 140
caractères en encodage sur 8 bits, soit par 70 caractères en encodage sur 16 bits.

II.1.2 Asterisk et les SMS

D’après les études faites, sur des solutions open source, plus précisément sur l’état de l’art sur la solution Asterisk, nous avons pu découvrir qu’Asterisk
intègre dans ses nouvelles versions un outil qui nous permet d’envoyer des SMS en ligne de commande: le smsq

Le smsq est une application simple d’utilisation conçue pour faciliter les envoies de messages en ligne de commande. Il a été prévu pour fonctionner sur la
boite d’Asterisk et pour avoir l’accès direct aux annuaires de file d’attente pour SMS et pour Asterisk. Sous sa forme plus simple nous pouvons envoyer un
SMS par une commande comme:

smsq –motx-channel=ZAp/1/6234567 5648209’hello world’ Ceci crée un dossier de file d’attente pour un message de TX (à transmettre, sortir de message
de la boite asterisk), lancé dans la file d’attente 0, pour envoyer le texte « hello world » à 5648209. Il place alors un dossier dans l’annuaire de
/var/spool/asterisk/outgoing, pour lancer un appel à 6234567 (le numéro du SMSC par défaut de smsq) d’attacher à l’application SMS avec l’argument du
nom de file d’attente(0).

Pour envoyer un SMS dans le réseau GSM à partir de notre serveur Asterisk, il nécessite des moyens d’accès aux réseaux GSM. C’est ainsi qu’il existe trois
moyens d’accès aux réseaux GSM:

o L’architecture A:
L’architecture A représente un serveur Asterisk intégrant une carte TDM, pour l’accès aux réseaux PSTN afin d’accéder aux réseaux GSM via la ligne fournie
par la SONATEL, que nous avons utilisée comme passerelle. Mais d’après les recherches que nous avons eues à faire, la SONATEL ne dispose pas la
technologie qui permet d’envoyer des SMS via les lignes analogies, bien que cela existe dans certains pays.

Figure 14: L’accès au réseau GSM via au ligne analogique

L’architecture B:

Ici, l’accès aux réseaux GSM se fait via à un fournisseur sur l’Internet. Le fournisseur fournie un compte (login, mot de passe) et son numéro de SMSC. Pour
chaque SMS envoyé en ligne de commande au SMSC (fournisseur), le fournisseur vérifie l’état du compte à partir du login et mot de passe avant de router le
SMS au réseau GSM. L’inconvénient de cette solution est: elle est uniquement limite aux SMS, la dépendance du fournisseur et aussi de l’Internet, et ne
permet pas de faire la voix.
Figure 15: L’accès au réseau GSM via un fournisseur sur Internet

L’architecture C:

Il existe une troisième architecture, qui consiste de mettre en place d’une passerelle GSM (Gatewaye GSM) directement reliée, à notre réseau privé. Cette
passerelle se comporte comme un téléphone mobile GSM, peut supporter jusqu’à 30 puces GSM. L’utilisation des passerelles GSM permet, d’éviter les coûts
élevés pour les communications partant du réseau fixe vers le mobile, d’envoyer plus réception de SMS sur PC.
Figure 16: L’accès au réseau GSM via une passerelle

C’est cette solution que nous avons choisie pour envoyer et recevoir des SMS, afin de permettre aux étudiants de la section informatique de pouvoir obtenir
des informations via leurs téléphones mobiles. La base de données représentante notre serveur d’information.

II.2 Maquette regroupant la ToIP et SMS


Figure 17: Maquette de test regroupant ToIP et SMS

III. PERSPECTIVES ET OUVERTURE

L’implémentation du couplage (PABX IP et SMS)

Connexion à un site distant via l’Internet


Figure 18: Connexion à des sites distants via l’Internet

Utilisation dans un environnement hostile


Figure 19: Maquette de déploiement dans un environnement hostile

Cette architecture, représente l’interconnexion de trois villages dont la distance entre eux fait 2 km. Dans chaque village, il y a une antenne
omnidirectionnelle qui peut couvrir un rayon de 1km. La liaison inter village se fait par une communication point à point (avec les antennes maison). Ainsi
toutes les personnes qui sont cette zone et qui ont des téléphones GSM WIFI peuvent se communiquer entre elles.

Etude et mise en place d’un système de communication de VoIP: Appliqué à un PABX IP open source

Etude d’un système de communication VoIP

 Etude d’un système de communication VoIP

 Etat de l’art sur la Téléphonie sur IP et Solutions logiciels libres

 Notions sur la Téléphonie et sur les PABX classiques


 Avantages Système de téléphonie IP et téléphonie sur IP

 La Téléphonie sur IP: Architecture et mode d’access

 Le protocole H323: Equipements, avantages et inconvénients

 Le protocole SIP et Etude comparative entre SIP et H3233

 Codecs et Gestion de qualité de service: Téléphonie IP

 Logiciels de Téléphonie IP: VOCAL Asterisk Yate – comparaison

 Asterisk: présentation, installation et configuration

 PABX IP avec Architecture SMS: Maquette de test et Couplage

 VoIP: Système de communication

Vous aimerez peut-être aussi