Table of Contents

Scheda VoIP Sangoma A200

ATTENZIONE! Non comprate le schede Sangoma! Il software necessario a farle funzionare semplicemente fa schifo e per giunta non è libero!

La mia esperienza con questa scheda è pessima e non la consiglierei a nessuno, neanche se fosse gratis.

Caratteristiche

From www.freepbx.org: Sangoma's A200 cards can support up to four FXO or FXS Ports (minimum 2, maximum 4) as sold. They are sold in a variety of different configurations, ranging from bare boards (with no ports) which can have daughter boards installed on them later, to boards that have 4 FXOs or boards that have 4 FXS ports pre-installed.

You can add up to five REMORA cards to an A200 card. Each Remora card takes up an additional PCI Slot inside your computer case, but connects only to the main A200 Card. Each Remora card will give you an additional 4 ports.

Caso d'uso

Si vuole utilizzare Asterisk per connettere alcuni telefoni IP con una linea telefonica analogica. La scheda Sangoma è equipaggiata con un modulo FXO che fornisce due porte analogiche da collegarsi ad altrettante linee telefoniche

Pacchetti Debian Wheezy installati:

I pacchetti module-assistant e linux-headers servono per la compilazione dei moduli kernel dahdi.

Usare module-assistant per creare il pacchetto Debian dahdi-modules (moduli kernel)

Verificare di aver installato il pacchetto linux-headers relativo alla versione del kernel in uso.

È possibile eseguire la compilazione come utente non privilegiato, ridirigendo tutto nella directory corrente: 

cd /usr/local/src
mkdir dahdi-2.6.1+dfsg2-1
cd dahdi-2.6.1+dfsg2-1
module-assistant --userdir . --text-mode build dahdi

Quindi, da root, si installa il pacchetto .deb risultante: 

dpkg -i dahdi-modules-3.2.0-4-amd64_2.6.1+dfsg2-1+3.2.51-1_amd64.deb

La procedura module-assistant effettua un clean nella directory di compilazione, sfortunatamente questo impedisce la compilazione dei driver Wanpipe di Sangoma (vedi avanti). Per questo dopo aver eseguito module-assistant conviene eseguire nuovamente il make, per evitare problemi riportati più avanti: 

cd /usr/local/src/dahdi-2.6.1+dfsg2-1/usr_src/modules/dahdi/
make

Installare i programmi DAHDI user-space

Adesso si possono installare i pacchetti:

Perché il modulo kernel dahdi venga caricato bisogna creare un file di configurazione /etc/dahdi/system.conf con almeno queste direttive: 

loadzone        = it
defaultzone     = it

All'esecuzione di /etc/init.d/dahdi start viene caricato il modulo kernel dahdi, il kernel logga: 

[22710.527986] dahdi: Telephony Interface Registered on major 196
[22710.527991] dahdi: Version: 2.6.1
[22710.639833] dahdi_ioctl_chanconfig: No channel for number 1

Dopo aver caricato il modulo compaiono dei nuovi device: 

# ls -l /dev/dahdi/
crw-rw---T  1 root dialout 196, 254 Sep 15 21:52 channel
crw-rw---T  1 root dialout 196,   0 Sep 15 21:52 ctl
crw-rw---T  1 root dialout 196, 255 Sep 15 21:52 pseudo
crw-rw---T  1 root dialout 196, 253 Sep 15 21:52 timer

Il comando dahdi_hardware conferma che l'hardware è stato riconosciuto: 

# dahdi_hardware 
pci:0000:03:04.0     wanpipe-     1923:0040 Sangoma Technologies Corp. A200/Remora FXO/FXS Analog AFT card

Compilazione di Wanpipe

Wanpipe è la suite software necessaria ad usare la scheda Sangoma A200. Wanpipe ingloba in un unico code base il supporto per quasi tutto l'hardware Sangoma, includendo programmi di configurazione, supporto e debug, moduli kernel per Linux e driver per Windows. Insomma un blob mostruoso e per giunta non libero, che fa a pugni con qualunque principio di efficienza e qualità del software. Per questo motivo sconsiglio vivamente l'acquisto di schede Sangoma!

