Mise à jour du 5 janvier 2024 : correction de quelques erreurs de configuration détaillées en annexe à la fin du billet.

Cela fait environ neuf ans maintenant que j’ai mis en place un serveur Asterisk pour gérer ma téléphonie domestique. Depuis, la partie qui a été de loin la plus compliquée a été l’accès au réseau téléphonique commuté (RTC) : avec une fibre chez Orange, et donc une ligne téléphonique fixe dont l’accès passe obligatoirement par leur Livebox, un matériel qui n’a pas été conçu pour être raccordé à autre chose qu’un téléphone à touches, cette contrainte a été quelque peu frustrante parfois.

Après avoir attiré les foudres d’Orange quand j’ai essayé de parler directement en SIP à leur infrastructure IMS, quelles solutions me reste-t-il pour profiter de mon serveur Asterisk sans prendre de ligne VoIP chez un opérateur tiers ?

Dans ce billet, qui sera l’opportunité pour moi de mettre à jour des articles que j’ai rédigés précédemment sur le sujet, je vous présente la solution que j’utilise actuellement : passer par un boîtier de conversion SIP vers analogique (FXS/FXO) comme la gamme MP-1xx de chez AudioCodes. J’ai eu récemment l’occasion d’aider un de mes lecteurs à configurer le sien et ce billet, que j’espère pouvoir être utile à d’autres, est le fruit d’un long échange de courriels qui lui a permis lui aussi de profiter de la souplesse d’Asterisk.

Pourquoi un boîtier séparé

Mon installation téléphonique a donc un certain historique sur lequel il peut être intéressant de revenir dessus en préambule. Au début, en 2014, mon serveur Asterisk tournait sur une machine sous Gentoo Linux dans laquelle j’avais enfiché une carte OpenVox A400P, une carte PCI fournissant jusqu’à quatre interfaces FXO (à raccorder à des lignes analogiques) ou FXS (à raccorder à des téléphones analogiques). Environ deux ans plus tard, j’ai remplacé la machine par une nouvelle, plus puissante, ce qui a été l’occasion de passer à FreeBSD, mais j’utilisais toujours cette même carte.

J’ai d’ailleurs toujours continué à utiliser cette carte pendant que j’expérimentais avec siproxd_orange. En temps normal, ce proxy SIP que j’avais concocté pour interfacer mon Asterisk directement avec l’infrastructure téléphonique d’Orange n’était pas en production chez moi, mais il m’arrivait ponctuellement de faire de petites campagnes d’essai. Je tombais alors sur d’étranges bugs qui empêchaient souvent le bon fonctionnement des appels entrants, comme en témoignent les billets consacrés aux versions 0.2 ou 0.2.1 de siproxd_orange. Puis après la fin du projet, je suis revenu à la carte OpenVox.

Cette solution, quoique peu élégante à mon goût, fonctionnait bien pendant quelques années jusqu’au milieu de l’année 2020, quand mon serveur s’est mis à avoir des kernel panics de manière assez aléatoire et inexpliquée. Cela arrivait souvent pendant un appel téléphonique. Nous étions en plein confinement à ce moment-là, et un de ces plantages est survenu en plein milieu d’une réunion client ; c’était très embarrassant. J’ai fini par obtenir la preuve que le fautif était le portage FreeBSD de DAHDI, le pilote de la carte FXO, qui n’avait plus l’air maintenu. Du côté Linux, le même pilote, mieux tenu à jour, avait carrément retiré la prise en charge de mon modèle de carte analogique : signe qu’il était temps de trouver une autre solution.

Je me suis donc tourné vers un adaptateur téléphonique sous la forme d’un boîtier à part. Le principe est simple : munis d’une Ethernet et d’une prise FXO, ces boîtiers font la conversion entre la signalisation et les signaux analogiques historiques d’une part, et SIP et RTP d’autre part. Il suffit généralement de paramétrer le routage à effectuer quand un INVITE arrive du côté SIP ou quand une sonnerie arrive côté FXO.

Donc, fin 2020, j’ai investi dans un adaptateur Grandstream HT-813, puis j’ai retiré la carte analogique. Les plantages se sont arrêtés, mais cette solution de remplacement ne me plaisait guère. Le son était gâché par un grésillement à 60 Hz en permanence. Il y avait aussi parfois des ratés dans l’extraction du numéro de l’appelant. Mais ce qui m’a contraint à abandonner cette solution est que le boîtier ne détectait pas toujours les sonneries correctement : parfois, un appel entrant était détecté comme un premier appel, abandonné, puis un second arrivant très vite après, alors qu’en fait c’était le même train de sonneries. Peut-être des problèmes qui ont été corrigés par des mises à jour de firmware depuis, mais je n’avais guère envie de jouer les béta-testeurs pour un produit qui m’a coûté pas loin de cent euros.

