Simulation d'un provider ToIP basé sur asterisk et a2billing

Transcription

1 Simulation d'un provider ToIP basé sur asterisk et a2billing Laurent GALLON IUT des Pays de l'adour dépt R&T Mont de Marsan I. INTRODUCTION Les architectures ToIP sont de plus en plus présentes dans les entreprises. Elles permettent à la fois de faire converger les deux infrastructures classiques, téléphonique et informatique, et par là même de réduire les coûts. Mais les entreprises cherchent aussi à réduire les coûts des abonnements téléphoniques et des communications. Une solution est d'utiliser l'accès Internet de l'entreprise pour faire passer ses appels externes par un provider ToIP. Ce dernier offre à l'entreprise la possibilité de passer du monde IP vers le monde de la téléphonie commutée (3G/RNIS) à des coûts moindres que ceux engendrés par des accès directs à ces réseaux. Dans ce papier, nous proposons un exemple d'implémentation de provider ToIP, utilisable en salle de TP. Nous abordons en particulier les problèmes de l'authentification, de l'utilisation de passerelles vers le monde commuté, du routage des appels entrants et sortants, et de la taxation des appels. La totalité de notre proposition repose sur l'ipbx libre Asterisk, couplé au logiciel libre de taxation a2billing, pour avoir une infrastructure la plus ouverte et la moins coûteuse possible. L'architecture de la plateforme est décrite sur la figure 1. par le provider pour mettre en place une communication avec un tiers. Cette communication peut être destinée à un autre téléphone IP, où à un téléphone du monde commuté. L'authentification permet de vérifier les droits d'accès de l'appelant, et de le taxer correctement. Le routage des appels et l'utilisation de passerelles vers le monde commuté. Ici, l'important est de pouvoir router les appels sortants (le client est l'initiateur de l'appel) soit vers un autre poste IP, soit vers une passerelle permettant d'accéder aux réseaux commuté. Mais il faut aussi penser aux appels entrants, qui doivent pouvoir aboutir au client. La taxation, qui permet dans un premier temps de comptabiliser la durée de chaque appel, et si nécessaire, d'estimer le coût de la communication. Fig. 2 : Modules du Provider ToIP Nptez enfin que le composant «Provider ToIP» fait partie d'une plateforme générique de ToIP, présentée par Patrick Charrin dans l'article «Une plateforme pédagogique pour illustrer les différentes architectures de ToIP» de ce même workshop. II. Fig. 1 : Schéma général de la plateforme Nous n'aborderons pas ici toutes les fonctionnalités d'un provider ToIP. Nous focalisons notre proposition sur les éléments indispensables du provider, à savoir (cf figure 2) : l'authentification de l'appelant, c'est-à-dire la reconnaissance de l'entreprise qui essaie de passer ASTERISK ET A2BILLING A. Asterisk Asterisk est un IPBX (autocommutateur téléphonique IP) open source fonctionnant sous Linux ou Windows. Il a été créé en 1999 par Mark Spencer, et a été le support de lancement de la société Digium. Il permet à des terminaux ToIP de communiquer entre eux, en utilisant différents protocoles de communications, comme SIP, IAX, Il implémente les services téléphoniques traditionnels (renvois et transferts d'appels, Ne Pas Déranger, boîtes vocales, ) et les services avancés

2 (messagerie unifiée, IVR, centre d'appel, ). Il permet en outre de passer du monde IP vers les réseaux téléphoniques publics (analogique / RNIS / 2G-3G) par l'adjonction de cartes ou boîtiers passerelles. La configuration d'asterisk est effectuée en utilisant différents fichiers de configuration (contenus dans le répertoires /etc/asterisk). On y trouve en particulier : le fichier sip.conf, qui contient la liste et les profils des utilisateurs utilisant le protocole SIP pour communiquer avec Asterisk le fichier iax.conf, qui contient la liste et les profils des utilisateurs utilisant le protocole IAX pour communiquer avec Asterisk le fichier extensions.conf, dans lequel on configure le plan de numérotation et les règles de routage des appels entrants et sortants le fichier musiconhold.conf, dans lequel on configure la musique d'attente le fichier chan_dahdi.conf, dans lequel on configure l'accès aux cartes et boitiers permettant l'accès aux réseaux téléphoniques publics Bien d'autres fichiers sont disponibles, nous ne pouvons tous les citer ici. L'ensemble de ces fichiers constitue une «jungle» qu'il est parfois difficile à maîtriser, d'autant que certaines modifications nécessitent une intervention dans plusieurs fichiers. Aussi, différentes interfaces graphiques pouvant se coupler à Asterisk ont vu le jour : Asterisk@home, trixbox, Ces interfaces sont une aide à la modification des fichiers de configuration d'asterisk. Cependant, elles sont parfois limitées (elles n'offrent pas toutes les possibilités de configuration), ou spécifique à une implémentation particulière (ex : Trixbox). Aussi, en règle générale, les administrateurs sont amenés à modifier «à la main» les fichiers de configuration pour effectuer certaines opérations spécifiques. a2billing permet de définir des «rates», c'est-à-dire des tarifications en fonction de la destination des appels (préfixe). Un client («customer») pourra passer des appels à travers a2billing, en se voyant affecter d'une certaine tarification. L'ensemble des tarifs qui peuvent être appliqués à ce client sont regroupés dans une «rate card». Les «rate cards» correspondent donc aux différentes offres tarifaires proposées par a2billing à ses clients. Fig. 3 : a2billing Bien entendu, a2billing reconnait ses clients grâce à une authentification De plus, il est capable d'appliquer deux types de routage : le LCR qui revient à rechercher le chemin coutant le moins au provider, et le LCD qui revient à rechercher le coût le plus avantageux pour le client. Nous allons nous appuyer sur ces fonctionnalités pour simuler un Provider ToIP à partir d'asterisk et de a2billing. III. MISE EN PLACE DU PROVIDER TOIP A. Architecture du TP Nous considérons l'architecture de TP suivante (Fig. 4) : Asterisk peut aussi être couplé à une base de données, type MySQL par exemple (ce n'est pas la seule possibilité!), afin de stocker les utilisateurs et leurs profils, et enregistrer les tickets de taxation, c'est-à-dire les tickets indiquant la durée des appels et leur coûts. Néanmoins, Asterisk ne fournit pas par défaut de logiciel de taxation. Les tickets existent, mais ils doivent être exploités par une application extérieure, comme par exemple a2billing. B. A2billing a2billing est un logiciel de taxation, très complet, qui permet non seulement de gérer les tickets d'appels, mais aussi de gérer des comptes clients, de créditer de différentes manières ces comptes («cartes prépayées», paiement à la facture, ), et de les débiter en fonction des appels passés, et leur facturation. Figure 4 : architecture du réseau de TP On retrouve les éléments présentés dans le papier «Une plateforme pédagogique pour illustrer les différentes architectures de ToIP» de Patrick Charrin : Chaque entreprise est représentée par un IPBX configuré par un binôme d'étudiant. Dans nos

3 manipulations, cet IPBX doit supporter le protocole SIP. ON peut utiliser un Alcatel OxO, un matracom AXS, un Asterisk, Plusieurs téléphones sont connectés à cet IPBX, avec des numéros SDA. Dans le cadre de ce TP, nous aurons une seule entreprise, dont la plage SDA est xx. Le provider ToIP est constitué d'un Asterisk sur lequel est rajouté a2billing. Nous allons détailler la configuration de a2billing dans la suite de ce chapitre. Le réseau IP est en réalité un réseau Ethernet, mise en œuvre par un simple switch. Un téléphone IP, déclaré sur l'asterisk du composant «Provider ToIP», représentera le monde des téléphones IP (tout numéro qui commence par 09xxxxxxxx) La Voice Gateway (ou Media Gateway) est implémentée par un Asterisk, sur lequel nous avons é une carte Digium B410P qui offre 4 accès de base T0. Le réseau RNIS est réalisé par un simulateur Patapsco. Quelques téléphones sont connectés sur ce simulateur, et permettent de disposer de numéros SDA caractéristiques (15/18, 08xxxxxxxx, 0467xxxxxx, 06xxxxxxxx), qui seront taxés différemment. Notez que le simulateur de réseau RNIS peut être remplacé par la solution basée sur Asterisk, présentée dans le papier d'angel Abénia. De plus, les composants «Provider ToIP» et «Voice Gateway» peuvent facilement être regroupés en un seul en ant la carte B410P directement dans l'asterisk du composant «Provider ToIP». Ceci étant, à l'heure où nous écrivons, nous n'avons pas testé cette possibilité, et la documentation d'a2billing ne laisse pas apparaître la possibilité d'utiliser misdn ou Dahdi. Si cette information se vérifie, cela signifie que les accès RNIS ne peuvent être directement gérés par a2billing, et cela complexifie le regroupement des deux composants. B. Configuration de a2billing Nous considérons que l'ation d'asterisk et de a déjà été effectuée (voir annexes A et B). Nous allons décrire maintenant les différentes phases de configuration nécessaires au bon fonctionnement du Provider ToIP a2billing 1) Utilisation de a2billing dans le plan de num. de asterisk La première opération à effectuer est de dire à Asterisk d'utiliser a2billing. Pour cela, dans le plan de numérotation d'asterisk (c'est-à-dire à la fin du fichier \etc\asterisk\extensions.conf), il faut définir deux nouveaux contextes, a2billing et did, qui contiennent les instructions suivantes : [a2billing] exten => _X.,1,Answer() exten => _X.,2,Wait(2) exten => _X.,3,AGI(a2billing.php) exten => _X.,4,Wait(2) exetn => _X.,5,HangUp() [did] exten => _X.,1,AGI(a2billing.php 1 did) Le contexte a2billing sera associé aux profils SIP des clients (customers) du provider ToIP. Ainsi, les appels en provenance de ses clients seront traités par a2billing (instruction AGI(a2billing.php)). Bien entendu, ces appels seront taxés différemment en fonction de la destination. Le contexte did sera utilisé par les appels en provenance d'une entité non cliente du Provider, et à destination de l'une de ses entreprises clientes. Dans notre exemple, ce sera le cas si un téléphone du réseau public cherche à appeler le numéro Pour que ces appels aboutissent au contexte did, il faut modifier le fichier /etc/asterisk/sip.conf, et plus exactement la directive context dans le contexte [general] : [general] context = did Ces appels ne seront a priori pas taxés. Il faut penser à relancer Asterisk pour prendre en compte ces modifications : #/etc/init.d/asterisk restart De manière générale, il est toujours intéressant d'avoir une fenêtre de commande dans laquelle s'affichent les messages relatifs aux différentes opérations effectuées par Asterisk. Pour cela, on peut utiliser le CLI (Command Line Interface) d'asterisk, dans une fenêtre de commande : #asterisk -rvvvv On peut d'ores et déjà vérifier que le nouveau plan de numérotation a bien été pris en compte, grâce à la commande : #CLI>dialplan show a2billing Le résultat doit être :

4 2) Déclaration et configuration des «providers» et des «customers» A2billing peut communiquer avec deux types d'entités : les fournisseurs d'accès («providers»), qui vont offrir un accès vers un réseau téléphonique les «customers», qui sont les clients du provider ToIP. Dans notre exemple, nous avons 1 client («customer») : l'entreprise 2 fournisseurs d'accès : la Voice Gateway, qui permet d'accéder au réseaux téléphoniques publics le téléphone IP, qui représente l'accès au monde IP (numéros en 09xxxxxxxx) Ces trois entités peuvent être déclarées à partir de l'interface graphique de configuration de a2billing, accessible depuis un navigateur Web à l'adresse: du provider ToIP>/a2billing/admin Les identifiants de connexion sont : login = root mot de passe = changepassword a) Les «Déclaration des providers providers peuvent être créés à partir du menu». Provider / Add Provider Il faut juste préciser le nom que l'on souhaite leur donner. Dans notre exemple, nous créons deux providers, appelés «MondeIP» et «MondeRNIS». Parallèlement à la création des deux providers, il faut penser à créer les «trunks» associés. Un trunk permet de qualifier le canal de communication utilisé entre a2billing et un provider, c'est-à-dire de préciser tous les éléments techniques qui vont permettre à ce lien d'être utilisé. On peut créer les trunks à partir du menu «Provider / trunks / Add Trunk». Dans notre exemple, nous aurons deux trunks, l'un appelé «VersMondeRNIS», l'autre «VersMondeIP». Ces deux trunks utiliseront le protocole de communication SIP. Il faut aussi penser à préciser l'adresse IP à laquelle aboutie le trunk de la Voice Gateway pour «VersMondeRNIS» = , du téléphone IP pour «VersMondeIP» = ). Enfin, il faut rattacher chaque trunk à son provider.

