Die wenigsten Büro- und Privat-PCs haben eine eigene feste IP-Adresse aus dem öffentlichen Adressbereich des Internets. Diese wäre mit dem jetzigen IPv4-Standard wahrscheinlich auch nicht für jedes TCP/IP-taugliche Gerät verfügbar, da der IPv4-Adressraum zu klein ist für alle bereits vorhandenen Geräte.

Der IPv4-Adressraum verfügt über insgesamt 2 hoch 32 einzelne Adressen und man kann wahrscheinlich nicht herausfinden, ob es wirklich noch möglich wäre, jedem IP-fähigen, aktuell vorhandenen Gerät eine feste IP-Adresse aus dem öffentlichen Adressraum zu geben. Das Problem ist auch, dass die Adressen nicht wahllos vergeben werden können, sondern nur innerhalb sinnvoller Broadcastdomains und bereits ganze Class-A-Bereiche (ca. 17 Mio Adressen) in den Anfängen des Internets großzügig auch einzelnen Firmen zugeteilt wurden.

Eine Lösung dieses Problems ist es Rechner, bzw. gesamte Rechnernetze, über ein so genanntes NAT-Gateway mit dem Internet zu verbinden. NAT ist das Akronym für "Network Address Translation". Mithilfe von NAT teilt ein einzelner Rechner (NAT-Gateway) seine feste offizielle IP-Adresse mit allen verbundenen Rechnern, die in der Regel über eine IP-Adresse aus dem privaten, im Internet nicht gerouteten Bereich^[78], verfügen. Ein NAT-Gateway nimmt alle Anfragen von Rechnern aus dem privaten Netz (meist Intranet genannt) an und leitet diese dann mit der eigenen offiziellen IP-Adresse ins Internet weiter. Kommen die angeforderten Daten aus dem Internet zurück, leitet das NAT-Gateway die Daten entsprechend ins Intranet^[79]. TCP/IP-Datenpakete bestehen in der Regel aus einem Envelope (Umschlag) und dem Content/Payload (Inhalt/Nutzlast). Im Envelope stehen Informationen über Ursprung und Ziel des Contents, also auch die IP-Adresse des Rechners, von dem die Kommunikation gestartet wurde. Diese Daten werden vom NAT-Gateway umgeschrieben. Es merkt sich die ursprüngliche IP-Adresse (für die Rückantwort) und schreibt für den öffentlichen Bereich des Internets seine eigene offizielle IP-Adresse in den Envelope. Kommen die angeforderten Daten zurück, schreibt das NAT-Gateway wieder die ursprüngliche IP-Adresse in den Envelope und leitet die Daten entsprechend an den Rechner zurück, der eigentlich die Kommunikaton gestartet hatte. Dies klappt bei den meisten Protokollen sehr gut. Allerdings benutzt SIP nicht den Umschlag, sondern schreibt die für das Protokoll benötigte IP-Adresse in den Inhalt des Paketes. Normale NAT-Gateways können nur mit IP-Adressen im Envelope umgehen, nicht aber im Content. Der gängige Fehler ist nun folgender: Der Zielrechner verfügt über eine offizielle IP-Adresse und der Quellrechner über eine private Adresse. Der anfordernde Rechner adressiert die Pakete mit der offiziellen IP-Adresse und schreibt seine Absenderadresse direkt in den Content und nicht in den Envelope. Die Pakete werden korrekt geroutet und landen beim Zielrechner. Da die Quell-IP nicht im Envelope gesetzt war, konnte das NAT-Gateway die private nicht in eine offizielle IP-Adresse umschreiben. Daher versucht der Zielrechner, die Daten an die in den Paketen angegebene IP-Adresse zu senden. IP-Adressen aus dem privaten Adressbereich werden jedoch nicht geroutet und der Quellrechner erhält keine Daten vom Zielrechner. In der Regel besitzen die Rechner im Intranet eines Unternehmens IP-Adressen aus dem privaten Adressbereich und müssen für die Kommunikation mit Rechnern im Internet auf die Dienste eines NAT-Gateways zurückgreifen.^[80] Für Telefone im Intranet ist diese Adressproblematik ohne Belang, da ja im Intranet alle IP-Adressen geroutet und IP-Pakete korrekt verteilt werden. Verbindungen ins Internet sind jedoch mit SIP standardmäßig über ein NAT-Gateway nicht möglich. Eine genaue Beschreibung des NAT-Problems, das auch für einige andere Anwendungen relevant ist, findet man in der Wikipedia unter http://de.wikipedia.org/wiki/Network_Address_Translation.

	Auf welchen Ports Asterisk nach eingehenden RTP-Verbindungen lauscht, kann in der rtp.conf eingestellt werden.