Oggi e’ stata rilasciata una nuova release di Medianix base, la 0.7, oltre che il nuovo modulo FreePBX. Dal trac di medianix:

Changes in FreePBX 0.3 module:

* asterisk upgraded to 1.4.4

* asterisk-gui upgraded to svn trunk 20070520

* zaptel upgraded to 1.4.2.1

Changes in medianix 0.7 base:

* zaptel modules upgraded to 1.4.2.1

* base system upgraded to latest debian sid

* some minor bugfix

Maggiori dettagli al link http://trac.medianix.org

asterisk, medianix, VoIP

Oggi mi sono svegliato presto, con un pensiero che mi ronzava nella testa. Si, ho risolto il problema con fastweb, e il mio SIP server ora funziona alla perfezione. Pero’ i “tecnici” di fastweb hanno qualcosa come 15 tickets chiusi in un giorno dove sta scritto che le cose non funzionano a causa mia, della mia configurazione, e questo proprio non riuscivo a farmelo andare giu’.

Inizio a pensare a come convincerli del fatto che il problema e’ loro mentre faccio colazione, e un pensiero si fa sempre piu insistente nella mia testa. In fondo, ora il loro “GAD” e’ staccato, e quindi se fanno una verifica a loro risulta che la mia connessione sia “down”.

Decido quindi di tornare a Milano sulla scena del crimine, e di ingannare fastweb al fine di dimostrare quanto siano incompetenti. Non so se riusciranno a risolvere il problema, ma questo in fondo poco importa, tanto so come risolverlo da me, l’importante e’ che capiscano che il problema e’ loro, non mio!.

Prendo la macchina e mi butto in autostrada, e, durante il tragitto, telefono a fastweb annunciando che siamo senza connessione e che probabilmente il loro GAD e’ morto, non da’ piu segni di vita. L’operatrice ovviamente mi rivolge le domande di rito, tipo “avete provato a riavviare il GAD togliendo e rimettendo la spina?”, e ancora “le linee telefoniche invece funzionano?” e cosi’ via. Ma io insisto che ho fatto tutto, che nulla funziona, che devono fare uscire un tecnico. Detto fatto, mi annuncia che ha aperto la segnalazione e che verro’ richiamato a breve per prendere un appuntamento da parte del tecnico che verra’ a sistemare il problema.

Passano 2 ore, io sono in ufficio che aspetto ( con il GAD staccato ma con la connessione che funziona a meraviglia ), quando finalmente suona il cellulare. E’ lui, il tecnico di fastweb, mi annuncia che verra’ presso la nostra sede alle 14:30 ( ho chiamato alle 9… se avessi davvero un guasto avrei perso mezza giornata di lavoro minimo! ah, che assistenza! ).

Arrivamo le 14:30, una telefonata mi annuncia che il tecnico arrivera’ un po’ in ritardo ma di stare tranquillo che sta arrivando. In effetti oggi piove che quel tizio lassu’ la manda, quindi non mi stupisco piu di tanto pensando ai possibili ingorghi da pioggia nel traffico milanese, mi metto il cuore in pace e aspetto.

Arrivano le 15 e finalmente il tecnico suona il campanello. E’ arrivato. gli vado incontro per accompagnarlo nel piccolo NOC dell’ufficio esordendo con un bel “buongiorno, le svelo un segreto, il nostro GAD funziona benissimo, e’ stato un problema simulato, ora le spiego il vero problema…”, e gli spiego tutta la pappardella di cio’ che e’ successo il giorno prima, di quale sia il vero problema, di quali siano le soluzioni che ho provato (si, compreso il fatto di staccare quel cesso di GAD).

Il tecnico porello e’ un dipendende di una azienda esterna in appalto, e piu di tanto non ne capisce, e’ anzi preoccupato di come giustificare la sua uscita. Ma io lo incalzo e lo invito a chiamare qualcuno che possa davvero capire il mio problema, e lui, gentilissimo e assolutamente senza colpa in tutto questo, mi asseconda. Chiama un suo contatto all’interno di fastweb dicendomi “questo e’ un ragazzo davvero in gamba, se c’e’ qualcuno che puo’ aiutarti e’ lui”. E in effetti ammetto che la persona dall’altra parte del telefono e’ competente. Con la sua guida e le password del tecnico ( che ovviamente non mi ha rivelato ) entriamo nel GAD dal terminale seriale.