5 du provider ToIP>/a2billing/customer) qui lui permettra, après authentification («WebUI login» + «WebUI password»), de visualiser son compte, et éventuellement recharger son crédit de communications. Remarque importante : dans le cadre de nos TPs, nous avons exclusivement utilisé des IPBX Asterisk, que ce soit en tant que Voice Gateway, ou en tant que Client. Dans ce cas, la mise en place d'un Trunk nécessite une authentification. Nous avons résolu ce problème en créant un «customer» (voir section suivante) correspondant à la Voice Gateway sur le Provider ToIP, et en configurant un enregistrement automatique de la Voice Gateway auprès du Provider ToIP (la configuration de la Voice Gateway est similaire à celle d'un client classique pour l'enregistrement automatique : voir plus loin dans ce document). Si le nom donné par le Provider ToIP au «client» Voice Gateway est par exemple, alors il faudra déclarer le trunk «VersMondeRNIS» avec à la place de l'adresse IP : /%dialingnumber% b) Déclaration du customer La déclaration des clients se fait à partir du menu CUSTOMER. Il faut dans un premier temps créer le client ( Add::Search Notez qu'il est possible de créer un seul client, où un ensemble de clients d'un seul coup. Ainsi, quand une nouvelle entreprise veut utiliser les services du Provider ToIP, il suffit de lui affecter une identité client déjà créée, mais non encore utilisée. Dans notre cas, nous ne créons qu'un seul client, que nous appelons Binome*7. / Add Customer). Ici, le numéro de compte «account number» + «WebUI» servent d'identifiants pour le client. Notez que ce dernier peut accéder à une interface Web sur a2billing password Notez qu'ici, nous avons opté pour un paiement à la facture («POSTPAID CARD»). En cas de choix «PREPAID CARD», le client devra créditer son compte avant de pouvoir passer des appels. De plus, nous avons laissé coché les options de création de profils SIP et IAX («CREATE SIP CONFIG» et «CREATE IAX CONFIG»). Ainsi, a2billing modifie automatiquement les fichiers additional_a2billing_sip.conf et additional_a2billing_iax.conf pour rajouter la déclaration du profil du client. L'administrateur n'a donc pas à intervenir.

6 Dans l'exemple que nous avons choisi, nous n'utiliserons qu'un seul callplan, basé sur un routage LCD, avec différents rates, mais au travers de deux providers ( MondeIP et MondeRNIS). Nous auront donc deux rate cards différents. Nous commençons par créer les deux rate cards ( Rates : / RateCards / Add RateCard) 3) Définition des rates, rates card et callplan Comme nous l'avons précédemment, a2billing est avant tout un logiciel de taxation. Tout appel téléphonique qui passe par lui (sortants ou entrants, c'est-à-dire vers les réseaux publics ou vers les entreprises clientes) doit pouvoir être taxé. Pour cela, a2billing utilise 3 notions : un rate (taux en français) est un tarif appliqué vers une destination (pays ou client, appel national, international, ) un rate card est un ensemble de rates appliqués à différentes destinations, à travers le même trunk (le même provider) Un callplan est un ensemble de rate cards, que l'on utilise sur la base de la même règle de routage : LCR (Least Cost Routing) si on recherche le coût le plus pletit pour le Provider ToIP LCD (Least Cost Dialling) si on recherche le coût le plus petit pour le client Pour résumé, un callplan est un ensemble de tarifs ( rate cards) disponibles à travers différents providers, que l'on chois à partir d'une règle de routage prédéfinie. Puis il faut créer les différents rates dans chaque Rate en les associant à la bonne RateCard et au bon trunk : Card (Rates / Rates / Add Rate), Notez que l'on peut facilement distinguer le coût pour le provider (buying rate), et le coût pour le client ( selling rate). C'est sur la base de ces informations que les routages LCR et LCD pourront être faits.

7 Une fois tous les rates créés, on obtient : Il faut maintenant créer la callplan (Rates / et lui rattacher les deux rate cards : CallPlan / Add Callplan), Il faut pour cela modifier le fichier sip.conf (on suppose que le trunk entre le client et le provider ToIP est un trunk sip). Dans ce fichier, il faut déclarer un profil sip de type peer qui correspond au profil sip qui a été créé automatiquement sur le provider ToIP. Notez que la section sip est appelée provider, alors que le nom d'utilisateur sur le Provider ToIP est Cela ne pose pas de problème au sens Asterisk, mais cela demande un peu plus de gymnastique au niveau de l'authentification pour plus de simplicité, on peut appeler la section sip , ce qui évitera tout problème futur. b) Enregistrement auprès du provider ToIP Il faut ensuite faire l'enregistrement automatique du client sur le provider ToIP. Pour cela, ajoutez la ligne suivante dans la partie register su fichier sip.conf de l'asterisk du client : Pour rattacher les deux rate cards, il faut aller modifier le callplan ExempleTP (voir figure ci-après, en haut de la colonne suivante) 4) Configuration du client Nous considérons ici que le client Binome*7 est un IPBX Asterisk. La configuration du client se déroule en deux étapes : enregistrement auprès du provider ToIP routage des appels sortants vers le provider ToIP a) enregistrement auprès du provider Là encore, si on a décidé d'appeler la section sip définissant le provider ToiP (et non pas provider comme dans l'exemple ci-dessus), il faut remplacer provider par dans la ligne ci-dessus. Après recharge des paramètres SIP sur l'asterisk du client (commande sip reload dans le CLI), vous devriez voir apparaître un message d'enregistrement du client sur le CLI du provider ToIP. A partir de ce moment, vous devriez être capable de passer un appel à travers votre Provider. Ceci étant, cela ne va pas marcher tout de suite en effet, a2billing n'a pas

