• Ce blog — désormais archivé — est en lecture seule.

Reconnaissance vocale dans une audioconférence par VoIP avec Asterisk

Asterisk, The Open Source PBX & Telephony Platform

Cet article présente mon rapport de projet tuteuré 2009.

Ce projet a pour but de réaliser une application permettant de visualiser un interlocuteur lors d’une conférence sur un serveur Asterisk.

Une première partie expliquera la voix sur IP de manière générale ainsi que les protocoles qu’elle met en œuvre. Puis nous présenterons le PABX Asterisk et ses fonctionnalités. Une troisième partie détaillera l’analyse de l’application à réaliser. Et pour terminer, l’application en elle-même sera présentée.

I – Introduction et Généralités

Le besoin

Lors d’une conférence en voix sur IP (VoIP), que ce soit avec le serveur de voix sur IP Asterisk (détaillé plus loin) ou autre, la qualité de réception (même si elle reste bonne) ne permet pas toujours de reconnaitre la personne qui parle. Quand un grand nombre de personnes établissent une réunion audio, en utilisant la fonction conférence d’Asterisk, il est bon de connaitre la personne qui est en train de parler. Cette fonctionnalité n’est pas présente dans le serveur Asterisk, ni dans aucun téléphone pouvant émettre des appels en voix sur IP (ceux-ci seront détaillés plus loin).

Il faut donc une application capable de s’intégrer au mieux à ce qui existe déjà. On ne peut pas modifier les téléphones existants. La solution est donc d’avoir une application en parallèle à côté du téléphone (si celui-ci se trouve sur un ordinateur). Pour se faire, l’application disposera de deux parties. Une sur le serveur, et une chez le participant à la conférence. Celui-ci pourra aisément reconnaitre la personne qui parle à un moment précis.

La voix sur IP

La voix sur IP ou encore VoIP pour Voice Over IP permet de communiquer par la voix via Internet ou tout autre réseau acceptant le protocole TCP/IP. Ainsi, il est possible de téléphoner par Internet et cette technologie est utilisée pour la téléphonie par Internet ToIP (Telephony Over IP).

Cette technologie se développe de plus en plus vite de nos jours parce que les infrastructures réseaux le permettent. En effet, la VoIP nécessite des temps de latence très courts et donc des débits assez importants. Avec IPv6, la qualité de service qui est incluse priorisera la voix, ce qui devrait améliorer le transfert de la voix sur IP.

La téléphonie IP est maintenant importante pour les entreprises. Voici les principales motivations pour déployer la VoIP (Source Sage Research 2003, sondage auprès de 100 décisionnaires IT).

Motivations
Pourcentage
Réduction de coûts
75 %
Nécessité de standardiser l’équipement
66 %
Hausse de la productivité des employés
65 %
Autres bénéfices de productivité
64 %
Hausse du volume d’appels à traiter
46 %
Autres facteurs
50 %

La voix sur IP utilise plusieurs protocoles réseau, pour l’établissement des connexions avec SIP, H.323 ou encore IAX et pour le transport de la voix en elle-même avec RTP et RTCP.

Pour pouvoir faire de la voix sur IP, il faut un serveur et des clients. Le serveur met en relation les clients. Pour que les clients puissent communiquer, ils doivent utiliser un téléphone sous forme applicative : un « soft phone » ou sous forme physique : un téléphone.

Un poste téléphonique physique possède une connexion dite analogique, c’est celui que la majorité des gens ont chez eux, relié au réseau téléphonique de France Télécom par une prise en T.

Un poste téléphonique numérique se connecte avec un câble Ethernet sur un réseau différent du réseau téléphonique de France Télécom. Il pourra se connecter sur un Switch POE (Power Over Ethernet) qui l’alimentera en courant et le connectera à un serveur de VoIP.

Le serveur analogique est appelé PABX (Autocommutateur téléphonique privé). Le serveur de VoIP est appelé IPBX (PABX IP ou PBX IP), c’est ce système qui assure l’acheminement de toute ou partie des communications en utilisant le protocole IP. Il est tout à fait possible de relier les deux et donc de communiquer à partir d’un système numérique vers analogique et vice-versa.

Le protocole SIP

Session Initiation Protocol (SIP) est un protocole standard ouvert de gestion de sessions souvent utilisé dans les télécommunications multimédia (son, image, etc.). Il est depuis 2007 le plus courant pour la voix sur IP.

