Marco's Informatik Blog

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!

Social Bookmarks

Hide Sites

Il perchè del topic è presto detto…rispondono a caso sapendo di non poter essere in qualche modo cazziati!
Da un cliente che ha tre borchie ISDN, ho chiesto un numero aggiuntivo su una di esse e dato che queste tre borchie erano in ricerca automatica, la borchia con il numero aggiuntivo è stata tolta dalla r.a., questo perchè le borchie multinumero non funzionano in modalità PBX (di solito borchie punto punto, ma anche punto multipunto, capita).
Comunque sia ovviamente c’era da riprogrammare anche quella del capofila per modificare la r.a. solo su due borchie…e qui comincia l’odissea.
Ieri la borchia capofila non andava affatto, l’altra si, mentre da oggi pomeriggio nemmeno questa, ne ingresso ne uscita.
Ovviamente la Telecom chi ha incolpato? ME! Il tecnico del centralino, con la solita storiella “c’è da ripogrammare il sistema…..” UEEE! Apparte che quella configurazione sul patton gira su N apparati, ma se prima che LORO mettessero le mani andava il tutto con 3 borchie, non vedo perchè non deve andare con due!!!!
Poi siccome loro pensano SEMPRE di aver a che fare con dei piccioni dall’altra parte del telefono (cose del tipo: non ho portante ADSL e loro “controllato i DNS?”), ma a questo punto mi pare chiaro il problema dal debug isdn del patton:

00:19:34  ISDN  > # 665 p: 1 R: sapi: 0 cr=1 ea=0 tei:  0 ea=1 SABME                p =1
00:19:35  ISDN  > # 666 p: 1 R: sapi: 0 cr=1 ea=0 tei:  0 ea=1 SABME                p =1
00:19:36  ISDN  > # 667 p: 1 R: sapi: 0 cr=1 ea=0 tei:  0 ea=1 SABME                p =1
00:19:37  ISDN  > # 668 p: 1 R: sapi: 0 cr=1 ea=0 tei:  0 ea=1 SABME                p =1
00:19:38  ISDN  > # 669 p: 1 R: sapi: 0 cr=1 ea=0 tei:  0 ea=1 SABME                p =1
00:19:39  ISDN  > # 670 p: 1 R: sapi: 0 cr=1 ea=0 tei:  0 ea=1 SABME                p =1
00:19:40  ISDN  > # 671 p: 1 R: sapi: 0 cr=1 ea=0 tei:  0 ea=1 SABME                p =1
00:19:41  ISDN  > # 672 p: 1 R: sapi: 0 cr=1 ea=0 tei:  0 ea=1 SABME                p =1
00:19:42  ISDN  > # 673 p: 1 R: sapi: 0 cr=1 ea=0 tei:  0 ea=1 SABME                p =1
00:19:43  ISDN  > # 674 p: 1 R: sapi: 0 cr=1 ea=0 tei:  0 ea=1 SABME                p =1
00:19:44  ISDN  > # 675 p: 1 R: sapi: 0 cr=1 ea=0 tei:  0 ea=1 SABME                p =1
00:19:45  ISDN  > # 676 p: 1 R: sapi: 0 cr=1 ea=0 tei:  0 ea=1 SABME                p =1

Ovviamente questa musica (tentativo di riconnessione) si ripete all’infinito su entrambe le porte atatccate alle borchie incriminate.
Quindi che dire, vediamo domani se rispondono di nuovo al mio sollecito di gusto con qualche altra storiella!
Come chiusura di post vi ricordo come attivare il debug su uan determinata porta isdn con il patton

login: {username qui}
password: {password qui}
enable
configure
debug ccisdn signaling
debug isdn event {slot} {porta} all

per esempio per il debug sulla bri 0/0

debug isdn event 0 0 all
mentre per disabilitare il debug, no debug all

Social Bookmarks

Hide Sites

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.

Social Bookmarks

Hide Sites