8 encore tous les éléments pour router les appels sortants : il lui manque la définition des destinations pour ces appels, c'est-à-dire des lignes de routage qui disent quel est le prochain destinataire quand on cherche à joindre un certain numéro. Ici, il y aura deux cas de figure : on cherche à appeler un numéro SDA d'un autre client de a2billing. Le prochain destinataire sera alors l'ipbx du client on cherche à joindre un numéro public (IP / RNIS / GSM/UMTS). Le prochain destinataire sera alors la VoiceGateway La configuration de ces destinations est effectuée de la même manière que celle concernant les appels entrants. C'est ce que nous expliquons dans le paragraphe suivant. 5) Configuration des appels entrants Comme pour tout IPBX, il est nécessaire de dire au Provider comment router les appels entrants, c'est-à-dire les appels en provenance des réseaux publics, et à destination de ses clients. Plus exactement, il faut lui indiquer quel client possède quel numéro SDA. Les numéros donnés par des providers ToIP à leur clients sont appelés DID (Direct Inward Dialling = Sélection Directe à l'arrivée (SDA) en français). Dans un premier temps, il faut créer ses numéros DID (Inbound DID / Add::Search / Add DID) : Notez que l'on peut choisir de taxer ou non les appels entrants (option BILLING). Un coût de location peut aussi être rajouté (Selling Rate / monthly rate). Une fois les DID créés, il faut créer les destination associées. Une destination indique à a2billing, quel numéro de DID est associé à quel client. Les destinations se crééent dans le menu Inbound DID / Destination / Add destination (figure colonne suivante). Une fois toutes vos destinations créées, vos clients doivent être en mesure de recevoir des appels en provenance des réseaux publics. En ce qui concerne les destinations qui ne vont pas vers un client, mais vers le réseau public, le principe est le même. On créé les DID, puis on créé les destinations, en mettant comme destinataire la Voice Gateway. 6) Accueil de appels sortants sur le Provider ToIP Si toutes vos destinations sont créées, et si vos clients sont bien enregistrés, vous devez être capable de passer des appels d'un client vers un réseau public. Cependant, vous remarquerez que lors d'un tel appel, le provider ToIP effectue plusieurs opérations : dans un premier temps, il dit combien de crédit il reste au client, et combine de temps l'appel peut durer. il demande ensuite de composer le numéro à appeler Si vous n'avez plus de crédit, vous pouvez recharger votre compte dans le menu Customers / add::search / add credit to this card (icône dollar sur la ligne du client). Pour supprimer l'annonce de la balance (crédit restant), il faut positionner la variable Say Balance after Auth à No dans la partie System settings / Global list. Enfin, pour ne pas annoncer la durée maximale autorisée de l'appel, positionnez la variable Say Duration à No, toujours dans la partie System settings / Global list. Enfin, si on souhaite que le Provider ne demande pas le numéro à appeler, et qu'il compose directement le numéro fourni lors de l'appel, il faut modifier la variable Use DNID dans la partie System settings / Global list, et la positionner à Yes. Ainsi, a2billing utilisera le numéro destinataire de la requête SIP comme numéro à appeler. 7) Conclusions Notez qu'ici, la destination associe le DID au client , et plus exactement au poste 100 de ce client (équivalent d'un Dial(SIP/100@ ) sous Asterisk). A travers ce chapitre, nous avons voulu guider le lecteur vers une première configuration d'asterisk + a2billing la plus simple possible. De nombreuses options n'ont pas été

9 abordées, et plusieurs solutions décrites ici doivent pouvoir être largement améliorées. IV. DIFFÉRENTES UTILISATIONS POSSIBLES DU PROVIDER TOIP EN TP avons détaillé la configuration du Provider ToIP, en nous appuyant sur un exemple utilisable en salle de TP. Enfin nous avons donné différentes pistes d'utilisation dans les séries de TP. VI. ANNEXES Sans trop rentrer dans les détails, nous estimons pouvoir utiliser notre Provider ToIP de plusieurs façons dans les TPs de téléphonie sur IP : il peut être utilisé comme passerelle entre le réseau téléphonique privé de l'entreprise, et les réseaux publics. La différence d'utilisation par rapport à une Media Gateway n'est pas flagrante, si ce n'est l'aspect authentification, et la possibilité de regarder la taxation des appels passés sur l'interface Web «customer». Cela reste néanmoins un composant support intéressant, se rapprochant de ce que l'on trouve dans la réalité. il peut aussi faire l'objet d'un TP. Outre l'aspect création de providers, et de customers, d'autres points nous semblent intéressants, et notamment les aspects taxation. Les étudiants peuvent aborder les notions de «buying cost» et de «selling cost», c'est-à-dire la différence entre ce que coûte réellement une communication au Provider ToIP, et le coût qui est facturé au client. On peut notamment mettre en place différents niveaux de fidélisation pour ses clients, en créant des «call plans» différents (IVOIRE, ARGENT, OR, PLATINE) qui implémenteront un écart coût facturé coût d'exploitation plus ou moins grand (plus le client est fidèle, c'est-à-dire plus il passe d'appels au travers du provider ToIP, plus il aura un niveau de fidélité lui permettant d'atteindre des coûts de facturation proches des coûts de facturation). De plus, les notions de LCR (Least Cost Routing) et LCD (Least Cost Dialling) pourront aussi être abordées, en créant plusieurs providers, aux coûts différents. Ainsi, pour les mêmes appels, les étudiants peuvent mettre en avant la différence entre choisir le coût d'exploitation le moins cher (LCR) et le coût de facturation le moins cher (LCD). Quoi qu'il en soit, le lecteur trouvera très certainement d'autres utilisations possibles à cet outil, en fonction de ses propres TPs. V. CONCLUSION Dans cet article, nous avons présenté une solution pour mettre en place un Provider ToIP utilisable en TPs de téléphonie sur IP. La solution est peu onéreuse, puisqu'elle nécessite un serveur informatique sous Ubuntu, l'ipbx logiciel gratuit Asterisk, et le logiciel de taxation gratuit a2billing. Après avoir présenté ces différents logiciels, nous A. Installation d'asterisk et de ses composants Prérequis : Nous supposons que nous utilisons un systèmes Linux Ubuntu (version 10.04). De plus, nous supposons que l'accès au réseau Internet est déjà configuré. L'ation d'asterisk peut être effectuée en lignes de commande depuis un terminal, ou à travers le logiciel de gestion des paquets Synaptic. Nous ne présentons ici que l'ation par lignes de commande. Les paquetages d'ation d'asterisk sont depuis plusieurs années intégrés dans la distribution Ubuntu (Debian). Aussi, il n'est pas nécessaire de récupérer les sources du logiciel, et de les compiler. Il suffit juste d'er les paquetages pré-compilés : asterisk La gestion automatique de dépendances de paquets va automatiquement calculer la liste des paquets nécessaires à l'ation d'asterisk. Certains de ces paquets sont peut être déjà és, d'autres peuvent être és, mais nécessitent une mise à jour, et enfin certains paquets doivent être nouvellement és. Dans tous les cas, apt-get vous donne toutes ces informations, et attend votre accord pour commencer le téléchargement des paquets (nouveaux + mises à jour) et leur ation. Notez que cette ation ne prend en compte que les paquetages indispensables au bon fonctionnement d'asterisk. Il est possible ensuite d'er d'autres paquetages, afin de rajouter des fonctionnalités à Asterisk, ou de le personnaliser. Par exemple : asterisk-prompt-fr-proformatique va er des prompts vocaux français supplémentaires, qui pourront être utilisés en remplacement des prompts vocaux anglais és par défaut. En particulier, si l'on souhaite pour jouer des musiques d'attente, Asterisk doit faire appel à un player externe (par exemple un player mp3). Dans nos manipulations, nous avons toujours utilisé madplay: madplay La configuration des musiques d'attente se fait dans le fichier /etc/asterisk/musiconhold.conf, dans la section [default]:

10 [default] mode=custom directory=/var/lib/asterisk/mohmp3 application=/usr/bin/madplay -Q -o raw:- --mono -R a -12 Il ne reste alors qu'à mettre les fichiers mp3 que vous souhaitez utiliser comme musique d'attente dans le répertoire /var/lib/asterisk/mohmp3 B. Installation de A2billing L'ation de A2Billing se fait uniquement en ligne de commande. Il n'existe pas (du moins au moment de l'écriture de cet article) de paquetage pré-compilé pour ce logiciel. Dans un premier temps, il faut récupérer l'archive contenant les fichiers d'ation. Elle peut être trouvée sur le site svn de a2billing : #svn co --username guest --password guest /1.8.1 /usr/local/src/a2billing/ Rem : Si vous ne disposez pas de l'outil svn, tapez la commande suivante : subversion Attention, plusieurs versions de a2billing sont disponibles. A l'heure où nous écrivons, la version la plus récente est la (c'est l'exemple pris dans la commande ci-dessus). Si vous souhaitez utiliser une version antérieure, il suffit de remplacer par le numéro de version souhaité dans la commande ci-dessus. La liste des versions disponibles peut être connue en se connectant sur le site utilisateur guest, mot de passe guest. Une fois cette opération effectuée, une arborescence complète de sous-répertoires et de fichiers est maintenant présente dans le répertoire /usr/local/src/a2billing. Avant d'aller plus loin, A2billing a besoin de différents logiciels pour pouvoir fonctionner. Plus précisément, il doit être é sur un serveur LAMP. On parle de serveur LAMP pour qualifier un serveur Web mis en œuvre sous Linux, à l'aide des logiciels Apache (le serveur Web), MySQL (base de données) et PHP (interpréteur de scripts PHP pour construire des pages Web dynamiques). libapache2-mod-php5 php5 php5-common php5-cli php5-mysql mysql-server apache2 php5-gd openssh-server php5-mcrypt php-gettext php5-sqlite python-mysqldb python-psycopg2 python-sqlalchemy libperlspeak-perl Bien entendu, a2billing nécessite aussi Asterisk pour pouvoir mettre en place les appels et les router. Si cela n'a pas déjà été fait, vous pouvez vous référer à l'annexe A pour er Asterisk. Nous pouvons maintenant passer à la mise en place et configuration de a2billing. Le premier élément à mettre en place est la base de données dans laquelle a2billing va stocker ses tickets de taxation, c'est-à-dire le résumé de chaque appel (heure de début, heure de fin, appelant, appelé, coût, ). #cd /usr/local/src/a2billing #mysql -u root -p < DataBase/mysql-5.x/a2billingcreatedb-user.sql Le script createdb-user.sql permet de créer une base de données appelée mya2billing, associée à l'utilisateur a2billinguser, mot de passe a2billing, sur la machine locale (host = ). Il faut maintenant créer les tables adéquates dans cette base de données. Pour cela, nous utilisons un autre script : #/usr/local/src/a2billing/database/mysql-5.x/ -db.sh Le script -db.sh demande le nom de la base de données (mya2billing), l'adresse de la machine sur laquelle se trouve la base de données ( ), le nom d'utilisateur (a2billinguser) et le mot de passe ( a2billing) pour insérer les tables dans la base de données. A l'issu de cette phase, vous pouvez vérifier que la base de données est bien configurée, en vous y connectant : #mysql -u root -p mya2billing Vous devriez ensuite avoir 97 tables différentes dans votre base de données : mysql>show tables; mysql>exit Il faut maintenant configurer a2billing pour qu'il utilise la base de données mya2billing. Pour cela, tapez les commandes suivantes : #cp a2billing.conf /etc #gedit /etc/a2billing.conf & Modifiez la section [database] comme suit : [database] hostname= port=3306 user=a2billinguser password=a2billing dbname=mya2billing dbtype=mysql On créé ensuite les fichiers de configuration d'asterisk dans lesquels a2billing enregistrera les profils SIP / IAX des clients, et on donne les droits à l'utilisateur www-data sur ces fichiers (pour qu'ils puissent être modifiés depuis l'interface