Le protocole SIP n’est donc pas seulement destiné à la VoIP. Il a de nombreuses autres applications telles que la visiophonie, la messagerie instantanée, la réalité virtuelle ou même les jeux vidéo.

Ce protocole de signalisation appartient à la couche session du modèle OSI. Son rôle est d’ouvrir, modifier et libérer les sessions. L’ouverture de ces sessions permet de réaliser de l’audio ou vidéoconférence, de l’enseignement à distance, de la voix (téléphonie) et de la diffusion multimédia sur IP essentiellement. Un utilisateur peut se connecter avec les utilisateurs d’une session déjà ouverte. Pour ouvrir une session, un utilisateur émet une invitation transportant un descripteur de session permettant aux utilisateurs souhaitant communiquer de s’accorder sur la compatibilité de leur média. SIP permet donc de relier des stations mobiles en transmettant ou redirigeant les requêtes vers la position courante de la station appelée. Enfin, SIP possède l’avantage de ne pas être attaché à un médium particulier et est censé être indépendant du protocole de transport des couches basses.

SIP partage de nombreuses similitudes avec le protocole HTTP comme le codage en ASCII et les codes de réponse. Le client envoie des requêtes au serveur, qui lui renvoie une réponse. Les requêtes de base sont :

Invite - Cette requête indique que l’application (ou utilisateur) correspondante à l’url SIP spécifiée est invitée à participer à une session. Le corps du message décrit cette session (par ex : média supportés par l’appelant). En cas de réponse favorable, l’invité doit spécifier les médias qu’il supporte.

Ack -  Cette requête permet de confirmer que le terminal appelant a bien reçu une réponse définitive à une requête Invite.

Options - Un proxy server en mesure de contacter l’UAS (terminal) appelé, doit répondre à une requête Options en précisant ses capacités à contacter le même terminal.

Bye - Cette requête est utilisée par le terminal de l’appelé afin de signaler qu’il souhaite mettre un terme à la session.

Cancel - Cette requête est envoyée par un terminal ou un proxy server afin d’annuler une requête non validée par une réponse finale comme, par exemple, si une machine ayant été invitée à participer à une session, et ayant accepté l’invitation ne reçoit pas de requête Ack, alors elle émet une requête Cancel.

Register - Cette méthode est utilisée par le client pour enregistrer l’adresse listée dans l’URL TO par le serveur auquel il est relié.

Les codes de réponse sont les suivants :

1xx = Information – La requête a été reçue et continue à être traitée.

2xx = Succès – L’action a été reçue avec succès, comprise et acceptée.

3xx = Redirection – Une autre action doit être menée afin de valider la requête.

4xx = Erreur du client – La requête contient une syntaxe erronée ou ne peut pas être traitée par ce serveur.

5xx = Erreur du serveur – Le serveur n’a pas réussi à traiter une requête apparemment correcte.

6xx = Echec général – La requête ne peut être traitée par aucun serveur.

Exemples de codes similaires à HTTP :
  • 100 Trying
  • 200 OK
  • 404 Not Found

Les codes supérieurs ou égaux à x80 sont spécifiques à SIP.

  • 180 Ringing (sonnerie)
  • 486 Busy (occupé)
  • etc…

En revanche, SIP diffère de HTTP du fait qu’un agent SIP (User Agent, UA) joue habituellement à la fois les rôles de client et de serveur. C’est-à-dire qu’il peut aussi bien envoyer des requêtes, que répondre à celles qu’il reçoit. Il y a deux types d’UA :

  • L’UAS (User Agent Server) – Il représente l’agent de la partie appelée. C’est une application de type serveur qui contacte l’utilisateur lorsqu’une requête SIP est reçue. Et elle renvoie une réponse au nom de l’utilisateur.
  • L’U.A.C (User Agent Client) – Il représente l’agent de la partie appelante. C’est une application de type client qui initie les requêtes.


GeSHi Error: GeSHi could not find the language brushbash (using path /home/www/willdurand/wordpress/wp-content/plugins/codecolorer/lib/geshi/) (code 2)

Ce message SIP indique que l’utilisateur « willouuuuuu » tente de communiquer avec l’utilisateur « 6002 ». On voit que le soft phone de l’appelant est X-Lite.

Avantages du protocole SIP :

