FritzBox : fonctionnalités avancées de VoIP / SIP

Modification avancée des paramètres VoiP des routeurs FritzBox : codec, VAD, détection des silences …

Certaines FritzBox fournissent un service de standard téléphonique (IPBX). Vous pouvez raccorder une ligne analogique, numérique ou SIP à votre équipement ainsi que des postes SIP, analogique, numérique ou DECT. Les services fournis permet de répondre aux attentes des TPE sans aucun problème.

Il peut parfois être utile d’accéder aux paramètres avancées non accessibles via l’interface web. Nous allons voir comment. Tout d’abord, vous devez vous connecter via telnet à votre FritzBox. Si vous ne savez pas comment faire, je vous invite à lire ce post : comment activer le service telnet de ma FritzBox.

La configuration se fait dans un seul fichier, /var/flash/voip.cfg

Pour éditer ce fichier, il faut utiliser nvi :

nvi /var/flash/voip.cfg

Bien entendu, il ne faut modifier les éléments de ce fichier que si vous savez ce que vous faites. Une mauvaise manipulation pourrait rendre inopérant les services de téléphonie de votre FritzBox.

Nous allons voir comment modifier les codecs et l’ordre de ceux-ci. Pour cela, il faut localiser les 2 lignes suivantes :

use_audiocodecs = no;
audiocodecs = "PCMA", "PCMU", "G726-32", "G726-40", "G726-24";

C’est la configuration par défaut. La première variable (use_audiocodecs) avec une valeur à « yes » permet de dire à la FritzBox d’utiliser les codecs listés dans audiocodecs dans l’ordre de préférence indiqué. Par défaut, la FritzBox utilise le codec selon l’ordre annoncé par l’opérateur. Nous pouvons forcer les priorités ainsi :

use_audiocodecs = yes;
audiocodecs = "G729", "PCMA", "PCMU", "G726-32", "G726-40", "G726-24";

Après avoir réalisé ces modifications, il faut arrêter, puis redémarrer le daemon VoIP :

voipd -s
voipd

Maintenant, il est possible d’utiliser le codec G11 en priorité afin d’avoir une meilleure qualité audio.

Nous allons voir comment activer la détection de silence et la fonction VAD (voice activity detection). Vous pourriez avoir besoin de ces fonctions si votre ligne dispose d’un débit limité.

A la fin du fichier voip.cfg , vous avez la variable rtpstream :

rtpstream {
    voice_activity_detection {
        vad_enabled = vadenabled_no;
        vad_threshold = 10000;
        }
        plc {
            in_the_stack = yes;
        }
        jitter {
            auto_on = yes;
            in_ms = 50;
            in_packets = 0;
        }
        rtcp_enabled = yes;
        silence_detection = no;
}

Que vous allez modifier comme suit :

rtpstream {
    voice_activity_detection {
        vad_enabled = vadenabled_yes;
        vad_threshold = 10000;
        }
        plc {
            in_the_stack = yes;
        }
        jitter {
            auto_on = yes;
            in_ms = 50;
            in_packets = 0;
        }
        rtcp_enabled = yes;
        silence_detection = yes;
}

La valeur du threshold étant à adapter selon votre environnement (faites des tests).

Je vous laisse découvrir les différents paramètres.

Sécurité des iPBX : responsabilité des intégrateurs

Je viens d’avoir un appel téléphonique d’un responsable d’une société qui vient de subir une fraude sur son installation téléphonique. Alerté par son opérateur, Orange pour ne pas le citer, il vient de subir des appels frauduleux pour un montant dépassant les 10k euros. Juste de quoi vous gâcher la journée.

L’opérateur ayant fait le nécessaire (suppression des appels à l’étranger), il cherche maintenant à savoir qui va payer cette facture bien salée. Et pour cela, il faut chercher le responsable, qui a fait la boulette. Un détournement des accès téléphoniques, un employé malintentionné ou une faille du système téléphonique.

Après un audit des accès téléphoniques de l’iPBX, cette hypothèse est rapidement écartée comme la seconde (les montants en jeu sont trop importants). Il reste donc l’hypothèse malheureusement la plus courante, une faille sur le système téléphonique.

Seul un audit permettra de déterminer quelle faille a été exploitée, et si cette faille est la conséquence d’une négligence dans la programmation et la maintenance du standard téléphonique. Malheureusement un certain nombre d’installateurs téléphoniques ou intégrateurs prennent la sécurité des équipements et des systèmes à la légère. Pour preuve, la non application des matchs de sécurité sur certains parcs de PABX pourtant reconnus vulnérables, ou la mise en oeuvre d’architecture dont la conception même fragilise toute l’infrastructure informatique de la société cliente.

