OpenPath
OpenScape => OpenScape - Office (OSO MX/LX/HX) => Topic started by: Hunter on March 08, 2013, 06:43:09 pm
-
Ciao a tutti,
stavo facendo delle prove per registrare dei Client SIP che utilizziamo sui ns cellulari al ns OSO MX, normalmente con altre centrali è sufficiente aprire la porta 5060 e "nattarla" sull'IP privato del centralino, ma con l'OSO non riesco a registrarmi.
Viceversa se sono collegato alla WLAN aziendale non ho problemi ad usare il Client.
Bisogna aprire altre porte che voi sappiate!? :-\
-
Siete riusciti ad utlizzare dei client sip collegandovi ad un indirizzo pubblico nattato su un indirizzo privato???
Avete per caso un sbc?
Le porte che servono per far passare la voce sono in realtà un range da rtp-min a rtp-max, ma se c' è di mezzo nat e nientaltro dubito che funzioni.
-
Metti mai che abbiano davvero un SBC (tipo questo (http://www.siemens-enterprise.com/it/products-services/voice-solutions/openscape-voice/session-border-controller.aspx)) o abbiano realizzato uno STUN (dubito)...ma se c'è di mezzo solo il NAT (Port Forwarding) e questo è solo per la Porta 5060...la vedo non dura, durissima. Direi impenetrabile.
-
Ciao,
io ho lo stesso problema di Hunter, qualcuno sa come fare?
Ho provato con diversi client SIP e su diversi smartphone ma dall'esterno della rete aziendale non si loggano al sistema..
E' necessario nattare altre porte oltre alla 5060 UDP?
O bisogna usare questo OpenScape Session Border Controller??
Grazie.
-
Per semplificare le cose:
il centralino e il telefono devono vedersi l' un l' altro con l' indirizzo ip effettivo.
Quindi:
o si usa wan o dmz con indirizzo pubblico sul centralino (no nat)
o vpn
o si inserisce un apparecchiatura in mezzo (SBC appunto) che permette di "spaccare il pacchetto" e convertire gli indirizzi ip.
o ... al momento non me ne vengono altre
Solo con nat come dice Kimera non te la caverai mai.
Ciao
-
Soluzioni che prevedono la presenza di un SBC (sia esso X oppure Y) sono in uso nel mondo Enterprise (grandi aziende)...e, di certo, non vengono sviluppate ed implementate per essere convenienti quando da abilitare è "solo" il "singolo" Client SIP remoto.
Anni fa...ma davvero anni fa (correva l'anno 2003/2004...), quando ancora Siemens era nella fase di approccio al SIP per implementarlo poi nei propri sistemi (eravamo agli albori...), il problema del NAT Traversal era stato affrontato e sviscerato da alcuni sviluppatori (Siemens Svizzera) che hanno gettato le basi per i vari SIP Client (di Siemens) che usiamo ora.
Allego un documento dell'epoca (ora il dominio "mysip.ch" che veniva usato dagli sviluppatori per testare i SIP Clients non è più di Siemens Svizzera...) che, personalmente, ritengo "storico" (ed è una chicca introvabile...sperando di non infrangere qualche legge)...e che la dice lunga (ovviamente, ora come ora, in giro si possono trovare anche spiegazioni e rimedi, vedi caso di ALG/Firewall o di SBC, migliori...e più al passo con i tempi) sul problema dello stare "Behind a NAT".
Forse sarebbe il caso di andare a vedere lato Firewall cosa si ha (SIP ALG (http://ww.voiptuts.com/2011/02/what-is-sip-alg-application-layer.html)?)...prima di esporre il proprio sistema facendolo risiedere (almeno per la parte WAN) nella DMZ o prima di assegnare direttamente un indirizzo IP Pubblico (magari di un Pool a disposizione) alla sua WAN Interface.
Saluti, Kimera.
-
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! ;D
-
Kimera, il tuo documento è davvero una chicca, molto interessante considerando che è stato fatto 10 anni fa!
Tornando ai giorni nostri, io vorrei evitare di dare un IP pubblico al centralino, e usare un SBC per pochi client SIP remoti non vale la pena, forse la soluzione della VPN fra telefono e centrale è la giusta via di mezzo.
Ma a questo punto chiedo: quale protocollo va usato, IPSec, PPTP, L2TP?
Si può usare il software VPN già a bordo degli smartphone o bisogna usare un'app specifica?
Hunter, se scopri che l'OSO non usa la 5060 facci sapere!
-
Mah...difficile a dirsi...comunque è un fatto ormai noto che, a causa della caduta (avvenuta recentemente) del protocollo PPTP posto sotto attacco anti-crittografico (de-crittografico), ultimamente siano raccomandati IPSec ed L2TP rispetto al "debole" PPTP (che era forte fino a l'altro ieri...).
-
Kimera, il tuo documento è davvero una chicca, molto interessante considerando che è stato fatto 10 anni fa!
Stiamo deviando per la tangente...ma chicca per chicca...eccoti un posto dove qualcuno ha conservato (da qualche parte ho una Folder con tutto pure Io) le prove tangibili di quel passato. Vedi mysip (http://mirror.kioss.undip.ac.id/pustaka-bebas/library-sw-hw/windows-1/sip/softphone/mysip/) per le tracce lasciate...con tanto di Datasheet (http://mirror.kioss.undip.ac.id/pustaka-bebas/library-sw-hw/windows-1/sip/softphone/mysip/datasheet_sip-client-v2.pdf) del SIP Client (SCS)...e correva l'anno 2004!
Devo anche aver scambiato qualche mail con gli sviluppatori...all'epoca.
Alla storia non si comanda!
Saluti, Kimera.
-
Tornando al discorso relativo a come ovviare ai problemi EDIT
di tramite il NAT Traversal (ALG)...direi che vale sempre prima la pena di provare ad usare, se presenti, le funzionalità di SIP ALG (SIP Transformations) quando si hanno a disposizione dei Firewall che le possiedono. Non è detto che se ne riesca a venire a capo...ma tentar non nuoce...e poi bisogna sempre vedere che tipologia di indirizzamento IP Pubblico viene offerta dalla connessione in uso (ad esempio: un solo IP Pubblico sul quale si attua il NAT a livello di xDSL Router con conseguente Forwarding di tutte le Porte ed i Protocolli verso la WAN del Firewall retrostante oppure un Pool di IP Pubblici per il quale un indirizzo del Pool stesso può essere assegnato direttamente alla WAN del Firewall [in questo caso il NAT non lo attua il xDSL/Rotuer] ed al quale, in questo caso, spessa l'onere [o meno] del NAT verso la Subnet privata interna...sempre a seconda della posizione [LAN vs DMZ] in cui è [topo]logicamente posizionato l'IP-PBX).
-
Tornando al discorso relativo a come ovviare ai problemi EDIT di tramite il NAT Traversal (ALG)...direi che vale sempre prima la pena di provare ad usare, se presenti, le funzionalità di SIP ALG (SIP Transformations) quando si hanno a disposizione dei Firewall che le possiedono. Non è detto che se ne riesca a venire a capo...ma tentar non nuoce...e poi bisogna sempre vedere che tipologia di indirizzamento IP Pubblico viene offerta dalla connessione in uso (ad esempio: un solo IP Pubblico sul quale si attua il NAT a livello di xDSL Router con conseguente Forwarding di tutte le Porte ed i Protocolli verso la WAN del Firewall retrostante oppure un Pool di IP Pubblici per il quale un indirizzo del Pool stesso può essere assegnato direttamente alla WAN del Firewall [in questo caso il NAT non lo attua il xDSL/Rotuer] ed al quale, in questo caso, spessa l'onere [o meno] del NAT verso la Subnet privata interna...sempre a seconda della posizione [LAN vs DMZ] in cui è [topo]logicamente posizionato l'IP-PBX).
Lo scenario dove sto facendo le prove è un IP Pubblico pulito (stessa espressione che usiamo con gli elettricisti quando chiediamo i contatti per i citofono) assegnato alla WAN e poi è il Firewall "natta" le varie porte sugli IP Privati. Però ormai la curiosità mi sta lacerando, giusto per la cronaca, non faccio prove mettendo la centrale su un IP Pubblico, perchè so già che funziona.
Vi terrò aggiornati.
-
Lo scenario dove sto facendo le prove è un IP Pubblico pulito assegnato alla WAN e poi è il Firewall "natta" le varie porte sugli IP Privati.
(un IP Pubblico è) Assegnato alla WAN di chi?
...è assegnato alla WAN del Firewall (si usano 3 IP...due assegnati sulle interfacce WAN e LAN del Router ed uno sulla WAN del Firewall...) ed il Firewall, che è posto dietro il Router (quindi con un solo livello di NAT realizzato appunto dal Firewall...visto che il Router non fa NAT in questo caso), esegue poi il suo NAT (quindi NAT singolo)...oppure tale IP Pubblico è assegnato alla WAN del Router che esegue un primo NAT lasciando al Firewall il compito di eseguire il secondo (quindi double-NAT)?
Di solito quando si ha un solo IP Pubblico statico non si può evitare il doppio NAT (anche se si fa Any Port/Any Protocol Forwarding verso la WAN del Firewall)...nel senso che tale IP Pubblico è assegnato dal gestore ITSP alla WAN del Router a prescindere da cosa c'è alle spalle tale Router (potrebbe anche non esserci un Firewall)...e tale Router deve quindi realizzare forzosamente il primo NAT verso la sua LAN (ossia verso la Subnet interna o verso comunque la Subnet interna che si instaura tra la sua LAN e la WAN dell'eventuale Firewall posto alle sue spalle, sempre che questo ci sia)...e quindi l'eventuale Firewall alla fine si ritrova a fare il secondo NAT verso la LAN privata...mi pare che solo avendo un Pool di IP Pubblici si possa ricadere nel primo caso (NAT fatto solo dal Firewall).
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.
La VPN (Client to Gateway e Gateway to Gateway) può sicuramente essere una soluzione...
Nota: insisto con lo scrivere che c'è, da qualche parte, un (xDSL)-Router interposto tra Internet ed il Firewall ma, questi due apparati, potrebbero essere anche "accorpati" in un unico device (un xDSL Modem/Router/Firewall...esempio: il Netgear DGVF338 che in più aveva anche il WiFi)...ma questa è solo una mia presunzione per tentare di dare un nome alle cose.
Correggetemi se sbaglio (Sopra ho corretto "...di NAT Traversal (ALG)..." con "...di tramite il NAT Traversal (ALG)..." altrimenti sembra che il NAT Traversal sia il problema e non una tecnica per risolvere un problema!).
-
Per gli scettici (a parte TUTTO quello che si trova in Internet relativamente al NAT e alle conseguenze, positive e negative, del suo uso) invito la lettura di questa (https://gigaset.com/medias/sys_master/VoIP_nat-troubleshooting_en.html) pagina (fonte Gigaset Communications GmbH, AKA Gigaset PRO, per i suoi terminali DECT/IP). Non tanto perchè essa fa riferimento a questioni specifiche dei Gigaset VoIP ma soprattutto per la parte di "Background Informations" annessa.
Saluti, Kimera.
-
Lo scenario dove sto facendo le prove è un IP Pubblico pulito assegnato alla WAN e poi è il Firewall "natta" le varie porte sugli IP Privati.
(un IP Pubblico è) Assegnato alla WAN di chi?
Alla WAN del Firewall. ;D Avendo una subnet pubblica /28 non aveva senso fare un doppio NAT, a che pro!? :o
Il router diventa quindi trasparente poichè diventa il Gateway del Firewall, non ci sono NAT di mezzo.
Poi sarò io dal mio firewall che farò i vari PAT/NAT come preferite chiamarli. In ogni caso rimango abbastanza curioso sull'arcano. Perchè i casi sono veramente nell'ambito del rasoio di Occam, quindi o il firewall non fa il NAT corretto, oppure la porta 5060 non è quella che l'OSO MX utilizza per la registrazione dei client SIP, la seconda delle due mi lascia più perplesso perchè forzando internamente la registrazione sulla porta 5060 la registrazione avviene normalmente....uhm... :-X
-
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.
-
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..
-
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!
-
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...
-
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..
-
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.
-
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! ;D
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.
-
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?
-
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...