SIP est un protocole plus rapide. La séparation entre ses champs d’en-tête et son corps du message facilite le traitement des messages et diminue leur temps de transition dans le réseau.

Le nombre des entêtes est limité (36 au maximum et en pratique, moins d’une dizaine d’entêtes sont utilisées simultanément), ce qui allège l’écriture et la lecture des requêtes et réponses.

SIP est un protocole indépendant de la couche transport. Il peut aussi bien s’utiliser avec TCP qu’UDP.

De plus, il sépare les flux de données de ceux de la signalisation, ce qui rend plus souple l’évolution « en direct » d’une communication (arrivée d’un nouveau participant, changement de paramètres…).

Pourquoi ne pas se concentrer sur le protocole H.323 ?

H.323 est un autre protocole de gestion de sessions. Il est basé sur le monde de la téléphonie. Mais c’est un protocole propriétaire.

Ce tableau résume les différences entre SIP et H.323 :

SIP
H323
Nombre échanges pour établir la connexion
1 à 5 allers-retours
6 à 7 allers-retours
Maintenance du code protocolaire
Simple par sa nature textuelle à l’exemple de HTTP
Complexe et nécessitant un compilateur
Evolution du protocole
Protocole ouvert à de nouvelles fonctions
Ajout d’extensions propriétaires sans concertation entre vendeurs
Fonction de conférence
Distribuée
Centralisée par l’unité MC
Fonction de télé services
Oui, par défaut
H.323 v2 + H.450
Détection d’un appel en boucle
Oui
Inexistante sur la version 1un appel routé sur l’appelant provoque une infinité de requêtes
Signalisation multicast
Oui, par défaut
Non

SIP apparait comme étant beaucoup plus simple d’utilisation et de manipulation. C’est pour cela qu’il est préféré dans les applications de voix sur IP.

Skinny Client Control Protocol

Skinny Client Control Protocol (SCCP) est un protocole propriétaire CISCO utilisé pour les échanges entre le Call Manager (logiciel édité par Cisco permettant de traiter les appels dans une entreprise) et les téléphones IP (voir plus loin). 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.

SCCP s’utilise dans une architecture simple et il est facile à utiliser contrairement à H323.

Le Cisco Call Manager se comporte en proxy H323 et intègre une majorité des process H323. Il assure la gestion des événements de signalisation pour les appels initialisés en utilisant les protocoles communs tels que H.323, SIP, RNIS et/ou MGCP.

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 second 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 entre eux en utilisant RTP.

Le protocole RTP

Real-Time Protocol (RTP) est un protocole de communication. Il utilise le protocole de transport UDP qui permet l’envoi immédiat de flots de données. Il n’est pas vraiment un protocole temps réel en lui-même. RTP est un protocole de la couche application du modèle OSI.

RTP est utilisé dans les applications qui doivent être au plus proche du temps réel. Il permet ainsi de :

  • reconstituer la base de temps des flux : c’est-à-dire la possibilité de resynchroniser des flux.
  • mettre en place un séquencement des paquets, ce qui permet la détection des paquets perdus.
  • identifier le contenu des données.
  • transporter les applications audio et vidéo dans des trames.

Mais il ne garantie pas la fiabilité des échanges ni la garantie des délais de livraison, ni la continuité d’un flux temps réel. Ce n’est donc pas LA solution pour obtenir des transmissions temps réel sur IP.

Le protocole RTCP (protocole de contrôle des flux RTP) s’occupe de transmettre périodiquement des paquets de contrôle à tous les participants d’une session. Les données sont dans les paquets RTP, les contrôles dans des paquets RTCP.

RTCP envoie des informations supplémentaires liées à la session en cours et à la qualité de réception.

Il envoie des paquets de supervision, on peut les classer en 5 types :

  • 200 : rapport de l’émetteur
SR (Sender Report) : Ce rapport regroupe des statistiques concernant la transmission (pourcentage de perte, nombre cumulé de paquets perdus, variation de délai (gigue),…). Ces rapports sont issus d’émetteurs actifs d’une session.
  • 201 : rapport du récepteur
RR (Receiver Report) : Ensemble de statistiques portant sur la communication entre les participants. Ces rapports sont issus des récepteurs d’une session.
  • 202 : description de la source
SDES (Source Description) : Carte de visite de la source (nom, e-mail, localisation).
  • 203 : au revoir
BYE : Message de fin de participation à une session.
  • 204 : application spécifique