L'installazione avviene dai sorgenti: wanpipe-3.5.28.tgz. Qui sono indicati i requisiti per l'installazione e qui la procedura General Installation. Anche questo riferimento potrebbe essere utile: Automate installation of dahdi, libpri, sangoma, and all deps on debian.

Per compilare Wanpipe servono alcuni pacchetti di sviluppo: 

apt-get install gcc g++ automake autoconf libtool make libncurses5-dev flex bison \
    patch linux-headers-$(uname -r) sqlite3 libsqlite3-dev

Inoltre bisogna installare la libreria Primary Rate ISDN, anche se non useremo mai una linea ISDN:

La compilazione non va a buon fine su Debian Wheezy, d'altra parte non c'era da aspettarsi altro, vista l'architettura del software! Wanpipe non gradisce che DAHDI sia stato compilato e installato alla Debian way (con module-assistant, ecc.).

Preparare la directory con i sorgenti: 

cd /usr/local/src/
tar zxvf wanpipe-3.5.28.tgz

Gli impazienti possono andare direttamente al paragrafo Soluzione con pacchetto Debian.

Chi volesse ripetere il percorso pieno di ostacoli esegua invece: 

cd /usr/local/src/wanpipe-3.5.28
./Setup dahdi

Problema #1: privilegi di root e inquinamento del filesystem

Il comando Setup accetta anche un'opzione del tipo --builddir=/tmp/wanpipe_build, ma comunque ha bisogno dei privilegi di root perché installa file in diverse directory di sistema. Tentando l'esecuzione come utente non privilegiato si finisce con un bel Segmentation fault!

Un software con queste caratteristiche non soddisfa i criteri minimi neanche della decenza: il classico make e make install è il minimo che si dovrebbe pretendere al giorno d'oggi!

Queste le directory infestate dal Setup:

Per rimuovere tutta questa babele, almeno in teoria, dovrebbe bastare ./Setup remove.

Problema #2: percorso dei sorgenti DAHDI

Durante il setup non vengono trovati i sorgenti di zaptel, in realtà noi abbiamo il più moderno dahdi che lo sostituisce, ma Wanpipe continua ad utilizzare l'obsoleto nome zaptel. Scegliendo l'opzione m è possibile indicarne il percorso: 

Please enter zaptel dir: [Default: /usr/src/zaptel]
#> /usr/local/src/dahdi-2.6.1+dfsg-1/usr_src/modules/dahdi

Problema #3: versione DAHDI e versione kernel

Anche con i privilegi di root la compilazione fallisce: 

make[4]: *** [/usr/local/src/wanpipe-3.5.28/kdrvtmp/sdla_tdmv.o] Error 1
make[3]: *** [_module_/usr/local/src/wanpipe-3.5.28/kdrvtmp] Error 2
make[2]: *** [sub-make] Error 2
make[1]: *** [all] Error 2

Wanpipe dovrebbe supportare DAHDI 2.6 e il kernel 3.2.6 a partire dalla versione 3.5.25 (vedere il changelog), ma nel nostro caso non riesce l'autodetect della versione di DAHDI né quella del kernel (si conferma un software scritto con i piedi!).

Per far riconoscere la versione kernel la strada più rapida è modificare lo script Setup, circa alla riga 935, dentro la funzione get_kernel_ver(), prima della definizione di KERNEL_VERSION. Poiché nel nostro caso uname -r restituisce 3.2.0-3-amd64, mettiamo: 

    KVER=3
    KPATCH=2
    KLVL=0
    KEVER="-3-amd64"
    KERNEL_VERSION=$KVER"."$KPATCH"."$KLVL$KEVER

L'autodetect della versione DAHDI si basa sulla presenza di un file usr_src/modules/dahdi/include/dahdi/version.h autogenerato durante la compilazione, ma che la procedura guidata da module-assistant ha rimosso. Come contenuto basterebbe questo: 