Il GAD e’ una macchina ARM con un Linux embedded (kernel montavista), busybox e una cavolo di shell che emula in tutto e per tutto una CLI di Cisco IOS ( che fantasia quelli di telsey ). inizio a guardare la configurazione, e subito mi accorgo di una cosa. Non ci sono filtri apparentemente, ma c’e’ un limite di banda e di connessioni sulla porta udp 5060, ebbravi fastwebbari!.

Ranzo via il filtro con il permesso del tecnico al telefono, e giro un po’ nella cli alla ricerca di altri eventuali filtri. Il nulla, non c’e’ nulla. Decido per un “reload” del firmware, giusto per vedere se torna per caso il limite di prima, e nel frattempo ho sempre il mio hping che viaggia da una macchina esterna e il mio tcpdump che sniffa la eth0 della mia linuxbox.

La regola di limit non torna su, bene, ma una cosa mi salta all’occhio. Mentre il GAD fa il riavvio, durante lo shutdown per un attimo arrivano i pacchetti che sto inviando con hping2 (circa 10 pacchetti, giusto giusto prima del termine dello shutdown), e mentre il GAD si riavvia, altri 4 pacchetti arrivano da quando viene su la scheda di rete a quando appare la scritta “starting configuration” al terminale. Strano, sembra proprio il comportamento tipico di regole di iptables applicate durante il boot in uno script di init!. Ma dalla cli invece il nulla, non risultano filtri di alcun genere.

Morale della storia, non siamo riusciti a risolvere il problema, ma i tecnici hanno dovuto ammettere ( anche per iscritto, mi sono fatto firmare una dichiarazione, non si sa mai potrebbe servirmi ) che il problema sta sul loro GAD, suggerendomi di attendere il cambio di contratto che ho in corso e che a breve mi fara’ cambiare il GAD con un router cisco, sperando che con quello il problema non si verifichi piu’.

Una cosa e’ comunque certa, nel firmware del GAD fastweb effettivamente FILTRA i pacchetti in ingresso sulla 5060 UDP!

A questo punto ringrazio il tecnico, lo lascio andare via, e appena uscito dalla porta spengo il gad, lo metto da parte, e rimetto la mia bella macchina linux davanti a tutto, e vivo felice con la mia bella rete che funziona. Per ora va bene cosi’, ne riparliamo quando mi cambieranno il router…

To be continued…

asterisk, fastweb, VoIP

Cercando un poco su google si incappa facilmente in post di utenti di Fastweb che dichiarano di sospettare che quest’ultima filtri il protocollo SIP, rendendo di fatto difficile l’utilizzo di tanti provider VoIP che stanno nascendo in questi ultimi anni.

Io devo dire che sinceramente non ho trovato questi problemi, e, nat a parte con i suoi casini, un client SIP dentro la rete fastweb mi ha sempre funzionato egregiamente.

Oggi pero’ mi sono scontrato con un fatto sconcertante con il suddetto ISP.

Prima spieghiamo la situazione: un mio cliente, che possiede in ufficio un contratto “small businness”, decide di piazzare un Asterisk server sul quale ricevere delle chiamate via SIP. Per fare questo, essendo fastweb un grande NAT, compra il servizio “IP Pubblico”, e si fa assegnare 4 indirizzi ip pubblici, routati verso una macchina interna alla propria LAN (badate, non nattati o in pat, routati!)

Detto fatto, ci assegnano 4 indirizzi, rediretti verso la nostra macchina interna con ip 192.168.0.7, macchina linux che funge da router e redirige gli ip pubblici a 4 macchine dietro di essa. Tutto sembra funzionare a meraviglia, impostati gli ip alias sulle macchine che dovevano essere raggiungibili dall’esterno, queste ultime sono effettivamente raggiungibili, ci entro in ssh, mi apro apache, faccio tante cosine e tutto funziona.

Allora installo asterisk, mi chiamo via IAX2, funziona.

Configuro asterisk per stare in ascolto con chan_sip sulla porta udp 5060 (la porta standard per SIP) provo a registrarmi con un client dall’esterno e… uhmm… nulla, non si registra. Strano, funziona tutto… perche’ non si registra?

Decido quindi di tracciare un po’ il traffico, mi piazzo sul router, avvio tcpdump, entro in una mia macchina esterna a fastweb, e avvio un hping2 -2 -p 5060 . Niente, non c’e’ traccia di pacchetti che arrivino al mio router. Strano. Magari e’ il firewalling. Cancello TUTTE le regole di iptables, tanto per essere sicuri. Nulla, non arriva nulla.