APP : Fonctions spécifiques à une application.

Ce protocole permet de mieux gérer le temps réel.

Entête RTP :

< --------------------------------------------- 32 bits ----------------------------------------------->
V=2
P
X
CC
M
PT
Sequence number
Timestamp
Identifiant de la source de synchronisation (SSRC)
Identifiants de la source de contribution (CSRC)

Le champ Version V de 2 bits de longueur indique la version du protocole (V=2).

Le champ padding P : 1 bit, si P est égal à 1, le paquet contient des octets additionnels de bourrage (padding) pour finir le dernier paquet.

Le champ extension X : 1 bit, si X=1 l’en-tête est suivie d’un paquet d’extension.

Le champ CSRC count CC : 4 bits, contient le nombre de CSRC qui suivent l’entête.

Le champ marker M: 1 bit, son interprétation est définie par un profil d’application (profile).

Le champ payload type PT : 7 bits, ce champ identifie le type du payload (audio, vidéo, image, texte, html, etc.).

Le champ séquence number : 16 bits, sa valeur initiale est aléatoire et il s’incrémente de 1 à chaque paquet envoyé, il peut servir à détecter des paquets perdus.

Le champ timestamp : 32 bits, reflète l’instant où le premier octet du paquet RTP à été échantillonné. Cet instant doit être dérivé d’une horloge qui augmente de façon monotone et linéaire dans le temps pour permettre la synchronisation et le calcul de la gigue à la destination.

Le champ SSRC : 32 bits, identifie de manière unique la source, sa valeur est choisie de manière aléatoire par l’application. Le champ SSRC identifie la source de synchronisation (ou dit simplement « la source »). Cet identificateur est choisi de manière aléatoire avec l’intérêt qu’il soit unique parmi toutes les sources d’une même session. La liste des CSRC identifie les sources (SSRC) qui ont contribué à l’obtention des données contenues dans le paquet qui contient ces identificateurs. Le nombre d’identificateurs est donné dans le champ CC.

Le champ CSRC : 32 bits, identifie les sources contribuant.

II – Serveur, téléphones et conférences

Asterisk

Asterisk est un IPBX (Private Automatic Branch eXchange-IP) open source créé en 1999 par Mark Spencer fondateur de la société Digium. Cette application, publiée sous licence GPL, permet à un ordinateur d’opérer en tant que commutateur téléphonique privé (PBX).

Il permet ainsi la téléphonie au sein d’un LAN (Local Area Network = réseau local). Asterisk permet aussi la messagerie vocale, les conférences, les files d’attente, les agents d’appels, les musiques d’attente et les mises en garde d’appels ainsi que la distribution des appels. Ce sont toutes des fonctionnalités standard intégrées directement au logiciel.

Asterisk implémente les protocoles H.320, H.323, SIP et SCCP, ainsi qu’un protocole spécifique nommé IAX (Inter-Asterisk eXchange) : ce protocole IAX permet la communication entre deux serveurs Asterisk ainsi qu’entre client et serveur Asterisk. Ces protocoles peuvent être sollicités auprès d’un fournisseur d’accès internet ou bien auprès d’un opérateur de voix sur IP. Asterisk peut également jouer le rôle de registrar et passerelle avec les réseaux publics (RTC, GSM, etc.). Asterisk est extensible par des scripts ou des modules en Perl, en C, en Python, en PHP…

Le schéma ci-dessus présente une les inter-connexions possibles entre des périphériques et le PBX Asterisk.

Les différents types de téléphones

Les soft phone SIP / VoIP – téléphone SIP sur logiciel

Le soft phone est un programme qui emprunte les haut-parleurs et les microphones des ordinateurs, ou un casque qui se branche au PC pour permettre de passer et de recevoir des appels.

C’est en complément de ce type de téléphone que sera utilisée notre application puisqu’elle nécessite d’être exécutée sur un PC capable de lancer un programme Java. Les autres types de téléphones sont donnés à titre d’information.

Téléphones VoIP USB

Un téléphone USB se connecte au port USB d’un ordinateur et avec un logiciel soft phone SIP/VoIP il fonctionnera comme un téléphone normal. En essence, il s’agit d’un microphone et d’un haut-parleur. Toutefois, leur apparence identique à celle d’un téléphone normal fait que l’utilisateur saura s’en servir plus facilement.

IP-Phone