Il est grand temps que le petit monde de la téléphonie (installateurs, éditeurs, constructeurs …) adopte des pratiques strictes en terme de sécurité. Et pour commencer, la mise à disposition des patchs de sécurité devrait être gratuit (ce n’est pas encore le cas de tous les constructeurs) et le déploiement des mises à jour de sécurité inclu au contrat de maintenance en incluant des SLA (délai de déploiement de la mise à jour maximum garanti …). Une veille technique devrait aussi faire partie de ces contrats avec une information claire diffusée au client.

Les intégrateurs ou installateurs privés en tant que professionnels reconnus sont responsables devant la loi du respect des bonnes pratiques. Laisser un mot de passe par défaut ou faible est un exemple simple, mais qui engage la responsabilité du prestataire. Comme le fait de ne pas avoir répondu aux solicitations de son client lui demandant de mettre à jour le système, ou le fait d’avoir programmé le système en ignorant les règles de sécurité connues.

Les attaques se faisant de plus en plus nombreuses, j’espère qu’à la fois les clients (ceux qui refusent de mettre à jour leur système et qui refusent tout contrat d’infogérance) et les professionnels prennent plus sérieusement en compte ces risques.

FreePBX : Frederic Dickey Interview – Asterisk – Sangoma

Sangoma is a leading provider of hardware and software components that enable or enhance IP Communications Systems for both telecom and datacom applications.
Frederic Dickey is the VP of Product Management and Customer Services for Sangoma and we met up with him at FreePBX World in Las Vegas to discover more about their new products and how they interact with the FreePBX® EcoSystem.

Ansible : Freeswitch role : nouvelle version – v1.1

Je viens de publier la mise à jour du role FreeSwitch pour Ansible, le célèbre moteur d’orchestration. Ce role permet d’installer FreeSwitch à partir des sources sur les systèmes linux basés sur Debian/Ubuntu.

J’ai ajouté la gestion des variables, vous permettant d’utiliser une configuration collant au mieux de vos besoins.

L’utilisation est simple. Il faut dans un premier temps installer Ansible, puis ajouter mwolff44.freeswitch-mw à vos roles. Vous avez un exemple de configuration ci-dessous :

- hosts: all
  vars_files:
    - 'defaults/main.yml'
  tasks:
    - include: 'tasks/main.yml'
  handlers:
    - include: 'handlers/main.yml'

Le repository du role Ansible pour FreeSwitch est hébergé chez Github et est bien sûr validé en intégration continue grâce au service de travis-ci.org.

Si vous voyez des idées d’amélioration, n’hésitez pas.

Howto : comment configurer monit pour surveiller FreeSwitch

Guide détaillant la procédure de configuration de mont pour surveiller FreeSwitch et être alerter en cas de panne.

Il est essentiel de surveiller les services que nous déployons au sein de nos entreprises ou pour nos clients. Je vais vous présenter aujourd’hui comment superviser FreeSwitch avec Monit.

Monit est un outil léger open source (licence AGPL) permettant de superviser et de gérer les systèmes Unix. Il est capable d’exécuter des actions en cas de détection de défaillance.

Monit est disponible sous forme de paquet dans la plupart des distributions. L’installation sur un système basé sur Debian est très simple :

apt-get install monit

pour Centos, ce n’est pas plus compliqué :

yum install monit

La première chose à faire est de vérifier que la variable « START » a bien la valeur yes dans le fichier /etc/default/monit afin de permettre à Monit de démarrer.

Ensuite, la configuration centrale de Monit se fait au sein du fichier monitrc localisé sous /etc/monit. Dans ce fichier, vous pouvez notamment modifier l’adresse email qui recevra les alertes.

Ensuite, les configuration sont dans le répertoire /etc/monit/conf.d . Nous allons créer un fichier nommé freeswitch et y ajouter les lignes suivantes :

check process freeswitch with pidfile /usr/local/freeswitch/run/freeswitch.pid
  start program = "/etc/init.d/freeswitch start"
  stop program  = "/etc/init.d/freeswitch stop"

Nous allons simplement vérifier que FreeSwitch est bien démarré et si ce n’est pas le cas, nous demandons à Monit de le démarrer.

