Benchè noi in azienda ormai usiamo Asterisk da svariati anni per le nostre applicazioni, non ci eravamo ancora registrati come partner ufficiali, quindi l’altro giorno ho rimediato.
Ovviamente partiamo dalla base, ovvero l’affiliazione senza costi, che però offre comunque la possibilità di certificarsi.
Certo una certificazione di per se non è sinonimo di conoscenza assoluta, ma nel mi caso mi ha permesso di misurarmi sulla parte teorica di Asterisk, magari un pò arrugginita in qualche campo non continuamente usato (parlo del jitter, del SDP, della teoria sul DTMF)
Per farla breve ho conseguito la prima certificazione Digium, la dCCA!
Eccoci di ritorno!
Sono stato un pò assente, nel frattempo sono stato a MarsaAllam in Egitto ed eccomi di nuovo qua al lavoro, l’estate non è ancora finita, nuovi progetti partiranno ma adesso è tempo di afre un pò di bugfix.
Ho deciso di togliere un pò di fronzoli allo script safe_asterisk, in pratica
- Modificare la voce CONSOLE=yes in CONSOLE=no
- Togliere l’opzione -g, girare sempre in modalità di generazione coredump è peggiorativo per le prestazioni
- togliere -f dalla riga di esecuzione, in moda che Asterisk si in esecuzione in background (come demone)
io ho notato un sensibile miglioramente con questi semplici accorgimenti.
Ultimamente sto usando questo ATA in associazione al modulo res_fax della Digium, infatti in molte installazioni abbiamo collegato le analogiche di solito usate su macchien fax, per far ricevere ad Asterisk appunto i fax ed inviarli tramite mail.
Che che il 99% delle installazioni che abbiamo è ancora su Asterisk 1.4, ovviamente non c’è il supporto al T.38, quindi il fax è in-band (T.30) ed ovviamente i requisiti sono codec G.711 su LAN, il che non sarebbe comunque un problema, perchè usando il modulo res_fax in accoppiata a Patton e linea isdn, il problema dei fax falliti è pari allo zero.
Diverso il caso con le analogiche con gli HT-503, anche se il nuovo firmware risolve parecchi problemi.
Ma i parametri di tuning da provare sono molti:
- Caller ID Scheme : Bellcore/Telecordia oppure ETSI-FSK during ringing
- Caller ID Minimum RX Level: -30 o -40
- Jitter Buffer Type: Fixed
- Jitter Buffer Length: Low
- Caller ID Transport Type: Disable (tanto non funziona lo stesso, all’ultimo firmware)
- Gain : 0 sia TX che RX, da valutare
- Disable Line Echo Canceller (LEC): Yes
- Enable Current Disconnect: no
- Enable PSTN Disconnect Tone Detection: no
- AC Termination Mode : Inpedance Based (e sono 600 ohm)
- Number of Rings: 1
- PSTN Ring Thru FXS: ovviamente no
- Wait for Dial-Tone: di solito no
- Stage: 1
Con questi pochi (!) accorgimenti, non dovreste trovare problemi a ricevere fax! 
Ebbene si, certe volte mi capita di sentire colleghi che non reputano basilare aggiornare il firmware dei telefoni ip…..ma stiamo scherzando?
Noi usiamo principalmente Grandstream, perchè apparte gli snob considerino “cineseria” questi prodotti in confronto a Snom o Aastra, secondo me offrono un ottimo equilibri tra funzionalità e prezzo e devo dire che gli ultimi nati sono anche realizzati molto bene.
Apparte ciò è vero che un firmware nuovo può portare problemi, come il 1.1.6.16 con cui i telefoni davano occupato sempre.
Adesso ho “congelato” come release affidabile per i nostri sistemi la 1.2.3.5.
Un altra caso di successo dopo un aggiornamento di firmware l’ho avuto proprio oggi, un GXW-4004 (gateway fxs) non voleva saperne di far ricevere il fax all’apparecchio collegato, mentre dopo l’aggiornamento ha preso a funzionare regolarmente.
Nell’ultima versione delle centrali che sto producendo faccio ampio uso del provisioning per i telefoni Grandstream, non saranno ai livelli degli Snom, ma ci troviamo (e così i nostri clienti) molto bene.
Ovviamente loro preferiscono avere il menù in italiano, certo un pò maccheronico, ma meglio che nient per chi non conosce minimamente l’inglese.
Diversamente da come si trova scritto in giro, non è sufficiente mettere il file di testo Italian.txt nella root tftp, ma andrà rinominato anche il file gxp.lpf in gxp_Italian.lpf (rispettate le maiuscole/minuscole!!).
Alcuni telefoni si potrebbero aggiornare anche snza questa accortezza, ma nella mia castica è solo il 10%.
Altra cosa utile per il provisioning è settare la time zone, il corretto offset per l’Italia è 780, perchè ovviamente si parte dalle -12 (quindi 0) della linea del giorno, ad ovest.
Si lo so, è complicato quindi usate semplicemente 780!
Comincio con una regola generale, NON esponete il vostro Asterisk direttamente su internet a meno che non sia una questione di vita o di morte.
Non so quanti di voi conoscono sipvicious, una suite di programmi che permettono di far male, se usati da “malintenzionati”.
- svmap: uno scanner che identifica i device SIP in una rete
- svwar: scopre le estensioni in un SIP PBX
- svcrack: il password cracker (sia numeriche che alfanumeriche)
- svreport: reportistica
Non c’è male eh? tutto quel che serve.
Primo punto debole, la maggor parte di pbx, per comodità ha username=password per ogni estesione
Secondo punto debole, per usare trunk sip di svariati provider viente fatto port forwarding della 5060/udp e delle porte RTP
A questo punto con molta probabilità avremmo in /var/log/asterisk/full cosine di questo tipo
Feb 3 22:54:31 NOTICE[28514] chan_sip.c: Registration from ‘”0″‘ failed for ’86.72.2.248′ – Username/auth name mismatch
Feb 3 22:54:31 NOTICE[28514] chan_sip.c: Registration from ‘”1″‘ failed for ’86.72.2.248′ – Username/auth name mismatch
Feb 3 22:54:31 NOTICE[28514] chan_sip.c: Registration from ‘”2″‘ failed for ’86.72.2.248′ – Username/auth name mismatch
Feb 3 22:54:31 NOTICE[28514] chan_sip.c: Registration from ‘”3″‘ failed for ’86.72.2.248′ – Username/auth name mismatch
Feb 3 22:54:31 NOTICE[28514] chan_sip.c: Registration from ‘”4″‘ failed for ’86.72.2.248′ – Username/auth name mismatch
Feb 3 22:54:31 NOTICE[28514] chan_sip.c: Registration from ‘”5″‘ failed for ’86.72.2.248′ – Username/auth name mismatch
e poi
Feb 3 22:56:30 NOTICE[28514] chan_sip.c: Registration from ‘”1082″‘ failed for ’86.72.2.248′ – Wrong password
Feb 3 22:56:30 NOTICE[28514] chan_sip.c: Registration from ‘”1082″‘ failed for ’86.72.2.248′ – Wrong password
Feb 3 22:56:30 NOTICE[28514] chan_sip.c: Registration from ‘”1082″‘ failed for ’86.72.2.248′ – Wrong password
Feb 3 22:56:30 NOTICE[28514] chan_sip.c: Registration from ‘”1082″‘ failed for ’86.72.2.248′ – Wrong password
Feb 3 22:56:30 NOTICE[28514] chan_sip.c: Registration from ‘”1082″‘ failed for ’86.72.2.248′ – Wrong password
Feb 3 22:56:30 NOTICE[28514] chan_sip.c: Registration from ‘”1082″‘ failed for ’86.72.2.248′ – Wrong password
Complimenti! Siete vittime di sipvicious.
Li ci sono avvisi di password sbagliate, ma se non ci sono potrete notare che i vostri telefoni perdano la registrazione e poi la riacquistino…qualcuno ha usato l’accoppiata!
E nel cdr ci sarà la sorpresa!
Come difendersi? bhe per prima cosa, password complesse, si è vero sono scomode ma tanto va configurata una volta sola nel telefono, e nel caso usiate il provisioning nemmeno in quel caso.
Togliere l’esposizione da Internet è cosa buona e giusta, ma se avete SIP trunks voip da usare, lasciate l’ip pubblico e/o il portforwarding, ma limitate i vostri device all’uso in lan, ovvero usate permit/deny in sip.conf non in [general], ma per ogni singolo device.
Con queste brevi regole dovreste dormire sonni tranquilli…ed evitare bollette esagerate!
Ovviamente mi dissocio da qualsiasi uso nefasto e criminale di questa soluzione, riporto solo un uso curioso di Asterisk….
Una soluzione commerciale del genere, oltre a non poter essere comprata da tutti sta sui 1500 dollari..
Ebbene si, erano molti mesi che non mi occupavo di Trixbox (la 2.8.0.3) e soprattutto d’installarlo, ma per una piccola installazione ho deciso di riusarlo, precisamente in un Acer Veriton N260G.
Essenzialmente non sono cambiate tante cose, apparte l’adozione di Asterisk 1.6, sicuramente l’unica novità degna di nota in ambito “business” è la priorità nelle code, la possibilità di togliere il call waiting su un singolo device (utile per i call center) e modificare la durata del ringing sempre su singola estensione.
Nell’installazione la difficoltà è stata nel fatto che il kernel presente, il 2.6.18-128.el5 non riconosce la Marvell 80E8871, quindi mi sono installato un altro kernel, ovvero il 2.6.18-164.el5.
Fatto ciò ovviamente non funzionavano più i DAHDI drivers (kmod-dahdi), quindi l’ho dovuti reinstallare da questo repo, potete usare questa guida per usufruirne.
In definitiva comunque rimane una ottima soluzione per piccole installazioni, l’unica vera nota negativa è che non è presente nessuna utility di backup, cosa gravissima che ne limita i campi di utilizzo.
Sto seguendo un grosso progetto univeristario che mira alla realizzazione di una infrastruttura voip che inizalmente dovrà coprire 350 utenti, ma poi a regime saranno circa 4000.
E’ saltato subito fuori dai nostri incontri un’inaspettato fatto, Asterisk non è in grado di reggere l’urto di questa cosa, anche per la sua architettura ma proprio perchè sembra non pensato per essere così scalabile su queste cifre.
Inoltre abbiamo potuto vedere esperienze fatte dal GARR dove si fa largo uso di SER come sip proxy, di OpenSIPS per il load balancing e di Asterisk appunto per servizi avanzati, come IVR o voicemail, ma comunque non per chiamare.
Perchè questo? perchè SER è sicuramente più veloce, scalabile di Asterisk per lo standard SIP, e sicuramente si può fare molto meglio l’HA.
Noi ci stiamo indirizzando verso SipX in quanto è si un sip proxy scalabilissimo, ma anche flessibile come SER.
Inoltre supporta attivamente l’integrazione con LDAP/Active Directory, funge da voicemail server per Exchange 2007 e molto altro.
Inoltre è relativamente facile creare sistemo distribuiti per load balancing ed HA, e qui troverete tutte le sue varie features.
Aaaah quanto tempo che non mi capitava di fare un bel PBX, ma adesso basta Trixbox e tutti i suoi “accrocchi”.
Per un cliente ho “sfornato” un bel server IBM con una Sangoma 104DX (veramente facile adesso configurarle), Asterisk 1.4 pulito, DAHDI (addio maledetto Zaptel) e tutto basato su Ubuntu server 8.04, va che è una meraviglia.
Per configurarlo il nostro programma aziendale basato su client Windows e lato sever LDAP+Mono+PHP web services.
Risultato: ottimo, senza bestemmiare per i vari kernel panic e/o suicidi di FreePBX!
Previous Entries
Categories
Tag Cloud
Blog RSS
Comments RSS
Last 50 Posts
Back
Void 
Life 
Earth 
Wind 
Water 
Fire