#define DAHDI_VERSION "2.6.1"

ma non basta, mancano altri file che portano al problema seguente.

Problema #4: no symbol version

Il modulo kernel wanpipe compila con errori e quando si tenta di caricarlo con modprobe fallisce: 

[  551.916941] wanpipe: no symbol version for dahdi_hdlc_putbuf
[  551.916947] wanpipe: Unknown symbol dahdi_hdlc_putbuf (err -22)
[  551.916968] wanpipe: no symbol version for _dahdi_ec_span
[  551.916972] wanpipe: Unknown symbol _dahdi_ec_span (err -22)
[  551.916998] wanpipe: no symbol version for dahdi_alarm_notify
[  551.917001] wanpipe: Unknown symbol dahdi_alarm_notify (err -22)
[  551.917015] wanpipe: no symbol version for dahdi_hdlc_getbuf
[  551.917019] wanpipe: Unknown symbol dahdi_hdlc_getbuf (err -22)
...

Gli errori di compilazione sono loggati in /usr/local/src/wanpipe-3.5.28/setup_drv_compile.log: 

WARNING: "dahdi_hdlc_putbuf" [/usr/local/src/wanpipe-3.5.28/kdrvtmp/wanpipe.ko] undefined!
...

Anche in questo caso è la procedura guidata di module-assistant che ha rimosso il file Module.symvers generato durante la compilazione. Vedere la soluzione al paragrafo seguente.

Soluzione non Debian

La soluzione rapida ai problemi #3 e #4 è eseguire: 

cd /usr/local/src/dahdi-2.6.1+dfsg-1/usr_src/modules/dahdi/
make

va bene l'utente non privilegiato, come quando si è eseguita la procedura di compilazione con module-assistant. Al termine non rimuovere i file autogenerati: include/dahdi/version.h e drivers/dahdi/Module.symvers.

Modificare lo script Setup come indicato al problema #3.

Fatto questo il ./Setup dahdi funziona e il modulo kernel wanpipe risultante si carica con successo: 

[ 8383.502960] WANPIPE(tm) Multi-Protocol WAN Driver Module 3.5.28.0 (c) 1994-2010 Sangoma Technologies Inc
[ 8383.502966] wanpipe: Probing for WANPIPE hardware.
[ 8383.503015] pci 0000:03:04.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 8383.515036] wanpipe: AFT-A200-SH PCIe FXO/FXS card found (HDLC rev.13), cpu(s) 1, bus #3, slot #4, irq #15
[ 8383.515053] wanpipe: Allocating maximum 1 devices: wanpipe1 - wanpipe1.
[ 8383.515644] WANPIPE: TDM Codecs Initialized

Soluzione con pacchetto Debian

Il comando Setup di Wanpipe supporta lo switch builddeb che, senza usare i privilegi di root, compila tutti i moduli kernel e gli eseguibili, installandoli in una directory chroot e infine compilando un pacchetto .deb.

Ma non vi eccitate: la soluzione fa comunque schifo! La compilazione funziona da utente non privilegiato, ma i file risultanti messi nel pacchetto deb appartengono a tale utente (non viene usato fakeroot), quindi bisogna compilare come root. Sangoma: dilettanti allo sbaraglio! 

cd /usr/local/src/
tar zcvf wanpipe_etc.tgz /etc/wanpipe/
tar zxvf wanpipe-3.5.28.tgz
cd wanpipe-3.5.28
vi Setup
./Setup builddeb --with-zaptel=/usr/local/src/dahdi-2.6.1+dfsg2-1/usr_src/modules/dahdi  --protocol=TDM
dpkg --force-overwrite -i wanpipe_3528-k320-4-amd64_x86_64.deb
  1. Il protocollo TDM è sufficiente per la scheda A200 con modulo FXO.
  2. Il --force-overwrite è necessario per sovrascrivere il file wanrouter.ko fornito anche dal pacchetto linux-image-3.2.0-3-amd64: una porcheria dopo l'altra! FIXME Forse con il kernel 3.2.0-4-amd64 non esiste più il problema.
  3. Il file /etc/init.d/wanrouter installato dal pacchetto genera dei warning perché non contiene le necessarie voci LSB: di bene in meglio!
  4. Il postinst potrebbe fallire perché non riesce a caricare e scaricare il modulo wanrouter, in tal caso editare /var/lib/dpkg/info/wanpipe.postinst, cercare le righe con modprobe e mettere eval "modprobe wanrouter" || true; eseguire nuovamente il dpkg --configure wanpipe: la galleria degli orrori!