Cambio porta ad hping2, provo la 5061, e i pacchetti arrivano. Provo un po’ di porte random, e i pacchetti arrivano. Riprovo la 5060, il nulla. Decido quindi che il problema e’ in Fastweb, e quindi chiamero’ l’assistenza domani. Domani e’ oggi.

Siamo quindi arrivati a questa giornata infame. Stamattina, appena arrivato in ufficio, chiamo il 192194, servizio clienti di fastweb per le aziende. Spiego il problema all’operatore del call center, che apre un ticket e mi fa lasciare il numero di telefono, dicendomi che mi fara’ richiamare da un tecnico.

Dopo 2 ore non mi ha chiamato nessuno, quindi richiamo il 192194. Di nuovo mi dicono che un tecnico mi chiamera’ a breve, ed effettivamente dopo circa 10 minuti ricevo una telefonata.

Spiego il problema, il tecnico mi mette in attesa mentre controlla la configurazione del “GAD”, ovvero il loro piccolo router telsey con linux che mettono con questo genere di contratti. Dopo un po’ l’attesa finisce e il tecnico mi dice “non c’e’ nessun filtro sul gad, e’ sicuro che dal suo lato e’ tutto a posto?”

A questo punto io spiego che sto sniffando con tcpdump, che solo quella porta da problemi, che sono collegato diretto al gad e quindi non c’e’ ne firewall ne altro in mezzo. Sembra convincersi, e mi rimette in attesa. Attendo… attendo… passano 16 minuti in attesa, e cade la chiamata.

Richiamo il 192194, risponde un altro operatore, rispiego il problema. Mi conferma che non ci sono filtri sul gad e mi dice che mi richiameranno.

Dopo un’ora mi richiama un altro tecnico, rispiego nuovamente il problema, mi mette in attesa e dopo un po’ mi dice “non ci sono filtri sul gad, non e’ un suo problema?”. Io inizio ad irritarmi, ma gentilmente rispiego nuovamente il tutto, sottolineando che o i pacchetti si perdono a meta’ del cavo di rete di 50 cm tra il gad e il mio router, oppure i pacchetti si fermano da loro, sul gad o prima. Il tecnico a quel punto mi dice “forse e’ la sua scheda di rete rotta, ha provato a cambiare scheda di rete?”.

Ora mi incazzo sul serio, e inizio a spiegargli, bestemmiando allegramente, che dovrebbe provare a tracciare i pacchetti dumpando il traffico sulle sue fottute schede di rete, oppure che facciano uscire un tecnico a verificare di persona il problema, e smetterla di dire che e’ un problema dal mio lato, perche’ semplicemente NON e’ cosi’.

Il tecnico mi risponde “capisco, ok attenda un attimo, la richiamo io” e riaggancia. Dopo 10 minuti di richiama, e mi conferma che non ci sono problemi, e che quindi secondo lui il problema e’ da me. Non piu’ tanto gentilmente gli spiego qualcosa sulle reti e su quello che sto provando sperando di dimostrare che il problema non e’ mio. Dopo un po’ mi rimette in attesa, cade la linea e finisce li.

Irritato chiamo nuovamente il call center, dove mi viene detto che il ticket e’ stato chiuso con motivazione “problema di competenza del cliente”. Mi incazzo, chiedo di parlare con un responsabile, mi passano uno pseudotale, che riapre un nuovo ticket.

Ora senza tirarla ulteriormente per le lunghe, andiamo avanti tutta la giornata, fino alle 19 circa in questo modo. Ho chiamato il call center almeno altre 14/15 volte, tutte le volte mi confermavano che il ticket precedente era stato chiuso con la stessa motivazione, e mi dicevano che mi avrebbero fatto richiamare da un tecnico. Nessun tecnico mi richiamava, io richiamavo e il ciclo ricominciava.

Alla fine mi sono decisamente rotto, ho staccato fisicamente il loro “gad”, ho attaccato la mia macchina linux diretta al media converter, ho spoofato il mac-address del gad e mi sono preso il suo indirizzo IP interno a fastweb. Tutto magicamente ha iniziato a funzionare, e i pacchetti udp 5060 arrivano senza problemi, riesco a registrarmi al server senza problemi e le chiamate via SIP funzionano alla perfezione. Ma come, non mi avevano detto che non c’era nessun filtro e che il problema era mio?