Alors, début 2021, j’ai saisi une occasion sur eBay : un AudioCodes MP-114 d’occasion pour seulement 30 USD, dans sa configuration à deux prises FXS et deux prises FXO. Ce matériel me donne pleinement satisfaction : il tourne maintenant depuis un peu plus de deux ans sans aucune défaillance ni bug. L’appareil a beaucoup plus de possibilités et de souplesse que le GrandStream, ce qui a pour inconvénient d’en rendre le paramétrage difficile. Mais après avoir pris le temps de lire le manuel d’administration, j’ai fini par comprendre sa logique. Ce faisant, j’ai commis une grossière erreur : celle de ne pas documenter les paramètres que j’ai changés par rapport aux réglages usine.

Heureusement, une conversation récente par e-mail avec un de mes lecteurs a été l’occasion pour moi de revisiter la marche à suivre pour configurer un serveur Asterisk et un boîtier AudioCodes pour permettre à Asterisk d’accéder au RTC via une Livebox. Je partage donc avec vous, dans ce billet, la marche à suivre pour une configuration minimale viable d’Asterisk et d’un AudioCodes MP-1xx à cet effet. Merci à Benjamin, sans qui ce type de billet aurait été plus fastidieux à préparer pour moi !

Prérequis

Avant de commencer, il faut recueillir les adresses IPv4 du serveur Asterisk et de l’AudioCodes (ces boîtiers-là ne prennent pas en charge IPv6, hélas).

Ici, nous supposerons que :

• le serveur Asterisk a pour adresse IPv4 192.168.10.10 et l’AudioCodes 192.168.10.20 ;
• Asterisk et tous les postes téléphoniques ont des URI SIP qui finissent en @tel.example ;
• le nom d’hôte complet de l’AudioCodes est audiocodes.tel.example ;
• le numéro attribué à la ligne externe est le 09 00 11 22 33, ce qui s’exprime au format E.164 comme +33900112233.

Mon utilisation de noms de domaine dans les URI SIP n’est qu’une question d’élégance ; ce n’est pas indispensable. On peut très bien s’en passer ; dans ce cas, il faut simplement substituer l’adresse IP d’Asterisk à tel.example et l’adresse IP de l’AudioCodes à audiocodes.tel.example.

La configuration que je donne est valable pour un AudioCodes MP-114_FXS_FXO. Ses ports FXS sont numérotés 1 et 2 et ses ports FXO sont les ports 3 et 4. Sur un MP-118_FXS_FXO, les ports FXS sont les ports 1 à 4 et les ports 5 à 8 sont les FXO.

Enfin, côté Asterisk, je pars du principe que la pile SIP utilisée est celle de chan_pjsip et non pas chan_sip, qui est dépréciée.

Configuration d’Asterisk

Du côté d’Asterisk, il faut déclarer l’existence du boîtier AudioCodes. La configuration est similaire à celle d’un « trunk » SIP ordinaire.

Pour les appels sortants, il faut déclarer un endpoint et un AOR. J’ai nommé les deux audiocodes. La configuration est la suivante :

[audiocodes-common-settings](!)
type=endpoint

; À remplacer par le contexte servant de point d'entrée aux appels
; entrants
context=incoming_from_audiocodes

; À remplacer par le nom d'un transport sur lequel l'AudioCodes est
; joignable depuis Asterisk, et vice-versa.
transport=transport-udp-ipv4

; On n'autorise que le codec G.711 loi A : ça nous donnera la meilleure
; qualité. Les autres codecs sont strictement inutiles.
disallow=all
allow=alaw

; Mettre la langue des annonces et les tonalités en français.
language=fr
tone_zone=fr

; L'AudioCodes transmet le numéro de l'appelant tel que reçu par la
; Livebox, et on peut lui faire confiance
trust_id_inbound=yes

; Éléments de routage
from_domain=tel.example

[audiocodes](audiocodes-common-settings)
type=endpoint
aors=audiocodes

[audiocodes]
type=aor
max_contacts=1
remove_existing=yes