Aggiornamento del kernel

Nel caso in cui venga aggiornato il kernel è necessario ripetere i seguenti passaggi:

  1. Compilazione dei dahdi-modules con module-assistant e installazione del risultante pacchetto .deb.
  2. Esecuzione di make nella directory /usr/local/src/dahdi-<ver>/usr_src/modules/dahdi/.
  3. Compilazione di wanpipe con l'opzione builddeb e installazione del pacchetto .deb risultante.
  4. Ripristino della configurazione /etc/wanpipe/wanrouter.rc e /etc/init.d/wanrouter (in realtà un link a /usr/sbin/wanrouter).

Configurazione e caricamento stack software

Questo è l'ordine con cui deve essere caricato il software:

  1. /etc/init.d/dahdi start Carica il modulo kernel dahdi.
  2. /etc/init.d/wanrouter start In realtà è una copia del comando /usr/sbin/wanrouter. Carica il modulo kernel wanpipe.
  3. /usr/sbin/dahdi_cfg FIXME Viene eseguito all'avvio di dahdi, ma deve essere eseguito nuovamente dopo che è stato avviato wanrouter altrimenti Asterisk non trova i canali DAHDI.
  4. /etc/init.d/asterisk start Avvia il centralino VoIP Asterisk.

La configurazione può essere fatta in modo guidato con il tool setup-sangoma che fa l'autodetect dell'hardware ed esegue i sottoprogrammi necessari. Nel nostro caso è equivalente ad eseguire wancfg_dahdi. Fare attenzione che questa procedura (è software Sangoma: siete avvertiti!) vuole riscrivere tutti i file di configurazione Dahdi, Wanpipe e Asterisk, quindi ogni personalizzazione viene persa.

Esiste anche il tool dahdi_cfg (software Debian) che genera la configurazione per dahdi e quindi si sovrappone parzialmente per funzionalità ai tool setup-sangoma e wancfg_dahdi.

Dopo aver configurato e caricato dahdi e wanpipe si può vedere se i canali vengono riconosciuti e se è presente la linea telefonica sul primo canale: 

wanpipemon -i w1g1 -c astats -m 1
        ------- Voltage Status  (FXO,port 0) -------
VOLTAGE : 49 Volts
        ------- Line Status  (FXO,port 0) -------
Line    : connected

Configurazione di DAHDI

NOTA 1 Debian include il modulo kernel per la cancellazione echo OSLEC, oltre al predefinito MG2. Di conseguenza i vari tool sono stati patchati per utilizzarlo.

NOTA 2 La documentazione spesso fa riferimento al modulo ztdummy o al più moderno dahdi_dummy. Debian ha applicato una patch accettata upstream per cui il modulo non è più necessario e viene usato il timing interno.

NOTA 3 Una porta FXO viene collegata alla linea telefonica, su di essa la scheda telefonica deve attivare la segnalazione FXS.

/etc/dahdi/system.conf

File di configurazione letto dal tool dahdi_cfg per configurare a run-time il modulo kernel dahdi.

Il file può essere scritto a mano oppure generato (sovrascritto) dall'esecuzione di setup-sangoma oppure dall'esecuzione di wancfg_dahdi (entrambi installati con il software Wanpipe di Sangoma) oppure dall'esecuzione di dahdi_genconf (installato con il pacchetto Debian dahdi).

Il tool setup-sangoma fa l'autodetect dell'hardware installato e fa alcune domande per determinare la configurazione finale.

