MatteoSpi Ho capito solo metà del tuo messaggio. Puoi spiegare in modo più semplice per favore?
Per poter funzionare assegnando al cliente un IP privato, Melita usa un NAT a livello dei suoi apparati per mappare un IP pubblico - gli unici che possono accedere a internet - sugli IP privati. È molto simile al NAT che fanno i router dell'utente, solo che è gestito a livello di operatore ("carrier") ed è quindi chiamato Carrier Grade (CG) NAT.
Come tutti i NAT funziona (quasi) senza problemi quando una connessione inizia lato utente - il problema è che in VoIP quando arriva una chiamata la connessione inizia lato provider VoIP - il server VoIP deve essere in grado di chiamare il dispositivo VoIP dell'utente che sia il router stesso, o un ATA (Analog Telephone Adapter), o un centralino o telefono VoIP. Per farlo deve sapere a quali IP e porta collegarsi. E qui il NAT crea problemi.
Innanzi tutto bisogna saper qual è l'IP pubblico usato - e se su un NAT locale è facile, è quella assegnato all'interfaccia WAN, con il CG-NAT no. Poi bisogna sapere qual è la porta associata dal NAT all'IP, anche in questo caso in locale è abbastanza facile perché si può fare un port forwarding per associare le porte staticamente, con il CG-NAT no.
STUN (Session Traversal Utilities for NAT) è un protocollo che permette ad un dispositivo di interrogare un server che gli risponde con l'IP:porta che vede dall'esterno. In questo modo chi fa la richiesta può determinare dietro che tipo di NAT è, e nel caso del VoIP inserire nei messaggi le necessarie informazioni per essere contattato dal server. Il NAT Keepalive invia di tanto in tanto dei pacchetti per mantenere il mapping NAT attivo ed evitare che cambi. È necessario tarare l'intervallo in base alla durata del mapping NAT.
STUN ha un limite ed è che non funziona con il NAT di tipo "simmetrico". Ci sono altre tecniche che possono funzionare, ma non tutti i dispositivi economici le supportanto.
Non avendo mai usato Melita, non so dirti se questa soluzione funziona effettivamente.