; Modifier le nom de domaine, mais garder « audiocodes@ ».
contact=sip:audiocodes@audiocodes.tel.example

Pour les appels entrants, l’AudioCodes envoie à Asterisk des INVITE dont l’en-tête From a une URI qui contient le numéro de l’appelant. Pour que cela fonctionne correctement avec Asterisk, il faut déclarer un endpoint anonymous qui rejette tous les appels venant d’inconnus (si ce n’est pas déjà le cas), ainsi qu’un endpoint pour gérer le cas d’un appel entrant venant de l’AudioCodes.

; Endpoint utilisé pour les appels entrants.
; Garder le « anonymous@ » et adapter le nom de domaine
[anonymous@audiocodes.tel.example](audiocodes-common-settings)
type=endpoint
deny=0.0.0.0/0
deny=::/0
permit=192.168.10.20              ; à adapter

; Endpoint utilisé pour les appels entrants masqués.
; Ici, il faut que ce soit « anonymous@anonymous.invalid ».
[anonymous@anonymous.invalid](audiocodes-common-settings)
type=endpoint
deny=0.0.0.0/0
deny=::/0
permit=192.168.10.20              ; à adapter

; anonymous
; utilisé pour jeter tous les autres
[anonymous]
type=endpoint
language=fr
tone_zone=fr
deny=0.0.0.0/0
deny=::/0 

C’est tout du côté de la configuration de PJSIP.

La suite se passe dans extensions.conf. Nous allons créer un contexte minimal, incoming_from_audiocodes, qui fait sonner les deux téléphones SIP Tel1 et Tel2 simultanément :

[incoming_from_audiocodes]

exten => +33900112233,1,NoOp()
 same => n,Dial("PJSIP/Tel1&PJSIP/Tel2", 20)
 same => n,Hangup() 

Pour les appels sortants, il ne reste plus qu’à modifier le contexte utilisé par les téléphones internes pour que les appels sortants passent par un appel à Dial() comme :

Dial("PJSIP/audiocodes/sip:${EXTEN}@audiocodes.tel.example")

Configuration du boîtier AudioCodes

Ci-après figure une longue liste de paramètres à modifier sur le boîtier AudioCodes. Sur l’interface d’administration Web, dans le mode « Configuration », il y a dans la colonne de gauche la possibilité d’afficher les réglages de base ou les réglages complets. Pour cette liste, il faut au préalable cliquer sur la case « Full ».

Compatibilité électrique et électronique

Les paramètres par défaut des boîtiers AudioCodes conviennent pour une compatibilité électrique et électronique avec les réseaux téléphoniques états-uniens. Les caractéristiques des lignes téléphoniques françaises étant différentes, nous allons commencer par effectuer les réglages de compatibilité ci-après.

• VoIP > Media > Fax/Mode/CID Settings :

  • Caller ID TypeStandard ETSI

• VoIP > Coders and Profiles > Coders :

  Tout supprimer. Ne laisser que le codec « G.711A-law », qui donne la meilleure qualité audio durant les communications. Laisser « Packetization Time » à 20 ms et « Silence Suppression » à « Disabled ».

• VoIP > GW and IP to IP > Analog Gateway > FXO Settings

  • Dialing ModeOne Stage
  • Answer SupervisionNo
  • Rings before Detecting Caller ID0
  • Disconnect Call on Busy Tone Detection (CAS)Enable
  • Disconnect On Dial ToneEnable
  • FXO Double AnswerDisable

  Le paramètre « Rings before Detecting Caller ID » doit être mis à 1 si, à chaque appel entrant, l’AudioCodes signale d’abord un appel masqué avant de l’annuler et signaler un nouvel appel entrant avec le numéro du correspondant. La valeur 0 convient pour la Livebox 4 ; la valeur 1 convient pour la Livebox 6.

• VoIP > Media > Analog Settings

  • Min. Hook-Flash Detection Period [msec]100
  • Max. Hook-Flash Detection Period [msec]500
  • FXS Coefficient TypeEurope
  • FXO Coefficient TypeEurope

  Après avoir modifié ces paramètres, l’AudioCodes devra redémarrer pour les appliquer ; le bouton « Burn » permet de sauvegarder la configuration actuelle.

• VoIP > SIP Definitions > Advanced Parameters

  • Polarity ReversalDisable
  • Current DisconnectDisable