Avant de lancer Monit, vérifier bien que la syntaxe des fichiers de configuration est bonne avec la commande :

monit -t

Vous devez obtenir une belle réponse « Control file syntax OK ».

Nous allons maintenant compléter notre test afin de s’assurer que le process SIP est toujours fonctionnel. Pour cela, nous allons ajouter les lignes suivantes à notre fichier :

check host fs_server with address 127.0.0.1
   if failed port 5060 type udp protocol sip
      with target "localhost:5060" and maxforward 6
   then alert

En cas de dysfonctionnement, Monit vous enverra un mail d’alerte (attention à bien configurer votre mail et serveur dans le fichier monitrc).

Il possible de pousser aussi la supervision plus loin, selon le taux d’utilisation de votre machine, vérifier les process, les fichiers de log … et l’usage de la solution M/Monit permet un monitoring de vos serveurs centralisé simplement.

Ansible : freeswitch role – installation et compilation automatique

Je viens de publier mon nouveau role pour Ansible, le célèbre moteur d’orchestration. Ce role permet d’installer FreeSwitch à partir des sources sur les systèmes linux basés sur Debian/Ubuntu.

Je viens de publier mon nouveau role pour Ansible, le célèbre moteur d’orchestration. Ce role permet d’installer FreeSwitch à partir des sources sur les systèmes linux basés sur Debian/Ubuntu.

Il fait pour vous les tâches longues : installation des dépendances, téléchargement des sources, configuration et compilation, installation de FreeSwitch, sécurisation de l’installation (user et droits) et paramétrage du script de démarrage.

L’utilisation est simple. Il faut dans un premier temps installer Ansible, puis ajouter mwolff44.freeswitch-mw à vos roles. Vous avez un exemple de configuration ci-dessous :

- hosts: all
  vars_files:
    - 'defaults/main.yml'
  tasks:
    - include: 'tasks/main.yml'
  handlers:
    - include: 'handlers/main.yml'

Le repository du role Ansible pour FreeSwitch est hébergé chez Github et est bien sûr validé en intégration continue grâce au service de travis-ci.org.

Si vous voyez des idées d’amélioration, n’hésitez pas.

Téléphone SIP Snom : alerte de sécurité

Une alerte de sécurité vient d’être publiée ce jour sur le site Security Focus concernant les téléphones SIP de la marque SNOM. Les alertes sont de type critique. Si vous utilisez ces téléphones dans votre entreprise ou chez vos clients, je vous invite à lire de manière attentive cette alerte et d’apporter les correctifs nécessaires.

L’alerte touche les téléphones de bureau des gammes 3xx, 7xx et 8xx .

Les vulnérabilités touchent l’implémentation du serveur web implanté dans le téléphone, donc potentiellement toutes les actions utilisant ce serveur.

Les téléphones peuvent être compromis complètement par une attaque externe et il est possible de faire :

  • ajouter une backdoor au système, backdoor qui restera même si le téléphone est remis à 0 (reset)
  • activer à distance le microphone du téléphone afin d’écouter la pièce où est situé le téléphone
  • récupérer les conversations réalisées via le téléphone en installant un sniffer
  • rediriger les appels vers des numéros spéciaux avec pour conséquence une facture fortement alourdie.
  • utiliser le téléphone comme point d’entrée pour attaquer le réseau interne

La recommandation est terrible : ne pas utiliser le téléphone tant qu’un nouveau firmware ne vienne corriger les failles découvertes !

It is highly recommended by SEC Consult not to use this product until a
thorough security review of the firmware has been performed by security
professionals and all identified issues have been resolved.

Si vous voulez quand même utiliser ces téléphones, qui sont des produits de qualité, il faut respecter des règles strictes (règles qui devraient être mis en place dans tous les cas, quelque soit le téléphone) :

  • ne pas exposer l’interface web à l’extérieur de votre réseau, mais uniquement à des machines de confiance
  • ne pas réaliser d’auto-provisioning via un réseau externe non chiffré et bloquer la configuration via le serveur de Snom (provisioning.snom.com) – Ce provisioning est réalisé via le protocole HTTP non chiffré
  • ne pas exposer le port 5060 à l’extérieur de votre réseau sans avoir mis en place un filtrage

Pour conclure, si vous utilisez le client OpenVPN embarqué dans le téléphone, je vous engage à bien lire cette note de sécurité du wiki de Snom, et de réaliser au plus vite la mise à jour de vos téléphones.

SIP : comment débugger ?

Introduction

