In questo articolo andremo a definire le procedure di installazione e configurazione iniziale per il PBX al fine di impiegare questo apparato come centralino VoIP collegando ad esso un Account Messagenet (da usare come Trunk) ed un estensione interna, nel nostro caso un ulteriore client SIP a sua volta connesso al centralino.
A seconda di scelte tra loro equivalenti, il medesimo setup potrà essere reso possibile da configurazioni tra loro equivalenti: noi in questo caso propenderemo per scelte specifiche focalizzandoci su:
- configurazione in rete LAN senza port forwarding statico verso la rete pubblica;
- utilizzo di chan_sip (in opposizione all'altra scelta possibile, ovvero chan_pjsip, di base equivalente);
Ci sono poi molti setup possibili relativamente alla gestione ed alle applicazioni del nostro PBX, a seconda dello scopo e delle funzionalità che vogliamo ottenere: su questo aspetto, demandiamo all'installatore ed all'amministratore dell'apparato ogni possibile sviluppo o personalizzazione.
Installazione e Configurazione Preliminare
FreePBX viene distribuito da Sangoma tramite sistema installabile a partire da un'immagine iso gratuitamente fornita dal loro sito web:
https://www.freepbx.org/downloads/
E' un sistema operativo autonomo basato su derivazione di RedHat Linux, con PBX Asterisk modificato e personalizzato, script di configurazione ed interfaccia web di management, accesso e configurazione: installeremo tale software su di un host fisico o virtuale a nostra discrezione.
Sorvolando sulle fasi dettagliate dell'installazione, consigliamo caldamente di:
- impiegare password sicure per i diritti l'amministratore di sistema, concedendo tali privilegi ad un solo account utente;
- assegnare al nostro server un indirizzo IP di rete locale assegnato via DHCP (mantenendo sempre il medesimo, se possibile), e non dare indicazione alcuna sul routing: in questo modo, demanderemo al nostro router la configurazione di quanto concerne le caratteristiche della topolgia di rete, senza interventi ulteriori;
Attenzione: come vedremo più avanti nelle configurazioni, faremo in modo che il nostro PBX creda di avere assegnato direttamente un'indirizzo IP Pubblico, ovvero di non essere sotto NAT, sebbene noi si sia configurato con un firewall molto blando assegnando all'interfaccia di rete un'indirizzo di rete LAN privato (nel nostro caso, 192.168.130.243, ma è solo un esempio).Questo può sembrare controintuitivo, ma è atto a fare in modo che il nostro PBX non cerchi di effettuare in autonomia scelte di NAT Traversal che possano pregiudicarne il funzionamento, facendo inoltre sì che Messagenet riconosca il PBX come apparato di rete locale e si comporti conseguentemente, gestendo in modo ottimale la segnalazione ed il media.
Coerentemente con la scelta precedente:
- nessuna interfaccia di configurazione sarà disponibile dall'esterno della nostra rete locale: consigliamo di impiegare alternative sicure (VPN) per la configurazione di tali apparati dall'esterno della nostra rete locale; nessun port forwarding sarà richiesto per il funzionamento del dispositivo e ci baseremo su altri e più sicuri accorgimenti per evitare problematiche VoIP connesse a NAT Traversal:
- utilizzo del livello di trasporto TCP;
- ri-Registrazione frequente del Trunk Messagenet;
- utilizzo di KeepAlive al fine di mantenere attiva la sessione NAT verso il Proxy Messagenet;
- assegneremo policy di bassa sicurezza per il Firewall del nostro PBX: la sicurezza di rete deve essere demandata ad altro apparato (router/firewall) mentre la nostra rete LAN, per forza di cose, deve essere considerata sicura (altrimenti il problema è a monte); N.B.: questo suggerimento minimizza l'effort configurativo richiesto ed i problemi che possono sorgere complicando le configurazioni del Firewall: nel caso si debba necessariamente procedere restringendo le policies per il nostro firewall sul server, consigliamo di evitare scelte autoconfigurative e conoscere in dettaglio l'effetto delle nostre modifiche, al fine di evitare malfunzionamenti;
Configurazione del Setup Minimale
Come indicato, il nostro intento è quello di realizzare una configurazione minimale nella quale collegare un Account VoIP Messagenet come Trunk per il PBX: dovremo sostanzialmente abilitare un Trunk definendo un peer verso Messagenet che effettui registrazione al servizio presso il nostro proxy in TCP, e definire un'estensione (telefono IP, software od altro) che possa a sua volta ricevere ed effettuare chiamate con Messagenet, ma registrandosi ed invitando chiamate solo verso il PBX, senza dialogare direttamente con Messagenet: è la base minima per costiuire una rete di "interni" in una rete VoIP privata.
Di seguito indicheremo come realizzarla: ulteriori parametri dovranno essere modificati nel caso si vogliano definire configurazioni più complesse.
Per prima cosa andiamo a modificare le configurazioni generali del nostro PBX:
Advanced Settings
Consigliamo di verificare che effettivamente siano impostati i seguenti valori per la sezione Device Settings:
Nella sezione Dialplan and Operational, è inoltre possibile impostare la tonezeone del proprio paese, ad esempio quella italiana, per avere i toni telefonici relativi al paese voluto: tale modifica, però, non impatta le chiamate provenienti dalla rete telefonica Messagenet (rete fissa) poichè in questo caso i toni verranno rilasciati dai gateway di interconnessione alla centrale telefonica Messagenet.
SIP Settings (Chan SIP)
Consigliamo di verificare che effettivamente siano impostati i seguenti valori:
Attenzione:
- come precedentemente anticipato, il nostro PBX riterrà di essere pubblicamente esposto, sebbene non lo sia;
- in questa fase abbiamo indicato come interfaccia localmente in ascolto sul nostro PBX la porta 5060: questa porta sarà la porta localmente impiegata dal PBX per comunicare in SIP tramite il modulo chan_sip del PBX. Tale scelta, deve essere coerente con l'altro modulo predisposto per il SIP, ovvero chan_pjsip, il quale non potrà ascoltare sulla stessa porta, ma su di una differente: sarà necessario modificare questa impostazione in SIP Settings (Chan PJSIP) rendendo coerente la nostra scelta ed indicando una porta differente, che non useremo;
- si osservano alcune opzioni imposte manualmente in coda, atte ad abilitare il trasporto TCP per la segnalazione SIP ed a mantenere il nostro PBX sempre entro lo streaming audio: l'estensione interna gestirà il flusso audio RTP verso il centralino e poi dal centralino verso il proxy Messagenet, in due tratte separate, al fine di minimizzare issues di NAT Traversal;
SIP Settings (General SIP Settings)
Consigliamo di verificare che effettivamente siano impostati i seguenti valori:
Come precedentemente indicato, lasciamo il nostro PBX agnostico rispetto alla NAT ed alla rete locale: si registrerà abbastanza frequentemente da far si che non sia un problema.
Attenzione: i codec indicati sono quelli che Messagenet gestisce (accetta ed offre in chiamata) secondo l'ordine di preferenza condiviso: si consiglia fermamente di mantenere tale ordine, abilitando o disabilitando altri codec all'occorrenza. Sussiste però un problema: il codec preferito, ovvero g729 non è presente nell'installazione base, essendo tale codec sottoposto a licenza e quindi non gratuitamente fruibile per scopi commerciali; nel caso non sia per voi possibile implementare questo codec, rimuoverlo dalla lista disabilitandolo. N.B.: il codec alaw (g711 PCM alaw) è il medesimo codec impiegato nella fonia digiale ISDN, e conseguentemente offre le performances massime in relazione alla rete telefonica fissa/mobile.
Trunk - Inbound Route - Extension - Outbound Route
Queste quattro sezioni saranno da configurare al fine di poter ottenere effettivamente lo scopo voluto: consentire ad un apparato di essere registrato al centralino, chiamare con Messagenet tramite esso e ricevere da esso le chiamate per tale numero.
Partendo dalla prima sezione (Trunk) passeremo alle successive quando ci verrà richiesto, al fine di rendere coerente la configurazione (che necessita di alcuni elementi per poter procedere ai successivi). Al termine della configurazione avremo due peers e due users (intesi come da Asterisk): il nostro interno ed il nostro Account Messagenet.
Trunk
Outbound Route
Inbound Route
Extension
Chiamiamo la nostra estensione 123: la sua password e questo "username" saranno da indicare nel nostro device che fungerà da estensione interna, la quale si registrerà al nostro PBX con la password (differente da quella del Trunk Messagenet); essendo tutto nella nostra rete LAN, scegliamo UDP (default) come trasporto per la segnalazione ed evitiamo di impiegare KeepAlive per mantenere attive sessioni di NAT, poichè non ve ne saranno:
Note
- nell'esempio sopra stiamo indicando delle regole di dialplan che consentono di chiamare solo numerazioni di rete fissa / mobile nazionale: modificare a piacimento tali regole per poter gestire o consentire gli instradamenti tramite le le rotte outbound;
- usiamo il livello di trasporto TCP, anzichè standard UDP, poichè se un pacchetto supera l'MTU consentito sulla rete per il datagram (normalmente 1504), tale datagram verrebbe frammentato e non correttamente ricomposto alla destinazione, rendendo irresponsivo il destinatario che non riuscirebbe a ricostruire il messaggio ricevuto: TCP, riassemblando il pacchetto alla destinazione, evita questo problema e consente la ricezione di pacchetti SIP anche di dimensioni maggiori, tipicamente usati se gli apparati appongono header corposi alla segnalazione;
DID, CID e CLI: il Numero Geografico in relazione all'Account VoIP
Osservando sopra, si nota che il numero geografico non viene mai specificato nelle configurazioni: questo è corretto, dal momento che nel VoIP l'unico riferimento valido sarà lo Username dell'Account VoIP assegnato: il numero geografico è un riferimento che Messagenet imporra alla chiamata una volta immessa sulla rete telefonica fissa, ma non ha attinenza diretta con il VoIP e pertanto possiamo non specificarlo per comodità.
Nelle condizioni descritte, ovvero semplici, la visualizzazione o meno del numero chiamante può pertanto essere gestita sul nostro sito web, abilitando o disabilitando la visualizzazione del proprio numero alla destinazione.
Il problema naturalmente nasce nel momento in cui abbiamo un trunk al quale sono associate più numerazioni geografiche, come descritto in: Un solo Account VoIP con più numeri geografici
Rimandando in dettaglio all'articolo indicato, per quanto riguarda l'implementazione del servizio forniamo qui la "versione FreePBX" della configurazione necessaria.
Riconoscimento del numero geografico chiamato
Il fulcro della logica da applicare, anche per altre finalità con questo PBX, si basa sulle Inbound Routes: questo è fondamentalmente il nostro dialplan semplice sul quale imporremo regole basandoci principalmente sui concetti di DID (Direct Inward Dial, ovver "dove sto andando": il numero che è stato chiamato) e CID (CallerID, ovvero "chi sono": il numero che ci ha chiamato): decideremo in base a questi parametri, principalmente, cosa fare delle telefonate
Nella definizione del nostro trunk sopra, non abbiamo definito alcuna regexten per la nostra Register String, come invece viene mostrato qui:
tcp://5xxxxxx:password@sip.messagenet.it/5xxxxxx
In questo modo, ad esempio, le chiamate in arrivo avranno come DID il nostro username SIP; in caso contrario il DID sarebbe stato s, ovvero il default.
N.B.: la regexten viene usata dal nostro PBX quale userpart dell'header Contact del nostro tunk
In ogni caso però questo nostro riferimento viene imposto in modo statico, mentre a noi piacerebbe riconoscere chi effettivamente ha chiamato il trunk: per farlo, abbiamo due possibilità, le quali sono tra loro in alternativa:
Context from-pstn-toheader per il peer del trunk Messagenet
FreePBX mette nativamente a nostra disposizione proprio quello che ci serve:
https://wiki.freepbx.org/display/FPG/Trunk+Sample+Configurations
context=from-trunk
"from-trunk" means that incoming calls from this trunk will be treated as if they are coming from an outside line, and will be routed using the rules that you setup in the Inbound Routes Module. If there is no matching Inbound Route, Asterisk will deliver a "not in service message." "from-pstn-e164-us" is the same as "from-trunk," except that any leading + in the Caller ID will be removed. "from-pstn-toheader" is the same as "from-trunk," but that the called number (the DID) will be derived from the to: header instead of the From-DID header. "from-internal" means that incoming calls from this trunk will be treated as if they were made by an internal phone, and will be routed directly to an extension number, a feature code, or through the outbound routes module.
Anche se pare controintuitivo, andremo a modificare il context per il peer, nella sezione Outgoing del tab SIP Settings; fatto questo, opportune Inbound Routes consentiranno di gestire in maniera differente le chiamate in base al DID chiamato, sul medesimo Utente VoIP:
Replicazione manuale della logica per Asterisk, tramite Custom Destination
Applicheremo sostanzialmente la medesima logica esemplificata nell'altro articolo per Asterisk, ma impiegando le funzionalità di Custom Destination del nostro FreePBX. Sostanzialmente, creeremo una regola di Inbound Routes di default, per andare a leggere il numero chiamante correttamente dalla segnalazione SIP e ripercorrere poi le Inbound Routes con il DID corretto.
Applichiamo il tutto nell'esempio di seguito per distinguere le chiamate per Pippo da quelle per Topolino, i quali hanno diversi numeri geografici italiani sul medesimo trunk:
N.B.: a parità di DID, tra due Inbound Routes viene presa quella definita prima, senza dar conto del CID: se vogliamo dare priorità ad una rotta piuttosto che ad un'altra, di default, dovremo valorizzare il parametro "CID Priority Route" con Yes
Selezione dinamica del CLI in chiamata
Utilizzeremo, in questo caso, la possibilità di indicare il numero geografico del singolo interno chiamante andando a valorizzare opportunamente il suo displayname (vedi articolo precedente: questa funzionalità va abilitata tramite richiesta Messagenet via supporto).
A tale scopo:
- imposteremo l'Outbound CID corretto per la nostra Extension chiamante;
- disabiliteremo l'Override Extension dell'Outbound Route verso il tunk;
Ricezione FAX in VoIP con Protocollo T38
Messagenet, consente di utilizzare Asterisk, e quindi anche FreePBX, per ricevere FAX in T38, ovvero l'estensione del SIP per questo tipo di funzionalità telefonica.
Possiamo pertanto configurare oppurtunamente il nostro PBX, tramite Inbound Routes che potremo imporre per far rispondere alla chiamata usando il modulo spandsp disponibile di default sul FreePBX.
Possiamo scegliere, se:
- utilizzare un determinato User piuttosto che un'altro, al quale attiveremo la funzionalità FAX;
- utilizzare la funzione FAX del centralino, ovvero senza distinguere in base agli utenti del PBX;
Nelle immagini di seguito mostriamo:
- come configurare opportunamente il modulo chan_sip (spandsp) ed il servizio FAX generico del PBX;
- come abilitare un User per ricevere FAX sulla propria Extension;
- come dirottare le chiamate in ingresso secondo le Inbound Routes e la nostra scelta;
tags: FreePBX Trunk Sip Trunking PBX Centralino Telefonico Installatori