Client SIP su OSO MX quali porte aprire/nattare

[Kimera]

Ora è chiaro...come si dice? ah...delle due una.

La tua situazione (com'è abbastanza normale che sia in certi ambiti aziendali) ricade nel caso di Pool di IP Pubblici Statici (Subnet pubblica, tipico Pool di 16 indirizzi, ovviamente non tutti utilizzabili) e quindi non avrai da affrontare alcun doppio NAT perchè la WAN del Firewall avrà a disposizione il suo bel indirizzo IP Pubblico, uno utilizzabile dal Pool assegnato (per inciso: Io l'avevo scritto che in queste condizioni avresti avuto un solo NAT e che questo si sarebbe manifestato sul Firewall appunto...e non due livelli di NAT...e quindi il NAT doppio non saresti MAI stato costretto ad attuarlo a meno di non avere una configurazione davvero particolare [doppio Firewall back to back] ma sono cose da Anti-Cyber-Attack tipo Double Bastion Host). Il Router diventa dunque un Bridge.

Sul tema della 5060...non credo proprio che il problema stia dalla parte dell'OSO...che, da questo punto di vista, è (varie) RFC compliant...e sulla 5060 non ho grandi dubbi (prova ne è che dalla Subnet interna ti registri usando la 5060). Secondo me c'è qualche cosa che interviene quando la richiesta di registrazione proviene dall'esterno e quindi il Firewall è l'imputato "number one".

A questo punto la domanda viene spontanea: che Firewall stai usando?

Saluti, Kimera.

[sattelema]

Ragazzi,
io ho provato su 2 ADSL diverse di 2 gestori diversi con 2 router diversi (una con NAT diretto sul router, l'altra con NAT sul firewall posto dietro al router) ma non cambia nulla..
Tra l'altro su entrambe le linee se faccio il NAT della porta 8801 verso l'IP privato dell'OSO il myPortal for Mobile funziona correttamente dall'esterno, perciò non credo sia un problema di NAT..
E comunque, posso capire che il NAT dia fastidio al VoIP per instaurare la comunicazione, ma che neanche faccia loggare il client..

[Lucky]

Anche risolvendo il problema della registrazione, come risolvereste il problema della mancanza di fonia?

Scusate, ma secondo me trovare il modo di far registrare un utente che poi non possa chiamare o ricevere mi sembra uno spreco di tempo.

Ciao!

[Kimera]

L'unico modo certo è l'instaurazione di una VPN (Client to Gateway, se l'utente è un road-warrior che si connette da casa o dalla strada oppure Gateway to Gateway, se tra due sedi fisse) e, attraverso la VPN, effettuare poi l'autenticazione...

[sattelema]

In effetti è proprio così,
ho avuto la conferma ufficiale da Siemens:

"This scenario does not work because we use direct payload and in the media data we send private ip addresses and these are not routable in Internet.
The registration is possible but you do not have payload.
Please use VPN for this scenario."

Fine dei miei tentativi in tale direzione..

[Kimera]

Citare sè stessi non è mai il massimo...ma lo faccio (nota la frase evidenziata in rosso):

Qualcuno potrebbe aggiungere (od obbiettare) che anche il più blasfemo dei Router ha funzionalità Firewall (benchè difficilmente funga da terminatore VPN come fa un Firewall di rango)...ma, detto in sintesi, un conto è un Firewall con "ALG Support" (ed anche qui...si spalancano le porte dell'infinito) ed un altro è un normale Router che offre il servizio di Virtual Server ([Port/Service]-Forwarding verso gli Host della IP Subnet privata)...se, all'apparenza, entrambi possono sortire effetti simili (raggiungibilità di alcuni specifici servizi interni dall'esterno, vedi RDP, VNC, SSH, HTTP/HTTPS e chi ne ha più ne metta...) dall'altro, per il VoIP ad esempio, non sono affatto la stessa cosa (quando nel Payload dei messaggi di un SIP Client è contenuto il proprio IP Privato e tale SIP Client deve connettersi con un altro SIP Client all'esterno) al punto di arrivare, se non ci si fa caso, agli annosi problemi del Simmetric NAT/Full-Cone NAT ecc.

E' dura andare a manipolare (con un dispositivo) il Payload per adattarlo alle esigenze (o per superare delle restrizioni) che ti impone un certo tipo di connessione...ecco perchè, da questo punto di vista, la VPN può essere una soluzione.

Una nota: se guardi la configurazione di OSO MX con gli ITSP (vedi Wiki), ad esempio, citano chiaramente che il NAT simmetrico non è supportato e che quando si assegna un IP Pubblico alla WAN dell'OSO addirittura vanno disattivate (se presenti) eventuali funzionalità ALG nel Router posto tra l'OSO ed Internet.

Gli anni sono passati ma gli scenari sono sempre gli stessi.

Saluti, Kimera.

[Gen]

Mmm...sono piuttosto scettico sul fatto che le centrali debbano vedersi l'un, l'altra come con una VPN o direttamente con un IP Pubblico, (in realtà sono scettico a priori su queste cose) posso capire che la chiamata magari non venga instaurata, e qui sarebbero un altro paio di maniche, ma se io da un IP esterno qualunque, punto un IP Pubblico, dove ho un NAT sulla porta 5060 che mi va a finire sull'OSO MX, per lo meno la registrazione deve avvenire...poi se vorrò chiamare o utilizzare dei servizi, questo è un altro discorso, ma la registrazione deve funzionare, allo stesso modo in cui, mi loggo internamente...a meno che, la porta 5060 non sia quella che utilizza l'OSO per il SIP (e se devo essere sincero, la cosa non mi sembra nemmeno così strana perchè la S di Standard, non ho mai capito bene perchè l'abbiano messa visto che di standard nel SIP c'è veramente molto poco)

Comunque farò qualche prova giusto per levarmi lo sfizio! 

Ho fatto anch'io moltissime prove un mesetto fa e non c'è stato nulla da fare (nemmeno con la registrazione), nella stessa condizione descritta da Hunter.
Qualcuno ha qualche aggiornamento?

Saluti,
Gen.

[Zanobini]

In uffcio da me stiamo provando SBC. Lo abbiamo provato prima su OSV e funziona corettamente. Su OSO MX V3 stiamo riscontrando dei problemi. Sulla chiamata in entrata dal Client SIP verso un interno di OSO MX funziona correttamente ma se da un interno OSO MX provo a chiamare il client SIP che vedo correttamente registrato con l'indirizzo Ip di SBC la chiamata non va a buon fine. Qualcuno ha mica fatto delle prove con SBC su OSO MX?

[Kimera]

Chissà se lo scenario OpenScape MX V3 + OpenScape SBC è supportato?

Dalle R.N. pare proprio di no...il che non significa che (per principio) non possa funzionare ma significa certamente che in Siemens non è stato certificato.

Da quel che ricordo l'OpenScape SBC è supportato con OpenScape Voice V5/V6 e V7...