Votre nouveau serveur VoIP est en place. Mais pour une raison que vous ignorez vos appels ne fonctionnent pas comme prévus. Pas de panique, je vais vous présenter quelques outils en ligne de commande qui vont vous aider à déterminer la source du problème. En effet, le protocole SIP n’est pas toujours aussi simple à l’usage que dans la théorie. Les informations fournies par les systèmes de téléphonie Open Source (Asterisk, Freeswitch, Yate …) ou propriétaires ne sont pas toujours d’une grande aide (manque de lisibilité, de souplesse …).

Pourquoi des outils en ligne de commande : l’installation est simple et très rapide, fonctionnent sur toutes les distributions linux, et l’information souhaitée est facilement et rapidement accessible. Il est tout à fait possible d’utiliser ces outils afin de sauvegarder les informations collectées dans un fichier afin de réaliser des analyses plus fines avec des logiciels intégrant une interface graphique, comme le renommé Wireshark.

Pré requis

Vous vous êtes assuré de la bonne configuration de vos comptes SIP (du moins sur le papier), que le routage (diaplan) est correctement fait et que les appels sont possibles (droits d’accès à la route bien affectés, balance financière positive …). Si pour vous, vous ne voyez pas de loup à cette étape, nous allons entrer dans le dur.

Procédure

Je vais maintenant vous expliquer comment trouver de manière efficace la source du problème. Nous allons du plus général vers le plus détaillé. Tout d’abord, vérifier que les échanges de messages SIP se passent comme prévus (je ne vais pas les rappeler ici, je vous laisse ressortir vos cours. J’écrirais peut-être un de ces jours un article les détaillants) : enregistrement, établissement d’un appel, raccroché de l’appel. Si une des étapes est manquantes, il va falloir trouver des informations détaillées. Nous allons voir ces étapes dans le paragraphe suivant.

Comment tracer les messages SIP

Nous allons dans un premier temps vérifier que les messages SIP échanger sont conforment. Nous n’avons pas besoin de tout le détail, juste du type de message SIP (100, 180, 407, 404 …). On va ainsi pouvoir voir très simplement à quelle étape le problème se pose. Le serveur distant souhaite que le compte soit enregistrer avant d’autoriser un appel (merde, on m’avait dit que c’était une authentification par IP ?), le serveur distant vous répond par un bon 404 ? …

Pour cela, je vais utiliser tshark, outil renommé de tout bon administrateur linux. Il utilise la librairie pcap pour capturer le traffic de l’interface déclarée (avec l’option -i) et affiche (ou enregistre dans un fichier avec l’option -w) les informations décodées de paquets capturés. Les fichiers de capture créés peuvent être lus par Wireshark.

Nous allons utiliser toute la puissance de filtrage de tshark afin de trouver l’information souhaitée. Par exemple, il faut vérifier que l’invite correspond bien au format attendu.

tshark -i eth0 -R "ip.addr==78.x.y.10 and sip.CSeq.method eq INVITE" (-V)

Si vous souhaitez capturer l’ensemble du traffic SIP d’une adresse ip spécifique et d’un port spécifique :

tshark -i eth0 -R "ip.addr==78.x.y.10 and port==5060" -z sip,stat

Un autre outil fort utile peut être utilisé, j’ai nommé tcpdump.

tcpdump est un analyseur de paquet. Il utilise libpcap, une librairie C/C++ afin de capturer les paquets.  Vous devez avoir les droits de super utilisateur afin de pouvoir l’utiliser.

Nous allons voir le détail de la commande à utiliser :

-i eth0 — le nom de l’interface à écouter

-n — afin de ne pas résoudre les hostnames

host 1.2.3.4 — filtre le traffic sur cette adresse IP (peut être remplacé par net pour capturer un réseau ex : net 1.2.3.0/24)

proto udp — en général on utilise de l’udp

-w /tmp/file.pcap — pour enregistrer la capture dans un fichier. Mais comme on souhaite avoir le retour en console, on ne vas pas ajouter cette option.

Vous trouverez le détail des options de la commande de tcpdump sur cette page.

Conclusion

Nous venons de voir de manière simple comment débugger un chance SIP entre 2 machines. Vous pouvez utiliser la capture afin de l’importer dans un GUI comme Wireshark afin de réaliser des recherches plus poussées, afficher une vue graphique des échanges ou générer des statistiques.

Il est aussi possible d’utiliser d’autres outils comme ngrep. Je vous présenterai dans un prochain article l’outil HOMER.