L’IP-Phone est un terminal téléphonique fonctionnant sur le réseau LAN IP à 10/100 avec une norme soit propriétaire, soit SIP, soit H.323. Il peut y avoir plusieurs codecs pour l’audio, et il peut disposer d’un écran monochrome ou couleur, et d’une ou plusieurs touches soit programmables, soit préprogrammées. Il est en général doté d’un hub passif à un seul port pour pouvoir alimenter le PC de l’utilisateur (l’IP-Phone se raccorde sur la seule prise Ethernet mural et le PC se raccorde derrière l’IP-Phone).

Utilisation d’un téléphone analogique via un adaptateur ATA

Pour utiliser un téléphone analogique avec le réseau VoIP, il est nécessaire d’utiliser un adaptateur ATA. Un adaptateur ATA permet de relier d’un coté le réseau Ethernet (RJ-45) et de l’autre le téléphone analogique (RJ-11). Ainsi un téléphone analogique apparaîtra sur le réseau VoIP comme un téléphone IP normal.

Les conférences

En plus des appels classiques (d’un poste à un autre), Asterisk offre la possibilité d’effectuer des conférences entre plusieurs utilisateurs. Pour cela on doit configurer une « salle de conférence » à laquelle on attribut un numéro particulier. Un nombre illimité de salles de conférences virtuelles peut être déclaré et utilisé pour les besoins de réunions téléphoniques.

Le premier utilisateur se connectant à une salle de conférence est mis en attente jusqu’à ce qu’il soit rejoint par un ou plusieurs autres utilisateurs.

Il est possible de protéger une conférence par des mots de passe (administrateur et utilisateur simple) et d’y appliquer différents modes de fonctionnement : Parler/écouter, Surveillance (écoute uniquement), Locuteur (parler seulement). Chaque conférence peut être enregistrée, pour des besoins de réécoute par exemple.

La connexion à une conférence ne nécessite pas d’équipement particulier. Tous les types de téléphones vus précédemment peuvent donc être utilisés.

On rejoint une salle de conférence en appelant un numéro spécifique.

III – Analyse

Cahier des charges

I – Introduction

Contexte

Ce projet s’inscrit dans le cadre de notre formation en licence professionnelle durant laquelle nous devons effectuer un projet tuteuré.

II – Description de la demande

Objectifs à atteindre

Le but du projet est de développer une application permettant d’identifier les personnes présentes lors d’une conférence audio sur Asterisk et d’afficher les personnes qui sont en train de parler.

Descriptif du produit du projet

Le produit du projet est une application graphique écrite en langage Java. Celle-ci sera composée de deux parties :

  • une partie serveur : installée sur le serveur Asterisk.
  • une partie client : installée sur chacun des postes clients.

Les fonctions du produit

Le programme client permet d’afficher le nom d’utilisateur des clients connectés lors d’une conférence Asterisk. Il indique également en temps réel les clients qui sont en train de parler.

Le programme serveur détecte les activités (connexion, déconnexion, parole) des utilisateurs d’une conférence sur le serveur Asterisk et en informe tous les programmes clients connectés.

Critères d’acceptabilité de la réception du produit

Le produit devra être développé en utilisant les technologies suivantes :

  • le langage Java pour le développement de l’application
  • Jpcap : Jpcap est une librairie Java permettant la capture et l’envoie de paquets sur un réseau. Durant notre projet, seule la fonction de capture a été utilisée. Les principaux avantages de Jpcap sont :
    • Possibilité de capturer les paquets Ethernet, IPv4, IPv6, ARP/RARP, TCP, UDP, et ICMPv4
    • Open source, sous licence GNU LGPL

III – Les contraintes

Les contraintes de coûts

Le projet est basé sur l’utilisation de solutions libres :

  • le PABX Asterisk
  • une distribution de Linux Fedora
  • le langage Java
  • la librairie Jpcap

Les contraintes de délais

Le projet complet devra être rendu le 15 mars 2009. Un premier rapport contenant l’analyse du projet est à rendre au cours du mois de janvier.

IV – Développement

Planification

1- Etude d’Asterisk

2- Installation d’une distribution de Fedora, installation et configuration d’Asterisk, installation et configuration d’un soft phone sur les deux PC clients.

3- Etude du protocole SIP et conception du programme client-serveur.

4- Etude du protocole RTP et implémentation dans le programme.

Ressources