Sono senza parole.

asterisk, fastweb, VoIP

Medianix e’ una distribuzione GNU/Linux basata su Debian e Morphix, la prima non ha bisogno di presentazioni, la seconda e’ fondamentalmente una distribuzione basata su Debian e Knoppix che permette la costruzione di LiveCD personalizzati in maniera modulare, semplice e veloce.

Unixmedia S.r.l., l’azienda per cui lavoro, su questi due progetti ha creato Medianix, ovvero la rivisitazione dei concetti di morphix riveduti, implementati e adattati per la creazione di alcuni prodotti, commerciali e non, che costituiscono parte integrante di molte attivita’ che l’azienda stessa svolge sul mercato. Medianix in particolare costituisce la base per la creazione di alcune distribuzioni Linux mirate per la creazione dei propri prodotti, soprattutto nel mercato della telefonia.

La base di Medianix e’ comunque rilasciata completamente free e liberamente scaricabile/utilizzabile e, penso, si adatta effettivamente a molti diversi utilizzi. A tale fine, con anche la speranza che la comunita’ di potenziali utilizzatori contribuiscano anche attivamente al suo sviluppo, sono stati aperti un repository svn, un trac site e un repository debian dove e’ possibile sia collaborare al progetto, sia utilizzare tutto il codice che verra’ mano a mano rilasciato liberamente utilizzabile.

Uno dei prodotti che Unixmedia sta preparando e’ un Centralino VoIP/ APBX/ IVR ottimizzato per gli ambienti dei clienti ai quali si propone sul mercato, in cui verranno inclusi anche molti software sviluppati da Unixmedia ad-hoc per medianix e con funzionalita’ avanzate. Le distribuzioni che includeranno questi software saranno solo commerciali, e quindi non gratuite, tuttavia, utilizzando in gran parte software libero come base per molte delle proprie distribuzioni, Unixmedia rilascera’ anche diverse distribuzioni “ripulite” di tutte le componenti proprietarie liberamente scaricabili. Il primo esempio di queste distribuzioni e’, anche se attualmente solo una prima “beta release”, Medianix-FrePBX 0.6, liberamente scaricabile e comprensiva di Asterisk aggiornato alla versione 1.4.1, mISDN, Asterisk-GUI arredi e corredi.

Per chi utilizza Debian o una sua derivata, inoltre, sono stati rilasciati i pacchetti precompilati, usati in Medianix FreePBX, di Asterisk aggiornato alla 1.4.1, mISDN aggiornato all’ultima release, Asterisk-GUI e altri.

Trovate i link ai repository nella pagina repository debian.

asterisk, medianix, VoIP

PDAstre e’ un demone il cui scopo e’ unificare e amministrare complesse strutture telefoniche, quali sistemi IVR, PBX, VoIP servers distribuiti, etc etc.Il mondo open source offre oramai diversi software, alcuni anche molto validi, per i vari aspetti della telefonia, sia tradizionale che over internet. Spesso pero’ questi software coprono solo parzialmente il vasto campo della telefonia, e non sempre permettono una reale scalabilita’ in ambienti distribuiti, e l’interoperabilita’ tra di essi non e’ sempre ottimale. PDAstre si inserisce in questo contesto con l’intento di integrare molti di questi software in un unica interfaccia che ne gestisca non solo le funzionalita’ ma anche la distribuzione, lo statistico (CDR), e molto altro.

PDAstre e’ concepito per un utilizzo interno da parte di NexLab, ma, viste le dimensioni del progetto e la potenziale utilita’ dello stesso anche in altri ambienti, ho deciso di pubblicare questo trac site nell’intenzione di gestire il progetto in maniera pubblica in tutti i suoi sviluppi, a partire dalla discussione iniziale per la sua progettazione.

PDAstre e’ sviluppato in Python, scelta imposta un po’ dal fatto che e’ un linguaggio che personalmente mi piace molto e che conosco sufficientemente bene, un po’ dal fatto che offre gia’ una svariata collezione di framework, librerie, applicazioni che permettono di ridurre molto la quantita’ di codice da scrivere per PDAstre stesso.

Per il momento non e’ stato rilasciato codice, in quanto ancora si sta delineando la fase progettuale concernente la struttura stessa del demone.

L’indirizzo del progetto e’ http://www.nexlab.it/trac/pdastre/

asterisk, VoIP