J’ai également été amené à jouer avec le paramètre « Voice Volume », sur la page VoIP > Media > Voice Settings, pour obtenir un niveau d’écoute satisfaisant. De mon côté, j’ai choisi de positionner ce volume à +6 dB.

Pour finir, il y a un paramètre qui nécessite d’exporter le fichier de configuration au format .ini, l’éditer puis le réimporter. Il s’agit d’ajouter le paramètre ETSICallerIDTypeOneSubStandard, qu’il faut positionner à 2 afin que l’AudioCodes détecte le signal correspondant à l’identité de l’appelant au bon moment à la réception d’un appel entrant. Le fichier de configuration devrait comporter une section comme ceci :

[Analog Params]

MinFlashHookTime = 100
FlashHookPeriod = 500
ETSICallerIDTypeOneSubStandard = 2
CountryCoefficients = 66
FXSCountryCoefficients = 66
EnableFXOCurrentLimit = 1

Le sous-standard ainsi sélectionné désigne la transmission de l’identité de l’appelant par une pulsation de sonnerie juste avant la première sonnerie, ce qui est désigné par la norme ETSI EN 300 659-1 par le sigle « RP-AS » (Ringing Pulse Alerting Signal). Le mode de transmission est détaillé dans le § 6.1.2 de cette norme.

Si vous comptez utiliser vos prises FXS avec des téléphones à cadran comme le Socotel S63, vous pouvez aussi ajouter le paramètre EnablePulseDialDetection = 1 dans le fichier de configuration, dans la même section.

Interopérabilité avec Asterisk

Les paramètres ci-dessous permettent au boîtier AudioCodes et à Asterisk de fonctionner correctement ensemble.

• VoIP > GW and IP to IP > Analog Gateway > Caller Display Information

  S’assurer que pour tous les ports FXO (donc les ports 3 et 4 sur un MP-114), le paramètre « Presentation » soit positionné à « Restricted » et non pas « Allowed ». Ceci permet de signaler les appels masqués comme tels.

• VoIP > GW and IP to IP > Analog Gateway > Caller ID Permissions

  Pour chaque port FXO, mettre « Caller ID » à « Enable ». Ceci permettra à l’AudioCodes de recevoir le numéro de l’appelant de la Livebox pour le transmettre ensuite à Asterisk.

• VoIP > SIP Definitions > General Parameters

  • Asserted Identity ModeAdd P-Asserted-Identity

  Ceci devrait faire en sorte que l’AudioCodes transmette bien à Asterisk le numéro de l’appelant tel qu’il l’a reçu de la Livebox, si ce n’était pas déjà le cas.

• VoIP > GW and IP to IP > Analog Gateway > FXO Settings

  • Waiting for Dial ToneNo

• VoIP > SIP Definitions > General Parameters

  • Enable Early MediaEnable

Routage

Les paramètres de configuration ci-après définissent ce que l’AudioCodes doit faire lorsqu’il reçoit un appel côté analogique ou côté SIP :

• VoIP > Control Network > IP Group Table

  Cliquer sur « Add », puis saisir les paramètres suivants :

  • Index1
  • DescriptionRTC
  • Proxy Set ID1
  • SIP Group Nameaudiocodes.tel.example
  • Contact Useraudiocodes
  • Local Host Nameaudiocodes.tel.example
  • Media Realm Name(vide)
  • IP Profile ID0

• VoIP > Control Network > Proxy Sets Table

  Sélectionner le Proxy Set ID 1, puis saisir :

  • Proxy Address 1asterisk.tel.example
  • Transport Type 1UDP

• VoIP > GW and IP to IP > Hunt Group > Endpoint Phone Number

  Dans une ligne du tableau, configurer les éléments suivants :

  • Channel(s)5-8
  • Phone Numberif-fxo5
  • Hunt Group ID1
  • Tel Profile ID0

  Le paramètre « Channel(s) » dépend du matériel : sur un MP-114_FXS_FXO, ce sera le port 3 ; sur un MP-118_FXS_FXO, ce sera le port 5.

  Sur certains modèles, il se peut que les numéros de canaux soient numérotés à partir de 0 plutôt qu’à partir de 1. Au cas où la configuration ne marcherait pas, essayez en retranchant 1 au numéro de port dans le champ « Channel(s) ».

  Le « Phone Number » de ce Hunt Group est obligatoire, mais peut être alphanumérique à condition de se terminer par un chiffre. Une possibilité est de mettre « if-fxo » suivi du numéro du port de la première prise FXO (comme « if-fxo3 »). Ainsi, les prises FXO peuvent être adressés par des URI SIP de la forme sip:if-fxoN@audiocodes.tel.example, où N désigne un numéro de port.

