



Esistono tre metodi per collegare due PBX Trixbox, attraverso l’uso di estensioni IAX (per maggiore “comodità” verso il NAT rispetto al SIP), attraverso l’uso di un approccio PEER/USER o attraverso l’uso di FRIENDS.
Io preferisco, ma a titolo personale, l’uso del secondo approccio, che descriverò di seguito.
In questo esempio i due sistemi escono sulle urbane in maniera indipendente, usano il trunk di interconessione solo per le chiamate interne, poniamo 2XX il primo sistema, 3XX il secondo.
PRIMO SISTEMA
IAX2 TRUNK
Outgoing Dial Rules : 3XX
Trunk Name : LinkSedi-out
Peer Details
host=(IP FISSO o DYNDNS SISTEMA2)
qualify=yes
type=peer
User Context : LinkSedi-in
User Details
context=from-internal
host=(IP FISSO o DYNDNS SISTEMA2)
type=userOutbound Routing
Route Name : LinkSedi-out
Route Password : VUOTA
Dial Patterns : 3XX
Trunk Sequence : IAX2/LinkSedi-out
SECONDO SISTEMA
IAX2 TRUNK
Outgoing Dial Rules : 2XX
Trunk Name : LinkSedi-out
Peer Details
host=(IP FISSO o DYNDNS SISTEMA1)
qualify=yes
type=peer
User Context : LinkSedi-in
User Details
context=from-internal
host=(IP FISSO o DYNDNS SISTEMA1)
type=userOutbound Routing
Route Name : LinkSedi-out
Route Password : VUOTA
Dial Patterns : 2XX
Trunk Sequence : IAX2/LinkSedi-out
Tutto qua, molto semplice direi!




Oggi è un anno esatto che ho aperto questo mio piccolo blog!
Un ringraziamento a tutti i visitatori, che sempre più numerosi mi vengono a far visita (oramai superati i 150.000 contatti)..
Quando ho iniziato a scrivere questo piccolo blog non credevo di riuscire a fare qualcosa di buono, doveva essere un semplice memorandum personale, invece mi fa piacere di essere un riferimento per le ricerche di tantissimi visitatori e “colleghi”!
Grazie a tutti!




The bad packets stop here, come recita il sito ufficiale.
IPCop è una delle prime e meglio riuscite distruzioni linux dedicate al firewalling.
Piccola, veloce ed immediata, è l’ideale per creare firewall con semplicità, ma può essere dotata di decine e decine di addons, quali content filtering (SquidGuard o Dansguardian), antivirus, monitoraggio reti, server OpenVPN e così via.
Inoltre da svariati test effettuati è molto più performante, sia in termini di ritardo di rete che di semplice reboot rispetto al suo fork italiano, Endian.
Personalemente ho usato entrambi, ma tropo IPCop meno “legata” e molto più customizzabile, specialemente per quanto riguarda il Content Filtering e controllo sulle connessioni in uscita.
A dire il vero questi sono moduli di IPCop, chiamati BOT e COP+.
Infatti per fare un firewall completo consiglio di installare oltre ai componenti sopracitati anche Net-Traffic, un comodo “riepilogo” del traffico, giornaliero, settimanale, mensile etc..etc..
Il sito maggiore per gli addons è http://firewalladdons.sourceforge.net oltre a http://www.ipcop.org/modules.php?op=modload&name=phpWiki&file=index&pagename=IPCopAddons .
Ah ovviamente IPCop supporta l’IDS Snort, utilissimo anche per individuare attività come la replicazione dei worms.
Tempo permettendo posterò via via configurazioni e “trucchetti” su vari moduli ![]()
Per finire, cosa molto interessante, dal road map della distribuzione è previsto il passaggio al kernel 2.6 nella versione 1.5 e all’utilizzo di Shorewall per la creazione delle regole dalla versione 1.6




I toni dtmf sono molto importanti nella telefonia, sia classica che ip, basti pensare che sono indispensabili per i menù dei vari IVR (che personalemente odio
)
Nella stragrande maggioranza dei telefoni IP, per impostazione predefinita abbiamo toni dtmf in-band (oppure in-audio), ma questa modalità può dar problemi con la voicemail.
Inoltre questa modalità funziona se c’è abilitato il codec ulaw (o alaw), altrimenti la compressione potrebbe “danneggiare” il tono distorcendolo.
Per funzionare con le voicemail i toni dovranno essere rfc2833 o SIP info.
Altresì potete impostare auto, così facendo Asterisk se un dispositivo non sarà in grado di gestire un tono rfc2833, sarà usato inband.
Dimenticavo, dtmfmode= auto, rfc2833 o inband in sip.conf o iax.conf o in ogni singola estensione.




Molte volte può essere utile connettersi a dei dekstop remoti, ad esempio per assistere i propri clienti, ma spesso i pc stanno dietro firewall o semplicemente dei router con NAT.
Il problema è quindi raggiungere questi client, non sempre è possibile effettuare port forwarding, soprattutto se i client sono tanti o non c’è personale tecnico per farlo!
Niente paura, è possibile usare una tecnica chiamata vnc reverso, ovvero la connessione viene inziata dal pc di cui vogliamo controllare il desktop, in altre parole sarà il nostro client ad essere “in ascolto”.
Unico requisito è che ovviamente il nostro client dovrà essere raggiungibile dall’esterno, ma la nostra infrastruttura IT sarà in grado di fare un port forwarding! (o no?!) ![]()
Innanzittutto dobbiamo forwardare dal nostro router (se non abbiamo un ip pubblico) la porta tcp 5500, ovvero la porta in cui sarà in ascolto il demone vnc client (Listening VNC viewer).
Nel computer remoto dovrà essere installato vnc con una password qualsiasi ed eseguito il server (come servizio o manuale), a questo punto cliccare con il tasto destro sull’icona del VNC server e scegliere Add New Client…
In questo modo il server (pc remoto) si connetterà al client (nostro pc) e noi potremmo controllare la sessione desktop di quel pc, senza preoccuparsi di altri NAT


More Options ...
Categorie
Tag Cloud
Blog RSS
Comments RSS

Void « Default
Life
Earth
Wind
Water
Fire
Light 