La téléphonie IP ne peut pas fonctionner avec la traduction d'adresses réseau (NAT), car si des adresses IP privées (RFC-1918) sont échangées dans des messages de signalisation, ces adresses ne sont pas accessibles du côté public du NAT et ne peuvent pas être utilisées pour les sessions multimédias.

Le problème n'est pas rencontré dans tous les scénarios de VoIP. Il n’est pas utilisé pour l’accès à distance basé sur le VPN et les NAT ne sont généralement pas nécessaires à l’intérieur du réseau de l’entreprise. La VoIP doit traverser le NAT habituellement à la frontière entre l'entreprise et un circuit VoIP vers un fournisseur de services ainsi que dans le service VoIP hébergé.

Si la conception du réseau comprend un pare-feu dans le réseau de l'entreprise pour protéger certains serveurs ou une partie du réseau afin que le trafic de téléphonie IP doive traverser le pare-feu interne, alors le pare-feu ne doit pas effectuer de fonction NAT. La téléphonie IP fonctionnera ensuite à travers le pare-feu une fois que les ports appropriés seront ouverts sur le pare-feu. Pour obtenir de plus amples renseignements sur la liste des ports nécessaires pour tout produit Avaya, consultez le site Web de soutien d’Avaya à l’adresse https://support.avaya.com pour consulter la documentation et les articles de connaissances actuels relatifs à l’ouverture d’une demande de service.

Lorsque vous connectez l'entreprise à un fournisseur de services IPT par le biais d'une ligne VoIP, soit SIP, soit H.323, un NAT est effectué à la frontière de l'entreprise. La solution pour ce scénario est de déployer un Session Border Controller (SBC) près du NAT, par exemple, dans la DMZ de l'entreprise. Les SBC de plusieurs fournisseurs ont été testés pour leur interopérabilité avec les solutions de téléphonie IP d'Avaya.

Vous pouvez également, dans certains cas, utiliser un Application Layer Gateway (ALG).

Des solutions basées sur des normes telles qu'ICE et STUN devraient être prises en charge dans certains scénarios de traversée de NAT.