Le matériel suivant a été mis à notre disposition (dans les locaux de l’ISIMA) durant toute la durée du projet :

  • 1 PC pour le serveur Asterisk sur lequel nous avons installé un système d’exploitation Fedora.
  • 2 PC pour les clients fonctionnant sous Windows XP + 2 casques-micro.

Analyse de la partie serveur

La partie Serveur représente 85% des fonctions remplies par notre application.

Il s’agit d’un programme qui se lance sur le serveur où est présent le PABX Asterisk.

Le programme est écrit en Java, et respecte le design pattern MVC (Modèle Vue Contrôleur). Voici le schéma UML qui le représente :

Principe de fonctionnement :

Ce programme doit d’abord écouter (sniffer) les connexions réseaux. Nous avons choisi d’écouter toutes les trames qui passent sur le serveur est qui sont transportées par UDP, ceci est fait dans un thread (ThreadCapture) qui vit le temps de l’application et qui se lance au démarrage du programme. Nous pouvons donc récupérer les trames contenant les messages SIP et paquets RTP. Nous ne retenons que les messages SIP et paquets RTP.

Un message SIP est parsé pour créer un nouvel objet SipMessage.

Un paquet RTP est aussi analysé pour devenir un nouvel objet de type RtpPacket.

Dans un autre thread (Serveur), on attend des connexions provenant des programmes clients sur le port 50600 (port que nous avons délibérément choisi). Les clients sont retenus car on doit leur renvoyer des informations. UDP étant un protocole non-connecté, on doit nécessairement retenir les informations pour les atteindre.

Un client est identifié par une adresse IP et un numéro de port.

C’est le modèle (Modele) de l’application qui reçoit les paquets retenus et qui effectue les traitements associés. Globalement, il avertit les clients dont il a connaissance de ce qu’il se passe.

Si le paquet contient un message SIP : on peut avertir qu’un client vient de rejoindre la conférence ou au contraire qu’il l’a quittée.

Si le paquet est un paquet RTP : on avertit les clients qu’un client en particulier est en train de parler.

Les messages envoyés aux clients par le programme sont :

  • NEW:nom = Un nouveau participant nommé « nom » à rejoint la conférence.
  • QUIT:nom = Le participant nommé « nom » a quitté la conférence.
  • GIVEYOURNAME: = Le serveur ne peut trouver seul le nom d’un participant, il demande alors au client de lui indiquer.
  • YOU:nom = Indique au client que le serveur à bien récupérer le nom du participant.
  • ENREGISTRE: = Le client est bien enregistré auprès du serveur.
  • EXIT: = Le serveur se termine, il l’indique à ses clients.

Analyse de la partie cliente

Le programme client est l’interface graphique de notre application. Mais elle n’exécute pas de tâches spécifiques. Ce programme est exécuté sur l’ordinateur (distant) d’un participant à une conférence. Il ne remplace pas le soft phone.

Principe de fonctionnement :

Ce programme démarre en demandant un enregistrement auprès du programme serveur. Un thread (ThreadConnexion) gère les échanges entre ce serveur et le programme client.

Il affiche ensuite la liste des personnes connectées à la conférence qu’il reçoit du serveur.

Quand une personne parle, le programme est averti et indique par un voyant lumineux qui est en train de parler.

Comme le programme serveur, le client respecte le design pattern MVC. Voici le schéma UML qui le représente :

Le client peut envoyer les messages suivant :

  • CLIENT: = Indique au serveur que le client vient de se connecter.
  • EXITCLIENT:nom = Indique que le client « nom » s’est déconnecté.
  • MYNAME:nom = Indique au serveur le nom du client.

Communication client/serveur

Pour gérer la communication entre notre application serveur et les applications clientes, nous avons implémenté notre propre protocole de communication, basé sur l’envoi de messages.

  • Connexion d’un client au serveur

  • Déconnexion d’un client

  • Déconnexion du serveur

  • Connexion d’un client SIP (Le nom du participant a été trouvé dans le message SIP)

  • Connexion d’un client SIP (Le nom du participant n’a pas été trouvé dans le message SIP)

  • Déconnexion d’un client SIP

  • Le serveur détecte une activité vocale

  • Le serveur détecte du bruit

Distinguer la voix du bruit