Il tool dahdi_genconf fa l'autodetect dell'hardware (solo se il modulo kernel wanpipe è caricato correttamente) e legge alcune impostazioni da /etc/dahdi/genconf_parameters. Ad esempio con questo genconf_parameters: 

# Set tone zone values. This is used for playing tones (busy, dial-tone and such).
# The default is us. This sets the value for both loadzone and defaultzone in system.conf.
lc_country              it

# For FXO (analog lines) - use KS or LS? KS is the default and is normally the
# better choice as it allows detecting hang-ups on many lines.
fxo_default_start       ks

# The dialplan context into which to send trunks in chan_dahdi.conf or users.conf.
context_lines           from-pstn

# The echo canceler to use. If you have a hardware echo canceler, just leave it be,
# as this one won’t be used anyway. Debian dahdi-linux provides the OSLEC kernel module.
echo_can                oslec

produce il seguente /etc/dahdi/system.conf: 

# Span 1: WRTDM/0 "wrtdm Board 1" (MASTER) 
fxsks=1
echocanceller=oslec,1
fxsks=2
echocanceller=oslec,2

# Global data
loadzone        = it
defaultzone     = it

La zona indica quali convensioni nazionali usare per le segnalazione sulla linea (segnale di libero, occupato, squillo, ecc.), se un canale non indica una zona particolare verrà usata quella di default.

La parola chiave fxsks indica che sul quel canale viene attivata la segnalazione FXS (quindi è una porta FXO da collegare a una linea telefonica) e che si userà il meccanismo Kewlstart per richiedere il segnale di libero. La nostra scheda Sangoma ha due porte FXO, ma useremo solo la prima.

Con un file di configurazione corretto e dopo aver caricato correttamente anche Wanpipe (vedi paragrafo successivo) è possibile eseguire dahdi_cfg e verificare con dmesg che i canali DAHDI siano stati configurati: 

[160213.897210] wanpipe1: Open (usecount=1, channo=1, chanpos=1)...
[160213.897226] wanpipe1: Open (usecount=1, channo=2, chanpos=2)...

Se non si esegue dahdi_cfg i canali DAHDI non sono disponibili, Asterisk ad esempio non carica neanche il modulo chan_dahdi: 

ERROR[4384] chan_dahdi.c: Unable to open channel 1: No such device or address here = 0, tmp->channel = 1, channel = 1
ERROR[4384] chan_dahdi.c: Unable to register channel '1'

/etc/dahdi/modules

Elnco dei moduli kernel da caricare al boot. Non serve nel nostro caso.

/etc/dahdi/init.conf

Modifica il comportamento di default di /etc/init.d/dahdi. Non serve nel nostro caso.

Configurazione di Wanpipe

Se tutto è stato configurato correttamente, eseguendo /etc/init.d/wanrouter start il kernel logga: 

WANPIPE(tm) Interface Support Module 3.5.28.0 (c) 1994-2010 Sangoma Technologies Inc
WANPIPE(tm) Multi-Protocol WAN Driver Module 3.5.28.0 (c) 1994-2010 Sangoma Technologies Inc
wanpipe: Probing for WANPIPE hardware.
wanpipe: AFT-A200-SH PCIe FXO/FXS card found (HDLC rev.13), cpu(s) 1, bus #3, slot #4, irq #16
...
wanpipe1: Starting WAN Setup