Text to speech : comment utiliser festival, eSpeak et GoogleTTS avec asterisk, solution de téléphonie open source

Introduction

Il est souvent indispensable de diffuser des messages spécifiques aux appelants, des messages pouvant changer selon le contexte de l’appel (numéro appelé, numéro de compte saisi …). Il est difficile de prévoir tous les cas et d’enregistrer en studio à l’avance toutes les éventualités sans même parler du coût. Je vous propose d’utiliser un service de google permettant de générer un signal audio à partir d’un texte.

Nous allons voir dans cet article 3 moyens différents de réaliser de la synthèse vocale pour notre serveur asterisk.

Note : toutes les commandes sont pour une machine fonctionnant sous debian/ubuntu, mais vous pouvez simplement les transposer pour un autre système d’exploitation linux.

Qu’est-ce que le text to speech ?

Text to speech ou TTS pour les intimes, est une technique informatique permettant de transformer un texte écrit en parole artificielle, autrement dit, c’est de la synthèse vocale. Je vous renvoie sur wikipedia afin de découvrir l’histoire et les techniques de la synthèse vocale.

Il existe plusieurs solutions libres de synthèse vocale : Festival et eSpeak sont les 2 les plus connues fonctionnant sous linux. Nous allons voir l’installation et l’usage sous asterisk.

Une autre solution non libre, mais gratuite et qui à l’avantage de la simplicité : GoogleTTS. GoogleTTS est un service en ligne de Google (ah bon ?) réalisant de la synthèse vocale et qui est de plus, de bonne qualité.

Solution de synthèse vocale Festival

Installation

L’installation est très simple, le paquet étant disponible dans les repos de Debian et Ubuntu mais aussi de Centos.

apt-get install festival speech-tools

Ensuite, vous devez modifier le fichier festival.scm afin de permettre à asterisk de se connecter au serveur festival. Le fichier est situé dans le répertoire /usr/share/festival/

(define (tts_textasterisk string mode)
"(tts_textasterisk STRING MODE)
Apply tts to STRING. This function is specifically designed for
use in server mode so a single function call may synthesize the string.
This function name may be added to the server safe functions."
(let ((wholeutt (utt.synth (eval (list 'Utterance 'Text string)))))
(utt.wave.resample wholeutt 8000)
(utt.wave.rescale wholeutt 5)
(utt.send.wave.client wholeutt)))

Ensuite, il faut démarrer le serveur festival avec la commande suivante :

festival --server 2>&1 > /dev/null &

Bine entendu, il est souhaitable de l’ajouter au fichier /etc/rc.local afin que le serveur festival soit lancé au démarrage de la machine.

Maintenant, nous devons paramétrer asterisk afin de lui indiquer où joindre notre serveur festival. Pour cela il faut modifier le fichier /etc/asterisk/festival.conf comme ci-dessous :