Un des principaux objectifs du projet consistait à détecter les trames RTP contenant de la voix et celle contenant du bruit (pas de voix). Le problème majeur est que le protocole RTP envoie un flux continu de paquets. Qu’il y ait de la voix ou non, des paquets sont envoyés. Il faut donc identifier les paquets comportant de la voix des paquets comportant du bruit.

Etude des différentes RFC

Les Request For Comments (RFC), littéralement demande de commentaires, sont une série numérotée de documents électroniques documentant les aspects techniques d’Internet.

Nous avons aussi parcouru les différentes RFC relatant du protocole RTP mais rien ne nous a permis de distinguer la voix du bruit. Les RFC nous ont seulement permis de concevoir une classe RtpPacket pour notre application.

La VAD

La détection d’activité de la voix (VAD) est utilisée pour détecter la présence de la parole dans un signal audio. Dans la voix sur IP et les applications de téléphonie mobile, la VAD peut réduire la bande passante et le trafic sur le réseau en transmettant les paquets audio seulement si de la parole est détectée. Cette détection est effectuée par des algorithmes et ont la sur de nombreux téléphones IP ainsi que sur certains softphones.

Cette technologie paraissait intéressante pour notre projet puisque seuls les paquets contenant de la voix sont envoyés au serveur. Malheureusement, Asterisk ne supporte pas cette fonctionnalité et elle doit être désactivée sur les téléphones IP et softphones se connectant à un serveur Asterisk.

La capture avec Wireshark – Tests et conclusions

Nous avons utilisé le logiciel Wireshark afin de capturer les trames échangées entre le serveur et les softphones. Puis nous avons analysé le contenu de celles-ci afin de trouver ce qui pourrait différencier une trame contenant de la voix d’une trame contenant du bruit.

X-Lite

Nous avons tout d’abord capturé des trames en utilisant le softphone X-lite. L’avantage de ce softphone, pour nous, est qu’il possède une icône indiquant à l’utilisateur qu’il transmet de la voix.

Nous nous intéressons seulement aux trames envoyées par le client au serveur et non l’inverse.

Nous avons effectué plusieurs captures en utilisant différents paramètres :

Pour chacune des captures, la taille du payload (données transportés dans le paquet) est de 160 octets. Pour chaque trame nous effectuons également la somme des octets du payload.

  • Bouton « Mute » du softphone activé :

Pour tous les paquets capturés, le payload (ici en bleu) ne contient que des octets de valeur FF.

La somme des octets est égale à -160.

  • Microphone muet ou débranché :

Contrairement à ce que l’on aurait put penser, le fait de désactiver le micro n’a pas le même effet que d’activer le « Mute » du softphone. On obtient des trames qui contiennent les valeurs hexadécimales suivantes : FB, FC, FD, FE, FF, 7B, 7C, 7D, 7E, 7F. Ces valeurs sont alternées sans ordre précis. Les trames ne sont donc pas identiques les unes aux autres.

La somme des octets est supérieure à 7000 pour quasiment toutes les trames.

  • Microphone activé et voix constante

Lorsque de la voix est transmise, les payload de chaque trame sont différents. Ils n’existent aucune similitude entre eux.

La somme des octets est inférieure à 7000 dans tous les cas.

On peut donc en déduire l’algorithme suivant :


GeSHi Error: GeSHi could not find the language brushbash (using path /home/www/willdurand/wordpress/wp-content/plugins/codecolorer/lib/geshi/) (code 2)

3CX VoIP Phone

En capturant les paquets émis lors de l’utilisation de ce softphone, on peut voir que le payload ne fait pas la même taille que pour des paquets émis par X-Lite. On ne peut donc pas appliquer l’algorithme décrit précédemment.

Idefisk

Wireshark pose problème lors de la capture de paquets envoyés lors du l’utilisation de ce softphone. En effet celui-ci ne détecte pas des paquets UDP mais des paquets OICQ (logiciel de messagerie instantanée utilisé en Chine). Quoi qu’il en soit la taille du payload est la aussi différente et ne permet pas d’appliquer l’algorithme.

IV – L’application réalisée

En mode graphique, on peut sélectionner l’interface sur laquelle l’application serveur écoute.

L’application serveur loggue les derniers messages SIP et les derniers paquets RTP qu’elle a écoutée et identifiée comme utiles. (En relation avec une conférence).

Le client affiche le nom de chaque participant et un témoin lumineux. Ici, le participant « William » parle alors que le participant « Geoffrey » ne parle pas.

V – Bilan technique

