Buongiorno a tutti

Volevo sapere se si poteva registrare client sip sulla centrale Openscape Office Mx V 3.0 da remoto senza avere una vpn

Non so come configurare delle linee sip in selezione passante di twt

Dal supporto tecnico di twt dicono

"Le selezioni passanti a differenza delle linee voip singole, non prevedono ne registrazione ne la

fornitura di credenziali per effettuare la chiamata. Le selezioni passanti vengono "autenticate

ed autorizzate" dalla rete TWT in base all'indirizzo ip . Vengono accettate

solo le chiamate provenienti dall’IP del gateway solo se il numero chiamante appartiene alla

selezione passante. sono da considerarsi collegamenti "gateway to gateway". Il session border

controller TWT è in ascolto sulla porta TCP e UDP 5060 IP 77.239.128.13."


grazie a tutti e buon lavoro

Quote from: Kimera on February 13, 2013, 09:35:42 am

Non capisco: quando si programma un IP Trunking nelle HG1500 appartenenti a sedi interconnesse tramite una VPN (nello specifico: VPN Box-To-Box instaurate dai rispettivi Firewall, Firewall che fungono da (Default) Gateway per ciascuna delle HG1500 in questione) GIA' nella programmazione dei Trunk si inseriscono (ad incrocio) gli IP di ciascun nodo remoto...quindi le "rotte" sono GIA' (in qualche misura) dettate (...altrimenti l'HG1500 della Sede A non saprebbe di dover riversare il suo traffico IP/VoIP verso l'HG1500 della Sede B e viceversa...).

Se dovesse essere necessario esplicitare una rotta statica (quindi sul Routing) dell'HG1500 oltre a quella che si crea quando si programma l'IP Trunking significherebbe che i due Firewall non sono programmati (la loro VPN non è programmata) a dovere.

O sbaglio il ragionamento ?

Sbagli in parte il ragionamento e in parte è corretto.

Lascia perder per un attimo gli ip "incrociati" sui trunk degli HG.

In una situazione normale accade questo:

Un pc deve instradare un pacchetto, se la destinazione è nella sua rete (controllo tramite sn mask), instrada il pacchetto diretto.
Se non è nella sua rete cerca un rotta statica per instradare, se non è nelle rotte statiche usa il GW di default.
Tralaltro il gw di default in teroia non esiste perchè un una rotta statica verso tutte le destinazioni. Vedi un "route print" su qualunque pc.

Negli HG, invece, accade una cosa strana specialmente nella parte voip:

HG deve instradare un pacchetto, la destinazione non è nella sua rete, per instradarlo usa la catena delle rotte statiche e poi il default GW.
I pacchetti di ritorno (per chi conosce iptables: stato connessione RELATED, ESTABLISHED) vengono instradati secondo la catena già "scovata" per l'invio.

Quando HG riceve un pacchetto, per la prima volta (per chi conosce iptables: stato connessione NEW) e il pacchetto proviene da una rete diversa, HG in alcuni casi non risponde.
Se invece la rete di provenienza è presente tra le rotte statiche allora risponde.

Ora il motivo esatto non lo so...

le ipotesi sono due:

A) Siemens ha messo volutamente questa cosa come controllo di sicurezza
B) E' un bug: hg riceve il pacchetto, cerca di rispondere ma non trova una via su cui instradarlo.

Tralatro questa cosa non è valida sempre. esempio che è successo a me:

Due sedi in VPN con cornet ip e alcuni pc connessi in vpn con softclient SIP.

Sede A 192.168.60.x
Sede B 192.168.70x
pc in vpn 192.168.250.x con Sede A

le due sedi avevano un solo gw di default, i pc di più avendo una VPN sul pc ma non centra.

I pc si registravano (e funzionavano) correttamente sulla sede A, Sede A e Sede B non si connettevano in cornet.
Aggiunte le rotte statiche sui due HG per le due sedi (straripeto assolutamente inutili in teoria) e tutto ha preso a funzionare.

Forse questo problema c'è solo con le connesisoni TCP (trasporto del cornet se non sbaglio) mentre con le UDP (SIP) no.
Oppure è proprio stato fatto come controllo di sicurezza solo sui trunk per. Non lo so.

le rotte statiche e il defautl gateway servono per indicare verso che destinazione mandare i pacchetti... non per valutare da chi arrivano. nell' header del pacchetto c'è l'indirizzo del mittente e del destinatario con le rispettive porte . se l'indirizzo del destinatario non  è nella stessa sotto rete viene inviato o al default gateway oppure se presente una rotta statica di quella sotto rete al suo gateway ....
Per quanto riguarda la differenza tra tcp e udp la differrenza è solo a livello di trasmissione dei pacchetti... TPC controlla la reale ricezione del pacchetto da parte del destinatario e non fa il riodino dei pacchetti  ed è per questo che è usato nella trasmissione della voce (sip e non sip) ma anche di tutti le trasmissioni "real-sensitive"

Se i default gateway nelle hg e nella centrale sono corrette in tutte le sedi secondo me il problema può essere solo nelle rotte delle vpn.   Ma riesci ad accedere via web all'hg di altre sedi da quella di prato ?

La configurazione della centrale non la metto in dubbio, oltretutto ha Como ho portato una nuova centrale che preventivamente avevo provato ad Arezzo. Quindi ho cambiato gli indirizzi e l'ho provata a Como. Esito negativo. Il default gateway non è, da tutte le sedi riesco a raggiungere sia il centralino che HG1500. Mettendo l'indirizzo IP della centrale telefonica al Pc pingo tutte le sedi e vengo raggiunto. quello che mi stranisce è che escudendo il firewall e quindi mettendo un indirizzo Ip pubblico alla HG1500 il risultato non cambia. Esito negativo.

penso che i firewall delle varie sedi facciamo tra di loro delle vpn quindi se metti un indirizzo pubblico alla hg 1500 è giusto che non funzioni

Quote from: Lucky on November 27, 2012, 08:19:16 pm

Alive monitor attivo? con che protocollo? icmp? Passa il ping?
In call-monitor la chiamata impegna il fascio voip?

Una bella sniffata (wireshark) sulla lan del hg di como per vedere cosa succede nella comunicazione voip?

Alive monitoring ho provato sia attivato che disattivato, esito negativo. Il protocollo sia Cornet che Sip, esito negativo. Il ping funziona. il call monitoring non l'ho fatto. Ho fatto una sniffata ma non c'ho capito nulla. Se vuoi te la mando in privato.

il ping verso quale indirizzo lo hai fatto e lo hai fatto da un pc o dall' hg 1500?
per caso è cambiato il default gateway della sede di Como ?
Dato per assodato  che prima del cambio della rete tutte e tre le sedi si chiamavano a vicenda e dopo invece no,  non penso che il problema sia da ricercarsi nella configurazione della centrale di Como ma nella configurazione della rete. L'unica cosa che potrebbe essere legata alla centrale è la configurazione del default gateway sia del centralino che dell'Hg1500.
Hai provato da Siena a pingare l'indirizzo dell'hg1500 e del centralino di como ?

Giusto