[general]
host=localhost
port=1314
;usecache=yes
;cachedir=/var/lib/asterisk/festivalcache/
festivalcommand=(tts_textasterisk "%s" 'file)(quit)\n

Maintenant, nous allons vérifier que le module est bien chargé par asterisk en entrant cette commande en cli :

CLI> core show application festival

  -= Info about application 'Festival' =-

[Synopsis]
Say text to the user.

[Description]
Connect to Festival, send the argument, get back the waveform, play it to
the user, allowing any given interrupt keys to immediately terminate and return
the value, or 'any' to allow any number back (useful in dialplan).

[Syntax]
Festival(text[,intkeys])

[Arguments]
Not available

[See Also]
Not available

Si vous obtenez une sortie comme celle-ci , c’est parfait, sinon chargez le module manuellement :

CLI> module load app_festival.so

Utilisation

Nous allons maintenant le tester en modifiant le fichier /etc/asterisk/extensions.conf :

;Festival demo
exten => s, 1, Answer()
exten => s, n, Festival('Welcome! Your phone number is ${CALLERID(num)}.')
exten => s, n, Hangup()

Le résultat est acceptable sans être exceptionnel. Je ne vous ai pas présenté l’installation de la langue française, car la qualité n’est pas suffisante en regard des autres solutions que je vais présenter dans la suite de ce post. Mais comme festival est une solution open source nativement intégrée avec asterisk, il me semblait important de vous en parler.

Solution de synthèse vocale eSpeak

Installation

Tout d’abord, il faut installer les fichiers de développement d’asterisk. Ensuite, il est d’installer eSpeak. Pour nous simplifier la vie, nous allons utiliser les paquets, mais pour un serveur de production je vous encourage à installer eSpeak via les sources.

apt-get install espeak
apt-get install asterisk-espeak

L’installation via les paquets est maintenant terminée.

Utilisation

Nous allons voir l’utilisation de eSpeak au sein du dialplan asterisk. La commande à utiliser est Espeak et est assez simple à utiliser. Voici la syntaxe :

Espeak(text[,intkeys,language])

Le texte est entre guillemets, intkey peut prendre 2 valeurs, soit any, soit une des touches du téléphones et language la langue souhaitée. Voici un exemple :

;eSpeak Demo

exten => 1234,1,Answer()

;;Play mesage using default language as set in espeak.conf

exten => 1234,n,Espeak("This is a simple espeak test in english.",any)

;;Play message in Spanish

exten => 1234,n,Espeak("Esta es una simple prueba espeak en español.",any,es)

;;Play message in Greek

exten => 1234,n,Espeak("Αυτό είναι ένα απλό τέστ του espeak στα ελληνικά.",any,el)

;;Read a text file from disk (relative to the channel language)

;;and play it with espeak using the asterisk channel language.

exten => 1234,n,ReadFile(MYTEXT=/path/${LANGUAGE}/myfile,200)

exten => 1234,n,Espeak("${MYTEXY}",any,${LANGUAGE})

exten => 1234,n,Hangup()

Le logiciel est sous licence GPL, vous êtes donc libre de l’utiliser et bien entendu de l’améliorer.

Solution de synthèse vocale GoogleTTS

Installation

Afin d’utiliser GoogleTTS sur notre serveur asterisk, il est nécessaire que notre serveur ait un accès à internet (le script doit faire appel aux serveurs de Google) mais il nécessite aussi l’installation des paquets suivants :

apt-get install perl libwww-perl sox mpg123

Ensuite, nous allons utiliser un script AGI développer par Zaf, asterisk-googletts. Le script est développé en PERL.

Premièrement, localisez l’emplacement du dossier agi-bin afin d’y installer le script. Pour cela, vérifiez la variable astagidir dans le fichier asterisk.conf . Ensuite téléchargez le fichier googletts.agi dans ce répertoire :

wget https://raw.github.com/zaf/asterisk-googletts/master/googletts.agi
chmod +x googletts.agi

Maintenant, vous avez terminé l’installation !.

Utilisation

L’utilisation est extrêmement simple. Il suffit de faire un appel agi afin d’utiliser la synthèse vocale. Voici un exemple simple :

;DEMO GoogleTTS
exten => S,1,Answer()
exten => s,n,agi(googletts.agi,"Asterisk vous parle enfin.",fr)
exten => s,n,Hangup()

Un peu d’explication : googgletts.agi accepte plusieurs variables (4) que nous allons détailler :

  • La première contient le texte. L’exemple est parlant !
  • La seconde contient la langue qui doit être utilisée (par défaut en-US). La liste est très longue.
  • Les autres variables sont optionnelles :
    • 3ème variable : elle peut prendre soit la valeur « any » ou n’importe quel chiffre ou # ou * . Quand un de ces éléments est saisi par l’appelant sur son clavier téléphonique, la lecture du texte est arrêtée.
    • 4ème variable correspond à la vitesse de lecture (par défaut la valeur vaut 1). Vous pouvez accélérer la lecture en utilisant par exemple cette valeur 1.2 .

L’utilisation est assez simple et le résultat est convaincant. La communication avec les serveurs de Google se fait en clair, mais il est possible d’utiliser une connexion cryptée (pour cela, il faut modifier le script PERL.

Conclusion

Nous avons vu 3 solutions différentes afin de réaliser de la synthèse vocale sous asterisk. Sachez qu’il en existe d’autres gratuites ou payantes de différente qualité. A part festival dont la qualité me semble juste, eSpeak et GoogleTTS apporte une qualité suffisante pour la plus part des installations. Quelle solution utilisez-vous ?

FreeSWITCH : problème avec git « merge error »

Vous rencontrez une erreur « merge error » lorsque vous souhaitez faire un pull sur la branche 1.4 de FreeSWITCH. Pas de panique, l’équipe de développement FreeSWITCH a réalisée quelques modifications. Pour corriger cette erreur impactant votre repo local, il vous suffit d’entrer cette commande :

git reset --hard origin/v1.4

Vous pouvez installer maintenant la dernière version stable 1.4.