Processing WAN device wanpipe1...
wanpipe1: Locating: A200/A400/B600/B700/B800/B610 card, CPU A, PciBus=3, PciSlot=4
wanpipe1: Found: A200/A400/B600/B700/B800/B610 card, CPU A, PciBus=3, PciSlot=4, Port=0
wanpipe1: AFT PCI memory at 0xDF9F0000
...
wanpipe1: Configuring FXS/FXO Front End ...
wanpipe1: Module 1: Installed -- Auto FXO (FCC mode)!
wanpipe1: Module 2: Installed -- Auto FXO (FCC mode)!
...
wanpipe1: Configuring Device   :wanpipe1  FrmVr=13
wanpipe1:    Global MTU     = 1500
wanpipe1:    Global MRU     = 1500
...
wanpipe1: Configuring Interface: w1g1
wanpipe1:w1g1: Running in TDM Voice Zaptel Mode.
wanpipe1: Registering TDMV FXO iface to module 1!
...
wanpipe1: Configuring Interface: w1g1 (log supress)
wanpipe1: Configuring TDMV Master dev w1g1
wanpipe1: Registering TDMV FXO iface to module 2!
...
wanpipe1: ALAW override parameter detected. Device will be operating in ALAW
wanpipe1: Wanpipe device is registered to Zaptel span # 1!
wanpipe1: AFT communications enabled!
wanpipe1: AFT Per Port TDM Intr (swring)
wanpipe1: Module 1: FXO Line is connected!

/etc/wanpipe/wanpipe1.conf

Definisce i device e le interfacce disponibili con il software Wanpipe. Nel nostro caso il device è la scheda A200 e le interfacce sono le due porte FXO installate.

Può essere scritto a mano oppure generato automaticamente dallo script setup-sangoma o dallo script wancfg_dahdi. Nel nostro caso abbiamo accettato tutte le impostazioni predefinite scegliendo il codec ALAW (Europe). Questo il risultato: 

[devices]
wanpipe1 = WAN_AFT_ANALOG, Comment

[interfaces]
w1g1 = wanpipe1, , TDM_VOICE, Comment

[wanpipe1]
CARD_TYPE       = AFT
S514CPU         = A
CommPort        = PRI
AUTO_PCISLOT    = NO
PCISLOT         = 4
PCIBUS          = 3
FE_MEDIA        = FXO/FXS
TDMV_LAW        = ALAW
TDMV_OPERMODE   = FCC
RM_BATTTHRESH   = 3
RM_BATTDEBOUNCE = 16
FE_NETWORK_SYNC = NO
MTU             = 1500
UDPPORT         = 9000
TTL             = 255
IGNORE_FRONT_END = NO
TDMV_SPAN       = 1
TE_AIS_MAINTENANCE = NO

TDMV_HW_DTMF            = NO
TDMV_HW_FAX_DETECT      = NO
HWEC_OPERATION_MODE     = OCT_NORMAL
HWEC_DTMF_REMOVAL       = NO
HWEC_NOISE_REDUCTION    = NO
HWEC_ACUSTIC_ECHO       = NO
HWEC_NLP_DISABLE        = NO
HWEC_TX_AUTO_GAIN       = 0
HWEC_RX_AUTO_GAIN       = 0
HWEC_TX_GAIN            = 0
HWEC_RX_GAIN            = 0

[w1g1]
ACTIVE_CH       = ALL
MTU             = 8
TDMV_HWEC       = NO

/etc/wanpipe/wanrouter.rc

File di configurazione utilizzato dagli script Wanpipe che indica le directory da utilizzare, alcuni parametri di funzionamento, ecc.

Viene generato (sovrascritto) all'esecuzione di wancfg_dahdi.

/etc/init.d/wanrouter

Script che esegue lo start/stop del tool wanrouter, scopo principale dello script è caricare il modulo kernel wanpipe e le sue dipendenze.

Lo script viene abilitato ai vari runlevel quando si esegue la procedura di setup setup-sangoma o wancfg_dahdi.

Anche questo script di Sangoma fa schifo: non contiene i tag LSB (Linux Standard Base) per organizzare la sequenza di bootstrap e insserv giustamente si lamenta: 

insserv: warning: script 'K01wanrouter' missing LSB tags and overrides
insserv: warning: script 'wanrouter' missing LSB tags and overrides

Questi i tag LSB che abbiamo aggiunto dentro allo script: 

### BEGIN INIT INFO
# Provides:          wanrouter
# Required-Start:    dahdi
# Required-Stop:     dahdi
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: WANPIPE WAN Router Initialization Script
# Description:       This file should be used to construct scripts to be
#                    placed in /etc/init.d.
### END INIT INFO

/etc/wanpipe/scripts/start