• VoIP > GW and IP to IP > Hunt Group > Hunt Group Settings

  Cliquer en haut à droite sur « Advanced Parameter List » pour afficher les paramètres avancés.

  Dans une ligne du tableau, configurer les éléments suivants :

  • Hunt Group ID1
  • Channel Select ModeCyclic Ascending
  • Registration Mode(laisser vide)
  • Serving IP Group ID1
  • Gateway Nameaudiocodes.tel.example
  • Contact Useraudiocodes

• VoIP > GW and IP to IP > Routing > Tel to IP Routing

  Dans une ligne du tableau, saisir :

  • Src. Hunt Group ID1
  • Dest. Phone Prefix*
  • Source Phone Prefix*
  • Dest. IP Address(vide)
  • Port(vide)
  • Transport TypeNot Configured
  • Dest. IP Group ID1
  • IP Profile ID0
  • Cost Group IDNone

• VoIP > GW and IP to IP > Routing > IP to Hunt Group Routing

  Afficher les paramètres avancés.

  Dans une ligne du tableau, saisir :

  • Dest. Phone Prefix[+,0,1,3,*,#]
  • Source Phone Prefix(vide)
  • Source IP address(adresse IP du serveur Asterisk)
  • Hunt Group ID1
  • Source IP Group ID−1
  • IP Profile ID0

• VoIP > GW and IP to IP > Analog Gateway > Automatic Dialing

  Pour chaque port FXO, mettre « +33900112233 » et mettre « Auto Dial Status » à « Enable ». Ceci indique à l’AudioCodes que sur une sonnerie, il doit prendre la ligne immédiatement et rediriger l’appelant vers Asterisk.

Cette configuration représente le minimum nécessaire pour passer des appels depuis et vers l’extérieur. Faites un test dans les deux sens ; et si cela ne fonctionne pas, faites une capture réseau avec tcpdump sur la machine hébergeant Asterisk, récupérez le .pcap ainsi obtenu et examinez-le dans Wireshark sur un poste de travail.

Conclusion

Dans ce billet, je vous ai montré comment configurer de façon adéquate un boîtier AudioCodes afin de pouvoir profiter d’un serveur Asterisk derrière une ligne Livebox sans peine.

J’ai mis ces paramètres de configuration sur ce billet de blog dans l’espoir que cela puisse être utile à d’autres qui seraient dans une situation analogue. Bien entendu, cela n’est qu’un point de départ et il est possible de faire quelque chose de beaucoup plus sophistiqué si on souhaite adresser des points de détail comme le format des URI échangés entre Asterisk et l’AudioCodes.

Mise à jour du 5 janvier 2024

Les modifications suivantes ont été apportées :

• Ajout d’une photo d’un boîtier AudioCodes en guise d’illustration ;
• Côté AudioCodes :
  • Paramètre « Dest. Phone Prefix » : [+,0,1,3] devient [+,0,1,3,*,#] (pour pouvoir accéder aux services téléphoniques comme le renvoi d’appel),
  • Ajout d’un commentaire sur le paramètre « Rings before Detecting Caller ID » qui a parfois besoin d’être mis à 1 au lieu de 0 suivant la situation,
  • Ajout d’explications supplémentaires concernant le paramètre ETSICallerIDTypeOneSubStandard,
  • Le paramètre « Disconnect On Dial Tone » doit être mis à « Enable ». Cela afin de gérer correctement le cas d’un appel entrant décroché moins de quelques secondes après l’abandon de l’appel par l’appelant. Cela se manifestait le plus souvent par des messages vocaux laissés sur le répondeur consistant uniquement en une tonalité d’invitation à numéroter (tonalité continue),
  • Le paramètre « Caller Display Information » doit être mis à « Restricted » pour les ports FXO. Il s’agit en effet de ce qui est présenté par défaut en cas d’appel entrant sans présentation du numéro. Dans ce cas, il est souhaitable de faire apparaître cela comme un appel masqué. Avec le paramètre « Allowed », les appels masqués s’affichent comme venant de « 1 » ;
• Côté Asterisk : adaptation de la configuration pour gérer correctement le cas des appels masqués après modification de la configuration côté AudioCodes. Sans cela, les appels masqués sont rejetés.