L’issu de notre projet n’est pas très bon en soi. En effet, nous n’avons pas trouvé LA solution au problème majeur, à savoir la distinction entre voix et bruit dans le protocole RTP. Nous avons trouvé des solutions qui fonctionnent très bien pour plusieurs soft-phones, mais nous n’avons pas réussi à trouver un lien logique entre ces solutions. Nos recherches sur Internet et dans les différentes RFC n’ont rien données, nous n’avons pas trouvé de solution à un problème similaire au nôtre.

Selon nous, la distinction entre voix et bruit dans un paquet RTP ne peut être faite. Nous ne sommes pas arrivés à trouver une solution unique, mais nous ne savons même pas si c’est possible ou si cela existe réellement.

Ainsi nous sommes peu satisfaits du résultat du projet, le programme client/serveur en lui-même fonctionne mais le gros du travail est plus qu’instable. Nous n’avons pas pu mettre en place une solution générique. Notre solution fonctionne mais pour un certain type de matériel seulement.

VI – Conclusion

Le projet que nous avons réalisé nous a permis d’améliorer nos connaissances dans le domaine des réseaux, de la VoIP et plus particulièrement de la ToIP et ainsi de maitriser les outils et technologies nécessaires au développement de l’application.

L’objectif que nous nous étions fixé n’a pas été atteint, puisque le problème majeur n’a pas été trouvé, non par faute de temps, mais plus par faute de documentation ou d’idées.

Ce projet nous a permis d’apprendre à faire des recherches, à mettre en place une simple idée pour essayer de trouver une solution, à agir par nous-mêmes pour trouver une solution.

En effet, ce projet n’est pas comme la plupart des projets que nous avions auparavant, où il s’agissait de créer quelque chose qui existe déjà. Ce projet devait créer quelque chose de nouveau. Nous pensions que la solution à notre problème principale était néanmoins connue, mais nous nous sommes rendu compte que non.

Ce projet était tout de même très intéressant et nous avons pris plaisir à le mettre en œuvre.

Il est clair que la distinction entre la voix et le bruit n’est pas possible en analysant seulement les trames. D’autres possibilités s’offrent à nous : détecter côté client la parole (détection sur l’entrée micro), décoder la voix et l’analyser, …

Annexes :

Sources :

  • Print
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Twitter
  • Google Bookmarks
  • FriendFeed
  • LinkedIn
  • MySpace
  • Netvibes
  • PDF
  • Ping.fm
  • RSS
  • Technorati
  • viadeo FR
  • Wikio
  • Yahoo! Buzz

Related Posts

Cet article a été publié dans Ancien blog avec les mots-clefs : , , , , , , , , , . Bookmarker le permalien. Les commentaires et les trackbacks sont fermés.

5 commentaires

  1. Ikbel
    Le 12 août 2010 à 10 h 41 min | Permalien

    bonjour, ce projet est très intéressant est-ce-que est possible d’avoir le code source ??
    merci d’avance.

    • Le 12 août 2010 à 14 h 05 min | Permalien

      Bonjou Ikbel,

      les chercheurs qui m’ont confiés ce projet ne m’ont pas autorisé à diffuser le code source. Je ne peux donc rien vous fournir…

      Cordialement,

  2. SAIDI
    Le 10 mai 2011 à 15 h 58 min | Permalien

    Bonjour;
    j’ai voulu installé Asterisk sur mon Pc, j’ai installé Linux (ubuntu); j ai trouvé des difficultés pour l’installer. je vous demande s’il ya eu un moyen de me guider afin de réussir à l’installer et le marcher.
    Cordialement

    • Le 5 juillet 2011 à 12 h 55 min | Permalien

      Bonjour,

      Je pense que la documentation devrait suffir.

  3. Le 6 juin 2011 à 22 h 58 min | Permalien

    j’ai aimé le cours il m’a été d’une grande importance ùais j »aimerai que vous m’aide plus please,c’est pour mon memoire,je dois concevoire un réseau voip avec une reconnaissance vocale dans la video conference en plus place un module qui permet de placé de mot clé tel que assasina,bombe,etc. et de que lors d’une conversation le mot clé est utiliséil y a un bip d’alerte et message addressé à l’administrateur et l’enreigistrement de la conversation aidé-moi please surtout pour l’application ou la realisation.mon ,ail est nsisijuslain@yahoo.fr,
    mon numero : +243 999 703 761