Come spiegato nella FAQ Auto-start Zaptel after Wanpipe, è indispensabile eseguire dhadi_cfg dopo aver avviato wanrouter. Lo script /etc/wanpipe/scripts/start qui è stato adattato a DAHDI e ad una shell diversa da Bash: 

#!/bin/sh
 
# Make sure that udev/devfs DAHDI device has come up.
cnt=1
max_delay=10
while [ "$cnt" -le "$max_delay" ]; do
    if [ -e /dev/dahdi/ctl ]; then
            break;
    fi
    echo "Waiting for DAHDI device /dev/dahdi/ctl ($cnt/$max_delay)..."
    sleep 1
    cnt=$(($cnt + 1))
done
 
if [ ! -e /dev/dahdi/ctl ]; then
    echo
    echo "Error: DAHDI device failed to come up";
    echo "Possible Cause: UDEV not installed!";
    echo
    exit 1
fi
 
sleep 1
dahdi_cfg -vvvv
 
exit 0

Configurazione di Asterisk

Installare i pacchetti Debian:

asterisk-dahdi serve ad interfacciare Asterisk con i canali DAHDI, asterisk-prompt-it-menardi-gsm contiene i messaggi del centralino in italiano. Quando tutto è configurato correttamente ed Asterisk si è avviato, è possibile connettersi alla console e verificare i canali DAHDI: 

asterisk -vr
Asterisk 1.8.13.1~dfsg-1, Copyright (C) 1999 - 2012 Digium, Inc. and others.
...
=========================================================================
Connected to Asterisk 1.8.13.1~dfsg-1 currently running on naxos (pid = 11482)
*CLI> dahdi show channels 
   Chan Extension  Context         Language   MOH Interpret        Blocked    State     
 pseudo            default                    default                         In Service
      1            from-pstn                  default                         In Service
      2            from-pstn                  default                         In Service
*CLI>

Invece eventuali messaggi di errore vengono loggati in /var/log/asterisk/messages.

Terminologia

Canale Percorso attraverso il quale instradare delle chiamate, può essere ad esempio FXO (linea telefonica), FXS (apparecchio telefonico), SIP (voce su IP, standard usato da molti device), IAX (voce su IP, standard proposto da Asterisk).
Estensione
Contesto

Principali file di configurazione

/etc/asterisk/chan_dahdi.conf

Il file può essere scritto a mano oppure generato (sovrascritto) dall'esecuzione di setup-sangoma oppure dall'esecuzione di wancfg_dahdi (entrambi installati con il software Wanpipe di Sangoma). Contiene la configurazione globale DAHDI e dei canali.

Questa è la parte relativa ai due canali FXO della scheda A200: 

;Sangoma AFT-A200 [slot:4 bus:3 span:1]  <wanpipe1>
; Span 1: WRTDM/0 "wrtdm Board 1" (MASTER) 
;;; line="1 WRTDM/0/0"
context=from-pstn
group=0
echocancel=yes
signalling=fxs_ks
callerid=asreceived
channel => 1
;;; line="2 WRTDM/0/1"
context=from-pstn
group=0
echocancel=yes
signalling=fxs_ks
callerid=asreceived
channel => 2

/etc/asterisk/dahdi-channels.conf

Il file può essere scritto a mano oppure generato (sovrascritto) dall'esecuzione di setup-sangoma oppure dall'esecuzione di wancfg_dahdi (entrambi installati con il software Wanpipe di Sangoma) oppure dall'esecuzione di dahdi_genconf chandahdi (installato con il pacchetto Debian dahdi). Questo file dovrebbe contenere solo la configurazione dei canali DAHDI e dovrebbe essere incluso (con una direttiva #include) dal file di configurazione vero e proprio chan_dahdi.conf.

/etc/asterisk/modules.conf

In questo file si può disabilitare il caricamento di moduli Asterisk che non servono. Abbiamo disabilitato il modulo LDAP Realtime Driver e altri: 

