Document sur l'Auto provisioning, contacts, presence et streaming sur asterisk

Auto provisioning – Gestion des contacts – Présence – Vidéo surveillance

Introduction :

De nos jours, les entreprises, les universités migrent leurs infrastructures téléphoniques vers
du IP. Cette migration leur offre plusieurs avantages comme la réduction des coûts liés à la
maintenance, la tolérance aux pannes, la souplesse du réseau, facilité d’implémentation et de
configuration et une multitude de services. Mais cette migration n’a pas que des avantages,
elle apporte aussi plusieurs inconvénients :

- La complexité du réseau se retrouve maintenant chez le client ou l’employé qui doit
avoir des compétences informatiques pour configurer les équipements (téléphones
IP, ordinateurs, imprimantes, etc…) pour qu’ils puissent se connecter sur le réseau.
- Une perte de temps énorme pour les administrateurs réseau qui doivent configurer
ou reconfigurer chaque équipement et les mettre à jour.
- Augmentation des coûts liés à la formation des employés sur les configurations de
ces équipements etc…
- La congestion du réseau dû à tous les équipements réseaux (ordinateurs,
imprimantes, téléphones IP, etc. …) utilisant le même support de communication.

Pour palier à ces problèmes, ces téléphones IP supportent une multitude de protocoles
(DHCP, TFTP) que nous pouvons mettre à profit pour paramétrer ces équipements à distance
et de manière automatique sans aucune interaction du client. Dans la suite de ce mémoire,
nous allons implémenter cette solution qui permettra aux administrateurs réseau de gagner en
temps pour le paramétrage et la maintenance des téléphones IP et épargner aux abonnés des
configurations fastidieuses.
Ensuite nous allons implémenter le service de « répertoire de contacts » et de « recherche de
contacts » dans les téléphones IP ce qui permettra aux employés d’une entreprise de retrouver
facilement le numéro de leurs correspondants.
Ensuite nous allons implémenter le service de présence avec les téléphones logiciels qui
permettra aux abonnés de savoir si leur correspondant est joignable, occupé, absent,
indisponible. Ce service nous permettra aussi de réduire la congestion dans le réseau car
l’abonné sera tenté d’appeler que lorsque son correspondant sera en ligne et donc moins de
signalisations inutiles dans le réseau.
Enfin nous allons mettre en place le principe de streaming dynamique en implémentant le
service de vidéosurveillance sur mobile dans un réseau IP. Ainsi on pourra surveiller les
locaux de l’ESMT à travers un téléphone logiciel en utilisant une caméra IP et un serveur
IPBX appelé Asterisk.

Promotion : 2009 – 2011 1


Chapitre I:
Problématique et Contexte de l’étude

Promotion : 2009 – 2011 2


I.1 - Contexte
Nombreuses sont les entreprises ou universités qui achètent les téléphones CISCO pour
pouvoir faire de la voix sur IP. Cependant ces téléphones nécessitent au préalable des
configurations pour pouvoir fonctionner ; des configurations qui nécessitent des compétences
informatiques que les employés n’ont pas forcement. Au cours de notre stage, nous devrons
configurer ces téléphones de manière automatique.

Avec les téléphones analogiques, chaque employé doit avoir son propre calepin avec les
numéros des autres employés ou mémoriser les numéros ce qui est très difficile si l’entreprise
a beaucoup d’employés. En effet les téléphones analogiques ne peuvent pas enregistrer des
numéros de contacts. Si le calepin se perd, il faut encore reconstituer tous ces contacts ce qui
n’est pas chose aisée. Le téléphone RNIS ayant une capacité limitée, ne peut pas contenir un
grand nombre de numéros. Notre travail sera d’implémenter une base de données des contacts
dans ces téléphones.

Pendant le fonctionnement de ces téléphones, une autre situation se présente. On remarque
une congestion fréquente du réseau. Cette congestion est dû à plusieurs personnes appelant au
même moment et dont le réseau ne peut supporter la capacité. Alors le réseau est obligé de
rejeter des appels ou les mettre en attente jusqu’à ce qu’une ressource se libère. De plus
quand un appel veut s’établir, si l’appelé n’est pas disponible, de la bande passante est
consommée inutilement pour les échanges de signalisations. Ce qui peut pénaliser les autres
abonnés voulant appeler en cas de congestion. Nous devrons fournir une solution permettant
de réduire la congestion dans un réseau.

Pour lutter contre la criminalité, le vol et les agressions, la vidéo surveillance est la solution
la plus utilisée pour surveiller les locaux, les rues, etc… dans les entreprises comme dans les
universités. Seulement pour pouvoir visualiser les caméras, il faut un ou plusieurs écrans de
télévisions ou d’ordinateurs. Possédant des téléphones IP supportant la vidéo, nous devons
faire en sorte que ces téléphones puissent afficher les images de la caméra

I.2 - Problématique
La problématique est de pouvoir mettre à jour, configurer à distance et de manière
automatique des téléphones CISCO pour qu’ils puissent fournir des services sans aucune
interaction du client ou employé. Cette action de pouvoir configurer, mettre à jour à distance
et de manière automatique un équipement pour qu’il puisse se connecter au réseau est appelé
l’auto provisioning. Puis nous devrons intégrer des numéros de contacts de l’entreprise dans
ces téléphones CISCO. Ensuite nous allons échanger les informations de présence entre les
abonnés pour qu’ils n’appellent que lorsque leur correspondant est en ligne et ainsi limiter la
congestion et améliorer la gestion des ressources. Enfin nous allons diffuser le flux vidéo de
la caméra de surveillance sur les téléphones logicielles IP.

Promotion : 2009 – 2011 3


I.3 - Présentation du lieu de stage

Pendant un mois et demi, j’ai eu à effectuer mon stage au laboratoire de commutation de
l’ESMT et au laboratoire de recherche de la société RTN pour des besoins d’infrastructures.

L’ESMT est une institution multinationale, qui a été créée à Dakar
en 1981 à l’initiative de sept pays de l’Afrique de l’ouest (Bénin,
Burkina Faso, Mali, Mauritanie, Niger, Sénégal, Togo). En 1998,
l’intégration se renforce par l’adhésion de la Guinée Conakry. Avec plus de quinze autres
pays utilisateurs, l’ESMT, en tant que centre d’excellence de l’UIT, assure un mandat de pôle
de convergence et de recherche appliquée dans le domaine des télécommunications /TIC dans
toute l’Afrique francophone en particulier. Elle accueille aujourd’hui plus de 17 nationalités
en formation initiale et continue, et est liée au Sénégal par un accord de siège qui lui confère
un statut diplomatique.

Aujourd’hui l’ESMT est :

 Premier centre d’excellence francophone de l’UIT (2000) ;
 Reconnue et homologuée par le CAMES (2003) ;
 Institut membre du CAMES ;
 Label centre d’excellence UEMOA (2005) ;
 Académie régionale CISCO.

L’école supérieure multinationale des télécommunications est régie par un ensemble de
textes réglementaires et statutaires :
Un accord intergouvernemental entre les pays membres (Bénin, Burkina Faso,
Guinée Conakry, Mali, Mauritanie, Niger, Sénégal, Togo) définit les engagements
de chaque pays, le statut juridique de l’école ainsi que ses modalités de
fonctionnement ;
Depuis 1986, un accord de siège avec le gouvernement du Sénégal lui donne un
statut d’institution diplomatique. Le statut du personnel et le règlement intérieur,
qui sont en accord avec les lois du Sénégal.

La mission de l’ESMT consiste à : « Accompagner et renforcer nos clients dans leur
stratégie de développement au travers d’une offre de prestations de service diversifiée et
adaptée, conformes aux standards internationaux. »

La vision de l’ESMT : « Nous sommes une institution-clef dans la politique
d’enseignement et de formation dans les TIC en Afrique à côté des autres acteurs du
secteur. Nous nous efforçons de devenir le leader dans ce domaine, la vitrine des TIC et
l’institution d’enseignement et de recherche de référence en Afrique. »
Pour assurer la migration entre le présent et le futur, les axes stratégiques de l’ESMT sont :
L’axe client (Placer le client au centre de l’organisation) ;

Promotion : 2009 – 2011 4


L’axe croissance rentable (Activer les moteurs de la croissance sous contrainte de
la rentabilité et de nouveaux relais) ;
L’axe innovation (Développer la recherche et l’innovation) ;
L’axe ressources humaines (Professionnaliser les collaborateurs et les mobiliser
pour la réalisation de notre ambition).

Présentation de la société Réseaux et Techniques Numériques (RTN)

Réseaux et Techniques Numériques (R.T.N) est une société dirigée par une
équipe de professionnels qualifiés, spécialisée en logiciels libres et centrée sur
les services informatiques, techniques numériques et télécommunications.

Cette société offre une gamme de formations se basant sur des supports de cours, fruits de
recherches approfondies. Ces supports testés et avérés permettent aux apprenants d’être
aussitôt opérationnels.

Sa mission vise à accroître la compétitivité de ses clients par la valorisation des composantes
informatiques, logicielles et réseaux constituants le système d'information de ses clients. Il
s'agit de générer des gains importants de productivité en produisant plus et mieux à budget,
organisation et infrastructure quasi-équivalent via la valorisation des outils logiciels métiers
préexistants et ceci, sans rupture des cycles d'exploitation de service de l'entreprise et sans
remise en cause organisationnelle.

Domaines d’activités

La société RTN offre une palette de solutions dans le domaine de la technologie de
l’information et de la communication. Ses solutions sont orientées Open Source et réalisées
selon les besoins et l'exploration des opportunités d'entreprise. Elles répondent par
conséquent aux problèmes réels.

RTN met également un accent particulier sur les suites bureautiques de linux (traitement de
texte, tableurs et logiciels de présentation de conférence et de traitement d’images), le
développement des Services à Valeurs Ajoutées, la Téléphonie sur IP, les services réseaux
(DHCP, DNS, WEB, les annuaires LDAP, la Messagerie Collaborative, partage des données)
et l’interconnexion sécurisées de sites distants, participant ainsi à la cohabitation et
l’harmonisation des réseaux hétérogènes Linux-Windows.

Promotion : 2009 – 2011 5


RTN intervient dans les domaines suivants :

 Formation et encadrement des personnels des entreprises;

 Mise à niveau du personnel des entreprises sur les technologies de l’information et de
la communication ;

 Conseils et orientations professionnelles pour la gestion d’un réseau d’entreprise
dynamique ;

Promotion : 2009 – 2011 6


Chapitre II :
Auto Provisioning

Promotion : 2009 – 2011 7


II.1 - Présentation et Scenario de fonctionnement

