Pagina 5 di 42 primaprima ... 3 4 5 6 7 15 ... ultimoultimo
Visualizzazione dei risultati da 41 a 50 su 418
  1. #41
    Utente di HTML.it L'avatar di pilovis
    Registrato dal
    Mar 2001
    Messaggi
    3,273
    Piaf a mio giudizio e' la migliore, la piu' completa e la piu' flessibile distro basata su Asterisk.
    Con Piaf vai sul sicuro

    Controlla solo di avere le risorse sufficienti per gestire tutte quelle linee e quei telefoni:

    Processore = Core Duo (o equivalente) 2 Ghz minimo
    Memoria RAM = min. 2 Gigabytes
    Banda internet di upload= min. 48 kbit/sec per canale audio concorrente (56 kbit/sec min. se usi Ulaw o Alaw come codec, 128 Kbits/s se usi il nuovo codec HD g722).
    Latenza (ping) < 50/60 ms
    Jitter <25 ms

    Pings (latenza) piu' elevati creano fastidiosi "echo".
    Se il Jitter fosse piu' elevato (fino a 100 ms Max) lo compensi con il "Jitter buffer" da settare su Asterisk.

    Banda, latenza e Jitter della tua ADSL li testi qui: http://test.ngi.it (devi avere Java installato)

    Ciao.

    Maurizio
    Ultima modifica di pilovis; 09-01-2014 a 09:12
    Progettista elettronico, appassionato di informatica dal 1982, sistemista Linux dal 2002, sono consulente tecnico del Giudice per le indagini preliminari, valuto richieste di consulenza, in ambito Voip/Telefonia anche con grado di sicurezza militare.

  2. #42
    Utente di HTML.it L'avatar di pilovis
    Registrato dal
    Mar 2001
    Messaggi
    3,273
    puoi anche fare come ho fatto io:
    per ognuna delle due sedi metti un centralino.
    I due centralini li colleghi tra loro con un canale IAX2, condividendo cosi' gli interni, le regole di chiamata e linee esterne.
    Con due centralini suddividi il carico e soprattutto la banda internet e puoi fare in modo che se un centralino va giu', l'altro prende immediatamente in carico tutti i suoi interni e le sue numerazioni e li mantiene finche' l'altro server non torna online.

    Magari un giorno faro' un How-to anche per questo
    Progettista elettronico, appassionato di informatica dal 1982, sistemista Linux dal 2002, sono consulente tecnico del Giudice per le indagini preliminari, valuto richieste di consulenza, in ambito Voip/Telefonia anche con grado di sicurezza militare.

  3. #43
    Utente di HTML.it L'avatar di pilovis
    Registrato dal
    Mar 2001
    Messaggi
    3,273
    Con 8 IP statici ne puoi usare solo 6, perche' un ip e' riservato al Gateway pubblico e uno al Broadcast della rete degli 8 ip.

    Comunque un IP riservalo solo per il Voip e non ci mettere nessun altro servizio sopra, onde evitare che per qualche motivo l'IP ti finisca in blacklist da qualche parte.

    Ti consiglio anche di mettere un Gateway/Firewall prima del centralino, perche' gli attacchi sui centralini, soprattutto quelli Asterisk, sono all'ordine del giorno, moltissimi hakers africani, mediorientali e dei paesi dell'est, vanno in cerca di centralini mal programmati, cercando di bucarli per telefonare a scrocco.

    E' buona regola sul centralino usare Iptables per permettere accessi solo dagli IP autorizzati e bloccare tutti gli altri.

    Ultima cosa, per lo stesso motivo di cui sopra, per i collegamenti dei telefoni al centralino, nel caso viaggiassero fuori dalla LAN e fossero esposti ad Internet (es, i telefoni voip dalla sede 2 alla sede 1 dove c'e' il centralino) non usare le porte convenzionali (es. 5060-5061 UDP), ma usa porte diverse (es. 8280...8286 UDP), in questo modo gli scanner automatici degli hackers, settati sulle porte convenzionali, non trovano porte "interessanti" sul tuo IP e non segnalano quindi la presenza di un centralino attivo.

    L'ideale sarebbe fare un NAT e forwardare solo le porte utili per il centralino.
    Ultima modifica di pilovis; 09-01-2014 a 09:14
    Progettista elettronico, appassionato di informatica dal 1982, sistemista Linux dal 2002, sono consulente tecnico del Giudice per le indagini preliminari, valuto richieste di consulenza, in ambito Voip/Telefonia anche con grado di sicurezza militare.

  4. #44
    Utente di HTML.it L'avatar di pilovis
    Registrato dal
    Mar 2001
    Messaggi
    3,273

    Client Voip per Asterisk su Android

    Sto provando diversi clients voip gratuiti per Android da collegare al mio centralino Asterisk.
    Ho comperato un telefono economico con Android 4.0.4 e con poca memoria disponibile, quindi con le condizioni ideali per fare dei test.

    Tra tutti i clients gratuiti che ho provato, l'unico che ha dato risultati buoni di affidabilita' e stabilita' e' stato Zoiper, tutti gli altri crashano paurosamente, oppure dopo un po' si scollegano e cosi' rimani irraggiungibile .

    Zoiper tra l'altro ha anche la possibilita' di usare il protocollo IAX2 che rispetto a quello SIP e' piu' stabile, occupa meno banda e in una qualche maniera cripta anche leggermente i dati .

    Vi terro' aggiornati sulle prove.
    Progettista elettronico, appassionato di informatica dal 1982, sistemista Linux dal 2002, sono consulente tecnico del Giudice per le indagini preliminari, valuto richieste di consulenza, in ambito Voip/Telefonia anche con grado di sicurezza militare.

  5. #45
    Utente di HTML.it L'avatar di pilovis
    Registrato dal
    Mar 2001
    Messaggi
    3,273

    Mail automatica da Asterisk su chiamata non risposta con caller ID del chiamante, ora e data

    Per essere avvisati di ogni chiamata non risposta e' possibile programmare Asterisk per farci mandare una mail contenente tutte le indicazioni relative alla chiamata:

    ecco la linea da utilizzare nelle extensions.conf:

    exten => s,n,TrySystem(echo “Chiamata da ${CALLERID(name)} ${CALLERID(number)} ricevuta alle ore ${STRFTIME(${EPOCH},,%l:%M:%S %p %Z di %A %B %e)}” | mail miamail@miaposta.com)

    N.B.: ovviamente "miamail@miaposta.com" va sostituito con il vostro indirizzo di posta elettronica.
    (il comando "mail" deve ovviamente funzionare da linea di comando sul vostro server Asterisk)

    Esempio di cio' che si riceve:

    Da: asterisk PBX user <asterisk@miodominio.com>
    A: miamail@miaposta.com
    Data: 14/01/2014 12:04:21

    “Chiamata da linea1:014118xxxx ricevuta alle ore 12:04:21 PM CET di Tuesday January 14”
    Ultima modifica di pilovis; 14-01-2014 a 13:53
    Progettista elettronico, appassionato di informatica dal 1982, sistemista Linux dal 2002, sono consulente tecnico del Giudice per le indagini preliminari, valuto richieste di consulenza, in ambito Voip/Telefonia anche con grado di sicurezza militare.

  6. #46
    Utente di HTML.it
    Registrato dal
    Jul 2007
    Messaggi
    7
    consigli sacrosanti...
    sui centralini sono assegnati ippubblici statici, accesso riservato da alcuni ip per ovvi motivi di sicurezza che hai detto...
    la prima esperienza su interni remoti è molto positiva, è stato facilissimo: per evitare problemi di comunicazione (uno degli interlocutori muto), usare l'impostazione usenat yes nella configurazione dell'interno.
    Appena termino la configurazione base delle sedi, mi piacerebbe condividere qualche passo di scripting php con phpagi
    ciao e grazie ancora per i tuoi contributi
    ps: provengo da un centralino 3cx...adesso siamo su un altro pianeta

  7. #47
    Utente di HTML.it L'avatar di pilovis
    Registrato dal
    Mar 2001
    Messaggi
    3,273
    Per quanto possibile usa IAX2 invece del protocollo SIP per connettere clients e PBX esterni, occupa meno banda, usa una sola porta ed e' piu' affidabile.
    Progettista elettronico, appassionato di informatica dal 1982, sistemista Linux dal 2002, sono consulente tecnico del Giudice per le indagini preliminari, valuto richieste di consulenza, in ambito Voip/Telefonia anche con grado di sicurezza militare.

  8. #48
    Utente di HTML.it L'avatar di pilovis
    Registrato dal
    Mar 2001
    Messaggi
    3,273
    Comunque Asterisk non e' tutto rose e fiori, ritengo sia molto meglio FreeSwitch, piu' completo e potente.
    Purtroppo per FreeSwitch, il fatto di non avere una interfaccia grafica di controllo decente, lo rende adatto solo a quei centralini dove le configurazioni sono scolpite nella roccia e non devono essere modificate, il dover programmare tutto a manina con righe di testo poco intelleggibili lo rende inadatto per i centralini che necessitano di veloci e frequenti riprogrammazioni.
    Io li uso entrambi, FreeSwicth lo uso come centralino di supporto di Asterisk per i canali Skype e Google Voice.
    Ultima modifica di pilovis; 15-01-2014 a 12:07
    Progettista elettronico, appassionato di informatica dal 1982, sistemista Linux dal 2002, sono consulente tecnico del Giudice per le indagini preliminari, valuto richieste di consulenza, in ambito Voip/Telefonia anche con grado di sicurezza militare.

  9. #49
    Utente di HTML.it L'avatar di pilovis
    Registrato dal
    Mar 2001
    Messaggi
    3,273

    Sistema Voip professionale con Load balancing e High Availability

    Un po' di accademia utile per chi ha intenzione di diventare provider Voip e vuole implementare un sistema profesionale ad alta efficienza e alta ridondanza.
    Serve anche per molti provider Voip Italiani che forse non sanno nemmeno come si fa, dato che quando gli va giu' la rete i servizi vanno offline

    Il tutto si basa sula gestione dei DNS autoritativi e il parametro SVR, che purtroppo pochi conoscono, inclusi i nostri stimatissimi professori universitari

    Ecco una spiegazione di come fare:

    Il record "SVR" del DNS e' utilizzato per definire le priorita' e il peso di un certo numero di servers che assieme gestiscono uno specifico servizio internet, analogamente a quanto fa il record "MX" per la posta elettronica.
    Si puo' utilizzare questo parametro non solo per il protocollo SIP ma anche per altri tipi di servizio.

    Non voglio dilungarmi troppo sulla teoria, per cui vi posto un mio esempio pratico di configurazione di un DNS che regge un servizio Voip ad alto traffico con ridondanza.

    Occorrono in questo caso tre servers Voip, due per il load balancing e uno per il Failover.
    I tre servers sono interconnessi tra loro con canale IAX2 e tutti quanti condividono le stesse configurazioni.

    La configurazione di BIND per un ipotetico dominio "mysipdomain.com" e' molto semplice, basta leggere attentamente le mie note in questo esempio.

    NOTA BENE: nell'esempio qui sotto, in grassetto ci sono i records DNS, mentre dopo il ";" ci sono i miei commenti esplicativi che devono essere omessi nel vostro file di configurazione:

    esempio pratico:

    ;
    ; INIZIO CONFIGURAZIONE
    ;
    ; ------------------------------------
    ; configurazione esempio di pilovis
    ;-------------------------------------
    ;
    ; Sezione SOA records - Start of Authority
    ;

    $ORIGIN mysipdomain.com.
    @ SOA ns1.mysipdomain.com. root.mysipdomain.com. (
    1995032001 3600 3600 604800 86400 )


    ;
    ; Sezione dei nameservers autoritativi per questo dominio
    ;

    NS ns1.mysipdomain.com.
    NS ns2.nselsewhere.com.


    ;
    ; Sezione per il load balancing
    ;
    ; in questo esempio specifico per il servizio SIP, ogni tre richieste per il server ;main.mysipdomain.com la
    ; quarta viene dirottata al server secondario secondary.mysipdomain.com (3 a 1)
    ; notare che usando SRV 0 1 per entrambi si ha il load balancing al 50% tra i due servers (1 a 1)

    _sip._udp.mysipdomain.com SRV 0 1 5060 main.mysipdomain.com.
    SRV 0 3 5060 secondary.mysipdomain.com.


    ; qui di seguito ne potete mettere quanti ne volete ...
    ;
    ; Sezione per la ridondanza (redundancy)
    ;
    ; se uno qualsiasi dei due server sopra non risponde, la relativa richiesta passa automaticamente al server di backup

    SRV 1 0 5060 backup.mysipdomain.com.


    ; qui di seguito ne potete mettere quanti ne volete ...
    ;
    ; NOTARE BENE che il formato del record SVR e' il seguente:
    ; _service._proto.name TTL class SRV priority weight port target
    ;
    ; - SPIEGAZIONE DETTAGLIATA DEI PARAMETRI SVR -
    ;
    ; TTL e' il tempo di vita espresso in secondi del record SRV nella cache DNS del client e puo' essere omesso,
    ; quando il TTL scade, il client che utilizza il servizio svuota la cache locale del dns ed effettua ;un'altra richiesta
    ; al nameserver autoritativo del dominio, in modo che se il server primario torna online puo' di nuovo gestire il servizio.
    ; il parametro _service indica il tipo di servizio da erogare
    ; il parametro _proto indica il protocollo TCP o UDP per il servizio
    ; il parametro name e' il dominio principale che gestisce il servizio
    ; il parametro class e' sempre IN e puo' essere omesso come in questo esempio.
    ; priority e' la priorita' del server indicato, piu' il valore e' basso e piu' la priorita' e' alta = redundancy
    ; weight e' il peso (percentuale di carico) tra piu' server con la stessa priorita' = load balancing
    ; port e' la porta TCP o UDP port alla quale il servizio e' offerto
    ; target e' il nome di dominio della macchina che eroga il servizio, puo' essere diverso dal name,
    ; infatti volendo si puo' anche usare un provider SIP esterno come dominio target
    ;
    ;
    ; sezione per gli A records - risoluzione dominio - indirizzo IP
    ;
    ; notare che occorre un A record per ogni host settato nei records SRV
    ; ad eccezione dei domini esterni che sono gia' risolti dai loro DNS autoritativi
    ;

    ns1.mysipdomain.com. IN A 10.0.0.1
    main.mysipdomain.com. IN A 10.0.0.3
    secondary.mysipdomain.com. IN A 10.0.0.4
    backup.mysipdomain.com. IN A 10.0.0.5


    ;
    ; in questo specifico esempio non serve un A record per ns2.nselsewhere.com.
    ; dato che e' non e' un nostro dominio e ha gia' i suoi dns che lo risolvono
    ; ma se il vostro dns secondario e' sotto il vostro dominio allora serve un record A in questa sezione
    ;
    ; FINE CONFIGURAZIONE
    ;



    -------------------------------------------------------------
    Informazioni aggiuntive sulla SOA (Start of Authority):
    -------------------------------------------------------------

    In questo esempio:

    $ORIGIN mysipdomain.com.
    @ SOA ns1.mysipdomain.com. root.mysipdomain.com. (
    1995032001 3600 3600 604800 86400 )


    Il record SOA contiene le seguenti informazioni:

    - Host di origine - l'host in cui è stato creato il file. mysipdomain.com.

    - Server DNS autoritativo primario: ns1.mysipdomain.com.

    - Indirizzo di posta elettronica-indirizzo di posta elettronica della persona responsabile dell'amministrazione dei file di zona del dominio. Si noti che un "." viene utilizzato invece di un "@" nel nome di posta elettronica. root.mysipdomain.com.

    (tra parentesi)

    - Numero di serie - il numero di revisione di questo file di zona. Incrementare il numero di ogni volta che viene modificato il file di zona. È importante incrementare questo valore ogni volta che viene apportata una modifica, in modo che le modifiche verranno distribuite a tutti i server DNS secondari. 1995032001

    - Aggiorna ora - il tempo in secondi, un server DNS secondario attende prima di eseguire query record SOA del server DNS primario per controllare le modifiche. Quando scade il tempo di aggiornamento, il server DNS secondario richiede una copia del record SOA corrente dal primario. Il server DNS primario ottempera a questa richiesta. Il server DNS secondario confronta il numero di serie del record SOA corrente del server DNS primario e il numero di serie nel record SOA propri. Se sono diversi, è possibile che il server DNS secondario richiederà un trasferimento di zona dal server DNS primario. Il valore predefinito è 3.600. 3600

    - Ora - tentativo il tempo in secondi, un server secondario attende prima di ritentare un trasferimento di zona non riuscito. In genere, il tempo di tentativi è inferiore al tempo di aggiornamento. Il valore predefinito è 600. 3600

    - Scadenza tempo - il tempo in secondi, che un server secondario verrà effettuati altri tentativi per completare un trasferimento di zona. Se il tempo scade prima del trasferimento, il server secondario scadrà il relativo file di zona. Ciò significa che secondario interromperà rispondendo alle query che ritiene che i dati troppo vecchi per essere affidabile. Il valore predefinito è 86.400. 604800

    - TTL minimo - il valore minimo di time-to-live si applica a tutti i record di risorse nel file di zona. Questo valore viene fornito nelle risposte alle query per informare gli altri server quanto tempo è necessario mantenere i dati nella cache. Il valore predefinito è 3.600. 86400

    Tutti questi parametri non devono essere messi a caso, ma devono seguire una precisa strategia di progetto per avere la massima affidabilita' del nostro specifico servizio Voip, non c'e' una regola generale ma vanno studiati caso per caso.
    Ultima modifica di pilovis; 15-01-2014 a 13:01
    Progettista elettronico, appassionato di informatica dal 1982, sistemista Linux dal 2002, sono consulente tecnico del Giudice per le indagini preliminari, valuto richieste di consulenza, in ambito Voip/Telefonia anche con grado di sicurezza militare.

  10. #50
    Utente di HTML.it L'avatar di pilovis
    Registrato dal
    Mar 2001
    Messaggi
    3,273

    per colpa di qualcuno non si fa piu' credito a nessuno

    Il fatto di aver messo online sul mio sito le guide per asterisk ha portato a continui attacchi e tentativi di hackeraggio, per cui ho deciso di rimuovere i files .

    Se qualcuno volesse averli puo' scrivermi in privato o meglio ancora contattarmi su ICQ.
    Ultima modifica di pilovis; 16-01-2014 a 08:27
    Progettista elettronico, appassionato di informatica dal 1982, sistemista Linux dal 2002, sono consulente tecnico del Giudice per le indagini preliminari, valuto richieste di consulenza, in ambito Voip/Telefonia anche con grado di sicurezza militare.

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.