; No LDAP database for RealTime Configuration.
noload => res_config_ldap.so
; No DAHDI transcoding cards installed.
noload => codec_dahdi.so
; No Voicetronix cards installed.
noload => chan_vpb.so
; No FreeTDS library to log to Microsoft SQL Server.
noload => cel_tds.so
; No AIS (Application Interface Specification) for clustering.
noload => res_ais.so
; We don't want Asterisk Extension Language and dialplan in extensions.ael
noload => pbx_ael.so
; We don't want dialplan written in Lua (extensions.lua).
noload => pbx_lua.so
; We don't store Call Detail Records into PostgreSQL.
noload => cdr_pgsql.so

Iil caricamento di moduli non necessari causava messaggi di errore o di warning e un asterisk general protection che impediva ad Asterisk di partire (anche Asterisk lascia a desiderare: una configurazione sbagliata che genera un general protection è sintomo di software scritto male!): 

ERROR[22971] res_config_ldap.c: No directory URL or host found.
ERROR[22971] res_config_ldap.c: Cannot load LDAP RealTime driver.
NOTICE[11891] cel_tds.c: cel_tds has no global category, nothing to configure.
WARNING[11891] cel_tds.c: cel_tds module had config problems; declining load
ERROR[11891] codec_dahdi.c: Failed to open /dev/dahdi/transcode: No such file or directory
ERROR[11891] chan_vpb.cc: No Voicetronix cards detected
ERROR[11891] ais/clm.c: Could not initialize cluster membership service: Try Again
asterisk[11418] general protection ip:7f637a77fee2 sp:7fffc2e658d0 error:0 in libc-2.13.so[7f637a748000+17d000]

/etc/asterisk/asterisk.conf

Per avere le voci del centralino in italiano: 

defaultlanguage = it

/etc/asterisk/extensions.conf

Contiene il dialplan del centralino Asterisk.

Client SIP

Per consentire la registrazione a un client SIP (softphone tipo CSipSimple per Android oppure un telefono IP) si aggiunge al file di configurazione /etc/asterisk/sip.conf una sezione del tipo: 

;---------------------------------------------------------------
; SIP channel: mobile softphone
; It receives and places calls: it is a friend.
;---------------------------------------------------------------
[niccolo]
callerid=Niccolo <100>
type=friend
context=sip-phones
host=dynamic
secret=MySipSecret

Il client SIP va inserito come estensione in un opportuno contesto, ad esempio in /etc/asterisk/extensions.conf si definisce il contesto sip-phones con l'estensione (interno) 100: 

[sip-phones]
exten => 100,1,Verbose(1,Dialling extension 100: Niccolo SIP phone)
exten => 100,n,Dial(SIP/niccolo,45)
exten => 100,n,Hangup()

Wind: operatore bastardo che filtra le porte

Asterisk sta in ascolto sulla porta 5060 UDP e TCP, eventualmente anche sulla porta 5061 per il TLS. Acluni operatori di connettività (3G oppure ADSL) potrebbero filtrare tale traffico, in uscita o in ingresso. Ad esempio con una connessione 3G Wind verso una ADSL Wind Infostrada, la porta 5060 risulta totalmente filtrata!

Ovviamente è possibile mettere Asterisk in ascolto su altra porta (riconfigurando Asterisk oppure con regole iptables è possibile ridirigere una o più porte alternative sulla 5060), ma ancora non ho potuto verificare che la soluzione sia affidabile. Oltre al traffico SIP infatti c'è da verificare che anche il traffico voce (RTP) passi correttamente, con tutti i problemi connessi al NAT, ecc.

Problemi NAT e firewall

Debug

Con una configurazione di DAHDI sbagliata Asterisk può non partire proprio. Ecco cosa succede lanciando il programma in modo interattivo: 

# asterisk -cvvvvv
...
  == Registered application 'DAHDIBarge'
 app_dahdibarge.so => (Barge in on DAHDI channel application)
Segmentation fault

Se invece il programma si avvia, è possibile uscire dalla linea di comando con: 

*CLI> core stop now

TODO

FIXME Verificare se c'è da aggiornare il firmware.