L’auto provisioning, mot anglais désignant l'approvisionnement, est un terme utilisé dans le
monde de l'informatique, désignant l'allocation automatique de ressources. Les outils d’auto
provisioning sont des outils de gestion de configuration (on parle également de "gestion de
paramétrage") permettant d'installer et de configurer des logiciels à distance, ou encore
d'allouer de l'espace disque, de la puissance ou de la mémoire.

Dans le monde des télécommunications, l’auto provisioning consiste à adapter un service
aux besoins d'un client. Au sens large, le provisioning est l'affectation plus ou moins
automatisée de ressources à un utilisateur (poste de travail, téléphonie,...).

Dans le cadre de mon stage, je dois approvisionner les téléphones IP CISCO pour pouvoir
les paramétrer et les mettre à jour à distance. Voici le scénario de fonctionnement de l’Auto
provisioning.

Figure II-1 : Schéma de fonctionnement de l’auto provisioning

Promotion : 2009 – 2011 8


Dans un premier temps, le téléphone doit avoir un identifiant dans le réseau et cet
identifiant est une adresse IP. Cette adresse IP est donnée automatiquement et avec une durée
déterminée par un serveur DHCP. Donc le téléphone va faire une requête au serveur DHCP
(1). Dans le serveur DHCP on va indiquer où se trouve le serveur TFTP (2) en utilisant le
fichier dhcp.conf. Le serveur DHCP va alors répondre à la requête du téléphone (3) en lui
donnant une adresse IP et en lui indiquant où se trouve le serveur TFTP.

Figure II-2 : Comme décrit dans le scénario de fonctionnement, le téléphone va chercher une
adresse ip auprès de notre serveur dhcp. Le serveur lui attribue l’adresse 192.168.1.5. Les
échanges dhcp sont coloriés en bleu.

Le téléphone va ensuite interroger le serveur TFTP (4) pour récupérer ses informations de
configuration. Ces informations de configuration se trouvent dans un ou plusieurs fichiers
écrit dans le langage XML ex : SEP[@MAC].cnf.xml. Dans ce fichier de configuration que
le téléphone va lire on va aussi indiquer où se trouve le serveur IPBX (Asterisk dans notre
cas) sur lequel il va s’y connecter ensuite (5). Le serveur TFTP va répondre à la requête du
téléphone (6) en lui indiquant où se trouve le serveur IPBX.

Figure II-3 : Le téléphone récupère ensuite son fichier de configuration sur le serveur tftp
(SEP18EF639E60F4.cnf.xml).

Promotion : 2009 – 2011 9


Figure II-4 : Le téléphone se met à jour en téléchargeant le nouveau firmware (P00308010200.sb2).
Les messages ont été tronqués car ils sont trop longs.

Enfin le téléphone va aller s’authentifier sur le serveur IPBX (Asterisk) (7). Le serveur va
vérifier que le téléphone existe dans le fichier sccp.conf (8) et (9) et enfin l’accepter en lui
attribuant un numéro et une ligne (10). Si le téléphone n’existe pas dans sccp.conf alors le
serveur IPBX va soit le rejeter, soit le permettre de se connecter mais ne laisser que la
possibilité au téléphone d’appeler le service support où hotline en anglais.
Notons tout de même que cette procédure fonctionne avec les téléphones IP CISCO que
nous utilisons pendant notre stage. Pour les téléphones de marque différente, la procédure
peut être différente.

Promotion : 2009 – 2011 10


Figure II-5 : Ces messages indiquent l’enregistrement du téléphone sur le serveur asterisk. Ensuite
asterisk envoi les paramètres du téléphone configurés dans sscp.conf comme le paramétrage des
touches, des boutons, l’heure à afficher, le nom de téléphone à afficher, etc…

II.2 - Solution retenue

Il existe plusieurs types de protocoles pour approvisionner les téléphones IP : on peut
utiliser le serveur FTP ou WEB pour configurer les téléphones et de plus ces protocoles sont
plus sécurisés que le TFTP. Mais peu de téléphones supportent ces protocoles d’où
l’utilisation du protocole TFTP qui est supporté par les téléphones CISCO avec lesquels nous
travaillons.

Promotion : 2009 – 2011 11


Pour la solution IPBX, Asterisk à été privilégié que CISCO call manager car elle est
gratuite, open source et populaire qui est un gage d’évolutivité. De plus avec toute sa
communauté d’utilisateurs et de développeurs, on a de l’aide sur internet.

II.3 - Logiciels et Equipements utilisés
Nous avons besoin d’un serveur DHCP, TFTP, Asterisk. Etant sur Debian, nous utiliserons
dhcp3-server comme serveur DHCP, TFTPD pour le serveur TFTP, et Asterisk comme
serveur IPBX. Et comme équipements, un Switch ; un pc portable faisant office de serveur
DHCP, TFTP et Asterisk ; des téléphones IP CISCO 7912, 7940 et un ATA188.

II.4 - Installation et Configuration

Serveur DHCP
Dynamic Host Configuration Protocol (DHCP) est un terme anglais désignant un
protocole réseau dont le rôle est d’assurer la configuration automatique des paramètres IP
d’une station, notamment en lui affectant automatiquement une adresse IP et un masque
de sous-réseau. DHCP peut aussi configurer l’adresse de la passerelle par défaut, des
serveurs de noms DNS, et éventuellement donner d’autres types d’informations telles que
les adresses de serveurs TFTP ou FTP. L’ordinateur ou téléphone IP équipé de TCP/IP,
mais dépourvu d’adresse IP, envoie par diffusion un datagramme (DHCP DISCOVER)
qui s’adresse au port 67 de n’importe quel serveur à l’écoute sur ce port. Ce datagramme
comporte entre autre l’adresse physique (MAC) du client. Tout serveur DHCP ayant reçu
ce datagramme, s’il est en mesure de proposer une adresse sur le réseau auquel appartient
le client, diffuse une offre DHCP (DHCP OFFER) à l’attention du client (sur son port
68), identifié par son adresse physique. Cette offre comporte l’adresse IP du serveur, ainsi
que l’adresse IP et le masque de sous-réseau qu’il propose au client. Il se peut que
plusieurs offres soient adressées au client s’il y a plusieurs serveurs.
Le client retient une des offres reçues (la première qui lui parvient), et diffuse sur le
réseau un datagramme de requête DHCP (DHCP REQUEST). Ce datagramme comporte
l’adresse IP du serveur et celle qui vient d’être proposée au client. Elle a pour effet de
demander au serveur choisi l’assignation de cette adresse, l’envoi éventuel des valeurs
des paramètres, et d’informer les autres serveurs qui ont fait une offre qu’elle n’a pas été
retenue.
Le serveur DHCP choisi élabore un datagramme d’accusé de réception (DHCP ack pour
acknowledgement) qui assigne au client l’adresse IP et son masque de sous-réseau, la
durée du bail de cette adresse, et éventuellement d’autres paramètres :
- Adresse IP de la passerelle par défaut,
- Adresses IP des serveurs DNS,
- Adresses IP des serveurs TFTP.

Promotion : 2009 – 2011 12


-
Figure II-6 : Fonctionnement du dhcp

Pour implémenter le serveur DHCP, nous allons installer le paquet dhcp3-server en
utilisant la commande suivante:
#apt-get install dhcp3-server

Ensuite nous acceptons le téléchargement des paquets. Le paquet téléchargé et installé,
nous passons à la configuration du serveur.
Les fichiers de configuration se trouvent dans le dossier /etc/dhcp3/dhcpd.conf.
Sur d’autres systèmes ils se trouvent dans /etc/dhcp/dhcpd.conf.
Nous modifions ce fichier en dé-commentant ou en ajoutant les informations suivantes.
Les explications des lignes sont après le # :

Dhcpd.conf

ddns-update-style interim;
#Peut être de type ad-hoc ou interim, et permet au serveur DHCP de mettre à jour
des entrées DNS. Les deux modes (ad-hoc et interim) décrivent des méthodes sur la
manière d’effectuer ces mises à jour. Aujourd’hui, il est conseillé de ne plus utilisé
le style ad-hoc pour les serveurs DHCP récents. Donc toujours mettre : ddns-
update-style interim

ignore client-updates;
#La méthode interim est le standard. Le client peut demander au serveur DHCP de
mettre à jour le serveur DNS en lui passant ses propres paramètres (nom de
domaine). Dans ce cas le serveur est configuré pour honorer ou pas la demande du
client. Ceci se fait avec le paramètre ignore client-updates ou allow client-updates.

authoritative;
#Dans le cas où il y aurait plusieurs serveurs DHCP, celui-ci fait office d’autorité.

subnet 192.168.1.0 netmask 255.255.255.0 {
#le sous réseau dans lequel les adresses seront attribuées

Promotion : 2009 – 2011 13


option routers 192.168.1.1;
#L'option routers spécifie une liste d'adresses IP de routeurs qui sont sur le sous-
réseau du client. Les routeurs doivent être mentionnés par ordre de préférence

option subnet-mask 255.255.255.0;
#L'option subnet-mask spécifie le masque de sous-réseau du client. Si aucune
option subnet-mask n'est fournie dans la portée du bloc, DHCPD utilisera en dernier
recours le masque de la déclaration de sous-réseau auquel appartient l'adresse en
cours d'attribution. Cependant, toute déclaration d'option subnet-mask remplacera le
masque de sous-réseau spécifié dans la déclaration de sous-réseau

option nis-domain "emeric.com";
#Cette option spécifie le nom du domaine du client. Le domaine est une chaîne de
caractères

option domain-name "emeric.com";
#Cette option spécifie, le nom de domaine que le client doit utiliser lorsqu'il résout
des noms d'hôte via les serveurs de noms DNS

option domain-name-servers 192.168.1.1;
#il spécifie une liste de serveurs de noms de domaines disponibles pour les clients.
Les serveurs doivent être spécifiés par ordre de préférence

option time-offset -18000;
# Eastern Standard Time (il spécifie le décalage en secondes pour le client de sous-
réseau par rapport aux coordonnées de temps universelles

option ntp-servers 130.159.196.118;
#l’adresse IP du serveur de temps

option TFTP-server-name "192.168.1.1";
#l’adresse IP du serveur de partage de fichiers TFTP

range dynamic-bootp 192.168.1.2 192.168.1.10;
#Plage d’adresses valides à offrir aux machines qui veulent booter en réseau

default-lease-time 43200;
#temps de bail par défaut en secondes

max-lease-time 86400;
#temps de bail maximum en secondes
}

Maintenant nous redémarrons le serveur DHCP.
#/etc/init.d/isc-dhcp-server restart

Promotion : 2009 – 2011 14


Serveur TFTP
TFTP (Trivial File Transfer Protocol) est un protocole simplifié de transfert de fichiers.
Il fonctionne en UDP sur le port 69, au contraire du FTP qui utilise lui TCP. L'utilisation
d'UDP, protocole « non fiable », implique que le client et le serveur doivent gérer eux-
mêmes une éventuelle perte de paquets. En termes de rapidité, l'absence de fenêtrage nuit
à l'efficacité du protocole sur les liens à forte latence. On réserve généralement l'usage du
TFTP à un réseau local.
Les principales simplifications visibles du TFTP par rapport au FTP est qu'il ne gère pas
le listage de fichiers, et ne dispose pas de mécanismes d'authentification, ni de
chiffrement. Il faut connaître à l'avance le nom du fichier que l'on veut récupérer. De
même, aucune notion de droits de lecture/écriture n'est disponible en standard.
À cause de ces fonctionnalités absentes, FTP lui est généralement préféré. TFTP reste
très utilisé pour la mise à jour des logiciels embarqués sur les équipements réseaux
(routeurs, pare-feu, téléphones IP, etc.) ou pour démarrer un PC à partir d'une carte
réseau.

Figure II-7 : Demande de fichier du client au serveur TFTP

Installation du serveur TFTPD et du client TFTP
#aptitude install tftpd
#aptitude install tftp

Création d’un répertoire racine du serveur TFTPD et changement de permission
#mkdir /tftpboot
#hmod 777 /tftpboot
#chown emeric.emeric /tftpboot (je change le propriétaire du dossier ‘nom.groupe’).

Nous cherchons et éditons le fichier /etc/inetd.conf pour indiquer au serveur TFTPD où se
trouve le répertoire racine que nous avons crée juste avant :
/srv/tftp que nous changeons en /tftpboot

Nous ajoutons cette ligne si elle n’est pas déjà présente.
tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd /tftpboot

Promotion : 2009 – 2011 15


Enfin nous redémarrons le serveur TFTPD pour qu’il tienne compte des modifications
apportées.
#cd /etc/init.d
#./openbsd-inetd restart

Nous testons que le serveur TFTPD fonctionne avec les commandes suivantes :
#tftp 127.0.0.1
tftp> (cette ligne signifie que le serveur fonctionne.)

Maintenant le téléphone CISCO après avoir reçu une adresse IP par le serveur DHCP, il
interroge le serveur TFTP pour recevoir les informations de configurations. Pour cela
deux fichiers de configurations sont nécessaires :

OS « SERIES DU TELEPHONE ».TXT : Le nom du fichier doit être obligatoirement en
majuscule. Je dois remplacer « SERIES DU TELEPHONE » par le numéro de série du
téléphone.
Ex : un CISCO IP Phone Séries 7912. Le numéro de série est 7912. Donc le fichier sera
OS7912.TXT et à l’intérieur je ne vais mettre que la version du firmware du téléphone.
Ce fichier est utilisé si on veut mettre à jour le téléphone CISCO. Donc on va mettre une
version supérieure à celui du téléphone.
Ex : CP7912080003SCCP070409A

SEP000D657072B5.cnf.xml : C’est le deuxième fichier utilisé pour la configuration du
téléphone CISCO où le 000D657072B5 représente l’adresse mac du téléphone (Dans
notre cas celui du CISCO IP Phone Séries 7912). Le contenu de ce fichier est en XML car
c’est le langage qu’il comprend.
XML (eXtensible Markup Language ou Langage à balises extensible) est en quelque sorte
un langage HTML amélioré permettant de définir de nouvelles balises. Il s'agit
effectivement d'un langage permettant de mettre en forme des documents grâce à des
balises.
Contrairement à HTML, qui est à considérer comme un langage défini et figé (avec un
nombre de balises limité), XML peut être considéré comme un métalangage permettant
de définir d'autres langages, c'est-à-dire définir de nouvelles balises permettant de décrire
la présentation d'un texte. La force de XML réside dans sa capacité à pouvoir décrire
n'importe quel domaine de données grâce à son extensibilité. Il va permettre de structurer,
poser le vocabulaire et la syntaxe des données qu'il va contenir.
En réalité les balises XML décrivent le contenu plutôt que la présentation. Ainsi, XML
permet de séparer le contenu de la présentation. Ce qui permet par exemple d'afficher un
même document sur des applications ou des périphériques différents sans pour autant
nécessiter de créer autant de versions du document pour autant de téléphones.

Voici le contenu du fichier SEP000D657072B5.cnf.xml :

Promotion : 2009 – 2011 16


SEP000D657072B5.cnf.xml
<device xsi:type="axl:XIPPhone">
<devicePool>
<name>NOM DU TELEPHONE</name>
<dateTimeSetting>
<name>CMLocal</name>
<dateTemplate>D.M.YA</dateTemplate>
<timeZone>GMT Standard/Daylight Time</timeZone>
<ntps>
<ntp>
<name>ADRESSE IP DU SERVEUR DE TEMPS</name>
<ntpMode>Unicast</ntpMode>
</ntp>
</ntps>
</dateTimeSetting>
<callManagerGroup>
<members>
<member priority="0">
<callManager>
<ports>
<ethernetPhonePort>2000</ethernetPhonePort>
</ports>
<processNodeName>ADRESSE IP DU SERVEUR IPBX</processNodeName>
</callManager>
</member>
</members>
</callManagerGroup>
<srstInfo>
<name>Enable</name>
<srstOption>Enable</srstOption>
<userModifiable>true</userModifiable>
<ipAddr1>ADRESSE IP DU SERVEUR ASTERISK</apAddr1>
<port1>2000</port1>
<ipAddr2></apAddr2>
<port2>2000</port2>
<ipAddr3></ipAddr3>
<port3>2000</port3>
</srstInfo>
<mlppDomainId>-1</mlppDomainId>
<mlppIndicationStatus>Default</mlppIndicationStatus>
<preemption>Default</preemption>
</devicePool>
<loadInformation>VERSION DU FIRMWARE</loadInformation>
<vendorConfig>
<disableSpeaker>false</disableSpeaker>
<disableSpeakerAndHeadset>false</disableSpeakerAndHeadset>
<forwardingDelay>1</forwardingDelay>
<pcPort>0</pcPort>
<settingsAccess>1</settingsAccess>
<garp>0</garp>
Promotion : 2009 – 2011 17


<voiceVlanAccess>1</voiceVlanAccess>
<videoCapability>1</videoCapability>
<autoSelectLineEnable>0</autoSelectLineEnable>
<webAccess>1</webAccess>
<daysDisplayNotActive>1,7</daysDisplayNotActive>
<displayOnTime>08:30</displayOnTime>
<displayOnDuration>11:30</displayOnDuration>
<displayIdleTimeout>01:00</displayIdleTimeout>
</vendorConfig>
<versionStamp></versionStamp>
<userLocale>
<name></name>
<uid>1</uid>
<langCode>en</langCode>
<version>4.0(1)</version>
<winCharSet>iso-8859-1</winCharSet>
</userLocale>
<networkLocale></networkLocale>
<networkLocaleInfo>
<name></name>
<uid>64</uid>
<version>4.0(1)</version>
</networkLocaleInfo>
<deviceSecurityMode>1</deviceSecurityMode>
<idleTimeout>120</idleTimeout>
<authenticationURL></authenticationURL>
<directoryURL> </directoryURL>
<idleURL></idleURL>
<informationURL></informationURL>
<messagesURL></messagesURL>
<proxyServerURL></proxyServerURL>
<servicesURL></servicesURL>
<dscpForSCCPPhoneConfig>96</dscpForSCCPPhoneConfig>
<dscpForSCCPPhoneServices>0</dscpForSCCPPhoneServices>
<dscpForCm2Dvce>96</dscpForCm2Dvce>
</device>

Dans ce fichier, nous avons besoin de modifier que les informations en rouges. Notons
toutefois que certains types de téléphones CISCO ne lisent pas de la même manière ce
fichier soit à cause d’un bug donc la mise à jour peut régler soit fait volontairement par la
marque. Pendant que certains prendront un 0 comme désactivé, d’autres le prendront
comme activé. Ex : <webAccess>1</webAccess> .pour certains types de téléphones, ça
veut dire que l’accès web doit être activé pendant que d’autres vont le prendre comme
désactivé.

La structure du fichier XML change en fonction du protocole de signalisation supporté
par le téléphone. Nous travaillons avec des CISCO phones Séries 7912 supportant le

Promotion : 2009 – 2011 18


protocole SCCP. Pour ceux supportant le protocole SIP la structure du fichier est
différente.
En plus des deux fichiers ci-dessus, un troisième fichier peut être rajouté avec le nom
« XMLDefault.cnf.xml ». Il n’est pas obligatoire mais peut être utile lorsque l’on veut
mettre à jour massivement plusieurs types de téléphones CISCO (7912, 7920, 7940, 7960,
CISCO IP Communicator). Nous pouvons aussi l’utiliser pour paramétrer tous les
téléphones IP pour qu’ils se connectent à Asterisk mais ils ne pourront pas supporter des
services supplémentaires. Voici sa structure:

XMLDefault.cnf.xml
<Default>
<callManagerGroup>
<members>
<member priority="0">
<callManager>
<ports>
<ethernetPhonePort>2000</ethernetPhonePort>
</ports>
<processNodeName>ADRESSE IP IPBX</processNodeName>
</callManager>
</member>
</members>
</callManagerGroup>
<loadInformation6 model="IP Phone 7910">SCCP11.8-5-2S</loadInformation6>
<loadInformation6 model="IP Phone 7911">SCCP11.8-5-2S</loadInformation6>
<loadInformation9 model="IP Phone 7935"></loadInformation9>
<loadInformation8 model="IP Phone 7940">P00308010100</loadInformation8>
<loadInformation7 model="IP Phone 7960">P00308010100</loadInformation7>
</Default>

Si les téléphones doivent être mis à jour, en plus de ces deux (trois) fichiers, Nous
devons télécharger le fichier du firmware (système embarqué) en .zip que nous allons
décompresser dans le répertoire racine du serveur tftpboot. Ex : Si nous prenons toujours
notre CISCO IP Phone Séries 7912, nous aurons dans le dossier /tftpboot :
- SEP000D657072B5.cnf.xml
- OS7912.TXT
- CP7912080003SCCP070409A.sbin (correspond au firmware de mise à jour du CISCO IP
Phone Séries 7912).

Serveur Asterisk
Asterisk est une plateforme de téléphonie Open Source initialement conçue pour
fonctionner sur linux. C’est probablement l’un des outils les plus puissants, les plus
flexibles et les plus extensibles fournissant tous les services de télécommunications. Il est
conçu pour s’interfacer avec n’importe quel dispositif logiciel ou matériel de
Promotion : 2009 – 2011 19


télécommunication de manière cohérente et progressive. Il crée un environnement unique
qui peut être façonné pour s’adapter à n’importe quel cas d’utilisation notamment en tant
que :
- Gateway VOIP supportant les protocoles MGCP, SCCP, SIP, H.323, etc…
- Private branch exchange (PBX) ;
- Serveur vocal interactif ;
- Serveur de messagerie vocale ;
- Serveur de conférence ;
- Translation de numéro ;
Asterisk peut fonctionner avec des cartes zaptel ou des cartes non zaptel de certains
constructeurs. Ces cartes servent à sa connexion aux lignes téléphoniques classiques
(RTC, RNIS, etc…).

Nous avons installé Asterisk 1.4 car elle plus stable avec l’extension Chan_sccp_b. Cette
extension est un module qui ajoute au serveur Asterisk la possibilité de supporter le
protocole SCCP utilisé par les téléphones IP CISCO avec plus de fonctionnalités et plus
de compatibilité avec les téléphones.
Skinny Client Control Protocol (SCCP) est un protocole propriétaire CISCO utilisé pour
les échanges entre le Call Manager et les IPPHONES. Le terme SKINNY est utilisé pour
indiquer que le protocole SCCP est très simple et requiert de ce fait des ressources
processeur limitées. Les messages sont transmis via TCP en utilisant le port 2000.
Ceux-ci comportent au minimum trois champs de quatre octets :
- Un entier représentant la taille du message total.
- Un deuxième champ réservé qui doit toujours être à zéro.
- Un identifiant (MessageId) pour déterminer la nature du message. Le
MessageId permet de définir l’information transmise entre le poste IP et le
Call Manager.
Lorsque toutes les étapes du protocole de signalisation ont été exécutées les postes
dialoguent en eux en utilisant RTP.

Nous téléchargeons Asterisk:
#wget http://downloads.Asterisk.org/pub/telephony/Asterisk/releases/Asterisk-
1.4.42.tar.gz

Ensuite, Nous décompressons l’archive (.tar.gz) téléchargée:
#tar -zxvf Asterisk-1.4.42.tar.gz -C /usr/local/

Installation des dépendances:
#apt-get install linux- headers-`uname -r`
#apt-get install libncurses5-dev bison libssl-dev libcap-dev libnewt-dev zlib1g-dev procps
gcc g++ make binutils doxygen

Promotion : 2009 – 2011 20


Une fois à l'intérieur du dossier créé précédemment lors de la décompression de l'archive
(.tar.gz) de Asterisk, nous aurions à exécuter quelques commandes qui compileront et
installeront Asterisk sur le système.
#cd /usr/local/Asterisk-1.4.42
#./configure
#make menuselect (optionnel : pour vérifier que toutes les dépendances sont installées)
#make
#make install
#make samples

Par défaut Asterisk supporte le protocole SCCP à travers le fichier de configuration
skinny.conf. Mais nous installons Chan_sccp_b à Asterisk qui offre plus de
fonctionnalités que celui-ci.
Nous téléchargeons le paquet Chan_CISCO-3.0_RC3.tar.gz sur
http://sourceforge.net/projects/chan-sccp-b/ ensuite nous le désarchivons dans /usr/src/ :
#tar -xvzf Chan_CISCO-3.0_RC3.tar.gz -C /usr/src
# cd /usr/src/Chan_SCCP-3.0_RC3/
#./configure
#make
#make install

Après l'installation nous démarrons le serveur Asterisk:
#Asterisk
#Asterisk -rvvv

Dans le fichier modules.conf, nous chargeons le module chan_sccp.so afin qu'il soit pris
en compte par Asterisk et nous déchargeons le module chan_skinny.so afin d'arrêter son
fonctionnement :

modules.conf
load => chan_sccp.so
noload => chan_skinny.so

Nous copions ensuite le fichier sccp.conf dans le répertoire d’Asterisk :
#cp /usr/src/Chan_SCCP-3.0_RC3/conf/sccp.conf /etc/Asterisk/

Comme nous l’avons vu dans « II.1 - présentation et scénario de fonctionnement », le
téléphone doit pouvoir s’authentifier au niveau d’Asterisk pour avoir une ligne. Donc
nous devons ajouter dans le fichier sccp.conf les informations relatives au téléphone. Cela
se fait comme avec les autocommutateurs traditionnels en ajoutant tout d’abord
l’équipement ainsi que ces paramètres ensuite nous ajoutons une ligne correspondant à un
numéro de téléphone et enfin on associe l’équipement à la ligne créée.
Voici un exemple de configuration dans sccp.conf de notre CISCO IP Phone Séries
7912 :
Promotion : 2009 – 2011 21


Sccp.conf
[SEP000D657072B5]; Ajout de l’équipement en mettant l’adresse mac.
type = device ; Nous spécifions que ce format ou cette configuration est celui d’un équipement.
devicetype = 7912 ; Type d’équipement.
description = CIP 7912 N.1005 ; une description du téléphone.
button = line, 1005 ; On associe la ligne 1005 à cet équipement.
button = line, Hotline ; Nous lui associons aussi une ligne qui mène vers le service support si
besoin d’information.
tzoffset = +2 ;
transfer = off ; Activation ou désactivation de la capacité de transfert d’appel du téléphone.
cfwdall = on ; Activation de renvoi de tous les appels.
cfwdbusy = on ; Activation de renvoi de tous les appels si on est occupé.
cfwdnoanswer = on ; Activation de renvoi d’appel si pas de réponse.
dtmfmode = outband ; Quand vous appuyez une touche, Asterisk envoie un son pour vous
indiquer qu’une touche à été appuyé. La fréquence de ce son peut être dans la bande de fréquence
de la parole « inband » ou hors de la bande de fréquence «outband ». Pour les téléphones CISCO
ce son est toujours transmis hors de la bande de fréquence d’où le « outofband ».
imageversion = CP7912080003SCCP070409A ; Version du firmware du téléphone. Utile pour les
mises à jour.
deny=0.0.0.0/0.0.0.0 ; Interdire toutes les adresses IP. Il faut toujours un permit où Asterisk va
bloquer l’enregistrement du téléphone.
permit=192.168.1.0/255.255.255.0 ; Ce téléphone, pour qu’il soit accepté, il doit avoir une
adresse IP dans la plage 192.168.1.1192.168.1.254.
dnd = on ; Activation de la fonction ne pas déranger.
trustphoneip = no ; Nous ne faisons pas confiance à l’adresse IP du téléphone au cas où il est
derrière un NAT.
nat = off ; l’équipement supporte le NAT.
directrtp = off ; Cette option permet que la voix ne passent plus par Asterisk mais directement
entre les équipements.
softkeyset = softkeyset ; Utilisé pour paramétrer les boutons du téléphone en différents états (en
ligne, raccrocher…).

[1005] ; Ajout de la ligne 1005.
type = line ; Spécifie que cette configuration est celui d’une ligne.
label = Votre ligne est OK ; Le label correspondant au bouton de la ligne.
description = Line 1005 ; Description au dessus de l’écran.
cid_name = CISCO 7915 N°1005 ; Le nom de cet abonné.
cid_num = 1005; Son numéro.
context = ec2lt ; le context de l’abonné.
incominglimit = 2 ; Pas plus de 2 appels entrants. L’un des appels sera en attente.
transfer = on ; Capacité de la ligne à faire un transfert.
secondary_dialtone_digits = 9; Après 9 chiffres composés la sonnerie envoyé par Asterisk quand
nous appuyons une touche change. Utile si l’utilisateur dépasse le nombre de numéro du plan de
numérotation.
secondary_dialtone_tone = 0x22 ; Sonnerie de touche clavier.
musicclass=default ; Musique par défaut quand on décroche, pendant un appel.
language=en ; Langue pour le téléphone. Utilisé pour les sonneries. Si c’est en anglais ou en
français.
echocancel = on ; Annulé l’écho.
silencesuppression = off ; S’il y a pas de parole alors Asterisk supprime le signal.

Promotion : 2009 – 2011 22


II.5 - Test de configuration

Donc au démarrage, le téléphone CISCO va demander une adresse IP au serveur DHCP qui
le lui donne et lui passe en même temps l’adresse IP du serveur TFTP. Le téléphone va
ensuite sur le serveur TFTP et cherche avant tout le fichier XMLDefault.cnf.XML et lit les
informations de mise à jour communes et ensuite s’attaque au fichier SEP[MAC
ADDRESS].cnf.xml pour des configurations personnalisées. Si en lisant l’un des fichiers ci-
dessus il se rend compte que la version du firmware est supérieur au tien, alors il va
directement lire le fichier OS[SERIES TELEPHONE].TXT qui contient le nom du nouveau
firmware sans le .sbin ou .bin à la fin. Alors il recherche ce fichier dans le même dossier ou
répertoire et lorsqu’il le trouve il se met à jour directement, redémarre et recommence le
même processus. Si le téléphone se rend compte que la version du firmware est inférieur, égal
ou différent de celui qu’il possède alors il l’ignore et continu le processus en modifiant ses
configurations. Il récupère l’adresse de l’IPBX et va se connecter dessus.
Avant de connecter les téléphones IP sur Asterisk en utilisant le fichier sccp.conf, nous allons
tester tout d’abord le bon fonctionnement des téléphones CISCO avec le fichier skinny.conf
qui est le module SCCP par défaut d’Asterisk. Voici les configurations :

Skinny.conf
[phone1]
device=SEP000D657072B5
callerid="phone1" <1000>
context=ec2lt
linelabel="telephone emeric"
line => 1000

[phone2]
device=SEP18EF639E60F4
callerid="phone2" <2000>
context=ec2lt
linelabel="telephone toto"
line => 2000

Et dans le fichier extensions.conf nous ajoutons le plan de numérotation suivant :

Extensions.conf
exten => 1000,1,dial(SKINNY/1000)
exten => 2000,1,dial(SKINNY/2000)

Maintenant que les téléphones fonctionnent et s’appellent, nous passons à la connexion des
téléphones en utilisant le fichier sccp.conf qui à été déjà configuré plus haut (Cf. II-4).

Promotion : 2009 – 2011 23


II.5.1 - CISCO IP Phone Séries 7912, 7940

Figure II-8 : CISCO IP Series 7912 Figure II-9 : CISCO IP Series 7940

Nous commençons par mettre à jour des téléphones 7912 et 7940 en les interconnectant dans
le même réseau que celui du serveur DHCP, TFTP et Asterisk.

Figure II-10 : Schéma d'interconnexion des téléphones IP Cisco

Promotion : 2009 – 2011 24


Avant mis à jour, le firmware du 7912 était : CP7912010300SCCP040312A (version 1.3)

Figure II-11 : Ancien Firmware 7912

Après mis à jour nous avons : CP7912080003SCCP070409A (version 8.0.3)

Figure II-12 : Nouveau Firmware 7912

Pour le 7940, Avant mis à jour nous avions : P0030301MFG2 (version 3.3.1)

Figure II-13 : Ancien Firmware 7940

Promotion : 2009 – 2011 25


Après mis à jour nous avons : P00308010200 (version 3.8.1)

Figure II-14 : Récupération du firmware Figure II-15 : Mise à jour du 7940

Figure II-16 : Nouveau firmware P00308010200

Voici l’écran des téléphones lorsqu’ils arrivent à se connecter dans Asterisk :
Les boutons verticaux correspondent au nombre de lignes qu’on peut attribuer à un téléphone.
Les boutons horizontaux sont configurables aussi dans sccp.conf au niveau des softskeys.

Figure II-17 : Ecran de connexion à Asterisk 7912 Figure II-18 : Ecran de connexion à Asterisk 7940

Promotion : 2009 – 2011 26


Les traces de toute la procédure d’auto provisioning se trouve dans (ANNEXE-1).

II.5.2 - ATA188

Figure II-19 : Photo de l'ATA 188

L'adaptateur de téléphone analogique CISCO ATA 188 connecte des téléphones analogiques
courants avec des réseaux de téléphonie IP.

Figure II-20 : Schéma d’interconnexion de l’ATA188
Promotion : 2009 – 2011 27


Configuration d’Asterisk et de l’ATA188 :
La configuration est presque la même que celle des téléphones CISCO à la seule différence
que le fichier SEP[Adresse Mac IP PHONE].cnf.xml est remplacé par ATA[Adresse Mac de
l’ATA].cnf.xml et nous devons ajouter un deuxième fichier qui doit être le fichier par défaut
possédant les configurations par défaut de tous les ATA. Ce fichier doit être en binaire. Ce
fichier s’appelle atadefault.cfg. Pour l’avoir, on récupère l’archive de mise à jour du firmware
SCCP de l’ATA. Dans cette archive se trouve un fichier sk_example.txt qui contient les
configurations par défaut de l’ATA. Nous modifions CA0 (call manager) en mettant l’adresse
IP du serveur Asterisk.
CA0 : 192.168.1.1 (Dans un réseau de production il faut toujours avoir un autre serveur
Asterisk de secours au cas où celui-ci tombe. Donc au niveau de CA1 on va mettre l’adresse
IP du deuxième serveur Asterisk).

Ensuite nous devons convertir le fichier sk_example.txt en atadefault avec :
./cfgmt.linux (nous sommes toujours dans le dossier de l’archive décompresser).

Nous ajoutons l’extension .cfg à atadefault et nous le mettons ainsi que tous les fichiers de
mise à jour et le fichier ATA0013808DA533.cnf.xml dans le dossier racine du serveur TFTP
(/tftpboot) et nous connectons l’ATA dans le réseau. Il ne reste plus qu’à ajouter
l’équipement et la ligne à l’ATA dans le fichier sccp.conf. Il faut comprendre qu’à chaque
équipement il faut une adresse MAC pour pouvoir sonner le téléphone désiré. Notre ATA188
possède en fait deux adresses MAC correspondant aux deux équipements analogiques qu’on
peut connecter. Mais sur l’équipement on ne met qu’une adresse MAC de l’ATA qui
correspond en général au téléphone analogique du port 0. Donc pour connaître la seconde
adresse MAC nous cherchons les équipements détectés par Asterisk mais ne possédant pas de
ligne avec la commande :
Asterisk>show sccp lines

Et nous avions pu repérer la deuxième adresse mac qui était ATA13808DA53301.
Maintenant nous définissons les deux équipements correspondant aux deux adresses MAC de
l’ATA188 et les deux lignes correspondantes.

Sccp.conf
[ATA0013808DA533]
type = device
devicetype = ata
description = Analog Phone 0
button = line, 1002
tzoffset = +2
transfer = off
dtmfmode = outband
deny=0.0.0.0/0.0.0.0
permit=192.168.1.0/255.255.255.0
trustphoneIP = no
Promotion : 2009 – 2011 28


NAT = on

[1002]
type = line
label = Analog Phone
description = Analog Phone ATA Port 0
cid_name = Analog Phone 1002
cid_num = 1002
context = ec2lt
secondary_dialtone_digits = 4
secondary_dialtone_tone = 0x22
musicclass=default
language=en
echocancel = on
silencesuppression = off

[ATA13808DA53301]
type = device
devicetype = ata
description = Analog Phone 1
button = line, 1003
tzoffset = +2
transfer = off
dtmfmode = outband
deny=0.0.0.0/0.0.0.0
permit=192.168.1.0/255.255.255.0
trustphoneip = no
nat = on

[1003]
type = line
label = Analog Phone
description = Analog Phone ATA Port 1
cid_name = Analog Phone 1003
cid_num = 1003
context = ec2lt
secondary_dialtone_digits = 4
secondary_dialtone_tone = 0x22
musicclass=default
language=en
echocancel = on
silencesuppression = off

Nous redémarrons Asterisk pour qu’il prenne en compte les modifications.

Promotion : 2009 – 2011 29


II.6 - Difficultés rencontrées et insuffisances

L’une des difficultés est l’arrêt inopiné d’Asterisk lorsque le module chan_sccp est utilisé.
Elle est plus récurrente avec la version 1.6 d’Asterisk. La version 1.4 d’Asterisk est plus
stable. Cette pour cette raison que nous ne conseillons pas son utilisation pour le moment
dans un environnement de production.
L’autre difficulté rencontrée pendant nos tests, est la nécessité de redémarrer Asterisk pour
prendre en compte les modifications apportées dans le fichier sccp.conf ce qui conduit à
arrêter les communications en cours. Ce problème étant assez grave, nous avions décidé de
mettre toutes les configurations du fichier sccp.conf dans une base de données externe
(MySQL). Ainsi au lieu de recharger à chaque fois le fichier sccp.conf, Asterisk ira
directement dans la base de données MySQL qu’on n’aura pas besoin de recharger.
La procédure est clairement expliquée sur le site de chan_sccp ( http://chan-sccp-
b.sourceforge.net/doc/setup_sccp.html#sccp_config_sep ). Nous utilisons MySQL 5.0 et donc
la procédure qui suit concerne la version 5.0 de MySQL.
Pour commencer nous devons installer dahdi-linux et dahdi-tools pour que Asterisk puissent
se connecter avec la base de donnée MySQL.
#wget http://downloads.Asterisk.org/pub/telephony/dahdi- linux-complete/releases/dahdi-
linux-complete-2.4.1.2+2.4.1.tar.gz
#wget http://downloads.Asterisk.org/pub/telephony/Asterisk/releases/Asterisk-addons-
1.4.13.tar.gz
#tar -zxvf dahdi-linux-complete-2.4.1.2+2.4.1.tar.gz
#tar -zxvf Asterisk-addons-1.4.13.tar.gz

#cd /usr/local/dahdi-linux-complete-2.4.1.2+2.4.1
#./configure
#make
#make install

#cd /usr/local/Asterisk-addons-1.4.13
#./configure
#make menuselect (optionnel : pour vérifier que toutes les dépendances sont installées)
#make
#make install

Nous nous déplaçons dans le dossier source de Chan_sccp_b.
#cd /usr/src/Chan_SCCP-3.0_RC3/
# mysql -p asterisk < conf/mysql-v5.sql

Nous modifions le fichier /etc/asterisk/res_mysql.conf :

Promotion : 2009 – 2011 30


res_mysql.conf
[general]
;dbhost = 127.0.0.1 ; Adresse IP de la machine hébergeant la base de donnée MySQL
;dbport = 3306 ; port par défaut de MySQL
dbname = asterisk ; Nom de la base de donnée utilisée par Asterisk
dbuser = Asterisk ; A remplacer par le nom d’utilisateur d’accès à la base de donnée
dbpass = Asterisk_password ; A remplacer par le mot de pass d’accès à la base de données
dbsock = /var/lib/mysql/mysql.sock ou /var/run/mysqld/mysqld.sock sur Debian squeeze

Nous ajoutons ces deux lignes dans le fichier /etc/asterisk/sccp.conf

sccp.conf
devicetable=sccpdevice ; Base de données pour les équipements
linetable=sccpline ; Base de données pour les lignes

Nous modifions le fichier /etc/asterisk/extconfig.conf :

extconfig.conf
[settings]
sccpdevice => mysql,asterisk,sccpdeviceconfig ; sccpdeviceconfig sera utilisé au lieu de
sccpdevice
sccpline => mysql,asterisk,sccpline

Nous nous connectons à la base de données d’Asterisk

#mysql -u « nom d’utilisateur » -p
#password : « mot de pass »
MySQL>use database asterisk;

MySQL>insert into sccpdevice
(type,description,tzoffset,dtmfmode,mwilamp,mwioncall,pickupexten,pickupmodeanswer,pri
vacy,name) values ("7975","My 1st
Phone",0,"on","on","on","on","on","full","SEP010102030404");

MySQL>insert into sccpline
(id,pin,label,description,context,incominglimit,transfer,mailbox,vmnum,cid_name,cid_num,tr
nsfvm,secondary_dialtone_digits,secondary_dialtone_tone,musicclass,language,accountcode,
audio_tos,audio_cos,video_tos,video_cos,echocancel,silencesuppression,callgroup,pickupgro
up,amaflags,setvar,name) VALUES(121,212,"Line 121","Line
121","internal",2,"on",121,88121,"My
Name",121,89121,10,"0x22","default","en",121,"0xB8",6,"0x88",5,"on","off","1,3-5","3-
5","","","121");

MySQL> insert into buttonconfig (device,instance,type,name,options) VALUES
("SEP010102030404",1,"line",121,"");

Promotion : 2009 – 2011 31


MySQL> insert into buttonconfig (device,instance,type,name,options)
VALUES("SEP010102030404",2,"speeddial","friend","122,122@hints");
VALUES("SEP010102030404",3,"feature","dnd","busy");

VALUES("SEP010102030404",4,"feature","cfwdbusy","122");

Maintenant nous pouvons relancer Asterisk:
#asterisk -rvvv
Asterisk CLI>stop now
#asterisk
#asterisk -rvvv

Maintenant Asterisk en plus de sccp.conf, utilise aussi la base de données MySQL pour
authentifier un équipement.

Nous avons eu à configurer en masse des téléphones CISCO en utilisant le TFTP qui est un
protocole non sécurisé donc ne peut être utiliser qu’en local dans un même site mais qu’en
est- il des téléphones distants se trouvant dans des sites différents et reliés à internet. Les
téléphones IP devront traverser un NAT, passer par internet et allés s’auto-configurer sur le
site distant ayant Asterisk. Ici nous ne pourrions plus utiliser le TFTP par mesure de sécurité
mais le HTTP ou HTTPS. Donc le téléphone IP au démarrage va aller sur un site web (HTTP
ou HTTPS) sur lequel nous allons demander le login et le pass à l’employé. Après s’être
authentifié, le téléphone va se configurer et se mettre à jour et enfin se connecter à l’IPBX.
Cette solution est très utile si on fait du clustering d’Asterisk (plusieurs IPBX Asterisk
connectés entre eux et éparpillés sur plusieurs sites avec lesquels on fait aussi du partage de
charge.). Si l’un des Asterisk tombe en panne, tous les téléphones connectés à ce site doivent
pouvoir basculer vers un autre IPBX Asterisk sur un autre site distant. Pour cela il faut avoir
une base de donnée maître et des bases de données esclaves et redondants.

Mais maintenant que nous avons réussi à configurer à distance plusieurs types de téléphones
CISCO et de les mettre à jour, une deuxième problématique se présente. Comment intégrer
les contacts de l’entreprise ou université dans ces téléphones IP CISCO ?

Promotion : 2009 – 2011 32


Chapitre III : Gestion des contacts

Promotion : 2009 – 2011 33


III.1 - Présentation

Pour résoudre ce problème, nous créons une base de données contenant tous les contacts de
l’entreprise et nous faisons en sorte que les téléphones CISCO puissent y accéder à distance.
En effet, les téléphones CISCO ont la possibilité, de lire du code PHP et d’afficher le résultat
sur leur écran, ce qui nous sera utile pour afficher les contacts se trouvant sur le serveur web
distant.
Pour expliquer le principe de fonctionnement, nous allons reprendre le schéma de
fonctionnement de l’auto provisioning auquel nous allons ajouter le serveur web :

Figure III-21 : Principe de fonctionnement de gestion de contacts distant

Après avoir interrogé le serveur TFTP, le téléphone CISCO récupère ses fichiers de
configurations. Dans ces fichiers de configurations écrits en XML, nous allons indiquer, en

Promotion : 2009 – 2011 34


plus du serveur IPBX (Asterisk), celui du serveur WEB dans lequel sont stockés les contacts
de l’entreprise. Donc le téléphone CISCO, en récupérant ses fichiers de configurations,
récupère aussi l’adresse IP du serveur WEB. Ensuite, lorsque l’employé veut le numéro d’une
personne, le téléphone va interroger le serveur WEB. Le serveur WEB répond au téléphone
en donnant tous les numéros appartenant à cette personne.
Comme nous pouvons le remarquer sur le schéma ci-dessus, pour afficher les contacts sur
le téléphone, nous n’avons pas besoin du serveur Asterisk. Néanmoins Asterisk devient
nécessaire quand il faut appeler ces contacts.

III.2 - Logiciels et Technologies utilisées
Pour la mise en œuvre de cette solution, nous avons eu besoin de tous les logiciels et
équipements utilisés dans la mise en œuvre de l’auto provisioning (serveur DHCP, serveur
TFTP, serveur Asterisk, téléphones IP CISCO, Switch) auquel nous ajouterons un serveur
WEB. Un serveur WEB est un logiciel permettant de rendre accessibles à de nombreux
ordinateurs (les clients) des pages web stockées sur le disque du serveur. Il est aussi appelé
serveur HTTP.

L'installation suivante comprend l'installation de l'interpréteur PHP, un langage de
programmation permettant de créer des pages créées dynamiquement, ainsi que MySQL, un
système de gestion de bases de données relationnelles puissant fonctionnant sous Linux
Debian.

III.3 - Installation et Configuration

Serveur TFTP
La procédure d’installation à déjà été faite (Cf. II-4). La seule modification à apporter se
trouve dans le fichier SEP000D657072B5.cnf.xml dans lequel nous allons indiquer le serveur
WEB ainsi que le fichier en PHP que le téléphone va lire.

SEP000D657072B5.cnf.xml
<directoryURL>http://192.168.1.1/contacts/PhoneDirectory.php</directoryURL>
<servicesURL>http://192.168.1.1/contacts/services.php</servicesURL>

La balise <directoryURL></directoryURL> permet d’indiquer le lien menant vers le
répertoire de contacts. Et le <servicesURL></servicesURL> permet d’indiquer le lien vers
d’autres services. Nous utilisons la balise <servicesURL> pour pouvoir ajouter le service de
recherche dans la base de données des contacts et le service d’aide aussi.

Promotion : 2009 – 2011 35


Serveur Apache
Il nous faut installer un serveur HTTP qui va s'occuper d'afficher nos différentes pages.
Pour cela, nous allons installer l'un des serveurs le plus utilisé et le plus connu : Apache.
# apt-get install apache2

Nous testons l'installation d'apache : http://localhost: nous avons une page nous indiquant que
tout est ok.
Il va créer un dossier www (/var/www sur Debian) dans lequel nous allons mettre les pages
PHP qui seront lues par les téléphones CISCO.

Serveur PHP
Pour que le serveur puisse exécuter du code PHP et renvoyer le résultat, il faut installer
cette extension php5.
# apt-get install php5

Maintenant nous allons créer un dossier « contacts » et nous allons y mettre les pages PHP à
utiliser pour afficher les contacts sur les téléphones CISCO. Le code source de ces pages ainsi
que l’explication de son fonctionnement se trouve dans ANNEXE-2 à la fin de ce mémoire.
Et dans le fichier XML du serveur TFTP, nous allons mettre les liens pointant sur ces pages
PHP comme indiquer dans (Serveur TFTP) ci-dessus.

Serveur MySQL
PHP est très souvent couplé à un système de base de données : MySQL. Nous installerions ici
Mysql-server version 5. Vous verrez plus bas que nous allons également installer
phpmyadmin. Il s'agit d'un script PHP qui permet de gérer ses bases de données MySQL de
façon très simple à travers le navigateur.
# apt-get install mysql-server
Nous vérifions que MySQL fonctionne bien :
# mysql -p
Entrons le mot de passe
>exit;

Nous installons les librairies php5-mysql pour pouvoir accéder à la base de données MySQL
avec nos pages PHP:
# apt-get install php5-mysql

Nous installons PhpMyAdmin :
# apt-get install phpmyadmin
Choix du serveur dans les paramètres de configuration qui s’affichent pendant l’installation :
Apache2
Nous redémarrons Apache quand proposé
Nous nous connectons sur l'adresse http://localhost/phpmyadmin
Promotion : 2009 – 2011 36


Maintenant que tout est bien installé, Nous allons créer la base de donnée que nous allons
utiliser pour stocker tous les contacts à afficher sur le téléphone.
Nous nous loguons dans MySQL en ligne de commande.
#mysql -u root -p
#Nous entrons le mot de pass root.
Nous créons la base de données pour les contacts « astcontacts » :
>create database astcontacts;
Nous nous connectons sur la base « astcontacts » :
>Use astcontacts;

Nous créons une table « contacts » dans lequel nous allons ajouter les paramètres de ces
contacts comme le nom, le prénom, numéro maison (phone_home), numéro mobile
(phone_mobile), numéro de travail (phone_work), autre numéro (phone other):

>CREATE TABLE contacts (
id MEDIUMINT NOT NULL AUTO_INCREMENT,
first_name varchar(100) default NULL,
last_name varchar(100) default NULL,
phone_home varchar(25) default NULL,
phone_mobile varchar(25) default NULL,
phone_work varchar(25) default NULL,
phone_other varchar(25) default NULL,
PRIMARY KEY (id),
KEY idx_cont_last_first (last_name,first_name)
)TYPE=MyISAM;

Pour ajouter les contacts en ligne de commande :
>INSERT INTO contacts (
first_name, last_name, phone_home, phone_mobile, phone_work, phone_other)
VALUES (
'Emeric','Kamleu','5555551170','5555555212','5555555200','5555554685'
);

Sinon nous pouvons aussi utiliser phpmyadmin (http://localhost/phpmyadmin) pour insérer
les contacts. Une page s’affiche et nous demande le login et le mot de pass. Ensuite nous
cliquons sur la base de données « astcontacts » dans le panneau de gauche ; nous cliquons sur
la table « contacts » et pour ajouter un contact on clique sur « insert ».

Nous allons sur la base de données MySQL pour créer un nouvel utilisateur:
>use mysql;

Nous ajoutons l’utilisateur CISCO :

Promotion : 2009 – 2011 37


>INSERT INTO user (Host,User,Password)
VALUES('localhost','CISCO',PASSWORD('CISCO'));

Nous lui donnons les droits :
>grant usage on *.* to CISCO@localhost identified by 'CISCO';

Nous lui donnons l’accès :
>grant all privileges on *.* to CISCO@localhost;

Nous mettons à jour les privilèges :
>FLUSH PRIVILEGES;
>exit;

Nous testons l’utilisateur :
#mysql - u CISCO - p CISCO
>use astcontacts;
>select * from contacts;
Le résultat va afficher les contacts insérés plus haut en ligne de commande.

III.4 - Test de configuration

Les liens menant vers le répertoire de contact et les services complémentaires (la recherche
d’un contact, etc…) ajoutés dans le fichier XML du serveur TFTP sont chargés au démarrage
par le téléphone IP. Donc si nous modifions les liens dans SEP000D657072B5.cnf.xml, le
téléphone ne le prendra en compte qu’au redémarrage.
Maintenant quand nous cliquons sur le bouton répertoire, le téléphone IP va sur le serveur
web lire le fichier PHP correspondant et affiche le résultat.

Figure III-22 : Répertoire de contacts Figure III-23 : Contacts de Mr Mamadou Barry

Nous avons aussi eu à implémenter des services complémentaires comme la recherche dans
les contacts.

Promotion : 2009 – 2011 38


Figure III-24 : Recherche du contact Ouya Figure III-25 : Contact Samuel Ouya trouvé

Ainsi que l’aide.

Figure III-26 : Service d'aide

III.5 - Difficultés rencontrées et solutions

Il est possible d’utiliser directement un fichier en XML que le téléphone va lire pour
afficher les contacts.
Ex : http://192.168.1.1/contacts/PhoneDirectory.xml
La structure du fichier PhoneDirectory.xml sera :

PhoneDirectory.xml
<CiscoIPPhoneDirectory>
<Title>Contacts IGTTT</Title>
<Prompt>Selectionner un numéro pour appeler</Prompt>
<DirectoryEntry>
<Name>Le Chef: Akori </Name>
<Telephone>11293110122</Telephone>
</DirectoryEntry>
<DirectoryEntry>
<Name>Toto</Name>
<Telephone>toto</Telephone>
Promotion : 2009 – 2011 39


</DirectoryEntry>
</CiscoIPPhoneDirectory>

Cette méthode fonctionne mais elle est limitée car ne fonctionne pas sur tous les séries de
téléphone; ne peut afficher qu’au maximum 32 contacts et n’affiche qu’un numéro de
téléphone par contact. Le téléphone ne pouvant qu’afficher 32 contacts au maximum, si on en
ajoute un de plus dans ce fichier, le téléphone va afficher des erreurs. Donc il est plus utile
pour les petites entreprises de moins de 33 employés.

La deuxième difficulté vient du fait que les différentes séries des téléphones IP CISCO
lisent de manière différente le code PHP. Lors de nos test, les téléphones IP CISCO 7912
lisaient sans problème le fichier d’affichage des contacts et affichait le résultat. Mais le
téléphone IP CISCO 7940 en lisant le même fichier affichait des erreurs tout simplement
parce que dans ce code PHP, il y avait deux fonctions « echo » (un echo pour exécuter des
paramètres et un autre pour afficher le résultat). Le « echo » est utilisé en PHP pour afficher
des informations à l’écran où exécuter des paramètres. Or le CISCO IP phone 7940 lorsqu’il
rencontre un « echo » dans le code PHP, il sait que ce n’est que pour afficher un résultat.
Donc il s’attend à une structure XML contenant des contacts à afficher. Si le « echo » sert à
exécuter des paramètres, le téléphone ne comprend pas et affiche des erreurs. C’est pour cette
raison que nous avons effectué des modifications aux différents codes utilisés pour afficher
les contacts comme sur les autres séries. Ces nouveaux codes compatibles avec tous les
téléphones seront ajoutés à l’annexe-2.

Ayant testé cette solution, nous avons remarqué que ça prend du temps pour rechercher un
contact ou parcourir tous les contacts dans le répertoire. Et plus le nombre de contacts
augmente, et plus le temps de retrouver un contact augmente. Pour améliorer l’ergonomie,
nous pouvons essayer de voir dans quelle mesure implémenter la prédiction d’appel. Donc au
lieu de rechercher dans le répertoire de contacts ou parcourir ce même répertoire, nous
pouvons juste commencer à composer le nom, prénom ou numéro et le téléphone va
rechercher dans la base de données les contacts correspondants à ce nom, prénom et numéro
et le proposer en temps réel à l’appelant.

Nous avons remarqué dans certains pays comme le Sénégal, la plupart des habitants ont le
ou les mêmes noms (mamadou, diouf, aliou, fatou, etc…). Donc dans une entreprise comme
la Sonatel par exemple qui possède des milliers d’employés repartis sur plusieurs sites, le
répertoire de contacts peut contenir des doublons ; ce qui va poser des problèmes pour choisir
la bonne personne à appeler. Nous pouvons réduire ce nombre de doublons en ajoutant dans
chaque contact le champ description pour préciser ses fonctions dans la société et permettre
les appels par adresses mail si on utilise dans Asterisk les appels par noms. Donc nous
pourrions différencier les employés par site ou département.
Ex : par site on aura mamadou.diouf@sonatel-dakar et mamadou.diouf@sonatel-thies. Ou
par département aliou.diagne@comptabilité et aliou.diagne@technique.

Promotion : 2009 – 2011 40


Pour réduire la congestion dans un réseau, nous allons dans la suite implémenter les
échanges de présence entre les abonnés. Ces échanges de présence vont permettre aux
abonnés de n’appeler que lorsque leur correspondant est disponible et donc réduire les
signalisations inutiles (appels vers un correspondant en communication, occupé ou
déconnecté du réseau).

Promotion : 2009 – 2011 41


Chapitre IV : PRESENCE

Promotion : 2009 – 2011 42


IV.1 - Présentation

La présence est définie comme suit:
" Mise à jour dynamiquement des informations sur l'état des entités sélectionnées, où
l'information, les états, la sélection et la dynamique de mise à jour sont variables et adapté à
l'application".
Avant la présence se limitait au statut "en ligne", "déconnecté", "occupé" dans la messagerie
instantanée. De nos jours, la présence peut s’appliquer à la téléphonie et couplée avec
d’autres technologies, fournir des services variés. Maintenant la présence n’est plus liée qu’au
statut ; c’est aussi la disponibilité pour différents services (suis-je disponible à accepter des
appels, à accepter des SMS, à une (vidéo) conférence où avec qui je veux discuter?) ; c’est
aussi donné ma localisation (je suis à la maison, au boulot, à l’école). Toutes ces informations
de présence peuvent être données manuellement ou automatiquement en utilisant des
applications ou technologies tierces comme le logiciel de calendrier, téléphone, la
domotique, la voiture, la géolocalisation, blog, etc...

Figure IV-27 : Processus de fonctionnement de la présence. Bob publie ses informations de
présence à travers plusieurs types d’applications (GPS, calendrier, soft phone, blog) et ses
contacts, Alice et Sara sont immédiatement notifier.

Sans tenir compte de la multitude de services qu’il peut offrir, La présence est importante
dans un réseau de téléphonie car si l’appelant en consultant ses contacts se rend compte que
celui avec qui il veut correspondre n’est pas disponible, alors l’appelant ne va pas appeler et
donc moins de gaspillage de bande passante et une meilleure gestion des ressources.

Promotion : 2009 – 2011 43


IV.2 - Solution retenue

Il existe deux types de protocoles de présence ouvert : XMPP et SIP/SIMPLE.

SIMPLE est un protocole informatique. Le sigle signifie: "SIP for Instant Messaging and
Presence Leveraging Extensions (simple)". SIMPLE applique le protocole Session Initiation
Protocol (SIP) aux problèmes concernant:
L'inscription pour avoir des informations sur la présence ou non d'une personne et la
réception des notifications quand l'information de présence change. Par exemple,
quand un utilisateur se logue sur son poste ou revient du déjeuner.
L'envoi de petit message, tels que les SMS.
La gestion d'une conférence.
L'implémentation des bases du protocole SIMPLE peut être trouvée dans les SIP Softphones
(X-Lite, Lotus Sametime, SIP Communicator) et les SIP Hardphones.

Après plusieurs années de formats propriétaires (Yahoo Messenger, MSN…), l'IETF a
entériné un standard de messagerie instantanée : XMPP, pour Extensible Messaging and
Presence Protocol (protocole extensible de messagerie et de présence).
Basé sur XML et issu du projet Open Source Jabber et ses nombreuses implémentations, ce
protocole a depuis été utilisé au sein de l'outil de messagerie Google Talk, ainsi que dans
d'autres projets.
XMPP n'est pas le seul protocole établi par l'IETF : SIP/SIMPLE (pour Session Initiation
Protocol for Messaging and Presence Leveraging Solutions) y est également un standard. SIP,
bien qu'encore au stade de l'élaboration, est en partie implémenté dans les récentes versions
de Windows Messenger.
L'avantage premier de XMPP est d'être basé sur XML. Celui lui ouvre des possibilités
d'extension inaccessibles à SIP. Grâce à cela, XMPP peut être utilisé dans des applications et
systèmes très divers.

Cependant nous avons retenu la solution SIP/SIMPLE à implémenter car le protocole SIP
est largement utilisé de nos jours par les téléphones logiciels comme matériels et la plupart
peuvent supporter le SIMPLE à travers une mise à jour du firmware si ce n’est pas déjà le
cas. De l’autre côté, le protocole XMPP est supporté par peu de téléphones logiciels et très
rarement supporté par les téléphones matériels. Toutefois on peut implémenter la présence
sur Asterisk avec le XMPP en utilisant Openfire.

Promotion : 2009 – 2011 44


IV.3 - Logiciels et Equipements utilisés

Pour implémenter le SIP/SIMPLE, nous avons eu à tester plusieurs solutions dont :
Opensips, Kamailio. Mais ces deux logiciels ne font que récupérer et envoyer les
informations de présence à ceux qui le demandent même ceux non autorisés. C’est pour cette
raison que nous utilisons un autre serveur chargé d’appliquer les politiques de présence qui
utilise le protocole XCAP.
XCAP (XML Configuration Access Protocol) est un protocole applicatif permettant à un
client de lire, écrire et modifier des informations de configuration stockées sur un serveur
dans un format XML. L’accès à ces fichiers de configuration se fait avec le protocole http.
Un serveur XCAP est utilisé par des clients XCAP pour stocker des donnés telles que des
listes de contacts et des politiques de présence en coopération avec un serveur de présence
SIP supportant les méthodes PUBLISH, SUBSCRIBE et NOTIFY afin de fournir une
solution complète de serveur SIP SIMPLE.
Donc après avoir testé Opensips (serveur de présence) avec Openxcap (serveur de politique
de présence) d’une part, et Kamailio (Comme serveur de présence et en même temps serveur
de politique de présence) d’autre part, nous avons retenu la solution Kamailio pour
différentes raisons :
Kamailio intègre déjà un serveur XCAP ce qui est plus intéressent si on veut installer une
solution complète de présence sur un seul et même serveur ce qui est notre cas. En plus
un module à été introduit à la version 3.1.0 de Kamailio (xhttp) qui est capable de
capturer tout type de paquet http. si c’est un paquet XCAP alors xhttp l’envoi au serveur
XCAP intégré (le module xcap_server). Donc Kamailio peut en même temps échanger les
signalisations SIP sur le port 5060 et échanger les informations XCAP en http sur le
même port 5060.

Opensips et Openxcap sont plus utilisés dans un réseau où l’on veut séparer
physiquement le serveur de présence du serveur de politique de présence car si tous les
deux sont installés dans un même serveur plus de ressources sont utilisés et il faut en plus
définir deux ports : le port du serveur de présence (par défaut 5060) et le port du serveur
XCAP (par défaut 80). Or si le serveur sur lequel on veut les installer possède déjà un
serveur web (ce qui est notre cas), il faut modifier le port d’Openxcap et l’adresse menant
à lui sur tous les clients XCAP.

Promotion : 2009 – 2011 45


IV.4 - Installation et Configuration

Figure IV-28 : Schéma d'interconnexion global avec présence

Kamailio

Nous commençons par installer Kamailio :
#cd /usr/local/src/
#git clone --depth 1 git://git.sip-router.org/sip-router Kamailio-3.1.0
#cd Kamailio-3.1.0
#git checkout -b 3.1 origin/3.1
#make PREFIX=/usr/local/kamailio-3.1-xcap FLAVOUR=kamailio
include_modules="db_mysql presence presence_xml xhttp xcap_server" cfg
#make all
#make install

Nous éditons le fichier /usr/local/kamailio-3.1-xcap/etc/kamailio/kamctlrc pour donner
SIP_DOMAIN=[le nom de domaine SIP sinon adresse IP serveur SIP] et DBENGINE=[la
base de données utilisée].

kamctlrc
SIP_DOMAIN=192.168.1.1
DBENGINE=MYSQL

Promotion : 2009 – 2011 46


Ensuite nous créons la base de données de Kamailio :
#/usr/local/Kamailio-3.1-xcap/sbin/kamdbctl create
#yes
#yes

Nous ajoutons des utilisateurs SIP dans la base de données de Kamailio :
#/usr/local/kamailio-3.1-xcap/sbin/kamctl add alice alice
#/usr/local/kamailio-3.1-xcap/sbin/kamctl add bob bob

Nous remplaçons le fichier /usr/local/Kamailio-3.1-xcap/etc/Kamailio/Kamailio.cfg par celui
présent sur cette page (http://kb.asipto.com/kamailio:presence:k31-made-simple). Donc on
copie tout le fichier indiqué par les traits rouges et nous remplaçons tout ce qui se trouve dans
kamailio.cfg.

Figure IV-29 : image du fichier à copier sur la page web

IV.5 - Test de configuration

Pour tester le fonctionnement de la présence nous allons utiliser le logiciel SIP
Communicator ou jitsi. Voici la procédure de configuration du téléphone logiciel :
Nous commençons par enregistrer un utilisateur en cliquant sur «Add New Account ».
Nous choisissons le compte SIP puis nous l’ajoutons un compte alice@adresse serveur ou
domaine ; nous mettons le mot de pass alice et nous cliquons sur advanced pour configurer la
présence.

Promotion : 2009 – 2011 47


Figure IV-30 : Ajout du compte alice dans SIP Communicator

Nous cliquons sur Enable XCAP stored contacts pour stocker les contacts sur le serveur
XCAP et nous ajoutons le lien d’écoute du serveur http://Adresse serveur ou
domaine :5060/xcap-root. Puis nous cliquons sur Next et nous nous enregistrons.

Figure IV-31 : Activation de la présence et activation du stockage sur le serveur xcap

Ensuite nous recommençons la même procédure avec bob et nous ajoutons à l’un, l’autre
comme contact puis nous acceptons l’autorisation et nous arrivons à voir l’état de l’autre.

Promotion : 2009 – 2011 48


Figure IV-32 : Alice voit bob en ligne Figure IV-33 : Bob voit aussi Alice en ligne
Lorsque nous changeons l’état de l’un l’autre s’en rend compte.

Figure IV-34 : Alice reste en ligne mais voit bob absent Figure IV-35 : Bob est absent

Figure IV-36 : Alice ne veut pas être dérangée Figure IV-37 : Bob voit Alice comme indisponible

Promotion : 2009 – 2011 49


Figure IV-38 : Alice est déconnectée Figure IV-39 : Bob voit Alice comme déconnecté

IV.6 - Difficultés rencontrées et insuffisances

L’une des difficultés vient du fait qu’à chaque mise à jour mineure comme majeure des
logiciels (Kamailio, Opensips, Openxcap), il y a des modules qui sont ajoutés, d’autres sont
supprimés, des paramètres sont ajoutés et d’autres sont retirés. Mais les tutoriels de
configuration sont rarement mis à jour pour prendre en compte les nouvelles modifications.
Donc nous devions avoir des bases en langage de programmation et en débogage pour arriver
à bien configurer ces différents logiciels (Opensips, Openxcap, Kamalio).
Une autre difficulté est dû aux logiciels qui ne supportent pas totalement la présence ni le
stockage distant. En effet l’autre fonctionnalité du serveur XCAP est la mobilité des clients.
Chaque fois qu’un téléphone ajoute des contacts dans son répertoire, ce contact est
sauvegardé sur le serveur XCAP. Donc même si nous changeons de softphone les contacts ne
seront pas perdus. Lors de nos tests, nous avons remarqué que la plupart des logiciels
supportant la présence et le stockage XCAP pouvaient seulement sauvegarder les contacts sur
le serveur XCAP mais ils ne pouvaient pas les récupérer si nous changions de client.

Une possibilité d’amélioration est de pouvoir utiliser la géolocalisation et la domotique
avec la présence. Comme exemple de service, un employé possédant un smartphone est en
entrain de rentrer chez lui et son smartphone, doté d’un outil de géolocalisation détermine sa
position constamment. Lorsque le smartphone se rend compte que l’employé est à 400 mètres
de sa maison, il envoie automatiquement un signal de présence au serveur de présence de
l’opérateur qui ensuite le notifie au serveur domotique de la maison de l’employé. Le serveur
domotique analyse le message de présence et décide d’allumer la climatisation et les lumières
dans la maison avant que l’employé n’arrive.
Un autre exemple intéressant serait par exemple d’utiliser la géolocalisation et la présence
pour autoriser les appels. En effet si nous voulons appeler par exemple une personne se
trouvant à 20-30 mètres de nous, alors le téléphone refuse de l’appeler et à la place nous
indiquent sa position géographique.

Promotion : 2009 – 2011 50


Pour lutter contre la criminalité, le vol et les agressions, la vidéo surveillance est la solution
la plus utilisée pour surveiller les locaux, les rues, etc… dans les entreprises comme dans les
universités. Seulement pour pouvoir visualiser les caméras, il faut un ou plusieurs écrans de
télévisions ou d’ordinateurs. A l’ère de la mobilité, pourquoi ne pourrions-nous pas surveiller
ces locaux avec nos téléphones. C’est pour cette raison que nous allons dans la suite diffuser
le flux vidéo de la caméra de l’ESMT sur un téléphone IP.

.

Promotion : 2009 – 2011 51


Chapitre V : Streaming

Promotion : 2009 – 2011 52


V.1 - Présentation et Scénario de fonctionnement

Le streaming est une technologie qui permet de visionner/écouter un fichier vidéo/audio au
fur et à mesure de son arrivée sur un ordinateur, par opposition au téléchargement, qui
nécessite un rapatriement total.
Le streaming est une technique de transfert de données sous forme d'un flux (Stream en
anglais) régulier et continu qui permet de diffuser des contenus multimédias sur Internet, à la
demande et en temps réel, sans solliciter le disque dur. Il utilise des formats de compression
et des protocoles adaptés permettant de distribuer et de diffuser en temps réel, via Internet,
des contenus multimédias volumineux. Le contenu est lu au fur et à mesure qu’il est stocké
en mémoire. Les applications demandant du streaming sont nombreuses. Comme exemple :
• la formation à distance permettant à des utilisateurs situés à différents endroits du globe
de suivre un cours en simultané;
• l’envoi en parallèle de flux boursiers et de nouvelles télévisées au travers d’un réseau
local IP;
• l’envoi d’une vidéo ou d’une émission TV dans le cadre de la communication dans une
entreprise, tel que l’allocution du Président ou le lancement d’un nouveau produit;
• la diffusion de chaînes TV ou de radios traditionnelles pouvant être vues et écoutées à
n’importe quel endroit de la planète via un accès Internet;
• la location d’une vidéo à distance selon le principe «VoD» (Video on Demand).
• La vidéosurveillance

Contrairement à un fichier que vous auriez entièrement téléchargé avant de le lire, les
fichiers multimédias transmis par streaming sont fortement "compressés", c'est à dire réduits
pour faciliter leur transmission et ainsi permettre leur lecture en temps réel. Ses applications
sont nombreuses, depuis la diffusion d'un morceau jusqu’à la transmission de vidéo en direct
à travers le net, Il existe deux sortes de streaming : l'un est dit "dynamique", l'autre est dit
"statique".
Aussi appelé pseudo streaming ou « faux » streaming. Le streaming statique est fait à partir
d’un serveur web habituel et utilise des protocoles HTTP et FTP. Lire en streaming statique
consiste à lire progressivement le fichier pendant son téléchargement. En fait le fichier est
téléchargé, et après quelques secondes nécessaires au chargement des premières secondes du
fichier multimédia, le navigateur commence à le lire pendant que derrière la suite du fichier
est téléchargée. Le fichier téléchargé est détruit par le navigateur après son utilisation. Ce
type de streaming permet donc d’utiliser n’importe quel type de fichier multimédia, mais il
faut que les fichiers soient préalablement stockés dans la mémoire ram, il ne peut pas
transmettre de flux en temps réel, c’est pourquoi l’on parle ici de « faux » streaming.

Dans le cas du streaming dynamique, le fichier diffusé contient plusieurs fois les mêmes
informations à différents niveaux de qualité. En fonction de la vitesse de connexion de
l'internaute, le serveur sélectionnera le niveau de qualité maximal pour une diffusion en
temps réel.

Promotion : 2009 – 2011 53


Contrairement au streaming statique, ici il n’est pas nécessaire de télécharger l’ensemble du
fichier vu que le serveur de streaming envoie au client les données en temps réel et ne sont
pas stockées comme le ferait le pseudo streaming, en effaçant automatiquement les données
après la lecture. Il n’y a donc pas de copie du média sur le disque dur du client. Il transmet le
contenu en temps réel, mais il convient aussi pour la diffusion de fichiers préenregistrés
comme le streaming statique. De plus, ce streaming s’adapte à la bande passante de
l’utilisateur, il ne va pas en utiliser plus que nécessaire. Si le flux de données est supérieur à
la bande passante disponible, la vidéo sera coupée. Le serveur est également capable de
s'adapter automatiquement aux variations de la bande passante : si la connexion se détériore
et que le taux de transfert baisse, le contenu est livré avec une moindre qualité afin d'éviter
les interruptions de diffusion. Si en revanche la connexion devient plus fluide, la qualité
s'améliore.

Pour pouvoir diffuser une vidéo en streaming sur un téléphone logiciel comme matériel, il
faut un transcodage pour pouvoir adapté le format de la vidéo à celle du téléphone.

Figure V-40 : Schéma de fonctionnement d'Asterisk

Comme on peut le voir sur le scénario de fonctionnement le téléphone doit pouvoir
composé un numéro que Asterisk va analyser et aller récupérer le flux vidéo qu’il va rediriger

Promotion : 2009 – 2011 54


sur le téléphone. Mais comme Asterisk ne peut pas transcoder la vidéo, nous allons ajouter
des modules externes qui vont s’en occuper.

V.2 - Protocoles et formats de compression utilisés

V.2.1 – Protocoles

Dans les réseaux informatiques et les télécommunications, un protocole de communication
est une spécification de plusieurs règles pour un type de communication particulier. Les
protocoles des flux vidéo permettent donc de communiquer avec le serveur pour obtenir un
flux d'informations en fonction de ses besoins. Différents protocoles ont été mis en place pour
assurer le transport des flux de données, en essayant au mieux de répondre aux pertes de
données ou délais de réception.

Le protocole TCP/IP et UDP/IP :
Son nom vient des deux principaux protocoles TCP (Transmission Control Protocol) de
niveau Transport et IP (Internet Protocol) de niveau Réseau. C’est un protocole de transport «
fiable », qui assure la réception des données dans l’ordre. En cas de perte, il assure la
retransmission et élimine les données dupliquées. L’avantage principal par rapport à l’UDP
est qu’il essaye de délivrer toutes les données correctement et en séquence.
UDP est un protocole de transport simple, sans connexion, permettant un débit optimal
mais « non fiable » : en effet ici le protocole ne garantit pas l’arrivée des paquets dans
l’ordre, si bien qu’une application doit le faire elle même. C’est un protocole utilisé pour la
diffusion multimédia.
IP s'occupe d'acheminer un paquet à l'hôte destinataire tandis que TCP et UDP (User
Datagram Protocol) assurent la communication de bout en bout entre processus applicatifs.
TCP assure le séquencement et une plus grande fiabilité de transmission qu'UDP mais il est
plus lent (vu les fonctions à mettre en œuvre, en particulier pour le contrôle de flux).

Le protocole RTP (Real-time Transport Protocol)
Le protocole de Transport en Temps Réel (RTP) est le standard proposé pour faciliter la
synchronisation et la récupération des variations de délai et de perte de paquets. RTP peut
également véhiculer des paquets multicast afin d’acheminer des conversations vers les
destinataires multiples; en fait, il a été conçu directement pour un environnement multipoint.
Le protocole est encapsulé dans un datagramme UDP.
Le rôle principal de RTP consiste à mettre en œuvre des numéros de séquence de paquets
IP pour reconstituer les informations de voix ou vidéo même si le réseau change d’ordre des
paquets, ce qui est susceptible de se produire dans la mesure où le fonctionnement d’internet
ne garantit pas que deux paquets successifs empruntent le même chemin. Cela permet, par
exemple pour des applications vidéo, de décoder et placer au bon endroit sur l’écran chaque

Promotion : 2009 – 2011 55


paquet sans attendre ses prédécesseurs et pour des applications de voix de reconstituer les
échantillons de parole.

Le protocole RTCP (Real-time Transport Control Protocol)
RTCP est un protocole de contrôle utilisé conjointement avec RTP pour contrôler les flux
de données et la gestion de la bande passante. RTCP permet de contrôler le flux RTP, et de
véhiculer périodiquement des informations de bout en bout pour renseigner sur la qualité de
service de la session de chaque participant à la session. Des quantités telles que le délai, la
gigue, les paquets reçus et perdus sont très important pour évaluer la qualité de service de
toute transmission et réception temps réelles.

Le protocole RTSP (Real Time Streaming Protocol)
RTSP a pour but d’établir et de contrôler un ou plusieurs flux synchronisés de contenu
multimédia, tels l’audio et le vidéo par exemple. Même si la spécification de RTSP lui permet
de prendre en charge la distribution de ce contenu multimédia, la distribution de ce flux sera
en général prise en charge par RTP, RTSP ayant ainsi comme seule fonction la commande du
flux. RTSP n’est pas un protocole connecté. C’est le serveur qui garde tout au long d’une
session un numéro lui permettant d’identifier les flux en cours et les clients concernés par ce
flux. Les messages de contrôle RTSP seront acheminés via une connexion qui pourra utiliser
soit UDP soit TCP et sera établie sur le port 554. Les flux multimédia seront acheminés en
utilisant un protocole quelconque de la couche de transport. C’est souvent le protocole RTP
qui est utilisé pour la transmission des flux.

Figure V-41: Requêtes RTSP

Promotion : 2009 – 2011 56


V.2.2 - Formats de compression

Pour bien comprendre la notion de format de compression, on doit comprendre la
différence entre un codec et un conteneur.
Un codec est un algorithme de compression utilisé pour réduire la taille d’un flux. Il y a des
codecs audio et des codecs vidéo.

Pour commencer, considérez un conteneur comme l’emballage d’un cadeau. Vous recevez
un cadeau le jour de votre anniversaire, vous vous posez la question : « qu’est-ce qu’il y a à
l’intérieur ?" »Vous ne vous souciez pas vraiment de la boite elle même, vous vous intéressez
plutôt à son contenu. Le problème ? Vous ne pouvez pas voir à l’intérieur de la boite. Que
faites vous donc ? Vous prenez une paire de ciseaux et vous l’ouvrez. Un conteneur se base
sur cette idée, son rôle est de réunir le son et l’image. Il contient une ou plusieurs flux déjà
encodés à l’aide de codecs. Généralement, il y a un flux vidéo et un flux audio. AVI, MOV,
ASF, MP4, etc… sont des conteneurs. Les flux contenus peuvent être encodés à l’aide de
codecs différents. On pourrait ainsi mettre n’importe quel codec dans n’importe quel
conteneur.

V.2.2.1 - Exemples de codecs audio supportés par Asterisk

G.711 : G.711 est un standard de codage de la voix utilisé principalement dans les réseaux
téléphoniques commutés mais aussi en VoIP. Échantillonnage : 8000 Hz pour une bande
passante du téléphone entre 300 et 3400 Hz. Bande passante sur le réseau : 64 ou 56 kbit/s.
Type de codage : MIC (Modulation d'impulsion codée, PCM en anglais).

G.722 : La norme de codage mondiale G.722 normalisée par l'UIT-T permet d'obtenir en voix
sur IP une qualité de voix "haute définition" (dite téléphonie large-bande). Cette qualité est
obtenue par doublement de la bande de fréquence codée (50-7 000 Hz) par rapport à la
qualité téléphonique usuelle dite bande étroite (300-3 400 Hz) produite par le format de
codage G.711 (MIC) utilisé en téléphonie "classique" sur les réseaux RTC. L'utilisateur
bénéficie donc d'une sensation de présence de son interlocuteur, d'un confort d'écoute et d'une
intelligibilité fortement améliorés.

G.723.1 : Le G.723 est normalisé pour deux taux de compression, à savoir 5.3 kbit/s et 6.4
kbit/s. Ces deux débits correspondent à deux types de codage différents, il ne s'agit pas d'un
simple ajustement. La version à 6.4 kbit/s est d'une qualité légèrement supérieure à la version
5.3 kbit/s. Ces deux codecs ont une latence algorithmique de 30 ms. Le G.723 est surtout
utilisé pour la visio-conférence et la téléphonie sur IP (VoIP), que ce soit sur signalisation
H.323 ou SIP.

Promotion : 2009 – 2011 57


V.2.2.2 - Exemples de codecs vidéo supportés par Asterisk

H.263 : À l’origine, H.263 a été développé pour la transmission de la vidéo sur des lignes à
très bas débits, pour des applications de visiophonie via le réseau téléphonique commuté de
type H.324. Elle a ensuite été intégrée dans les protocoles de visioconférence sur IP du type
H.323 mais aussi SIP. Le même codec a été repris par la norme H.324m qui permet de
réaliser des appels vidéo sur les réseaux mobiles de troisième génération.

H.263P : (appelée H.263+) ratifiée en février 1998 permet d’élargir les domaines
d’applications en étant plus flexible et en améliorant l’efficacité de codage, tout en restant
compatible avec la version 1. H.263+ n’est plus restreint pour ce qui concerne la taille de
l’image et la fréquence d’image.

H.264 : H.264 (MPEG-4 Part 10) comprend de nombreuses techniques nouvelles qui lui
permettent de compresser beaucoup plus efficacement les vidéos que les normes précédentes
et fournit plus de flexibilité aux applications dans un grand nombre d'environnements réseau.

V.2.2.3 - Exemples de conteneurs :

3gp : 3gp est un conteneur vidéo défini par 3GPP destiné au téléphone mobile de troisième
génération (3G). C'est une version simplifiée du MPEG-4 partie 14 (MP4). Les fichiers 3GP
ont pour extension .3gp ou .3g2

Mp4 : MPEG-4 Part 14 ou MP4, est une partie de la norme MPEG-4 spécifiant un format
conteneur pour encapsuler des données de type multimédia (audio ou vidéo essentiellement).
L'extension de nom de fichier généralement associée à ce format est « .mp4 » (d'où le nom «
MP4 »).

Promotion : 2009 – 2011 58


V.3 - Vidéosurveillance sur mobile

Figure V-42 : Schéma d'interconnexion global avec la vidéosurveillance sur téléphone IP

L’ESMT disposant d’une caméra IP AXIS M1011-W, nous l’avons utilisé comme source
de flux vidéo pour implémenter ce service de streaming. La caméra IP peut diffuser la vidéo
au format h.264, MPEG4-ES, MJPEG ; en plusieurs résolutions (640x480, 176x144, etc…) et
sur différents protocoles (HTTP, RTSP). Mais le problème, c’est qu’aucun de ces formats
n’est supporté ni par un téléphone IP (h.263, h.263p), ni par Asterisk d’où l’utilisation
d’applications externes app_rtsp et app_transcoder. L’application app_rtsp permet la
diffusion d’un flux RTSP sur un terminal vidéo. Si ce flux vidéo émit par l’application
app_rtsp n’est pas encodé avec un codec vidéo compatible à celui du téléphone, alors il
convient de le transcoder avec l’application app_transcoder. Donc l’utilisation de ces deux
applications permettent à Asterisk de diffuser la vidéo de la caméra ou d’un programme TV
sur le téléphone.
En supposant qu’Asterisk a déjà été installé (Cf. II-4), Je vais commencer par installer les
applications app_rtsp et app_transcoder.

Promotion : 2009 – 2011 59


V.3.1 - APP_RTSP

Nous téléchargeons les sources :
#cd /usr/src
#svn co https://Asteriskvideo.svn.sourceforge.net/svnroot/Asteriskvideo/

Ensuite nous téléchargeons le fichier d’installation d’app_rtsp sur dakarlug [W-15]
#cd /home/user/Downloads
#wget http://blog.dakarlug.org/media/29jan11/FICHIERS.zip
#unzip FICHIERS.zip -d /home/user/Documents
#cp /home/user/Documents/FICHIERS/app_rtsp/Makefile /usr/src/Asteriskvideo/app_rtsp/

Nous modifions le fichier app_rtsp.c. J’ajoute à la ligne 65 :
#define AST_MODULE "Rtsp application"

Nous compilons l’application :
#cd /usr/src/Asteriskvideo/app_rtsp/
#make
#make install

Pour vérifier que l’application a bien été chargée par Asterisk, Nous utiliserons :
#Asterisk -rvvv
#stop now
#Asterisk
#Asterisk -rvvv
*CLI>show modules
…..
app_rtsp.so RTSP applications 0
…..

V.3.2 - APP_TRANSCODER

Cette application externe à Asterisk permet de convertir un flux RTSP MPEG4-ES en flux
RTSP H.263+ compatible avec la plupart des téléphones :
#cp /home/user/Documents/FICHIERS/app_rtsp/Makefile
/usr/src/Asteriskvideo/app_transcoder/
#cd /usr/src/Asteriskvideo/app_transcoder/

Nous modifions le Makefile comme suit :
Z_LIBS := $(LIBS) -lpthread  Z_LIBS := $(LIBS) -lavcodec
BINARY = app_rtsp.so  BINARY = app_transcoder.so
OBJECTS = app_rtsp.o  OBJECTS = app_transcoder.o
Promotion : 2009 – 2011 60


Nous modifions app_transcoder.c en ajoutant la ligne :
#define AST_MODULE "Transcoder application"

Puis nous compilons l’application :
Make
Make install

La vérification est la même que celle de app_rtsp à la seule différence que nous cherchons
app_transcoder.so après avoir tapé show modules.
Maintenant nous devons apporter quelques modifications à la caméra pour pouvoir récupérer
la vidéo au bon format.

V.3.3 - Configuration Caméra AXIS

Nous connectons la caméra à note machine avec un câble croisé. Nous créons tout d’abord
un serveur DHCP (Cf. II-4) car la caméra n’a pas d’adresse fixe. Mais cette fois nous
utilisons un masque de sous-réseau 255.255.255.252 pour que le serveur n’attribue que deux
adresses (192.168.1.1 pour ma machine et 192.168.1.2 obligatoirement pour la caméra).
Nous nous connectons à la camera à l’aide du navigateur à l’adresse 192.168.1.2. Il faut
autoriser la connexion RTSP sans authentification et forcer la taille de la vidéo à 176x144.
Pour cela, dans la partie Setup  User Settings, nous cochons Enable anonymous viewer
login pour autoriser n’importe qui à accéder à la vidéo sans s’authentifier dont Asterisk. Puis
nous changeons la résolution dans Setup Video en déroulant la liste jusqu’à 176x144 pixels
dans la section Image Appearance. Nous fixons une adresse IP (ex : 192.168.1.20) à la
camera. Cette adresse fixe doit correspondre au sous réseau dans lequel nous allons le
connecter (192.168.1.0). Nous déconnectons la caméra de notre pc et nous le connectons dans
le réseau.

V.3.4 - Configuration Asterisk

Pour pouvoir transcoder et lire le flux vidéo RTSP de la caméra IP AXIS, il faut ajouter les
lignes suivantes à la fin du fichier /etc/asterisk/extensions.conf dans le contexte [esmt].

Extensions.conf
[esmt]
Exten => 8001,1,Goto(transcodage,s,1)

[transcodage]
Exten => s,1,Answer
Exten => s,2,transcode(,s@camera,h263@qcif/fps=10/kb=52/qmin=4/qmax=12/gs=50)
Exten => s,3,HangUp
Promotion : 2009 – 2011 61


[camera]
Exten => s,1,Answer
Exten => s,2,rtsp(rtsp://192.168.1.20:554/mpeg4/media.amp)
Exten => s,3,Hangup

Nous ajoutons un compte SIP pour le téléphone à la fin du fichier /etc/asterisk/sip.conf
Le contexte doit être le même que celui défini dans extensions.conf. Dans notre cas c’est
« esmt ».

SIP.conf
Videosupport=yes

[900]
language=fr
type=friend
context=esmt
secret=900
host=dynamic
username=900
disallow=all
allow=ulaw
allow=alaw
allow=g723.1
allow=g729
allow=h263
allow=h263p

V.3.5 - Test de configuration

Nous utilisons x-lite pour se connecter à Asterisk en ajoutant le login : 900, mot de pass :
900, proxy : 192.168.1.15 (adresse du serveur Asterisk). La procédure de configuration de x-
lite se trouve dans ANNEXE-3.

Promotion : 2009 – 2011 62


En appelant le 8001 Nous pouvons voir la caméra :

Figure V-43 : Affichage de la vidéo de la caméra

Figure V-44 : Vidéo de la caméra à travers le téléphone

Sur les deux figures ci-dessus, la caméra est entrain de surveiller le laboratoire de
commutation pour détecter d’éventuels intrus.

Promotion : 2009 – 2011 63


Figure V-45 : Détection d'un intrus dans le laboratoire

On dirait que la caméra a détecté un intrus.

V.4 - Problèmes rencontrés

L’application app_transcoder est limitée qu’au transcodage d’un seul codec vers un autre
(MPEG4-ES vers h.263p). Or la plupart des serveurs de streaming ne supporte pas le codec
MPEG4-ES ce qui restreint l’implémentation de cette solution qu’à quelques équipements
supportant ce codec. Une autre difficulté vient du fait que ces applications externes n’ont plus
évolué depuis 2006 ce qui rend leur installation assez difficile sur des nouvelles distributions.
Et de plus les téléphones logiciels et Asterisk supportent déjà le h.264 qui offre une qualité
d’image meilleure que le h.263 ou h.263p.

De nos jours, les Smartphones se démocratisent et ont la possibilité de lire des vidéos de
haute définition (h.264, mp4, avi, etc...). Il faut donc que les développeurs d’Asterisk
s’impliquent un peu plus dans la vidéo avec Asterisk pour en faciliter l’utilisation.
Une autre amélioration serait d’ajouter une fonction pause sur le streaming. Ainsi un
utilisateur peut commencer à regarder une vidéo sur son mobile et faire une pause et
continuer de le regarder sur sa tablette par exemple qui est connecté aussi à Asterisk.

Promotion : 2009 – 2011 64


CONCLUSION
Au cours de notre stage, il nous a été demandé de solutionner plusieurs problématiques
dont :

Pouvoir mettre à jour, configurer à distance et de manière automatique des téléphones
CISCO pour qu’ils puissent fournir des services sans aucune interaction du client ou
employé. Pour pouvoir pallier ce problème, ces téléphones IP supportaient une multitude de
technologies (DHCP, TFTP, SCCP) que nous avions utilisé. Ainsi nous avions installé un
serveur DHCP pour donner une adresse IP automatiquement aux téléphones, nous avions
installé un serveur TFTP pour modifier les configurations du téléphone et un serveur Asterisk
pour effectuer les appels. Nous avons constaté que le module chargé de gérer la signalisation
entre les téléphones CISCO et Asterisk était instable et pouvait arrêter le serveur Asterisk. Et
aussi toute modification du fichier de configuration de ce module nécessitait le redémarrage
complet du serveur Asterisk. Nous avons toutefois apporté une solution à ce problème en
mettant les configurations de ce module dans une base de données externe. Une amélioration
serait d’approvisionner ces téléphones en utilisant des protocoles plus sécurisé que le TFTP
comme le HTTP, HTTPS ou FTP.

Puis nous avons intégrer des numéros de contacts dans ces téléphones CISCO. Pour ce
faire, nous avons ajouté les contacts dans un serveur web distant sur lequel les téléphones se
connectaient pour récupérer les contacts. Nous avons constaté que tous les téléphones ne
lisaient pas les informations de la même manière ce qui nous ont poussé à améliorer le code
pour qu’il soit compatible avec le maximum de séries des téléphones CISCO. Un
prolongement possible de ce sujet serait de faire de la prédiction d’appel sur ces téléphones
ce qui permettrait de gagner plus de temps en recherche des contacts. Une autre amélioration
serait les appels par adresses mails qui permettraient d’identifier une personne de manière
unique dans une entreprise et ainsi réduire les doublons dans la base de données des contacts.

Nous avons échangé les informations de présence entre les abonnés pour qu’ils n’appellent
que lorsque leur correspondant est en ligne et ainsi limiter la congestion en utilisant le
logiciel Kamailio. Mais nous avons remarqué que le concept de présence allait plus loin que
cela et nous permettait de créer des services riches. Cependant nous avons remarqué que ce
service était encore en cours de développement à cause des bugs d’autorisations et la non
prise en compte de la mobilité des contacts par les clients XCAP. Une amélioration serait
d’utiliser la présence avec d’autres technologies comme le GPS ou la domotique pour
apporter de nouveaux services.

Enfin nous avons diffusé le flux vidéo d’une caméra de surveillance sur les téléphones
logicielles IP. Ce qui nous a permis de surveiller un local en utilisant un téléphone.
Cependant les codecs utilisés par les téléphones étant différents de ceux utilisés par les
ordinateurs et équipements de streaming, il fallait transcoder la vidéo. Pour cela nous avions
installé deux modules (app_rtsp et app_transcoder) à Asterisk : Un chargé de récupérer le
flux vidéo de la caméra et de l’envoyer au téléphone et l’autre chargé d’adapter le format de
la vidéo à celui du téléphone. Une amélioration possible serait de coupler la géolocalisation

Promotion : 2009 – 2011 65


wifi avec le streaming vidéo ce qui permettrait par exemple de diffuser une vidéo de publicité
à un endroit précis ou en fonction de notre position basculer la vidéo d’un équipement à un
autre pour un meilleur confort de visionnage.

Promotion : 2009 – 2011 66


BIBLIOGRAPHIE (B)
[B-1]. DE Gloria Gihanne Agnès," Rapport de travail EC2LT: Téléphonie sur IP ",
Dakar/Sénégal, EC2LT, 56p.

[B-2]. GNU Linux Magazine Edition N°94 (Mai 2007), "Diffusion d’un flux vidéo" dans
Voix et image sur IP : Asterisk et la vidéo, Administration et développement sur système
Unix, France, pp.55-56.

WEBOGRAPHIE (W)
[W-1]. Qu’est-ce que le XML (octobre 2008). Consulté le 22 juillet 2011.

http://www.commentcamarche.net/contents/XML/XMLintro.php3

[W-2]. Auto provisioning sur linux (octobre 2009). Consulté le 22 juillet 2011.

http://wiki.Asterisk- france.org/index.php/Auto-provisionning_avec_dhcp3-server_et_atftpd

[W-3]. Configuration serveur DHCP sur Debian (janvier 2009). Consulté le 22 juillet 2011.

http://www.debianhelp.co.uk/dhcp.htm

[W-4]. Options de configuration serveur DHCP (juillet 2005). Consulté le 22 juillet 2011.

http://www.delafond.org/traducmanfr/man/man5/dhcp-options.5.html ,

[W-5]. Mettre en place un serveur TFTP sous Debian (septembre 2008). Consulté le 22
juillet 2011.

http://imranasghar.blogspot.com/2008/09/how-to-setup-TFTP-server-on-debian.html

[W-6]. Tout sur Chan_sccp_b (décembre 2008). Consulté le 20 juillet 2011.

http://chan-sccp-b.sourceforge.net/doc/setup_sccp.html#sccp_config_sep

[W-7]. Protocol SCCP. Consulté le 22 juillet 2011.

http://www.javvin.com/protocolSCCP.html

[W-8]. Installation d’un serveur web sous Debian (Janvier 2007). Consulté le 22 juillet 2011.

http://olange.developpez.com/articles/debian/installation-serveur-dedie/?page=page_2#LII

[W-9]. Services XML pour téléphones CISCO (Juillet 2011). Consulté le 23 juillet 2011.

http://www.voIP- info.org/wiki/view/Asterisk+CISCO+79XX+XML+Services,

[W-10]. Contacts avec un serveur web (Octobre 2010). Consulté le 23 juillet 2011.
http://wiki.inisec.com/index.php/Contact_lookup_via_mysql_database
Promotion : 2009 – 2011 67


[W-11]. Appel par adresse mail avec Asterisk (Juin 2009). Consulté le 12 juillet 2011.

http://www.blyon.com/p2p-sIP- uri-dialing

[W-12]. Définition de la présence (Décembre 2010). Consulté le 28 juillet 2011.

http://en.wikIPedia.org/wiki/Presence_information

[W-13]. Protocole XMPP (Mars 2006). Consulté le 28 juillet 2011.

http://www.journaldunet.com/developpeur/tutoriel/theo/060302-protocole-xmpp-
jabber.shtml,

[W-14]. SIMPLE Working Group. Consulté le 28 juillet 2011.

http://datatracker.ietf.org/wg/simple/charter/

[W-15]. Bilan de manifestation linux de dakarlug (Janvier 2011). Consulté le 13 juillet 2011.

http://blog.dakarlug.org/2011/01/31/bilan-apres- midi-linux-290111/

[W-16]. Asterisk video ressources (mars 2008). Consulté le 24 juillet 2011.

http://web.archive.org/web/20080324184531/http://sip.fontventa.com

[W-17]. Le protocole RTSP (2010). Consulté le 2 Août 2011.

http://wapiti.telecom-
lille1.eu/commun/ens/peda/options/ST/RIO/pub/exposes/exposesser2010-ttnfa2011/rio-
jouzel/CDN_website/protocole_RSTP.html

Promotion : 2009 – 2011 68


II. TABLE DES MATIERES

Remerciements
Résumé
Sommaire
Liste des abréviations
Introduction ---------------------------------------------------------------------------------------------P.1

Chapitre I : Problématique et Contexte de l’étude ----------------------------------------- -------P.2
I.1 - Contexte --------------------------------------------------------------------- -------P.3
I.2 - Problématique -------------------------------------------------------------- -------P.3
I.3 - Présentation du lieu de stage --------------------------------------------- -------P.4

Chapitre II : Auto provisioning -------------------------------------------------------------- --------P.7
II.1 - Présentation et Scénario de Fonctionnement ---------------------------------P.8
II.2 - Solution retenue -------------------------------------------------------------------P.9
II.3 - Logiciels et EquIPements utilisés -----------------------------------------------
P.9
II.4 - Installation et Configuration ---------------------------------------------------P.10
Serveur dhcp ------------------------------------------------------------------P.10
Serveur TFTP -------------------------------------------------------------------
P.12
Serveur Asterisk --------------------------------------------------------------
P.17
II.5 - Test de configuration -----------------------------------------------------------P.21
II.5.1 - CISCO IP Phones Séries 7912, 7940 -----------------------------------
P.22
II.5.2 - ATA188 ------------------------------------------------------------------ P.24
II.6 - Difficultés rencontrées et critiques personnelles ----------------------------P.27

Chapitre III : Gestion des contacts -----------------------------------------------------------------P.31
III.1 - Présentation ---------------------------------------------------------------------P.32
III.2 - Logiciels et Technologies utilisées ------------------------------------------P.33
III.3 - Installation et Configuration --------------------------------------------------P.33
Serveur TFTP -------------------------------------------------------------------
P.33
Serveur apache ---------------------------------------------------------------P.33
Serveur php -------------------------------------------------------------------P.34
Serveur Mysql ----------------------------------------------------------------P.34
III.4 - Test de configuration ----------------------------------------------------- ----P.36
III.5 - Difficultés rencontrées et solutions ------------------------------------- ----P.37

Chapitre IV : Présence -------------------------------------------------------------------------- ----P.40
Promotion : 2009 – 2011 69


IV.1 - Présentation ---------------------------------------------------------------- ----P.41
IV.2 - Solution retenue ----------------------------------------------------------- ----P.42
IV.3 - Logiciels et EquIPements utilisés --------------------------------------- ----P.42
IV.4 - Installation et Configuration --------------------------------------------- ----P.43
IV.5 - Test de configuration ----------------------------------- ----------------- --- P.45
IV.6 - Difficultés rencontrées et critiques personnelles --------------------------P.47

Chapitre V : Streaming ------------------------------------------------------------------------------P.49
V.1 - Présentation et Scénario de fonctionnement --------------------------------P.50
V.2 - Protocoles et formats de compression utilisés ------------------------ ------P.52
V.2.1 - Protocoles ----------------------------------------------------------------P.52
V.2.2 - Formats de compression ----------------------------------------- ------P.54
V.2.3 - Exemples de codecs audio supportés par Asterisk --------------- ---
P.54
V.2.4 - Exemples de codecs vidéo supportés par Asterisk ------------ ------
P.55
V.2.5 - Exemples de conteneurs ------------------------------------------------P.55
V.3 - Vidéosurveillance sur mobile ------------------------------------------- ----- P.55
V.3.1 - APP_RTSP -------------------------------------------------------- -----P.56
V.3.2 - APP_TRANSCODER ------------------------------------------- ----- P.56
V.3.3 - Configuration camera -------------------------------------------- -----P.57
V.3.4 - Configuration Asterisk -------------------------------------------------
P.57
V.3.5 - Test de configuration -------------------------------------------------- P.58
V.4 - Problèmes rencontrés ---------------------------------------------------- ------P.60

Conclusion ---------------------------------------------------------------------------------------------P.61
Bibliographie ------------------------------------------------------------------------------------------P.63
Webographie ------------------------------------------------------------------------------------------P.63
Table des matières ------------------------------------------------------------------------------------P.65
Annexes

Promotion : 2009 – 2011 70

Document sur l'Auto provisioning, contacts, presence et streaming sur asterisk

Contenu connexe

Tendances

En vedette

Similaire à Document sur l'Auto provisioning, contacts, presence et streaming sur asterisk

Plus de Emeric Kamleu Noumi

Document sur l'Auto provisioning, contacts, presence et streaming sur asterisk